12.5 Static LSP Configuration

This section shows how to build a minimum configuration for a static LSP. The example uses the topology shown in Figure 12-9. A static LSP will be created from San Francisco to Tokyo. Typically, the IGP would choose the path from San Francisco to Chicago to Tokyo. MPLS will be used to engineer a path from San Francisco, through Chicago, then through London, to Tokyo.

Figure 12-9. Static LSP Topology

The first configuration output below shows San Francisco's routing table prior to the configuration of a static LSP. The native IGP, OSPF, prefers the path from San Francisco through Chicago to Tokyo for address 10.10.10.5/32 .

 lab@SanFran> show route 10.10.10.5  inet.0: 20 destinations, 20 routes (19 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both  10.10.10.5/32  *[  OSPF  /10] 00:00:21, metric 20                     > to 10.0.24.1 via fxp1.0 

The next configuration examples show the steps necessary to configure a static LSP from San Francisco through Chicago, then through London, to Tokyo. The example below shows the configuration used for San Francisco. In addition to adding family MPLS to all involved interfaces and launching the MPLS protocol, as was shown above, it is necessary to add the static-path inet statement to the configuration. This essentially inserts a static route in the routing table for the address 10.10.10.5/32 . With the next-hop thus statically defined, label 100 will be pushed onto the packets destined for 10.10.10.5 as they leave the LSR bound for the next-hop, 10.0.24.1 .

 [edit protocols mpls]  lab@SanFran#  set static-path inet 10.10.10.5 next-hop 10.0.24.1 push 100  [edit protocols mpls] lab@SanFran# show  static-path inet {   10.10.10.5/32 {   next-hop 10.0.24.1;   push 100;  } interface all; } 

Since Chicago and London are considered transit routers in MPLS, the only function they will serve is to swap labels. The example below shows the configuration of Chicago. Again, family MPLS has already been added to all appropriate interfaces and the MPLS protocol has already been launched.

 [edit protocols mpls]  lab@Chicago#  set interface fe-1/1/2 label-map 100 next-hop 10.0.2.2 swap 200  [edit protocols mpls] lab@Chicago# show interface all;  interface fe-1/1/2.0 {   label-map 100 {   next-hop 10.0.2.2;   swap 200;  } } 

The next example shows the configuration for router London. In this example, label 200 is being received from Chicago and swapped with label , which will be sent to Tokyo. In this example, the penultimate router sets the label to . When the egress router receives the label , it will know to pop the label and route the packet in the traditional IPv4 fashion. Again, family MPLS has already been added to all appropriate interfaces and the MPLS protocol has already been launched.

 [edit protocols mpls]  lab@London#  set interface fe-2/0/1 label-map 200 next-hop 10.0.0.1 swap 0  [edit protocols mpls] lab@London# show interface all;  interface fe-2/0/1.0 {   label-map 200 {   next-hop 10.0.0.1;   swap 0;  } } 

The next example shows the route table for route 10.10.10.5/32 from router San Francisco. In this case, the LSP has been configured and is showing as a static path. Static routes in JUNOS take a protocol preference of 5. MPLS takes a protocol preference of 7, while OSPF takes a protocol preference of 10.

The static route shows the interface to be used for the next-hop. Most importantly, this output shows Push 100 for this route, indicating that traffic destined for 10.10.10.5/32 will take the LSP that was defined in the configuration.

JUNOS assigns a numerical value to routes depending on how they have been derived. This numerical value is called the protocol preference. The lower the protocol preference, the more favorable the route. For example, statically defined LSPs are static routes; therefore, they are given a protocol preference of 5, just as any other static route would be. Routes derived by LDP are given a protocol preference of 9. Because 5 is less than 9, the static route is preferred over the LDP route. For a complete listing of protocol preferences, see Chapter 8.

A statically used LSP has a protocol preference of 5, which is preferable to the IGP OSPF preference of 10. JUNOS places an asterisk (*) in front of routes that have been selected for placement in the forwarding table. This is shown for the static LSP in the following example:

 lab@SanFran>  show route 10.10.10.5/32  inet.0: 21 destinations, 21 routes (20 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.5/32  *[Static/5] 11:57:46  > to 10.0.24.1 via fe-0/0/0.0,  Push 100  [OSPF/10] 11:57:45, metric 20                     > to 10.0.24.1 via fe-0/0/0.0 

This section demonstrated the steps necessary to build a static LSP. This section also showed the contents of the routing table that result from creating a static LSP.