[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15
Jonas,
As expected - the problem is related to vc type negotiation.
You have hit CSCuq28998 :)
talk to your cisco rep
Workaround:
- configure VC type 5 between the routers (configured on HP side)
- configuring no-control-word
The bug has been reported in 15.2(4)S4a, perhaps there?s an image with the problem fixed.
Cheers,
Jeff
On 11/14/15, 17:31, "Jonas Bjork" <mr.jonas.bjork at me.com> wrote:
>Dear Mr. Jeff,
>
>Thank you for your reply. Below is the complete output in question (l2 is short for l2transport).
>You are mentioning platform capabilities and that the default might have changed. How do I alter this?
>
>pe#sh mpls l2 vc 42 d
>Local interface: Po190.42 up, line protocol up, Eth VLAN 42 up
> Destination address: X.X.1.89, VC ID: 42, VC status: down
> Last error: Imposition VLAN rewrite capability mismatch with peer
> Output interface: none, imposed label stack {}
> Preferred path: not configured
> Default path: no route
> No adjacency
> Create time: 00:00:59, last status change time: 00:31:40
> Last label FSM state change time: 00:00:18
> Last peer autosense occurred at: 00:00:18
> Signaling protocol: LDP, peer X.X.1.89:0 up
> Targeted Hello: X.X.0.2(LDP Id) -> X.X.1.89, LDP is UP
> Graceful restart: not configured and not enabled
> Non stop routing: not configured and not enabled
> Status TLV support (local/remote) : enabled/not supported
> LDP route watch : enabled
> Label/status state machine : remote invalid, LruRnd
> Last local dataplane status rcvd: No fault
> Last BFD dataplane status rcvd: Not sent
> Last BFD peer monitor status rcvd: No fault
> Last local AC circuit status rcvd: No fault
> Last local AC circuit status sent: DOWN PW(rx/tx faults)
> Last local PW i/f circ status rcvd: No fault
> Last local LDP TLV status sent: No fault
> Last remote LDP TLV status rcvd: Not sent
> Last remote LDP ADJ status rcvd: No fault
> MPLS VC labels: local 242, remote 1199
> Group ID: local 0, remote 0
> MTU: local 9216, remote 9216
> Remote interface description:
> Remote VLAN id: 42
> Sequencing: receive disabled, send disabled
> Control Word: Off (configured: autosense)
> SSO Descriptor: X.X.1.89/42, local label: 242
> Dataplane:
> SSM segment/switch IDs: 0/0 (used), PWID: 142
> VC statistics:
> transit packet totals: receive 0, send 0
> transit byte totals: receive 0, send 0
> transit packet drops: receive 0, seq error 0, send 0
>pe#
>
>Anyone else: feel free to join in. Maybe we have any L2VC/PW ninjas watching.
>
>Best regards,
>Jonas Bjork
>
>
>> On 15 Nov 2015, at 1:26, Jeff Tantsura <jeff.tantsura at ericsson.com> wrote:
>>
>> Been forever since i looked at cisco, however sounds like vc type mismatch. They used to have it as a platform capability, perhaps SW upgrade changed the default.
>>
>> to my memory "show mpls l2 transport" should provide enough details.
>>
>> Hope this helps
>>
>> Regards,
>> Jeff
>>
>>> On Nov 14, 2015, at 4:50 AM, Jonas Bjork <mr.jonas.bjork at me.com> wrote:
>>>
>>> Hi, I am using a couple of AToM/EoMPLS tunnels in order to carry customer voice and data traffic across our IP/MPLS core, and it is currently working just fine. The first side consists of a Cisco 7600 router (rsp) and the other one is an HP A5500-HI routing switch with full LER/E-LSR capability. At the HP site, the tunnels are facing the access ports towards our premium end-customers; and on the Cisco PE I terminate the tunnels on one of the 2x10GE portchannel backbone links. There is vlan X on the HP side and vlan Y on the Cisco side - vlan rewrite is working perfectly - as long as I use IOS 12.
>>>
>>> After upgrading the Cisco router software to IOS 15 the tunnels won't come up. sh mpls l2 vc Y d says:
>>> ...
>>> Last error: Imposition VLAN rewrite capability mismatch with peer
>>> ...
>>>
>>> I use almost exactly the same Cisco configuration before and after the upgrade (only minor changes and nothing related to this) and I havn't touched the HP. Apparently they don't talk the same L2PW language. I wonder though, why now? We use service instances on the HP switchport as endpoint, we initiate the targetted LDP session in addition to the pseudowire handshake from a sub interface MPLS crossconnect. There is no MTU mismatch; not here - not anywhere.
>>>
>>> Anyone heard of this issue or experienced it?
>>>
>>> Best regards,
>>>
>>> Jonas Bj?rk
>>> SNE, Europe/Sweden (hope you guys will help me anyway:)
>