The way I do it is use an internal community for my policies, and then overwrite it when I hand it over to the Transit provider, so it matches the upstream policy.
Far easier than renumbering the AS number across the live network :) On 16 March 2015 at 17:13, Nick Hilliard <[email protected]> wrote: > On 16/03/2015 17:03, David Wilkinson wrote: > > I am looking at setting up some BGP communities and I was wondering what > is > > the correct/recommended way to do communities with a 32-bit ASN? > > > > Obviously I can't use the asn:nn format with our 32-bit ASN, So would I > use > > private ASNs or AS23456 or should I be looking at using extended > communities? > > > > I am looking at doing the usual stuff adding communities to incoming > routes > > from transits, peers, customers. Allowing customers to block > announcements > > out via a transit provider/peer. Setting up a black hole community, etc > > The shorter answer is that you are far better off renumbering your ASN. > It's painful, but it's a lot less painful than pretending you can fix this > on your network and realising later on deciding that this is pointless and > then renumbering. > > The longer answer is that the IETF has not yet dealt with this situation > and the various working groups involved are in mild to total denial that a > problem exists. Extended BGP communities have been put forward as a > candidate (RFC 5668), but support on router platforms is fairly limited at > the moment. It also only support 32b:16b style ASNs, so if you plan to > use the local administrator field for anything, then you'd better be able > to fit it into 16 bits. There is some talk about a kitchen sink BGP > community mechanism (draft-raszuk-wide-bgp-communities), but in the last 4 > years it hasn't progressed beyond talk. > > Nick > > >
