[c-nsp] EoMPLS/Sup32/xconnect - missing something obvious

L'argent largent at ai.net
Sat May 23 20:11:08 EDT 2009


L'argent wrote:
> Gert Doering wrote:
>>
>> On the interface that forms the EoMPLS bridge ("towards the customer"),
>> you should NOT enable any MPLS stuff.  (I'm not sure what happens if
>> you do, but that's not required).
>>
>>   
> Ok. Removed.
>
>> You need the MPLS stuff on the 10G interface that interconnects the
>> routers.
>>
>> Then check "show ip cef 10.0.0.114" on this router, and it should tell
>> you that a MPLS path exists ("nexthop ... label yy")
>>
>>   
> I posted the ip cef detail for the two loopbacks and I don't see a 
> label applied after the nexthop. So no MPLS path exists.  What should 
> I check next?
>>> #sh mpls l2 binding
>>>   Destination Address: 10.0.0.114,  VC ID: 100
>>>     Local Label:  unassigned.
>>>     Remote Label: unassigned
>>>     
>>
>> This might be due to missing "mpls ip" on the 10G link.
>>
>>  
>>> #sh mpls interfaces
>>> Interface              IP            Tunnel   BGP Static Operational
>>> GigabitEthernet4/2     Yes           No       Yes No     No
>>>     
>>
>> ... indeed.  Don't enable MPSL on the customer-facing ports, enable it
>> on your "router-to-router" interfaces.
>>
>> gert
>>   
>
> So the topology looks like this:
>
> G4/2-T5/1 <---> T5/1- G4/2.
>
> G4/2 is customer facing.
> Tengig 5/1 is router1 to router 2 facing.
>
> Router 1's two interfaces now look like this:
>
> interface GigabitEthernet4/2
> mtu 1526
> no ip address
> speed nonegotiate
> xconnect 10.0.0.114 100 pw-class EtherEncap
>
> interface TenGigabitEthernet5/1
> mtu 1538
> ip address 10.1.1.37 255.255.255.252
> mpls traffic-eng tunnels
> mpls ldp discovery transport-address interface
> mpls bgp forwarding
> mpls label protocol ldp
> mpls ip
>
> #sh ip cef 10.0.0.114 detail
> 10.0.0.114/32, epoch 4
>  local label info: global/50
>  nexthop 10.1.1.38 TenGigabitEthernet5/1
>
> #sh ip cef 10.0.0.114
> 10.0.0.114/32
>  nexthop 10.1.1.38 TenGigabitEthernet5/1
>
> and
>
> Router 2:
>
> interface GigabitEthernet4/2
> mtu 1526
> no ip address
> speed nonegotiate
> xconnect 10.0.0.113 100 pw-class EtherEncap
>
> interface TenGigabitEthernet5/1
> mtu 1538
> ip address 10.1.1.38 255.255.255.252
> mpls traffic-eng tunnels
> mpls ldp discovery transport-address interface
> mpls bgp forwarding
> mpls label protocol ldp
> mpls ip
>
> #sh ip cef 10.0.0.113 detail
> 10.0.0.113/32, epoch 5
>  local label info: global/21
>  nexthop 10.1.1.37 TenGigabitEthernet5/1
>
> #sh ip cef 10.0.0.113
> 10.0.0.113/32
>  nexthop 10.1.1.37 TenGigabitEthernet5/1
>
> ----
>
> I cleared the mpls ldp neighbors and they reestablished, but no other 
> changes that I can determine. There does not appear to be an MPLS path 
> between the two 10G interfaces.
>
> sh mpls l2 binding on both routers shows unassigned labels, though the 
> ip cef seems to show a local label assigned.
>
> Where should I look next?
>
> Thanks so much for the assistance so far!
Both routers are reporting this on their tengig interfaces (now):

#sh mpls interfaces detail
Interface TenGigabitEthernet5/1:
        IP labeling enabled (ldp)
        LSP Tunnel labeling enabled
        BGP labeling enabled
        MPLS operational
        MTU = 1538


I don't know if there is some thing that should be reset to "reset" the 
xconnect, but I've tried a shut/no-shut without success.

Thanks.




More information about the cisco-nsp mailing list