- NANOG - lists.nanog.org

RE: multi-homing fixes
by James Spenceley 29 Aug '01

29 Aug '01

> the point of 2xDS3 was specifically to get major services, > and not to get > every basement dual-homer. do the latter and you have the > same grazing > of the commons as we have today. major services often equals large pipe size, but not always. rather than setting the baseline at pipe size (which essentially indicates a cost), make the cost of the miroallocation high enough to discourage mass uptake by said backyard dual-homers. > randy -- James This Email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. Before opening or using attachments, check them for viruses and defects. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 8220 6000 and destroy the original message. Thank You.

1 0

RE: multi-homing fixes
by James Spenceley 29 Aug '01

29 Aug '01

David, > >Checking each prefix sounds like an awful lot of work, much better to > >bitbucket a entire countries prefixes if they collectively > don't account for > >0.nnn% of your traffic. > > Except that prefixes aren't allocated by country. Prefixes > are allocated > to ISPs (mostly). I guess i should have used a ;-). My point, If US operators only want to accept prefixes for 'free' from networks that account for a percentage of their traffic, your in a position to effectively blackhole much of the developing nations Internet. Is access to a countries Internet more or less important than access to a route with a different bit length or traffic level ? The size of prefix isn't necessarily the only basis for that prefixes value. > -drc -- James This Email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. Before opening or using attachments, check them for viruses and defects. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 8220 6000 and destroy the original message. Thank You.

2 1

RE: multi-homing fixes
by David R. Conrad 29 Aug '01

29 Aug '01

James, At 11:44 AM 8/29/2001 +1000, James Spenceley wrote: >Checking each prefix sounds like an awful lot of work, much better to >bitbucket a entire countries prefixes if they collectively don't account for >0.nnn% of your traffic. Except that prefixes aren't allocated by country. Prefixes are allocated to ISPs (mostly). Rgds, -drc

1 0

RE: multi-homing fixed -- not!
by Roeland Meyer 29 Aug '01

29 Aug '01

