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: [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
