Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Example: Enable IS-IS Link Delay with Source Packet Routing in Networking (SPRING) in a Layer 3 Virtual Private Network (VPN)

This example shows how to configure IS-IS link delay with SPRING in a Layer3 VPN scenario. In the example, you can create two VPNs between PE1 and PE2. VPN1 optimizes link delay and VPN2 optimizes IGP metric. Although you can configure the feature to enable bidirectional traffic in the test topology, we're focusing on a unidirectional traffic scenario in this example. Specifically, your task is to control the forwarding path for Layer 3 VPN traffic sent by PE1 to destinations advertised by PE2.

Requirements

This example uses the following hardware and software components:

  • Four MX Series routers

  • Junos OS Release 21.1R1 or later running on all devices

Topology

Figure 1: IS-IS Link Delay Topology IS-IS Link Delay Topology

In the topology, most links have a (default) IGP metric of 10, dynamic delay measurements, and blue coloring. The exceptions are the red colored path between PE1 and P1 and the static delay configuration on the P2 to PE2 link.

We've configured the test topology to support IS-IS link delay for both IPv4 and IPv6. We've configured the P2 router as a route reflector with the PE devices as its clients. To keep the topology simple, we are using static routes in the PE2 router's VRFs. This eliminates the need for CE devices and a PE-CE routing protocol such as EBGP.

Your goal is to configure the network so that the routes advertised by PE2 for VPN1 take a path that optimizes delay while also being confined to using only blue links. In contrast, traffic sent to the routes associated with VPN2 can take either a blue or red link with path optimization based on its IGP metric.

  • The Flex Algorithm Definition (FAD) for VPN1 uses algorithm 128. We've configured it to use blue colored links only (PE1>P2>P1>PE2) over a path that is optimized to reduce delay. To help demonstrate proper path selection, you configure a static delay of 20000 microseconds between P2 and PE2. This delay is significantly higher than the dynamic delay measured on the remaining links. As a result you expect flex algorithm 128 traffic to avoid the P2 to PE2 link, instead preferring additional hops along the blue color path (PE1>P2>P1>PE2).
  • The Flex Algorithm Definition (FAD) for VPN2 uses algorithm 129. We've configured it to take either blue or red links (PE1>P1>PE2 or PE1>P2>PE2), with the path optimized on IGP metric. As a result traffic using flex algorithm 129 has two equal cost paths between PE1 and PE2, both incurring two hops and a resulting metric of 20.

Overview

In IP networks, the bulk of traffic often goes through the core network, which reduces costs but might result in increased latency. Business traffic, however, often benefits from the ability to make path-selection decisions based on other performance metrics, such as path latency, rather than relaying on the traditional path optimization based simply on IGP metrics. Optimizing a path to reduce latency can greatly benefit applications like real-time voice and video. It can also enable high performance access to financial market data where milliseconds can translate into significant gains or losses.

Starting in Junos OS Release 21.1R1, you can enable IS-IS link delay in IP networks. You can achieve minimum IGP metric paths by configuring IS-IS with the appropriate link cost using the default IS-IS algorithm (0). Doing so optimizes paths to the endpoint that are based strictly on the sum of the link metrics. By using the IS-IS delay flex algorithm you can optimize paths based on their end-to-end delay.

Link delay can be dynamically measured using Two-Way Active Measurement Probes (TWAMP). The routers then flood their link delay parameters. The routers in the area store these parameters in the shared Link State Database (LSDB). Ingress nodes run an SPF algorithm against the LSDB to compute paths that are optimized on various attributes, such as link colors, IGP metric, traffic-engineering (TE) metric, or as shown in this example, link delay.

