Case Study 2: Using Constraints in RSVP LSPs

This study shows the addition of two simple constraints to the RSVP LSP configuration. Additionally, it offers an opportunity to see the primary and secondary LSP functions. It also shows how to use the traffic-engineering statement to place routes in inet.0 and inet.3 .

The topology for this study is shown in Figure 12-11. Here, two routing paths for the primary and secondary LSPs are established. These will travel from Chicago to Tokyo. The primary path will be established through San Francisco, New York, and London, while the secondary path will be established through Brussels and Amsterdam.

The path command is used in the MPLS configuration as shown next . In the following example, two constraints have been configured. Both are loose constraints. Path Tokyo-primary will force the LSP to traverse through New York, while path Tokyo-secondary will force the LSP to traverse through Amsterdam.

 [edit protocols mpls]  lab@Chicago# edit label-switched-path Tokyo  [edit protocols mpls label-switched-path Tokyo]  lab@Chicago#  set to 192.168.24.1  [edit protocols mpls label-switched-path Tokyo] lab@Chicago#  set primary Tokyo-primary  [edit protocols mpls label-switched-path Tokyo] lab@Chicago# up [edit protocols mpls] lab@Chicago# edit label-switched-path Tokyo-backup  [edit protocols mpls label-switched-path Tokyo-backup]  lab@Chicago#  set to 192.168.24.1  [edit protocols mpls label-switched-path Tokyo-backup] lab@Chicago#  set secondary Tokyo-secondary  [edit protocols mpls label-switched-path Tokyo-backup] lab@Chicago# up  [edit protocols mpls]  lab@Chicago#  set path Tokyo-primary 192.168.5.1 loose  [edit protocols mpls] lab@Chicago#  set path Tokyo-secondary 192.168.12.1 loose  [edit protocols mpls] lab@Chicago# set interface all [edit protocols mpls] lab@Chicago# show mpls {  label-switched-path Tokyo {   to 192.168.24.1;   primary Tokyo-primary;  }  label-switched-path Tokyo-backup {   to 192.168.24.1;   secondary Tokyo-secondary;   }   path Tokyo-primary {   192.168.5.1 loose;   }   path Tokyo-secondary {   192.168.12.1 loose;   }   interface all;  } 

Now that the paths have been configured and committed, the results can be seen by using the show mpls lsp command. The example below shows that there are two LSPs that have been created, and they are both up.

 lab@Cicago>  show mpls lsp  Ingress LSP: 2 sessions To              From            State Rt ActivePath       P     LSPname  192.168.24.1    192.168.16.1    Up     1 Tokyo  *     Tokyo  192.168.24.1    192.168.16.1    Up     0 Tokyo-backup   Tokyo-backup  Total 2 displayed, Up 2, 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 shows the results of the show mpls lsp extensive command. This command shows the path that each LSP is taking. In addition, it is possible to see the differences in metrics between the two paths.

 lab@Chicago>  show mpls lsp extensive  Ingress LSP: 2 sessions 192.168.24.1   From: 192.168.16.1, State: Up, ActiveRoute: 1, LSPname: Tokyo   ActivePath: Tokyo (primary)   LoadBalance: Random  *Primary   Tokyo       State: Up     Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 40)           10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S     Received RRO (S [L] denotes strict [loose] hops):           10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S     6 Jan  2 07:49:33  Selected as active path     5 Jan  2 07:49:33  Record Route:  10.0.16.2 S 10.0.0.2 S 10.0.2.1 S 10.0.24.2 S     4 Jan  2 07:49:33  Up     3 Jan  2 07:49:33  Originate Call     2 Jan  2 07:49:33  CSPF: computation result accepted     1 Jan  2 07:49:04  CSPF failed: no route toward 192.168.5.1    Created: Wed Jan  2 07:49:03 2002 192.168.24.1   From: 192.168.16.1, State: Up, ActiveRoute: 0, LSPname: Tokyo-secondary   ActivePath: Tokyo-backup (secondary)   LoadBalance: Random  *Secondary Tokyo-backup     State: Up     Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)           10.0.15.1 S 10.0.13.2 S 10.0.31.1 S     Received RRO (S [L] denotes strict [loose] hops):           10.0.15.1 S 10.0.13.2 S 10.0.31.1 S     6 Jan  2 07:49:34  Selected as active path     5 Jan  2 07:49:34  Record Route:  10.0.15.1 S 10.0.13.2 S 10.0.31.1 S     4 Jan  2 07:49:34  Up     3 Jan  2 07:49:33  Originate Call     2 Jan  2 07:49:33  CSPF: computation result accepted     1 Jan  2 07:49:04  CSPF failed: no route toward 192.168.12.1    Created: Wed Jan  2 07:49:03 2002 Total 2 displayed, Up 2, 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 sample of output from the CLI shows that the LSP is listed in inet.3 and the IS-IS route is listed in inet.0 .

 lab@Chicago>  show route 192.168.24.1   inet.0  : 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.24.1/32  *[  IS-IS/18  ] 00:26: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:20:04, metric 30, metric2 0                       via at-2/1/0.100, label-switched-path Tokyo to 10.0.15.1 via ge-3/0/0.0, label-switched-path Tokyo 

There are several ways to get the LSP into the inet.0 table. Once in the inet.0 routing table, the LSP can be used by protocols other than BGP for traffic forwarding. In this example, the set protocols mpls traffic-engineering bgp-igp command is used to force the LSP into inet.0 . The configuration for this scenario follows :

 [edit]  lab@Chicago# set protocols mpls traffic-engineering  bgp-igp  [edit] lab@Chicago# show protocols mpls traffic-engineering bgp-igp; 

A show route command demonstrates that both the IS-IS route and RSVP route are now listed in inet.0 .

 lab@Chicago>  show route 192.168.24.1  inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.24.1/32  *[RSVP/7] 00:04:36, metric 30, metric2 0                       via at-2/1/0.100,  label-switched-path Tokyo  > to 10.0.15.1 via ge-3/0/0.0,  label-switched-path Tokyo-   backup  [  IS-IS/18  ] 00:04:40, metric 30, tag 2                     > to 10.0.15.1 via ge-3/0/0.0 

In the following example, a link in the primary path has been broken, making it possible to observe how the routing table changes over to using the configured secondary path. Only one LSP, Tokyo-backup and the IS-IS route are visible in the routing table.

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

This case study demonstrated the configuration of redundant LSPs. It also explored some of the commands used to verify LSP functionality and view the impact of various configuration options on the routing tables.