|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: The Cidr Report
On Sun, 13 Feb 2005, Michael Smith wrote: > > From: "Warren Kumari, Ph.D, CCIE# 9190" <[email protected]> > > Date: Mon, 14 Feb 2005 10:14:38 -0500 > > To: <[email protected]> > > Subject: Re: The Cidr Report > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: > > > >> On Sat, 12 Feb 2005, Alexander Koch wrote: > >> > >>> On Sat, 12 February 2005 14:58:42 +0000, Stephen J. Wilcox wrote: > >>>> From: "Stephen J. Wilcox" <[email protected]> > >>>> [...] - would you agree that most of the poor deaggregating is not > >>>> intentional > >>>> ie that they're announcing their '16 class Cs' or historically had 2 > >>>> /21s and > >>> > >>> Think about someone putting in a Null0 route and re- > >>> exporting stuff unconditionally, now after he originates > >>> his /19 he is then adding a /24 here, and a /25 there. > >>> Lack of experience, when you suggest to them they should > >>> remove these announcements they are afraid to change it, > >>> not understanding the implications, etc. > >>> > >>> Not to mention ppl using cisco and prefix lists, it is > >>> way too easy with cisco to say '/19 le 24', and then they > >>> use outbound prefix lists to their transit supplier > >>> (different, but related as I see it). Some transit ISPs > >>> use that a lot, and encourage the table growth. > >> > >> There are some business reasons to de-aggregate. Look at some outages > >> caused by 'routing problems' (someone leaked my /24's to their peers, > >> peers, peer and my traffic got blackholed, because the public net only > >> knows me as a /20) > >> > >> There are multiple reasons for deaggregation aside from 'dumb > >> operator', > >> some are even 'valid' if you look at them from the protection > >> standpoint. > >> > >> -Chris > > > > That and the "I have 1 circuit to $good_provider and 1 circuit to > > $bad_provider and the only way I can make them balance is to split my > > space in half and announce more specifics out through each provider" > > argument. I have also often seen people do this without announcing the > > aggregate because <some undefined bad thing> will happen, usually > > justified with much hand-waving. The people who do this can usually > > not be reasoned with.... > > > > It happens all the time... > > > > Warren. > > So, say I'm a provider that has received a /22 from UUNet (just for example > Chris :-) ) and I now get another transit provider and announce the /22 > there. So, I call UUNet and ask them to announce the /22 as a more specific > because I don't want a de-facto asymmetric configuration. I *want* to get a > /20 from ARIN but my usage doesn't justify it yet, so I have to ride the /22 > for some time. Hi Mike, this isnt the scenario being discussed. The scenario of issue is where you get your /22 from UUNET and announce 4x /24 ie based on what ips you have you choose to announce more than the minimum to make them routable > By the long string of anecdotal attacks in the string to date, listing most or > all such providers as "bad" or "uninformed" how do you separate out those > providers who are legitimately interested in routing redundancy and not clue > impaired? Do we just say "too bad, routing table bloat is more important than > your need for redundancy small guy!"? As I say this isnt the issue here, altho what you suggest would be an example of further aggregation that i personally think is extreme. Multihoming must be possible and a hierarchical structure to the internet is not appropriate. > I find it interesting that the general theme is one of "we're smarter than > they are because we aggregate more routes" as if clue were directly correlated > to aggregated routing announcements. Well, there does seem to be some loose correlation it cant be denied... (counter examples not required, we know they exist) Steve
|