Genie's Tech Blog

Where knowledge has no dimensions

MPLS TE tunnels without IGP

Hello Friends,

i was trying to test out few things on MPLS TE and then i came across an observation that you can build the MPLS TE tunnel without running an IGP (Interior Gateway Protocol). Later on, I made another observation that the MPLS TE tunnel would come up even if we don't have RSVP configured on the interfaces. Though both these tunnels and configurations totally defy the facts that we have read about MPLS Traffic-engineering and also defy the purpose of MPLS TE tunnels but still this stuff seems to be working out. Lets consider a sample topology say:

R1 ---- R3 ---- R4 ---- R6

where R1 acts as the head-end of the TE tunnel and R6 as the tail-end. We are not running any IGP protocol here but just plane ipv4 BGP. Lets now have a look at the configuration:

Config on R1:
=============
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel100
 ip unnumbered Loopback0
 tunnel mode mpls traffic-eng
 tunnel destination 6.6.6.6
 tunnel mpls traffic-eng path-option 1 explicit name lanos verbatim
!
interface Ethernet0/1
 ip address 13.13.13.1 255.255.255.252
 mpls ip
 mpls traffic-eng tunnels
!
router bgp 100
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 13.13.13.2 remote-as 100
 !        
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255
  redistribute connected
  neighbor 13.13.13.2 activate
 exit-address-family
!
ip route 6.6.6.6 255.255.255.255 Tunnel100
!
ip explicit-path name lanos enable
 next-address 13.13.13.2
 next-address 34.34.34.2
 next-address 46.46.46.2
 next-address 6.6.6.6
!
Config on R3:
=============
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/0
 ip address 34.34.34.1 255.255.255.0
 mpls ip
 mpls traffic-eng tunnels
!
interface Ethernet0/1
 ip address 13.13.13.2 255.255.255.252
 mpls ip
 mpls traffic-eng tunnels
!
router bgp 100
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 13.13.13.1 remote-as 100
 neighbor 34.34.34.2 remote-as 100
 !
 address-family ipv4
  network 3.3.3.3 mask 255.255.255.255
  redistribute connected
  neighbor 13.13.13.1 activate
  neighbor 13.13.13.1 route-reflector-client
  neighbor 34.34.34.2 activate
  neighbor 34.34.34.2 route-reflector-client
 exit-address-family
!   

Config on R4:
=============
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!         
interface Ethernet0/0
 ip address 34.34.34.2 255.255.255.0
 mpls ip  
 mpls traffic-eng tunnels
!
interface Ethernet0/2
 ip address 46.46.46.1 255.255.255.0
 ip ospf network point-to-point
 mpls ip
 mpls traffic-eng tunnels
!
router bgp 100
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 34.34.34.1 remote-as 100
 neighbor 46.46.46.2 remote-as 100
 !
 address-family ipv4
  network 4.4.4.4 mask 255.255.255.255
  redistribute connected
  neighbor 34.34.34.1 activate
  neighbor 34.34.34.1 route-reflector-client
  neighbor 46.46.46.2 activate
  neighbor 46.46.46.2 route-reflector-client
 exit-address-family
!

Config on R6:
=============
mpls traffic-eng tunnels
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface Ethernet0/2
 ip address 46.46.46.2 255.255.255.0
 mpls ip
 mpls traffic-eng tunnels
!
router bgp 100
 bgp router-id 6.6.6.6
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 46.46.46.1 remote-as 100
 !
 address-family ipv4
  network 6.6.6.6 mask 255.255.255.255
  redistribute connected
  neighbor 46.46.46.1 activate
 exit-address-family
!

This is the basic configuration which is required to bring up the TE tunnel. If you notice the above configuration, the interfaces do not have RSVP configured. We need to remember that the TE tunnel will only come up when you have "verbatim" keyword configured with the explicit-path. Verbatim Path feature allows network nodes to support Resource Reservation Protocol (RSVP) extensions without supporting Interior Gateway Protocol (IGP) extensions for traffic engineering (TE), thereby bypassing the topology database verification process. Please note that the tunnel will not come up if you use "autoroute announce" and also if you use the node id's in the explicit path. We will need to configure the hop by hop interface addresses in order to make this work. Tunnel remains up with static route configured. Will now see the output as well.

R1#sh mpls tra tu tu100

