The post about BGP community strings on Junos received a comment about difficulties removing large BGP communities.
This is a response to that comment, to see what works.
BGP Large communities are defined in RFC 8092, which defines them as a 12-octet, or byte, structure. It is split into three groups of four octets:
- Global Administrator: A namespace identifier, typically an AS number
- Local Data Part 1: An operator-defined value
- Local Data Part 2: An operator-defined value
In Junos, we can define these as follows:
set policy-options community cm-test-large-1 members large:65002:100:200Lab Setup
All of the examples that follow are based on the following lab diagram.
The vMX-1 and vMX-2 devices have a simple eBGP configuration between them. Both are running Junos 20.4R3.
VMX-2 is advertising four routes. These are 192.168.1.0/24 through 192.168.4.0/24 and do not have any communities attached.
The relevant configuration is shown below.
vMX-1:
lab@vMX-1> show configuration protocols bgp
group external-group {
type external;
peer-as 65002;
neighbor 10.100.1.2;
}
lab@vMX-1>vMX-2:
lab@vMX-2> show configuration protocols bgp
group external-group {
type external;
export advertise-static;
peer-as 65001;
neighbor 10.100.1.1;
}
lab@vMX-2> show configuration policy-options policy-statement advertise-static
term statics {
from {
protocol static;
route-filter 192.168.0.0/16 orlonger;
}
then accept;
}
term final {
then reject;
}
lab@vMX-2>On vMX-1, we have received the four routes, and there are no communities attached.
lab@vMX-1> show route protocol bgp detail | match "entry|Communities"
192.168.1.0/24 (1 entry, 1 announced)
192.168.2.0/24 (1 entry, 1 announced)
192.168.3.0/24 (1 entry, 1 announced)
192.168.4.0/24 (1 entry, 1 announced)
lab@vMX-1>Adding Large Communities
This step is being performed on vMX-2. We will tag each route with a different community.
In the following commands, we define the new large communities.
lab@vMX-2> edit
Entering configuration mode
[edit]
lab@vMX-2# set policy-options community comm-large-1 members large:65002:100:10
[edit]
lab@vMX-2# set policy-options community comm-large-2 members large:65002:100:20
[edit]
lab@vMX-2# set policy-options community comm-large-3 members large:65002:200:30
[edit]
lab@vMX-2# set policy-options community comm-large-4 members large:65002:200:40
[edit]
lab@vMX-2#After defining the communities, the advertise-statics policy is updated, so it now looks like this:
[edit]
lab@vMX-2# show policy-options policy-statement advertise-static
term add-comm-1 {
from {
protocol static;
route-filter 192.168.1.0/24 exact;
}
then {
community add comm-large-1;
}
}
term add-comm-2 {
from {
protocol static;
route-filter 192.168.2.0/24 exact;
}
then {
community add comm-large-2;
}
}
term add-comm-3 {
from {
protocol static;
route-filter 192.168.3.0/24 exact;
}
then {
community add comm-large-3;
}
}
term add-comm-4 {
from {
protocol static;
route-filter 192.168.4.0/24 exact;
}
then {
community add comm-large-4;
}
}
term statics {
from {
protocol static;
route-filter 192.168.0.0/16 orlonger;
}
then accept;
}
term final {
then reject;
}
[edit]
lab@vMX-2#The first four terms match the individual static routes and attach a community string to them, but do not accept or reject the route, allowing it to fall through to the other terms. The term ‘statics’ is where the routes are accepted to be advertised to vMX-1.
On the vMX-1 router, we can now see that the routes have community strings attached to them.
lab@vMX-1> show route protocol bgp detail | match "entry|Communities"
192.168.1.0/24 (1 entry, 1 announced)
Communities: large:65002:100:10
192.168.2.0/24 (1 entry, 1 announced)
Communities: large:65002:100:20
192.168.3.0/24 (1 entry, 1 announced)
Communities: large:65002:200:30
192.168.4.0/24 (1 entry, 1 announced)
Communities: large:65002:200:40
lab@vMX-1>Deleting Large Communities Using A Specific Community
In the first test, I have added the communities to vMX-1 with the same names and created a policy to match the 192.168.1.0/24 route and remove the community large:65002:100:10.
[edit]
lab@vMX-1# show policy-options
policy-statement bgp-remove-comms {
from {
route-filter 192.168.1.0/24 exact;
}
then {
community delete comm-large-1;
}
}
community comm-large-1 members large:65002:100:10;
community comm-large-2 members large:65002:100:20;
community comm-large-3 members large:65002:200:30;
community comm-large-4 members large:65002:200:40;
[edit]
lab@vMX-1# show protocols bgp
group external-group {
type external;
import bgp-remove-comms;
peer-as 65002;
neighbor 10.100.1.2;
}
[edit]
lab@vMX-1#
This has removed the community from the 192.168.1.0/24 route, as shown below.
lab@vMX-1> show route protocol bgp detail | match "entry|Communities"
192.168.1.0/24 (1 entry, 1 announced)
192.168.2.0/24 (1 entry, 1 announced)
Communities: large:65002:100:20
192.168.3.0/24 (1 entry, 1 announced)
Communities: large:65002:200:30
192.168.4.0/24 (1 entry, 1 announced)
Communities: large:65002:200:40
lab@vMX-1>Deleting Large Communities Using A Wildcard Community
The policy has been changed to match all routes from 192.168.0.0/16 and remove the community strings by using a wildcard match.
lab@vMX-1# show policy-options
policy-statement bgp-remove-comms {
term delete-all-comms {
from {
route-filter 192.168.0.0/16 orlonger;
}
then {
community delete regular-wildcard;
}
}
}
community comm-large-1 members large:65002:100:10;
community comm-large-2 members large:65002:100:20;
community comm-large-3 members large:65002:200:30;
community comm-large-4 members large:65002:200:40;
community regular-wildcard members *:*;
[edit]
lab@vMX-1#
The wildcard string of *:* seems to match all the large community strings, as well as matching all regular community strings.
lab@vMX-1> show route protocol bgp detail | match "entry|Communities"
192.168.1.0/24 (1 entry, 1 announced)
192.168.2.0/24 (1 entry, 1 announced)
192.168.3.0/24 (1 entry, 1 announced)
192.168.4.0/24 (1 entry, 1 announced)
lab@vMX-1>
Next, let’s try it with a large wildcard community. The policy has been updated as shown below.
[edit]
lab@vMX-1# show policy-options
policy-statement bgp-remove-comms {
term delete-comms-with-200 {
from {
route-filter 192.168.0.0/16 orlonger;
}
then {
community delete large-wildcard-match-200;
}
}
}
community comm-large-1 members large:65002:100:10;
community comm-large-2 members large:65002:100:20;
community comm-large-3 members large:65002:200:30;
community comm-large-4 members large:65002:200:40;
community large-wildcard-match-200 members large:*:200:*;
community regular-wildcard members *:*;
[edit]
lab@vMX-1#
The intent is to remove communities with
‘200’ between the two colons. We have a new community string, and the policy statement has been updated.
lab@vMX-1> show route protocol bgp detail | match "entry|Communities"
192.168.1.0/24 (1 entry, 1 announced)
Communities: large:65002:100:10
192.168.2.0/24 (1 entry, 1 announced)
Communities: large:65002:100:20
192.168.3.0/24 (1 entry, 1 announced)
192.168.4.0/24 (1 entry, 1 announced)
lab@vMX-1> The match works as expected – removing the community strings from 192.168.3.0/24 and 192.168.4.0/24.
Conclusion
Large communities largely behave the same as regular communities. The methods of adding, matching, and deleting them are the same.