- NANOG - lists.nanog.org

Cleveland or Columbus Colocation?
by Charles Mills 09 Nov '10

09 Nov '10

Can anyone from these areas recommend someone? I know Expedient is in Cleveland but would like others to look at as well. Feel free to contact me off list. Chuck

3 2

Hotmail Operations
by David Hooton 09 Nov '10

09 Nov '10

Hi All, Could someone from Hotmail operations please contact me offlist, a couple of your outbound SMTP relays are trying to wipe one of our customers off the face of the earth. -- Kind Regards, David Hooton Managing Director Platform Networks www.platformnetworks.net

1 0

Re: RINA - scott whaps at the nanog hornets nest :-)
by Scott Weeks 09 Nov '10

09 Nov '10

Been unexpectedly gone for the weekend, apologies for the delay. Wow, can subjects get hijacked quickly here. I think it happened within one or two emails. It was just for weekend fun anyway... --- bill(a)herrin.us wrote: From: William Herrin <bill(a)herrin.us> > And so, "...the first principle of our proposed new network architecture: Layers are recursive." : Anyone who has bridged an ethernet via a TCP based : IPSec tunnel understands that layers are recursive. WRT the paper I'm having trouble correlating what you say with their notion of recursive layer network communications. It seems apples and oranges, but maybe I have Monday-its. It's only a little after noon here. > http://www.ionary.com/PSOC-MovingBeyondTCP.pdf : John Day has been chasing this notion long enough to write three : network stacks. If it works and isn't obviously inferior in its : operational resource consumption, where's the proof-of-concept code? Not having read the following enough, being in operations and not in the research areas as much as others on this list I don my flameproof underpants and post this: pouzinsociety.org gives: --------------------------------------------------------- "The TSSG developed CBA prototype, which consists of a fully functional componentised network stack and the ancillary supporting infrastructure, has been contributed to the Pouzin Society as the TINOS project. TINOS will provide the underlying platform and execution environment upon which a RINA prototype can be developed. The TSSG and i2CAT will be joining forces with the Pouzin Society to contribute to the development of a RINA prototype based on the TINOS platform. The TINOS code is freely available under the LGPL license." --------------------------------------------------------- the "CBA prototype" link being: http://www.tssg.org/4WARD/2010/07/component_based_architecture_n.html Seemingly unfortunate (to me) is: "...an open-source project to create a Java platform operating system." : The last time this was discussed in the Routing Research Group, none : of the proponents were able to adequately describe how to build a : translation/forwarding table in the routers or whatever passes for : routers in this design. When I asked on RRG I was told by the chairs, privately, that no open-slate designs would be considered. No RINA proponents are participating in the list, as well. WRT RRG I had assumed various proposals would be considered with equal respect and dignity, the basic components described, a 'winner' selected and then the engineering details designed. Watching the list has been an experience in reality (it's not all peace, love and happiness out there :-) and I now more clearly understand the comments made by others on this list about the process. Since it wasn't allowed on RRG, I hoped to spur discussion here between those who spend more cycles in research and learn from that discussion. It didn't happen yet... ;-) scott ps. Thanks for the response. I am really curious about the approach. It would seem to weed out a lot of redundant things that various layers repeat.

3 2

Re: RINA - scott whaps at the nanog hornets nest :-)
by Scott Weeks 09 Nov '10

09 Nov '10

--- dot(a)dotat.at wrote: The point of a clean slate design is to rethink the foundations of your architecture, and get rid of constraints that set you up to fail. ---------------------------------- Yes, and I thought this idea could be the beginning of one way to do that and became interested in what others thought. However, there're not very many avenues to ask for competent responses on things like this. Thanks for the responses. scott ps. The "NAT is your friend" part is what I thought would whap at the nest for weekend fun... :-)

1 0

Re: RINA - scott whaps at the nanog hornets nest :-)
by Scott Weeks 09 Nov '10

09 Nov '10

