A question about BGP Communities

[Mitrixsen]

Hello!

I have a question about BGP communities. I understand that communities are path attributes which are a way of tagging specific BGP route advertisements in order to ensure proper route selection policies/traffic engineering, etc.

I've seen examples of BGP policies like this from other resources
If a customer of Level 3 tags their prefixes with 3356:90 then they will set the local preference to 90. If you tag them with 64983:0 then they will prepend the AS number three times to all their BGP neighbors in Europe.

I understand how these communities work but the question is, when exactly would I want to use them in the real world? Couldn't all this traffic engineering and route selection be simply achieved by creating a

route-map

and directly changing the path attributes for our prefixes ourselves?

Does anyone please have an example of where a community would be more suitable than what I've mentioned above?

Thank you in advance for your help.

David

[M02@rt37]

Hello @Mitrixsen,

Yes, you are correct! Traffic engineering and route selection can indeed be achieved by creating

route-maps

and directly changing the path attributes for your prefixes. In fact,

route-maps

are commonly used to implement various BGP policies, such as setting local preference, modifying AS path, or manipulating MED (Multi-Exit Discriminator) values.

When you have direct control over your BGP configurations and you are peering with a limited number of providers or peers, using

route-maps

to modify path attributes is a viable option. This approach allows you to have fine-grained control over the behavior of BGP route advertisements for specific prefixes and specific BGP neighbors.

However, there are scenarios where using BGP communities can be more advantageous. First, using BGP communities can simplify your BGP configurations and make them more efficient. Instead of configuring complex

route-maps

for each prefix and each peer, you can group related prefixes and apply policies based on communities in a more centralized and streamlined manner. BGP communities provide a standardized way to communicate policies between different BGP peers, including multiple providers. This can be particularly useful when you are peering with various ISPs or exchanging routes with multiple autonomous systems. With communities, you can define policies that can be understood and implemented consistently by all peers supporting BGP communities. As your network grows and the number of prefixes and BGP peers increases, managing individual

route-maps

for each prefix-peer combination can become unwieldy. BGP communities allow you to scale your traffic engineering policies more easily by tagging prefixes with communities and applying policies based on those community tags. 

Furthermore, with BGP communities, you can make dynamic changes to your traffic engineering policies without modifying individual

route-maps

or BGP configurations. This flexibility can be valuable when you need to adjust policies frequently in response to network changes or traffic patterns. BGP communities can enable community-based actions across multiple prefixes. For example, you might want to apply specific policies to all prefixes related to a particular customer or region. Using communities, you can easily tag these groups of prefixes and apply the desired actions universally.

[Flavio Miranda · Accepted solution]

Hi @Mitrixsen 

Here an excellent source

https://www.catchpoint.com/bgp-monitoring/bgp-communities

[Joseph W. Doherty]

Think of a

cli

command passing a parameter to a system, like

show interface e0

Then consider the prior's system a BGP peer.

The

show interface

being represented by a community tag's value.

The

e0

being what a community is attached to.

Or, if you have used a calculator supporting functions, like square root, consider a specific community value representing the square root function and what the community tag is attached to as what we want the square root function applied to.

In the above two examples, there's a demarcation between client and server and a pre-agreement between client and server what can be requested.

Ditto for community tagging.

Real world examples usually abound with my AS has a pre-agreememt with other AS(s) what to do to/for routes tagged with specific community values.  Usually doings things I cannot do myself or things best done further upstream.

[Joseph W. Doherty · Accepted solution]

"Couldn't all this traffic engineering and route selection be simply achieved by creating a

route-map

and directly changing the path attributes for our prefixes ourselves?"

No.

Simple example you want to, dynamically, pass routes to a peer AS but you also don't want that peer to further propagate; how could you otherwise do this?

BTW, often there's much about AS to AS policies that go way beyond just getting packets from source to destination, usually much revolve around $$$ (often not seen by anyone outside the involved [ISP] companies).

In the reference @Flavio Miranda provided, consider all the pre-known communities.  Could you do all those yourself and/or easily without dynamic data passed between BGP peers?