August 2010 - Test - lists.nanog.org

RE: UPDATED - Comcast enables 6to4 relays
by Skywing 31 Aug '10

31 Aug '10

- S -----Original Message----- From: John Jason Brzozowski <john_brzozowski(a)cable.comcast.com> Sent: Tuesday, August 31, 2010 5:57 To: Pekka Savola <pekkas(a)netcore.fi> Cc: NANOG <nanog(a)nanog.org> Subject: Re: UPDATED - Comcast enables 6to4 relays On 8/31/10 7:36 AM, "Pekka Savola" <pekkas(a)netcore.fi> wrote: > On Tue, 31 Aug 2010, John Jason Brzozowski wrote: >> Enabled two more 6to4 relays this morning. :) > > Out of curiousity, what is the aggregate Mbps load on the relays? > Related question is the platform on which these are run. [jjmb] for now I can say the traffic doubled after the first pair of relays were deployed. They are Linux based. ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =========================================

1 0

RIPE Labs article on the Duke/RIPE NCC BGP experiment
by Andrei Robachevsky 31 Aug '10

31 Aug '10

Dear Colleagues, On Friday, 27 August, at 08:41 (UTC), RIPE NCC staff involved in the Routing Information Service (RIS) project conducted an Internet routing experiment in conjunction with a research group from Duke University in the United States. The goal of this experiment was to further global understanding of Internet routing behaviour, specifically the use of optional attributes in Border Gateway Protocol (BGP). The experiment ended as scheduled at 09:08 (UTC). Shortly after this, we discovered that the experiment had caused an unexpected and unintended negative impact on Internet operations, lasting for approximately 30 minutes. An article has now been published that provides more information on the experiment and its effect on the network: https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experim… If you have any questions or comments regarding this incident, please contact <ncc(a)ripe.net>. Regards, Andrei Robachevsky Chief Technical Officer, RIPE NCC

1 0

Did your BGP crash today?
by Kasper Adel 30 Aug '10

30 Aug '10

Havent seen a thread on this one so thought i'd start one. Ripe tested a new attribute that crashed the internet, is that true? Kim

39 84

Life experience: Cisco ASR9000 vs. Juniper MX960
by Jason Lixfeld 30 Aug '10

30 Aug '10

I'm looking for feedback on Cisco's ASR9000 vs. Juniper MX960. We're evaluating the two and are in the process of testing these two platforms and I'd like to try to have a leg up on testing if there are any gotchas that have crept up in the real world. What we're looking for information on are problems that have arisen in these areas: - Interface linerate issues (oversubscription, etc) - Backplane/slot capacity issues (oversubscription, etc) - Supervisor/RE switchover - DC PDUs and power redundancy - BGP4/MP-BGP - IPv6 - L2VPN - L3VPN - VPLS - LDP - RSVP - MPLS-TE - MPLS-FRR - OSPF - ISIS - In the case of Juniper, interoperability with Cisco for MPLS and associated protocols and features. - Anything else you'd like to mention, good or bad. If anyone is interested, I'll compile the results and provide them to whomever. Thanks in advance.

2 1

route-views.sydney.routeviews.org
by John Kemp 30 Aug '10

30 Aug '10

RouteViews has now established a routing data collector at the EQUINIX exchange in Sydney, Australia. We are now accepting peers. If you would like to participate in the project by contributing your routes, please contact us at: help(a)routeviews.org. RouteViews currently operates collectors at the University of Oregon, at the Palo Alto IX, at the Equinix IX in Ashburn Virginia, at the LINX in London, at WIDE in Tokyo, and at other locations. We are now ready to serve peers who are reachable at EQIX SYD1. RouteViews collectors are useful as operational looking glasses, as well as a sources of data for network research. RouteViews also participates in the BGPMON project, which provides real-time data feeds in support of the Cyclops free route-monitoring service. In general, we ask for full routes input, and filter to zero output. Our peering details are: AS6447, V4 Address: 202.167.228.100/25, V6 Address: 2001:de8:6::6447:1/64 Additional information is available at http://www.routeviews.org/ John Kemp (kemp(a)network-services.uoregon.edu) RouteViews Engineer E-MAIL: help(a)routeviews.org PHONE: 541-346-1714

1 0

Off-Topic: Seeking sponsor for infrastructure related site.
by Jay Ess 30 Aug '10

30 Aug '10

