Allowing IGP Traffic to Use an LSP

Problem

You want to configure IS-IS and OSPF so they can also use the LSPs on the ingress router.

Solution

Configure OSPF and IS-IS so that the LSP is advertised into the IGP. For OSPF, configure the area with the following command:

[edit protocols ospf area 0.0.0.0 ] aviva@R1# set label-switched-path R1-to-R6

The configuration for IS-IS is similar:

[edit protocols isis] aviva@R1# set label-switched-path R1-to-R6

Discussion

One of the main reasons that you configure LSPs on your network is to control the shortest path between two points on the network. If enough bandwidth is available on the LSP, you might also want to have your IGP traffic routed along the LSP instead of having it use the default best-effort routing. To configure this, set up OSPF and IS-IS so that the LSP is advertised into the IGP. For OSPF, use the set label-switched-path command for each OSPF area, and for IS-IS, use this command at the top of the IS-IS configuration. In this recipe, R1-to-R6 is the name of the LSP configured on the ingress router R1. Because only the ingress router is aware of the LSP and because this is the only router that can place packets into the LSP tunnel, you can configure this only on the ingress router.

Lets look at the effect of this configuration. Before configuring OSPF to use the LSP, check which routes have been learned from OSPF:

aviva@R1> show route protocol ospf inet.0: 14 destinations, 18 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.3/32 *[OSPF/10] 00:00:07, metric 1 > via so-0/0/2.0 10.0.0.6/32 *[OSPF/10] 00:00:07, metric 2 > via so-0/0/2.0 10.1.13.0/30 [OSPF/10] 00:00:07, metric 1 > via so-0/0/2.0 10.1.36.0/30 *[OSPF/10] 00:00:07, metric 2 > via so-0/0/2.0 224.0.0.5/32 *[OSPF/10] 01:56:46, metric 1 MultiRecv

The router knows how to reach its immediate neighbor R3 (router ID of 10.0.0.3/32 and subnet of 10.1.31.0/30) and the next downstream neighbor, R6 (router ID of 10.0.0.6/32 and subnet of 10.1.36.0/30). R1 has one OSPF neighbor, 10.1.13.2, which is the immediately adjacent router:

aviva@R1> show ospf neighbor Address Interface State ID Pri Dead 10.1.13.2 so-0/0/2.0 Full 10.0.0.3 128 35

After you advertise the LSP into OSPF, check the neighbors again:

aviva@R1> show ospf neighbor Address Interface State ID Pri Dead 10.0.0.6 R1-to-R6 Full 10.0.0.6 0 0 10.1.13.2 so-0/0/2.0 Full 10.0.0.3 128 36

The output shows that R1 now has a second neighbor, 10.0.0.6, which is R6, that is reachable not over a physical interface but rather over the LSP.

Looking at the routing table shows a route to 10.0.0.6/32 that uses the LSP:

aviva@R1> show route table inet.0 protocol ospf inet.0: 14 destinations, 18 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.0.3/32 *[OSPF/10] 00:01:50, metric 1 > via so-0/0/2.0 10.0.0.6/32 *[OSPF/10] 00:01:50, metric 1 > via so-0/0/2.0, label-switched-path R1-to-R6 10.1.13.0/30 [OSPF/10] 00:01:50, metric 1 > via so-0/0/2.0 10.1.36.0/30 *[OSPF/10] 00:01:50, metric 2 > via so-0/0/2.0 224.0.0.5/32 *[OSPF/10] 02:00:33, metric 1 MultiRecv

You verify the IS-IS configuration in the same way, checking the IS-IS interfaces and adjacencies to confirm that IS-IS is aware of the LSP:

aviva@R1> show isis interface IS-IS interface database: Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric R1-to-R6 2 0x1 Disabled Point to Point 10/10 lo0.0 0 0x1 Passive Passive 0/0 so-0/0/2.0 2 0x1 Disabled Point to Point 10/10 aviva@R1> show isis adjacency Interface System L State Hold (secs) SNPA R1-to-R6 R6 0 One-way 0 so-0/0/2.0 R3 2 Up 18

Both outputs show that IS-IS treats the LSP as an IS-IS interface and considers it an adjacency.