LSPs and Routing Table Integration

LY
<Chapter Title>

N
O
SE
U
AL
N
R
TE
IN
LSPs and Routing Table Integration

LY
N
O
SE
U
The Use of the inet.3 Routing Table
AL

Which types of traffic should see and use established LSPs? In the JUNOS software
implementation of MPLS, the default behavior makes BGP the only protocol that is
aware of the presence of LSPs, and only then when BGP attempts to resolve the next
hops associated with advertised prefixes.
N

Because MPLS LSPs are often used to engineer and direct transit traffic across an
ISP’s backbone, the default behavior results in internal traffic, which is not associated
R

with a BGP next hop, continuing to use IGP forwarding. The result is that transit traffic
associated with a BGP next hop that resolves through the inet.3 table is subjected
to LSP forwarding while all other traffic remains unaware of the LSP’s presence. To
TE

maintain this separation from the normal IGP routing table, LSPs are normally
installed in the inet.3 table only.

BGP Installs LSP as Next Hop

IN

When attempting to resolve the BGP next hop associated with a given prefix, BGP first
looks in the inet.3 table. If the next hop can be resolved in the inet.3 table, the
resulting LSP is installed into the forwarding table as the next hop for that BGP prefix.
If the next hop cannot be resolved in inet.3, BGP next attempts to resolve the next
hop through the main inet.0 table.

2 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
Route Resolution
AL

The example in the next series of slides shows how a router uses the information
learned by BGP to direct transit traffic onto an LSP. We begin by examining how traffic
is forwarded to the 134.112/16 network from the perspective of CoreNet.
Things start with the 134.112/16 prefix being learned by the New York router through
N

its EBGP session to YankeeNet. The San Francisco router then learns about 134.112/
16 through its IBGP session to New York. The San Francisco router installs the prefix
R

as active and readvertises the prefix to the Hawaii router, again using EBGP.
In this example, routers in AlohaNet begin sending traffic to 134.112/16 prefixes
TE

through San Francisco. When this transit traffic arrives at the San Francisco router, it
must decide how to forward this transit traffic to 134.112/16.
So far, nothing in this example has anything to do with MPLS or traffic engineering.
This has simply been a recap of conventional BGP operation.
IN

© 2008 Juniper Networks, Inc. All rights reserved. 3

LSPs and Routing Table Integration

LY
N
O
SE
U
Unusable BGP Next Hop
AL

This example backs up the process a bit and looks at a common problem with BGP
routes: unusable next hops. This discussion helps reinforce the interaction of BGP and
LSP routing table integration. Note that the previous slide shows the San Francisco
router advertising the 134.112/16 prefix to a router in AlohaNet. A route with an
N

unusable next hop cannot be active and, therefore, cannot be exported from the
routing table.
R

A look at the routing table on the San Francisco router reveals that the router has
learned the 134.112/16 through BGP, but it also shows that the route cannot be
used. The route learned from the New York router to 134.112/16 is hidden, which is
TE

why the all switch was added to the show route command in the example. More
investigation is necessary to determine why.
Again, there is no MPLS traffic engineering in this example.
IN

4 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
Why the Route Is Hidden
AL

An extensive view of the 134.112/16 prefix at the San Francisco router shows that
the next hop for this route is unusable, even though the correct next hop for the route
is listed. At this point, it appears that the San Francisco router does not know how to
get to the next hop 10.0.29.1 connected to New York.
N

The problem here is that the 10.0.29/30 prefix used to support the EBGP peering
session between New York and Boston is not advertised by CoreNet’s IGP. Put simply,
R

the problem is that San Francisco does not have a route to 10.0.29/30.
Once again, there is still no MPLS traffic engineering in this example.
TE
IN

© 2008 Juniper Networks, Inc. All rights reserved. 5

LSPs and Routing Table Integration

LY
N
O
SE
U
Setting Next-Hop Self Is a Viable Solution
AL

