August 2001 - Test - lists.nanog.org

None
by David Barak 30 Aug '01

30 Aug '01

Charles Sprickman wrote: >The internet is different now, there's no >comparison to what it was in '94 or '96. Those >episodes were more >embarrasments than anything else. Would UUNet or ATT >or Genuity think >twice about upgrading routers if there was impending >danger of a lack of >memory or cpu? In this market, with capital expenditures WAY down, I would expect non-upgrade solutions to be more likely. >Can a small ISP in Florida still clobber the whole >internet? Learning experiences, that's all... You'd be surprised at the number of substantive ISPs who can be impacted by customer mistakes... David Barak "Quis custodes ipsos custodiet?" - Juvenal __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com

1 0

backhoe damage (karachi, pakistan)
by Jim Mercer 30 Aug '01

30 Aug '01

a backhoe (or potentially a group of labourers with picks and shovels) managed to sever a pile of cable near one of the CO's in Karachi, Pakistan. this outage is effecting several ISP's and voice services. ETA for fix is 14:00 GMT 8^) -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Now with more and longer words for your reading enjoyment. ]

1 0

Re: What is the limit? (was RE: multi-homing fixes)
by smd＠clock.org 30 Aug '01

30 Aug '01

The Internet *FAILED* in 1994. The number of prefixes carried globally exceeded the ability of the global routing system to carry it, and as a result, some parts of the world deliberately summarized away whole large-scale ISPs merely to survive. The Internet *FAILED* again in 1996, when the dynamicism in the global routing system exceeded the ability of many border routers to handle, and as a result, some networks (not just core ones) deliberately made the Internet less quick to adjust to changes in topology. Thus, the routing system FAILED twice: once because of memory, once because of processor power. If the size or the dynamicism of the global routing system grows for a sustained period faster than the price/performance curve of EITHER memory OR processing power, the Internet will FAIL again. I do mean the Internet, and not just some pieces of it. The old saw, "the Internet detects damage and routes around it" simply isn't true, when your routing system isn't working. It was unpleasant both times. Three continents were effectively isolated from one another for a couple of days while organizing a response to the memory crisis. Three of the largest ISPs at the time were crippled on and off for days during the processing power crisis, and even when mechanisms were brought into place, relatively unimportant bugs destabilized the entire Internet from time to time. Note that the processor power issue is the one that has been scariest, since it has had small-scale failures fairly regularly. Things like selective packet drop *exist* because of the price/performance curve and engineering gap for deploying and USING more processing power. So, Moore's Law, or more specifically the underlying curve which tracks the growth of useful computational power, is exactly what we should compare with the global routing system's growth curve. Note that when Moore is doing better than the Internet, it allows for either cheaper supply of dynamic connectivity, or it allows for the deployment of more complex handling of the global NLRI. The major problem, as you have pointed out, is that processing requirement is often bursty, such as when everyone is trying to do a dynamic recovery from a router crash or major line fault. We could still use 68030s in our core routers, it's just that it'd take alot longer than it used to perform a global partition repair, which means your TCP sessions or your patience will probably time out alot more frequently. | I think that what we need to do is have a fourth group, call them Internet | Engineers for lack of a better word, come in and determine what the sign | should read. Structures built according to best known engineering practices still fall down from time to time. That's the problem in anticipating unforeseen failures. Consider yourself lucky that you haven't had to experience a multi-day degredation (or complete failure!) of service due to resource constraints. And that you haven't run into a sign that says: "please note: if you try to have an automatic partition repair in the event this path towards {AS SET} fails, your local routing system will destabilize". | Finally, we have a sixth group, call them the IETF, come in | and invent a flying car that doesn't need the bridge at all. As Randy (with his IETF hat) says: "send code". Sean.

13 18

Re: What is the limit? (was RE: multi-homing fixes)
by Philip Smith 30 Aug '01

30 Aug '01

At 06:01 30/08/2001 -0400, John Fraizer wrote: >Speaking of filtering: > >AS64602 at Mae-West from Digex (AS2548) ASPATH=2548 64602 64602 64602 >64602 64602 64602 IGP > >AS65515 at Mae-West from Verio (AS2914) ASPATH=2914 10910 10910 10910 >10910 10910 10910 11908 10530 5593 65515 IGP > >AS65515 at AADS from Verio (AS2914) ASPATH=2914 10910 10910 10910 10910 >10910 10910 11908 10530 5593 65515 IGP > >AS65515 at Paix from Verio (AS2914) ASPATH=2914 10910 10910 10910 10910 >10910 10910 11908 10530 5593 65515 IGP > >Which part of (64512 - 65535 != valid ASN) do providers not understand? > >Filter! Filter! Filter! And your favourite router vendors have a useful command/knob to remove private ASes from announcements too. It's not hard to put that on all eBGP peerings... philip --

1 0

Re: What is the limit? (was RE: multi-homing fixes) (fwd)
by Larry Sheldon 30 Aug '01

30 Aug '01

> > > Err. Water and electricvity make a dangerous mix. > > > > Ya. My air handling systems seem to deal with it OK. > > They are kept in different places. Now think how are you going to combine > hot-swappability and water cooling, and not let moisture to get out :) I don't recall seeing any mops around when the CE's replaced a board on the 1100/90's. They were not "hot-swappable"--but nobody had thought of _that_ as a good marketing drool. We had "redundant" equipment and took the broken one off-line to work on it. [snip] > As soon as you do liquid cooling the price goes up an order of magnitude. > > This is as simple as that. Be interesting to know where that came from. Particularly when you consider the "liquid-cooled" versus "can't do it" costs. > My take is that the real answer is to move from heavy, sticky electrons to > photons; the trick is to get them to interact in useful ways :) Had your finger on an operating LASER lately?

