Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Applying Routing Policies at Different Levels of the BGP Hierarchy

 

This example shows BGP configured in a simple network topology and explains how routing polices take effect when they are applied at different levels of the BGP configuration.

Requirements

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

Overview

For BGP, you can apply policies as follows:

  • BGP global import and export statements—Include these statements at the [edit protocols bgp] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp] hierarchy level).

  • Group import and export statements—Include these statements at the [edit protocols bgp group group-name] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp group group-name] hierarchy level).

  • Peer import and export statements—Include these statements at the [edit protocols bgp group group-name neighbor address] hierarchy level (for routing instances, include these statements at the [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] hierarchy level).

A peer-level import or export statement overrides a group import or export statement. A group-level import or export statement overrides a global BGP import or export statement.

In this example, a policy named send-direct is applied at the global level, another policy named send-192.168.0.1 is applied at the group level, and a third policy named send-192.168.20.1 is applied at the neighbor level.

A key point, and one that is often misunderstood and that can lead to problems, is that in such a configuration, only the most explicit policy is applied. A neighbor-level policy is more explicit than a group-level policy, which in turn is more explicit than a global policy.

The neighbor 172.16.2.2 is subjected only to the send-192.168.20.1 policy. The neighbor 172.16.3.3, lacking anything more specific, is subjected only to the send-192.168.0.1 policy. Meanwhile, neighbor 172.16.4.4 in group other-group has no group or neighbor-level policy, so it uses the send-direct policy.

If you need to have neighbor 172.16.2.2 perform the function of all three policies, you can write and apply a new neighbor-level policy that encompasses the functions of the other three, or you can apply all three existing policies, as a chain, to neighbor 172.16.2.2.

Figure 1 shows the sample network.

Figure 1: Applying Routing Policies to BGP
Applying Routing Policies to BGP

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

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 an IS-IS default route policy:

  1. Configure the device interfaces.
  2. Enable OSPF, or another interior gateway protocols (IGP), on the interfaces.
  3. Configure static routes.

  4. Enable the routing policies.
  5. Configure BGP and apply the export policies.

  6. Configure the router ID and autonomous system (AS) number.
  7. If you are done configuring the device, commit the configuration.

Results

From configuration mode, confirm your configuration by issuing 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.

Verification

Confirm that the configuration is working properly.

Verifying BGP Route Learning

Purpose

Make sure that the BGP export policies are working as expected by checking the routing tables.

Action

user@R1> show route protocol direct


user@R1> show route protocol static


user@R2> show route protocol bgp


user@R3> show route protocol bgp


user@R4> show route protocol bgp

Meaning

On Device R1, the show route protocol direct command displays two direct routes: 172.16.1.1/32 and 10.10.10.0/30. The show route protocol static command displays two static routes: 192.168.0.1/32 and 192.168.20.1/32.

On Device R2, the show route protocol bgp command shows that the only route that Device R2 has learned through BGP is the 192.168.20.1/32 route.

On Device R3, the show route protocol bgp command shows that the only route that Device R3 has learned through BGP is the 192.168.0.1/32 route.

On Device R4, the show route protocol bgp command shows that the only routes that Device R4 has learned through BGP are the 172.16.1.1/32 and 10.10.10.0/30 routes.

Verifying BGP Route Receiving

Purpose

Make sure that the BGP export policies are working as expected by checking the BGP routes received from Device R1.

Action

user@R2> show route receive-protocol bgp 172.16.1.1


user@R3> show route receive-protocol bgp 172.16.1.1


user@R4> show route receive-protocol bgp 172.16.1.1

Meaning

On Device R2, the route receive-protocol bgp 172.16.1.1 command shows that Device R2 received only one BGP route, 192.168.20.1/32, from Device R1.

On Device R3, the route receive-protocol bgp 172.16.1.1 command shows that Device R3 received only one BGP route, 192.168.0.1/32, from Device R1.

On Device R4, the route receive-protocol bgp 172.16.1.1 command shows that Device R4 received two BGP routes, 172.16.1.1/32 and 10.10.10.0/30, from Device R1.

In summary, when multiple policies are applied at different CLI hierarchies in BGP, only the most specific application is evaluated, to the exclusion of other, less specific policy applications. Although this point might seem to make sense, it is easily forgotten during router configuration, when you mistakenly believe that a neighbor-level policy is combined with a global or group-level policy, only to find that your policy behavior is not as anticipated.