Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Routing Policies for BGP Communities

Understanding BGP Communities, Extended Communities, and Large Communities as Routing Policy Match Conditions

A BGP community is a group of destinations that share a common property. Community information is included as a path attribute in BGP update messages. This information identifies community members and enables you to perform actions on a group without having to elaborate upon each member. You can use community and extended communities attributes to trigger routing decisions, such as acceptance, rejection, preference, or redistribution.

You can assign community tags to non-BGP routes through configuration (for static, aggregate, or generated routes) or an import routing policy. These tags can then be matched when BGP exports the routes.

A community value is a 32-bit field that is divided into two main sections. The first 16 bits of the value encode the AS number of the network that originated the community, while the last 16 bits carry a unique number assigned by the AS. This system attempts to guarantee a globally unique set of community values for each AS in the Internet. Junos OS uses a notation of as-number:community-value, where each value is a decimal number. The AS values of 0 and 65,535 are reserved, as are all of the community values within those AS numbers. Each community, or set of communities, is given a name within the [edit policy-options] configuration hierarchy. The name of the community uniquely identifies it to the routing device and serves as the method by which routes are categorized. For example, a route with a community value of 64510:1111 might belong to the community named AS64510-routes. The community name is also used within a routing policy as a match criterion or as an action. The command syntax for creating a community is: policy-options community name members [community-ids]. The community-ids are either a single community value or multiple community values. When more than one value is assigned to a community name, the routing device interprets this as a logical AND of the community values. In other words, a route must have all of the configured values before being assigned the community name.

The regular community attribute is four octets. Networking enhancements, such as VPNs, have functionality requirements that can be satisfied by an attribute such as a community. However, the 4-octet community value does not provide enough expansion and flexibility to accommodate VPN requirements. This leads to the creation of extended communities. An extended community is an 8-octet value that is also divided into two main sections. The first 2 octets of the community encode a type field while the last 6 octets carry a unique set of data in a format defined by the type field. Extended communities provide a larger range for grouping or categorizing communities.

The BGP extended communities attribute format has three fields: type:administrator:assigned-number. The routing device expects you to use the words target or origin to represent the type field. The administrator field uses a decimal number for the AS or an IPv4 address, while the assigned number field expects a decimal number no larger than the size of the field (65,535 for 2 octets or 4,294,967,295 for 4 octets).

When specifying community IDs for standard and extended community attributes, you can use UNIX-style regular expressions. The only exception is for VPN import policies (vrf-import), which do not support regular expressions for the extended communities attribute.

Regular BGP communities attributes are a variable length attribute consisting of a set of one or more 4-byte values that was split into 16 bit values. The most significant word is interpreted as an AS number and least significant word is a locally defined value assigned by the operator of the AS. Since the adoption of 4-byte ASNs, the 4-byte BGP regular community and 6-byte BGP extended community can no longer support BGP community attributes. Operators often encode AS number in the local portion of the BGP community that means that sometimes the format of the community is ASN:ASN. With the 4-byte ASN , you need 8-bytes to encode it. Although BGP extended community permits a 4-byte AS to be encoded as the global administrator field, the local administrator field has only 2-byte of available space. Thus, 6-byte extended community attribute is also unsuitable. To overcome this, Junos OS allows you to configure optional transitive path attribute - a 12-byte BGP large community that provides the most significant 4-byte value to encode autonomous system number as the global administrator and the remaining two 4-byte assigned numbers to encode the local values as defined in RFC 8092. You can configure BGP large community at the [edit policy-options community community-name members] and [edit routing-options static route ip-address community] hierarchy levels. The BGP large community attributes format has four fields: large:global administrator:assigned number:assigned number.

The BGP IPv6 unicast address specific extended community are encoded as a set of 20-bytes value. The 20-byte value gets interpreted in the following format:

  • Most significant 2-bytes encodes the Type and Sub-Type value (high value (most significant byte) and Low value (second most significant byte)).

  • Next 16-bytes encodes the IPv6 unicast address. It is the global administrator in the IETF RFC.

  • Last 2-bytes encodes the operator defined local values. It is local administrator in the IETF RFC.

The IPv6 unicast address specific BGP extended community attributes are represented by a keyword ipv6-target, ipv6-origin, or ipv6-extended followed by IPv6 and local administrator separated by <, >, and :.

Note:

The length of the BGP large communities attribute value should be a non-zero multiple of 12.

Example: Configuring a Routing Policy to Redistribute BGP Routes with a Specific Community Tag into IS-IS

This example defines a policy that takes BGP routes from the Edu community and places them into IS-IS with a metric of 63.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

Figure 1 shows the topology used in this example.

Figure 1: Redistributing BGP Routes with a Specific Community Tag into IS-ISRedistributing BGP Routes with a Specific Community Tag into IS-IS

In this example, Device A, Device B, Device C, and Device D are in autonomous system (AS) 1 and are running IS-IS. All of the AS 1 devices, except Device D, are running internal BGP (IBGP).

Device E is in AS 2 and has an external BGP (EBGP) peering session with Device C. Device E has two static routes, 10.2.0.0/16 and 10.3.0.0/16. These routes are tagged with the Edu 2:5 community attribute and are advertised by way of EBGP to Device C.

Device C accepts the BGP routes that are tagged with the Edu 2:5 community attribute, redistributes the routes into IS-IS, and applies an IS-IS metric of 63 to these routes.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section #d206e62__d206e383 describes the steps on Device C and Device E.

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device A

