BGP community strings are widely used in routing policy. In this post we’re going to look at:
- How to define community strings.
- How to add and remove community strings from a route
- How to match on community strings attached to a route.
Lab Setup
All of the examples that follow are based on the following lab setup.
VMX-2 is advertising the following routes to vMX-1.
| Route | Community Strings |
| 172.16.0.0/24 | 65001:100 65002:50 |
| 172.16.1.0/24 | 65001:200 65003:6789 |
| 172.16.2.0/24 | 65001:300 65002:50 |
| 172.16.3.0/24 | 65001:400 65003:9876 |
| 172.20.0.0/24 | 12345:100 large:4200000000:1000:70 |
| 172.20.1.0/24 | 12345:200 large:4200000000:2000:70 |
| 172.20.2.0/24 | 12345:54321 large:65550:20:100 |
| 172.20.3.0/24 | 12345:45123 no-export |
Initially, vMX-1 and vMX-3 have no BGP policy applied. This results in vMX-1 advertising all of its BGP routes to vMX-3, except for one with the no-export community set.
A Note On Default Behavior
Junos advertises community strings to eBGP neighbors by default, there is no specific configuration required for this. The route 172.20.3.0/24 is not advertised from vMX-1 to vMX-3 because it has the no-export community set.
How To View Community Strings On A Route
Before we start working with communities, we should work out how to view what communities are attached to a route.
In Junos, this can be seen by showing the detailed route output.
lab@vMX-1> show route 172.16.1.0/24 detail
inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
172.16.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0xc3a4cf8
Next-hop reference count: 16
Source: 10.100.1.2
Next hop type: Router, Next hop index: 587
Next hop: 10.100.1.2 via ge-0/0/1.0, selected
Session Id: 0x140
Protocol next hop: 10.100.1.2
Indirect next hop: 0xc659384 1048574 INH Session ID: 0x141
State: <Active Int Ext>
Local AS: 65001 Peer AS: 65001
Age: 7:18 Metric2: 0
Validation State: unverified
Task: BGP_65001.10.100.1.2
Announcement bits (3): 0-KRT 2-BGP_RT_Background 3-Resolve tree 1
AS path: I
Communities: 65001:200 65003:6789
Accepted
Localpref: 100
Router ID: 192.168.0.2
Thread: junos-main
lab@vMX-1>We can use the Junos CLI to make this output a bit more readable by matching on lines with ‘entry’ or ‘Communities’.
lab@vMX-1> show route protocol bgp detail | match "entry|Communities"
172.16.0.0/24 (1 entry, 1 announced)
Communities: 65001:100 65002:50
172.16.1.0/24 (1 entry, 1 announced)
Communities: 65001:200 65003:6789
172.16.2.0/24 (1 entry, 1 announced)
Communities: 65001:300 65002:50
172.16.3.0/24 (1 entry, 1 announced)
Communities: 65001:400 65003:9876
172.20.0.0/24 (1 entry, 1 announced)
Communities: 12345:100 large:4200000000:1000:70
172.20.1.0/24 (1 entry, 1 announced)
Communities: 12345:200 large:4200000000:2000:70
172.20.2.0/24 (1 entry, 1 announced)
Communities: 12345:54321 large:65550:20:100
172.20.3.0/24 (1 entry, 1 announced)
Communities: 12345:45123 no-export
lab@vMX-1>How To Define BGP Community Strings
On Junos, communities are defined under ‘policy-options’ and can have more than one community string specified.
The general format of the command to set a community string is:
set policy-options community <name> members <community-id>
or, if you want to specify multiple community ids:
set policy-options community <name> members [ <community-id> <community-id> <community-id> ]
Below are some basic examples of configuring various types of community strings.
## Define a community with a standard community string
[edit]
lab@vMX-1# set policy-options community comm-customers members 65001:100
## Define a community with two standard community strings
[edit]
lab@vMX-1# set policy-options community comm-customers-peers members [ 65001:100 65001:200 ]
## Define a community with one large community string
[edit]
lab@vMX-1# set policy-options community comm-large-string members large:420000000:1000:70
## Define a community with one extended community string
[edit]
lab@vMX-1# set policy-options community comm-extended-target members target:65001:100
[edit]
lab@vMX-1# set policy-options community comm-extended-origin members origin:65001:100 If we show the policy-options stanza, it now looks like this:
[edit]
lab@vMX-1# show policy-options
community comm-customers members 65001:100;
community comm-customers-peers members [ 65001:100 65001:200 ];
community comm-extended-origin members origin:65001:100;
community comm-extended-target members target:65001:100;
community comm-large-string members large:420000000:1000:70;
[edit]
lab@vMX-1#How To Add And Remove Community Strings From A Route
To add or remove communities, a modifying action is used under the ‘then’ clause of a policy term.
The available options are
- set – Set the communities for the route to the one specified. Removes existing communities.
- add – Adds the specified community to the route, any existing communities are unchanged.
- delete – Deletes the specified community from the route.
Example 1 – Add, Set, And Delete Communities
In this example, we will use route filters to identify specific routes and:
- Set community 65001:8000 on route 172.16.0.0/24
- Add community 65001:9000 on route 172.16.1.0/24
- Delete community 65002:50 from route 172.16.2.0/24
First, we define the community strings and policy on vMX-1.
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term setting-community {
from {
route-filter 172.16.0.0/24 exact;
}
then {
community set comm-new-1;
}
}
term adding-community {
from {
route-filter 172.16.1.0/24 exact;
}
then {
community add comm-new-2;
}
}
term deleting-community {
from {
route-filter 172.16.2.0/24 exact;
}
then {
community delete comm-65002-50;
}
}
}
policy-statement test {
term 1 {
from community comm-customers;
}
}
community comm-65002-50 members 65002:50;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
[edit]
lab@vMX-1#Then we apply the policy as an export against vMX-3.
[edit]
lab@vMX-1# show protocols bgp
group internal {
type internal;
peer-as 65001;
neighbor 10.100.1.2;
}
group as65005 {
type external;
peer-as 65005;
neighbor 10.100.2.2 {
export export-vMX3;
}
}
[edit]
lab@vMX-1#Here are the routes on vMX-3 before the policy is applied.
lab@vMX-3> show route 172.16.0.0/24 detail | match Comm
Communities: 65001:100 65002:50
lab@vMX-3> show route 172.16.1.0/24 detail | match Comm
Communities: 65001:200 65003:6789
lab@vMX-3> show route 172.16.2.0/24 detail | match Comm
Communities: 65001:300 65002:50
lab@vMX-3>And now after the policy is applied.
lab@vMX-3> show route 172.16.0.0/24 detail | match Comm
Communities: 65001:8000
lab@vMX-3> show route 172.16.1.0/24 detail | match Comm
Communities: 65001:200 65001:9000 65003:6789
lab@vMX-3> show route 172.16.2.0/24 detail | match Comm
Communities: 65001:300
lab@vMX-3>This helps show the difference between the ‘set’ and ‘add’ options. Choosing the wrong one could have unintended consequences for your policy.
Example 2 – Adding Two Or More Communities
If you want to add more than one community string, you need to use multiple ‘community add’ actions. If we change the ‘adding-community’ term, we can see this in action.
The policy now looks like this:
[edit]
lab@vMX-1# show policy-options policy-statement export-vMX3
term setting-community {
from {
route-filter 172.16.0.0/24 exact;
}
then {
community set comm-new-1;
}
}
term adding-community {
from {
route-filter 172.16.1.0/24 exact;
}
then {
community add comm-new-2;
community add comm-new-1;
}
}
term deleting-community {
from {
route-filter 172.16.2.0/24 exact;
}
then {
community delete comm-65002-50;
}
}
[edit]
lab@vMX-1#If we check on vMX-3, we can see it now has two additional communities added to 172.16.1.0/24.
lab@vMX-3> show route 172.16.1.0/24 detail | match Comm
Communities: 65001:200 65001:8000 65001:9000 65003:6789
lab@vMX-3> Example 3 – Deleting All Communities From A Route
How do you delete all the community strings from a route? The answer is to use a community that uses a regular expression as a match. This will be explained in more detail in the matching on community strings section below.
For now, we need to set a community that matches all possible community strings and change our policy to use this new community.
For this example, we will remove all community strings from 172.16.0.0/24 before advertising it to vMX3.
Our policy options stanza on vMX-1 now looks like this:
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term delete-all-communities {
from {
route-filter 172.16.0.0/24 exact;
}
then {
community delete comm-all;
}
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
[edit]
lab@vMX-1#Looking at the 172.16.0.0/24 route on vMX-3, there are no community strings set.
lab@vMX-3> show route 172.16.0.0/24 detail | match Comm
lab@vMX-3>How To Match On Community Strings
Now that we know how to put a community string on a route, how do we match routes based on community strings?
In the following examples, we’re going to get vMX-1 to match routes based on communities and advertise those routes to vMX-3. All other routes will be rejected.
Example 4 – Match On A Specific Community
To match just one community, we specify it as a match in the ‘from’ portion of a policy term.
In this example, we match on just 65001:100. The policy on vMX-1 is updated as follows:
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community comm-customers;
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-customers members 65001:100;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
[edit]
lab@vMX-1#On vMX-3, we now only have one BGP route.
lab@vMX-3> show route protocol bgp
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 00:00:03, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.16.0.0/24 (1 entry, 1 announced)
Communities: 65001:100 65002:50Example 5 – Match On Two Communities
In this example, we want to match on routes that have both community 65001:100 and 65002:50.
Based on the example of adding multiple communities, you may think we need to specify two communities in the from clause. This doesn’t work, but is shown below. The updated policy on vMX-1 is:
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community [ comm-customers comm-65002-50 ];
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-customers members 65001:100;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
[edit]
lab@vMX-1#We see two routes on vMX-3.
lab@vMX-3> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 00:06:46, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.16.2.0/24 *[BGP/170] 00:00:52, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.16.0.0/24 (1 entry, 1 announced)
Communities: 65001:100 65002:50
172.16.2.0/24 (1 entry, 1 announced)
Communities: 65001:300 65002:50
lab@vMX-3>This is due to the behavior of the policy statement in Junos. When you have multiple matches of the same type they usually act as a logical OR operation. So what we said in the policy was to accept routes that have either 65001:100 or 65002:50 communities.
Instead, we need to make one community that has both community ids defined. The config on vMX-1 is now:
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community comm-both-comms;
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-both-comms members [ 65001:100 65002:50 ];
community comm-customers members 65001:100;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
[edit]
lab@vMX-1#The routes on vMX-3 are:
lab@vMX-3> show route protocol bgp
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 00:12:18, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.16.0.0/24 (1 entry, 1 announced)
Communities: 65001:100 65002:50
lab@vMX-3>Example 6 – Match On Many Communities – Community Regular Expressions
Sometimes we don’t want to match on one specific community, but many.
Although community strings are just numbers, they are treated as strings which means we can use regular expressions to match the individual characters of the community string.
In this case, we can use community string regular expressions to do things like:
- Match all communities that start with a specific number
- Match all communities that have a specific number in the middle
Example 6A – Match Communities Ending With :100
We can update the vMX-1 policy as follows to match all communities ending with :100.
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community comm-regex-end-100;
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-both-comms members [ 65001:100 65002:50 ];
community comm-customers members 65001:100;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
community comm-regex-end-100 members *:100;
[edit]
lab@vMX-1#We see the following routes on vMX-3.
lab@vMX-3> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 00:25:32, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.0.0/24 *[BGP/170] 00:02:16, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.16.0.0/24 (1 entry, 1 announced)
Communities: 65001:100 65002:50
172.20.0.0/24 (1 entry, 1 announced)
Communities: 12345:100 large:4200000000:1000:70
lab@vMX-3>The above looks like a success, and it is, but it is worth pointing out that not all the routes with communities ending in :100 are present. Remember that 172.20.2.0/24 has a community of large:65550:20:100.
What this shows is that the regular expressions are specific to a type of community – standard, extended, or large. Since we have two routes with a large community ending in :70, let’s see how to match on that.
Updated vMX-1 policy is:
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community comm-large-regex-end-70;
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-both-comms members [ 65001:100 65002:50 ];
community comm-customers members 65001:100;
community comm-large-regex-end-70 members large:*:*:70;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
community comm-regex-end-100 members *:100;
[edit]
lab@vMX-1#And the routes on vMX-3 are:
lab@vMX-3> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.20.0.0/24 *[BGP/170] 00:06:58, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.1.0/24 *[BGP/170] 00:00:46, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.20.0.0/24 (1 entry, 1 announced)
Communities: 12345:100 large:4200000000:1000:70
172.20.1.0/24 (1 entry, 1 announced)
Communities: 12345:200 large:4200000000:2000:70
lab@vMX-3>Example 6B – Match Communities Starting With 1 And Ending 00
In this instance, we want to match routes with a community string that starts with a 1 before the colon and ends with a 00 after the colon.
The vMX-1 policy is updated to be:
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community comm-regex-start-1-end-00;
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-both-comms members [ 65001:100 65002:50 ];
community comm-customers members 65001:100;
community comm-large-regex-end-70 members large:*:*:70;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
community comm-regex-end-100 members *:100;
community comm-regex-start-1-end-00 members "^(1.*):(.*00)$";
[edit]
lab@vMX-1#The routes on vMX-3 are:
lab@vMX-3> show route protocol bgp
inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.20.0.0/24 *[BGP/170] 00:30:07, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.1.0/24 *[BGP/170] 00:23:55, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.20.0.0/24 (1 entry, 1 announced)
Communities: 12345:100 large:4200000000:1000:70
172.20.1.0/24 (1 entry, 1 announced)
Communities: 12345:200 large:4200000000:2000:70
lab@vMX-3>Example 6C – Match Communities With A 2 Or 5 After The Colon
In this example, we want to match any route with a 2 or a 5 immediately after the colon.
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term match-communities {
from community comm-regex-2-or-5;
then accept;
}
term final {
then reject;
}
}
community comm-65002-50 members 65002:50;
community comm-all members *:*;
community comm-both-comms members [ 65001:100 65002:50 ];
community comm-customers members 65001:100;
community comm-large-regex-end-70 members large:*:*:70;
community comm-new-1 members 65001:8000;
community comm-new-2 members 65001:9000;
community comm-regex-2-or-5 members "(.*):([25].*)$";
community comm-regex-end-100 members *:100;
community comm-regex-start-1-end-00 members "^(1.*):(.*00)$";
[edit]
lab@vMX-1#The routes on vMX-3 are:
lab@vMX-3> show route protocol bgp
inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/24 *[BGP/170] 00:00:41, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.16.1.0/24 *[BGP/170] 00:00:41, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.16.2.0/24 *[BGP/170] 00:00:41, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.1.0/24 *[BGP/170] 00:29:00, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.2.0/24 *[BGP/170] 00:00:41, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.16.0.0/24 (1 entry, 1 announced)
Communities: 65001:100 65002:50
172.16.1.0/24 (1 entry, 1 announced)
Communities: 65001:200 65003:6789
172.16.2.0/24 (1 entry, 1 announced)
Communities: 65001:300 65002:50
172.20.1.0/24 (1 entry, 1 announced)
Communities: 12345:200 large:4200000000:2000:70
172.20.2.0/24 (1 entry, 1 announced)
Communities: 12345:54321 large:65550:20:100
lab@vMX-3>Example 7 – Matching Routes Based On Number Of Communities
For this example, I’ve removed the no-export from route 172.20.3.0/24.
Junos policy allows you to match a route based on the number of communities that are present.
The match statement is community-count and you need to specify a number and then the option of either equal, orhigher, or orlower. In contrast to other match types, if more than one community-count statement is present they act in a logical AND fashion.
The policy on vMX-1 has been updated as follows:
[edit]
lab@vMX-1# show policy-options policy-statement export-vMX3
term match-communities {
from {
community-count 1 equal;
}
then accept;
}
term final {
then reject;
}
[edit]
lab@vMX-1#On vMX-3 we see the following results.
lab@vMX-3> show route protocol bgp
inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.20.0.0/24 *[BGP/170] 00:00:20, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.1.0/24 *[BGP/170] 02:58:46, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.2.0/24 *[BGP/170] 02:30:27, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
172.20.3.0/24 *[BGP/170] 00:00:20, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.100.2.1 via ge-0/0/2.0
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
172.20.0.0/24 (1 entry, 1 announced)
Communities: 12345:100 large:4200000000:1000:70
172.20.1.0/24 (1 entry, 1 announced)
Communities: 12345:200 large:4200000000:2000:70
172.20.2.0/24 (1 entry, 1 announced)
Communities: 12345:54321 large:65550:20:100
172.20.3.0/24 (1 entry, 1 announced)
Communities: 12345:45123
lab@vMX-3>At first glance, it appears that something has gone wrong. Why do three of the routes have two community strings each? The answer is that the community-count only considers standard communities. It doesn’t count extended or large communities, at least not at this time.
Example 8 – Understand The Ordering Of Your Policy
With all this adding, removing, and matching of community strings, something I haven’t yet mentioned is what order you should do this in.
What do you think will happen when with the following policy?
[edit]
lab@vMX-1# show policy-options
policy-statement export-vMX3 {
term delete-communities {
then {
community delete comm-all;
}
}
term match-communities {
from community comm-customers;
then accept;
}
term final {
then reject;
}
}
community comm-all members *:*;
community comm-customers members 65001:100;
[edit]
lab@vMX-1#Let’s have a look at vMX-3 and see what the outcome is.
lab@vMX-3> show route protocol bgp
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
lab@vMX-3> show route protocol bgp detail | match "entry|Communities"
lab@vMX-3>No BGP routes at all. But why?
As a route is evaluated against the policy, it starts with the term delete communities. Since there is no match clause, all routes match and have their communities deleted. Since there is no terminating action in that term, the route progresses to the next term.
Term match communities is next, and will match any route with the community string of 65001:100. The problem is all the community strings were deleted by the first term, so the route doesn’t match this term.
The route continues to the final term, which matches all routes and rejects them.
With that in mind, it seems best to structure your overall policy to match community strings before deleting them from a route.
Next Steps
So far we have looked at how to define community strings, or community string regular expressions. We’ve looked at how to add or remove them from a route, and how to match routes based on what community is attached.
But what now, is that all there is to using communities? Not quite.
Now you know how to match on a community, you can use that match to do anything you want to the matched route. You can set or modify attributes such as local preference, med values, or just about anything else based on the fact the route had a particular community or combination of communities attached to it.
Due to comments, I have added a post on Junos and large BGP community strings.
Adding and accepting using large communties works great. But if you try and delete any large:*:*:* community, I have not been able to remove them. Even if I specifically put the exact large:11111:1:20 community, the community is not removed.
Thoughts?
Hi, thanks for the question.
I had a play with large community strings and have added a new post – BGP large community strings on Junos
In short – I didn’t have any troubles removing the large communities.
I suspect it might be an issue with either the ordering of your policies, or ordering of terms within a policy. If the route is matched and a terminating action (accept or reject) is taken before the term that deletes the community, then that term won’t be applied.