Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring Policy Chains and Route Filters

 

A policy chain is the application of multiple policies within a specific section of the configuration. A route filter is a collection of match prefixes.

Requirements

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

Overview

An example of a policy chain applied to BGP is as follows:

The adv-statics, adv-large-aggregates, and adv-small-aggregates policies, in addition to the default BGP policy, make up the policy chain applied to the BGP peers of Device R1. Two of the policies demonstrate route filters with different match types. The other policy matches all static routes, so no route filter is needed.

Optionally, you can convert this policy chain into a single multiterm policy for the internal BGP (IBGP) peers. If you do this, one of the advantages of a policy chain is lost—the ability to reuse policies for different purposes.

Figure 1 displays Device R1 in AS 64510 with its IBGP peers, Device R2 and Device R3. Device R1 also has external BGP (EBGP) connections to Device R4 in AS 64511 and Device R5 in AS 64512. The current administrative policy within AS 64510 is to send the customer static routes only to other IBGP peers. Any EBGP peer providing transit service only receives aggregate routes with mask lengths smaller than 18 bits. Any EBGP peer providing peering services receives all customer routes and all aggregates whose mask length is larger than 19 bits. Each portion of these administrative policies is configured in a separate routing policy within the [edit policy-opitons] configuration hierarchy. These policies provide the administrators of AS 64510 with multiple configuration options for advertising routes to peers.

Device R4 is providing transit service to AS 64510, which allows the AS to advertise its assigned routing space to the Internet. On the other hand, the peering service provided by Device R5 allows AS 64510 to route traffic directly between the autonomous systems (ASs) for all customer routes.

Topology

Figure 1 shows the sample network.

Figure 1: BGP Topology for Policy Chains
BGP Topology for Policy Chains

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.

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

Device R5

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 device interfaces.
  2. Configure the IBGP connections to Device R2 and Device R3.
  3. Apply the export policies for the internal peers.
  4. Configure the EBGP connection to Device R4.
  5. Apply the export policy for Device R4.
  6. Configure the EBGP connection to Device R5.
  7. Apply the export policies for Device R5.
  8. Configure OSPF connections to Device R2 and Device R3.
  9. Configure the routing policies.
  10. Configure the static and aggregate routes.
  11. 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.

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

Verification

Confirm that the configuration is working properly.

Verifying the Route Advertisement to Device R4

Purpose

On Device R1, make sure that the customer routes are advertised to Device R4.

Action

user@R1> show route advertising-protocol bgp 10.1.0.6

Meaning

The adv-large-aggregates policy is applied to the peering session with Device R4 to advertise the aggregate routes with a subnet mask length between 16 and 18 bits. The 172.16.0.0/16 aggregate route is being sent as defined by the administrative policy, but a number of other routes with larger subnet masks are also being sent to Device R4.

Checking Where the Longer Routes Are Originating

Purpose

On Device R1, find where the other routes are coming from.

Action

user@R1> show route 172.16.3.16/28

Meaning

Device R1 has learned this route through its BGP session with Device R3. Because it is an active BGP route, it is automatically advertised by the BGP default policy. Remember that the default policy is always applied to the end of every policy chain. What is needed is a policy to block the more specific routes from being advertised.

Blocking the More Specific Routes

Purpose

Create a policy called not-larger-than-18 that rejects all routes within the 172.16.0.0 /16 address space that have a subnet mask length greater than or equal to 19 bits. This ensures that all aggregates with a mask between 16 and 18 bits are advertised, thus accomplishing the goal of the administrative policy.

Action

  1. On Device R1, configure the not-larger-than-18 policy.

  2. On Device R1, apply the policy to the peering session with Device R4.

  3. On Device R1, check which routes are advertised to Device R4.

    user@R1> show route advertising-protocol bgp 10.1.0.6

Meaning

The policy chain is working correctly. Only the 172.16.0.0 /16 route is advertised to Device R4.

Verifying the Route Advertisement to Device R5

Purpose

On Device R1, make sure that the customer routes are advertised to Device R5.

Device R5 is Device R1’s EBGP peer in AS 64512. The administrative policy states that this peer receives only aggregate routes larger than 18 bits in length and all customer routes. In anticipation of encountering a problem similar to the problem on Device R4, you can create a policy called not-smaller- than-18 that rejects all aggregates with mask lengths between 16 and 18 bits.

Action

  1. On Device R2, configure an aggregate route for 172.16.128.0/17.

  2. On Device R1, check which routes are advertised to Device R5.

    user@R1> show route advertising-protocol bgp 10.0.0.9

    The aggregate route 172.16.128.0/17 is advertised, in violation of the administrative policy

  3. On Device R1, configure the not-smaller-than-18 policy.

  4. On Device R1, apply the policy to the peering session with Device R5.

  5. On Device R1, check which routes are advertised to Device R5.

    user@R1> show route advertising-protocol bgp 10.0.0.9

Meaning

The policy chain is working correctly. Only aggregate routes larger than 18 bits in length and all customer routes are advertised to Device R5.