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

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Mon Feb 18 07:33:39 EST 2008


Nathan <mailto:have.an.email at gmail.com> wrote on Monday, February 18,
2008 11:31 AM:

> On Feb 18, 2008 7:51 AM, Oliver Boehmer (oboehmer)
> <oboehmer at cisco.com> wrote: 
>> Nathan <> wrote on Monday, February 18, 2008 12:59 AM:
>>> 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.
> [...]
>>>     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".
> 
> Yes, there is a secondary route through a router Z that is connected :
> 
>          directly to B
>          directly to A on the same subnet as B (subnet A,B,Z)
>          directly to A on another subnet
> 
> 
> However the only routes to C and D go through B, and the OSPF cost of
> A-Z-B is bigger than A-B.
> 
> There's also another router connected to the Z-B subnet and to the
> A-B-Z subnet, but I don't see any reason for packets to go through
> there unless an Ethernet cable becomes unplugged.

Ok, I see.  

>> Please do "show ip cef ${D loopback}" on A to find out.
> 
> A#show ip cef ${D loopback}
> ${D loopback}/32, version 1788, epoch 0, cached adjacency ${B as seen
> from A} 0 packets, 0 bytes
>   tag information set, shared
>     local tag: 40
>   via ${B as seen from A}, GigabitEthernet0/1.7, 267 dependencies
>     next hop ${B as seen from A}, GigabitEthernet0/1.7
>     valid cached adjacency
>     tag rewrite with Gi0/1.7, ${B as seen from A}, tags imposed: {}
> 
> Am I correct in supposing that there should be a tag imposed there?

Yes, there should. 

> When I do the same on B I do see a tag imposed, the same 396 as B
> prepends to the vpn label when I do the sh ip cef for the VPN route,
> that seems normal.
> 
> Could this possibly be some kind of redistribution problem between BGP
> and OSPF? I redistribute some internal routes between BGP and OSPF,
> but the why and the "how to avoid" of that is a story in itself.

Oh. So is D's loopback seen via BGP, not via OSPF? as LDP doesn't assign
or advertise any labels to BGP prefixes, you end up without a tag on D.
Can you "fix" this by putting the route in an IGP and send it to D? 

	oli
 


More information about the cisco-nsp mailing list