Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring Communities in a Routing Policy

 

A community is a route attribute used by BGP to administratively group routes with similar properties.

Requirements

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

Overview

One main role of the community attribute is to be an administrative tag value used to associate routes together. Generally, these routes share some common properties, but that is not required. Communities are a flexible tool within BGP. An individual community value can be assigned to a single route or multiple routes. A route can be assigned a single community value or multiple values. Networks use the community attribute to assist in implementing administrative routing policies. A route’s assigned value can allow it to be accepted into the network, or rejected from the network, or allow it to modify attributes.

Figure 1 shows Device R1, Device R2, and Device R3 as internal BGP (IBGP) peers in autonomous system (AS) 64510. Device R4 is advertising the 172.16.0.0/21 address space from AS 64511. The specific routes received by Device R1 from Device R4 are as follows:

user@R1> show route receive-protocol bgp 10.0.0.13

The administrators of AS 64511 want to receive certain user traffic from Device R1, and other user traffic from Device R3. To accomplish this administrative goal, Device R4 attaches the community value of 64511:1 to some routes that it sends and attaches the community value 64511:3 to other routes that it sends. Routing policies within AS 64510 are configured using a community match criterion to change the local preference of the received routes to new values that alter the BGP route selection algorithm. The route with the highest local preference value is preferred.

On Device R1, routes with the 64511:1 community value are assigned a local preference of 200, and routes with the 64511:3 community value are assigned a local preference of 50. On Device R3, the reverse is done so that routes with the 64511:3 community value are assigned a local preference of 200, and routes with the 64511:1 community value are assigned a local preference of 50. This information is then communicated through IBGP by both Device R1 and Device R3 to Device R2.

Topology

Figure 1 shows the sample network.

Figure 1: Topology for Regular BGP Communities
Topology for Regular BGP Communities

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section Step-by-Step Procedure describes the steps on Device R1 and R4.

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

Device R3

Device R4

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 CLI User Guide.

To configure Device R1:

  1. Configure the interfaces.
  2. Configure internal gateway protocol (IGP) connections to Device R2 and Device R3.
  3. Configure the IBGP connections to Device R2 and Device R3.
  4. Configure the EBGP connection to Device R4.
  5. Configure the policy send-direct.

    This policy is referenced in the IBGP connection to Device R2 and enables Device R2 to have external reachability. An alternative is to configure a next-hop self policy on Device R1 and Device R3.

  6. Configure the policy that changes the local preference for routes with specified community tags.
  7. Configure the autonomous system (AS) number and 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 CLI User Guide.

To configure Device R4:

  1. Configure the interfaces.
  2. Configure the EBGP connection to Device R1 and Device R3.
  3. Configure the community tags.
  4. Configure the policy send-static.

    This policy is referenced in the EBGP connections to Device R1 and Device R3. The policy attaches the 64511:1 (from-R1) community to some routes and the 64511:3 (from-R3) community to other routes.

  5. Configure the static routes.
  6. Configure the autonomous system (AS) number and router ID.

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 R4

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

Verification

Confirm that the configuration is working properly.

Verifying the Routes Sent on Device R4

Purpose

On Device R4, check the routes sent to Device R1 and Device R3.

Action

user@R4> show route advertising-protocol bgp 10.0.0.14 extensive




user@R2> show route advertising-protocol bgp 10.0.0.10 extensive

Meaning

Device R4 has tagged the routes with the communities 64511:1 and 64511:3 and sent them to Device R1 and R3.

Verifying the Routes Received on Device R2

Purpose

On Device R2, check the routes received from Device R1 and Device R3.

Action

user@R2> show route receive-protocol bgp 192.168.0.1 extensive




user@R2> show route match-prefix 172.16.*




Meaning

Device R2 has the routes with the expected local preferences and the expected active routes, as designated by the asterisks (*).