First of all i want to apologize for the off topic nature of this post. I am seeking sponsorship for one of my hobby project. My needs is one or two dedicated servers on a stable network in USA and or Europe. DNSDigger.com is one of my hobby projects that has outgrown my own means of hosting as i am on 75% sick leave from my ordinary job. DNSDigger is a database of domain and hostnames that is resolved into IP-adresses and can show what domains a IP-adress (or IP-span) has "behind". The data is collected by downloading com/net-zone from Verisign and http spidering. Then "simply" resolving all the hundreds of millions of hostnames and make it search able. This sounds like a bandwidth hog but i actually run all this from a home private cable connection (dont tell anyone ;) and i have had no troubles except for outgrowing my Pentium D "server". If you find this service fun and valuable and have the means of providing an high end dedicated server plus hosting i would love to hear from you. An "powered by <your company>"-link/button and information page will be offered. /John Stromstedt (john(a)netrogenic.com)

1 0

Re: Recycling old cabling?
by Frank A. Coluccio 30 Aug '10

30 Aug '10

All of the larger telcos and power utilities have been 're-smelting' copper for decades. Verizon (nee NY Telephone) had a copper smelting plant on Staten Island at one time that recycled all of the used cross-connect wire and cables removed from underground and poles. Telco main distribution frame personnel were, and very likely still are, instructed to use "copper-scrap" bags for depositing small bits and pieces of copper wiring collected at cleanup time at the end of work shifts. Many years ago, copper, for this reason, was one of the three "C"'s that no one would mess with. Copper and Cash were two.I'll leave the third one to the reader's imagination. This subject is interesting because it's one of the cost-justifiers in business models that seek to re-engineer large office buildings and other copper-intensive venues where the objective is to replace all copper wiring with hybrid fiber-wireless alternatives. While reclamation through salvage is only a by-product of this movement, it is nonetheless one that is cash intensive, so it cannot be overlooked. Not only is the copper data cabling removed (Cat3/5e/6, in this case), but also potentially tons of power cables and racks supporting sometimes hundreds of riser telecom/LAN closets, where there are usually anywhere from two to four closets per floor, depending on the size of the floor plate, in a forty- or sixty-story building, say. Every copper penny helps these days. --- streiner(a)cluebyfour.org wrote: From: "Justin M. Streiner" <streiner(a)cluebyfour.org> To: nanog(a)nanog.org Subject: Recycling old cabling? Date: Tue, 17 Aug 2010 07:29:50 -0400 (EDT) Just out of curiosity, is anyone here recycling old cabling and plant infrastructure for their raw materials, or engaging a recycler to handle those materials? Where I work, there is almost always a renovation project going on. This provides opportunities to rip out Cat3/Cat5/long-abandoned thicknet/thinnet/FDDI-grade fiber/etc, which we normally do. Most of the time that old cabling ends up in the dumpster, but I'm wondering if anyone is recycling it, either by their choice, or as the result of company policy or relevant laws in your area? Cat3/Cat5 can be broken down to raw materials with some effort, but I haven't seen many recyclers with an economically viable process for doing it. Coax is a bit tougher, but not impossible (same questions about economic viability still apply). Fiber can be tough, expecially if you're dealing with something like 20+ year old gel-buffered cable where the has long-since dried out. I'd be interested to hear other peoples' experiences along these lines. jms

7 6

AT&T routing problems towards www.worldspan.com?
by sthaug＠nethelp.no 30 Aug '10

30 Aug '10

We have problems reaching www.worldspan.com (216.113.132.22) from some locations. The common problem seems to be AT&T (AS 7018). Our AS path towards the 216.113.128.0/19 prefix is typically 3356 7018 17228 19631 Anybody else see problems here? I note that I can ping 216.113.132.22 from some locations within our network - but not, for instance, from route-server.ip.att.net. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

3 3

[NANOG-announce] Reminder: NANOG Steering Committee nominations are open
by Steve Feldman 30 Aug '10

30 Aug '10

