- Test - lists.nanog.org

Re: outside the box Was: The Gorgon's Knot.
by Dave O'Shea 28 Sep '01

28 Sep '01

Joseph T. Klein [mailto:jtk@titania.net] Sez: > > > At 21:32 +0200 28-09-2001, Stephane Bortzmeyer wrote: > >On Friday 28 September 2001, at 18 h 17, > >"Joseph T. Klein" <jtk(a)titania.net> wrote: > > > >> would have problems given larger route tables. We all > don't have routers > >> that can easily chew through a 100,000+ line BGP table. > > OK ... I amend my prior statement 250,000+ > > Yet, I don't belive every corner of every network has routers that can > easily chew through 100,000 route tables. Not the corners, probably. But certainly the areas more towards the core. > > > > >I believe it is a legend. Unless you use Cisco 25xx to have > a full BGP feed. > > Yeah right. I suggest you look at real world loaded 7200s. They have > problems with full routing tables. > I won't say a 7200 is just going to slice through them, but, they manage as long as you don't toss too much work at them. Can a 7200 be upgraded to 256mb? I am not using them these days so I forget... I have a feeling that when looking at 12-18 month growth of the global BGP table, there may be a point where it becomes fairly important to move routing analysis and processing out of the actual boxes that are moving the traffic, and into boxes that are optimized for it. Even with the current tables, a cisco 120xx box can work up a bit of a sweat when you "cl ip bgp (insert favorite AS here)" -- a lot more CPU than it would burn up in forwarding 2-3gbps of traffic. Even the current router-as-route-reflector technique uses a system optimized for packet forwarding to do more math than it was really built for. Routers are designed to beat existing benchmarks -- and the most common benchmark is "how many packets can I stuff into this thing?". > > > >Any Taiwan-made PC can swallow much more. The limit is not > clear but is > >certainly far away from us. > > I want to you to put a couple of channelized DS-3s, an ATM OC12c, > and a POS OC48c to your backbone plus all the BGP peers you can sign > up at AADS on a PC. There's some truth to the idea that a halfway capable gamer's machine has more actual processing power than most high-dollar routers. I'd guess that the difference is that a PC is optimized for analyzing and manipulating data, with I/O viewed just as a way to get more data. That said, I am *not* giving up my Quake/Unreal machine to serve as a route reflector until someone figures out how to stuff a GeForce3 into a GSR. My wife will beat me with a stick if I tell her I need to run 48vdc into my den. The 3KVA UPS already got the "Martha Stewart would *not* approve" look. I guess the model that comes to mind is something like MAE-West, which at one time was using something like a pair of Sparc-20's to handle several hundred various BGP sessions, and left the packet shuffling to hardware that was designed for the purpose. > > The black and white simplicity expressed by people on this forum is > unbelievable. .. and usually based on the assumption that everyone makes their decisions based upon the same experiences and observations.

2 1

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

| I have not see a solution that provides an answer to the need for robust, | high performance connectivity as well as multi-homing. Do you have an | alternative suggestion? We would love your comments on the ones being proposed (in drafts) or discussed (in list & list archives) in multi6, especially if the mechanisms are portable to other header formats (e.g. ipv4, where this is a pressing, current problem, rather than a barrier to deployment or something that would be useful to solve "soonishly"). Indeed, if you have even pretty wild ideas about how to do it, there's an audience for you that not only is amazingly polite and reasonably focused, but is REALLY REALLY keen on having real live operator input. Sean. PS if you are a draft-author or know one, please look at my or my co-chair's nagging email about updates/fixes/last-calls as appropriate PPS http://www.ietf.org/html.charters/multi6-charter.html (charter, information, links to mailing list & archives)

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

I wrote: > Filter To clarify and avoid accusations of hypocrisy, I continue to believe that progressive route-flap dampening is a reasonable alternative, and results in far fewer "help, i can't get through your network" calls to your NOC. Perhaps that indicates flap-dampened networks aren't nearly as often in the process of trying to be used as brand-new long prefixes? Sean. PS http://www.ripe.net/docs/ripe-210.html and the network i am involved with does use this

