On Thu, Oct 9, 2014 at 4:43 PM, Ewen McNeill <nznog(a)ewen.mcneill.gen.nz>
FWIW, it appears to me that sending two 0x8100
tags stacked is not
802.1ad, but some "pre-standard" double tagging.
Even if the frames
started out 802.1ad compliant. 802.1ad seems to require a SVLAN tag
(0x88a8) around a CVLAN tag (0x8100). Although it appears the difference
mostly only matters for the interpretation of this one bit (DEI or CFI).
If Chorus is going to offer 0x8100-double-tagging (ie, two 0x8100 tags
stacked, pre-802.1ad Q-in-Q) it seems like it'd maximise compatibility if
you were able to clear bit 5 (CFI on 0x8100/DEI on 0x88a8) of the tag in
that specific case (ie, two stacked 0x8100 tags).
I've been trying to do some reading on what might happen on our Juniper
MX80 on ingress from a Chorus handover.
We are only inspecting one VLAN at this stage - the outer VLAN ID. Junos
seems to default to 0x8100 so by not specifying a TPID we are looking for
0x8100 tags. My best understanding is that based on this the Juniper is
looking for the 802.1Q standard. Thus:
"The Canonical Format Indicator (CFI) bit indicates whether the following
12 bits of VLAN identifier conform to Ethernet or not. For Ethernet frames,
this bit is always set to 0. (The other possible value, CFI=1, is used for
Token Ring LANs, and tagged frames should never be bridged between an
Ethernet and Token Ring LAN regardless of the VLAN tag or MAC address.)"
From my reading it would also seem that when having the
CFI bit set to be
1, if the frame was even accepted then the MAC address would be
Another interesting comment from the O'Reilly Juniper MX book is:
"Canonical Format Indicator (CFI)
This is a one-bit field that specifies which direction to read the MAC
value of 1 indicates a noncanonical format, whereas a value of 0 indicates
format. Ethernet and IEEE 802.3 always use a canonical format and the least
significant bits first, whereas Token Ring is the opposite and sends the
bit first. This is really just an outdated relic and the CFI will always
a value of 0 on any modern Ethernet network."
I should have a good test case set-up soon and I should have a better
understanding of what is going on within our MXs.
If anyone else has a better understanding of what might happen on a Juniper
MX here when the TPID is 0x8100 please let us know.