Case Study 1: Prefix Mapping and BGP

This case study continues to use the same topology used for most of the signaled LSP examples earlier in this chapter. Figure 12-10 shows the topology used. Earlier in the chapter, the focus was on the ingress and egress points of the LSP with a few quick looks at some of the transit LSRs. This section will focus more on using MPLS LSPs and how to get from specific networks to the LSP destination. In Figure 12-10, Tokyo has network 192.168.10.0/30 attached.

The configuration sample below shows that interface fe-1/0/0 is set up as an IS-IS passive interface in the IGP. The example below also shows the output of the show route 192.168.10.0/30 command, which demonstrates that this route is known by IS-IS.

  [edit protocols isis]  lab@Chicago# show  interface {   fe-1/0/0 passive;  } [edit protocols isis] lab@Chicago# exit configuration-mode lab@Chicago>  show route 192.168.10.0/30  inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.10.0/30     *[IS-IS/18]  00:00:12, metric 40, tag 2                     > to 10.0.15.1 via ge-3/0/0.0 

The interface address for this network is 192.168.10.2 . The passive statement is now removed from the IS-IS protocol, referring to interface fe-1/0/0 , which is 192.168.10.2 .

 [edit protocols isis]  lab@Chicago#  delete interface fe-1/0/0 passive  [edit protocols isis] lab@Chicago# show  interface {   fe-1/0/0;  } 

After this configuration change is committed, the show route 192.168.10.0/30 command does not return anything, indicating that the prefix is no longer reachable by the IS-IS protocol.

 lab@Chicago> show route 192.168.10.0/30  lab@Chicago> 

The next configuration sample shows the addition of an LSP mapped to a destination prefix on the egress router.

  [edit protocols rsvp]  lab@Chicago#  set interface all  [edit protocols rsvp] lab@Chicago#  set interface fxp0 disable  [edit protocols rsvp] lab@Chicago# up [edit protocols] lab@Chicago# edit mpls  [edit protocols mpls]  lab@Chicago#  set interface all  [edit protocols mpls] lab@Chicago# edit label-switched-path 1 [edit protocols mpls label-switched-path 1] lab@Chicago#  set to 192.168.24.1  [edit protocols mpls label-switched-path 1] lab@Chicago#  set install 192.168.10.0/30  [edit protocols mpls label-switched-path 1] lab@Chicago# set no-cspf [edit protocols mpls label-switched-path 1] lab@Chicago# exit [edit protocols mpls] lab@Chicago# exit [edit protocols] lab@Chicago# show  rsvp {   interface all;   }   mpls {   label-switched-path example1 {   to 192.168.24.1;   install 20.171.15.0/30;   no-cspf;   }   interface all;  } 

The example below shows the routing table for network 192.168.10.0/30 installed in inet.3 . However, if an attempt is made to ping or run a traceroute , no route is found because inet.3 is only used for BGP next-hop resolution.

 lab@Chicago> show route 192.168.10.0/30  inet.3:  2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.10.0/30  *[  RSVP/7  ] 00:00:11, metric 30, metric2 0                     > to 10.0.15.1 via ge-3/0/0.0, label-switched-path example1 lab@Chicago>  traceroute 192.168.10.0  traceroute to 192.168.10.0 (192.168.10.0), 30 hops max, 40 byte packets traceroute: sendto:  No route to host  1 traceroute: wrote 192.168.10.0 40 chars, ret=-1  *traceroute: sendto: No route to host traceroute: wrote 192.168.10.0 40 chars, ret=-1  *traceroute: sendto: No route to host traceroute: wrote 192.168.10.0 40 chars, ret=-1 

When the active switch is added to the same configuration, then the traceroute will use the LSP because it has now been added to the inet.0 routing table.

 [edit protocols mpls label-switched-path 1]  lab@Chicago#  set install 192.168.10.0/30 active  [edit protocols mpls label-switched-path 1] lab@Chicago# show to 192.168.24.1; install 192.168.10.0/30  active;  no-cspf; } lab@Chicago# commit 

The traceroute for the network goes through the LSP to get to 192.168.10.1 .

 lab@Chicago>  traceroute 192.168.10.1  traceroute to  192.168.10.1  (192.168.10.1), 30 hops max, 40 byte packets  1  10.0.15.1 (10.0.15.1)  0.973 ms  0.779 ms  0.715 ms  MPLS Label=251050  CoS=0 TTL=1 S=1  2  10.0.13.2 (10.0.13.2)  0.780 ms  0.702 ms  0.681 ms  MPLS Label=100312  CoS=0 TTL=1 S=1  3  10.0.31.1 (10.0.31.1)  0.551 ms  0.532 ms  0.511 ms  4  192.168.10.1  (192.168.10.1)  0.499 ms  0.475 ms  0.453 ms 

When the active switch is added to the end of the install statement, it takes the route and installs it into inet.0 . BGP would still reference the route if necessary for next-hop resolution.

The next configuration sample takes a look at something that at first might seem a bit peculiar. First, the interface fe-1/0/0 is put back into IS-IS as a passive interface. After this change is committed, both routes are installed, and the LSP is the active one. This is because they are both in inet.0 and MPLS routes have a protocol preference of 7 versus 18 for IS-IS routes. This is shown in the configuration sample below.

 [edit protocols isis]  lab@Chicago# set interface fe-1/0/0 passive lab@Chicago> show route 192.168.10.0  inet.0: 27 d  estinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.10.0/30  *[  RSVP/7  ] 00:03:27, metric 30, metric2 0                     > to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1                     [  IS-IS/18  ] 00:00:14, metric 40, tag 2                     > to 10.0.15.1 via ge-3/0/0.0 

In the next example, the active switch is removed from the LSP configuration. As can be seen below, the IS-IS route is active.

 [edit protocols mpls label-switched-path 1]  lab@Chicago#  delete install 192.168.10.0/30 active  [edit protocols mpls label-switched-path 1] lab@Chicago# show to 192.168.24.1; install 192.168.10.0/30; no-cspf; } [edit protocols mpls label-switched-path 1] lab@Chicago# commit and-quit  commit lab@Chicago>  show route 192.168.10.0   inet.0:  27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.10.0/30  *[  IS-IS/18  ] 00:03:43, metric 40, tag 2                     > to 10.0.15.1 via ge-3/0/0.0  inet.3:  2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.10.0/30  *[  RSVP/7  ] 00:00:08, metric 30, metric2 0                     > to 10.0.15.1 via ge-3/0/0.0, label-switched-path 1 

The following example shows a traceroute to 192.168.10.1 . Once again, the IGP route is most favorable.

 lab@Chicago>  traceroute 192.168.10.1  traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 40 byte packets  1  10.0.15.1 (10.0.15.1)  0.667 ms  0.558 ms  0.512 ms  2  10.0.13.2 (10.0.13.2)  0.543 ms  0.528 ms  0.506 ms 10.0.31.1 (10.0.31.1)  0.544 ms  0.527 ms  0.513 ms  192.168.10.1  (192.168.10.1)  0.482 ms  0.467 ms  0.598 ms