Device B

Device C

Device D

Device E

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device E:

  1. Configure the interfaces.

  2. Configure the statics policy, which adds the Edu community attribute to the static routes.

  3. Configure EBGP and apply the statics policy.

  4. Configure the static routes.

  5. Configure the router ID and the AS number.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device C:

  1. Configure the interfaces.

  2. Configure IBGP.

  3. Configure the Edu-to-isis policy, which redistributes the Edu-tagged BGP routes learned from Device E and applies a metric of 63.

  4. Enable IS-IS on the interfaces, and apply the Edu-to-isis policy.

  5. Configure the send-isis-and-direct policy, which redistributes routes to Device E, through EBGP.

    Without this policy, Device E would not have connectivity to the networks in AS 1.

  6. Configure EBGP and apply the send-isis-and-direct policy.

  7. Configure the router ID and the autonomous system (AS) number.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device E

Device C

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the IS-IS Neighbor

Purpose

Verify that the BGP routes from Device E are communicated on the IS-IS network in AS 1.

Action

From operational mode, enter the show route protocol isis command.

Meaning

As expected, the 10.2.0.0/16 and 10.3.0.0/16 routes are in Device D’s routing table as IS-IS external routes with a metric of 73. If Device C had not added 63 to the metric, Device D would have a metric of 10 for these routes.

Example: Configuring a Routing Policy That Removes BGP Communities

This example shows how to create a policy that accepts BGP routes, but removes BGP communities from the routes.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

This example shows two routing devices with an external BGP (EBGP) connection between them. Device R2 uses the BGP session to send two static routes to Device R1. On Device R1, an import policy specifies that all BGP communities must be removed from the routes.

By default, when communities are configured on EBGP peers, they are sent and accepted. To suppress the acceptance of communities received from a neighbor, you can remove all communities or a specified set of communities. When the result of a policy is an empty set of communities, the community attribute is not included. To remove all communities, first define a wildcard set of communities (here, the community is named wild):

Then, in the routing policy statement, specify the community delete action:

To suppress a particular community from any autonomous system (AS), define the community as community wild members "*:community-value".

Topology

Figure 2 shows the sample network.

Figure 2: BGP Policy That Removes CommunitiesBGP Policy That Removes Communities

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R1

Device R2

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1:

  1. Configure the interfaces.

  2. Configure BGP.

    Apply the import policy to the BGP peering session with Device R2.

  3. Configure the routing policy that deletes communities.

  4. Configure the autonomous system (AS) number and the router ID.

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R2:

  1. Configure the interfaces.

  2. Configure the router ID and the autonomous system (AS) number.

  3. Configure BGP.

  4. Configure multiple communities, or configure a single community with multiple members.

  5. Configure the static routes.

  6. Configure a routing policy that advertises static routes into BGP and adds the BGP community to the routes.

  7. Apply the export policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device R1

Device R2

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the BGP Routes

Purpose

Make sure that the routing table on Device R1 does not contain BGP communities.

Action
  1. On Device R1, run the show route protocols bgp extensive command.

  2. On Device R1, deactivate the community remove configuration in the import policy.

  3. On Device R1, run the show route protocols bgp extensive command to view the advertised communities.

Meaning

The output shows that in Device R1’s routing table, the communities are suppressed in the BGP routes sent from Device R2. When the community remove setting in Device R1’s import policy is deactivated, the communities are no longer suppressed.

Example: Configuring a Routing Policy Based on the Number of BGP Communities

This example shows how to create a policy that accepts BGP routes based on the number of BGP communities.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

This example shows two routing devices with an external BGP (EBGP) connection between them. Device R2 uses the BGP session to send two static routes to Device R1. On Device R1, an import policy specifies that the BGP-received routes can contain up to five communities to be considered a match. For example, if a route contains three communities, it is considered a match and is accepted. If a route contains six or more communities, it is considered a nonmatch and is rejected.

It is important to remember that the default policy for EBGP is to accept all routes. To ensure that the nonmatching routes are rejected, you must include a then reject action at the end of the policy definition.

Topology

Figure 3 shows the sample network.

Figure 3: BGP Policy with a Limit on the Number of Communities AcceptedBGP Policy with a Limit on the Number of Communities Accepted

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R1

Device R2

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R1:

  1. Configure the interfaces.

  2. Configure BGP.

    Apply the import policy to the BGP peering session with Device R2.

  3. Configure the routing policy that sends direct routes.

  4. Configure the autonomous system (AS) number and the router ID.

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure Device R2:

  1. Configure the interfaces.

  2. Configure the router ID and the autonomous system (AS) number.

  3. Configure BGP.

  4. Configure multiple communities, or configure a single community with multiple members.

  5. Configure the static routes.

  6. Configure a routing policy that advertises static routes into BGP and adds the BGP community to the routes.

  7. Apply the export policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device R1

Device R2

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the BGP Routes

Purpose

Make sure that the routing table on Device R1 contains the expected BGP routes.

Action
  1. On Device R1, run the show route protocols bgp command.

  2. On Device R1, change the community-count configuration in the import policy.

  3. On Device R1, run the show route protocols bgp command.

  4. On Device R1, run the show route protocols bgp extensive command to view the advertised communities.

Meaning

The output shows that in Device R1’s routing table, the BGP routes sent from Device R2 are hidden. When the community-count setting in Device R1’s import policy is modified, the BGP routes are no longer hidden.