White Paper

Route Resolution
Using Mechanisms in Junos OS to Determine and Modify Route Resolution Behavior

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 How Route Resolution Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Routing Table Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Default Behavior of Route Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Changing the Default Behavior of Route Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Applying Import Policy to Route Resolution Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Case Study: Use Route Resolution with Multitopology Routing to Direct Traffic over LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Case Study: Use Route Resolution for L3VPN Route Reflector to Use IGP Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 About Juniper Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

List of Figures
Figure 1. Topology where routers have routing tables supporting IP and MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Figure 2. Topology with IP/MPLS and egress PE routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Figure 3. An IBGP core running IP/MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Figure 4. Voice traffic traverses an MPLS LSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Figure 5. Route Reflectors Receive the Same Route Announcement from Two Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

List of Tables
Table 1. Routing Table Resolution Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Executive Summary
Route resolution is the mechanism used in Juniper Networks Junos operating system to determine the action that should be taken when a route has a next hop that is an IP address. The next hop must go through its own route lookup, and in this sense, how the original route forwards traffic is determined or resolved. While there are specific default behaviors for route resolution, it is also possible to change these behaviors by using route resolution configuration commands. Having the ability to change the behavior of route resolution is a very powerful and compelling way for a provider to designate how traffic flows across the network. By reading this paper, you will gain knowledge about how route resolution works and how it can be configured using Junos OS. Several example use cases are explained including key router configurations for each use case. The first case describes how to use route resolution along with Multitopology Routing to direct traffic to use an MPLS path versus an IP path. The second case shows how route resolution can be used for L3VPN routes. This is particularly useful for a route reflector not enabled with MPLS and where ties must be broken on interior gateway protocol (IGP) metrics. Readers of this paper are expected to have a thorough understanding of routing which includes IGP, BGP, and MPLS.

Introduction
Route resolution is used to determine what the forwarding next hop should be for a particular route that has an IP address next hop. The default behavior of route resolution depends on the routing table in which the route resides, the protocol, and the route preferences of the next-hop IP addresses if there is more than one. Through route resolution configuration commands, it is possible to use a different set of criteria for lookups of next-hop IP address information. This can be useful when it is desirable to direct particular traffic in different ways. For example, it is possible through route resolution configurations to direct some traffic to use an IP path rather than a preferred MPLS path. Routes that commonly have an IP address as a next hop are internal BGP (IBGP) routes.

How Route Resolution Works

Route resolution is used when a route has a next-hop IP address that is not directly connected. This remote next-hop IP address is then used to determine the forwarding path of the original route. The module that does route resolution is often referred to as the resolver. Routes with remote next-hop IP addresses are registered with the resolver module. These may be routes such as a static route with a remote IP address as a next hop, or most commonly, an IBGP route. Some routes have forwarding next hops that are not registered with the resolver. These routes include directly connected subnets, local routes, or routes that are from an IGP. Note that a route with a forwarding next hop over an Ethernet interface has an IP address as part of the next hop. However, the resolver is not used in this case because the next-hop IP address is directly connected, and any further resolution is done using Address Resolution Protocol (ARP) (which resides in the kernel).

Routing Table Basics

Routing information is stored in routing tables and there can be numerous instances of these. For example, each address family has a separate routing table. That is, IPv4 routes reside in the routing table inet.0 , and similarly IPv6 routes reside in the routing table inet6.0. MPLS uses the routing table mpls.0 for transit and egress label-switched path (LSP) labels and uses routing table inet.3 to contain IP routes that map to ingress LSPs. Protocols such as LDP and RSVP use the information from other routing tables to populate routing table inet.3 . Routes can also populate multiple routing tables. For example, when you run an IGP along with MPLS, the loopback IP addresses reside in both routing tables inet.0 and inet.3 . It is also possible to make routes populate multiple routing tables by using rib-group configuration commands, but that is beyond the scope of this document. Figure 1 shows a simple topology where MPLS and IP forwarding are supported through the core (PE1-P1-PE2). The core is running an IGP and MPLS. The loopback addresses of the provider edge (PE) routers are stored in both of the routing tables ( inet.0 and inet.3 ).

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

IP/MPLS CE1 PE1 P1 PE1 CE1

IP addr: 1.33.0.1/24

lo0 addr: 10.255.165.77

IP addr: 10.255.165.79

IP addr: 1.44.0.1/24

Figure 1. Topology where routers have routing tables supporting IP and MPLS Example : Both IS-IS and RSVP/MPLS are configured as shown in Figure 1. The loopback address of PE2, 10.255.165.79/32, is in both inet.0 and inet.3 on router PE1:

router_PE1> show route 10.255.165.79/32 inet.0: 29 destinations, 29 routes (28 active, 0 holddown, 1 hidden) <- Route is in RIB + = Active Route, - = Last Active, * = Both 10.255.165.79/32 *[IS-IS/18] 00:00:42, metric 3 > to 1.2.0.2 via t1-0/1/1.0
<- Route is in RIB inet.0

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.255.165.79/32 *[RSVP/7] 00:00:33, metric 3 > via t1-0/1/1.0, label-switched-path r0-r1
inet.3

Default Behavior of Route Resolution