This is a quick reminder that nominations for the NANOG Steering Committee election are still open. The deadline for nominations is in about a week, on Monday, August 30. Also, nominations for Program Committee membership will be accepted beginning this Tuesday, August 24. Elections for three of the six elected positions on the NANOG Steering Committee will be held in October, 2010, for two-year terms ending in October, 2012. The current SC members whose terms are expiring are Patrick Gilmore, Joe Provo, and Robert Seastrom. Joe is finishing his second consecutive term, so per the charter, cannot be considered for reelection until October 2011. If you care about NANOG as a forum, and think you would like to take a turn at volunteering your time to help make it better, please consider either volunteering yourself or nominating someone else. For more information about the role of the Steering Committee, or to find out more about what's involved in being a Steering Committee member, please consult the NANOG charter or contact someone who is already serving and ask them directly. http://www.nanog.org/governance/charter/ http://www.nanog.org/governance/steering/steeringcommittee.php Per the charter, Steering Committee members must attend at least two of three NANOG meetings per year while in office. HOW TO NOMINATE SOMEONE You may nominate someone else, or yourself. There is no limit to the number of nominations that may be submitted by a single person. Individual nominees will be contacted directly to confirm that they are willing to accept the nomination, and so that they can supply a biography for the NANOG web page. To submit a nomination, send the nominee's full name and contact details to nominations(a)nanog.org. The deadline for nominations is 11:59 PM EDT on Monday, August 30. The candidates will be given an opportunity to make brief comments and/or accept questions from the community at the NANOG 50 Community Meeting on Sunday, October 3. As a reminder, the full election timeline is: Aug. 2 - SC Nominations begin Aug. 24 - Potential charter amendments discussed in nanog-futures Aug. 24 - PC Nominations begin Aug. 30 - SC Candidate information posted/nominations close Sep. 13 - Call for Communications Committee nominations Sep. 21 - Ballot approved Oct. 3 - Voting opens at 12:00 EDT Oct. 4 - PC Candidate Information posted/nominations close Oct. 6 - Voting closes at 09:15 EDT, results announced before the close of NANOG 50. For the SC, Steve Feldman _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 1

Re: Did your BGP crash today?
by Deepak Jain 29 Aug '10

29 Aug '10

On BB, so top posting. Apologies. It seems that creating a worst case BGP test suite for all kinds of nastiness (in light of the recent RIPE thing) might not be a bad idea - so that we can all test the implementation ourselves before we deploy new code. Like all funky attributes, all funky AS SETs... With knobs for 1 to mem exhaust (for long data sets, etc). Unless BGP is massively more complicated than I remember, its not a very advanced CS grad project. I'm thinking a quagga or perl BGP talker would be a good place to start. Deepak ----- Original Message ----- From: Christopher Morrow <morrowc.lists(a)gmail.com> To: Florian Weimer <fw(a)deneb.enyo.de> Cc: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Sun Aug 29 01:12:00 2010 Subject: Re: Did your BGP crash today? On Sat, Aug 28, 2010 at 6:14 AM, Florian Weimer <fw(a)deneb.enyo.de> wrote: > * Christopher Morrow: > >> (you are asking your vendors to run full bit sweeps of each protocol >> in a regimented manner checking for all possible edge cases and >> properly handling them, right?) > > The real issue is that both spec and current practice say you need to > drop the session as soon as you encounter any unexpected data. That's sorry, I conflated two things... or didn't mean to but did anyway. 1) users of gear that does BGP really need to ask loudly and longly (and then go test for themselves) that their BGP speakers do the 'right thing' when faced with oddball scenarios. If someone sends you a previously unknown attribute... don't corrupt it and pass it on, pass if transitive, drop if not. 2) some thought and writing and code-changes need to go into how the bgp-speakers of the world deal with bad-behaving bgp speakers. Is 'send notify and reset' the right answer? is there one 'right answer' ? Should some classes of fugly exchange end with a 'dropped that update, moved along' and some end with 'pull eject handle!' ? it's doubtful that 2 can get solved here (nanog, though certainly some operational thought on the right thing would be great as guidance). i would hope that 1 can get some traction here (via folks going back to their vendors and asking: "Did you run the Mu-security/Oolu-univ/etc fuzzing test suites against this code? can I see the results? I hope they match the results I'm going to be getting from my folks in ~2wks... or we'll be having a much more structured/loud conversation..." another poster had a great point about 'all the world can screw with you, you have no protections other than trust that the next guy won't screw you over (inadvertently)'. There are no protections available to you if someone sets (example) bit 77 in an ipv4 update message to 1 when it should by all accounts be 0. Or (apparently) if they send a previously unknown attribute on a route :( You can put in max-prefix limits, as-path limits (length and content), prefix-filters.. but internal-message-content you are stuck hoping the vendors all followed the same playbook. With everyone saying together: "Please appropriately test your implementation for all boundary cases" maybe we can get to where these happen less often (or nearly never) - every 3 months is a little tedious. -chris

2 1