How BGP Communities and Extended Communities Are Evaluated in Routing Policy Match Conditions

When you use BGP communities and extended communities as match conditions in a routing policy, the policy framework software evaluates them as follows:

Each route is evaluated against each named community in a routing policy from statement. If a route matches one of the named communities in the from statement, the evaluation of the current term continues. If a route does not match, the evaluation of the current term ends.
The route is evaluated against each member of a named community. The evaluation of all members must be successful for the named community evaluation to be successful.
Each member in a named community is identified by either a literal community value or a regular expression. Each member is evaluated against each community associated with the route. (Communities are an unordered property of a route. For example, 1:2 3:4 is the same as 3:4 1:2.) Only one community from the route is required to match for the member evaluation to be successful.
Community regular expressions are evaluated on a character-by-character basis. For example, if a route contains community 1234:5678, the regular expressions see nine discrete characters, including the colon (:), instead of two sets of numbers (1234 and 5678) separated by a colon. For example:
If a community member is a regular expression, a string match is made rather than a numeric match.

For example:
Given a route with a community value of 1100:100, this route matches community example2 but not example1.
To match routing policy one, the route must match either comm-one or comm-two.
To match comm-one, the route must have a community that matches 1:2 and a community that matches 4:5 or 4:6.
To match comm-two, the route must have a community that matches 7:8 and a community that matches 9:10.

Multiple Matches

When multiple matches are found, label aggregation does not happen. Consider the following configuration:

Suppose, for instance, that two routes are received with community attributes target:65000:1000 origin:65200:2000 and that the community name is "5...:.*". In this case, both the extended community attributes, target:65000:1000 and origin:65200:2000 match the regular expression of the community name. In this case, label aggregation does not occur. In the following example, the Label operation field shows that the labels are not aggregated.

You can resolve this issue in either of the following ways:

Be more specific in the regular expression if the site-of-origin extended community attribute does not overlap with the target one.
Specify the site of origin in the community name.

Both methods are shown in the following examples.

Be More Specific in the Regular Expression

Specify the Site of Origin in the Community Name

Inverting Community Matches

The community match condition defines a regular expression and if it matches the community attribute of the received prefix, Junos OS returns a TRUE result. If not, Junos OS returns a FALSE result. The invert-match statement makes Junos OS behave to the contrary. If there is a match, Junos OS returns a FALSE result. If there is no match, Junos OS returns a TRUE result. To invert the results of the community expression matching, include the invert-match statement in the community configuration.

Extended Community Type

The extended community type is not taken into account by regular expressions. Consider, for instance, the following community attributes and community name.

Communities:

5200:1000
target:65000:1000
origin:65200:2000

Community attribute:

community-name members "5...:.*"

In this case, both extended community attribute, 5200:1000 and the extended community attribute, origin:65200:2000, match the regular expression of the community name. Therefore, the label aggregation does not occur, as shown here:

You can resolve this issue by using a more specific regular expression. For example, you can use the anchor character (^) to bind the location of the digits, as shown here:

Note:

With the implementation of the large community feature in release 17.3, Junos OS checks to prevent the matching of extended or large communities against base BGP or base BGP regular expression communities. In other words, a received community can only be matched against the appropriate wild community pattern, like normal communities against simple-wild, extended communities against extended-wild and large communities against large-wild patterns. For example, to allow the advertisement of routes carrying the origin extended community, use the origin:*:65020 expression.

Multiple Communities Are Matched with Ex-OR Logic

This differs from the AND matching logic used for non-extended communities in BGP.

If, for instance, four routes are received with two sets of community attributes, the regular expression might match both community attributes. Consider the following example:

Communities—5200:1000 target:65000:1000
Communities—target:65000:1000 origin:65200:2000
Community attribute—community community-name member [ "^5...:.*" origin:65.*:.* ]

Both labels are aggregated, as shown here:

A more complete example of community values is shown here:

This regular expression matches community values starting with 1, 3, or 4, and matches extended community values of type origin whose administrative value starts with 2, 3, or 6.

Including BGP Communities and Extended Communities in Routing Policy Match Conditions

To include a BGP community or extended community in a routing policy match condition, include the community condition in the from statement of a policy term:

Additionally, you can explicitly exclude BGP community information with a static route by using the none option. Include this option when configuring an individual route in the route portion to override a community option specified in the defaults portion.

You can include the names of multiple communities in the community match condition. If you do this, only one community needs to match for a match to occur (matching is effectively a logical OR operation).

ON THIS PAGE