Name: R1_t100                             (Tunnel100) Destination: 6.6.6.6
  Status:
    Admin: up         Oper: up     Path: valid       Signalling: connected
    path option 1, type explicit (verbatim) lanos (Basis for Setup, path weight 0)

  Config Parameters:
    Bandwidth: 0        kbps (Global)  Priority: 7  7   Affinity: 0x0/0xFFFF
    Metric Type: TE (default)
    AutoRoute: disabled LockDown: disabled Loadshare: 0 [0] bw-based
    auto-bw: disabled
  Active Path Option Parameters:
    State: explicit path option 1 is active
    BandwidthOverride: disabled  LockDown: disabled  Verbatim: enabled 

  InLabel  :  -
  OutLabel : Ethernet0/1, 20
  Next Hop : 13.13.13.2
  RSVP Signalling Info:
       Src 1.1.1.1, Dst 6.6.6.6, Tun_Id 100, Tun_Instance 3308
    RSVP Path Info:
      My Address: 13.13.13.1   
      Explicit Route: 13.13.13.2 34.34.34.2 46.46.46.2 6.6.6.6 
      Record   Route:   NONE
      Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
    RSVP Resv Info:
      Record   Route:   NONE
      Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
  Shortest Unconstrained Path Info:
    Path Weight: UNKNOWN
    Explicit Route:  UNKNOWN
  History:
    Tunnel:
      Time since created: 1 days, 23 hours, 10 minutes
      Time since path change: 1 days, 22 hours, 52 minutes
      Number of LSP IDs (Tun_Instances) used: 3308
    Current LSP: [ID: 3308]
      Uptime: 1 days, 22 hours, 52 minutes
    Prior LSP: [ID: 1606]
      ID: path option 1 [3307]
      Removal Trigger: configuration changed
      Last Error: RSVP:: Could not add RSVP Path: Operation failed: internal error
R1#

If we see the above output, we notice that the TE tunnel has come up but we also notice that RSVP signalling and RSVP path information is also present which is weird as we have no RSVP enabled on the interfaces. I then ran the rsvp debug "debug ip rsvp message" to see why I am seeing this information and I noticed that rsvp messages are flowing through and RSVP neighborship is also built.

Output on R1:
==========
R1#debug ip rsvp messages 
RSVP messages (sent/received via IP) debugging is on
R1#
*Dec  5 18:02:42.359: RSVP: session [TBD]
  Incoming Resv, I/F=Et0/1, Layer=IP
  IP   HDR: 13.13.13.2->13.13.13.1, TOS=0xC0, Len=128, TTL=254, RA=N
  RSVP HDR: RRC=N, TTL=255, Len=108, Cksum=0xD8E3
R1#
*Dec  5 18:02:49.026: RSVP: 1.1.1.1_3308->6.6.6.6_100[Src] {7}:
  Outgoing Path, I/F=Et0/1, Layer=IP, NHOP=13.13.13.2, Prerouted=Y
  IP   HDR: 1.1.1.1->6.6.6.6, TOS=0xC0, Len=224, TTL=255, RA=Y
  RSVP HDR: RRC=N, TTL=255, Len=200, Cksum=0xFAA5
R1#
*Dec  5 18:03:10.986: RSVP: session [TBD]
  Incoming Resv, I/F=Et0/1, Layer=IP
  IP   HDR: 13.13.13.2->13.13.13.1, TOS=0xC0, Len=128, TTL=254, RA=N
  RSVP HDR: RRC=N, TTL=255, Len=108, Cksum=0xD8E3
R1#

R1#show ip rsvp nei
Neighbor        Encapsulation  Time since msg rcvd/sent
13.13.13.2      Raw IP         00:00:10   00:00:04  

* Neighbors inactive for more than one hour are not shown.
  Use the "inactive" keyword to display them.
R1#show ip rsvp int
interface    rsvp       allocated  i/f max  flow max sub max  VRF            
Et0/1        ena        0          0        0        0   
R1#

Output on R4:
==========
R4#show ip rsvp int
interface    rsvp       allocated  i/f max  flow max sub max  VRF            
Et0/0        ena        0          0        0        0   
Et0/2        ena        0          0        0        0   
R4#show ip rsvp nei
R4#show ip rsvp neighbor 
Neighbor        Encapsulation  Time since msg rcvd/sent
34.34.34.1      Raw IP         00:00:05   00:00:16  
46.46.46.2      Raw IP         00:00:12   00:00:19  

