MPLS TE: If you want standard compliance, you have to ask nicely

In a comment to my post describing the role of implicit NULL in LDP, an anonymous commenter complained about lack of Cisco’s standard compliance in MPLS TE tunnel setup process. Time for packet capture and Wireshark :). The tests were performed on the MPLS TE network I’ve used to illustrate MPLS troubleshooting with LSP ping; packets were captured on the link between C4 and C2 (the penultimate hop and the tunnel tail-end) at the time when the MPLS TE tunnel was established from C1 to C2. In all tests, an ICMP Echo Request packet was sent over the tunnel to verify whether C4 performed PHP or used an MPLS shim header on the last hop of the tunnel.

With the default settings, C2 signaled that C4 should use explicit NULL (label = 0), but C2 performed PHP (which is the usual action the penultimate hop of an MPLS TE tunnel should do). The wireshark decodes are shown below (note that C4 sends the ICMP packet traversing the tunnel without the MPLS shim header, indicating that it performed PHP):

Frame 1 (212 bytes on wire, 212 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
Resource ReserVation Protocol (RSVP): PATH Message.
    RSVP Header. PATH Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.34
    TIME VALUES: 30000 ms
    EXPLICIT ROUTE: IPv4 10.0.7.33, IPv4 10.0.1.7
    LABEL REQUEST: Basic: L3PID: IP (0x0800)
    SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style,  [C1_t0]
    SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 13. 
    SENDER TSPEC: IntServ: Token Bucket, 62500 bytes/sec. 
    ADSPEC

Frame 2 (132 bytes on wire, 132 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.7.33 (10.0.7.33), Dst: 10.0.7.34 (10.0.7.34)
Resource ReserVation Protocol (RSVP): RESV Message. 
    RSVP Header. RESV Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.33
    TIME VALUES: 30000 ms
    STYLE: Shared-Explicit (18)
    FLOWSPEC: Controlled Load: Token Bucket, 62500 bytes/sec. 
    FILTERSPEC: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 13. 
    LABEL: 0

Frame 3 (104 bytes on wire, 104 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 100
    Identification: 0x0000 (0)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 253
    Protocol: ICMP (0x01)
    Header checksum: 0xa78f [correct]
    Source: 10.0.1.3 (10.0.1.3)
    Destination: 10.0.1.7 (10.0.1.7)
Internet Control Message Protocol

When the penultimate hop is a more compliant router, it uses the explicit NULL in the MPLS header to encapsulate the ICMP packet, resulting in potential problems on C2 (according to RFC 3032, the whole label stack should be discarded when an explicit NULL is encountered).

If you want C2 to behave in a more standard-compliant way, you have to ask nicely with the mpls traffic-eng signalling advertise implicit-null global configuration command. You can use an access list with this command to indicate which neighbors need standard-compliant signaling. The access list should be used if you have a mix of neighbors that interpret the explicit NULL the way it should be interpreted and older IOS devices that could be confused by the implicit NULL label in the RSVP RESV message.

Anyhow, after mpls traffic-eng signalling advertise implicit-null has been configured on C2, the RSVP RESV message used implicit NULL label (Label = 3):

Frame 1 (212 bytes on wire, 212 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
Resource ReserVation Protocol (RSVP): PATH Message. 
    RSVP Header. PATH Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.34
    TIME VALUES: 30000 ms
    EXPLICIT ROUTE: IPv4 10.0.7.33, IPv4 10.0.1.7
    LABEL REQUEST: Basic: L3PID: IP (0x0800)
    SESSION ATTRIBUTE: SetupPrio 7, HoldPrio 7, SE Style,  [C1_t0]
    SENDER TEMPLATE: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 16. 
    SENDER TSPEC: IntServ: Token Bucket, 62500 bytes/sec. 
    ADSPEC

Frame 2 (132 bytes on wire, 132 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.7.33 (10.0.7.33), Dst: 10.0.7.34 (10.0.7.34)
Resource ReserVation Protocol (RSVP): RESV Message.
    RSVP Header. RESV Message. 
    SESSION: IPv4-LSP, Destination 10.0.1.7, Tunnel ID 0, Ext ID a000103. 
    HOP: IPv4, 10.0.7.33
    TIME VALUES: 30000 ms
    STYLE: Shared-Explicit (18)
    FLOWSPEC: Controlled Load: Token Bucket, 62500 bytes/sec. 
    FILTERSPEC: IPv4-LSP, Tunnel Source: 10.0.1.3, LSP ID: 16. 
    LABEL: 3

Frame 3 (104 bytes on wire, 104 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src: 10.0.1.3 (10.0.1.3), Dst: 10.0.1.7 (10.0.1.7)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 100
    Identification: 0x000a (10)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 253
    Protocol: ICMP (0x01)
    Header checksum: 0xa785 [correct]
    Source: 10.0.1.3 (10.0.1.3)
    Destination: 10.0.1.7 (10.0.1.7)
Internet Control Message Protocol

This article is part of You've asked for it series.

2 comments:

  1. The RFC 3032 does not mention that a PE should discard the whole label stack when it receives a packet with explicit nulll label....
    In this case the tunnel tail end is supposed only to discard the outter label (with explicit null), correct?

    ReplyDelete
  2. RFC 3032 says that an explicit NULL that is not the only label in the stack is invalid and that the packet should be forwarded using IPv4 forwarding table when explicit NULL is encountered (section 2.1, page 5). RFC 4182 fixed that problem.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.