This slide solves the 134.112/16 hidden route problem at San Francisco through a
next-hop self policy applied at the New York router. A next-hop self solution is one of
several viable ways to correct unreachable BGP next hops.
Setting next-hop self on the New York router results in the route advertisement for
N

134.112/16 arriving at the San Francisco router with a BGP next hop that represents
the New York router’s loopback address. The San Francisco router can resolve the
R

New York router’s loopback address because the IGP running throughout the AS
advertises that information.
TE

At this stage, transit connectivity to 134.112/16 destinations is now provided by

CoreNet. This connectivity is based on IGP forwarding, however.
As before, no MPLS traffic engineering features are enabled at this point.
IN

6 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
LSP from San Francisco to New York Is Configured
AL

Now that we applied next-hop self to the BGP route making it usable. The sample
network is ready for MPLS traffic engineering to enter the fray.
The key aspects of the configuration at San Francisco that define an RSVP-signaled
LSP to New York are shown on the slide. Once established, the LSP is the preferred
N

route to 134.112/16 because BGP looks up a prefix in the inet.3 table (for LSPs)
before looking in the inet.0 table (used by IGPs) and because LSPs are preferred
R

over IGP routes due to route preference.

Although not shown, we assume that baseline MPLS and RSVP functionality is
TE

correctly configured on all the routers in AS 64512.

IN

© 2008 Juniper Networks, Inc. All rights reserved. 7

LSPs and Routing Table Integration

LY
N
O
SE
U
LSP Establishment Is Confirmed
AL

In the example on the slide, the LSP is established over the preferred IGP path. The
absence or presence of traffic engineering does not alter the way that LSPs are
integrated into the routing table. Besides, in the sample network, there is only one
path for the LSP to take.
N

In this example, the LSP is signaled using RVSP; we could also use LDP signaling with
much the same result. The output of a show mpls lsp extensive command
R

confirms proper establishment of the to_ny LSP.

TE
IN

8 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
Comparing Route Preferences
AL

The slide shows that once the LSP to New York is established, information about the
route to the New York router’s loopback address (the next hop for the 134.112/16
prefix) is present in not one but two routing tables. These are inet.0, used by all
routing protocols, and inet.3, which is used by LDP and RSVP (which install the
N

information in inet.3) and BGP, which uses the information in inet.3.

But what ensures that BGP resolves its next hop through the LSP to New York instead
R

of the IGP route? The answer is simple: the preference assigned to LSPs is lower than
the preference assigned to IGP routes. This causes the router to prefer LSPs over IGP
routes. Should preferences be set the same, entries in the inet.3 table are
TE

preferred over entries in the inet.0 table.

A key point on the slide is that both the IGP and MPLS routes are active, albeit in
separate tables. The result is that traffic addressed to 192.168.24.1 uses the IGP
route, while traffic associated with a BGP next hop of 192.168.24.1 uses the LSP.
IN

© 2008 Juniper Networks, Inc. All rights reserved. 9

LSPs and Routing Table Integration

LY
N
O
SE
U
BGP Installs LSP as Forwarding Next Hop for 134.112/16
AL

It helps to keep in mind that the goal of this whole exercise is not to use the LSP to
reach the New York router’s loopback address; the goal is to direct transit traffic
associated with the 134.112/16 prefix onto an LSP for transport across the CoreNet
AS.
N

The slide shows that the BGP route to 134.112/16 is present in the inet.0 routing
table as a BGP route. However, the results of BGP next-hop resolution through the
R

inet.3 table results in the to_ny LSP being installed as the forwarding next hop for
traffic associated with the 134.112/16 prefix.
TE

Packets destined to 134.112/16 that arrive at the San Francisco router are forwarded
over the LSP. No other traffic will use this LSP with the current configuration. Note also
that packets can only enter an LSP at the ingress node.
IN

10 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
Route Resolution at Ingress Router
AL

The previous example demonstrated how signaled LSPs are installed in the inet.3
routing table. Both RSVP and LDP install the IP prefix to the egress router into the
inet.3 table on the ingress router.
The next-hop data for entries in the inet.3 table consist of the LSP’s egress
N