A business, using between /24 and /19 (exposure of /20's is uncertain. sometimes ... sometimes not), still can't multi-home. Therfore, not fixed. |> From: Randy Bush [mailto:randy@psg.com] |> Sent: Tuesday, August 28, 2001 6:34 PM |> |> > how many providers have multiple POP's in a city that are |> _completely |> > redundant_? That is, they can operate _fully_ with one POP out of |> > service? |> |> none can operate *fully*, as a customer access line pretty |> much has to |> terminate in a single router which can, and eventually will, fail. |> |> but, most large providers have more than one pop in the |> largest cities, |> bay area, nyc, dee cee, etc. and those pops are redundantly |> and diversely |> wired. if not, don't buy from them. life can be simple. |> |> of course, in toledo, you're probably sol. Even big guys, in certain areas, are sol. thx for the proof.

1 0

Re: DNS Parser
by smoot＠tic.com 29 Aug '01

29 Aug '01

> "Deepak Jain" <deepak(a)ai.net> said: > Since IP allocations have been such a hot topic lately, I thought I'd ask > this -- > > Does anyone know of a simple script that will go through a list of BIND > primary files, or more and output a list of output like this: You might find my package "updatehosts" useful. It manages the DNS as a set of flat files (e.g. relationally normalized). It manages reverse zones automatically. Included are some tools to convert the zone files into the flat file format. It is GPLed and available at: ftp://ftp.tic.com/pub/updatehosts -- Smoot Carl-Mitchell Consultant

1 0

RE: What is the limit? (was RE: multi-homing fixes)
by Martin, Christian 29 Aug '01

29 Aug '01

> I don't think filtering on RIR allocations has anything to do > with keeping the > small people down. It is not a political problem, it is a > technology problem. Indirectly it certainly does. It is the small people who cannot justify the host requirements to acquire an allocation from the RIRs. Because the small provider cannot acquire PI space, they must resort to route leaking of PA space to the non-assigning upstream, who in turn must then announce this PA-microallocation to its peers. And, because, like it or not, the facts show that large (forgive the coinage) tier-1s are doing very passive filtering at the peering points, we see this explosion. It is quite enlightening to see what the big-8 exchange between each other. This is where the unobstructed growth is most dangerously occuring. And please don't tell me that we should force the smaller ASN to co-lo or multihome to the same provider of whatever. Any business that allows their suppliers to drive their business requirements when better alternative solutions exist shouldn't be in business. Coming from someone who has on occasion, introduced superfluous information into the GRS, there are limitations to BGP that force such leakage. And it is not a multihoming issue, but a traffic engineering one. Geoff has addressed this problem in his work on multihoming, but this thread is addressing only the multihoming-for-redundancy issue. This is half the problem, and as suggested, is dependent on the RIR allocation policy. What is also occuring (again, in a more dangerous sense) is the intentional leakage of more specific routing information by the mid-size regional ISP for the purposes of multi-provider TE. downstream A has met the requirements for an RIR allocation. It purchases one OC-12 at rock-bottom pricing from NSPA. It then purchases and OC-3 for backup to NSPB, but at a higher cost. If NSPA and NSPB are mutually well-connected at the same level in the AS hierarchy, then there will be an inbound load-distribution problem. So, the ISP breaks the /19 into 32 /24s, and announces them to both providers, depreferencing 6 of them toward the OC-12 carrier using communities. This forces all traffic to flow exactly toward the NSP with the best preference for the route if 1) the /24s are leaked between NSPA and B, and 2) the providers prefer customer routes over peer routes over customer backup routes (which nearly all providers do.). Furthermore, all peer ASNs of NSPA and B and their customers follow a non-deterministic path, that can only be affected if the above requirements are again met. However, there is no method at the ISPs disposal to scope these announcements to only these two NSPs (as the superfluous information does not need to flow beyond them, only the aggregate.) The idr-wg has been working on a mechanism to scope this longer-prefix leakage to the NSPs involved in this type of multihoming. It is actually derived from the dist-list-exclude and dist-list-include path attributes in IDRP (see sections 7.12.5-6 of ISO 10747 for more info). What this would allow a downstream to do is responsibly leak information only to those providers that are being paid to accept it. Isn't that novel? Instead of oppressing our smaller brethren, lets empower them to contribute to the solution. Attempting to squash them hasn't resolved anything, as we all seem to be well aware. Talk to your vendors - encourage them to implement draft-bonaventure-bgp-redistribution-01.txt as it matures. Now if we can only get the providers to upgrade their software... Regards, chris > > It will ultimately be solved when core routers can handle an > Internet worth of > /32's > and an EGP is developed to efficiently propogate changes > (perhaps an open > central > registry with policy applied locally). One has to wonder why > vendors don't > satisfy the > first requirement today. > > Until that time, you can either satisfy the (fairly > reasonable) minimum > allocation requirements, > Implement any number of alternate kludges that have been > proposed, or go home. > > KL >

1 0

Re: multi-homing
by Paul Vixie 29 Aug '01

29 Aug '01

uurtamo(a)arttoday.com (steve uurtamo) writes: > is _your_ router going to explode if my /24 gets added to your table? of > course not. your main concern is that your router explodes if _too_ many > people's prefixes, of whatever size, get added to your table. this is, i > think, a good thing to worry about, but it's a little early to be worrying. i think that absent the worrying that's already gone on, from way back before CIDR when BGPv3 was classful, is the only reason you can still say it's "early." alas, doomsayers who are taken seriously in their own time, that is, early enough for their prophesies to be treated as foresight and acted upon preventatively, are often called unstable sky-is-falling cranks in the history books. (witness the Y2K debacle if CIDR doesn't excite you.)

1 0

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

29 Aug '01

|> From: Martin, Christian [mailto:cmartin@gnilink.net] |> Sent: Tuesday, August 28, 2001 3:22 PM |> |> This is the umpteenth time that this type of thread and its |> spawn have been religiously fought out on NANOG. I didn't notice any wildly religious views, this time around. Maybe, with practice, we are getting better at it? |> What we don't see is any real data that indicates who |> is right and who is wrong. The only empirical data |> shows a comparison between routing table growth and Moore's |> law, which doesn't amount to a whole hill of beans |> if there isn't a reasonable frame of reference to which |> we can make comparisons. This is a serious problem. Can we not issue a writ of habeus corpus? Where is the body of evidence for the claims? Yes, I see a theoretical problem and, yes, there is sufficient argument that someone should start work on it (IETF?). However, is anyone working on it? In the meanwhile, I see no reason to bring the Internet to a screeching halt, based on the evidence thus far presented. |> To offer an analogy, what we are doing is standing in front |> of a bridge that says "Maximum Weight - Not Too Much Or It |> Might Collapse". This reminds me much of the arguments presented by D'Crock wrt the imminent collapse if only a few more TLDs were introduced. Which, in light of the volume in COM alone, was absurd. We, involved in the ICANN, are adding a bunch more than a few, with no software changes. Collapse is not expected anytime soon. Those of us running the independent root-zones have done the tests (which D'Crock was trying to forestall with such argument) and found the claims baseless and not amounting to anything more than FUD. The proof is in the new ICANN TLD roll-outs. The instance-proof was actually there all along, since NSI was running both root servers and gTLD servers on the same boxen. I am now seeing the same sort of argumentation. Only this time, the objective is to try and keep folks from being able to multi-home or otherwise achieve independence. Jeez, in both cases, the upper-level goal seemed to be the same. Why is that? BTW, I have direct evidence to the above, all the way back to the newdom list. Also, the FUD did delay things a *bunch* of years. Does this sound familiar? |> 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. Now *that* would indeed be novel. However, I suspect that the answer would be as elusive as the same answer was for the DNS. The bottom-line is that it appears to be bandwidth and hardware limited. Just like the DNS. The architecture appears to be open-ended. I must confess that I know the DNS much better than I know BGP. The projected worst-case scenario *appears* to be artificial, given the evidence at hand. It doesn't follow that what *can* happen, *will* happen. The Sun could go nova tomorrow, but I'm betting that it wont. |> So I plead with you all, lets end this war of baseless |> claims and move toward a solution, by first determining |> at what point we need one, and then determining what it is. Realistic projected usage scenarios might be a good place to start. It's amazing how real requirements have a way of actualizing the problem. Let's get the proper horse/cart relationship, first. |> TTFN, |> -chris (who happens to be a pragmatist) -roeland (who realizes that business needs drive IT, not the other way around)

2 1

Performance monitoring package utilizing Cisco SAA
by Yu Ning 29 Aug '01

29 Aug '01

Hi nanog, I wonder if there is any third part IP network performance monitoring software utilizing Cisco SAA (Service Assure Agent) feature ? The package should be able to generate and publish performance & SLA report in web style (better with historical graph, like MRTG). BTW, if not utilize Cisco SAA what do you use for your backbone performance monitoring ? Thanks for any input. Yu Ning ____________________________________________ (Mr.) Yu Ning, Chief Engineer ChinaNET(AS4134) Sr. Sup.& New Sev. R&D Internet Product Dep. DCB, China Telecom Beijing, P.R.China +86-10-62072357/62072354 ____________________________________________

1 0

What is the limit? (was RE: multi-homing fixes)
by Martin, Christian 28 Aug '01

28 Aug '01

This is the umpteenth time that this type of thread and its spawn have been religiously fought out on NANOG. The camps are split between the doomsayers (Internet armageddonists), the pragmatists, and the laisez-faire who are continually walking on sunshine. Assertions are made, flames are thrown, people dodge and parry, and the war goes on. In the end, the armageddonists fortell the end of the Internet, the pragmatists portend that a solutin must be found, and the grazers simply don't get it or don't care because there is revenue on the line in a shrinking market. What we don't see is any real data that indicates who is right and who is wrong. The only empirical data shows a comparison between routing table growth and Moore's law, which doesn't amount to a whole hill of beans if there isn't a reasonable frame of reference to which we can make comparisons. For example, what is the state of the Internet routing system today, in terms of memory utilization and processing load? Most of my routers spend a majority of their processing cycles doing a whole lot of nothing (besides crash every so often because of cosmic radiation and other stellar phenomena), have copious amounts of memory, and process a couple of thousand updates a day under steady state (no link flaps internally). Under extreme circumstances (protocol implementation bugs, filtering leaks, etc), the routers enter into a state of hary-cary, but this is rare, and independent (in most cases) of the size of the table. So they are not by any means part of the current Moore cycle, but perhaps a few generations behind. So, I sit back and evaluate the data available to me and wonder, "Where does this all break? At what point does the routing system overheat, and what steps can be taken to prevent it?" I see a lot of answers to the latter, many which I agree with, but some of which I can't make an accurate judgement until the former is answered. To offer an analogy, what we are doing is standing in front of a bridge that says "Maximum Weight - Not Too Much Or It Might Collapse". The Armageddonists have formed a picket line in front of it, the pragmatists are inspecting the beams and footings, and the grazers are driving their 18-wheelers across, honking their horns, and swigging their favorite hop-juice. 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. At the same time, we have a fifth group, call them vendors, begin design on a new bridge that has known scaling limitations that we can all agree on. 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. So I plead with you all, lets end this war of baseless claims and move toward a solution, by first determining at what point we need one, and then determining what it is. TTFN, -chris (who happens to be a pragmatist) > -----Original Message----- > From: hardie(a)equinix.com [mailto:hardie@equinix.com] > Sent: Tuesday, August 28, 2001 4:39 PM > To: david.conrad(a)nominum.com > Cc: davids(a)webmaster.com; nanog(a)merit.edu > Subject: Re: multi-homing fixes > > > > drc writes: > > Micro-allocations and filtering are treating symptoms. The > underlying > > disease (rational route announcement policy) > > > I agree with David's analysis of the problem right up to this point; > from my pespective the underlying disease is the route > convergence/routing table growth issue. The route announcement > policy's rationality has to be judged in the light of this greater > pathology. It *is* the real problem, though, and we have to keep it > in mind to understand that any invocation of market forces, draconian > filters, or community-mindedness only delays the progress of the > underlying pathology. In a sense, they too are symptoms, however > rational they may appear in today's lights. > > Or as Randy puts, we're playing whack-a-mole here, and we're doing it > knowing it only buys us time. > > The underlying problem is real, and it will take time to develop a > real solution. Encourage your vendors to participate in the > appropriate working groups, tell them you'll spend money on products > that fix it, and be ready as an operator to help debug potential > solutions. It's important. > > End of pleading.... > regards, > Ted > > (Not speaking for Equinix; speaking for David. No wait, I > meant *to* David.) > > > >

1 0