1 0

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by smd＠clock.org 28 Sep '01

28 Sep '01

| I don't know whether to argue this on the grounds that N^2 grows faster than N | and that the memory and processing capabilities of any single routing node are | insignificant next to the power of flap propagation It's more fun to suggest that not only should the Internet work in theory, it should work in practice, and in such a way that it can continue growing along several axes (number of users/links/nodes, time-online per user, amount of traffic moved per user per unit of time, ...). This suggests that cheap technology SHOULD be used. Unfortunately, the people who argue for "home appliances" have fallen victim to the theology of capex as the one true God, and should invest in some dotcoms/dotnets that work along those lines, while they still can. The reality is that upgrade and replacement costs in an expanding corner of the Internet tend to be large, and downtime represents a substantial real operational expense in the presence of modern SLAs (not to mention opportunity costs). Understanding those costs is as important as choosing equipment that works well enough today. This makes even home appliances appear expensive to own compared with the physical goo inside them, and there is no magic trick around high TCO in a busy part of the Internet. Forgive me for discussing engineering principles on NANOG. I know they're off-topic, and will shut up now. Sean. PS also sorry for the trendy acronym meaning total cost of ownership

2 1

Re: The backbone that sucks least?
by Paul Vixie 28 Sep '01

28 Sep '01

> We have servers colocated in 8 locations, 4 each with 2 of the big-name > colo providers, one of which made news today (no points for accurate > guesses). We are looking at adding new server locations in a carrier > neutral location like Equinix (who else is doing multiple carrier neutral > locations and has available space? paix, for one. > Of those, who sucks least? Does paying extra for UUNET actually get you > anything extra (better customer service, better billing/accounting service, > better trouble ticket tracking and reporting)? i've just got to say that uunet's monitoring and trouble ticketing is Great. i don't know whether their backbone is good or not, but their proactive monitoring and subsequent issue tracking is just Great, that's all, Great. whoever set it up should definitely buy themselves a cigar, or whatever.

5 4

Re: The Gorgon's Knot. Was: Re: Verio Peering Question
by Paul Vixie 28 Sep '01

28 Sep '01

> > would have problems given larger route tables. We all don't have routers > > that can easily chew through a 100,000+ line BGP table. > > I believe it is a legend. Unless you use Cisco 25xx to have a full BGP feed. > > Any Taiwan-made PC can swallow much more. The limit is not clear but is > certainly far away from us. I don't know whether to argue this on the grounds that N^2 grows faster than N and that the memory and processing capabilities of any single routing node are insignificant next to the power of flap propagation, or on the grounds that it is not possible for a person to argue about what THEY ought to do -- after all they just do it, or not, or whatever -- so the argument here seems to be about what OTHER PEOPLE -- that is, third parties -- ought to do, which is just nuts. Either way, it sure is NANOG in here.

1 0

Re: yummy yummy routing analysis from jim/andy/beej
by k claffy 28 Sep '01

28 Sep '01

sorry if this was posted already, but Renesys folks did some neato work on the RIPE BGP update archive double plus bgp-storm cool k ----- Forwarded message from cowie(a)renesys.com ----- Hi, all. We have significantly revised and extended our analysis of BGP prefix announcement/withdrawal storms that correlate with Code Red/Nimda propagation phases: http://www.renesys.com/projects/bgp_instability We welcome your feedback. --jim

1 0

Re: Verio Peering Question
by Patrick W. Gilmore 28 Sep '01

28 Sep '01

At 11:38 AM 9/28/2001 -0700, Steve Gibbard wrote: >I really don't see Verio being hypocritical here. Instead, I see Verio >making a decision about what they want in their own routing table, but >offering routes to other providers in case those other providers want to >make a different decision. Those other providers are welcome to filter or >accept those routes as they see fit. This seems like a simple case of >Verio not forcing its policies on anybody else. Except, of course, Randy has stated the reason for implementing the filtering policy (or one of them anyway) is because the Internet will collapse if we do not filter / stop long announcements. Since hypocrisy is essentially saying one thing and doing another, I would say this fits the definition nicely. But tell ya what, let's ignore the hypocrisy issue. I will drop it if you will. Filter does not allow smaller providers and companies to multi-home. Each network is, of course, allowed to do as they please. I encourage Verio and Verio engineers to continue filtering if they so desire. I also encourage all other providers to filter Verio exactly as Verio filters them. No one would be doing anything unethical, immoral, or illegal, but somehow I think Verio would decide it was no longer in their best interest to filter their peers. In fact, this is probably in the best interest of Verio's peers. It would remove any possible advantage Verio had over their competitors when speaking to potential customers. I know for a fact Sprint gained customers when they were filtering *because* they filtered (it was the only way to ensure the announcement got to Sprint). My suggestion would make the cost higher than the benefit. >-Steve -- TTFN, patrick

1 0

Re: Which had more impact on the net?
by George William Herbert 28 Sep '01

28 Sep '01

Sean Donelan <sean(a)donelan.com> committed: >Which had more impact on the the net? > 1. Destruction in New York City Sept 11 and following days > 2. Nimda virus/worm on Sept Sept 18 and following days > 3. Multiple fiber cuts on Sept 26 My home business was down for hours from side effects of 1, most of a day from side effects of 2, and didn't notice 3. Current backbone engineers I talk to on a regular basis fall about 50:50 into similar experience and having also taken a hit Sept 26 AM when Backhoe Roundup began. Speaking of which, this *has* been an interesting 2+a bit week period; reflecting on the various effects sounds like a good NANOG paper. >The Nimda, Code Red I/II, and other worms had a more difuse >impact. Their effects show up with a ramping period, peaking >after a few hours and then slowly declining over several days. >Their impact is extremely long lived. It mostly affects the >edges of the network. I'd disagree somewhat there. I think it mostly affects things the further from "backbones" that you get; a lot of ISPs took severe hits across their entire network depending on the manner in which IP space is allocated across their networks interacting with the attack patterns of Nimda. That doesn't map well to at least some usage of "edge", but I think I get your point... -george william herbert gherbert(a)retro.com

2 1

Re: Which had more impact on the net?
by Patrick W. Gilmore 28 Sep '01

28 Sep '01

At 01:47 AM 9/27/2001 -0400, Sean Donelan wrote: > > >Which had more impact on the the net? > > 1. Destruction in New York City Sept 11 and following days > 2. Nimda virus/worm on Sept Sept 18 and following days > 3. Multiple fiber cuts on Sept 26 I vote for #3, if you are considering a purely technological / routing Point Of View, which is the point of this mailing list. Affecting the backbones hurts everyone, everywhere, trying to do anything on the 'Net. The other are two localized (either in type or location) to matter overall. NIMDA did not affect e-mail, chat, IM, et cetera (pretty much), and did not even affect most web servers enough to matter to end users. News web sites being down did not affect anything other than the news web sites being down. And the destruction of a couple COs within a few city blocks (*and* a few city blocks :-{ ) is not - from a purely technological / routing standpoint - that big a deal. OTOH, #1 has a much more lasting impact. From increased traffic on web sites for years to come if this drags out, to the affect on "disaster planning", to the impact many of us who help run the Internet feel (I know I do), September 11th will have a much more profound impact on the 'Net than fiber cuts, especially in the long term But then, even if not one fiber was cut, not one website saw increased traffic, and not one colo was damaged on September 11th, it would still have a more of an impact than the other two in a lot of ways which are hard to measure at the command line of a cisco or Juniper. -- TTFN, patrick

3 2