interface and the label value assigned by the LSP’s first downstream router.
Note that the various routing protocols continue to use the inet.0 IP routing table to
R

determine the current active route to IP destinations.

Continued on next page.
TE
IN

© 2008 Juniper Networks, Inc. All rights reserved. 11

LSPs and Routing Table Integration

Route Resolution at Ingress Router (contd.)

A sample inet.3 entry that shows the next-hop forwarding information for an LSP is
shown here. Note the presence of a label push operation and egress interface:
user@host> show route table inet.3 detail
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
192.168.24.1/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP Preference: 7
Next hop: via so-0/2/0.0 weight 1, selected

LY
Label-switched-path to-amsterdam
Label operation: Push 100080
State: <Active Int>
Local AS: 64512

N
Age: 2:19:06 Metric: 2
Task: RSVP
Announcement bits (1): 1-Resolve inet.0

O
AS path: I

SE
U
AL
N
R
TE
IN

12 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
BGP Resolves Its Next Hop Using Both Tables
AL

BGP must resolve a protocol next hop to a forwarding next hop in a process known as
a recursive route lookup. The goal of this process is to resolve the advertised BGP next
hop to a directly connected forwarding next hop.
BGP uses both the inet.0 and inet.3 tables when attempting to resolve a
N

next-hop address. When the same prefix appears in both inet.0 and inet.3
tables, as is the case of this example, BGP chooses the route with the lowest
R

preference. This results in the selection of the LSP when default preference values are
at play. In the event of a preference tie, entries in inet.3 are preferred over inet.0
entries.
TE
IN

© 2008 Juniper Networks, Inc. All rights reserved. 13

LSPs and Routing Table Integration

LY
N
O
SE
U
BGP Selects inet.3 over inet.0
AL

By default, BGP prefers LSP-based resolution of a BGP prefix’s next hop. If there is a
preference tie between inet.3 and inet.0, BGP selects the inet.3 route over
the inet.0 route.
N

LSP Installed as Forwarding Next Hop in inet.0

R

The LSP’s forwarding information is copied into inet.0 when BGP can resolve its
next hop though the LSP. A key point is that the LSP itself is not installed into inet.0.
Rather, the BGP prefix is installed into inet.0 with a forwarding next hop that points
TE

to the LSP. Thus, traffic not associated with the BGP next hop in question continues to
be unaware of the LSP’s presence. The slide shows how the forwarding table is
ultimately configured to forward over the LSP for traffic associated with the BGP prefix
134.112/16.
IN

14 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
LSPs Are Installed in Ingress Router’s inet.3 Table
AL

In summary, LSPs appear in the ingress router’s inet.3 table. The next-hop address
points to the egress router as if it were directly connected and not at the end of an LSP
passing through many transit points. Normally the LSP’s egress address is specified
as the egress router’s loopback address, which also serves as the router ID.
N

When the LSP is up, this next hop is usable by BGP for next hop route resolution. When
the LSP is down, the next hop referenced by the LSP is unusable. Packets still can use
R

normal IGP routing information to resolve the next hop, however.

TE

Only BGP Is Aware of inet.3

Only BGP pays attention to the entries housed in inet.3 and only then when it is
resolving a BGP next hop. LSPs are hidden from the main IP routing table, which
allows non-BGP traffic to continue to use the IGP forwarding path.
IN

Note that the examples we discuss in this section are based on the default LSP
routing table integration behavior. With additional configuration, the presence of LSPs
can be made known to non-BGP traffic. The decision to traffic engineer internal traffic
requires careful consideration because MPLS, and even basic router troubleshooting,
might be complicated when pings and traceroutes begin using LSPs.

© 2008 Juniper Networks, Inc. All rights reserved. 15

LSPs and Routing Table Integration

LY
N
O
SE
U
Routing Tables Used in MPLS
AL

In summary, three tables are important when you configure MPLS along with normal
routing protocols. These are inet.0, inet.3, and mpls.0:
• inet.0: The primary IP unicast routing table. Normally, IGPs only look in
this table to resolve next hops. You can allow IGPs to access LSP
N

