Juniper

White Paper

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

Copyright © 2012, Juniper Networks, Inc.

1

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

2

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.

3

White Paper - Route Resolution

IP/MPLS CE1

PE1

IP addr: 1.33.0.1/24

lo0 addr: 10.255.165.77

P1

PE1

CE1

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) to 1.2.0.2 via t1-0/1/1.0

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

via t1-0/1/1.0, label-switched-path r0-r1

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 hop’s 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.

4

Copyright © 2012, Juniper Networks, Inc.

White Paper - Route Resolution

Table 1. Routing Table Resolution Mapping Routing Table

Resolution Routing Table

Resolution Routing Table When the Route Preference Is Equal

inet.0

inet.3, inet.0

inet.3

inet.2

inet.2

-

inet.6

inet6.3, inet6.0

inet6.3

bgp.l3vpn.0

inet.3

-

bgp.l3vpn-inet6.0

inet6.3

-

bgp.l2vpn.0

inet.3

-

Multiple-Topology RIB :.inet.0

:.inet.0

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 happens—that 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; 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:08:44, metric2 3 > via so-0/0/0.0, label-switched-path r0-r1 show route 1.3.0.1/32 extensive | grep “Originating RIB” 10.255.165.81/32 Originating RIB: inet.3 via so-0/0/0.0, label-switched-path r0-r1