Best explained with a diagram... (the port shown here is on a QFX 5100)
Single-tagged
VLANS 2-513,1000
ingress
|
|
|
\_/
-----------------
| |
| ge-0/0/6 |
| |
-----------------
| |
| |
if VLAN if VLAN
2-513 then 1000 swap
push outer that to be
VLAN 1234 VLAN 42
| |
| |
send CVLAN send single
& SVLAN tagged VLAN
inside a 42 inside
l2circuit a l2circuit
| |
| |
----------- -----------
| | | |
| vc id 5 | | vc id 9 |
| | | |
----------- -----------
These virtual circuits are encapsulated as circuit cross-connect (CCC) l2circuits and connect to logical-tunnel units on an MX960 (which are peered with another unit that then pops them into two different VPLS routing instances)
Example config...
QFX side...
[...]
interfaces {
[...]
ge-0/0/6 {
flexible-vlan-tagging;
mtu 1800;
encapsulation flexible-ethernet-services;
unit 2 {
description "Test NNI - CCC for customer VLANs";
encapsulation vlan-ccc;
vlan-id-list 2-513;
input-vlan-map {
push;
vlan-id 1234;
}
output-vlan-map pop;
}
unit 1000 {
description "Test NNI - CCC for management";
encapsulation vlan-ccc;
vlan-id 1000;
input-vlan-map {
swap;
vlan-id 42;
}
output-vlan-map swap;
}
}
[...]
}
[...]
protocols {
l2circuit {
neighbor 192.168.0.1 {
[...]
interface ge-0/0/6.2 {
virtual-circuit-id 5;
description "Test NNI - CCC for customer VLANs";
mtu 1800;
}
interface ge-0/0/6.1000 {
virtual-circuit-id 9;
description "Test NNI - CCC for management";
mtu 1800;
}
[...]
}
[...]
}
[...]
}
[...]
MX side...
[...]
interfaces {
[...]
lt-1/1/0 {
logical-tunnel-options {
per-unit-mac-disable;
}
[...]
unit 1102 {
description "Test NNI - CCC for customer VLANs";
encapsulation vlan-ccc;
mtu 1800;
vlan-id 1234;
peer-unit 1101;
family ccc;
}
unit 1101 {
description "Test NNI - CCC for customer VLANs";
encapsulation vlan-vpls;
mtu 1800;
vlan-id 1234;
peer-unit 1102;
family vpls;
}
}
[...]
lt-1/3/0 {
logical-tunnel-options {
per-unit-mac-disable;
}
[...]
unit 1202 {
description "Test NNI - CCC for management";
encapsulation vlan-ccc;
mtu 1800;
vlan-id 42;
peer-unit 1201;
}
unit 1201 {
description "Test NNI - CCC for management";
encapsulation vlan-vpls;
mtu 1800;
vlan-id 42;
peer-unit 1202;
}
}
[...]
}
[...]
protocols {
[...]
l2circuit {
neighbor 192.168.0.2 {
[...]
interface lt-1/3/0.1202 {
virtual-circuit-id 9;
description "Test NNI - CCC for management";
mtu 1800;
}
interface lt-1/1/0.1102 {
virtual-circuit-id 5;
description "Test NNI - CCC for customer VLANs";
mtu 1800;
}
[...]
}
[...]
}
[...]
routing-instances {
[...]
management-vpls {
instance-type vpls;
vlan-id all;
interface lt-1/1/0.1201;
[...]
route-distinguisher 192.168.0.1:65002;
vrf-target target:65002:0;
protocols {
vpls {
no-tunnel-services;
site MX960 {
automatic-site-id;
}
connectivity-type permanent;
}
}
}
[...]
customer-vpls {
instance-type vpls;
vlan-id all;
interface lt-1/1/0.1101;
[...]
route-distinguisher 192.168.0.1:65001;
vrf-target target:65001:0;
protocols {
vpls {
no-tunnel-services;
site MX960 {
automatic-site-id;
}
connectivity-type permanent;
}
}
}
[...]
}
[...]
No matter which way we've tried to configure this, we always find that the CVLAN data (VLANs 2-513 inside SVLAN 1059) never make it through. But the management data (VLAN 1000 swapped to VLAN 41) works fine.
So we think it's something to do with the vlan-id-list being used.
We've also tried connecting virtual circuit 5 to a port on another QFX instead (just so we can easily examine the traffic coming out of it) and nothing seems to come through.
Yet the status of these virtual circuits is up, no issues are shown there.
Our guess is that we're mixing switch-chip functions with non-switch-chip functions which won't work... can anyone propose an alternative way of doing this?
Short of using two physical ports connected directly together... or asking the upstream (that we've taken an NNI from) for a second link, just for management!