information available in inet.3 on an LSP-by-LSP basis by installing LSP

prefixes into inet.0 using the install prefix active CLI
R

configuration command in the configuration for that LSP.

• inet.3: The MPLS routing table. All signaled LSPs are installed in this
TE

table where only BGP can find them. You can add prefixes associated
with the LSP to the inet.3 table by using the install prefix CLI
configuration command in the configuration for that LSP. This knob is
useful when you want BGP to use the LSP and next-hop self is not in
effect at the egress node.
IN

• mpls.0: The MPLS label switching table. Transit and egress routers use
the contents of this table to swap and pop labels as needed when
handling the LSP.

16 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
The Ramifications of a Passive IGP Solution
AL

The examples shown thus far made use of a next-hop self policy on the LSP’s egress
node to accommodate resolution of the BGP next hop associated with routes
advertised by YankeeNet. This slide details the dramatic impact of choosing a passive
IGP vs. a next-hop self policy solution when the default routing table integration
N

behavior is at play.
In this example, the LSP egress is still New York’s 192.168.24.1 loopback address.
R

The issue is that the BGP next hop associated with the 135.112/16 prefix is now
10.0.29.1. This prefix is resolvable by the IGP due to the use of a passive IGP instance
in the interface that supports the EBGP peering session to Boston.
TE

The result is that BGP can no longer resolve its next hop through the LSP installed in
the inet.3 table. The San Francisco router therefore resolves the BGP next hop
through the inet.0 table. Therefore, transit traffic associated with the 134.112/16
prefix is no longer subjected to LSP forwarding! This is a significant point because the
IN

lack of LSP forwarding might violate service level agreements and can result in
performance problems relating to a lack of capacity on the IGP’s preferred links. Many
would consider a passive IGP or next-hop self solution as equally workable. While this
is true, you must consider the impact these choices have on LSP routing table
integration.
Continued on next page.

© 2008 Juniper Networks, Inc. All rights reserved. 17

LSPs and Routing Table Integration

The Ramifications of a Passive IGP Solution (contd.)

To resolve this issue, you can use the install prefix command to install specific
prefixes—in this case, the 10.0.29/30 route, into inet.3. Another option is to deploy
traffic engineering shortcuts. This option installs prefixes downstream
from the egress router into the inet.3 table.
Remember this rule: Only BGP prefixes that have the LSP destination address as the
BGP next hop are resolvable through an LSP. In other words, the LSP egress address
must equal the BGP next-hop address for LSP forwarding of transit traffic to occur.

LY
N
O
SE
U
AL
N
R
TE
IN

18 © 2008 Juniper Networks, Inc. All rights reserved.

 LSPs and Routing Table Integration

LY
N
O
SE
U
The 60,000-Dollar Question
AL

Can you describe how traffic destined to 192.168.24.1 and 192.168.24.5 will be
forwarded, given the operational output shown on the slide?
N
R
TE
IN

© 2008 Juniper Networks, Inc. All rights reserved. 19

LSPs and Routing Table Integration

LY
N
O
SE
U
Traffic to 192.168.24.1
AL

Because the 192.168.24.1 route is not a BGP route, there is no BGP next hop
associated with this prefix. Traffic to 192.168.24.1 uses IGP forwarding because the
presence of the LSP that terminates at the 192.168.24.1 address is not known to the
IGP.
N

Traffic to 192.168.24.5
R

In contrast, the longest match for the 192.168.24.5 address is the 192.168.24/24
prefix that is learned through BGP. The BGP next hop for this route equals the LSP’s
TE

egress address allowing the BGP next hop to be resolved through the inet.3 table.
Traffic to 192.168.24.5 is forwarded over the LSP.
The presence of LSP forwarding is clearly indicated by the presence of MPLS label
values in the output. We expect the destination unreachable message seen in the last
IN

hop in this example because the 192.168.24/24 route at New York is configured with
a reject next hop.

20 © 2008 Juniper Networks, Inc. All rights reserved.