[c-nsp] /18 and multihomed BGP

[Robert Lister]

On Thu, 2010-08-12 at 15:21 +0300, RAZAFINDRATSIFA Rivo Tahina wrote:
> Hi all,
> 
> I'm BGP multihomed with 2 ISPs and have a /18 subnet.
> I declared the /18 block in RIPE database as 64 /24.
> I'm adding a new ISP and he asked me to modify the 64 /24 in RIPE to 
> a unique /18.

The RIPE database is probably a policy requirement of your new ISP, but
it does not necessarily reflect what you are actually announcing with
BGP. (It should do) Are you announcing, at the moment, one /18 or 64
x /24 with BGP? You could probably keep the /24s but add a route: object
for the /18 if it's not there already.

> How does this change affect the existing routing with 2 former ISPs?
> How can I announce a /24 prefix from one ISP to another? He is 
> talking about "no export", what is the purpose of this attribute?

If you have no technical reason to de-aggregate your /18 then you should
not announce lots of /24s, but one /18.

Announce the whole /18, regardless of the RIPE assignment status.

If you want to set things so that you announce more specific /24s to one
ISP, but not others for traffic reasons then you will have to announce
more specific /24s, this de-aggregation is not the best situation but
sometimes unavoidable. (The argument of routing table size vs. IP
address resource efficiency comes to mind!) So you either de-aggregate
when needed (more routes in the global routing table), 
or request more blocks from RIPE (and possibly have a difficult time
justifying!)

no-export is a well known community that you can set on outbound BGP
prefixes to your transits/peers so that, although you may be announcing
a bunch of more specific /24 to them, they will not re-announce these
outside of their AS. 

This is not going to be much use unless you have more than one
connection to the same AS, for example two transit connections to the
same provider at different locations, and you want to tell that provider
that "for these /24s, prefer this router.... for these /24s, prefer that
router" but they don't re-announce this information outside, because
it's only relevant to them.

(Unless your new transit provider is using a script to build BGP filters
from the information in the RIPE database, and so it sees a lot of /24s
as well as the /18, but they don't want to announce all the /24s. 
Setting no-export on the /24s would fix this without them having to
hack/fix their scripts, or manually changing the policy for you.)

If you set no-export on the more specific /24 routes, then by default
they should be received but not announced anywhere external by your
transit provider. (That is, if your transit provider is not deleting
your communities!)

If you have lots of different transit providers with only a single
connection to each, then no-export isn't going to be of much use. 
You are probably either going to have to announce prefixes to 
them or not.

Obviously you would NOT set no-export on the covering /18 route, as this
is what you want them to announce to the rest of the world.

Rob


-- 
Rob Lister
NetSumo Limited
D: +44 (0) 20 7993 1707
S: +44 (0) 20 7993 1700
E: rob.lister at netsumo.com