Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Testing a Routing Policy with Complex Regular Expressions

This example shows how to test a routing policy using the test policy command to ensure that the policy produces the results that you expect before you apply it in a production environment. Regular expressions, especially complex ones, can be tricky to get right. This example shows how to use the test policy command to make sure that your regular expressions have the intended effect.

Requirements

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

Overview

This example shows two routing devices with an external BGP (EBGP) connection between them. Device R2 uses the BGP session to send customer routes to Device R1. These static routes have multiple community values attached.

To test a complex regular expression, Device R2 has a policy called test-regex that locates routes. The policy is configured like this:

This regular expression matches community values beginning with either 1 or 3.

Topology

Figure 1 shows the sample network.

Figure 1: Routing Policy Test for Complex Regular ExpressionsRouting Policy Test for Complex Regular Expressions

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

The section #configuration271__policy-test-regex-st 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

Procedure

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

  2. Configure BGP.

    Apply the import policy to the BGP peering session with Device R2.

  3. Configure the routing policy that sends static routes.

  4. Configure the routing policy that tests a regular expression.

  5. Configure the static routes and attaches community values.

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

    This affects Device R2’s routing table, and as no impact on Device R1 and Device R3.

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.

Test to See Which Communities Match the Regular Expression

Purpose

You can test the regular expression and its policy by using the test policypolicy-name command.

Action

  1. On Device R2, run the test policy test-regex 0/0 command.

  2. On Device R2, change the regular expression to match a community value containing any number of instances of the digit 2.

  3. On Device R2, rerun the test policy test-regex 0/0 command.

Meaning

The 172.16.1.0 /24 and 172.16.3.0/24 routes both have communities attached that match the ^64510:[13].*$ expression. The 172.16.2.0/24 route has communities that match the ^65020:2+$ expression.