[c-nsp] Bizarre MPLS label problem, hex value?

[Oliver Boehmer (oboehmer)]

Nathan <> wrote on Monday, February 18, 2008 12:59 AM:

> Hi,
> 
> I've tried all the MPLS troubleshooting docs I've been able to find,
> and hard resets of BGP sessions, but I must be missing something.
> 
> I have four routers in a row, A B C D, I want packets to go inside a
> VRF from A to D. Packets travel from B to D without any problem, but
> not from A to D. My problem is general over all the VRFs I have
> tested. I've chosen as example a vrf in which all the routers
> concerned have interfaces (so they're all PE routers . . . that's not
> a problem, is it?)

No, it's not. B and C will act as "P" routers for an LSP from A to D.

>     A#sh ip cef vrf ${vrf} 0.0.0.0 0.0.0.0
>     0.0.0.0/0, version 109, epoch 0, cached adjacency ${B as seen
>     from A} 0 packets, 0 bytes
>       tag information set
>         local tag: VPN-route-head
>         fast tag rewrite with
>             Recursive rewrite via ${D loopback} 0x20, tags imposed
>       {413} via ${D loopback}, 0 dependencies, recursive
>         next hop ${B as seen from A}, GigabitEthernet0/1.7 via ${D
>         loopback}/32 valid cached adjacency
>         tag rewrite with
>             Recursive rewrite via ${D loopback} 0x20, tags imposed
> {413} 
> 
> What does that 0x20 mean??

I don't know offhand, but in order to proceed, you need to follow the
recursion to find out the outer (IGP/LDP) label of the packet. The "413"
shown above is the vpn label received via MBGP.
A seems to have multiple paths to D, so the final label stack will be
determined at "run-time".
Please do "show ip cef ${D loopback}" on A to find out.

> 
> I would have expected something like what I get when I try the same
> diagnostics starting from router B :
> 
>     B#sh ip cef vrf ${vrf} 0.0.0.0 0.0.0.0
>     0.0.0.0/0, version 105, epoch 0, cached adjacency ${C as seen
>     from B} 0 packets, 0 bytes
>       tag information set
>         local tag: VPN-route-head
>         fast tag rewrite with Fa6/0, ${C as seen from B}, tags
> imposed: {396 413}
>       via ${D loopback}, 0 dependencies, recursive
>         next hop ${C as seen from B}, FastEthernet6/0 via ${D
>         loopback}/32 valid cached adjacency
>         tag rewrite with Fa6/0, ${C as seen from B}, tags imposed:
> {396 413} 

B only has a single IGP path to D, so the full label stack is printed.

>     C#sh mpls forwarding-table labels 396
>     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next
>     Hop tag    tag or VC   or Tunnel Id      switched   interface
>     396    Pop tag     ${D loopback}/32   157406938041 Fa1/0      ${D
> seen from C}
> 
>     D#sh mpls forwarding-table labels 413
>     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next
>     Hop tag    tag or VC   or Tunnel Id      switched   interface
>     413    Untagged    0.0.0.0/0[V]      1076956933 Fa0/0.12  
> 192.168.12.4 
> 
> If I understand correctly, the MPBGP session between A and D is
> OK, but something is stopping A from learning the local tag on
> B . . . the local tag that I would have expected to see instead of
> VPN-route-head when I did the sh ip cef on B. 

As explained above: A looks to have multiple IGP paths, so you need to
do the recursion yourself and verify all possible paths.

	oli