BGP Communities as transit provider

https://www.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf

Has anyone implemented BGP communities as the transit provider to an extent like N-Layer in the above NANOG presentation? Well, on ROS, obviously.

What about passing communities through to upstreams\peers?

As typical with MT, the route filters\BGP communities section of ROS looks rather extensive, but as someone that hasn’t done it before, I don’t know how complete it is compared to other implementations. I also didn’t see a guide\howto\wiki on it. :-\

No one has done this?

We do!

We set different communities for routes learned from transit providers, local peers, and downstream customers.

We pass through some communities from downstream customers to our upstream peers and we also add some communities from upstreams to depref certain routes with certain carriers. We also use the blackhole communities when needed.

I’m just going to copy everything you do, okay? First the marketing help, now actually using communities as anything but a customer.

Do you allow your customers (say EV) to set a community tag to affect any of your upstreams\peering?

Is it convoluted to setup or fairly straight forward? I know that technically how to do everything is in the wiki, but that doesn’t mean it’s easy to figure out.

Sounds good!

We allow some, but not all, downstream customers send us communities. It depends on what our relationship is with them.

Here’s what we do:

:2001 = routes learned from transit provider 1
:2002 = routes learned from transit provider 2
:3000 = routes learned from peering partners
:4000 = routes learned from downstream customers

It is pretty easy to do with route filters. On the BGP Actions tab go down to Append BGP Communities and enter the ASN:Community you want(example 30162:3000).

Okay, I’m looking to be able to do something like customer ASN 65500 passes me a community to not advertise his routes to 174. If I have 174 as a transit or peer, great, don’t advertise there. I would also push that out to all other transit or peer connections.

Okay, so they send me a community of 174:6000, meaning they want No-Export of 174. Would this be valid? Keep in mind this is purely an educated guess.

/routing bgp peer
add disabled=yes name=Cogent out-filter=Cogent-out remote-address=0.0.0.1 remote-as=174 ttl=default
add disabled=yes name=Level3 out-filter=Level3-out remote-address=0.0.0.2 remote-as=3356 ttl=default
add disabled=yes name=AT&T out-filter=AT&T-out remote-address=0.0.0.3 remote-as=7018 ttl=default

/routing filter
add action=discard bgp-communities=174:6000 chain=Cogent-out
add bgp-communities=174:6000 chain=Level3-out
add bgp-communities=174:6000 chain=AT&T-out

You’re close…

First, you’d want to make your own community and use your ASN. Lets say your ASN is 12345.

So on your network 12345:6000 will not send routes to 174.

/routing filter
add action=discard bgp-communities=12345:6000 chain=Cogent-out disabled=no invert-match=no set-bgp-prepend-path=""

You dont need the passthrough rules for the other two peers.

You’re close…

First, you’d want to make your own community and use your ASN. Lets say your ASN is 12345.

So on your network 12345:6000 will not send routes to 174.

/routing filter
add action=discard bgp-communities=12345:6000 chain=Cogent-out disabled=no invert-match=no set-bgp-prepend-path=""

You dont need the passthrough rules for the other two peers.

So if my customer of ASN 65500 announces to me a No-Export to 174, I would then change it to my ASN in the filter rule?

Would my customer’s No-Export 174 advertisements to me just pass through me to 3356 and 7018? I thought I would have had to implicitly allow them to go through.

You would tell Mr Customer that if they want no-export to 174 then they need to add 12345:6000 to the routes they dont want exported.

That community would pass through to your other two transit providers but they wouldn’t know what to do with it. You could setup a filter rule to remove that community before sending it off to the other two providers.