When to set or to add a community matters

Junos policies allow to attach communities to BGP advertisements. Communities are used to identify and categorize routes and are a key element to implement services like VPNs.

When including a community, we have two options: set or add.

With “set”, all the existing communities are cleared and only the one specified by our policy is attached.
Let’s make an example:

  • router receives a route with community A
  • router exports that route to another peer
  • an export policy is used to control advertisements towards peer
  • export policy says “community set B”
  • as result, route is advertised to peer with community B only (set clears A)

On the other hand, “add” appends the specified communities to the existing ones. This way we preserve pre-existing communities while adding new ones.

One typical question is: which one do I use?

As usual, the answer is “it depends”..or at least I thought it was 🙂

Generally, I use “set” when I no longer need existing communities and I want to “start fresh”.
For example, some communities are used to perform route control towards router A but they do not have any meaning when route is sent to router B. For this reason, it might be a good choice to use “set” and avoid to send useless communities to router B.

Similarly, if router B needed to see communities attached by router A, then i would use “add”. This approach might be useful if router B needed that information to take a choice. For instance, router B, due to SP policies, may prefer to discourage routes that went through router A. Maybe, that could be done by checking the AS Path but, if not possible, relying on communities is a great option.

Looking at those examples, it really seems that “Add or set? It depends”

But that is not always the case.

I was recently configuring a L2VPN (pseudowire).

My export policy was:

root@pe1> show configuration policy-options policy-statement l2vpn-export
term ok {
    then {
        community set l2vpn;
        accept;
    }
}
then reject;

Route is advertised to RR (which reflects it to other PEs) and it includes community l2vpn only (route target):

l2vpn.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

*  1.1.1.1:201:1:3/96 (1 entry, 1 announced)
 BGP group rr type Internal
     Route Distinguisher: 1.1.1.1:201
     Label-base: 800006, range: 2, status-vector: 0x0, offset: 3
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] I
     Communities: target:200:1

Everything seems ok but, then, I move to remote PE and check l2vpn connections:

root@pe4> show l2vpn connections
Layer-2 VPN connections:

...

Instance: l2vpn-internet
Edge protection: Not-Primary
  Local site: SRX (3)
No connections found.

No circuits found!

When it happened I was a bit lost. I thought of everything: encapsulation error, routing instance missing parameters, etc…

Then I was told to use “add” instead of “set”:

root@pe1> show configuration policy-options policy-statement l2vpn-export
term ok {
    then {
        community add l2vpn;
        accept;
    }
}
then reject;

Let’s check how route is advertised to RR:

l2vpn.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

*  1.1.1.1:201:1:3/96 (1 entry, 1 announced)
 BGP group rr type Internal
     Route Distinguisher: 1.1.1.1:201
     Label-base: 800006, range: 2, status-vector: 0x0, offset: 3
     Nexthop: Self
     Flags: Nexthop Change
     Localpref: 100
     AS path: [100] I
     Communities: target:200:1 Layer2-info: encaps: VLAN, control flags:[0x0] , mtu: 0, site preference: 100

What a change!

Look at the communities field 🙂 Along with the RT, we have other communities like encapsulation, mtu, site preference (for multihoming) and mtu.
All those additional communities are system generated and are needed by remote PEs in order to build the pseudowire.

By using “set” we clear those system generated communities and break pseudowire establishment!.

Now, remote PE can build the l2vpn:

Instance: l2vpn-internet
Edge protection: Not-Primary
  Local site: SRX (3)
    connection-site           Type  St     Time last up          # Up trans
    1                         rmt   Up     Sep 28 01:50:51 2021           1
      Remote PE: 1.1.1.1, Negotiated control-word: No
      Incoming label: 800008, Outgoing label: 800006
      Local interface: ge-0/0/5.200, Status: Up, Encapsulation: VLAN
      Flow Label Transmit: No, Flow Label Receive: No

So back to our question…”add or set?”…here, definitely add 🙂

Ciao
IoSonoUmberto

Leave a comment