MPLS-TE via RSVP – Part 1 of 3 – Cisco IOS

I’m going to have to split this topic into three separate posts because otherwise it’ll just be too long and I’ll lose you halfway through.
Part 1 – Cisco IOS
Part 2 – Juniper JunOS
Part 3 – Brocade Netiron XMR/MLX
Part 4 – Cisco IOS-XR

Most people I speak to who have MPLS experience is usually experienced with LDP. Most probably because it’s easy and they have no need for traffic engineering.

However in the ISP space, the vast majority of MPLS cores run RSVP-TE. Not only does it give you traffic-engineering capabilities, it also gives you features like fast-reroute and hot standby LSPs. You can also use your IGP to carry TE extensions, but only link-state protocols will do this for you. i.e. you can forget about EIGRP doing anything good for you in an ISP core.

Some people tend to think that RSVP-TE is difficult, but really it’s not that difficult at all. Once you get over the initial hurdles you’ll see how powerful it can be. I have extensive Brocade Netiron RSVP-TE experience, a fair amount of JunOS RSVP-TE experience and hardly any IOS RSVP-TE experience. This is because my current core is all Brocade and Juniper. Unfortunately I can only test RSVP-TE on IOS and not IOS-XR as I don’t have any IOS-XR boxes available for me to test on. It’s far more likely that an ISP core would be running IOS-XR over IOS.

Let’s take the following topology into consideration that I’ll be using for all vendor makes. AR1 and AR3 are my ‘edge’ routers running iBGP with each other. They are each advertising a second loopback address to each over over BGP. CR1, CR2, and CR3 are my core routers not running any BGP at all.

IOS basic config

Let’s start with the core network first. I’m pasting the relevant pieces of config here of CR1. CR2 and CR3 are going to be very similar:

mpls traffic-eng tunnels
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
 ip ospf 1 area 0
!
interface Serial1/0
 ip address 10.2.0.2 255.255.255.0
 ip ospf 1 area 0
 mpls traffic-eng tunnels
!
interface Serial1/2
 ip address 10.3.0.1 255.255.255.0
 ip ospf 1 area 0
 mpls traffic-eng tunnels
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0

AR1:

mpls traffic-eng tunnels
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
!
interface Loopback20
 ip address 20.20.20.20 255.255.255.255
!
interface Tunnel0
 ip unnumbered Loopback0
 tunnel destination 4.4.4.4
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 5 dynamic
 no routing dynamic
!
interface Serial1/0
 ip address 10.2.0.1 255.255.255.0
 ip ospf 1 area 0
 mpls traffic-eng tunnels
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 router-id 2.2.2.2
!
router bgp 13
 network 20.20.20.20 mask 255.255.255.255
 neighbor 4.4.4.4 remote-as 13
 neighbor 4.4.4.4 update-source Loopback0
 no auto-summary

AR3 has a similar config to AR1, so I’m not going to list it here. Essentially what we’ve done is enabled mpls traffic-engineering globally, enabled it on the transit interfaces, and finally enabled OSPF-TE in OSPF. The AR routers have an iBGP connection to each other. There is no need to enable MPLS IP anywhere as that actually enables LDP.

Now that my tunnels are up, let’s try and ping a BGP learned route and see what happens:

AR3#ping 20.20.20.20

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.20, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

This won’t work because IOS won’t actually use this tunnel for any routing unless I specifically allow it. I could do static routing or PBR, but why not just let the routing protocol do the work?

interface Tunnel0
 tunnel mpls traffic-eng autoroute announce

This command allows the IGP to use the tunnel in it’s tree calculation. Let’s take a look at whether it works now or not:

AR3#ping 20.20.20.20       

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.20, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/37/44 ms

Let’s take a look at the route and CEF table:

AR3#sh ip route 2.2.2.2    
Routing entry for 2.2.2.2/32
  Known via "ospf 1", distance 110, metric 129, type intra area
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0
      Route metric is 129, traffic share count is 1

AR3#sh ip cef 20.20.20.20
20.20.20.20/32, version 12, epoch 0
0 packets, 0 bytes
  tag information from 2.2.2.2/32, shared
    local tag: tunnel-head
    fast tag rewrite with Tu0, point2point, tags imposed: {16}
  via 2.2.2.2, 0 dependencies, recursive
    next hop 2.2.2.2, Tunnel0 via 2.2.2.2/32
    valid adjacency
    tag rewrite with Tu0, point2point, tags imposed: {16}

In order to get to 2.2.2.2 which is the next-hop, it will send the traffic through the LSP tunnel. If we check the CEF table we can see that traffic will be directed towards the tunnel and have the label value of 16 imposed onto it. We can ensure this is correct with a traceroute:

AR3#traceroute 20.20.20.20

Type escape sequence to abort.
Tracing the route to 20.20.20.20

  1 10.3.0.1 [MPLS: Label 16 Exp 0] 36 msec 28 msec 44 msec
  2 10.2.0.1 44 msec 44 msec * 

It’s exactly what we see. Also note that the tunnel is actually following the shortest IGP path at the moment. This is because in the above config we told the ARs to signal the path dynamically. This means it’ll follow the IGP best path. Which will lead us onto our next section.

IOS explicit paths

We can tell IOS that we actually want to use the CR2-CR3 path instead of just learning this information dynamically. We now want to use CR2 and CR3 in the path and not CR1. We can do this in two ways depending on the topology. Either I tell my ingress router that it should follow a very specific path, or I just tell the ingress router to specifically miss a particular node. As LSPs are unidirectional, let’s try both.

AR1:

ip explicit-path name through-CR2-CR3 enable
 next-address 10.5.0.2 
 next-address 10.6.0.2 
 next-address 10.7.0.2 