* Neighbors inactive for more than one hour are not shown.
  Use the "inactive" keyword to display them.
R4#

So we come to one conclusion that rsvp gets enabled on the interfaces which has "mpls traffic-eng tunnels" configured. Further in order to understand how this is working I ran the following debugs and then try to shut / no shut the tunnel interface to see how path lookup is happening:

debug mpls traffic-eng path verify

debug mpls traffic-eng path lookup

debug mpls traffic-eng path spf

Outputs from R1:
============
R1(config)#int tu 100
R1(config-if)#shut
R1(config-if)#
*Dec  5 18:12:12.327: %LINK-5-CHANGED: Interface Tunnel100, changed state to administratively down
*Dec  5 18:12:12.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed state to down
R1(config-if)#
R1(config-if)#no shut
R1(config-if)#
*Dec  5 18:12:16.842: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Lookup called   <<<<<<<<<<<<<<<<<<<<<
*Dec  5 18:12:16.842: TE-PCALC: 1.1.1.1_3309->6.6.6.6_100 {7}: Path Request Info
*Dec  5 18:12:16.842:   Flags:  IP_EXPLICIT_PATH  NO_TOPOLOGY_CHECK  METRIC_TE   <<<<<<<<<<<<<<<<<<<<<
*Dec  5 18:12:16.842:   IP explicit-path: Supplied
*Dec  5 18:12:16.842:     13.13.13.2
*Dec  5 18:12:16.842:     34.34.34.2
*Dec  5 18:12:16.842:     46.46.46.2
*Dec  5 18:12:16.842:     6.6.6.6
*Dec  5 18:12:16.842:   bw 0, min_bw 0, metric: 0
*Dec  5 18:12:16.842:   setup_pri 7, hold_pri 7
*Dec  5 18:12:16.842:   affinity_bits 0x0, affinity_mask 0xFFFF
*Dec  5 18:12:16.842: TE-PCALC-PATH: Get Path Common: Skip topology check for verbatim path to dest 6.6.6.6
*Dec  5 18:12:16.842: TE-PCALC-PATH: get_path_no_check: share count=0, dest=6.6.6.6
*Dec  5 18:12:16.842: TE-PCALC-PATH: static_path_no_check on verbatim path to 6.6.6.6
*Dec  5 18:12:16.842: TE-PCALC-PATH:   can't find node info for address 13.13.13.2
*Dec  5 18:12:16.842: TE-PCALC-PATH:  Failed to get node info for hop 13.13.13.2
*Dec  5 18:12:16.842: TE-PCALC-PATH:   can't find node info for address 34.34.34.2
*Dec  5 18:12:16.842: TE-PCALC-PATH:  Failed to get node info for hop 34.34.34.2
*Dec  5 18:12:16.842: TE-PCALC-PATH:   can't find node info for address 46.46.46.2
*Dec  5 18:12:16.842: TE-PCALC-PATH:  Failed to get node info for hop 46.46.46.2
*Dec  5 18:12:16.842: TE-PCALC-PATH:   can't find node info for address 6.6.6.6
*Dec  5 18:12:16.842: TE-PCALC-PATH:  Failed to get node info for hop 6.6.6.6
*Dec  5 18:12:16.842: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Lookup result: success
*Dec  5 18:12:16.842: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Verify called
*Dec  5 18:12:16.842: TE-PCALC: Verify Path Periodic: 1.1.1.1_3309->6.6.6.6_100 {7}: (protocol nil  area nil)
*Dec  5 18:12:16.842:   Flags:  METRIC_TE  IP_EXPLICIT_PATH  NO_TOPOLOGY_CHECK
*Dec  5 18:12:16.843:   sub-lsp weight:0 (Total LSP weight:0)
*Dec  5 18:12:16.843: TE-PCALC-VERIFY: 1.1.1.1_3309->6.6.6.6_100 {7}: Skip topology check for verbatim path
*Dec  5 18:12:16.843: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Verify result: success
*Dec  5 18:12:16.878: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel100, changed state to up
R1(config-if)#end
R1#
*Dec  5 18:12:16.879: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Verify called
*Dec  5 18:12:16.879: TE-PCALC: Verify Path Periodic: 1.1.1.1_3309->6.6.6.6_100 {7}: (protocol nil  area nil)
*Dec  5 18:12:16.879:   Flags:  METRIC_TE  IP_EXPLICIT_PATH  NO_TOPOLOGY_CHECK   <<<<<<<<<<<<<<<<<<<
*Dec  5 18:12:16.879:   sub-lsp weight:0 (Total LSP weight:0)
*Dec  5 18:12:16.879: TE-PCALC-VERIFY: 1.1.1.1_3309->6.6.6.6_100 {7}: Skip topology check for verbatim path  <<<<<<<<<<<<<<<
*Dec  5 18:12:16.879: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Verify result: success
R1#
*Dec  5 18:12:18.209: %SYS-5-CONFIG_I: Configured from console by console
R1#
R1#
*Dec  5 18:12:31.492: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Verify called
*Dec  5 18:12:31.492: TE-PCALC: Verify Path Periodic: 1.1.1.1_3309->6.6.6.6_100 {7}: (protocol nil  area nil)
*Dec  5 18:12:31.492:   Flags:  METRIC_TE  IP_EXPLICIT_PATH  NO_TOPOLOGY_CHECK
*Dec  5 18:12:31.492:   sub-lsp weight:0 (Total LSP weight:0)
*Dec  5 18:12:31.492: TE-PCALC-VERIFY: 1.1.1.1_3309->6.6.6.6_100 {7}: Skip topology check for verbatim path
*Dec  5 18:12:31.492: TE-PCALC-API: 1.1.1.1_3309->6.6.6.6_100 {7}: P2P LSP Path Verify result: success
R1#
R1#
R1#un all
All possible debugging has been turned off
R1#
From the above debugs, what we notice is that first when we un-shut the tunnel interface, path lookup is called. Then the router checks for the path information where it find the verbatim explicit-path configured. As soon as the router sees the verbatim keyword, it sets the flap to NO_TOPOLOGY_CHECK which means that the router will by bypassing the topology database verification. Though the path lookup happens for every address specified in the explicit-path but since IGP is not configured, its unable to find a valid node-id. Then the router calls up for LSP path verification where it notices the following output:
 
