Re: [Nanog-futures] Admission for Committee Members
On Wed, Aug 31, 2011 at 8:30 AM, David Temkin d...@temk.in wrote: All, I would like to propose an amendment to the bylaws for the coming election cycle. The various committees put in many tireless hours of effort to bring a content rich, well attended, well sponsored meeting to our attendees. In return they generally get a free lunch and a brief thank you. I propose that any committee member who attends six or more committee meetings between NANOG meetings is entitled to a free registration for the upcoming meeting. Attendance would be gauged by the chair of the committee and this would only be available as a benefit to sanctioned committees. I'll keep this short and sweet, however I feel that this is the least that we can do for our hard working committee members. I would ask that the Board sponsor this for the upcoming election, however if they choose not to I think we can put this out to petition. Hmm. Six is a good number as the PC, at least, normally has exactly six meetings between NANOGs. A strong incentive for at least some to make all of the meetings. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Rogers Canada using 7.0.0.0/8 for internal address space
From: valdis.kletni...@vt.edu Date: Tue, 24 May 2011 00:22:36 -0400 On Mon, 23 May 2011 21:14:02 PDT, Cameron Byrne said: Now, the onus is on the DoD to make its content available over unique IPv6 space so that the Roger's customers can get to it using the 6to4-PMT solution. There is always a solution. Which they should be ready to do already, since didn't the US Govt. mandate IPv6 support sometime last century? ;) Not really. Backbone networks were required tobe IPv6 capable back last decade, but no requirement for any end systems or services. (Nor was backbone network defined.) By October 1, 2012 all public services (web, mail, and DNS) must be IPv6 capable and reachable using native IPv6 via all carriers being used for public access. By October 1, 2014 all U.S. government services and networks must support IPv6. No tunnels. No special names for IPv6 services. It also includes any government sponsored services that are contracted out and government laboratories. Both some DOD and civilian network have been IPv6 capable for some years, there was no requirement for it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: NANOG 52 - Room block filling up!
Date: Mon, 23 May 2011 11:08:10 -0400 (EDT) From: Brandon Ross br...@pobox.com I take that back, it shows as booked if you go through normal booking channels, if you use the starwoodmeetings URL in the NANOG meeting information page it shows availability. Which means our block is not full, but, outside the block, the hotel is fully booked. If we don't use all of the NANOG block by the 30th, those rooms will probably be released for general use but it is very likely that if you don't reserve soon either the block will fill or the few rooms left will be booked shortly after they are released. Don't wait too long! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: coprorations using BGP for advertising prefixes in mid-1990s
From: Tony Li tony...@tony.li Date: Thu, 12 May 2011 16:47:54 -0700 On May 12, 2011, at 2:37 PM, Kevin Oberman wrote: Does no one remember EGP? ASNs are MUCH older than BGP. And we were using BGPv3 prior to the existence of V4. We used BGPv4 back in the days when Tony Li would chastise us for reporting a bug in a 10 day old Cisco build saying that we could not expect BGPv4 code over a week old to work. He felt that we should deploy new code daily. To be fair, that was for folks on the isp-geeks mailing list, who were effectively doing alpha test with me. I was fixing about 1 significant bug per day and doing at least one release per day. 10 day old code was missing at least 10 fixes... ;-) And that was BGP3. BGP4 was the next developer. Regards, Tony Yes, Tony. It was absolutely fair. It was certainly not your (or Cisco's) fault. It was a huge effort on the part of a small number of Cisco engineers (I assume that you and Paul wrote most of the code) to get a complex protocol stable and ready for implementation in far too little time. It was utter insanity and it all worked! (Just in time for the death of the PRDB). In no way was I criticizing your efforts. I just remember that message and thinking how much testing and planning we do today before rolling new code onto production systems. The idea of reloading production routers with code we absolutely knew would prove buggy on a weekly (or more than weekly) basis seems so unimaginable today. I'm looking forward to seeing Milo at NANOG 52 next month in Denver! I'm sure that he remembers all of this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: coprorations using BGP for advertising prefixes in mid-1990s
Date: Thu, 12 May 2011 17:15:17 -0400 From: Dorn Hetzel d...@hetzel.org The actual number would be considerably smaller as there were large (for some definition of large) block assignments of ASNs ~1000 or so to various academic networking entities such as NSFNet and regional networks as well as other Federal/Military networking organisations. -dorian Well, for one data point, I was issued 3492 around Spring of 1994. Does no one remember EGP? ASNs are MUCH older than BGP. And we were using BGPv3 prior to the existence of V4. We used BGPv4 back in the days when Tony Li would chastise us for reporting a bug in a 10 day old Cisco build saying that we could not expect BGPv4 code over a week old to work. He felt that we should deploy new code daily. The big push was to have v4 available before the old PRDB was frozen by Merit/NSFnet. (And, who remembers the PRDB?) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: 23,000 IP addresses
From: Owen DeLong o...@delong.com Date: Tue, 10 May 2011 12:02:33 -0700 On May 10, 2011, at 11:49 AM, Michael Holstein wrote: In the EU you have Directive 2006/24/EC: But I'm not, and neither are most of the ISPs in the linked document. Regards, Michael Holstein Information Security Administrator Cleveland State University In the US, I believe that CALEA requires you to have those records for 7 years. Owen, Afraid not. As of this time there are no data retention requirements in CALEA. There is a proposal to add data retention to CALEA this year, but I can't even find anything indicating the legislation has been introduced. According to an article in the NY Times last fall, the FBI will be asking for several new tools in CALEA that include data retention requirements, requiring P2P software to allow intercept and requiring that providers dong encryption (e.g. Blackberry) to provide the ability for the government to decrypt the data. I don't know that legislation has actually been introduced, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: 23,000 IP addresses
Date: Tue, 10 May 2011 15:51:32 -0400 From: Michael Holstein michael.holst...@csuohio.edu In the US, I believe that CALEA requires you to have those records for 7 years. No, it doesn't (records *of the requests* are required, but no obligation to create subscriber records exists). Even if it did .. academic institutions are exempt (to CALEA) as private networks.* There are various legislative attempts afoot to create one here in the US .. but none have passed. There is a great deal of uncertainty about the issue of academic institutions being exempt. I know tha that the opinion of the University of California's Counsel was that the wording in the last CALEA update a few years ago removed that exemption and a representative of the FBI, speaking on CALEA requirements, was explicit in saying that they were not exempt. (Of course, that would be the FBI's position.) In any case, get your own legal opinion about this. Don't rely on NANOG for legal advice. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Yahoo and IPv6
From: valdis.kletni...@vt.edu Date: Mon, 09 May 2011 12:25:55 -0400 On Mon, 09 May 2011 18:16:20 +0300, Arie Vayner said: Actually, I have just noticed a slightly more disturbing thing on the Yahoo IPv6 help page... I have IPv6 connectivity through a HE tunnel, and I can reach IPv6 services (the only issue is that my ISP's DNS is not IPv6 enabled), but I tried to run the Start IPv6 Test tool at http://help.yahoo.com/l/us/yahoo/ipv6/ and it says: We detected an issue with your IPv6 configuration. On World IPv6 Day, you will have issues reaching Yahoo!, as well as your other favorite web sites. The *really* depressing part is that it says the same thing for me, on a *known* working IPv6 network. And then when I retry it a few minutes later, with a tcpdump running, it works. And then another try says it failed, though tcpdump shows it seems to work. For what it's worth, the attempted download file is: % wget http://v6test.yahoo.com/eng/test/eye-test.png --2011-05-09 11:44:39-- http://v6test.yahoo.com/eng/test/eye-test.png Resolving v6test.yahoo.com... 2001:4998:f00d:1fe::2000, 2001:4998:f00d:1fe::2002, 2001:4998:f00d:1fe::2003, ... Connecting to v6test.yahoo.com|2001:4998:f00d:1fe::2000|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [image/png] Saving to: `eye-test.png.1' [ = ] 2,086 --.-K/s in 0s 2011-05-09 11:44:39 (154 MB/s) - `eye-test.png.1' saved [2086] Looking at the Javascript that drives the test, it appears the *real* problem is that they set a 3 second timeout on the download - which basically means that if you have to retransmit either the DNS query or the TCP SYN, you're dead as far as the test is concerned. I have talked to Yahoo engineers about this and they say that their testing has shown that, if it takes more than 3 seconds for a site to load, they start to lose significant traffic. Hence the 3 second timeout. Sadly, I'm afraid that they have a point, but at the same time I suspect that they are assuring failure for almost everyone. A 5 second timeout would probably be more reasonable, but is probably unacceptable to Yahoo management. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Cent OS migration
Date: Mon, 9 May 2011 14:58:57 -0400 (EDT) From: Jay Ashworth j...@baylink.com - Original Message - From: Walter Vaughan wvaug...@steelerubber.com You most definately will want to make sure your user id's are identical between the two systems, otherwise stuff like @CB will have wrong information. Excellent point. Also, do you have any expertise maintaing a linux box? If you want something closer to SCO in mentality, FreeBSD and SCO have the same grandparents. Linux is like the cute girl that moved into town. Stuff isn't always where you expect to find it, and you may get a surprise if you reach into the wrong place. Oh, don't *even* send him to BSD. CentOS and SuSE 11 are the only rational free Linuces for business use. *Any* of the BSDs are so much less well supported that they'll drive you straight up a wall. Depends on what he is doing. BSDs tend to be far more mature than any Linux. They are poor systems for desktops or anything like that. They are heavily used as servers by many vary large providers and as the basis for many products like Ironport (Cisco) and JunOS (Juniper). (I'll admit that I run FreeBSD on my laptop with great success, but you have to REALLY want it.) That said, the BSD community is smaller and the addition of features and the latest hardware support is slower on BSDs. If you are very concerned with security, I'd never hesitate to recommend OpenBSD. For more general use, FreeBSD. For an unusual platform, NetBSD. For a walk on the wild side, try DragonFly and Hammer. That said, I run both Linux and FreeBSD regularly and they both have their place. You want the right tool for the job. The one Linux distro I don't recommend for experienced users is Ubuntu. I don't like Windows because it presumes it know how I want to do things better than I do and Ubuntu does the same. If my sister was planing to play with Linux, I'd send her directly to Ubuntu, though. (Tool...job. She does not get along well with computers.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Top-posting (was: Barracuda Networks is at it again: Any Suggestions as to anAlternative? )
From: Michael Painter tvhaw...@shaka.com Date: Sun, 10 Apr 2011 23:11:44 -1000 gord wrote: I wonder if there's a filter for top-postings in list that have a bottom-posting rule? This thread is very operationally interesting to me but I've lost the plot :( http://www.nanog.org/mailinglist/listfaqs/generalfaq.php?qt=convent refers. PS: I know that some devices actually prevent bottom-posting by default. Workarounds are possible and are evident in other recent posts to this list. Additionally, may I suggest you file a bug report with your vendors or switch to a device that you can control properly :) It makes the thread very hard to follow. Why not? Please don't top post! I used to have this available for a 'signature', but, with a few exceptions, it seems to fall on blind eyes these days.sigh I put nearly identical text in response to top-posted messages and, if it was not too difficult, move the top-posted response to the end, before my response. Of late I have started to get responses from people (not even the person who top-posted) saying that I should f*** off and that they would post however they wanted. Very hostile and even threatening. I even manage to bottom post from my iPod. With cut and paste, it's really not hard, but I guess it's just beyond the capacities of some and somehow offensive to others. **Sigh** -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: 6453 routing leaks (January and Today)
From: Jared Mauch ja...@puck.nether.net Date: Thu, 24 Feb 2011 16:59:52 -0500 It appears there have been a large number of routing leaks from 6453 today based on my detection scripts that have been running. (shameless plug for http://puck.nether.net/bgp/leakinfo.cgi) A quick report of the data show (for today so far) a few thousand of leaks more than is normal for a day like today. I included a snapshot of yesterday below as well. I've included a more detailed report of the prefixes observed involved here: http://puck.nether.net/~jared/tata-leak-20110224.txt This seems to be a somewhat common event for 6453, loking through the history of data available, another event happened on 2011-01-28 as well. I'm interested in what best operational practices people have employed to help avoid the leaks seen here so I can document them for others to learn to prevent this from happening again. - Jared bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-24' group by blame_asn,asn_responsible order by 1 desc; count | blame_asn | asn_responsible ---+---+- 2208 | 6453 | 6453 360 | 7473 | 3257 230 | | 170 | 17379 | 5511 130 | 8068 | 3356 39 | 3225 | 6453 34 | 45419 | 3356 26 | 3356 | 3356 25 | 12180 | 2828 18 | 22351 | 701 16 | 7991 | 2914 16 | 14051 | 1239 10 | 29571 | 5511 4 | 32327 | 2828 4 | 8966 | 2914 4 | 19080 | 1239 4 | 30209 | 7018 4 | 18734 | 701 4 | 4657 | 3320 3 | 33748 | 1239 2 | 5056 | 1239 2 | 10026 | 2828 2 | 12252 | 2914 1 | 11696 | 2828 (24 rows) bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-02-23' group by blame_asn,asn_responsible order by 1 desc; count | blame_asn | asn_responsible ---+---+- 384 | 7473 | 3257 120 | 17379 | 5511 48 | | 27 | 45419 | 3356 24 | 12180 | 2828 11 | 23456 | 2914 (6 rows) bgp=# select count(blame_asn),blame_asn,asn_responsible from leakinfo where aprox_time::date = '2011-01-28' group by blame_asn,asn_responsible order by 1 desc; count | blame_asn | asn_responsible ---+---+- 9119 | 6453 | 6453 2265 | | 355 | 2914 | 2914 313 | 7473 | 3257 250 | 17379 | 5511 213 | 32592 | 701 106 | 3790 | 1239 72 | 19108 | 6461 62 | 14051 | 1239 51 | 34977 | 6453 48 | 31133 | 3356 47 | 8657 | 174 32 | 7713 | 2914 31 | 1257 | 1239 31 | 8966 | 2914 30 | 30209 | 7018 30 | 31133 | 1299 29 | 8342 | 1239 24 | 38925 | 3320 24 | 12180 | 2828 22 | 8657 | 3549 21 | 15641 | 3549 18 | 31133 | 2914 16 | 15412 | 2914 15 | 7473 | 3549 10 | 6762 | 1299 10 | 6762 | 7018 10 | 20299 | 1239 10 | 6762 | 3561 10 | 6762 | 174 9 | 4323 | 2914 7 | 26163 | 6461 7 | 9505 | 174 7 | 15149 | 6461 7 | 9070 | 3549 7 | 7819 | 6461 6 | 7473 | 174 6 | 3216 | 3549 6 | 1273 | 174 5 | 8657 | 3356 5 | 26769 | 3549 5 | 6762 | 2914 5 | 6762 | 3356 4 | 8047 | 701 4 | 8877 | 174 4 | 174 | 174 2 | 20299 | 174 2 | 7843 | 174 2 | 7473 | 6453 2 | 8928 | 3320 2 | 7991 | 2914 1 | 1273 | 3549 1 | 20485 | 2914 1 | 3216 | 1239 (54 rows) Can't say if it was a leak or de aggregation, but TATA announcements to us jumped from about 70,000 to almost 190,000 for a while today, then dropped back down. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: [Nanog-futures] NewNOG Website now IPv6 Enabled
FWIW, I get there via V6 and it looks fine. I do get the IPv6 address for newnog.org. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From: Michael K. Smith - Adhost mksm...@adhost.com Date: Tue, 8 Feb 2011 04:00:15 + Hey Shawn: Can I hit you offlist for some troubleshooting? I'm not seeing the same behavior from elsewhere. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) On 2/7/11 7:50 PM, Sean Figgins s...@labrats.us wrote: Does not seem that the DNS query returns any IPv6 information. And the normal page is just blank at the moment... -Sean On 2/7/11 8:24 PM, Michael K. Smith - Adhost wrote: Hello Everyone: We now have a fully functioning IPv6 website for http://www.newnog.org. If you find any site functionality that is broken please let me know! Many thanks to Owen for pointing out that the site was not reachable via IPv6, particularly given the recent global allocation event, Rob Seastrom for providing a quick turnaround on a record whilst on vacation, John Van Oppen for helping me test the site from a v6-enabled network (now? nope tap, tap, now? nope) and Duane Wessels for bringing Apache-fu to bear. If anyone would like to volunteer to chasing down v6 reachability to Paypal assets, I'd love to hear from them. :-) Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Agenda for Miami
Date: Tue, 11 Jan 2011 19:22:47 + From: Schiller, Heather A heather.schil...@verizonbusiness.com Hopefully posted soonish? Less than 3 weeks to the meeting, the early registration window has passed and there is still no agenda. Heather, Yes, the holidays and the collision with Internet2 Joint Techs has slowed down the process. The PC is meeting on Thursday to pretty much finalize the agenda and I hope it will be available this week. -- R. Kevin Oberman, Network Engineer NANOG Program Committee
Re: ARIN and the RPKI (was Re: AltDB?)
Date: Thu, 06 Jan 2011 14:24:01 +0900 From: Randy Bush ra...@psg.com I think ACLs here means prefix-lists ... or I hope that's what Randy meant? sorry. yes, irr based prefix lists. and, sad to say, data which have sucked for 15+ years. i was the poster child for the irr, and it just never took off. [ irr data are pretty bad except for some islands where there is culture of maintining them. and, as it is a global internet, islands don't help much. europe and japan are two islands with better than the average irr data quality. and they have rpki rolling to varied degrees. ] The day of reasonable accuracy of the IRR ended when UUnet bought ANI. Since ANI actually used the IRR to generate there router configs and ANI was pretty big, people were really forced to register. Curtis had a lot of excellent software that did all sorts of impressive stuff with the IRR, but I guess that all went into the bit bucket when UUnet took over. Very, very sad! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: NIST IPv6 document
. IPv8 has also been assigned. (Don't ask as it involved he who must not be named.) I am amazed at the number of folks who seem to think that there is time to change IPv6 is ANY significant way. Indeed, the ship has failed. If you r network is not well along in getting ready for IPv6, you are probably well on you way to being out of business. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: FAA - ASDI servers
Date: Tue, 4 Jan 2011 22:49:34 -0500 From: Christopher Morrow morrowc.li...@gmail.com On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Very true but why the reference to vacuum tubes? sadly it was an FAA computer system joke. But, since the F stands for Federal, if it is still up in two years, it must be reachable by IPv6. Today, the odds are pretty slim as almost no federal systems are reachable by IPv6. It will be an interesting two years for a lot of federal IT folks as the mandate is from the OMB who can pull a budget for non-compliance. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
NIST IPv6 document
NIST has released SP800-119, Guidelines for the Secure Deployment of IPv6. While I don't agree with everything in it, it is an excellent overview of IPv6, differences from IPv4, and security advice. While the title sounds like a security document, the security implications are only a part of it. I've not finished reading it, but my first reaction is that this is a good source of information. Well written, fairly detailed (at 188 pages) with lots of references. The PDF is available at: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: The tale of a single MAC
Date: Mon, 3 Jan 2011 08:45:54 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Hi, On Sun, 2 Jan 2011 08:50:42 -0500 Steven Bellovin s...@cs.columbia.edu wrote: On Jan 1, 2011, at 11:33 24PM, Mark Smith wrote: On Sat, 01 Jan 2011 20:59:16 -0700 Brielle Bruns br...@2mbit.com wrote: On 1/1/11 8:33 PM, Graham Wooden wrote: snip Excellent example is, IIRC, the older sparc stuff, where the ethernet cards didn't have MAC addresses as part of the card, but were stored in non-volatile or battery backed memory. This was actually the intended way to use MAC addresses, to used as host addresses rather than as individual interface addresses, according to the following paper - 48-bit Absolute Internet and Ethernet Host Numbers Yogan K. Dalal and Robert S. Printis, July 1981 http://ethernethistory.typepad.com/papers/HostNumbers.pdf Yup. That paper also discusses why 48 bits were chosen as the size, despite Ethernet systems being limited to 1024 hosts. I think things evolved into MAC per NIC because when add-in NICs were invented there wasn't any appropriate non-volatile storage on the host to store the address. On really old Sun gear, the MAC address was stored on a separate ROM chip; if the motherboard was replaced, you'd just move the ROM chip to the new board. I'm not sure what you mean, though, when you say when add-in NICs were invented -- the Ethernet cards I used in 1982 plugged into Unibus slots on our VAXen, so that goes back quite a ways... More that as add-in cards supplied their own storage for the MAC address, rather than expecting it from the host (e.g. something like MAC addresses set by init scripts at boot or the ROM chip you mentioned on Suns), this has now evolved into an expected model of a MAC address tightly bound to an Ethernet interface and supplied by the Ethernet interface e.g. by an add-in board if one is added. Now that this model as been around for a long time, people find it a bit strange when MAC addresses aren't as tightly bound to a NIC/Ethernet interface. This is all speculation on my part though, I'd be curious if the reasons are different. When I first read that paper, it was really quite surprising that MAC addresses were designed to be more general host addresses/identifiers that were also to be used as Ethernet addresses. One example they talk about is using them as unique host identifiers when sharing files via floppy disk. My Ethernet experience goes back before VAXen and the DEUNA to the original DIX Ethernet 3Com and InterLAN cards. They had the MAC in a ROM on the card set. (Yes, they were 2 card sets with a top of the card ribbon cable between them.) Don't confuse this with the REALLY old Ethernet V1 3Com and Wang 1 and 10 Mbps Ethernet, which I did not personally deal with. I worked with early Ethernet on quite a few systems and the only one I ever ran into that implemented the single per-system hardware MAC was Sun, though others (notably Digital, SGI and Xerox) would re-write all MACs with a single value derived from the network address (DECnet or XNS) at boot time. I seem to remember that Tektronix systems also did this before they bought the rights to the CMU TCP-IP stack and moved to IP. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: .gov DNSSEC operational message
Date: Tue, 28 Dec 2010 21:17:57 -0500 (EST) From: Jay Ashworth j...@baylink.com - Original Message - From: Florian Weimer f...@deneb.enyo.de That sounds like a policy decision... and I'm not sure I think it sounds like a *good* policy decision, but since no reasons were provided, it's difficult to tell. I don't know if it influenced the policy decision, but as it is currently specified, the protocol ensures that configuring an additional trust anchor never decreases availability when you've also got the root trust anchor configured, it can only increase it. This means that there is little reason to configure such a trust anchor, especially in the present scenario. Not being a DNSSEC maven, the idea that there was no out-of-band way to confirm what the in-band method was telling you seemed bad to me; Matt's explanation, OTOH, seems sensible. There is no reason that you could not do OOB transfers of keys, but it would be so cumbersome with the need to maintain keys for every TLD (and, for that matter, every zone under them) and deal with key rolls at random intervals and confirm that the new keys you were getting were, in fact legitimate would be more than overwhelming. It just does not scale. DNSSEC(bis) was designed to deal with this by being able to cryptographically confirm that all data is valid and all keys are legitimate as long as you have the root key. I am not about to go into how all of this is accomplished, but it does. Some parts of it are still a bit fragile, but the basic DNSSEC spec is now very solid and the implementations of it are getting to pretty good. (Can hardly wait for BIND 10!) I think the DNSSEC spec is a very good basket and I hope that the current implementations are, as well. At least I am very confident that they will fail-safe. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: .gov DNSSEC operational message
Date: Tue, 28 Dec 2010 22:34:20 -0500 (EST) From: Jay Ashworth j...@baylink.com Original Message - From: Kevin Oberman ober...@es.net There is no reason that you could not do OOB transfers of keys, but it would be so cumbersome with the need to maintain keys for every TLD (and, for that matter, every zone under them) and deal with key rolls at random intervals and confirm that the new keys you were getting were, in fact legitimate would be more than overwhelming. It just does not scale. I apologize; I was not clear. I was not suggesting OOB *production transfer of keying information*. I was rather suggesting that an additional publication of the keys, in an authenticatable manner, which could be used by anyone who believed that Something Hincky might be going on to confirm or deny, might be useful. Ahh. I did miss your point and I suspect others (other than Bill) might have, as well. Yes, having a verifiable source of keys OOB might have a small bit of value, but, assuming we get general adoption of RFC 5011, I think it's pretty limited value. Of course, this begs the question, how do we do a better job of verifying the keys received out of band than the root zone does of verifying the keys? Sort of a chicken and egg problem. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Alacarte Cable and Geeks
From: Robert E. Seastrom r...@seastrom.com Date: Sat, 18 Dec 2010 06:51:17 -0500 Jon Lewis jle...@lewis.org writes: This Can't End Well. Why not? As people shift from watching broadcast channels to streaming content and look to shut off their cable TV service, but keep internet, the cable co's are just going to have to raise internet prices to compensate. I can see a future where you buy internet from the cable co and they give you the basic cable TV channel lineup at no charge but in reality, you're paying for the cable internet what you used to pay for both cable internet and TV. Here in NoVA (Comcast former Adelpha territory), the future is now. I used to have internet-only service (there is little on TV that I care about). A bit over a year and a half ago, we added basic cable to the service. Total additional cost per month to go from Internet-only to Internet-plus-TV-bundle (same speed) was about $4. Hmmm. Better than the situation in my Comcast area. Internet w/o any cable costs MORE than basic cable (i.e. over the air + PEG). I'm sure that this pricing is to discourage customers from switching to a satellite provider for TV since I'm going to get most of it, anyway, and its not THAT much more to go to the standard package with the popular cable channels. Of course, you may want digital, HD, ... and discover the cable bill hits $200/mo. (Mine doesn't, but I have friends paying that.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: [Nanog-futures] an alternate proposal for NewNOG ’s membership structure
Steve, At last! Something that does not strike me as defective by design! Thank you. Based on the last financials I saw, I'd really like to see the discount on meetings be something more than $25. That mean $0 for those of us who register early. I would really hope that we can do better. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From: Steve Feldman feld...@twincreeks.net Date: Thu, 16 Dec 2010 17:31:18 -0800 In order to jump-start the process of defining a membership structure for NewNOG, I wrote an alternative proposal. My goals were to keep it as simple and short as possible, and address the concerns which came up during the election and afterwards. There are two parts, a Bylaws amendment to set the framework, and a policy document to set the specific rules. The policy document would be adopted by board resolution. Both are appended below. Please read the proposal (it's short!) and comment. Thanks, Steve == Bylaws amendment - Replace the current section 5 in its entirety with: 5. Membership 5.1 Membership Qualifications Membership in NewNOG is open to any individual with an interest in Internet operations, engineering, or research and who wishes to further education and knowledge sharing within the Internet operations community. Any individual may become a member of NewNOG by completing an application and payment of dues. 5.2 Membership Classes There shall be only one class of membership, with all the rights and privileges specified in these Bylaws. 5.3 Membership Dues The Board of Directors shall specify the cost of annual membership dues. The Board may establish discounts for members meeting certain criteria, or for members wishing to pay for more than one year in advance. 5.4 Rights and Benefits of Members Members in good standing shall be entitled to these privileges: * Vote in all NewNOG elections. * Run as a candidate for the Board of Directors * Serve on an administrative committee, as defined in section 9 * Other privileges as specified by the Board of Directors 5.5 Policies and Procedures The Board of Directors shall establish and publish policies and procedures for implementation of the membership program. == Membership Policies and Procedures, to be adopted by Board resolution: 1. Annual Dues 1.1 Standard rate The standard annual dues is $100. 1.2 Student discount Students enrolled in an undergraduate or graduate degree program at an accredited institution will receive a 50% discount for annual dues. Proof of enrollment is required. This may not be combined with any other discount. 1.3 Multi-year discount Individuals who prepay three or more years of membership in advance will receive a 10% discount. This may not be combined with any other discount. 2. Membership Terms 2.1 Start of membership The term of membership shall begin immediately upon receipt of the member's application and payment for dues. 2.2 Expiration of membership 2.2.1 New memberships For new members, the term of membership shall expire one year after the last day of the month during which the membership started, unless membership is renewed. 2.2.2 Continuing memberships For continuing members, the term of membership shall expire one year after the previous expiration date, unless membership is renewed. 2.3 Renewal A member may renew by submitting payment of the current dues amount before the expiration of the current membership term. Members who have prepaid for more than one year in advance shall be automatically renewed for the additional years prepaid. 3. Additional Benefits 3.1 Meeting discount Members in good standing will receive a $25 discount for registration for any conference operated by NewNOG. This may not be combined with any other discounts, including any discounts for students or early registration. == ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Over a decade of DDOS--any progress yet?
Date: Mon, 13 Dec 2010 10:09:16 -0500 From: Christopher Morrow morrowc.li...@gmail.com On Mon, Dec 13, 2010 at 8:49 AM, Drew Weaver drew.wea...@thenap.com wrote: verizon's ddos service was/is 3250/month flat... not extra if there was some sort of incident, and completely self-service for the customer(s). Is 3250/month a reasonable insurance against loss? (40k/yr or there abouts) -chris That doesn't sound too unreasonable as long as you are in a market Verizon services and you can find the right Verizon rep who isn't trying to sell transit at $25/mbps. if you find that guy, maybe they'll also be the mythical unicorn of a sales person who will sell you ipv6 transit too? Unless VZB has started accepting prefixes longer than /32, they really don't have real IPv6 transit to sell. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Start accepting longer prefixes as IPv4 depletes?
Date: Wed, 08 Dec 2010 15:34:47 -0600 From: Jack Bates jba...@brightok.net On 12/8/2010 3:12 PM, David Conrad wrote: Cameron, On Dec 8, 2010, at 12:01 PM, Cameron Byrne wrote: I believe a lot of folks think the routing paths should be tightly coupled with the physical topology. The downside, of course, being that if you change your location within the physical topology, you have to renumber. Enterprises have already voted with their feet that this isn't acceptable with IPv4 and they'll no doubt do the same with IPv6. In a mature IPv6 world, that is sane, i am not sure what the real value of LISP is. Sanity is in the eye of the beholder. The advantage a LISP(-like) scheme provides is a way of separating location from identity, allowing for arbitrary topology change (and complexity in the form of multi-homing) without affecting the identities of the systems on the network. Changing providers or multi-homing would thus not result in a renumbering event or pushing yet another prefix into the DFZ. I think the issue, and correct me if I'm wrong, is that LISP does not address issues of traffic engineering? A lot of the additional routes in DFZ are there specifically to handle traffic engineering. Yes. Locator-ID separation means that you would no longer have to add prefixes to the DFZ for traffic engineering. That would be in the province of the locator part of the operation. I see nothing preventing this from being done in LISP and being done in a much more manageable manner. This does, of course, increase the number of locators in the FIB, but the number of locators would be tiny compared to the current FIB, so I don't see an issue. The flow of traffic is usually based on ASN from a human standpoint, but dividing networks up and changing priorities on a per network basis is the mechanism BGP allows for determining that flow of traffic. Another large increase in DFZ was due to constraints. Even with engineering, I might divide a /16 into 4 /18 networks and be able to obtain the metrics I need. ARIN, over the years gave me a lot of /20 networks. It has been hopeful (and policy is still evolving with ARIN to accomplish this for our region) that IPv6 would not suffer from having to receive multiple small allocations which do not align with our traffic engineering needs but just add additional routes. So use locator to do the job right instead of twisting things with machinations in routing that the protocols were not designed for. I am simply amazed that, in this day and age, people still seem to not understand the value of locator-ID separation! Almost all early network protocols other than IP did this. IP, for good reason, became dominant and, in the process, the concept was largely forgotten. There was a contingent of folks who tried to get it into IPv6 as a base part of the standard, but they lost. (Yes, I understand the prevailing arguments, but it was till a HUGE mistake, IMHO.) It certainly would have been much better if locator-ID separation was built into the protocol (IPv6) rather than being shoe-horned in after the fact, but I really think we still need it. Note, LISP has some real corner case issues and may not be implementable on a general basis. I want locator-ID separation, but that does not necessarily mean LISP. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Want to move to all 208V for server racks
Date: Sat, 4 Dec 2010 23:26:46 +0100 (CET) From: Ingo Flaschberger i...@xip.at There's also a telco oriented 48V inverter rack system thats escaping my mind at the moment. It can be setup with A/B 48V strings, and you plug in inverter modules up to IIRC around 8kW. Not parallel capable between racks AFAIK. 48V (and some more when batteries are full) are slightly below the limit of non harmfull voltage. Thus you have a voltage with less power loss at short transports and a secure voltage. (creating a short is still not a great idea). Saying that 48V is not a harmful voltage is a very dangerous statement. It is unlikely to be a threat of electrocution (though even that has exceptions), but people have lost fingers to 12V systems. Lead-acid batteries can deliver way over 100 amps of current and a conductor across safe voltage will get hot and, if not heavy enough, will vaporize. The temperatures attained can cause major burns and, should the metal vaporize, can damage tissue so severely that fingers have been lost when the blood vessels were cauterized. While safety rules often list voltages under 50 as being safe, it is still important to exercise caution like removing rings, bracelets and the like. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: ARIN space not accepted
From: valdis.kletni...@vt.edu From: valdis.kletni...@vt.edu Date: Fri, 03 Dec 2010 20:00:15 -0500 On Fri, 03 Dec 2010 14:24:16 PST, Leo Bicknell said: It is speculated that no later than Q1, two more /8's will be allocated, triggering a policy that will give the remaining 5 /8's out to the RIR's. That means, prior to end of Q1, the bogon list will be: 0/8 10/8 127/8 172.16/12 192.168/16 224/3 Oh. And don't forget to do *bidirectional* filtering of these addresses. ;) Ahh, not quite. Blocking 224/3 bi-directionally might cause a few issues if you accept multicast traffic from anyone. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: TWT - Comcast congestion
Date: Tue, 30 Nov 2010 00:29:31 -0500 (EST) From: Jon Lewis jle...@lewis.org Anyone else seeing this or know the cause? 5: ash1-pr2-xe-2-3-0-0.us.twtelecom.net (66.192.244.214) 29.758ms 6: pos-3-11-0-0-cr01.ashburn.va.ibone.comcast.net (68.86.86.145) asymm 11 846.582ms 7: pos-1-7-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.87.86) asymm 8 866.718ms 8: pos-1-11-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.85.221) asymm 10 879.171ms 9: pos-0-11-0-0-cr01.losangeles.ca.ibone.comcast.net (68.86.87.37) asymm 11 925.695ms 10: pos-0-12-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.86.5) asymm 14 919.159ms We opened a ticket with TWT and were told we weren't the first to report the issue, but there was no ETR. I adjusted our routing to depreference TWT for reaching AS7922...which is kind of funny because Comcast clearly doesn't seem to want traffic via the route we're now sending it. 3356 7922 7922 7922 Don't want traffic via Level3...but can't take it via TWT?..I'll send it to you over Level3. At least that path works. We have seen the same thing with other carriers. As far as I can see, Comcast is congested, at least at Equinix in San Jose. Since this is all over private connections (at least in our case), the fabric is not an issue. Maybe they will be using the money from Level(3) to increase capacity on the peerings with the transit providers. (Or maybe not.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: reporting physical plant damage to ATT?
From: Paul Vixie vi...@isc.org Date: Thu, 25 Nov 2010 21:14:45 + there's a pacific telephone j-box at the edge of a parking lot in san mateo california that's been hit by a car hard enough to spring the door open. the copper punchdowns are now freely and publically accessible. i think it's not pac tel or pac bell or sbc any more, so what i need is to know how to tell ATT that they've got a physical plant problem that will soon be customer affecting, especially with the weather like it is. there was a call-before- you-dig sticker on it so i called that number and they said it wasn't their problem. i'm trying to do the right thing by asking ATT to make it so if i google for report damage to att it will give a useful result. meanwhile if someone from att asks me i will tell them the road address of the box. (i am not an att customer and calling 1-800-CALL-ATT did me no good at all.) Have you tried 611 (from an ATT land-line phone)? The menus are horrid, but you should finally get to a human. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Jumbo frame Question
From: Harris Hui harris@hk1.ibm.com Date: Fri, 26 Nov 2010 08:13:57 +0800 Hi Does anyone have experience on design / implementing the Jumbo frame enabled network? I am working on a project to better utilize a fiber link across east coast and west coast with the Juniper devices. Based on the default TCP windows in Linux / Windows and the latency between east coast and west coast (~80ms) and the default MTU size 1500, the maximum throughput of a single TCP session is around ~3Mbps but it is too slow for us to backing-up the huge amount of data across 2 sites. The following is the topology that we are using right now. Host A NIC (MTU 9000) --- GigLAN --- (MTU 9216) Juniper EX4200 (MTU 9216) ---GigLAN --- (MTU 9018) J-6350 cluster A (MTU 9018) --- fiber link across site --- (MTU 9018) J-6350 cluster B (MTU 9018) --- GigLAN --- (MTU 9216) Juniper EX4200 (MTU 9216) ---GigLAN --- (MTU 9000) NIC - Host B I was trying to test the connectivity from Host A to the J-6350 cluster A by using ICMP-Ping with size 8000 and DF bit set but it was failed to ping. Does anyone have experience on it? please advise. Thanks :-) MTU is only one issue. System tuning and a clean path are also critical. Getting good data streams between two systems that far apart is not easy, but with reasonable effort you can get 300 to 400 Mbps. If an 8000 byte ping fails, that says that SOMETHING is not jumbo enabled, but it's hard to tell what. This assumes that no firewall or other device is blocking ICMP, but I assume that 1400 byte pings work. Try hop-by-hop tests. I should also mention that some DWDM gear needs to be configured to handle jumbos. We've been bitten by that. You tend to assume that layer 1 gear won't care about layer 2 issues, but the input is an Ethernet interface. Finally, host tuning is critical. You talk about default window size, but modern stack auto-tune window size. For lots of information on tuning and congestion management, see http://fasterdata.es.net. We move terabytes of data between CERN and the US and have to make sure that the 10GE links run at close to capacity and streams of more than a Gbps will work. (It's not easy.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch)
Date: Sun, 31 Oct 2010 03:28:25 +0900 From: Randy Bush ra...@psg.com plonk ... goes your custom Marketing by annoyance, smoke, and mirrors? Gotta love the strategy do not buy from spammers I might also mention that I received private SPAM from a name we all know and loath. (Hint: He's been banned from NANOG for VERY good reason and his name is of French derivation.) I just added a filter to block any mail mentioning pica8 and will see no more of this thread or their spam. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Interesting IPv6 viral video
Date: Thu, 28 Oct 2010 13:08:02 -0700 From: Zaid Ali z...@zaidali.com Not quite accurate and a bit too dramatic on the panic side but the approach is interesting to put C-Level folks in the hot seat about v6. Would be interesting also to see if folks here get asked by C-Level folks bout IPv6. http://www.youtube.com/watch?v=eYffYT2y-Iw Cute. Silly, but cute. I think I see Tony Hain's hand somewhere in this. Tony??? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Choice of network space when numbering interfaces with IPv6
From: Warren Kumari war...@kumari.net Date: Sun, 17 Oct 2010 22:07:53 -0400 On Oct 16, 2010, at 10:55 PM, Kevin Oberman wrote: Date: Sun, 17 Oct 2010 01:56:28 +0100 From: Randy Bush ra...@psg.com http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they? must be some blowhard i have plonked Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as Standards. I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) juniper and cisco implement today Unfortunately, a couple of other router vendors whose top of the line units I have tested recently did not. Simple Matter of Programming ;-) Please suggest to said vendors that they implement this -- IMO it's the right way to do it... Rest assured that I did so during the debrief on our evaluation. I know one promised a fix quickly. I don't recall on the other as that problem was not very significant compared to other issues with that unit. These evals are so much fun. I had to listen to a sales type explain that mBGP was incomplete for MY benefit. It might confuse me to be able to run multiple address families over a single peering session. I am so touched for this sort of concern. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Choice of network space when numbering interfaces with IPv6
Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush ra...@psg.com wrote: http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they? Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as Standards. I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits. Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Choice of network space when numbering interfaces with IPv6
Date: Sun, 17 Oct 2010 01:56:28 +0100 From: Randy Bush ra...@psg.com http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they? must be some blowhard i have plonked Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as Standards. I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) juniper and cisco implement today Unfortunately, a couple of other router vendors whose top of the line units I have tested recently did not. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Choice of network space when numbering interfaces with IPv6
Date: Sun, 17 Oct 2010 10:24:41 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org On Sat, 16 Oct 2010 15:26:54 -0700 Kevin Oberman ober...@es.net wrote: Date: Sun, 17 Oct 2010 00:40:41 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush ra...@psg.com wrote: http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt Drafts are drafts, and nothing more, aren't they? Drafts are drafts. Even most RFCs are RFCs and nothing more. No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process. Only a handful have ever been designated as Standards. I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits. I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it. Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem. As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs. http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html I don't entirely agree with your arguments, but the approach looks, at first glance, to be quite interesting and could quite possibly fix the problem. I'll need to digest it a bit better. Have you or someone else authored a draft on this proposal? In the meantime, I still support /127s for P2P links. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Choice of network space when numbering interfaces with IPv6
Date: Sat, 16 Oct 2010 08:51:03 +1030 From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Hi, On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali z...@zaidali.com wrote: SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64. If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time. If you listen to the NANOG debate on IPv6 on P2P links, you will discover that the participants (Igor of Yahoo and Rob Seastrom of Affilias) agreed that the proper way to do this was to allocate a /64 for the link but to configure it as a /127. This was to avoid ping-pong DOS attacks. I believe that the session has already been cited, but see Igor's presentation at: http://nanog.org/meetings/nanog48/presentations/Tuesday/Gashinsky_LinkNumb_N48.pdf -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE
Pardon me, but did I miss the announcement of Whine on NANOG day? Between this thread and Network Operators Unite Against SORBS, I assume that I must have missed the announcement while I was in the road last week. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: [Nanog-futures] Stenographers for Future NANOGs?
Date: Wed, 06 Oct 2010 10:42:16 -0400 From: Randy Whitney randy.whit...@verizonbusiness.com As I am reading through Matt's notes since I cannot attend NANOG in person this time, I'm pondering whether it may make sense in the future for NewNOG to set aside budget to employ stenographers to cover at least the plenary of the conference. Matt has done an admirable job over the past few years volunteering to do this, but perhaps there might be some way to lift this burden from him? While I really appreciate Matt's efforts in posting the notes, the cost of stenographers seems hard to justify. After all, the slides and the A/V streams of all General Session presentations is archived and available at any time. I really hope Matt will continue his efforts or that someone else would volunteer to take over should Matt decide to stop, but unless the cost of stenographers is far lower than I expect, I'd have a hard time justifying the cost. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Stenographers for Future NANOGs?
On Oct 6, 2010, at 15:25, Sean Figgins s...@labrats.us wrote: On 10/6/10 8:42 AM, Randy Whitney wrote: As I am reading through Matt's notes since I cannot attend NANOG in person this time, I'm pondering whether it may make sense in the future for NewNOG to set aside budget to employ stenographers to cover at least the plenary of the conference. Matt has done an admirable job over the past few years volunteering to do this, but perhaps there might be some way to lift this burden from him? I would think that we probably need a very good and accurate transcript of any NewNOG community meetings. Even if we did not do this for the NANOG conference, it may be worth the cost for a couple hours. -Sean ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures I guess I miss the point. When I can go to nanog.org/meetings/nanog49/agenda.php and watch and listen to the full meeting, why would I need a transcopt? Sent from my iPod ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Stenographers for Future NANOGs?
From: Bill Woodcock wo...@pch.net Date: Wed, 6 Oct 2010 14:10:59 -0700 I guess I miss the point. When I can go to nanog.org/meetings/nanog49/agenda.php and watch and listen to the full meeting, why would I need a transcopt? If you didn't watch it live, then it's a quick way to scan through to see if you missed anything interesting (sometimes slides != what's discussed). Also, transcripts are search-engine indexible. This is the first GOOD reason for a transcript! Thanks, Bill. I still suspect it would be cheaper to have a transcript generated from the recording after the meeting than to have a stenographer at the meeting, but I do see this as a significant benefit to a written transcript. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Stenographers for Future NANOGs?
Date: Wed, 06 Oct 2010 15:35:29 -0600 From: Sean Figgins s...@labrats.us On 10/6/10 2:50 PM, Kevin Oberman wrote: I guess I miss the point. When I can go to nanog.org/meetings/nanog49/agenda.php and watch and listen to the full meeting, why would I need a transcopt? Not everyone can make the community meeting. The community meeting is not always broadcast. Not everyone will be able to understand who is asking what question. For the general conference, I agree that it does not always need to have transcripts. But as the community meeting is likely the place where corporate business is being discussed, this needs to be reviewable at a later date I do not know it this is a legal requirement at all, but I know that most incorporated organizations I have participated in have pretty decent transcripts or minutes from their business meetings. I don't quite understand this. The community meeting has been recorded for the past 3 years (9 meetings). I would think that the recording would both meet legal requirements and allow a transcript to be made later. At most, we might need a recording secretary to take notes, but this does not require a stenographer. Matt does an excellent job of it now and getting someone to take notes for pay would still be far less expensive that hiring a stenographer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: [Nanog-futures] Memberships, Bylaws and other election matters
Yes, I think 'yes' is the right vote. I do have one major concern, but I will vote 'yes' on both issues, regardless. I really worry about the voter base becoming disjoint from the attendee base. I think meeting attendees should get a vote as a part of attendance. How this is handled is not clear, but I would like to see paying attendees all get to vote for any year in which they attend a meeting. Whether or not non-paying attendees should get a vote is something I'm less site of. Good speakers are rather important and allowing them a vote for their efforts seems reasonably appropriate. Whatever the details, I strongly feel that the concept that meeting attendees must continue to be, as the old T-shirts said, Official Members. Sent from my iPod On Oct 5, 2010, at 7:34, Sylvie LaPerriere laperriere.syl...@gmail.com wrote: I am joining my voice to Steve's. I view this discussion on membership as very healthy and it should continue until the community reaches a strong consensus. I think voting 'yes' is the way forward and I also pledge to do what I can with my Board vote to keep from creating any categories of members that can't easily be undone until consensus from the community is reached. Sylvie 2010/10/4 Joel Jaeggli joe...@bogus.com On 10/4/10 12:13 PM, Steve Feldman wrote: On Oct 4, 2010, at 11:54 AM, Ren Provo wrote: Hi Steve, I appreciate your input here. It was clearly stated yesterday that several folks do not want a fellows membership class but I do not recall the reasoning other than Joel's comment that fee structure should cover all. Can you clarify why you would elect not to recognize significant contributions made from an individual? Thanks! -ren I personally have nothing against the concept. But some others do, and I don't want to make any choices that would be difficult or awkward to unmake until we end up with consensus either way. Recognition is a valuable socially sustaining community activity. I don't believe that it has any business being tied to membership. Assuming that the bylaws are accepted, certainly some of those deserving of community recognition will not be members, I don't see that as a problem. [Or, what Mike said!] Steve ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Troubleshooting TCP performance tutorial
Date: Fri, 17 Sep 2010 20:06:09 -0400 From: Abel Alejandro aalejan...@worldnetpr.com Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel. You might look at http://fasterdata.es.net. A lot of it is aimed at very large volume data transfers, but quite a bit is relevant to all TCP issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: ISP port blocking practice
From: Dobbins, Roland rdobb...@arbor.net Date: Fri, 3 Sep 2010 21:07:49 + On Sep 3, 2010, at 8:02 PM, Patrick W. Gilmore wrote: Could you point to more than one instance? I've not yet found one. I've yet to run across this, either, FWIW, except on extremely restrictive special-purpose endpoint networks. Doesn't mean that it doesn't happen, but it doesn't seem to be nearly as prevalent as TCP/25 blockage on general SP access networks. Worst case I have seen was the visitors network at EBC at one of the nation's largest telephone and Internet transit providers. They seemed to block ALL outgoing ports except 80, 443, and 22. No VPN. No submission port. No IMAP. (Didn't try POP3.) I tunneled mail over ssh, but I can imagine that a lot of corporate types who meet there are rather annoyed that they can't access mail. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Did your BGP crash today?
Date: Mon, 30 Aug 2010 10:55:03 -0500 From: Jack Bates jba...@brightok.net Florian Weimer wrote: This whole thread is quite schizophrenic because the consensus appears to be that (a) a *researcher is not to blame* for sending out a BGP message which eventually leads to session resets, and (b) an *implementor is to blame* for sending out a BGP messages which eventually leads to session resets. You really can't have it both ways. As good a place to break in on the thread as any, I guess. Randy and others believe more testing should have been done. I'm not completely sure they didn't test against XR. They very likely could have tested in a 1 on 1 connection and everything looked fine. I don't know the full details, but at what point did the corruption appear, and was it visible? We know that it was corrupt on the output which caused peer resets, but was it necessarily visible in the router itself? Do we require a researcher to setup a chain of every vender BGP speaker in every possible configuration and order to verify a bug doesn't cause things to break? In this case, one very likely would need an XR receiving and transmitting updates to detect the failure, so no less than 3 routers with the XR in the middle. What about individual configurations? Perhaps the update is received and altered by one vendor due to specific configurations, sent to the next vendor, accepted and altered (due to the first alteration, where as it wouldn't be altered if the original update had been received) which causes the next vendor to reset. Then we add to this that it may pass silently through several middle vendor routers without problems and we realize the scope of such problems and why connecting to the Internet is so unpredictable. This only way they could have caught this one was to have tested to a CRS which had another router to which it was announcing the attribute in a mal-formed packet. Worse, the resets should just keep happening as the CRS would still have the route with the unknown attribute which would just generate another malformed update to cause the session to reset again. While it may be possible to recover from something like this, it sure would not be easy. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: PacketShader
Date: Mon, 23 Aug 2010 06:27:00 -0700 From: Jim Shankland na...@shankland.org Mark Smith wrote: On Mon, 23 Aug 2010 05:59:43 -0400 valdis.kletni...@vt.edu wrote: I missed that, and that answers the was it a GigaBytes verses Gigabits error question. Nothing new here by the looks of it - people in this thread were getting those sorts of speeds a year ago out of PC hardware under Linux - http://lkml.org/lkml/2009/7/15/234 I have achieved a collective throughput of 66.25 Gbit/s. We've achieved 70 Gbps aggregate unidirectional TCP performance from one P6T6 based system to another. Very nice, but doing this with 1514-byte packets is the low-hanging fruit. (9K packets? That's the fruit that falls off the tree and into your basket while you're napping :-).) The more interesting limit: how many 40-byte packets per second can you shovel into this system and still have all of them come out the other end? Seems reasonable, but in our testing of 100G Ethernet capable routers we found one that handled 8000 bytes just fine, but could only run 9000 byte packets at about 90G. Just a bit unexpected. Really, in this day and age, a chassis throughput of 100G is pretty trivial. When you start getting up to the Tbps range on a system using standard components, then I'll be really interested. We do have a network of many end systems attached with 10Gbps Ethernet cards. I'm sure that we are not unique, though probably unusual. We are achieving stable disk to disk transfer rates of well over 3G between the US and Australia. I don't think that PacketShader would handle the load too well. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Google wants your Internet to be faster
It makes the thread very hard to follow. Why not? Please don't top post! From: Justin Horstman justin.horst...@gorillanation.com Date: Tue, 10 Aug 2010 11:54:12 -0700 That link is silly, and completely opposite to what they said -Original Message- From: Harry Hoffman [mailto:hhoff...@ip-solutions.net] Sent: Tuesday, August 10, 2010 11:00 AM To: valdis.kletni...@vt.edu Cc: nanog@nanog.org Subject: Re: Google wants your Internet to be faster Heh, well is seems like one of the PIRGs is joining the fray, at least in PA: http://www.pennpirg.org/action/google?id4=es The NY Times article has little to nothing to do with reality and it was bad of PennPIRG to cite that bit of twaddle. That said, the actual, published document has some huge issues. It pays excellent lip service to net neutrality, but it has simply HUGE loopholes with lots of weasel words that could be used to get away with most anything. for example, it expressly excludes and wireless network. It is being widely interpreted as being anti-network neutrality. Whether Google intended this is unclear. I suspect Verizon wanted exactly what it got. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Google wants your Internet to be faster
From: Joseph Jackson jjack...@aninetworks.net Date: Tue, 10 Aug 2010 14:42:43 -0700 -Original Message- From: Jeroen van Aart [mailto:jer...@mompl.net] Sent: Tuesday, August 10, 2010 3:33 PM To: NANOG list Subject: Re: Google wants your Internet to be faster Kevin Oberman wrote: That said, the actual, published document has some huge issues. It pays excellent lip service to net neutrality, but it has simply HUGE loopholes with lots of weasel words that could be used to get away with most anything. for example, it expressly excludes and wireless network. Not having read any of the articles and not having researched the matter of network neutrality much at all. But wouldn't using either a VPN service or setting up VPN on one or more virtual servers at strategic locations of your choice avoid this? Unless they try to bandwidth limit your VPN tunnel(s) indiscriminately. Or did I miss something blatantly obvious? At least VPN does a great job of routing around GeoIP blocking... The way I understand it is if you aren't paying for preferred service then your VPN traffic would be at the bottom of the stack on forwarding. So while it gets around GeoIP stuff vpns would be subject to the same quality of service settings as any other traffic that isn't paying for a faster service. Joseph VPNs are very handy for this, but it is worth remembering that it is not free. All of the traffic has to traverse the network to the VPN box and then to the client. This can hit congestion issues, but always increases RTT and that can be a real pain. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Google wants your Internet to be faster
Top posting reformatted. Kevin Oberman wrote: That said, the actual, published document has some huge issues. It pays excellent lip service to net neutrality, but it has simply HUGE loopholes with lots of weasel words that could be used to get away with most anything. for example, it expressly excludes and wireless network. From: Joly MacFie j...@punkcast.com Date: Tue, 10 Aug 2010 17:53:07 -0400 Isn't the essence of consensus is to find common areas of agreement while punting on the rest. There's plenty to focus on that IS in there, like transparency and FCC control? You can punt the rest, but when the wording states that a large and rapidly growing segment of the network is subject to having preferred services is a bit more that a 'punt'. Also, the wording seems to work hard at making sure that you will always be able to justify any non-neutral' things you might decide to do. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Broadband initiatives - impact to your network?
Date: Mon, 28 Jun 2010 16:46:37 -0700 From: George Bonser gbon...@seven.com -Original Message- From: Jonathan Feldman Sent: Monday, June 28, 2010 4:14 PM To: Randy Bush Cc: nanog@nanog.org Subject: Re: Broadband initiatives - impact to your network? I've never claimed to be particularly bright, but I do like to challenge assumptions. It isn't only the amount of bandwidth available but also in many cases the protocols used to transmit the data. It takes smarter than the average bear to figure out how to get data across a fat pipe over a long distance at a high rate. TCP protocols are limited by the number of packets allowed to be in flight according to how the stack is configured. One might need to go to unorthodox or rather new methods to use all the available bandwidth. There are many cases of someone being stymied as to why they can't even get anywhere near 10 megabits of throughput on a GigE path from Los Angeles to London using FTP, for example. In many cases the responsibility of getting data from point A to point B is handled by people who don't bring their network operators into the discussion where problems like this can be pointed out to them. Often the first time the enterprise network group hears about it is when someone complains that the fast pipe to $continent is slow and therefore must be broken and that is generally followed by the demand that it be fixed immediately if that demand is not included in the first email. That is when conversations bearing sounds like mpscp and uftp begin and then someone says aw, screw it, just send them a disk. If you really want to improve on the performance of data transfers over long distances (e.g. across an ocean), take a look at http://fasterdata.es.net. The Department of Energy and ESnet provides this information primarily for researchers needing to over large volumes of data over many thousands of kilometers. While some of the information will be beyond the capabilities of the average network user and either end can cause the performance problems, the information can explain a bit about why the problems exists and does provide some simple changes that can greatly enhance transfer speed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Micro-allocation needed?
From: Joe Abley jab...@hopcount.ca Date: Mon, 21 Jun 2010 17:55:40 -0400 I'm interested in the idea of anycasting one of the pool.ntp.org herd-members. Every time I've suggested such a thing I've been told (paraphrasing) that a good (server, client) NTP session exhibits reasonable RTT stability, this constitutes, in effect, a long-lived transaction, and hence anycast is not a good answer unless you have confidence that the potential for oscillations is low, or that the frequency of the oscillations is very low (i.e. in a private network this might be a good answer, but across the public Internet it's a poor answer). Has the thinking changed, or did I just misunderstand? Joe, This would be better asked on the NTP list, but I'd say it depends on the accuracy you want to achieve. For the NTP pool, the idea is to try for good accuracy and very good long-term stability are the goals. That does not work well of the actual source of the data changes very often. Aside from losing the advantages of long-term PLL filtering of the time, you also will see substantial changes in delay (i.e. RTT) and, almost certainly, jitter. Unless you are confident that the source of the anycast at any point in the network will remain stable over a very long term, it really does not sound like a good solution to me. Then again, with GPS time source available for 75 USD, anyone who is really trying for really good time should just buy one and run a local stratum 1 server. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Advice regarding Cisco/Juniper/HP
From: William Pitcock neno...@systeminplace.net Date: Thu, 17 Jun 2010 13:35:30 -0500 On Thu, 2010-06-17 at 11:07 -0700, Seth Mattinen wrote: On 6/17/2010 11:01, Sandone, Nick wrote: I would also add Brocade/Foundry to the mix as well. We've been deploying these switches with great results. Since the IOS is very similar to Cisco's, the transition has been quite easy. Do you still have to pay them to read the manual? We have plenty of Foundry gear and we've never had to pay anything to read the manuals for them. Then again, we bought it all new, so it came with printed manuals. There's a 1000+ page manual on the management software itself. The Brocade manuals are good, but you need to have a customer account to access them. Very annoying when you are trying to do an evaluation. I have spoken with one of their engineers about that and he said that they (the engineers and sale folks) are trying to get that changed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Junos Asymmetric Routing
Date: Sun, 30 May 2010 18:39:39 +0200 From: Randy Bush ra...@psg.com your perfectly fine multihop BGP session could break when rerouting occurs. one of the many reasons that there are no perfectly fine multi-hop bgp sessions. I remember a posting to this list back in the late 90s from Tony Li, who knows a bit about BGP. He urged that multi-hop BGP never be used and pointed out that it had not been intended for use except as a test tool, not a production one and should have been stripped from IOS before it was shipped. While there are a few good cases for using it, it is generally a bad, bad idea. And this thread demonstrates that he had reason for the warning -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Quick IP6/BGP question
Date: Mon, 24 May 2010 11:21:45 -0700 From: Thomas Magill tmag...@providecommerce.com From the provider side, are most of you who are implementing IP6 peerings running BGP over IP4 and just using IP6 address families to exchange routes or doing IP6 peering? Can't speak for most of us, but we run an iBGP v4 mesh carrying both v4 and v6 routes. For external peers, we run separate peerings. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: what about 48 bits?
Date: Sun, 04 Apr 2010 23:30:42 -0500 From: Larry Sheldon larryshel...@cox.net I keep seeing mention here of the permanent MAC address. Really? Permanent? Been a long time, but it seems like one of the fun things about having DECNet-phase IV on the network was its propensity for changing the MAC address to be the DECNet address. And it seems like the HP-UX machines (among others) could write what every they wanted to as addresses. Almost every system can re-write the MAC address. It's in the original 802.3 and DIX (Blue Book) Ethernet standards. I have not run into a system in some time that lacked this capability. Works on Windows, MacOS, Linux, and BSD. That said, all 802.3 devices are expected to have a permanent MAC address in ROM. At initialization time, that address is always used until software can program in the new address. Made MOP-DL booting (DECnet equivalent of bootp) interesting. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: IPv4 ANYCAST setup
From: Joe Abley jab...@hopcount.ca Date: Fri, 26 Mar 2010 10:06:02 -0700 On 2010-03-26, at 06:40, Max Larson Henry wrote: has someone experience in anycast ipv4 networks (to support DNS)? Never been done Dangerous TCP does not work etc etc etc. - Yes but as for DNS, anycast is essentially used for user requests (UDP) not to perform zone transfer(TCP). As others have mentioned, TCP can generally be used for any DNS query, not just AXFR. This becomes more important as DNS responses get bigger, e.g. responses from root servers due to the root zone containing DNSSEC information, see http://www.root-dnssec.org/. If your nameserver can't be reached over TCP, it's likely that there are people who can't talk to your nameserver. This means your DNS records can't be found. This is a bad thing. Here, in glorious LOLCAPS: ALWAYS MAKE SURE YOUR DNS SERVER CAN BE REACHED OVER TCP TCP IS NOT JUST FOR ZONE TRANSFERS FIX YOUR FIREWALLS :-) Fix your security officers! I have talked to multiple security officers (who are generally not really knowledgeable on networks) who had 53/tcp blocked and none have yet agreed to change it. The last one told me that blocking 53/tcp is standard industry practice as per his firewall training. Point out what RFCs said simply bounced off of him. He said that if the protocols would not handle blocked 53/tcp, the protocols would have to be changed. Opening the port was simply not open to discussion. They don't seen to really care if things are broken and seem to feel that it is up to the network to accommodate their idea of normal firewall configuration. I will say that these were at federal government facilities. I hope the commercial world is a bit more in touch with reality. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Is TDM going the way of dial-up?
Date: Fri, 26 Mar 2010 16:43:23 GMT From: msoko...@ivan.harhan.org (Michael Sokolov) Rick Ernst na...@shreddedmail.com wrote: I've noticed over the last 3 years or so that TDM, specifically T-1, access and transport has been in a steady decline. Customers are moving to FTTH and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A recent upgrade from OC-3 to GigE transport actually saved us a large chunk of money. I'm wondering if others are seeing the same behavior, if it's market-dependant, or if I'm just imagining things. Unfortunately what you are seeing is indeed where the world is going, and it is extremely painful to watch. My personal preference is the direct opposite of that: Ethernet for non-LAN use is my very antithesis, I hate it to the core of my being. V.35/HDLC forever for me! I will continue using HDLC over traditional synchronous serial WAN media for as long as I am alive. MS P.S. This message is being sent from a VAX running a variant of 4.3BSD (Quasijarus). Almost the entire ARPA Internet software stack that's running on my VAXen is mostly unchanged from how it was in 1988. Much as I love Sonet and the like, I will channel Randy and say that I hope all of my competitors do this. (OK. We really don't have competitors.) And, if you are using a 1988 TCP stack on a 4.3 system, you are not likely to ever efficiently utilize a higher speed link and will not behave well on any link. TCP has come a long way in the past 12 years. (Of course, I can't guess what mostly unchanged means.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: 10GBase-t switch
Date: Thu, 11 Mar 2010 12:51:00 -0800 From: Dave Temkin dav...@gmail.com Kevin Oberman wrote: Date: Thu, 11 Mar 2010 12:26:16 +0900 From: Randy Bush ra...@psg.com arista 7120t-4s... hot box. but you are giving away the secret sauce! Hot box for the datacenter, but small buffers make it unsuited for long distances. In the right place, this box can't be beaten in the price/performance realm. Can you point to another 1U box that has more than 16MB per-port buffer? I cannot. It's just that this is not enough buffer for longer distances with multiple well loaded ports. As I keep saying, this is the best price/performance box I have seen. I am not criticizing it, just pointing out that it may not be the solution to all purposes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: 10GBase-t switch
Date: Thu, 11 Mar 2010 12:26:16 +0900 From: Randy Bush ra...@psg.com arista 7120t-4s... hot box. but you are giving away the secret sauce! Hot box for the datacenter, but small buffers make it unsuited for long distances. In the right place, this box can't be beaten in the price/performance realm. Some of their salescritters can be annoying, too, but YMMV. We may have just hit a bad one. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: [members-discuss] Re: RIPE NCC Position On The ITU IPv6 Group (fwd)
Date: Mon, 01 Mar 2010 16:55:43 +0100 From: Adam Waite awa...@tuenti.com Hm, I was under the impression that ARPANET was a government run network... Not since 1992..what you're looking for these days is NIPRnet and SIPRnet, and ESnet, etc, etc, etc. While ESnet is funded by the Department of Energy and they certainly define the strategic policy of ESnet, they don't make design decisions nor get involved with the technical end of the network. ESnet is run by the University of California's Berkeley Lab under contract to the DOE. This may sound like hair splitting, but it is really very different from Fednets like NIPR and SIPR (and many, many others) including the Department of Energy's own DOEnet. Note that DOEnet is used for DOE business operations while ESnet is use support DOE funded research. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
From: gordon b slater gordsla...@ieee.org Date: Fri, 26 Feb 2010 16:52:21 + On Fri, 2010-02-26 at 09:40 -0600, Jorge Amodio wrote: I guess nobody needs ITU-T anymore, or do we ? ZCZC well, from vague memory, H.264, G711/729, H323, X.509 were/are ITU-T standards - maybe X.25 too though I could have that one wrong. I'll just sit on the fence: as an old radiocomms guy, I'd say ITU-_R_ is still very relevant if you guys DON'T want to watch/listen N. Korean or Bangladeshi TV/radio on your home Sat systems or car radios, to name a couple of recently quoted countries :) But ITU-T? That's one for the VoIP guys to shout about. No, it is one for everyone who does networking to shout about! ITU is exactly the sort of organization I DON'T want to see in control of the Internet. If you think IETF has gotten to unmanageable, wait until you deal with the ITU-T. It is VERY lawyer heavy. I had to attend some X.400/X.500 meetings and, while the lawyers were never running anything, most of the technical people could only speak through the lawyers and the suits out-numbered the techies by almost two to one. And this was a low-level working group. I understand it gets worse as you move up the ladder. The network revolution has left the ITU-T very little to do (at least compared to the old telco days) and they show every sign of wanting to bring all of us wild IP folks under control. Oh, and X.25 and X.509 are from an older organization that merged into the ITU-T when it was created, the CCITT (International Telegraph and Telephone Consultative Committee). It became the ITU-T in 1992. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: [Fwd: [members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]
Date: Sat, 27 Feb 2010 12:04:12 +0800 From: Phil Regnauld regna...@nsrc.org Nick Hilliard (nick) writes: And the politicians. Yes, they will erupt in hitherto unseen outbursts of self-righteous indignation at the stupid internet engineers who let this problem happen in the first place and who made no provision whatsoever for viable alternatives, Um, not to be the party pooper of your fire-and-brimstone scenario, but IPv6 deployment has taken quite a bit longer than expected. I'm not saying that political incentives (carrot stick) or government regulations in the line of implement IPv6 before X/Y or else... have had any effect, except maybe in Japan: look how long it took for the EU commission to jump on the bandwagon, for instance (or for that matter, how long it took any government to take IP seriously). But if was asked why IPv6 hasn't been deployed earlier, I'd be hard pressed to come up with a simple answer.It wasn't ready is probably not considered good enough for an elected official. rant I'm sorry, but some people are spending too much time denying history. IPv6 has been largely ready for YEARS. Less than five years ago a lot of engineers were declaring IPv6 dead and telling people that double and triple NAT was the way of the future. It's only been over the past two years that a clear majority of the networks seemed to agree that IPv6 was the way out of the mess. (I know some are still in denial.) Among the mistakes made was the abandonment of NAT-PT as a transition mechanism. The BEHAVE working group has resurrected it and I still have hope of a decent system, but it has not happened as of today and we need it yesterday. Because so many network engineers or their managers decided that IPv6 was either not going to happen or was too far down the line to worry about, vendors got a clear message that there was no need to spend development money adding IPv6 support to products or implement it for their services. I won't go into the mistakes made by the IETF because they were doing something very un-IETF under tremendous time pressure. The standards were developed on paper with almost no working code. This was because the IETF assumed that we would run out of IPv4 long ago since the basics of IPv6 pre-date CIDR. They pre-date NAT. Yes, IPv6 has been around THAT long. At leat one network was running IPv6 on its network, available to users for testing for over 15 years ago. It's been a production service for years. Let's face reality. We have met the enemy and he is us. (Apologies to Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for years after it was available. Almost all operating systems have been IPv6 capable for at least five years and most much longer. Most routers have been IPv6 ready for even longer. But we didn't move IPv6 into services nor offer it to customers. As a result, it just sat there. Code was not exercised and bugs were not found. Reasonable transition mechanisms are nowhere to be seen, and the cost of fixing this (or working around it) has grown to frightening proportions. /rant There is a lot of blame we can spread around, but take moment and look in a mirror while you parcel it out. I think we are more responsible for the situation than anyone else. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: austin eats
Date: Wed, 17 Feb 2010 11:12:46 +0900 From: Randy Bush ra...@psg.com is there a nanog austin eats page somewhere? i lost my old link to some wiki we used to use. and, a completely unverified recco from an austin friend (who thinks chicken fried steak is the meat nearest heaven). http://www.nanog.org/meetings/nanog48/restaurants.php It's mostly the obvious places. Oddly, Fogo de Chao, a churrascaria that opened a year ago is missing from the list as is my personal favorite, the Texas Chili Parlor which is right next to the state capitol at 1409 Lavaca. They have several types of chili, but the specialty is the Texas Chili with steak and no beans. Real chili. The medium will warm you well and the hot is...oh, my! (They have a release form for those who want to try it.) Of course, you are only a couple of blocks from 6th Street, home to all wonderful food and live music, mostly blues, jazz and rock. Little or no country last year when I was there. If you have a care, the legendary Salt Lick Bar-B-Que is a few miles out of town. Lots of good food, but most would not make my cardiologist happy. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Linux Router distro's with dual stack capability
Date: Thu, 11 Feb 2010 18:20:13 -0500 From: Chuck Anderson c...@wpi.edu On Thu, Feb 11, 2010 at 04:12:03PM -0600, William Pitcock wrote: On Thu, 2010-02-11 at 13:05 -0500, Jack Carrozzo wrote: Lots of people roll FreeBSD with Quagga/pf/ipfw for dual stack. See the freebsd-isp list. FreeBSD's network stack chokes up in DDoS attacks due to interrupt flooding. We used to use FreeBSD for firewalling and basic routing, but when noticing that we had horizontal scalability (e.g. a Celeron 667mhz performed nearly as well as a dual dual-core Xeon system when DDoS attacks happened), we switched to Vyatta, and generally have not looked back. Have you tried using FreeBSD's polling mode instead of interrupt mode? No experience with it myself, but it sounds cool: http://info.iet.unipi.it/~luigi/polling/ Polling is excellent for low speed lines, but for Gig and faster, most newer interfaces support interrupt coalescing. This easily resolves the issue in hardware as interrupts are only issued when needed but limited to a reasonable rate, Polling does not use interrupts, but consumes system resources regardless of traffic. FreeBSD has supported polling for a long time (V6?) and interrupt coalescing since some release of V7. (Latest release is V8.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Fiber Cut in CA?
From: Michael J McCafferty m...@m5computersecurity.com Date: Mon, 01 Feb 2010 19:29:24 -0800 Michael, We saw routes change on Level3's network about 13:40 PDT today. Routes from San Diego to Phoenix now go up to SJC, to Denver, to Dallas, to Phoenix. Some customers trying to reach us from Cox in Phoenix had some issues where Cox and Level 3 peer. Overall, *we* are not down, anywhere, but increased latency. The most recent info we have is: Notes : *** CASCADED EXTERNAL NOTES 02-Feb-2010 02:40:44 GMT spottsta From CASE: 3900562 - Event 02:05 GMT Field Services is in the process digging in the Junction box at this time. Testing will begin when fiber is accessible. 02:23 GMT Field Services has access to the fiber in the junction box and has begun testing fiber at this time. 02:33 GMT Field Services has isolated fiber cut to approximately 3,000 feet out from their current location at a construction site. They are attempting to gain access to the site at this time. Field Technicians are currently walking the route trying to determine a restoration plan. Case Status: Analysis in Progress On Mon, 2010-02-01 at 21:17 -0600, Micheal Patterson wrote: Anyone have any info on a current issue with a feed apparently being cut between AZ and CA that's causing problems for Cox customers by chance? The cut is a complete cut of a 108 fiber bundle between Yuma, AZ and El Centro, CA. L3 reports it is a very isolated area with no roads, making any access very difficult and slow. The last estimate we received at 23:37 EST (20:37 PST) was 3-4 more hours with the proviso that Estimate may change depending on circumstances on-site. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Comcast IPv6 Trials
From: tv...@eyeconomics.com Date: Thu, 28 Jan 2010 09:34:52 -0500 On Jan 28, 2010, at 9:07 AM, TJ wrote: -Original Message- From: tv...@eyeconomics.com [mailto:tv...@eyeconomics.com] Sent: Thursday, January 28, 2010 08:12 To: Richard Barnes Cc: NANOG Subject: Re: Comcast IPv6 Trials SNIP But then that begs the question of why lots of other very large retail Internet access providers have not indicated that they're committed to the same course of action (?). They're certainly not the only provider that employs a public IP address- intensive access model, so where are the other retail IPv6 trial announcements/pre-announcements? Other providers are moving in that direction, atleast a couple are (as a swag) 6-18 months behind Comcast ... /TJ I have no particular reason to to doubt that claim, and lots of reasons to actively hope that you are right. That said, the appearance of more public commitments like this -- and sooner rather than later -- could make a large difference, e.g., by reducing the general level of uncertainty (and uncertainty-amplifying speculation) during the terminal stages of IPv4 allocation. While no commercial entity would (and none should) willingly make such a public commitment before they're ready, it would be prudent to consider the potential downsides of that looming uncertainty when making judgements about how ready (or perhaps ready enough) should be defined. Might be worth noting that Comcast has been using IPv6 heavily for internal connectivity (including router access) for some time and already had substantial experience with IPv6, so I suspect that they are ahead of others on this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Comcast IPv6 Trials
Date: Wed, 27 Jan 2010 20:59:16 -0800 From: George Bonser gbon...@seven.com -Original Message- From: William McCall Sent: Wednesday, January 27, 2010 7:51 PM Subject: Re: Comcast IPv6 Trials Saw this today too. This is a good step forward for adoption. Without going too far, what was the driving factor/selling point to moving towards this trial? SWAG: Comcast is a mobile operator. At some point NAT becomes very expensive for mobile devices and it makes sense to use IPv6 where you don't need to do NAT. Once you deploy v6 on your mobile net, it is to your advantage to have the stuff your mobile devices connect to also be v6. Do do THAT your network needs to transport v6 and once your net is ipv6 enabled, there is no reason not to leverage that capability to the rest of your network. /SWAG My gut instinct says that mobile operators will be a major player in v6 adoption. SWAG is wrong. Comcast is a major cable TV, telephone (VoIP), and Internet provider, but they don't do mobile (so far). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Using /126 for IPv6 router links
From: TJ trej...@gmail.com Date: Mon, 25 Jan 2010 15:15:55 -0500 -Original Message- From: Tim Durack [mailto:tdur...@gmail.com] Sent: Monday, January 25, 2010 14:03 To: TJ Cc: nanog@nanog.org Subject: Re: Using /126 for IPv6 router links snip 2^128 is a very big number. However, from a network engineering perspective, IPv6 is really only 64bits of network address space. 2^64 is still a very big number. An end-user assignment /48 is really only 2^16 networks. That's not very big once you start planning a human-friendly repeatable number plan. An ISP allocation is /32, which is only 2^16 /48s. Again, not that big. Once you start planning a practical address plan, IPv6 isn't as big as everybody keeps saying... I didn't realize human friendly was even a nominal design consideration, especially as different humans have different tolerances for defining friendly :) It was absolutely an issue. The excellent A6 proposal was killed because it was not human friendly. Very computer friendly, but people were not too happy about dealing with it. It was, in most ways, vastly superior to , but a real pain to try to deal with by hand. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: D/DoS mitigation hardware/software needed.
From: Dobbins, Roland rdobb...@arbor.net Date: Sun, 10 Jan 2010 21:56:38 + On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote: The only thing you've said that is being disputed is the the claim that a firewall under a DDoS type of attack will fail before a server under the same type of attack. It's so obvious that well-crafted programmatically-generated attack traffic, if nothing else, will crowd out the good traffic that I'm just dumbfounded anyone thinks 'proof' of this is needed. Same thing for the fact that horizontally-scaled Web farm (with or without reverse caching proxies) will of necessity handle a great deal more TCP state than the biggest, firewall made to date. * because it doesn't correlate with my 22 years of experience in systems administration and 14 years in netops (including Yahoo netsecops where I did use IXIAs to compile stats on FreeBSD and Linux packet filtering), It doesn't correlate with my 25 years in the industry, a good portion of the last 15 years spent handling DDoS after DDoS after DDoS, during which the biggest, baddest firewalls choked and died over and over again, through multiple generations of said firewalls. Again, I was able to take down a hardware-based (for whatever value of 'hardware-based' is possible) firewall rated at 2gb/sec with 80kpps of traffic. * it doesn't correlate with experience in large networks with multiple geographically disperse data centers where we did use Arbor, Cisco and Juniper equipment, It correlates with my experience in large networks with geographically-dispersed IDCs with heterogeneous gear. * it doesn't correlate with server and firewall hardware and software designs, and last but not least, Which is a non-sequitur. * because you have shown no objective evidence to support the claim. I've my own broad subjective experience, and that of several other people who've commented on this thread have similar experiences. Since you haven't yet acquired this subjective experience, you can cause it to happen in a controlled test environment, should you so choose. Where then, can we find the results of your testing? The testing I did when I worked for the vendor in question is proprietary, as you can well surmise. You're free to do your own testing and confirm these assertions for yourself. Nobody has hurled insults in this thread other than yourself Roland. You accused me of acting in my own pecuniary interest, of trying to 'sell' things, *for no reason at all*. We just need some actual statistics. If you actually care about the truth of the matter, you're free to generate your own. If you read the RoK/USA DDoS preso to which I linked, you see the attack throughput and bandwidth metrics/host, and you also see where I noted multiple 'Web Application Firewalls', load-balancers, and so-called 'IPS' falling over as a result of those attacks. That gives you a range right there, along with some attack traffic characteristics, including average packet size. It makes no sense to put a stateful inspection device in front of servers, where *every single packet* is unsolicited, and therefore no state tracking is even possible in the first place. Stateless filters in hardware capable of mpps do a much better job, without the risk of falling over due to state-table exhaustion. Folks who've been unlucky enough to be subjected to significant DDoS attacks have run into this issue again and again and again. Perhaps you've simply been lucky; but one can't count on one's luck holding forever. There is a culture that has developed a dogma that firewalls are THE solution. Be it DDOS or most any other security threat. Like many dogmas, it is ingrained into so many people that denial is essentially heresy. People simply know that a firewall is essential, so any contrary argument is obviously bogus or confused and must be denied. I used to work at the place that probably invented the stateful firewall and the folks who invented it became the priests of the firewall dogma and went forth and preached its value. Note that this predates DDOS by many years and that they did have some valid arguments. But the result was an army of security experts who scowled and marked the audit as FAILED if you did not front EVERYTHING with a firewall. I know of one case where an organization bought a firewall and programmed it to pass everything, just to fix an automatic failure of a security audit. Oddly, the auditor did not even look at who the firewall was configured. Simple presence of the box made him happy. I'm afraid that you are fighting a dogma that will only slowly be beaten into recognizing reality, but I appreciate your fighting the good fight. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key
Re: I don't need no stinking firewall!
From: Jared Mauch ja...@puck.nether.net Date: Tue, 5 Jan 2010 16:20:56 -0500 On Jan 5, 2010, at 3:58 PM, Brielle Bruns wrote: It's all how you configure and tweak the firewall. Recommending people run servers without a firewall is bad advice - do you really want your Win2k3 server exposed, SMB, RPC, and all to the world? Some people think that exposing any functionality by default such as that is a poor security practice :) My biggest issue is that people think that Firewalls, AV, etc are a catch-all for any network/user/security badness. The real world is more complex than that. Most people make poor security choices and this creates much larger issues. I thought the firewall would protect me. I thought my IPS would protect me I thought my AV would protect me Most of these technologies create a truly false sense of security. I'm once again reminded of many people who do technically silly things like block TCP/53, packets over 512 bytes, port 587, ssl imap ports, etc. It's frustrating and sad because it's not an effective security strategy and frustrates grumpy old-school users as myself that used odi drivers w/ ka9q to multitask over our CSLIP networks. I suspect at least part of this will soon get fixed due to DNSSEC. Blocking tcp/53 and packets over 512 bytes will cause user complaints and, after enough education, the problem will get fixed. I had a problem with a large US government site due to tcp/53 blocking and had no luck getting it fixed. The Security Officer informed me that tcp/53 was only ever needed for zone transfer and any other use was clear evidence of abuse. RFCs meant nothing to him. (I don't know if he knew what an RFC was.) Now that gov domains are mandated to be signed, seems like he learned that tcp/53 could be used for normal operations. You can get more with a kind word and a two-by-four than you can with just a kind word. J. Michael Straczynski from Ceremonies of Light and Dark Babylon 5 -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Speed Testing and Throughput testing
Date: Mon, 2 Nov 2009 18:22:19 -0500 From: Jon Meek mee...@gmail.com I use iperf with packet capture on both sides, then analyze the packet capture for per-second throughput and re-transmits. I usually do 10 TCP streams for 30 seconds. Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is needed to deal with the bandwidth delay product. It is also possible that Ethernet drivers will have an effect. Local testing of the pair of test machines should be done if you can't get to about 980 Mbps on a Gig link (keeping in mind the comment about TCP tuning as latency increases). Jon On Mon, Nov 2, 2009 at 4:56 PM, Mark Urbach mark.urb...@pnpt.com wrote: Anyone have a good solution to get accurate speed results when testing at 10/100/1000 Ethernet speeds? Do you have a server/software that customer can test too? I'll also suggest http://fasterdata.es.net as a resource for network tuning. Tuning TCP is hard. UDP is simple, but some things can even impact UDP. Many less than obvious things can have a huge impact on high-speed data transfer. The choice of congestion algorithms can be very significant. As anyone who has used bittorrent should have noticed, having multiple TCP streams works better than a single stream. An oddity we have noted is that some routers will process switch layer 2 traffic if a layer 3 interface exists on the port even if it is unconfigured and unused. Man, that kills performance, even in low latency situations! FWIW, we use mostly iperf, but may be biased as the iperf maintainer works here. We did start using iperf before we hired him, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Minimum IPv6 size
From: Leo Vegoda leo.veg...@icann.org Date: Sun, 4 Oct 2009 04:32:44 -0700 On 03/10/2009 8:19, Matthew Petach mpet...@netflight.com wrote: [...] So, if I need to break up my /32 into 4 /34s to cover different geographical regions, I should instead renumber into a new range set aside for /34s and give back the /32? Sure seems like a lot of extra overhead. Perhaps we should give everyone an allocation out of each filter range, so that they can simply number from the appropriately-classed range; when you apply for space, you'd get a /32, a /33, a /34, a /35, a /36, etc. all from the appropriate, statically defined ranges. I think ARIN proposal 2009-5 (https://www.arin.net/policy/proposals/2009_5.html) is designed to cope with the situation you describe. I understand that it's on the agenda for the meeting in Dearborn. I don't think so. I believe the statement is not in regard to separate, discrete networks bu to a network with a national footprint which must deaggregate to do traffic engineering by region. Item 2 clearly makes 2009-5 non-applicable to this case. This issue will be discussed in a Mark Kosters moderated panel at NANOG in Dearborn. Hey, why not attend both meetings? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Minimum IPv6 size
Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge j...@mcvax.org --On 2 October 2009 16:43:14 -0700 Kevin Oberman ober...@es.net wrote: Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Minimum IPv6 size
Date: Sat, 03 Oct 2009 23:29:41 +0200 From: Christian Seitz se...@strato-rz.de Hello, Kevin Oberman wrote: Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge j...@mcvax.org --On 2 October 2009 16:43:14 -0700 Kevin Oberman ober...@es.net wrote: Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. each RIR has an overview of their managed address space with the longest prefixes they are assigning/allocating from their ranges. I currently use those overviews to build IPv6 BGP filters manually. If you build very strict filters, you have to check the overviews more often as with loose filters. https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html http://www.arin.net/reference/ip_blocks.html http://www.arin.net/reference/micro_allocations.html http://www.apnic.net/db/min-alloc.html http://lacnic.net/en/registro/index.html http://www.afrinic.net/Registration/resources.htm There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html Thanks for the AfriNIC URL. I did had not seen that page. I'm pretty sure that the PI space was not declared last time I looked for something. We do allow deaggregation of all space to /35. That is three bits allowing for 8 different announcements. We are always re-evaluating this policy and it is quite possible that it will be moved to a /36 in the future. We also are considering loosening the PI down to /50 or even /52. I really can't see much justification to go beyond that at this time. No matter how hard people try, I am sure that we will need to continue to broaden filters and expand the route tables. I belive that, in the long run (and not very long) the only solution will be some kind of locator/identifier separation which has the potential to control the size of the RIB and FIB for a very long time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key
Re: Minimum IPv6 size
Date: Fri, 02 Oct 2009 16:29:25 -0700 From: Seth Mattinen se...@rollernet.us Since we're on the topic of what's commonly accepted in IPv4 land (a /24), what's the story in IPv6 land? It seems to me that a /32 is a fur sure thing, but others will accept down to a /48, too. Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Link capacity upgrade threshold
Date: Sun, 30 Aug 2009 21:04:15 +0900 From: Randy Bush ra...@psg.com If your 95th percentile utilization is at 80% capacity, it's time to start planning the upgrade. s/80/60/ the normal snmp and other averaging methods *really* miss the bursts. s/60/40/ If you need to carry large TCP flows, say 2Gbps on a 10GE, dropping even a single packet due to congestion is unacceptable. Even with fast recovery, the average transmission rate will take a noticeable dip on every drop and even a drop rate under 1% will slow the flow dramatically. The point is, what is acceptable for one traffic profile may be unacceptable for another. Mail and web browsing are generally unaffected by light congestion. Other applications are not so forgiving. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Anyone else seeing (invalid or corrupt AS path) 3 bytes E01100 ?
From: Brett Watson br...@the-watsons.org Date: Mon, 17 Aug 2009 19:11:06 -0700 On Aug 17, 2009, at 5:17 PM, Paul Ferguson wrote: I recall Cisco code bugs that were fixed in semi- real-time, and quotes from tli: Code still warm from compiler. Confidence level: Boots in lab. IETF Dallas, 1995 I think. MCI Reston engg and Cisco (Ravi and others) in the terminal room cutting a new image of IS-IS for us because we'd tripped on the 24-day timer bug wherein all adjacencies would drop. Loaded on production routers that evening to fix the problem... good times :) I remember back in 1993 or 1994 getting a note from Tony Li chastising us for running BGP4 code that was over a WEEK old. How could we possibly expect things to work with code that far out of date? The amazing part is that BGP4 not only worked, but was very stable less then a month later when NSFnet shut down an se had to go to BGP4 to peer with everyone (like MCI, Sprint, NASA, and UUnet). Yep, it booted in the lab, all right. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Follow up to previous post regarding SAAVIS
Date: Wed, 12 Aug 2009 16:12:39 -0500 From: Justin Shore jus...@justinshore.com Jared Mauch wrote: I've come to the conclusion that if someone put a nice web2.0+ interface on creating and managing these objects it would be a lot easier. I've looked into IRR several times, usually after events like PCCW. Each time the amount of work to 1) figure out how to implement IRR and 2) actually implementing it far outweighed the benefit of doing it for my network. I would love to implement it and looking towards the future I will someday have to. Until it becomes much easier to do so, I don't foresee smaller SPs like myself allocating the necessary resources to an IRR project until we're forced to because of our individual growth or an idiot PCCW-type event that generates lots of bad PR. While a web 2.0 app would be very nice, it's really not that hard to do now. You do need the IRRToolSet or something similar. the IRRToolSet has languished for a long time and was getting harder and harder to keep running, but the move to sourceforge and the massive number of updates and clean ups should soon result in a 5.0 release that builds cleanly on most Unix/Linux platforms with a modern C++ compiler. Once that happens, it's really pretty simple to use the IRR for this sort of thing and, while the IRR data quality is pretty poor, it's a vast improvement over crossing your fingers and sticking your head in the sand. Except for the ugliness of the Perl I wrote well over a decade ago (when I was just learning Perl), I'd try to talk the powers that be into allowing me to release it as an example, but the relevant code is really, really trivial. (Not that government would let me without vast quantities of paperwork.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Dan Kaminsky
Date: Tue, 04 Aug 2009 13:32:42 -0400 From: Curtis Maurand cmaur...@xyonet.com andrew.wallace wrote: On Thu, Jul 30, 2009 at 11:48 PM, Dragos Ruiud...@kyx.net wrote: at the risk of adding to the metadiscussion. what does any of this have to do with nanog? (sorry I'm kinda irritable about character slander being spammed out unnecessarily to unrelated public lists lately ;-P ) What does this have to do with Nanog, the guy found a critical security bug on DNS last year. He didn't find it. He only publicized it. the guy who wrote djbdns fount it years ago. Powerdns was patched for the flaw a year and a half before Kaminsky published his article. http://blog.netherlabs.nl/articles/2008/07/09/some-thoughts-on-the-recent-dns-vulnerability However - the parties involved aren't to be lauded for their current fix. Far from it. It has been known since 1999 that all nameserver implementations were vulnerable for issues like the one we are facing now. In 1999, Dan J. Bernstein http://cr.yp.to/djb.html released his nameserver (djbdns http://cr.yp.to/djbdns.html), which already contained the countermeasures being rushed into service now. Let me repeat this. Wise people already saw this one coming 9 years ago, and had a fix in place. Dan K. has never claimed to have discovered' the vulnerability. As the article says, it's been know for years and djb did suggest a means to MINIMIZE this vulnerability. There is NO fix. There never will be as the problem is architectural to the most fundamental operation of DNS. Other than replacing DNS (not feasible), the only way to prevent this form of attack is DNSSEC. The fix only makes it much harder to exploit. What Dan K. did was to discover a very clever way to exploit the design flaw in DNS that allowed the attack. What had been a known problem that was not believed to be generally exploitable became a real threat to the Internet. Suddenly people realized that an attack of this sort was not only possible, but quick and easy (relatively). Dan K. did what a security professional should do...he talked to the folks who were responsible for most DNS implementations that did caching and a work-around was developed before the attack mechanism was made public. He was given credit for finding the attack method, but the press seemed to get it wrong (as they often do) and lots of stories credited him with finding the vulnerability. By the way, I know that Paul Vixie noted this vulnerability quite some years ago, but I don't know if his report was before or after djb's. Now, rather then argue about the history of this problem (non-operational), can we stick to operational issues like implementing DNSSEC to really fix it (operational)? Is your DNS data signed? (No, mine is not and probably won't be for another week or two.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Nanog mentioned on BBC news website
Date: Wed, 22 Jul 2009 21:27:39 +0100 From: andrew.wallace andrew.wall...@rocketmail.com Big up the Nanog community, you do the net proud... http://news.bbc.co.uk/1/hi/technology/8163190.stm First showed up on NANOG 7 hours ago, but it was a fun read. Clearly the article has little connection with reality. I am not an unpaid volunteer and neither were most or all of those involved. The idea that just because the traffic does not originate or terminate on my net means that working on solving a problem is altruism is pretty silly. And NANOG was not really involved though several of those that were are active in NANOG. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Cisco 7600 (7609) as a core BGP router.
From: Brad Fleming bdflem...@kanren.net Date: Fri, 17 Jul 2009 18:07:26 -0500 We don't run very much Cisco gear (none of their larger, hardware stuff) but I have a couple questions for the Cisco gurus out there... According to this page: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a0080159856_ps4835_Products_Data_Sheet.html The Cisco WS-SUP720-3BXL can hold 1,000,000 (IPv4); 500,000 (IPv6) route entries. 1) Does that mean a) The card can hold 1m IPv4 routes --OR-- 500K IPv6 routes or b) 1m IPv4 routes --AND-- 500K IPv6 routes? It means that it will hole 1M IPv4 OR 500K IPv6. It means that IPv6 addresses take twice the TCAM that IPv4 routes do, so that for every IPv6 route in TCAM, you can load two fewer IPv4 routes. Worse, TCAM is partitioned with a dedicated portion for IPv4 addresses and another for IPv6 + multicast. To adjust the partitioning, you must reload the supervisor. 2) I'm assuming MPLS cuts into the number somewhere but could anyone explain it briefly? Not really. The TCAM holds routes and the place to send packets destined for them. Since all TCAM is loaded based on flows and treated very much like MPLS, just without an external tag, the TCAM space should not be impacted. (I am NOT positive about this one, though.) 3) Do ACLs use some of these resources or do they get their own slice of memory? Nope. They are in a different TCAM in the Sup720. They have zero impact. That page also reports up to 40 Gbps per slot of switching capacity; 720 Gbps aggregate bandwidth. Is the 40Gbps per slot an aggregate or full-duplex value? I don't entirely understand the phrasing of the question, but I think you mean, do they double the numbers as router marketeers are wont to do by counting traffic in both directions? No. That is why you can drive all 4 ports of the 4x10GE card to almost the full 10G at the same time in both directions. Not quite, though. Cisco steals a little bandwidth on each cord for some internal signaling, so each pair of the 10GE ports is limited to about 19 GB. (I don't recall the exact number.) So they are just slightly oversubscribed. The backplane is actually a pair of 20 Gbps backplanes with the ports divided between them. On the 4x10G cards, the two top ports are on one backplane and the two bottom ones are on the other. They each have access to a full 20Gbps path less the stolen bandwidth. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Why choose 120 volts?
From: Alex Rubenstein a...@corp.nac.net Date: Tue, 26 May 2009 15:43:20 -0400 I have a pure curiosity question for the NANOG crowd here. If you run your facility/datacenter/cage/rack on 120 volts, why? Because we are stupid. I've been running my facility at 208 for years because I can get away with lower amperage circuits. I'm curious about the reasons for using high-amp 120 volt circuits to drive racks of equipment instead of low-amp 208 or 240 volt circuits. That makes you smarter than the average guy. But, if we were really smart, we'd run at least 277, or maybe 347. Countless amounts of money would be saved on losses (transformation), copper (smaller wire), and many other areas. Most of the stuff we all run is already insulated for these voltage levels. Even better would be all two pole 2 pole 480's or 2 pole 600's, then we wouldn't need neutrals. Oh, yeah! Nothing sounds like more fun than working in a room full of 480 or 600 delta. I LIKE neutrals. (Sort of like I like continuing to have a functioning heart.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: The adventures of Team ARIN
Date: Wed, 27 May 2009 13:19:55 +0900 From: Randy Bush ra...@psg.com https://www.arin.net/knowledge/comic.html Short short synopsis: comic about how ARIN handles certain things and what ARIN does etc. imiho, an embarrassment to arin and to the internet Initially I thought the same thing, but the feedback from the large number of totally clueless ARIN customers has been overwhelmingly positive. Clearly, the comic book was never intended for the typical subscriber to this list. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: two interfaces one subnet
From: Chris Meidinger cmeidin...@sendmail.com Date: Mon, 11 May 2009 23:38:30 +0200 On 11.05.2009, at 23:31, Dan White wrote: Chris Meidinger wrote: Hi, This is a pretty moronic question, but I've been searching RFC's on- and-off for a couple of weeks and can't find an answer. So I'm hoping someone here will know it offhand. I've been looking through RFC's trying to find a clear statement that having two interfaces in the same subnet does not work, but can't find it that statement anywhere. The OS in this case is Linux. I know it can be done with clever routing and prioritization and such, but this has to do with vanilla config, just setting up two interfaces in one network. I would be grateful for a pointer to such an RFC statement, assuming it exists. If your goal is to achieve redundancy or to increase bandwidth, you can bond the interfaces together - assuming that you have a switch / switch stack that supports 802.3ad. Then you could assign multiple IPs to the bonded interface without any layer 3 messyness. I should have been clearer. The case in point is having two physical interfaces, each with a unique IP, in the same subnet. For example, eth0 is 10.0.0.1/24 and eth1 is 10.0.0.2/24, nothing like bonding going on. The customers usually have the idea of running one interface for administration and another for production (which is a _good_ idea) but they want to do it in the same subnet (not such a good idea...) This will not work right. One interface can be 10.0.0.1/24, but any added interfaces would need to be /32 (10.0.0.2/32). What your customer wants can probably be done, but it is a really bad idea. Put them in different subnets. If you need to, break off a /30 from the /24. (That is a bit messy as you meed to break the /24 into a /25, a /26, a /27..., but it should work fine. Since the main interface has to talk to ALL of the subnets, you will need to use one address from each and that is pretty wasteful, but it should work.) Just really UGLY! If only a part of the address space need be used, it gets easier and less ugly. If a /25 will work, it's pretty much normal configuration on both interfaces. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Testing LFNs
Date: Wed, 06 May 2009 11:10:45 -0400 From: Kaegler, Mike kaegl...@tessco.com I have a new T3 thats 65msec long. I'd usually be using iperf to test new links, but at 65msec, even at the maximum window size, I can only get 6-8mbit through. No combination of options I've been able to find has gotten me more than 6mbit through this link. Should I just shotgun 9 copies of it? Are there better ways to test these links? Can one verify this link with just a pair of 7200s and linux machines on either side? Or is this something one really needs real test hardware for? If 6mbit go through clean, is there a real chance 44 will not? What is maximum window size? For T3 at 65 ms (is that one-way or RTT?) you don't need a really big window. Sounds like the system may need tuning. See http://fasterdata.es.net/ I use iperf at multiple Gigabit speeds and it works on a tuned system. You might want to use UDP for testing. It does not care about RTT, but is less efficient to receive. At 45 Mbps, there should be no problems, though. If all else fails, run 4 or 5 iperf jobs in parallel. (Use a different port for each.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Important New Requirement for IPv4 Requests
Date: Fri, 24 Apr 2009 19:05:26 +1200 From: Perry Lorier pe...@coders.net Large data sets? So you are saying that 512-byte packets with no windowing work better? Bill, have you measured this? Time to download a 100mb file over HTTP and a 100mb interface: 20 seconds. Time to download a 100mb file over FTP and a 100mb interface: ~7 minutes. And yes, that was FreeBSD with the old version openssl library that shipped with 6.3. As someone who copies large network trace files around a bit, 100MB at 100mb, over what I presume is a local (low latency) link is barely a fair test. Many popular web servers choke on serving files 2GB or 4GB in size (Sigh). I'm in New Zealand. It's usually at least 150ms to anywhere, often 300ms, so I feel the pain of small window sizes in popular encryption programs very strongly. Transferring data over high speed research networks means receive windows of at least 2MB, usually more. When popular programs provide their own window of 64kB, things get very slow. Very few people (including some on this list) have much idea of the difficulty in moving large volumes of data between continents, especially between the Pacific (China, NZ, Australia, Japan, ...) and either Europe or North America. Getting TCP bandwidth over about 1Gbps is very difficult. Getting over 5G is nearly impossible. I can get 5Gbps pretty reliably with tuned end systems over a 100 ms. RTT, but that drops to about 2G at 200 ms. A good web site to read a bout getting fast bulk data transfers is: http://fasterdata.es.net It is aimed at DOE and DOE related researchers, but the information is valid for anyone needing to move data on a Terabyte or greater scale over long distances. We move a LOT of data between our facilities at FermiLab in Chicago and Brookhaven in New York and CERN in Europe. A Terabyte is just the opener for that data. Also, if you see anything that needs improvement or correction, please let me know. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Important New Requirement for IPv4 Requests
From: Skywing skyw...@valhallalegends.com Date: Fri, 24 Apr 2009 10:55:07 -0500 Of course, sftp and other ssh-based protocols are *still* hamstrung to a maximum of 32k data outstanding due to hardcoded SSH channel window sizes by default for most people, unless you're patching up both your clients and servers. Sadly, this blows ssh out of the water for anything with even modest high-bitrate requirements over moderate-BDP links. The HPN patches for OpenSSH are readily available and, at least on FreeBSD, including them is just a single checkbox when you install. That said, I have been told that there is a corner case where a transfer using the HPN patches will lock up. I have never seen it, but that is purported to be the reason that OpenBSD has not accepted the patches for the base OpenSSH software. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Malicious code just found on web server
Date: Mon, 20 Apr 2009 10:52:57 -0700 From: Paul Ferguson fergdawgs...@gmail.com On Mon, Apr 20, 2009 at 10:40 AM, Nick Chapman nicknetwo...@gmail.com wrote: On Mon, Apr 20, 2009 at 12:47 PM, Neil kngsp...@gmail.com wrote: But if you figure out how they got write access to a static website, I'd love to hear it. Compromised FTP credentials would be my guess. They can be obtained by brute force attacks or credential stealing trojans. Yeah, it could have been any number of ways -- there has also been a huge increase of SSH brute-force attacks in the past few weeks: https://isc.sans.org/diary.html?storyid=6214 And, from several reports (including my own), they (brute force ssh attacks) seem to have stopped at about 22:30 UTC on the 19th. (Not that this is really relevant to the thread.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Gigabit speed test anybody?
From: char...@thewybles.com Date: Fri, 27 Mar 2009 22:47:17 + Owamp? owamp is a latency measurement tool. While we find it invaluable, I'm not sure how it fits in here. We use iperf on high-performance systems with a lot of tuning and Myricom 10GE cards to test 10 Gig circuits (10GE or OC-192). No particular endorsement of Myricom. We also qualified Chelsio. At the time we tested, TSO on the Chelsios caused some problems when the other end was a Myricom, but TSO is easily turned off. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Google Over IPV6
From: Florian Weimer f...@deneb.enyo.de Date: Fri, 27 Mar 2009 19:20:42 +0100 * Robert D. Scott: When I posted my original note, I was not really looking for end user feedback, but rather is anyone peering V6 with them on either a public fabric or private peer. Any idea if they have native V6 transit, or are tunneling, and to where. Google seems to aim at Tier 1 status for IPv6. No transit, no tunneling. From their web page at http://www.google.com/intl/en/ipv6/: To qualify for Google over IPv6, your network must have good IPv6 connectivity to Google. Multiple direct interconnections are preferred, but a direct peering with multiple backup routes through transit or multiple reliable transit connections may be acceptable. Your network must provide and support production-quality IPv6 networking and provide access to a substantial number of IPv6 users. Additionally, because IPv6 problems with users' connections can cause users to become unable to access Google if Google over IPv6 is enabled, we expect you to troubleshoot any IPv6 connection problems that arise in your or your users' networks. So you need multiple IPv6 connections or one IPv6 connection with transit IPv6 support to get it. A university with a direct peering with Google and and Internet2 transit to google would probably qualify. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Leap second tonight
From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= a...@develooper.com Date: Mon, 16 Mar 2009 23:07:42 -0700 On Dec 31, 2008, at 15:28, Kevin Oberman wrote: We use CDMA clocks and last leap second it took weeks for all of the cell sites to adjust the last one. As a result, I have set all of our clocks for manual leap second and set them to adjust tonight at midnight (UTC).I'll take a look in about 35 minutes and see how it worked. Chiming in a little late here ... Over at the NTP Pool we had about 9% of the servers not handle the leap second accurately; starting at midnight UTC. After an hour (so between 01:00 and 02:00) it was down to about 3%; a couple hours later down to about 1% of our servers (a few dozen)[1]. Most of those got in order within 24-48 hours.Interestingly the few who didn't get corrected within a few days were, tada: CDMA clocks. To stay vaguely NANOG on-topic: I believe at least some of our ~1700 NTP servers are routers; so I'm guessing they handled the leap second alright. Routers as ntp servers. Yuck! Routers route well, but they treat time as a low priority job and jitter on Cisco routers is simply terrible. Junipers do better, but are still a poor time server. Sounds like a RISKS lesson: Don't use side-effects of a tool for something critical. (If I understand it right then CDMA uses accurate time because it needs accurate frequency; not because it cares what time it is). As I understand it, they need both time and frequency to do cell hand-offs cleanly, but, as long as all towers in a carrier's market are showing the same time, it really does not matter if they do the leap second. Endrun Technologies, who make our clocks, ship them configured for manual leap seconds because so many cell operators are pretty casual about the leap second thing, but that means that the people using the clocks need to be aware that they need to be told when a leap second is coming and that, in turn, means the they must know a bit about leap seconds and must have read the manual. No surprise that a lot of CDMA clocks missed the leap second.
RE: XO peering.
On Tue, 2009-03-10 at 11:41 -0500, Mort, Eric wrote: We had some hardware issues in San Jose which triggered some other ugliness. We believe we have the issues mitigated at this time. Folks still seeing issues are encouraged to hit me up offline. Thanks, Eric J. Mort XO Communications Sr. Manager - IP Operations Desk - 314-787-7826 Cell - 314.486-9057 em...@xo.com -Original Message- From: Jake Mertel [mailto:j...@nobistech.net] Sent: Tuesday, March 10, 2009 11:34 AM To: John Martinez; nanog@nanog.org Subject: RE: XO peering. We had a number of issues in the Seattle area this morning, seemed to be isolated to traffic transiting via Level 3. We were forced to turn off the connection, and it's still disabled until we get an update from XO. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Web: http://www.nobistech.net/ Phone: (312) 281-5101 ext. 401 Fax: (808) 356-0417 Mail: 201 West Olive Street Second Floor, Suite 2B Bloomington, IL 61701 -Original Message- From: John Martinez [mailto:jmarti...@zero11.com] Sent: Tuesday, March 10, 2009 11:23 AM To: nanog@nanog.org Subject: Re: XO peering. We saw an issue with Level 3 hand off to XO in Chicago. Stefan Molnar wrote: There was a peering issue in San Jose with XO, that impacted our operations this morning. But looks like a side effect is after the hand off to NTT. Anyone who has an XO link can reach areas insdie NTT? As an example our route to Salesforce /21 is via NTT and it is not happy right now. Thanks, Stefan No joy from our (AS293) perspective. I still see traffic to XO at SJ black-holed. eqx-sj-rt1-re1 traceroute 198.17.75.45 traceroute to 198.17.75.45 (198.17.75.45), 30 hops max, 40 byte packets ^C Works fine from Ashburn, though. I've pref'ed XO down at SJ until it is working again. -- R. Kevin Oberman Energy Sciences Network (ESnet) Ernest Orlando Lawrence Berkeley National Laboratory (Berkeley Lab) E-Mail: ober...@es.net Phone: +1 510-486-8634 signature.asc Description: This is a digitally signed message part
Re: MAC address confusion
Sorry fot the top-post, but my Treo makes it almost impossible to do otherwise. The protocols using these reserved, local addresses all use them to embed the network layer address. AA addresses are used by DECnet and kin while 02 is for XNS, I seem to recall. As long as the only addresses used in these spaces are thse asigned by those protocols and they use peoperly assigned network layer addresses, ther will never be a conflict. That is the point in0the registration...marking them as reserved for the protocols in question and not to be used for anything else. Sent from my Treo: R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) E. O. Lawrence Berkeley National Laboratory (LBNL) ober...@es.net +1 510-486-8634 -Original Message- From: Saku Ytti saku+na...@ytti.fi Date: Wednesday, Mar 4, 2009 12:49 am Subject: Re: MAC address confusion To: nanog@nanog.org On (2009-03-03 13:50 -0800), Kevin Oberman wrote: This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. Why would they need to have same L3 address? The way I see it, only thing that matters is, if or not, the addresses might speak ethernetII. If your ethernetII switch sees your local 02 address and one of the addresses below and they collide, the switch will keep relearning the address behind two ports. Unless of course it is guaranteed, that none of these addresses will ever appear as BIA in ethernetII capable NIC. 02-07-01 (hex)RACAL-DATACOM 02-1C-7C (hex)PERQ SYSTEMS CORPORATION 02-60-86 (hex)LOGIC REPLACEMENT TECH. LTD. 02-60-8C (hex)3COM CORPORATION 02-70-01 (hex)RACAL-DATACOM 02-70-B0 (hex)M/A-COM INC. COMPANIES 02-70-B3 (hex)DATA RECALL LTD 02-9D-8E (hex)CARDIAC RECORDERS INC. 02-AA-3C (hex)OLIVETTI TELECOMM SPA (OLTECO) 02-BB-01 (hex)OCTOTHORPE CORP. 02-C0-8C (hex)3COM CORPORATION 02-CF-1C (hex)COMMUNICATION MACHINERY CORP. 02-E6-D3 (hex)NIXDORF COMPUTER CORPORATION -- ++ytti
Re: MAC address confusion
Date: Tue, 3 Mar 2009 08:42:16 +0200 From: Saku Ytti saku+na...@ytti.fi On (2009-03-02 17:31 -0800), Kevin Oberman wrote: http://standards.ieee.org/regauth/oui/oui.txt 02-07-01 (hex) RACAL-DATACOM Would be interesting to see what are the historical reasons.Perhaps they simply predate the scheme or some might not even co-exist in ethernet network to begin with, in which case they might be better documented elsewhere. IEEE after 802.3 was ratified. IEEE agreed to retain existing registrations and they have remained there. So where does this leave the current local scape addresses being globally assigned? Is it possible that we will run into legit 02 MAC addresses in the wild? Thee are properly locally assigned,not local scope addresses, but the effect is the same. This is only a problem if you have multiple systems running DECnet (or some other protocol using this) with the same layer 3 address. That should never happen, so there should be no duplication. The only real issue I see is with IPv6 EUI-64 addresses and even in that case, there would have to be two systems getting their address space from the same router interface before there is a conflict. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: IPv6 Confusion
From: David Conrad d...@virtualized.org Date: Wed, 18 Feb 2009 07:57:12 -1000 Mikael, On Feb 17, 2009, at 9:18 PM, Mikael Abrahamsson wrote: Suggestion: next time you buy equipment from competing vendors, tell the sales folk from the losing vendors that one deciding factor was (vendor or product) IPv6 support. That (and perhaps only that) will get their attention... :-) Well, considering how very few vendors actually support IPv6, it's hard to find proper competition. You don't have to tell the truth to the losing sales folk... :-) Yes, I saw the smiley, but what you suggested could cause a lot of suffering if it is a formal bid. (If a mom-n-pop buys a 2960, probably not an issue.) Ethical issues aside, giving incorrect information to a losing vendor is fraud and, at least in the public sector, can get you in more trouble than you would ever want to think about being in. Our procurement officers are scrupulous in detailing the required information for the losing bidder's debrief on contracts of any size. This means putting in just as much information as is required and nothing more and making sure that what is included is correct. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: IPv6 Confusion
From: Owen DeLong o...@delong.com Date: Tue, 17 Feb 2009 11:48:49 -0800 On Feb 17, 2009, at 11:28 AM, Tony Hain wrote: While people frequently claim that auto-config is optional, there are implementations (including OS-X) that don't support anything else at this point. The basic message is that you should not assume that the host implementations will conform to what the network operator would prefer, and you need to test. I can configure OS-X statically, so, that simply isn't true. What is true is that there are many implementations which do not (yet) support DHCPv6. That is not the same as don't support anything else. One last comment (because I hear just more bits a lot in the *nog community)... Approach IPv6 as a new and different protocol. If you approach it as IPv4 with more bits, you will trip over the differences and be pissed off. If you approach it as a different protocol with a name that starts with IP and runs alongside IPv4 (like we used to do with decnet, sna, appletalk...), you will be comforted in all the similarities. You will also hear lots of noise about 'lack of compatibility', which is just another instance of refusing to recognize that this is really a different protocol. At the end of the day, it is a packet based protocol that moves payloads around. The problem here, IMHO, stems from the fact that unlike DECnet, Appletalk, SNA, et. al., IPv6 is intended as a replacement for IPv4. (None of the other protocols was ever intended to replace any of the others). As a replacement, the IETF realized that at the current scale of the internet when they began designing IPv6, a flag day conversion (like what happened when we went to IPv4) was not possible. Unfortunately, the migration plan set forth by the IETF made many assumptions (especially on vendor preparedness and rate of adoption prior to IPv4 runout) that have not proven out, so, the Everyone who has IPv4 starts running dual-stack before we need any IPv6 only connectivity plan is not going to prove out. More unfortunately, there is no real contingency plan for how migration happens absent that scenario and we are, therefore, in for some interesting times ahead. While this is very true, at least the IETF has recognized the problem and the BEHAVE WG is trying to come up with some way of getting out of the trap we have worked our way into. The big iron folks are proposing something called Carrier Grade NAT. This one REALLY frightens me, but I understand a couple of hardware manufacturers are planning on building such a monster. It might actually work, but the amount of state carried strikes me as in invitation to disaster. There was a draft on CNG, but it expired last month. A copy is still available at: http://smakd.potaroo.net/ietf/all-ids/draft-nishitani-cgn-00.txt Also, a proposal for a different approach is at: http://mice.cs.columbia.edu/getTechreport.php?techreportID=560 (PDF) If you are really concerned about where we go whan v4 address space is exhausted, I strongly urge you to look at all of these issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Anyone notice strange announcements for 174.128.31.0/24
Date: Mon, 12 Jan 2009 13:52:17 -0500 From: Paul Stewart pstew...@nexicomgroup.net Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul -Original Message- From: Majdi S. Abbas [mailto:m...@latt.net] Sent: Monday, January 12, 2009 1:49 PM To: Michienne Dixon Cc: nanog@nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote: I'm not entirely certain what is going on but has anyone noticed some strange announcements for 174.128.31.0/24? I received a hijack notice that my AS (AS11708) was announcing the above IP range. I verified that I was not when I started noticing some strange announcements for that range. Around 10 Am CST AS11911 was announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083). Interestingly enough, ARIN indicates this is a part of range they have assigned for reachability testing. http://ws.arin.net/whois/?queryinput=174.128.31.0 randy lied but no packets died enough now More seriously, this is indeed reachability research. Try emailing the AS 3130 contacts although I'd imagine Randy will see this. http://psg.com/173-174/ explains what is going on. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpjlh8B9x05V.pgp Description: PGP signature
Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
Date: Sun, 04 Jan 2009 09:22:06 +0200 From: Hank Nussbacher h...@efes.iucc.ac.il At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote: On Sat, 3 Jan 2009, Hank Nussbacher wrote: You mean like for BGP neighbors? Wanna suggest an alternative? :-) Well, most likely MD5 is better than the alterantive today which is to run no authentication/encryption at all. But we should push whoever is developing these standards to go for SHA-1 or equivalent instead of MD5 in the longer term. Who is working on this? I don't find anything here: http://www.ietf.org/html.charters/idr-charter.html All I can find is: http://www.ietf.org/rfc/rfc2385.txt http://www.ietf.org/rfc/rfc3562.txt http://www.ietf.org/rfc/rfc4278.txt Nothing on replacing MD5 for BGP. I don't see why this is an issue (today). As far as I understand it, the vulnerability in MD5 is that, with time and cycles, it is possible to create a collision where two files have the same MD5 hash, so the counterfeit cert would check as valid. For the MD5 signature on a TCP packet, this is not relevant. Am I missing something? (I will admit to not being a cryptography person, so I may totally misunderstand.) I don't object to moving to a stronger hash, but, considering the expense and time involved, I'd suggest waiting for the new hash algorithm that the NIST challenge will hopefully provide. In other words, stick to MD5 in places where it is not believed to be vulnerable and where converting to SHA-1 or SHA-256 would be expensive. Where it IS believed vulnerable, the cost/benefit ratio would have to determine when the conversion is justified. For X.509 certs, I believe the answer is clearly that it is justified and has been for at least 2 years. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpsnqNVI34mF.pgp Description: PGP signature
Re: Leap second tonight
From: Kevin Day toa...@dragondata.com Date: Wed, 31 Dec 2008 16:41:39 -0600 Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+reminder+nanogpage=1refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. While I hope people are not still running NTP versions too old to handle leap seconds correctly, but that is only a small part of the problem. If the stratum 1 reference clocks don't handle leap seconds correctly, there is no way for NTP to deal with it. We use CDMA clocks and last leap second it took weeks for all of the cell sites to adjust the last one. As a result, I have set all of our clocks for manual leap second and set them to adjust tonight at midnight (UTC).I'll take a look in about 35 minutes and see how it worked. I've heard reports of various GPS clocks not dealing with the leap second correctly, as well. Fortunately, not too many need this sort of accuracy, but those of us who do need to be prepared. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpb4CY7IEfZG.pgp Description: PGP signature
Re: IPv6: IS-IS or OSPFv3
Date: Sat, 27 Dec 2008 15:23:25 -0500 From: Steven M. Bellovin s...@cs.columbia.edu On Fri, 26 Dec 2008 20:37:41 -0800 Kevin Oberman ober...@es.net wrote: The main reason I prefer ISIS is that it uses CLNS packets for communications and we don't route CLNS. (I don't think ANYONE is routing CLNS today.) That makes it pretty secure. Unless, of course, someone one hop away -- a peer? a customer? an upstream or downstream? someone on the same LAN at certain exchange points? -- sends you a CLNP packet at link level... You mean that someone is silly enough to enable CLNS on external interfaces? I mean, it's not by default on either Cisco or Juniper. I don't imagine any other routers do that, either. (Of course, SOMEONE is always that silly. But I hope the folks reading this are not.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpPe26dUNlK1.pgp Description: PGP signature