The egress router signals which flex algorithm is desired by attaching an associated color community to routes advertised through BGP. At the sending end (the local PE that has received the tagged routes advertised by the remote PE), these color communities are used to index into a color table that resolves the remote protocol next hop (the PE's loopback address) to a flex algorithm identifier. In the context of Layer 3 VPNs a color mapping policy is used at the ingress node to select which prefixes should have their next hops resolved via the color table.

The local PE then uses its local Flex Algorithm Definition (FAD) to map the flex algorithm identifier into a set of path selection criteria, for example "use blue links and optimize on delay". The ingress PE calculates the optimal path based on the values in the LSDB, pushes the related MPLS label stack onto the packet, and sends it to the associated next hop. This results in traffic-engineered MPLS paths using IS-IS as the signaling protocol.

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.

Note:

Depending on the type of MPCs in your MX Series routers you might need to explicitly enable enhanced IP services to support the IS-IS delay feature. When you commit the set chassis network-services enhanced-ip configuration statement, you will be prompted to reboot the system.

PE1

P1

P2

PE2

Step-by-step Procedure

  1. Configure the basic device settings such as hostname, IPv4, IPv6 addresses, loopback interface addresses, enhanced-ip mode, and enable the ISO and MPLS protocol families on all interfaces of all 4 routers.

  2. Configure the router-ID, autonomous system (AS) number, and apply a load balancing export policy to the forwarding table on all routers to enable load balancing of traffic.

  3. On PE1 and PE2, configure equal-cost multipath (ECMP) to enable fast reroute protection. Also configure chained composite next hop to allow the routers to point routes that share the same destination to a common forwarding next hop. This option improves forwarding information base (FIB) scaling.

  4. Enable MPLS protocol processing on all interfaces at all routers. Also enable traffic engineering.

  5. Enable TWAMP probes on all routers. These probes support dynamic measurement of the link delay between each pair of routers.

  6. Configure the IS-IS protocol for point-to-point operation (TWAMP based delay measurements are not supported on multi-point links), and enable node protection mode for Topology-Independent Loop-Free Alternate (TILFA) operation on all interfaces. You also enable passive mode IS-IS on the loopback interface and disable IS-IS level 1 to use only IS-IS level 2. Enable traffic engineering with layer 3 unicast topology to download IGP topology into the TED. Configure IS-IS to support SPRING routed paths. The prefix-sid export policy is defined in a subsequent step. This policy is used to have the local node advertise its loopback address with a mapping to one ore more flex algorithms.

  7. Configure dynamic IS-IS link delay-measurement using TWAMP probes on all IS-IS interfaces at all routers (except for the link between P2 and PE2, which uses a static delay value in this example).

  8. Configure the static delay-metric on the link between P2 and PE2.

  9. Configure PE1 and PE2 to support two Layer 3 VPNs (VPN1 and VPN2).

    Note:

    Note that the routing instances at PE2 are configured with IPv4 and IPv6 static routes. These routes are configured with the receive option to allow you to test connectivity using ping. The IS-IS delay feature operates the same if the Layer 3 VPN uses a dynamic routing protocol between the PE and an attached CE device. We use static routes in this example to keep the topology simple to allow focus on the IS-IS delay optimization feature.

  10. Configure a map policy at PE1 to enable VPN route resolution for matching prefixes against the BGP color table. This allows you to evoke flex path forwarding algorithms on a per-prefix basis. The map1 resolution policy is set to the ip-color resolution mode.

    Note:

    In a Layer 3 VPN context a mapping policy is needed to select which prefixes are allowed to have their next hop resolved in the color table. Simply having routes with extended next hops and color communities attached does not result in the use of the color table, unless a mapping policy is used.

  11. Configure VPN route export policies at PE2 to attach the desired color communities to the VPN routes it advertises to PE1 (via the route reflector). Of significance here is how the routes from VPN1 have the color community for flex path 128 (optimize delay) attached, while the routes advertised from VPN2 have the 129 color community attached (optimize IGP metric).

  12. Configure BGP peering between the PE devices and the route reflector. Configure the unicast network layer reachability information (NLRI) to support extended color next hops on the PE devices. Enabling this option allows routes with color communities to have their next hop resolve through the color table. Without the extended next hop setting route with color communities undergoing normal next hop resolution and will not use flex algorithm paths.

  13. You also enable support for IPv4 and IPv6 Layer 3 VPN unicast routes. On PE1 you apply the color mapping policies as import, so it can act on the routes received from the remote PE device.

    On PE 2 you apply export policy to attach the desired color community to the VPN route advertisements sent to PE1. The vpn-apply-export option is needed at PE2 to allow the export policies to act on VPN routes advertised to remote PEs.

  14. Define the per-packet load balancing policy on all routers.

  15. Configure support for segment routing with two flex algorithms (128 and 129) on all routers.

  16. Configure all routers to advertise their loopback address with support for both the 128 and 129 flex algorithms. The prefix-segment index option sets the base label for each router's loopback address. In this example the IPv4 base index and IPv6 base index is set to reflect the router number. As a result R0 (PE1) uses 1000 for IPv4 while R1 (P1) uses 1001.

  17. On all routers define the RED and BLUE MPLS administration groups, and assign the desired color to each interface. You also enable ICMP tunneling to allow trace route support in the context of MPLS based Layer 3 VPNs.

  18. Configure the FADs at the ingress PE device (PE1) under the routing-options hierarchy. In this case you assign flex algorithm 128 to optimize the path based on the delay-metric and 129 to optimize on the igp-metric. In this example, flex algorithm 128 must take only blue color paths, while flex algorithm 129 can take either a blue or a red color path. In this example you define the FADs at PE1 only as we focus only on the forwarding path from PE1 to PE2.

    To support bidirectional flex path forwarding you will need to define the desired FADs on the PE2 device. The P routers don't require a FAD definition as the FAD is only used by the ingress node when calculating a path to the egress node.

  19. Enter commit to from the configuration mode.

Results

Check the results of the configuration:

user@PE1# show interfaces

user@PE1# show policy-options

user@PE1# show protocols

user@PE1# show routing-options

user@PE1# show routing-instances

user@PE1# show services rpm

Verification

Verify IS-IS Adjacencies

Purpose

Verify expected IS-IS adjacencies on the routing devices.

Action

From operational mode, enter the show isis adjacency command.

Meaning

Th output indicates that PE1 has successfully formed IS-IS adjacencies on its ge-0/0/0.0 and ge-0/0/1.0 interfaces, which attach to their P1 and P2 routers, respectively.

Verify IS-IS Database

Purpose

Verify that link delay parameters are present in the IS-IS database.

Action

Use the show isis database extensive | match delay operational command.

Meaning

The output displays the dynamic delay that is associated with the various interfaces in the topology. The highlighted portion of the output specifies the static delay of 20000 microseconds that is configured on the P2 to PE2 link. The statically configured delay value is significantly higher than any of the dynamic delay measurements. This large delay is configured to make it easy to predict the delay optimized blue path through the network.

Verify BGP Peering

Purpose

Verify that both PEs have successfully established IPv4 and IPv6 peering sessions to the route reflector.

Action

Use the show bgp summary operational command. In this case we run the command on P2, the route reflector, as it provides a convenient location to confirm both peering sessions from both PEs using a single command.

Meaning

The output confirms that all BGP peering sessions are established correctly. The display also confirms that Layer 3 VPN routes are being advertised/learned over these peering sessions.

Verify Color Community on VPN Routes

Purpose

Verify the VPN routes advertised by PE2 are correctly tagged with a color community.

Action

Use the show route detail <prefix> table <table-name> operational command at PE1 to display details about a Layer 3 VPN route learned from PE2.

Meaning

The output confirms that a VPN prefix in the VPN1 routing instance has a color community color:0:128 attached. In addition, you can confirm that the protocol next hop for this route is the loopback address of the PE2 router with an extended next hop that indexes a matching entry in the color table.

Though not show, you can repeat this command for a prefix in the VPN2 table. You expect to find these routes have the color:0:129 attached.

Verify inetcolor.0 Routing Table

Purpose

Verify the inetcolor.0 routing table is correctly populated with all router IDs (loopback addresses) showing support for both the 128 and 129 flex algorithms.

Note:

IPv6 routes are supported via the inet6color.0 table. You can verify this table using the same approach as shown in this section for the IPv4 color table.

Action

Use the show route table inetcolor.0 operational command.

Meaning

The output displays the routes in the inetcolor.0 route table. The highlighted portion indicates the two routes originate from PE2. The 192.168.255.3-128<c> route has only one possible path and takes the ge-0/0/1.0 interface to P2 as a next hop. Recall that the 128 flex algorithm must use blue links, and from the perspective of PE1, which leaves only the blue colored ge-0/0/1 interface as a viable path.

In contrast, the route for 192.168.255.3-129<c> is able to load balance over both the ge-0/0/0.0 interfaces to P1 and the ge-0/0/1.0 to P2. Recall that this path for flex algorithm can take any path that is either blue or red, thus can use either of its interfaces when forwarding to its associated destination.

Verify TWAMP Operation

Purpose

Verify that TWAMP probes are operating between routers with dynamic link delay configured.

Action

Use the show services rpm twamp client operational mode command.

Meaning

The highlighted portion of the output indicates that PE1 has two TWAMP neighbors: P2 (10.0.1.2) and P1 (10.0.1.1).

If desired use the show services rpm twamp client probe-results operational mode command to see the current and historical delay measurement values.

Verify Route Resolution

Purpose

Verify the routes for the VPN1 and VPN2 resolve over the expected flex algorithm paths.

Action

Use the show route operational mode command.

Meaning

The highlighted output indicates that on the PE1 device, the 172.16.1.0 route for VPN1 uses FAD 128 taking only the blue color path, which makes P1 (10.0.2.2) its next hop while the route for VPN2, 172.16.2.0 uses FAD 129, which means it can take the red color path either through ge-0/0/0.0 interface to P1>PE2 or through the ge-0/0/1.0 interface to P2> PE2. This is also true for IPv6 routes, as shown here for VPN1:

The IPv6 route from VPN1 resolves to the same forwarding path as its IPv4 counterpart, which makes sense as they are both using flex algorithm 128 to force the use of blue links with delay optimization. Recall that you configured PE2, the source of these routes, to use a label base of 1287 for IPv4 routes and 4287 for IPv6 routes, and that the source-packet-routing srgb start-label to 8000. As a result the IPv4 route from VPN1 has a label of 81287 while the IPv6 route from VPN1 uses 84287.

Verify Forwarding Paths

Purpose

Verify the routes for VPN1 and VPN2 are forwarded over the expected flex algorithm paths.

Action

Use the ping and trace route operational mode commands to verify reachability, and to confirm the IPv4 forwarding path used by PE1 when sending traffic to VPN destinations as PE2.

Note:

The use of static routes with a receive next hop at PE2 allows you to ping the remote routes. You can expect the last hop of the trace route to timeout, however, as trace route processing is not supported when targeting an IPv4 static receive route.

Meaning

The output indicates that the expected forwarding paths are used. For example, the trace route for the 172.16.1.0/24 route in VPN1 shows that blue paths are used, and that the high-delay link between P2 and PE2 is avoided. This confirms that flex algorithm prefers a path with an extra hop if it results in a reduction of end-to-end path latency. In this case the 10.0.12.0 link between P2 and P1 is used while the direct link between P2 and PE2 is avoided.

In contrast, the path taken for the 172.16.2.0/24 route, associated with VPN2 and flex algorithm 129, is able to take either of the direct paths between PE1 and PE2. In this case the forwarding path is from PE1 to P1 and then to the destination (PE2), where as noted the last hop times out. This timeout on the last hop does not occur for routes that point to a CE device (as opposed to the static receive routes used in this example).

Though not show here for brevity, you expect the same forwarding paths for trace routes to the IPv6 VPN routes based on whether they are mapped to flex algorithm 128 or 129, which in this example means associated with VPN1 versus VPN2, respectively.