The route resolution default behavior depends on several factors. It depends on the routing table in which the route resides and the protocol associated with it. If there are next hops for this route that reside in more than one routing table, then the next hops route preference is taken into consideration. Further, if these route preferences are equal, then depending on the protocol in use, one routing table is chosen over the other. See Table 1 for some descriptions of routing tables and their corresponding route resolution mapping. For example, consider BGP routes residing in inet.0 . The default behavior is to look for the next-hop route in both inet.3 and inet.0 and prefer the one with the best preference. If there are next-hop routes with equal preference in both routing tables, then the default behavior is to use the route in inet.3 first. If the entry in inet.3 goes away, then the entry in inet.0 is used for next-hop IP address lookups. This is the behavior that occurs with no added configuration commands. A route resides in a particular routing table, and depending on which routing table it is, certain other routing table or tables are used for route resolution. Table 1 shows the mapping between routing tables and resolution routing tables for some common cases.

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Table 1. Routing Table Resolution Mapping

Routing Table
inet.0 inet.2 inet.6 bgp.l3vpn.0 bgp.l3vpn-inet6.0 bgp.l2vpn.0 Multiple-Topology RIB :<mtr_name>.inet.0

Resolution Routing Table

inet.3, inet.0 inet.2 inet6.3, inet6.0 inet.3 inet6.3 inet.3 :<mtr_name>.inet.0

Resolution Routing Table When the Route Preference Is Equal

inet.3 inet6.3 -

Example: This example shows the default behavior. Referring to Figure 1, a static route is configured on PE1 using the loopback address of PE2 for its next hop. Note that the keyword resolve must also be added to the static route, since the configured IP address of the next hop is not a directly connected route. If the next-hop address is not directly connected and you configure resolve, then normal resolution happensthat is, it looks for the next-hop IP address in inet.3 and in inet.0 (in this case the next hop IP address 10.255.165.81 is in both inet.0 and inet.3 with equal preferences, and therefore inet.3 is chosen). The subsequent show commands illustrate how the route is resolved over inet.3. Note the Originating RIB (routing table) in the output:

