[j-nsp] A wierd problem with QinQ at QFX5100
eising at nordu.net
Tue May 23 04:58:56 EDT 2017
Excerpts from Andrew Osnach's message of May 23, 2017 10:31 am:
> I have a mixed VC (QFX5100 and 3500, if it means) with 14.1X53-D40.8.
> There's an interface that incapsulates C-VLANs into S-VLAN:
> set interfaces ae31 flexible-vlan-tagging
> set interfaces ae31 mtu 9216
> set interfaces ae31 encapsulation extended-vlan-bridge
> set interfaces ae31 unit 3174 vlan-id-list 21-22
> set interfaces ae31 unit 3174 input-vlan-map push
> set interfaces ae31 unit 3174 input-vlan-map vlan-id 3174
> set interfaces ae31 unit 3174 output-vlan-map pop
> The other side:
> set interfaces ae0 flexible-vlan-tagging
> set interfaces ae0 mtu 9216
> set interfaces ae0 encapsulation extended-vlan-bridge
> set interfaces ae0 unit 3174 vlan-id 3174
> S-VLAN configured like this:
> set vlans sv3174-qinq interface ae0.3174
> set vlans sv3174-qinq interface ae31.3174
> At this point everything works fine, but if I create a VLAN with the
> same ID as a C-VLAN (21 or 22):
> set vlans v21-user vlan-id 21
> the traffic in the C-VLAN 21 stops.
> When I delete v21-user the traffic in C-VLAN 21 restores.
> What's wrong with it and how can I fix it?
QinQ on the QFX and all the other boxes running the ELS style is a bit
of an abomination.
VLANs configured with extended-vlan-bridge interfaces are forwarded
using a different daemon than VLANs forwarded using the
classic ethernet-switching daemon.
It's quite likely that you cannot share VLAN IDs between the two methods of forwarding.
I would bug Juniper about this, but I wouldn't expect them to be able to
More information about the juniper-nsp