*Dec  5 18:12:16.842: TE-PCALC: Verify Path Periodic: 1.1.1.1_3309->6.6.6.6_100 {7}: (protocol nil  area nil)
*Dec  5 18:12:16.842:   Flags:  METRIC_TE  IP_EXPLICIT_PATH  NO_TOPOLOGY_CHECK
 
Here it says that protocol nil and area nil. I believe as there is no Link state IGP configured, this is expected. We again see similar flags set as earlier set for path lookup. Since verbatim option is specified, the LSP path verification also results in a success and thus the TE tunnel comes up.
Hope the above post has clarified few more things on MPLS traffic engineering.
 
Happy reading..
Cheers..!!!

Comments (2) -

  • Hemanth Raj

    12/6/2012 9:27:18 AM |

    hey

    how the destination of the tunnel to be reached by the tunnel interface ,  it will  cause an recursive routing,reaching tunnel destination inside tunnel

  • Genie

    12/6/2012 10:51:21 AM |

    Hello Hemanth
    I just used the prefix 6.6.6.6, if there is any other loopback say loopback 1 on R6, we can point a static route on R1 towards it through Tunnel interface. Another point is, if we do not point a static route towards 6.6.6.6, it will not be reachable via TE tunnel.

    R1#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    R1(config)#no ip route 6.6.6.6 255.255.255.255 Tunnel100
    R1(config)#end
    R1#
    *Dec  6 16:52:28.325: %SYS-5-CONFIG_I: Configured from console by console
    R1#sh ip route 6.6.6.6
    Routing entry for 6.6.6.6/32
      Known via "bgp 100", distance 200, metric 0, type internal
      Last update from 46.46.46.2 00:02:01 ago
      Routing Descriptor Blocks:
      * 46.46.46.2, from 13.13.13.2, 00:02:01 ago
          Route metric is 0, traffic share count is 1
          AS Hops 0
          MPLS label: none
    R1#

    R1#sh run | in ip route
    ip route 101.1.1.1 255.255.255.255 Tunnel100
    R1#sh ip route 101.1.1.1
    Routing entry for 101.1.1.1/32
      Known via "static", distance 1, metric 0 (connected)
      Routing Descriptor Blocks:
      * directly connected, via Tunnel100
          Route metric is 0, traffic share count is 1
    R1#ping 101.1.1.1
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 101.1.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/20 ms
    R1#

    Hope this answers your question.

Comments are closed