[ppml] Effects of explosive routing table growth on ISP behavior
sleibrand at internap.com
Wed Oct 31 17:23:23 EDT 2007
Ted Mittelstaedt wrote:
> Suppose you have an ISP who has a /20.
> He has 3 NOCs. The first has a /21 assigned, the second and
> 3rd each have /22's, all of these are out of this /20
> The 3 NOCs are fully meshed for failover redundancy in case one
> of the providers tanks it, and he has a feed from each NOC
> to a transit provider.
> He starts out advertising the aggregate /20 to all 3 transit
> providers. But he then finds out that most of the destinations
> on the Internet favor 1 transit provider and so most of his
> traffic is coming in to 1 of the NOCs and being sent over
> the mesh failover links.
> He doesen't like this - so he splits the /20 advertisement into
> 3 advertisements, a /21 and 2 /22's and advertises all 4 out
> of each NOC, with prepending on the advertisements that are
> not for that specific NOC, (the 4th being the aggregated /20)
Good. With those advertisements, he only needs to do a couple more
things: make sure that his transit providers not only accept all those
routes from him, but also accept them from each other, and announce a
peer-level localpref community on the backup routes (in addition to the
prepending). That way, the backup link will be truly backup, and will
not receive inbound traffic from singly-homed downstream customers of
that transit provider. (All the NSPs we work with offer some form of
low-localpref community, and this is a routine current practice by our
> If the rest of the world starts filtering out his RIR-assignment
> size, then won't his load balancing go right out the window?
Not if you do peer-level localpref communities on the backup
announcements. That way, if I'm a third party network filtering at
RIR-assignment size, and I prefer transit provider 1 (like everyone
else), then my packets hit that transit provider, then get immediately
sent across the closest peering link to the preferred transit provider.
Not completely optimal, but it preserves the ISP's ability to do inbound
TE, while providing a safety valve to filter deaggregates where
necessary without losing reachability. Again, I'm not advocating anyone
start filtering just yet, but I think we need to design our policies to
ensure we don't block the safety valve.
More information about the ARIN-PPML