Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring BGP to Advertise Inactive Routes

 

By default, BGP readvertises only active routes. To have the routing table export to BGP the best route learned by BGP even if Junos OS did not select it to be an active route, include the advertise-inactive statement:

In Junos OS, BGP advertises BGP routes that are installed or active, which are routes selected as the best based on the BGP path selection rules. The advertise-inactive statement allows nonactive BGP routes to be advertised to other peers.

Note

If the routing table has two BGP routes where one is active and the other is inactive, the advertise-inactive statement does not advertise the inactive BGP prefix. This statement does not advertise an inactive BGP route in the presence of another active BGP route. However, if the active route is a static route, the advertise-inactive statement advertises the inactive BGP route.

Junos OS also provides support for configuring a BGP export policy that matches the state of an advertised route. You can match either active or inactive routes, as follows:

This qualifier only matches when used in the context of an export policy. When a route is being advertised by a protocol that can advertise inactive routes (such as BGP), state inactive matches routes advertised as a result of the advertise-inactive (or advertise-external) statement.

For example, the following configuration can be used as a BGP export policy to mark routes advertised due to the advertise-inactive setting with a user-defined community. That community can be later used by the receiving routers to filter out such routes from the forwarding table. Such a mechanism can be used to address concerns that advertising paths not used for forwarding by the sender might lead to forwarding loops.

Requirements

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

Overview

In this example, Device R2 has two external BGP (EBGP) peers, Device R1 and Device R3.

Device R1 has a static route to 172.16.5/24. Likewise, Device R2 also has a static route to 172.16.5/24. Through BGP, Device R1 sends information about its static route to Device R2. Device R2 now has information about 172.16.5/24 from two sources—its own static route and the BGP-learned route received from Device R1. Static routes are preferred over BGP-learned routes, so the BGP route is inactive on Device R2. Normally Device R2 would send the BGP-learned information to Device R3, but Device R2 does not do this because the BGP route is inactive. Device R3, therefore, has no information about 172.16.5/24 unless you enable the advertise-inactive command on Device R2, which causes Device R2 to send the BGP-learned to Device R3.

Topology

Figure 1 shows the sample network.

Figure 1: BGP Topology for advertise-inactive
BGP Topology for advertise-inactive

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 R2.

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

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 R2:

  1. Configure the device interfaces.
  2. Configure the EBGP connection to Device R1.
  3. Configure the EBGP connection to Device R3.
  4. Add the advertise-inactive statement to the EBGP group peering session with Device R3.
  5. Configure the static route to the 172.16.5.0/24 network.
  6. Configure 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.

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

Verification

Confirm that the configuration is working properly.

Verifying the BGP Active Path

Purpose

On Device R2, make sure that the 172.16.5.0/24 prefix is in the routing table and has the expected active path.

Action

user@R2> show route 172.16.5

Meaning

Device R2 receives the 172.16.5.0/24 route from both Device R1 and from its own statically configured route. The static route is the active path, as designated by the asterisk (*). The static route path has the lowest route preference (5) as compared to the BGP preference (170). Therefore, the static route becomes active.

Verifying the External Route Advertisement

Purpose

On Device R2, make sure that the 172.16.5.0/24 route is advertised toward Device R3.

Action

user@R2> show route advertising-protocol bgp 10.0.0.6

Meaning

Device R2 is advertising the 172.16.5.0/24 route toward Device R3

Verifying the Route on Device R3

Purpose

Make sure that the 172.16.6.0/24 prefix is in Device R3’s routing table.

Action

user@R3> show route 172.16.5.0/24

Meaning

Device R3 has the BGP-learned route for 172.16.5.0/24.

Experimenting with the advertise-inactive Statement

Purpose

See what happens when the advertise-inactive statement is removed from the BGP configuration on Device R2.

Action

  1. On Device R2, deactivate the advertise-inactive statement.

  2. On Device R2, check to see if the 172.16.5.0/24 route is advertised toward Device R3.



    user@R2> show route advertising-protocol bgp 10.0.0.6

    As expected, the route is no longer advertised.

  3. On Device R3, ensure that the 172.16.5/24 route is absent from the routing table.



    user@R3> show route 172.16.5/24

Meaning

Device R1 advertises route 172.16.5/24 to Device R2, but Device R2 has a manually configured static route for this prefix. Static routes are preferred over BGP routes, so Device R2 installs the BGP route as an inactive route. Because the BGP route is not active, Device R2 does not readvertise the BGP route to Device R3. This is the default behavior in Junos OS. If you add the advertise-inactive statement to the BGP configuration on Device R2, Device R2 readvertises nonactive routes.