![nanog logo](/images/nanog-logo.png)
nanog mailing list archives
Re: The Cidr Report
From: "Warren Kumari, Ph.D, CCIE# 9190" <warren () kumari net>
Date: Sun, 13 Feb 2005 20:57:42 -0500
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 13, 2005, at 6:19 PM, Christopher L. Morrow wrote:
On Sun, 13 Feb 2005, Michael Smith wrote:From: "Warren Kumari, Ph.D, CCIE# 9190" <warren () kumari net> On Feb 13, 2005, at 2:31 AM, Christopher L. Morrow wrote: 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 theaggregate because <some undefined bad thing> will happen, usually justified with much hand-waving. The people who do this can usually not be reasoned with....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 specificMeaning you have PA space from UUNET, and you have BGP so you can multi-home... I'd expect you to know how to deaggregate yourself. YouMIGHT even know how to send no-export on deaggregated prefixes, or use the1996 policies to influence preferences/prepends internal to 701, yes?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 /22for some time.I'm not clear as to how the /22 to /20 discussion goes, or how it's evenrelevant... but it's been a long day. Can you elaborate?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 cluea /22 in both directions seems like safe 'redundancy'. Adding no-export/24's or /32's if you want (yuck) would get you more preference inside oneprovider or the other.I'm also fairly sure I didn't say: "bad" or "uniformed" the 'bad provider'is from Warren, not I.
Whoops, I guess I wasn't very clear. By $good_provider and $bad_provider I wasn't meaning to imply that $good_provider ran their network "better" or "cleaner" than $bad_provider, merely that (by default and without tuning) more traffic travels via $good_provider than via $bad_provider (e.g. $bad_provider buys transit from $good_provider). I guess I should have used big_provider and little_provider or something.
impaired? Do we just say "too bad, routing table bloat is more importantthan your need for redundancy small guy!"?
No, I don't think anybody was saying that, just that many people are needlessly de-aggregating space. I have seen someone with a single T3 (and obviously a single provider!) announcing his PA /19 as a bunch of /24s, redistributed into BGP from OSPF! Some consultant had come in, set it up and left. After a bit of help, said person turned off BGP and has been running fine ever since. No-one was trying to take away your redundancy, just limit the number of unnecessary announcements. See Chris's comments above on how to get redundancy without making others pay for it....
I think that folks have been pushed toward multihoming with multipleproviders (not just 'redundant T1' or 'shadow T1' services inside the sameprovider) over the last few years. That means some bloat is bound to occur. I'm not measuring it myself, but the renesys folks and LCS folks have been I think? Perhaps they can comment on that phenomenon?I find it interesting that the general theme is one of "we're smarter thanthey are because we aggregate more routes" as if clue were directly correlated to aggregated routing announcements.
Well, often lack of aggregation is directly caused by lacy of clue. Obviously there are legitimate reasons for de-aggregating a big block (otherwise we would all just carry 0/0 :-) ) but if there is no additional information in the more specifics, then there is no reason for them the be announced.
it's not? :) (joking of course) As I said before some folks feel they have a legitimate reason for deaggregating. If you can spend some time chattingthem up about their reasons and either: 1) realizing they hav a point2) re-purpose their thoughts toward 'better cidr management' (as pfs said)then good for you... and everyone else :) I have spent sometime onoccasion doing this, sometimes it works out, othertimes it doesn't :( It'salways an experience though.
It certainly is...
- -- Militant Agnostic--I don't know and you don't either!-Chris
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCEAWZHSkNr4ucEScRAoz3AKD6qP+le+n38KEodea6WsoWB/av9gCdH/bu 4YG3VVrMNd/61Lr5ZZBgnRY= =/Ebs -----END PGP SIGNATURE-----
Current thread:
- Re: The Cidr Report, (continued)
- Re: The Cidr Report Vinny Abello (Feb 12)
- Re: The Cidr Report Christopher L. Morrow (Feb 12)
- Re: The Cidr Report Alexander Koch (Feb 13)
- Re: The Cidr Report Christopher L. Morrow (Feb 13)
- RE: The Cidr Report Justin Ryburn (Feb 13)
- RE: The Cidr Report Stephen J. Wilcox (Feb 13)
- Re: The Cidr Report Warren Kumari, Ph.D, CCIE# 9190 (Feb 13)
- Re: The Cidr Report Stephen J. Wilcox (Feb 13)
- Re: The Cidr Report Michael Smith (Feb 13)
- Re: The Cidr Report Christopher L. Morrow (Feb 13)
- Re: The Cidr Report Warren Kumari, Ph.D, CCIE# 9190 (Feb 13)
- Re: The Cidr Report Stephen J. Wilcox (Feb 13)
- Re: The Cidr Report Philip Smith (Feb 12)
- Re: The Cidr Report Jerry Pasker (Feb 12)
- Re: The Cidr Report Aaron Hopkins (Feb 13)
- Re: The Cidr Report Patrick W Gilmore (Feb 13)
- Re: The Cidr Report Mark Prior (Feb 14)
- Re: The Cidr Report Marc Binderberger (Feb 11)
- RE: The Cidr Report Neil J. McRae (Feb 12)
- Re: The Cidr Report Hank Nussbacher (Feb 12)