router_PE1> show configuration routing-options static { route 1.3.0.1/32 { next-hop 10.255.165.81; <- This is the IP address next hop (not directly connected) resolve; } } router_PE1> show route 1.3.0.1/32 inet.0: 35 destinations, 37 routes (34 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1.3.0.1/32
LSP

*[Static/5] 00:08:44, metric2 3 > via so-0/0/0.0, label-switched-path r0-r1 <- Indicates an MPLS

router_PE1> show route 1.3.0.1/32 extensive | grep Originating RIB 10.255.165.81/32 Originating RIB: inet.3 <- The next hop
comes from inet.3 Example : When the LSP is removed, the default behavior is to use inet.0 to resolve the next hop. You can tell by looking at the extensive show output of the route and look at the Originating RIB :

router_PE1# deactivate protocols mpls router_PE1# commit commit complete router_PE1 # run show route 1.3.0.1/32 extensive | grep Originating RIB 10.255.165.81/32 Originating RIB: inet.0 <- The next hop
comes from inet.0

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Changing the Default Behavior of Route Resolution

It is possible to change the default behavior of route resolution by using router configurations. Again, assuming that a next-hop route populates both inet.0 and inet.3 , it is possible to prefer one or two routing tables by using route resolution configuration commands (two is the limit). Example : This example uses route resolution configurations to resolve next hops using inet.3. By configuring in this way, inet.0 is not used if the LSP goes down (which is also shown at the end of this example). Using this configuration option ensures that the traffic only traverses an LSP and not a native IP path should the LSP go down.

router_PE1> show configuration routing-options resolution { rib inet.0 { resolution-ribs inet.3; <- Routes in inet.0 only use inet.3 to look up next-hop addresses } } router_PE1> show route 1.3.0.1/32 inet.0: 35 destinations, 37 routes (34 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1.3.0.1/32
used

*[Static/5] 00:07:00, metric2 3 > via so-0/0/0.0, label-switched-path r0-r1 <- Indicates the LSP is

router_PE1# run show route 1.3.0.1/32 extensive | grep originating 10.255.165.81/32 Originating RIB: inet.3
route in inet.3 routing table

<- The next hop

router_PE1# deactivate protocols mpls

removed

<- The LSPS go down; entries in routing table inet.3 are

router_PE1# commit commit complete router_PE1> show route 1.3.0.1/32 inet.0: 35 destinations, 37 routes (32 active, 0 holddown, 3 hidden) <- No route if no LSP router_PE1> show route 1.3.0.1/32 hidden <- The route becomes hidden

inet.0: 38 destinations, 39 routes (35 active, 0 holddown, 3 hidden) + = Active Route, - = Last Active, * = Both 1.3.0.1/32 [Static/5] 00:10:55 Unusable <- The static route is now unusable

It is also possible to force route resolution to only be performed over inet.0 and not over inet.3 .

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Example : This example uses route resolution configurations to force routes in inet.0 to only look for next-hop addresses in inet.0 (and not inet.3 as the normal default). By configuring in this way, inet.3 is not used for route resolution whether the LSP (and hence the entry in inet.3 ) is there or not:

router_PE1> show configuration routing-options resolution { rib inet.0 { resolution-ribs inet.0; <- Routes in inet.0 only resolve over inet.0 } }

router_PE1> show route 1.3.0.1/32 inet.0: 35 destinations, 37 routes (34 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1.3.0.1/32 *[Static/5] 00:21:28, metric2 3 > to 1.12.0.2 via so-0/0/0.0
<- Indicates an IP path is used

router_PE1> show route 1.3.0.1/32 extensive | grep originating 10.255.165.81/32 Originating RIB: inet.0
route in inet.0 routing table

<- The next hop

router_PE1> show route table inet.3 10.255.165.81/32 <- The next hop IP address is also in
inet.3, but as seen above, it is not used

inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.255.165.81/32 *[LDP/9] 00:21:45, metric 1 > via so-0/0/0.0, Push 300000

Applying Import Policy to Route Resolution Configurations

In some cases it may be desirable to apply a specific resolution behavior to a particular routing table. You can do this by using an import statement along with a policy on the resolution configurations. This tells the resolver which routes can be used and from which originating routing table. Note that the import policy only cares about the routes that are used to resolve next hops and not the actual routes themselves. That is, a typical import policy will have a list of IP addresses that are next-hop addresses. The actual routes are affected by the resolver import policy, but only indirectly. The resolution import policy only matches active routes in the specified routing table. Further, there is no way to indicate protocol choice. That is, the route with the best preference is chosen and it is not possible to indicate a particular protocol (for example, LDP or RSVP). One of the first questions that comes to mind is why would you want to use an import policy? One example is where you have two potential egress PE routers and you want traffic to go towards one PE router using MPLS and traffic towards the other PE router using native IP. It is possible to do this with route resolution along with a route resolution import policy.

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Figure 2 shows a network topology where ingress traffic to PE0 (from CE0) may egress either PE1 or PE2.

IGPP and MPLS Run In The Core CE0 PE0

fe-0/2/3 lo0: 10.255.72.170

P1

PE1

CE1

PE2

CE2

lo0: 10.255.72.168

Figure 2. Topology with IP/MPLS and egress PE routers Example : This example shows a simple case using static routes (the same concepts may be applied to a large set of IBGP routes). Configure two static routes along with IP addresses as next hops along with the resolve command. The next-hop IP addresses are the loopback IP addresses of the remote PE routers and reside in both inet.0 and inet.3 with the same route preferences. Next, configure route resolution to use both inet.3 and inet.0 along with an import policy. Note that if there were no import policy, the resolution configuration would be the same as the default behavior. And finally, configure a policy indicating which routing table each next-hop IP address should come from. This last step is how the path is chosen to use MPLS or IP depending on the egress PE router.

router_PE0> show configuration routing-options static { route 1.55.0.1/32 { next-hop 10.255.72.168; <- Next-hop IP address for 1.55.0.1/32 resolve; } route 1.66.0.1/32 { next-hop 10.255.72.170; <- Next-hop IP address for 1.66.0.1/32 resolve; } } resolution { rib inet.0 { resolution-ribs [ inet.3 inet.0 ]; <- Inet.0 routes may be resolved over inet.3 or inet.0 import PE1_mpls_PE2_ip; <- This policy determines how/which routing tables to } } router_PE0# show policy-options policy-statement PE1_mpls_PE2_ip { term a { from { rib inet.3; <- Indicates routes in routing table inet.3 route-filter 10.255.72.170/32 exact; <- Indicates PE1s loopback IP address } then accept; }
use

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

term b { from { rib inet.0; <- Indicates routes in routing table inet.0 route-filter 10.255.72.168/32 exact; <- Indicates PE2s loopback IP address } then accept; } term c { then reject; }

At this point, static route 1.55.0.1/32 uses a next hop that is in inet.0 (an IP forwarding path), and 1.66.0.1 uses a next hop that is in inet.3 (an MPLS forwarding path):

router_PE0 > show route 1.55.0.1/32 inet.0: 36 destinations, 37 routes (35 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1.55.0.1/32 *[Static/5] 00:15:29, metric2 2 > to 1.3.0.2 via fe-0/2/3.0 <- Path is IP router_PE0> show route 1.55.0.1/32 extensive | grep Orig 10.255.72.168/32 Originating RIB: inet.0 <- 1.55.0.1/32 route uses
inet.0

router_PE0> show route 1.66.0.1/32 inet.0: 36 destinations, 37 routes (35 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 1.66.0.1/32 *[Static/5] 00:15:38, metric2 66 > to 1.3.0.2 via fe-0/2/3.0, label-switched-path r0-r2 <- MPLS
next hop

router_PE0> show route 1.66.0.1/32 extensive | grep Orig 10.255.72.170/32 Originating RIB: inet.3 <- 1.66.0.1/32 route uses
inet.3

BGP
In a network running IBGP, each BGP announcement sent by a router to its peers includes a protocol next hop. This protocol next hop is an address that is associated directly with the router that announced the update into the core. The protocol next-hop address is typically the loopback address of the advertising router. On the receiving router, the underlying IGP is used to determine the path to reach the protocol next-hop address, and then traffic is directed towards this protocol next-hop forwarding entry. Through configuration commands, you can indicate that specific routing tables should be used to resolve BGP routes. It is also possible to resolve routes over a set of up to two routing tables. An IBGP update sent from one router to its neighbor includes a protocol next-hop address. The receiver of the IBGP update knows to forward traffic which is destined for the IP address associated with the update towards the protocol next hop included in the update. Route resolution is performed on a particular routing table in order to look up the protocol next-hop address, and based on that lookup, the forwarding next-hop information. By default, an IPv4 protocol next-hop address is resolved over the routing table inet.3 , assuming the next-hop address is in inet.0 and inet.3 routing tables with equal preferences. If the next-hop address is not present in inet.3 , it is resolved using routing table inet.0.

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Figure 3 shows a network with an IBGP core. CE1 is announcing routes to PE1. PE1 then announces these routes as IBGP updates to neighbor PE2. PE1 uses its loopback address, 10.255.165.93 , as the protocol next hop in the IBGP route announced to PE2.

IGPP Core Runing Over An IGP P1 P2

CE1

Routing Updates

/0 /0 -0 o s IBGP Rounting Updates lo0 10.255.165.93 is the protocol next hop fe -0 lo0: /2 /0 10.255.165.93

PE1

ge -1

/3

/0

PE2

CE2

t1-0/1/0 lo0: 10.255.165.99

P3

P4

Figure 3. An IBGP core running IP/MPLS Routes can reside in more than one routing table. In fact, it is typical for an IBGP core running MPLS to have all the router loopback addresses in inet.3 as well as in inet.0 . It is possible through configuration commands to indicate which routing table or tables should be preferred when performing route resolution.

Case Study: Use Route Resolution with Multitopology Routing to Direct lo0: Traffic over LSPs 10.255.72.168
A provider requires a certain type of application traffic such as voice to traverse a particular RSVP/MPLS LSP. This may be because the LSP is engineered so that it traverses uncongested links or for a number of other reasons. In addition, application voice traffic must be able to use basic IP as a backup path. The provider requires that the non-voice application traffic traverse basic IP paths. The provider would like to accomplish this by keeping the customer edge (CE) routers and provider (P) routers as simple as possible, and have additional necessary capabilities limited to the PE routers. It is possible to accomplish this by using multitopology BGP routing capabilities along with route resolution on the PE routers. By populating topology routing tables on a PE router with particular BGP updates, and configuring route resolution to prefer inet.3, traffic is directed over LSPs. The RSVP/MPLS LSP operates like any LSP traversing an IBGP core. Figure 4 shows an LSP between PE1 and PE2, where the LSP traverses routers P1 and P2.

10

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Voice Uses LSP MPLS LSP P1

11.19.56/30

P2

CE1
fe-0/2/1 11.19.30/30

PE1

11.19.6/30 11.19.15/30 11.19.1/30

11.19.25/30

PE2

CE2

IBGP Core
11.19.27/30 lo0: 10.255.165.99 11.19.141.1

lo0: 10.255.165.93

11.19.17/30 Default Tolology Voice Topology MPLS LSP

P3

P4

Figure 4. Voice traffic traverses an MPLS LSP To make separate decisions for groups of routes, you can use the community in a BGP update to determine which topology to add the route to. That is, BGP routing updates that are received with certain community values are considered members of a particular routing topology and therefore copied into that routing topologys routing table. Note that it is up to the CE device provider to set the desired community values in the BGP updates announced to the ingress PE router through policy configurations. It is up to the provider, through configurations on the PE router, to indicate which communities are members of which topologies. All BGP updates, (including updates which are members of a routing topology), populate the default topology routing table inet.0 . The protocol next-hop address in the BGP update is used during route resolution to determine the forwarding path. By using configuration commands, it is possible to indicate which routing tables should be used as a first and second lookup for this address. For example, route resolution may be configured to choose an MPLS path by looking for the protocol next-hop address in the routing table inet.3 first, and, if not found, by looking in routing table inet.0 second. To populate inet.3, basic traffic engineering is enabled on OSPF PE and P routers. This adds the loopback addresses of the PE routers into inet.3. This is very basic and no new resolution or multitopology-related commands are needed to accomplish this. The following examples show how to configure the PE routers for multiple routing topologies, route resolution, and very basic MPLS on the PE routers. This is followed by an example of basic BGP export policies for the CE router. Finally, we show an example of how to configure the router to handle forwarding plane traffic as it enters the PE router. On a PE router, you can use multitopology configurations to create a specific routing table ( :voice.inet.0 ). Example : This configuration shows how a topology named voice is created. It is configured under routing-options on the PE routers:

routing-options { topologies { family inet { topology voice; } } }

The topology routing table :voice.inet.0 may now be populated with routes. The PE router has a way of associating BGP routes with particular communities in a topology, and in this way, the routes are added to the topology routing table.

Copyright 2012, Juniper Networks, Inc.

11

White Paper - Route Resolution

Example : Both internal and external BGP configurations indicate that any BGP update with community value target:40:40 should be replicated into the voice topology routing table :voice.inet.0 . The configuration stanza below shows how this is done on PE1:

protocols { bgp { group ibgp { type internal; local-address 10.255.165.93; family inet { unicast { topology voice { community 40:40; } } } export nhs; neighbor 10.255.165.99; } group ebgp { type external; local-address 11.19.30.1; family inet { unicast { topology voice { community 40:40; } } } peer-as 101; neighbor 11.19.30.2; } } }
Once the routes are in the topology routing table, route resolution can be configured to change its default behavior for protocol next-hop route lookups. Route resolution is configured to first look for the protocol next-hop address in routing table inet.3 and, if it is not found, then it is configured to look in routing table inet.0 . This means that the LSP is preferred over basic IP, thus allowing a fallback path over basic IP. Example : The following stanza under rib :voice.inet.0 shows how route resolution for routing table :voice. inet.0 is configured to check for protocol next-hop addresses in inet.3 and then inet.0 . The stanza under rib inet.0 indicates that protocol next-hop addresses in routing table inet.0 resolve over inet.0 (and not inet.3 ). This is so that non-voice traffic does not use the LSP when it arrives on the PE router, since by default protocol next hops lookups are done on inet.3 first and then on inet.0 .

routing-options { resolution { rib :voice.inet.0 { resolution-ribs [ inet.3 inet.0 ]; } rib inet.0 { resolution-ribs inet.0; } } }

12

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Basic RSVP/MPLS and OSPF with traffic engineering are configured on the PE and P routers. Traffic engineering configured under OSPF causes the loopback addresses of the participating routers in the core to populate in inet.3 . Note that these addresses also include the protocol next-hop addresses of the IBGP routes. Example : The following configuration stanzas show how RSVP/MPLS and OSPF are configured on PE2. An MPLS LSP is needed for the voice application traffic.

protocols { rsvp { interface ge-1/3/0; interface t1-0/1/0; } mpls { label-switched-path r0-r2 { to 10.255.165.93; } interface ge-1/3/0.0; interface t1-0/1/0; } ospf { traffic-engineering; area 0.0.0.0 { interface ge-1/3/0.0; interface t1-0/1/0; interface lo0.0 { passive; } } } }
BGP routes are announced from the CE router to the ingress PE router with community value target:40:40 . This community is used to associate the BGP route with the voice routing topology. Example : The configuration below shows the configuration from CE1. These are very basic configurations with nothing specific to routing topologies:

protocols { bgp { group ebgp { type external; local-address 11.19.30.2; export set_community; peer-as 100; neighbor 11.19.30.1; } } } policy-options { policy-statement set_community { term a { then { community add voice; accept; } } } community voice members target:40:40; }

Copyright 2012, Juniper Networks, Inc.

13

White Paper - Route Resolution

The forwarding plane uses firewall filters to direct traffic using a routing topology. Import firewall filters are applied on the ingress PE router interfaces (CE router facing). This is only necessary on the PE router ingress interfaces and not on the core interfaces (P router facing). Please see: www.juniper.net/us/en/local/pdf/whitepapers/2000308-en.pdf for more information on how to use Multitopology Routing along with firewalls. Example : The firewall configuration below from PE1 indicates that if a packet has expedited-forwarding Differentiated Services code points (DSCPs) set in the IP packet header, forwarding topology :voice.inet.0 is used. The DSCP bits are typically set on the traffic at the application level before the traffic enters the CE router.

interfaces { fe-0/2/1 { unit 0 { family inet { filter { input ef_path; } address 11.19.30.1/24; } } } } class-of-service { interfaces { fe-0/2/1 { unit 0 { classifiers { inet-precedence default; } } } } } firewall { family inet { filter ef_path { term ef { from { forwarding-class expedited-forwarding; } then topology voice; } term default { then accept; } } } }
At this point all of the necessary components have been configured. The following traceroute examples show that traffic is indeed taking MPLS versus an IP path through the core, depending on how the traffic DSCP bits have been set. Any traffic with DSCP bits set, where there is no associated route in the topology forwarding tables, is dropped as expected.

14

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Example : The following traceroute shows voice traffic CE1 -> CE2 using basic IP where no DSCP bits are set. Comparing this traceroute to Figure 4 above, the path follows the IP path CE1-PE1-P3-P2-PE2-CE2:

rtr-CE1> traceroute 11.19.141.1 source 11.19.131.1 traceroute to 11.19.141.1 (11.19.141.1) from 11.19.131.1, 30 hops max, 40 byte packets 1 11.19.30.1 (11.19.30.1) 0.800 ms 0.693 ms 0.656 ms 2 11.19.1.2 (11.19.1.2) 0.593 ms 0.596 ms 0.514 ms <- this hop is via P3 3 11.19.15.2 (11.19.15.2) 0.727 ms 0.762 ms 0.687 ms 4 11.19.25.1 (11.19.25.1) 0.707 ms 0.618 ms 0.566 ms 5 11.19.141.1 (11.19.141.1) 0.978 ms 0.936 ms 0.883 ms
Example : The following voice traceroute shows CE1 <- CE2 taking the MPLS path when DSCP bits are set. Comparing this traceroute to Figure 3 above, the path follows the MPLS LSP, CE1-PE1-PE2-CE2:

rtr-CE1> traceroute 11.19.141.1 source 11.19.131.1 tos 160 traceroute to 11.19.141.1 (11.19.141.1) from 11.19.131.1, 30 hops max, 40 byte packets 1 11.19.30.1 (11.19.30.1) 0.873 ms 0.668 ms 0.622 ms 2 11.19.6.2 (11.19.6.2) 0.960 ms 0.888 ms 0.849 ms <- this hop is via the LSP MPLS Label=299776 CoS=2 TTL=1 S=1 3 11.19.56.1 (11.19.56.1) 0.982 ms 0.932 ms 0.881 ms MPLS Label=300144 CoS=2 TTL=1 S=1 4 11.19.25.1 (11.19.25.1) 36.360 ms 0.589 ms 0.610 ms 5 11.19.141.1 (11.19.141.1) 9.964 ms 0.913 ms 0.860 ms
Example : The following voice traceroute shows the traffic being dropped because prefix 11.19.142/24 is not in the voice topology routing table ((which is where the router looks due to the type of service (ToS) bits being set)).

rtr-CE1> traceroute 11.19.142.1 source 11.19.131.1 tos 160 traceroute to 11.19.142.1 (11.19.142.1) from 11.19.131.1, 30 hops max, 40 byte packets 1 11.19.30.1 (11.19.30.1) 0.758 ms !N 0.676 ms !N 0.620 ms !N <- this drop is
expected

Case Study: Use Route Resolution for L3VPN Route Reflector to Use IGP Metrics
A route reflector is often used as a non-traffic forwarding router to announce L3VPN BGP routes. An interesting situation arises when the route reflector does not run MPLS and therefore does not have an inet.3 routing table, yet it must still announce L3VPN BGP routes. For non-forwarding route reflectors advertising L3VPN BGP routes, there must be an entry in inet.3 in order for the routes to be installed as active routes and subsequently announced as BGP updates to route reflector clients. It is common for users to configure a static default route used to populate inet.3. This route, however, has no useful metrics on which to make intelligent path selection decisions. An alternative to populating inet.3 is to configure route resolution to resolve routes over inet.0 rather than inet.3 . In this way, all important IGP metrics are available to make logical path selection decisions, and there is no need for a discard route in inet.3. Note that there is also a third option where all of the IGP inet.0 routes are replicated into inet.3 through rib-group configurations, but this is beyond the scope of this document. There are some advantages to having route resolution use inet.0 instead of using a statically configured route in inet.3: There are no entries in route table inet.3 (since MPLS is not configured) and you must configure a static route. This is often confusing to users. By configuring the resolver to use inet.0, IGP metrics may be used for BGP path selection. This is useful for tie breaking when there are similar route-distinguishers being used on a route. By contrast, when relying on a static route in inet.3, there are no associated IGP metrics to use for BGP tie breaks and the ties are then broken on router ID.

Copyright 2012, Juniper Networks, Inc.

15

White Paper - Route Resolution

Figure 3 shows two route reflectors, A in San Francisco and B in Tokyo. Assume that CE2 and CE3 are both announcing the same route, 12.19.150/24 , to PE2 and PE3 respectively. The route reflectors receive these L3VPN BGP updates and make decisions on which update to prefer.

Route Reector A (San Francisco) L3VPN BGP Routes Sent to Other Clients

Route Reector B (Tokyo) L3VPN BGP Routes Sent to Other Clients

lo0: 10.255.72.46 IGP

lo0: 10.255.72.47

PE1 Client

PE2 Client
1.24.0/24 MPLS LSP/IGP lo0: 10.255.72.50

MPLS LSP/IGP

PE3 Client
1.35.0/24 lo0: 10.255.72.48 MPLS LSP/IGP

PE3 Client

1.48.0/24

1.59.0/24

CE1

CE2

12.19.150/24 Announced

12.19.150/24 Announced

CE3

CE4

Figure 5. Route Reflectors Receive the Same Route Announcement from Two Locations If there is no definitive tie breaking criteria, route reflectors A and B choose the best path for L3VPN BGP updates by breaking the tie on router ID. Assuming that PE3 has a preferable router ID, CE1 would send traffic destined to 12.19.150/24 through Tokyo where it could have used the San Francisco connected PE2 router (which is an entire continent closer and obviously preferable). For this reason, it is desirable to break ties using an IGP metric rather than a router ID. It is possible to break ties on the IGP metric by using some simple route resolution configuration commands. Example: The following stanza shows how you can configure route reflector A to use inet.0 instead of inet.3 for route resolution. Note that the configuration indicates that the resolution changes should be applied to the routing table bgp.l3vpn.0, which is where all of the L3VPN routes reside.

routing-options { resolution { rib bgp.l3vpn.0 { resolution-ribs inet.0; } } }

The route 12.19.150/24, advertised by both CE2 and CE3, now breaks the tie based on an IGP metric. Router reflector A prefers the route advertised by PE2 and route reflector B prefers the route advertised by PE3.

16

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Example : On route reflector A, the tie is broken based on an IGP metric preferring PE2: rtr-RR-A> show route 12.19.150.0/24 extensive

bgp.l3vpn.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) 1:1:12.19.150.0/24 (2 entries, 1 announced) TSI: Page 0 idx 0 Type 1 val 8f76db0 Nexthop: 10.255.72.50 Localpref: 100 AS path: [100] 102 I Communities: target:10:10 Cluster ID: 1.1.1.1 Originator ID: 10.255.72.50 Page 0 idx 1 Type 1 val 8f76ac8 Nexthop: 10.255.72.50 Localpref: 100 AS path: [100] 102 I Communities: target:10:10 Cluster ID: 1.1.1.1 Originator ID: 10.255.72.50 Advertise: 00000002 Path 1:1:12.19.150.0 from 10.255.72.50 Vector len 4. Val: 0 1 *BGP Preference: 170/-101 Route Distinguisher: 1:1 Next hop type: Indirect Next-hop reference count: 1 Source: 10.255.72.50 Protocol next hop: 10.255.72.50 <- PE2 is preferred Push 300336 Indirect next hop: 2 no-forward State: <Active Int Ext> Local AS: 100 Peer AS: 100 Age: 5:47 Metric2: 1 Task: BGP_100.10.255.72.50+179 Announcement bits (1): 0-BGP RT Background AS path: 102 I Communities: target:10:10 Accepted VPN Label: 300336 Localpref: 100 Router ID: 10.255.72.50 Indirect next hops: 1 Protocol next hop: 10.255.72.50 Metric: 1 Push 300336 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 1 Next hop type: Router Next hop: via so-0/2/3.0 10.255.72.50/32 Originating RIB: inet.0 Metric: 1 Node path count: 1 <- IGP metric
of next hop

Forwarding nexthops: 1 Nexthop: via so-0/2/3.0 BGP Preference: 170/-101 Route Distinguisher: 1:1 Next hop type: Indirect Next-hop reference count: 1 Source: 10.255.72.47

Copyright 2012, Juniper Networks, Inc.

17

White Paper - Route Resolution

Push 300304 Indirect next hop: 2 no-forward State: <Int Ext> Inactive reason: IGP metric <- tie is broken on IGP metric Local AS: 100 Peer AS: 100 Age: 5:44 Metric2: 2 Task: BGP_100.10.255.72.47+179 AS path: 103 I (Originator) Cluster list: 2.2.2.2 AS path: Originator ID: 10.255.72.48 Communities: target:10:10 Accepted VPN Label: 300304 Localpref: 100 Router ID: 10.255.72.47 Indirect next hops: 1 Protocol next hop: 10.255.72.48 Metric: 2 Push 300304 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 1 Next hop type: Router Next hop: via so-0/2/3.0 10.255.72.48/32 Originating RIB: inet.0 Metric: 2 Node path count: 1 <- IGP Forwarding nexthops: 1 Nexthop: via so-0/2/3.0
Traffic from CE1 destined to 12.19.150/24 traverses PE2. Similarly, traffic from CE4 destined to the same route traverses PE3. In this way, traffic does not unnecessarily traverse remote continents. Example : The example below shows the path traffic takes from CE1 destined to 12.19.150/24 . metric of next hop

rtr-CE1> traceroute 12.19.150.3 traceroute to 12.19.150.3 (12.19.150.3), 30 hops max, 40 byte packets 1 1.48.0.1 (1.48.0.1) 2.116 ms 2.020 ms 1.950 ms 2 1.24.0.1 (1.24.0.1) 2.943 ms 2.864 ms 2.835 ms <- via PE2 MPLS Label=300336 CoS=0 TTL=1 S=1 3 12.19.150.3 (12.19.150.3) 11.838 ms 3.518 ms 3.475 ms
Example : The example below shows the path traffic takes from CE4 destined to 12.19.150/24 .

rtr-CE4> traceroute 12.19.150.3 traceroute to 12.19.150.3 (12.19.150.3), 1 1.59.0.1 (1.59.0.1) 1.798 ms 1.687 2 1.35.0.1 (1.35.0.1) 2.628 ms 2.527 MPLS Label=300304 CoS=0 TTL=1 S=1 3 12.19.150.3 (12.19.150.3) 3.152 ms

30 hops max, 40 byte packets ms 1.646 ms ms 2.494 ms <- via PE3 3.078 ms 3.033 ms

18

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

In order to show the contrasting behavior between the examples explained thus far as well as other ways customers configure route reflectors to handle L3VPN routes, consider the case where a static route is added to inet.3 . Example : Use a static route to discard rather than perform a route resolution. Once this configuration change has been made, you will see that the tie is broken based on router ID (note that the resolution stanza has been replaced with a static route in inet.3).

routing-options { rib inet.3 { static { route 0.0.0.0/0 { discard; metric 65000; } } } } rtr-RR-A> show route 12.19.150/24 extensive | match inactive Inactive reason: Router ID rtr-RR-A> show route 12.19.150/24 extensive bgp.l3vpn.0: 5 destinations, 6 routes (5 active, 0 holddown, 0 hidden) 1:1:12.19.150.0/24 (2 entries, 1 announced) TSI: Page 0 idx 1 Type 1 val 8f76d38 Nexthop: 10.255.72.48 Localpref: 100 AS path: [100] 103 I (Originator) Cluster list: 2.2.2.2 Originator ID: 10.255.72.48 Communities: target:10:10 Cluster ID: 1.1.1.1 Originator ID: 10.255.72.48 Path 1:1:12.19.150.0 from 10.255.72.47 Vector len 4. Val: 1 *BGP Preference: 170/-101 Route Distinguisher: 1:1 Next hop type: Indirect Next-hop reference count: 1 Source: 10.255.72.47 Protocol next hop: 10.255.72.48 <- via PE3 (rather than PE2) Push 300304 Indirect next hop: 2 no-forward State: <Active Int Ext> Local AS: 100 Peer AS: 100 Age: 2:25 Metric2: 65000 Task: BGP_100.10.255.72.47+179 Announcement bits (1): 0-BGP RT Background AS path: 103 I (Originator) Cluster list: 2.2.2.2 AS path: Originator ID: 10.255.72.48 Communities: target:10:10 Accepted VPN Label: 300304 Localpref: 100 Router ID: 10.255.72.47 Indirect next hops: 1 Protocol next hop: 10.255.72.48 Metric: 65000

Copyright 2012, Juniper Networks, Inc.

19

White Paper - Route Resolution

Push 300304 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 0 Next hop type: Discard 0.0.0.0/0 Originating RIB: inet.3 Metric: 65000 Node path count: 1 Forwarding nexthops: 0 Next hop type: Discard BGP Preference: 170/-101 Route Distinguisher: 1:1 Next hop type: Indirect Next-hop reference count: 1 Source: 10.255.72.50 Protocol next hop: 10.255.72.50 Push 300336 Indirect next hop: 2 no-forward State: <Int Ext> Inactive reason: Router ID <- The tie is broken on Router ID Local AS: 100 Peer AS: 100 Age: 17:31 Metric2: 65000 Task: BGP_100.10.255.72.50+179 AS path: 102 I Communities: target:10:10 Accepted VPN Label: 300336 Localpref: 100 Router ID: 10.255.72.50 Indirect next hops: 1 Protocol next hop: 10.255.72.50 Metric: 65000 Push 300336 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 0 Next hop type: Discard 0.0.0.0/0 Originating RIB: inet.3 Metric: 65000 Node path count: 1 Forwarding nexthops: 0 Next hop type: Discard
Example : CE1 now traverses PE3 to reach 12.19.150/24 (this is not an efficient path).

rtr-CE1> traceroute 12.19.150.3 traceroute to 12.19.150.3 (12.19.150.3), 1 1.48.0.1 (1.48.0.1) 2.128 ms 2.032 2 * * * 3 1.23.0.2 (1.23.0.2) 3.080 ms 2.879 MPLS Label=300304 CoS=0 TTL=1 S=1 4 12.19.150.3 (12.19.150.3) 3.471 ms

30 hops max, 40 byte packets ms 1.959 ms ms 2.834 ms <- via PE3 (rather than PE2) 3.395 ms

3.429 ms

20

Copyright 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Conclusion
Route resolution is the mechanism used in Junos OS to determine the action that should be taken when a route has a next hop that is an IP address. Route resolution configuration commands provide a powerful mechanism for changing the way IBGP evaluates protocol next-hop addresses. It is possible to configure the router to perform route resolution on protocol next hops in a particular routing table. With multiple topologies, it is possible to indicate that inet.3 and then inet.0 should be used to resolve protocol next hops (rather than the topology routing table). This means that you can have traffic traverse an MPLS LSP as its primary path and traverse an IP path for its backup path. For L3VPN prefixes, it is possible to indicate that route resolution of protocol next hops should use routing table inet.0 (rather than inet.3). This is useful for route reflectors that are not running MPLS and yet are announcing L3VPN routes. Finally, the resolver may be used in many other contexts, such as resolving L2VPN/L2 circuit pseudowire and VPLS routes in mpls.0.

About Juniper Networks

Juniper Networks is in the business of network innovation. From devices to data centers, from consumers to cloud providers, Juniper Networks delivers the software, silicon and systems that transform the experience and economics of networking. The company serves customers and partners worldwide. Additional information can be found at www.juniper.net.

Corporate and Sales Headquarters Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Phone: 888.JUNIPER (888.586.4737) or 408.745.2000 Fax: 408.745.2100 www.juniper.net

APAC Headquarters Juniper Networks (Hong Kong) 26/F, Cityplaza One 1111 Kings Road Taikoo Shing, Hong Kong Phone: 852.2332.3636 Fax: 852.2574.7803

EMEA Headquarters Juniper Networks Ireland Airside Business Park Swords, County Dublin, Ireland Phone: 35.31.8903.600 EMEA Sales: 00800.4586.4737 Fax: 35.31.8903.601

To purchase Juniper Networks solutions, please contact your Juniper Networks representative at 1-866-298-6428 or authorized reseller.

Copyright 2012 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

2000354-001-EN

Feb 2012

Printed on recycled paper

Copyright 2012, Juniper Networks, Inc.

21