[Community bleaching on edge] RTBH no_export
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, On Wed, Feb 06, 2019 at 01:53:48PM -0000, adamv0025@netconsultings.com wrote:
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" https://tools.ietf.org/html/rfc7454#section-11 "In general, the intended audiences of Informational Communities are downstream networks and the GA itself, but any AS could benefit from receiving these communities." https://tools.ietf.org/html/rfc8195#section-2.1
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
On Wed, 6 Feb 2019 at 13:55, <adamv0025@netconsultings.com> wrote:
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…
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.
participants (3)
-
adamv0025＠netconsultings.com -
James Bensley -
Job Snijders