BGP4 on a /20

Phil Howard phil at
Thu Sep 18 23:22:19 UTC 1997

I'm trying to understand what all the implications of running BGP4 on
a network with a prefix longer than 19 bits.  Here are some of the points
I am thinking about.


If I go ahead and announce a /20 via two backbones, one of which is
the provider of the address space, then there will be redundant routes
for this space as the backbone provider will be announcing the /19
(or shorter) block themselves.

If I do this, it adds to the routing table glut, among other things.
The advantage gained is questionable.  If my link to the provider that
the space comes from goes down, they are still announcing and I'll only
be able to reach where my path via the alternate provider is shorter
than the path to the down provider itself.


If the provider were to be convinced to stop announcing for my /20,
then I'm going to get filtered at Sprint and AGIS and whoever else
is doing this and there won't be any /19 announcement that I can use
a default path on.

But the real catch here is that for the provider to stop announcing
my /20 they have to split their /19 into two /20's.  And if that was
really a /18 that means they will be announcing a /19 and a /20 where
before only a /18.  This gets worse the larger their block was.

Even worse than that, by doing this, they now have a /20 (the other
half of the /19 my /20 is in) with other customers who will now also
be filtered out at Sprint and AGIS and whoever else.  While it can be
OK to me if I want to give up that reachability, this is also imposing
this on the other customer(s) in the other /20.  So that provider is
not even likely to do that.

So, should I add to the glut of routes or should I add to the glut of

This needs to be simpler.


Phil Howard  +-------------------------------------------------------------+
KA9WGN       | House committee changes freedom bill to privacy invasion !! |
phil at      | more info:,4,14180,00.html | +-------------------------------------------------------------+

More information about the NANOG mailing list