Curtis, Sean, Since these networks presumable are being announced as more specific by customers of fONOROLA/iStar.net, wouldn't it be best to try and get someone who has an interest in making it work right to do the work, stead of kicking the backbone provider? Since the prefix originator is the one who's routing is breaking, and if they can just register in the RADB to fix things, I don't really see a problem. Personally, I'd like to see this type of aggregation working more often. This seems to be the best way to get reasonable aggregation out of the "SWAMP" and the rest of the ~20,000 legacy addresses. This combined with prefix length filtering, to help "encourage" people to get address space from their providers, will greatly reduce the total number of prefixes in the IPv4, "end state" routing table. (I suspect, but don't have data to prove (YET), that the best we will be able to do with the ~20,000 is reduce it to ~10k to ~15k.). If your routers can hold then hold about 100,000 prefixes at ~4 paths per prefix, you should be pretty well off for the next year or so. I personally think that allowing /19s in 208-223 is a little too generous with router ram. (And there is the issue of what happens to 64k Cisco SSP's when forwarding tables exceed 64k)... Of course if you are using a different routing vendor, you will see slightly different resource limits.
In message <960606181706.9ede@SDG.DRA.COM>, Sean Donelan writes:
Does anyone know what's going on in Canada?
In the last couple of weeks fONOROLA/iStar.net changed how they announce aggregated networks. Now fONOROLA is sending some more specific network announcements for multi-homed networks in 198.53.0.0 with a "no-export" BGP community to MCI, and ANS.
As long as you only connect with MCI or ANS, and use their IGP, things look pretty typical because the more specifics are carried internally. But if you use BGP, the no-export means any peers with MCI won't see the more specific network announcement from MCI.
The problem shows up when you see routes from Sprintlink. A few Canadian network connect through Sprint/Canada as well as fONOROLA. The more specific networks from 198.53 are announced by Sprintlink. Since the no-export suppressed the more specific announcement to MCI BGP peers, the traffic for those Canadian sites follows the more specific network announcement and heads for Sprint.
I understand the BGP mechanics are working as specified, so it isn't "broken" per se. But I'm just wondering if Canadian sites really expect traffic to go via Stockton, California?
I haven't been able to reach anyone at fONOROLA/Istar. I was just wondering if any other North American network operators had heard what was supposed to happen last month when fONOROLA made these changes. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
Sean,
I can't speak for Istar, but I do know that they had tried to make this a painless aggregation by indicating to both ANS and MCI which prefixes were in their aggregates that did not need to be advertised outside of ANS and MCI. Istar saved some 750 prefixes. I think this is roughly half what they had previously been announcing and they have over 3500 prefixes registered, indicating a lot were already site aggregated. This is certainly commendable.
Unfortunately, since there is no way for them to know which Istar prefixes also have connectivity through Sprint or someone else (with Sprint failing to register this in the IRR), there is no way that Istar can determine that those component have to be passed on by ANS and MCI except to aggregate and see what breaks. This is the type of "information exchange" and provider cooperation through the IRR that we have been talking about that isn't universally accepted.
As this type of non-trivial aggregation becomes more common, we can expect this sort of thing to be a regular occurance unless certain other providers take the time to register things. Yes, we know it is work, but nothing near the work Istar did to get these prefixes aggregated with as little disruption as possible.
The more specific prefixes blocked by ANS and MCI are listed below. We can determine which are heard from Sprint with a routing dump and unblock them. This is the "break it, see what broke, then fix it" method, but the end result will work.
Cheers,
Curtis
-- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-339-6094 http://www.fc.net