12.6 RSVP-Based Dynamic-LSP Configuration

The first example below shows the statements required to configure RSVP on a Juniper Networks M-Series router. It also demonstrates the common practice of disabling the signaling protocol across fxp0 , the management Ethernet interface. In most situations LSPs are not configured across the management LAN; therefore, running the RSVP signaling protocol on the management Ethernet interface is unnecessary.

 [edit protocols rsvp]  lab@Chicago#  set interface all  [edit protocols rsvp] lab@Chicago#  set interface fxp0 disable  [edit protocols rsvp] lab@Chicago# show  interface all;   interface fxp0.0 {   disable;  } 

Now that the RSVP protocol has been configured it is necessary to add the configuration elements that will build an LSP. Figure 12-10 shows the topology that will be used for the RSVP configuration example.

Figure 12-10. RSVP LSP Topology

In this example, an LSP will be established from Chicago to destination 192.168.24.1 on the Tokyo router. To configure the LSP, use the set mpls label-switched - path label- name to egress-router-address no-cspf command at the [edit protocols] level of hierarchy as shown below.

 [edit protocols]  lab@Chicago#  set mpls label-switched-path 1 to 192.168.24.1  [edit protocols] lab@Chicago# set mpls label-switched-path 1 no-cspf [edit protocols] lab@Chicago# show  mpls {   label-switched-path 1 {   to 192.168.24.1;  no-cspf;     } } 

The no-cspf statement included here makes sure that the LSR will not try to create the LSP based on the contents of the TED.

The following example illustrates the output of the show mpls lsp command. An LSP has been established to egress address 192.168.24.1 from ingress address 192.168.5.1 . The LSPname is explicitly shown in the output of this command. This is important as there could be multiple LSPs configured.

 lab@Chicago> show mpls lsp  Ingress LSP: 1 sessions  To              From            State Rt ActivePath       P     LSPname  192.168.24.1    192.168.16.1    Up  2                  *     1 Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 

The next example includes the output from the show mplS lsp extensive command. Adding the extensive switch to the end of the command dramatically increases the information shown in the output, including whether the LSP is a primary or secondary path, whether hops are loose or strict, the actual hops taken, and the time of LSP creation.

 lab@Chicago> show mpls lsp extensive  Ingress LSP: 1 sessions 192.168.24.1   From: 192.168.16.1, State: Up, ActiveRoute: 2, LSPname: 1  ActivePath:  (primary)  LoadBalance: Random  *Primary                    State: Up     Received RRO (S [L] denotes strict [loose] hops):           10.0.15.1 S 10.0.13.2 S 10.0.31.1 S    10 Jan  2 03:13:07  Selected as active path  9 Jan  2 03:13:07  Record Route:  10.0.15.1 S 10.0.13.2 S 10.0.31.1 S  8 Jan  2 03:13:07  Up     7 Jan  2 03:13:04  Deselected as active     6 Jan  2 03:13:04  No Route[2 times]     5 Jan  2 03:13:04  Clear Call     4 Jan  2 03:11:33  Selected as active path     3 Jan  2 03:11:33  Record Route:  10.0.15.1 S 10.0.13.2 S 10.0.31.1 S     2 Jan  2 03:11:33  Up     1 Jan  2 03:11:33  Originate Call    Created: Wed Jan  2 03:11:34 2002 Total 1 displayed, Up 1, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 

The show route 192.168.24.1 command shows that there is a route installed in both inet.0 and inet.3 . As the reader will recall from the discussion on RSVP and routing tables, the default behavior is for MPLS to install LSPs into inet.3 . The route in inet.1 is based on the native IGP, which in this case is IS-IS. As discussed earlier in Section 12.3.3, BGP will prefer routes in inet.3 over routes to the same prefix in inet.0 . The next example reiterates this point.

 lab@Chicago> show route 192.168.24.1  inet.0:  24 destinations, 24 routes (23 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 192.168.24.1/32    *[  IS-IS/18  ] 00:08:09, metric 30, tag 2                     > to 10.0.15.1 via ge-3/0/0.0  inet.3:  1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.24.1/32    *[  RSVP/7  ] 00:00:26, metric 30, metric2 0                     > to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1 

The next example illustrates the show mpls lsp command on the egress LSR (Tokyo) of the Figure 12-10 topology. Notice the Labelin field has a value of 3 . Section 12.3.1.1 explained that label 3 is used as an implicit null label, which is used in RSVP- and LDP-based LSPs to tell the upstream router to pop the label. Although what is shown in the label in column is a 3 , the router is actually receiving IP packets without an MPLS from the upstream router. This demonstrates the PHP concept.

 lab@Tokyo> show mpls lsp  Ingress  LSP: 0 sessions Total 0 displayed, Up 0, Down 0  Egress LSP: 1 sessions  To              From            State Rt Style Labelin Labelout LSPname  192.168.24.1    192.168.16.1    Up  0  1 FF       3        - 1 Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0 

Compare the output for Tokyo to the output for the upstream router, Amsterdam, below. The Labelout field shows a label value of 3 .

 lab@Amsterdam> show mpls lsp  Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0  Transit LSP: 1 sessions  To              From            State Rt Style Labelin Labelout LSPname  192.168.24.1    192.168.16.1    Up  1  1 FF  100304        3 1 Total 1 displayed, Up 1, Down 0 

This section demonstrated the commands used to configure the MPLS signaling protocol RSVP. It also compared the output from various show commands run on LSRs that are crossed by the LSP.