EoMPLS vlan rewrite between brands; possibly new bug in Cisco IOS 15

James Bensley jwbensley at gmail.com
Mon Nov 16 09:21:26 UTC 2015


On 15 November 2015 at 01: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

Hi Jonas,

In that output you have "Remote VLAN id: 42" -What is the local VLAN
ID on your Cisco PE? Do you need to VLAN rewrite here?

Since you using different VLANs at each end, can you build the
pseudowire at a point in the network stack where the VLAN tag has been
popped off already and transport the frames untagged, so they will be
pushed on again at the other end? (Is this is a VC type 4 pseudowire,
check with "show mpls l2transport binding 42", if so, a dummy VLAN
should be pushed on and popped off transparently if all hardware in
use supports it).

I don't know HP but with the Cisco 7600 for example, if it's VLAN 50
then you could add "interface vlan 50; xconnecy X.X.1.89 42 encaps
mpls", if your hardware supports that. Or use mux-uni; "int gix/x.y;
encaps dot1q y; xconnecy X.X.1.89 42 encaps mpls". Then add vice versa
on the HP kit.

What IOS have you tried to upgrade to, 15.2(4)S4a? If this is a VC
type 4 pseudowire and either the HP or Cisco isn't supporting
inserting a dummy VLAN tag, why is this a VC type 4 pseudowire? The
VLAN re-write I guess. Certainly in IOS 15.3 (so probably also in 15.2
but I'm not 100% certain of that) Cisco IOS should be defaulting to VC
type 5 unless the other end negotiates down to VC type 4. VC type 5 in
IOS supports transporting of untagged, tagged and double tagged
frames, I don't think there is any functionality in VC type 5 that
wasn't in older type 4's so I'd try and work out why your devices are
negotiating type 4 and maybe try to fix that, or as above, transport
untagged.

Cheers,
James.



More information about the NANOG mailing list