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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:) >
