Hi folks,
This “RTBH no_export” thread made me wonder what is the latest view on BGP community bleaching at the edge (in/out).
Anyone filtering extended RT communities inbound on NOSes that accept extended communities by default? Yeah about that…
adam
Hi Adam,
This "RTBH no_export" thread made me wonder what is the latest view on
BGP community bleaching at the edge (in/out).
At NTT/AS 2914 we took a look at BGP community bleaching recently. We
intend to deploy something along these lines on EBGP sessions with
non-customer peering partners:
LEAVE 65535:0 # allow graceful_shutdown
LEAVE $Peer_ASN:* # Allow peer's communities, these have no effect in NTT
DELETE *:* # delete the rest, including other well-known communities
(The last 'delete' line also implicitly removes things like 0:*, 2914:*,
23456:*, etc. Note that for customer facing EBGP sessions, we have a
different, more relaxed, policy.)
The thinking was that our customers can potentially benefit from BGP
communities set by our peering partners, but we also have to take BGP
UPDATE packing and memory utilisation into consideration.
IETF participants have written some snippets on the topic of BGP
community bleaching:
"Networks administrators SHOULD NOT remove other communities applied
on received routes" RFC 7454 - BGP Operations and Security
"In general, the intended audiences of Informational Communities are
downstream networks and the GA itself, but any AS could benefit from
receiving these communities."
RFC 8195 - Use of BGP Large Communities
Anyone filtering extended RT communities inbound on NOSes that accept
extended communities by default? Yeah about that.
I'd be hesitant to filter/scrub BGP Path Attributes that have no meaning
in your network, it may stiffle innovation somewhere.
Kind regards,
Job
Hi Adam,
I think Junos is an example of a NOS that advertises extended BGP
communities by default (and accepts them without scrubbing). It seems
"not ideal" to me (by which I mean there could be potential for BGP
NLRIs to be processed in an undesired way). However, I think that
ext-comm information sent in NLRI UPDATES over an AFI/SAFI 1/1 or 2/1
session aren't processed.
I haven't got the time to lab this right now but, I guess one question
would be if (for example) a CPE sends a BGP UPDATE over an 1/1 or 2/1
session into a PE inside a VRF, with ext comm attached, when the
UPDATE is advertised to another PE over a 1/128 or 2/128 session will
that remote PE process the ext-comm value the CPE sent to the initial
PE in the 1/1 or 2/1 session? What if that CPE was in instead a
transit or peering partner and you're running an Internet-in-a-VRF
design, can anyone on the Internet send routes into your edge PE and,
with the correct ext-comm, have them importing into another L3 VPN?
Cheers,
James.