--- dot(a)dotat.at wrote: From: Tony Finch <dot(a)dotat.at> : I note that he doesn't actually describe how to implement : a large-scale addressing and routing architecture. It's all : handwaving. There is more discussed in the book. The paper was written by another person and had to only hit the highlights, or it'd be too long for folks to want to read. I'd imagine you can get a copy of the book in a university library. :And he seems to think that core routers can cope with per-flow state. Can you elaborate for me? : The only bits he's at all concrete about are the transport : protocol, which isn't really where the unsolved problems are. It wasn't about just solving problems. It seems to me to be about if you could clean-slate design, what would you do? AFAICT the RRG folks are specifically focused on fixing problems: map-n-encap and tunneling being the most liked solutions. One similar thing to other proposals on that list, though, that has me wondering is the use of a 'server' in the middle to keep track of everything. scott

2 1

Re: [j-nsp] EX4200 JunOS Recommendation
by GIULIANO (UOL) 08 Nov '10

08 Nov '10

We are running 10.2R3 for 10 x EX4200. Everything is working fine ... from VC to BGP and virtual routers. > On Mon, Nov 8, 2010 at 2:59 PM, Richard A Steenbergen <ras(a)e-gerbil.net>wrote: > >> On Mon, Nov 08, 2010 at 11:43:55AM -0800, Mehmet Akcin wrote: >>> Hi Keegan, >>> >>> I always try to go with >>> >>> >> https://www.juniper.net/customers/csc/software/junos_software_versions.jsp >> >> Based on past experience, I find this list to be a giant load of horse >> shit. You'd have better luck picking good versions of code with a magic >> 8ball. > > > hahahahah For one, I don't think I would have taken that quite as seriously > coming from anyone else. Secondly I'm new here, but it's better than NANOG. > > >> Unfortunately I can't tell you specifically what works best for >> L2 on EX4200 because we use none of the first and very little of the >> second, but I can give you a very very long list of reasons why 10.2R3 >> is (at this exact moment) the best choice for EX8200 doing routing. >> > > We use the big cats for this but this may help someone I know. Thanks. > >> >> -- >> Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras >> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) >> >> >> > _______________________________________________ > juniper-nsp mailing list juniper-nsp(a)puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp >

1 0

Netflow Tool
by Mike Gatti 07 Nov '10

07 Nov '10

Anyone out there using a good netflow collector that has the capability data to export to CSV? Open Source would be best, but any suggestions are welcome. Thanks, =+=+=+=+=+=+=+=+=+=+=+=+= Michael Gatti cell.703.347.4412 ekim.ittag(a)gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=

11 10

.mil broken again?
by Antonio Querubin 07 Nov '10

07 Nov '10

I'm seeing DNS lookup failures for us.af.mil, usmc.mil, us.army.mil, and navy.mil. Possibly more .mil are affected. This is getting way too frequent. Anybody got a good out-of-band (not .mil) contact for reporting this? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony(a)lava.net

1 0

BGP support on ASA5585-X
by srg 07 Nov '10

07 Nov '10

Hi: At this moment we know that ASA5585-X does not support BGP. Does anybody know if BGP support in the ASA5585-X is in roadmap? More precisely... MP-BGP support in the ASA5585-X? Any "oficial" link in the Cisco website about this? (I did't find it) Thanks a lot and best regards

10 14

Ethernet performance tests
by Diogo Montagner 07 Nov '10

07 Nov '10

Hello everyone, I am looking for performance test methodology for ethernet-based circuits. These ethernet circuits can be: dark-fiber, l2circuit (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet circuit can be a mix of these technologies, like below: CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> CPE The goal is verify the performance end-to-end. I am looking for tools that can check at least the following parameters: - loss - latency - jitter - bandwidth - out-of-order delivery At this moment I have been used IPerf to achieve these results. But I would like to check if there is some test devices that can be used in situations like that to verify the ethernet-based circuit performance. The objective of these tests is to verify the signed SLAs of each circuit before the customer start to use it. I checked all MEF specifications and I only find something related to performance for Circuit Emulation over Metro-E (which is not my case). Appreciate your comments. Thanks! ./diogo -montagner

8 12