1 0

RE: What is the limit? (was RE: multi-homing fixes)
by Roeland Meyer 30 Aug '01

30 Aug '01

|> From: Randy Bush [mailto:randy@psg.com] |> Sent: Wednesday, August 29, 2001 9:18 PM |> |> > there would appear to be people who assert its not unafordable to |> > compute the routes for the current, and the forseeable network. |> |> and there are those of us who think we can probably do so iff we stop |> the explosion of /24s. Okay, let's get it back out of the realm of opinion and into requirements. I'll even go down one step more, to /25. Take the entire IP addr space, break it ALL into /25's, times the BGP table entry size, how big is that? Could 4GB of RAM do it? How about 8GB? Your average 64-bit processor can handle T-Bytes and they are affordable by your average basement dual-homers. Also, I just got a price quote for 512MB ECC PC133 DIMMS at $49US, retail. Oh yeah, that same processor runs faster than 1 GHz. That's todays *computer* technology. Router technology needs to catch up. Considering what router vendors charge, with very fat margins, for their low-tech routers, affordable tech arguments don't hold water. Routers are expensive because someone is stupid enough to pay the prices. We are getting royally ripped off there. Cisco takes special RAM because Cisco designed incompatible RAM circuitry so they could charge you more for the Cisco label. It also bolsters the FUD-storm and the after-market support vendors. BTW, you really ought to check out that site at http://www.routerrevolution.com. The reason I chose /25 is because the average small business can easily use that much space, but would have a hard time justifying a /24.

2 1

Re: multi-homing fixes
by smd＠clock.org 30 Aug '01

30 Aug '01

Iljitsch van Beijnum <iljitsch(a)muada.com> writes: | If we remove all non-essential | information from a route, we finally arrive at the single thing that must | always be encoded for each route individually: whether it is reachable or | not. If we assign a bit of memory to every possible route Is this a novel way of doing RIP and solving the split-horizon problem by eliminating the "D" in "DV"? Sorry for being obtuse, but what does this bit-vector really represent? That neighbour A (a MAC address on a LAN, or a p2p interface or a VP/VC/DLCI/blah on an NMBA interface) is an OK next-hop towards prefix X? Variations upon Random Routing will give you better results and significantly reduce your storage requirements! Or is it associated with a next-hop address with a recursive lookup into another database (e.g. your IGP), such that each known next-hop has one of these bit vectors associated with it? Or do you mean something else by "reachability" than I do? | An idea would be to assign /16s to geographic areas. Each ISP that has | customers in that area would announce the /16, just like they would do | now, but with an attached bitmap that indicates for which /24s this | announcement is valid and for which it isn't. So 10 ISPs in one area would | all announce the /16 with a 256 bit bitmap, so just 10 routes end up in | the default-free zone instead of 500. So, a per-prefix "holes" attribute in the form of a flattened Patricia Tree? Where is the savings here? Indeed, how do you avoid unflattening the bit-vector when eventually building your Adj_RIB/Loc_RIB/FIB? (Although admittedly you probably save more space on the line than gzipping the data stream would...) I'm pretty sure I need further explanation to "get it"./ Sean.

2 1

Re: FIBER CUT: Dallas to West Coast
by Sean Donelan 30 Aug '01

30 Aug '01

On Wed, 29 August 2001, Sean Donelan wrote: > Is anyone else seeing a fiber cut between Dallas and San Diego/Los Angeles? There is no mention of it on the UUNET/Worldcom web site, but it appears to be a Worldcom circuit cut somewhere between Dallas and Los Angeles. Some folks are backup now through re-routing. Worldcom has techs on-scene resplicing the cable. No ETR.

4 4

Re: What is the limit? (was RE: multi-homing fixes)
by smd＠clock.org 30 Aug '01

30 Aug '01

| If you had a router that could handle 2^32 prefixes, it will handle | the IPv4 Internet. Forever. The whole growth curve argument is | gone. Sure, just about anybody can build a router which has 2**32 forwarding directives burned into ROM. It gets easier with fewer interfaces, too. But, who wants a static network? In the early 90s we had a network where you could wait a week before the core of the Internet adapted to your topology change, and changed its routing towards a particular prefix. It wasn't really much fun. So, even though I convert (x/2)² into x/2 in what passes for my head, I think that it's pretty clear that the problem isn't the state at any given moment, but rather the rate of change of that state. | The global routing table cannot grow exponentially forever. And neither can the rate of change. The problem only has to be Too Hard to compute affordably, not NP-complete. (I bet others are already explaining this later in my $MAIL, but I seem to be stuck on doing things linearly today...) | For reference, there are approximately 10^80 electrons in the | universe (per several physics sources I found on the net). Oh cool, particle physics. How many degrees of freedom do these electrons have? Interesting point: a prefix in the global routing table CAN have one or more moments of inertia. Maybe something multilevel is even better. Something like following the contributions of constituent quark spin to a hadron or nucleon or would certainly be even more appropriate, since indeed an IGP perturbation can lead to fluctuation at the EGP (i.e. BGP) level, causing announcements to rotate about a set of interfaces. I bet Ahuja & Labowitz have even recorded this happening. Hey maybe there is some deep irony at work in that one can analogize the work of Dyson Sr (QED, QCD) and Jr (ICANN) in this way... | Not to minimze the short term issue, but to hand wave and say | "it's exponential and we'll never get ahead of it" is crap. It | won't be forever, so let's get ahead of it. There's lots of irony in that too. Other than the hand-wave, how do you propose to get (and stay) ahead of it? Sean.

5 4

RE: What is the limit? (was RE: multi-homing fixes)
by Roeland Meyer 30 Aug '01

30 Aug '01

1 0