!
interface Tunnel0
 tunnel mpls traffic-eng path-option 4 explicit name through-CR2-CR3
 tunnel mpls traffic-eng path-option 5 dynamic

AR3:

ip explicit-path name not-through-CR1 enable
 exclude-address 10.3.0.1
!
interface Tunnel0
 tunnel mpls traffic-eng path-option 4 explicit name not-through-CR1
 tunnel mpls traffic-eng path-option 5 dynamic
AR1#traceroute 40.40.40.40      

Type escape sequence to abort.
Tracing the route to 40.40.40.40

  1 10.5.0.2 [MPLS: Label 17 Exp 0] 60 msec 64 msec 72 msec
  2 10.6.0.2 [MPLS: Label 17 Exp 0] 64 msec 60 msec 48 msec
  3 10.7.0.2 68 msec 56 msec * 


AR3#traceroute 20.20.20.20

Type escape sequence to abort.
Tracing the route to 20.20.20.20

  1 10.7.0.1 [MPLS: Label 16 Exp 0] 48 msec 64 msec 64 msec
  2 10.6.0.1 [MPLS: Label 16 Exp 0] 76 msec 48 msec 72 msec
  3 10.5.0.1 64 msec *  60 msec

This is a pretty small topology, so by telling AR3 to skip CR1, there is only 1 other path available. So we create the explicit paths on each ingress router, and then under the tunnel interface we specify that this explicit path is more preferred than the dynamic path. Either way works and you can see from the traceroutes above that both work. The dynamic path is still left under the tunnel interface as we would still like to use it if the CR2-CR3 path becomes unavailable.

IOS Type-10 OSPF LSA

MPLS-TE extensions are carried within OSPF type-10 opaque LSAs. These LSAs have area flooding scope and hence they do not pass through multi-area OSPF. Another reason why ISP cores don’t run multi-area OSPF. You can see the LSAs in the database:

AR1#sh ip ospf database | begin Type-10
		Type-10 Opaque Link Area Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Opaque ID
1.0.0.0         2.2.2.2         887         0x80000002 0x005AC6 0       
1.0.0.0         3.3.3.3         173         0x80000003 0x005CBB 0       
1.0.0.0         4.4.4.4         557         0x80000002 0x0062AE 0       
1.0.0.0         22.22.22.22     385         0x80000002 0x00AAD5 0       
1.0.0.0         33.33.33.33     319         0x80000002 0x00D651 0       
1.0.0.2         2.2.2.2         172         0x80000004 0x004EFC 2       
1.0.0.2         3.3.3.3         173         0x80000003 0x00704A 2       
1.0.0.2         4.4.4.4         174         0x80000004 0x004AF6 2       
1.0.0.2         22.22.22.22     128         0x80000002 0x008CDD 2       
1.0.0.2         33.33.33.33     76          0x80000002 0x00EFFB 2       
1.0.0.3         2.2.2.2         111         0x80000002 0x0025D4 3       
1.0.0.3         3.3.3.3         173         0x80000003 0x00535C 3       
1.0.0.3         4.4.4.4         306         0x80000002 0x001918 3       
1.0.0.3         22.22.22.22     128         0x80000002 0x00C228 3       
1.0.0.3         33.33.33.33     319         0x80000002 0x0064CC 3   

If we dig deeper into the LSA originated by CR1 we can see the following:

AR1#sh ip ospf database opaque-area adv-router 3.3.3.3

            OSPF Router with ID (2.2.2.2) (Process ID 1)

		Type-10 Opaque Link Area Link States (Area 0)

  LS age: 310
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 1.0.0.0
  Opaque Type: 1
  Opaque ID: 0
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x5CBB
  Length: 28
  Fragment number : 0

    MPLS TE router ID : 3.3.3.3

    Number of Links : 0

  LS age: 310
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 1.0.0.2
  Opaque Type: 1
  Opaque ID: 2
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x704A
  Length: 132
  Fragment number : 2
          
    Link connected to Point-to-Point network
      Link ID : 2.2.2.2
      Interface Address : 10.2.0.2
      Neighbor Address : 10.2.0.1
      Admin Metric : 64
      Maximum bandwidth : 193000
      Maximum reservable bandwidth : 0
      Number of Priority : 8
      Priority 0 : 0           Priority 1 : 0         
      Priority 2 : 0           Priority 3 : 0         
      Priority 4 : 0           Priority 5 : 0         
      Priority 6 : 0           Priority 7 : 0         
      Affinity Bit : 0x1
      IGP Metric : 64

    Number of Links : 1

  LS age: 310
  Options: (No TOS-capability, DC)
  LS Type: Opaque Area Link
  Link State ID: 1.0.0.3
  Opaque Type: 1
  Opaque ID: 3
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x535C
  Length: 132
  Fragment number : 3

    Link connected to Point-to-Point network
      Link ID : 4.4.4.4
      Interface Address : 10.3.0.1
      Neighbor Address : 10.3.0.2
      Admin Metric : 64
      Maximum bandwidth : 193000
      Maximum reservable bandwidth : 0
      Number of Priority : 8
      Priority 0 : 0           Priority 1 : 0         
      Priority 2 : 0           Priority 3 : 0         
      Priority 4 : 0           Priority 5 : 0         
      Priority 6 : 0           Priority 7 : 0         
      Affinity Bit : 0x1
      IGP Metric : 64
          
    Number of Links : 1

You can see that it will show all your links, any affinities set, max reserved bandwidths, and any currently used bandwidths for different priorities.

I could go on for many hours showing various MPLS features but then I’ll never finish this article.

In the next part I’ll be doing JunOS showing the same features and config as I showed above. In the final part I’ll be doing the same for Brocade Netiron.

© 2009-2020 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright