[j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

[Olivier Benghozi]

4 months old thread, but (since I'm starting to test some QinQ stuff just now), I found both this thread and its «solution»:

PR1413700
«Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms»
«On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, untagged traffic over S-VLAN is forwarded with a single tag, whose processing behavior is not in line with other products (e.g., the MX platforms) and other providers (e.g., Cisco). If Q-in-Q is configured between these devices with different processing behavior of untagged traffic, this might cause the untagged traffic loss.»

So if I understand well, they suddenly chose compatibility with Cisco & MX instead of compat with old EX (whereas an option would have been fine).
The problem is: I'm not sure at all that it's really the case on Cisco gears...


> Le 24 mars 2019 à 16:36, Alexandre Snarskii <snar at snar.spb.ru> a écrit :
> 
> On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
>> Hi Alexandre,
>> 
>> Did it pass frames without C-tag in Junos versions < 18?
> 
> Yes. 
> 
> tcpdump from upstream side when switch running 17.4R1-S6.1:
> 
> tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> 17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> 
> exactly the same setup, switch upgraded to 18.3R1-S2.1:
> 
> 18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> 18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> 
> as you see, packets that were transferred with only S-vlan tag
> now encapsulated with both S-vlan and 'native' vlan..
> 
> 
>> 
>> Kind regards,
>> Andrey
>> 
>> Alexandre Snarskii писал 2019-03-22 13:03:
>>> Hi!
>>> 
>>> Looks like JunOS 18.something introduced an incompatibility of native
>>> vlan handling in QinQ scenario between ELS (qfx, ex2300) and non-ELS
>>> switches: when ELS switch forwards untagged frame to QinQ, it now adds
>>> two vlan tags (one specified as native for interface and S-vlan) 
>>> instead
>>> of just S-vlan as it is done by both non-ELS and 'older versions'.
>>> 
>>> As a result, if the other end of tunnel is non-ELS (or third-party)
>>> switch, it strips only S-vlan and originally untagged frame is passed
>>> with vlan tag :(
>>> 
>>> Are there any way to disable this additional tag insertion ?
>>> 
>>> PS: when frames sent in reverse direction, non-ELS switch adds only
>>> S-vlan and this frame correctly decapsulated and sent untagged.
>>> 
>>> ELS-side configuration (ex2300, 18.3R1-S1.4. also tested with
>>> qfx5100/5110):
>>> 
>>> [edit interfaces ge-0/0/0]
>>> flexible-vlan-tagging;
>>> native-vlan-id 1;
>>> mtu 9216;
>>> encapsulation extended-vlan-bridge;
>>> unit 0 {
>>>    vlan-id-list 1-4094;
>>>    input-vlan-map push;
>>>    output-vlan-map pop;
>>> }
>>> 
>>> (when native-vlan-id is not configured, untagged frames are not
>>> accepted at all).
>>>