[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