Examples: Configuring BGP Communities as Routing Policy Match Conditions

Create a community named dunedin and apply it in a routing policy statement:

[edit]policy-options {community dunedin members [ 56:2379 23:46944 ];policy-statement from-dunedin {from community dunedin;then {metric 2;preference 100;next policy;}}}

The preceding example modifies the metric and preference for routes that contain members of community dunedin only.

Note: You cannot set or add a community in a policy whose members use regular expressions or a wildcard.

Delete a particular community from a route, leaving remaining communities untouched:

[edit]policy-options {community dunedin members 701:555;policy-statement delete-dunedin {then {community delete dunedin;}}}

Remove any community from a route with the AS number of 65534 or 65535:

[edit]policy-options {community my-as1-transit members [ 65535:10 65535:11 ];community my-as2-transit members [ 65534:10 65534:11 ];community my-wild members [ 65534:* 65535:* ];policy-statement delete-communities {from {community [ my-as1-transit my-as2-transit ];}then {community delete my-wild;}}}

Match the set of community members 5000, 5010, 5020, 5030, and so on up to 5090:

[edit]policy-options {community customers members "^1111:50.0$";policy-statement advertise-customers {from community customers;then accept;}}

Reject routes that are longer than /19 in Class A space, /16 in Class B space, and /24 in Class C space:

[edit policy-options]community auckland-accept members 555:1;policy-statement drop-specific-routes {from {route-filter 0.0.0.0/1 upto /19 {community add auckland-accept;next policy;}route-filter 172.16.0.0/2 upto /16 {community add auckland-accept;next policy;}route-filter 192.168.0.0/3 upto /24 {community add auckland-accept;next policy;}}then reject;}

In the preceding example, for routes that are not rejected, the tag auckland-accept is added.

Create routing policies to handle peer and customer communities. This example does the following: