On Fri, Jul 26, 2019 at 03:13:52PM +0300, Alexandre Snarskii wrote: > On Tue, Jul 23, 2019 at 01:45:19AM +0200, Olivier Benghozi wrote: > > 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... > > According to our SE, this behaviour will be configurable in 18.3R3, 18.4R3 > and 19.1R2.
19.3R1: set interface ... input-native-vlan-push disable > > > > > Le 24 mars 2019 à 16:36, Alexandre Snarskii <s...@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). > > >>> > > _______________________________________________ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp