September 2001 - Test - lists.nanog.org

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

28 Sep '01

| When Sprint was filtering there was a demonstrable need based on the 64meg | limit that | mainstream routers had for memory at the time. I do not see that there is | any such physical | limitation today and I guarentee that the router vendors (all two of them) | have learned the lesson | of not including enough address lines on the equipment to allow for easy | memory upgrades. So we should throw away all the 7200s and similar routers today because they are in the way of growing numbers of long prefixes, replacing them with new routers manufactured since the time of the above-mentioned lesson? And when shall we throw away the 12000s and similar routers (or components thereof) because they are underpowered in the face of routing-table growth, compared to well-established alternatives? Incidentally, the lesson learned was that sheer storage AMOUNT is only a (perhaps small) part of the problem, compared to the processing necessary to use that storage in support of dynamic routing (in terms of CPU and in terms of accesses to that memory). Sean.

5 4

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

28 Sep '01

> Find a way to provide reliable multi homing without massive route > table growth and you fix many things. We tried, at least for the IPv6 community, but A6 was just experimentalized. > I do not run Vario ... I will not fault them for taking a stance? It's hard to justify any statement of the form "somebody else ought to do XYZ". If it's a good idea and well presented, they'll do it. If not, they won't. I would no more allow a third party (noncustomer) to tell me what routes I had to accept than I would allow a third party to tell me what e-mail (e.g., "spam") I had to accept. If I own the router (or mail server, or whatever) then it's up to me (and my customers) to decide how they're to be configured. The flip side definitely applies as well. If a peer doesn't like the routes I'm sending them then since they're not a third party to the peering relationship they definitely have the power and right to negotiate with me. But somebody like Patrick would qualify as a third party, with no rights at all, and would be, and should be, ignored.

3 2

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