Example: Configuring a Routing Policy for Conditional Advertisement Enabling Conditional Installation of Prefixes in a Routing Table

 

This example shows how to configure conditional installation of prefixes in a routing table using BGP export policy.

Requirements

This example uses the following hardware and software components:

  • M Series Multiservice Edge Routers, MX Series 5G Universal Routing Platforms, or T Series Core Routers

  • Junos OS Release 9.0 or later

Overview

In this example, three routers in three different autonomous systems (ASs) are connected and configured with the BGP protocol. The router labeled Internet, which is the upstream router, has five addresses configured on its lo0.0 loopback interface (172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, and 172.16.15.1/32), and an extra loopback address (192.168.9.1/32) is configured as the router ID. These six addresses are exported into BGP to emulate the contents of a BGP routing table of a router connected to the Internet, and advertised to North.

The North and South routers use the 10.0.89.12/30 and 10.0.78.12/30 networks, respectively, and use 192.168.7.1 and 192.168.8.1 for their respective loopback addresses.

Figure 1 shows the topology used in this example.

Figure 1: Conditional Installation of Prefixes
Conditional Installation of
Prefixes

Router North exports a default route into BGP, and advertises the default route and the five BGP routes to Router South, which is the downstream router. Router South receives the default route and only one other route (172.16.11.1/32), and installs this route and the default route in its routing table.

To summarize, the example meets the following requirements:

  • On North, send 0/0 to South only if a particular route is also sent (in the example 172.16.11.1/32).

  • On South, accept the default route and the 172.16.11.1/32 route. Drop all other routes. Consider that South might be receiving the entire Internet table, while the operator only wants South to have the default and one other specific prefix.

The first requirement is met with an export policy on North:

The logic of the conditional export policy can be summarized as follows: If 0/0 is present, and if 172.16.11.1/32 is present, then send the 0/0 prefix. This implies that if 172.16.11.1/32 is not present, then do not send 0/0.

The second requirement is met with an import policy on South:

In this example, four routes are dropped as a result of the import policy on South. This is because the export policy on North leaks all of the routes received from Internet, and the import policy on South excludes some of these routes.

It is important to understand that in Junos OS, although an import policy (inbound route filter) might reject a route, not use it for traffic forwarding, and not include it in an advertisement to other peers, the router retains these routes as hidden routes. These hidden routes are not available for policy or routing purposes. However, they do occupy memory space on the router. A service provider filtering routes to control the amount of information being kept in memory and processed by a router might want the router to entirely drop the routes being rejected by the import policy.

Hidden routes can be viewed by using the show route receive-protocol bgp neighbor-address hidden command. The hidden routes can then be retained or dropped from the routing table by configuring the keep all | none statement at the [edit protocols bgp] or [edit protocols bgp group group-name] hierarchy level.

The rules of BGP route retention are as follows:

  • By default, all routes learned from BGP are retained, except those where the AS path is looped. (The AS path includes the local AS.)

  • By configuring the keep all statement, all routes learned from BGP are retained, even those with the local AS in the AS path.

  • By configuring the keep none statement, BGP discards routes that were received from a peer and that were rejected by import policy or other sanity checking. When this statement is configured and the inbound policy changes, Junos OS re-advertises all the routes advertised by the peer.

When you configure keep all or keep none and the peers support route refresh, the local speaker sends a refresh message and performs an import evaluation. For these peers, the sessions do not restart. To determine if a peer supports refresh, check for Peer supports Refresh capability in the output of the show bgp neighbor command.

Caution

If you configure keep all or keep none and the peer does not support session restart, the associated BGP sessions are restarted (flapped).

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.

Router Internet

Router North

Router South

Configuring Conditional Installation of Prefixes

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 conditional installation of prefixes:

  1. Configure the router interfaces forming the links between the three routers.
  2. Configure five loopback interface addresses on Router Internet to emulate BGP routes learned from the Internet that are to be imported into the routing table of Router South, and configure an additional address (192.168.9.1/32) that will be configured as the router ID.

    Also, configure the loopback interface addresses on Routers North and South.

  3. Configure the static default route on Router North to be advertised to Router South.
  4. Define the condition for exporting prefixes from the routing table on Router North.
  5. Define export policies (into-bgp and conditional-export-bgp ) on Routers Internet and North respectively, to advertise routes to BGP.Note

    Ensure that you reference the condition, prefix_11 (configured in Step 4), in the export policy.

  6. Define an import policy (import-selected-routes) on Router South to import some of the routes advertised by Router North into its routing table.
  7. Configure BGP on all three routers to enable the flow of prefixes between the autonomous systems.Note

    Ensure that you apply the defined import and export policies to the respective BGP groups for prefix advertisement to take place.

  8. Configure the router ID and autonomous system number for all three routers. Note

    In this example, the router ID is configured based on the IP address configured on the lo0.0 interface of the router.

Results

From configuration mode, confirm your configuration by issuing the show interfaces, show protocols bgp, 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 Internet

Device North

Device South

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

Verification

Confirm that the configuration is working properly.

Verifying BGP

Purpose

Verify that BGP sessions have been established between the three routers.

Action

From operational mode, run the show bgp neighbor neighbor-address command.

  1. Check the BGP session on Router Internet to verify that Router North is a neighbor.

    user@Internet> show bgp neighbor 10.0.89.13
  2. Check the BGP session on Router North to verify that Router Internet is a neighbor.

    user@North> show bgp neighbor 10.0.89.14

Check the following fields in these outputs to verify that BGP sessions have been established:

  • Peer—Check if the peer AS number is listed.

  • Local—Check if the local AS number is listed.

  • State—Ensure that the value is Established. If not, check the configuration again and see show bgp neighbor for more details on the output fields.

Similarly, verify that Routers North and South form peer relationships with each other.

Meaning

BGP sessions are established between the three routers.

Verifying Prefix Advertisement from Router Internet to Router North

Purpose

Verify that the routes sent from Router Internet are received by Router North.

Action

  1. From operational mode on Router Internet, run the show route advertising-protocol bgp neighbor-address command.
    user@Internet> show route advertising-protocol bgp 10.0.89.13

    The output verifies that Router Internet advertises the routes 172.16.11.1/32, 172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, 172.16.15.1/32, and 192.168.9.1/32 (the loopback address used as router ID) to Router North.

  2. From operational mode on Router North, run the show route receive-protocol bgp neighbor-address command.
    user@North> show route receive-protocol bgp 10.0.89.14

    The output verifies that Router North has received all the routes advertised by Router Internet.

Meaning

Prefixes sent by Router Internet have been successfully installed into the routing table on Router North.

Verifying Prefix Advertisement from Router North to Router South

Purpose

Verify that the routes received from Router Internet and the static default route are advertised by Router North to Router South.

Action

  1. From operational mode on Router North, run the show route 0/0 exact command.
    user@North> show route 0/0 exact

    The output verifies the presence of the static default route (0.0.0.0/0) in the routing table on Router North.

  2. From operational mode on Router North, run the show route advertising-protocol bgp neighbor-address command.
    user@North> show route advertising-protocol bgp 10.0.78.13

    The output verifies that Router North is advertising the static route and the 172.16.11.1/32 route received from Router Internet, as well as many other routes, to Router South.

Verifying BGP Import Policy for Installation of Prefixes

Purpose

Verify that the BGP import policy successfully installs the required prefixes.

Action

See if the import policy on Router South is operational by checking if only the static default route from Router North and the 172.16.11.1/32 route from Router South are installed in the routing table.

From operational mode, run the show route receive-protocol bgp neighbor-address command.

user@South> show route receive-protocol bgp 10.0.78.14

The output verifies that the BGP import policy is operational on Router South, and only the static default route of 0.0.0.0/0 from Router North and the 172.16.11.1/32 route from Router Internet have leaked into the routing table on Router South.

Meaning

The installation of prefixes is successful because of the configured BGP import policy.

Verifying Conditional Export from Router North to Router South

Purpose

Verify that when Device Internet stops sending the 172.16.11.1/32 route, Device North stops sending the default 0/0 route.

Action

  1. Cause Device Internet to stop sending the 172.16.11.1/32 route by deactivating the 172.16.11.1/32 address on the loopback interface.
  2. From operational mode on Router North, run the show route advertising-protocol bgp neighbor-address command.
    user@North> show route advertising-protocol bgp 10.0.78.13

    The output verifies that Router North is not advertising the default route to Router South. This is the expected behavior when the 172.16.11.1/32 route is not present.

  3. Reactivate the 172.16.11.1/32 address on Device Internet’s loopback interface.

Verifying the Presence of Routes Hidden by Policy (Optional)

Purpose

Verify the presence of routes hidden by the import policy configured on Router South.

Note

This section demonstrates the effects of various changes you can make to the configuration depending on your needs.

Action

View routes hidden from the routing table of Router South by:

  • Using the hidden option for the show route receive-protocol bgp neighbor-address command.

  • Deactivating the import policy.

  1. From operational mode, run the show route receive-protocol bgp neighbor-address hidden command to view hidden routes.
    user@South> show route receive-protocol bgp 10.0.78.14 hidden

    The output verifies the presence of routes hidden by the import policy (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, and 172.16.15.1/32) on Router South.

  2. Deactivate the BGP import policy by configuring the deactivate import statement at the [edit protocols bgp group group-name] hierarchy level.
  3. Run the show route receive-protocol bgp neighbor-address operational mode command to check the routes after deactivating the import policy.
    user@South> show route receive-protocol bgp 10.0.78.14

    The output verifies the presence of previously hidden routes (172.16.12.1/32, 172.16.13.1/32, 172.16.14.1/32, and 172.16.15.1/32).

  4. Activate the BGP import policy and remove the hidden routes from the routing table by configuring the activate import and keep none statements respectively at the [edit protocols bgp group group-name] hierarchy level.
  5. From operational mode, run the show route receive-protocol bgp neighbor-address hidden command to check the routes after activating the import policy and configuring the keep none statement.
    user@South> show route receive-protocol bgp 10.0.78.14 hidden

    The output verifies that the hidden routes are not maintained in the routing table because of the configured keep none statement.