Hi, actually Juniper published PR1568533 about this (as it should have worked like KB35261 says but it was not) – the PR says it's fixed in 19.4R3-S3 too, by the way.
Olivier > Le 19 mai 2021 à 13:26, Antti Ristimäki <antti.ristim...@csc.fi> a écrit : > > Hi list, > > Just as a follow-up and for possible future reference, 18.4R3-S7 indeed sends > the untagged customer frames with only SVLAN tag to QinQ uplink, but > 18.4R3-S8 again reverts the behaviour such that those frames are sent > double-tagged with both SVLAN and native-vlan. Tested with QFX5110-48S. > > The hidden command "input-native-vlan-push <enable|disable>" also seems to > work in S8, whereas in S7 it doesn't seem to have any impact. > > Antti > > ----- On 9 Apr, 2021, at 13:17, Antti Ristimäki antti.ristim...@csc.fi > <mailto:antti.ristim...@csc.fi> wrote: > >> Hi Karsten, >> >> Thanks for the link, I wasn't aware of such KB article, although there are >> several other articles related to native-vlan handling. >> >> The QFX5110 in question was previously running 17.3R3-S3 and there the >> native-vlan was indeed double-tagged on the uplink, just like the table says. >> But despite that the table says, at least 18.4R3-S7 sends the frames >> single-tagged, no matter whether or not "input-native-vlan-push" is >> configured. >> >> I will try to sort this out with JTAC. >> >> Antti >> >> ----- On NaN , 0NaN, at NaN:NaN, Karsten Thomann karsten_thom...@linfre.de >> wrote: >> >>> Hi, >>> >>> I haven't tested the behvaior, but to avoid the big surprises you should at >>> least check the tables in >>> the kb: >>> https://kb.juniper.net/InfoCenter/index?page=content&id=KB35261&actp=RSS >>> >>> As you're not writing the exact release, there was a change if you upgraded >>> from >>> R1 or R2. >>> >>> Kind regards >>> Karsten >>> >>> Am Freitag, 9. April 2021, 10:02:21 schrieb Antti Ristimäki: >>>> Hi list, >>>> >>>> Returning to this old thread. It seems that the behaviour has again >>>> changed, >>>> because after upgrading QFX5110 to 18.4R3-S7 the switch does not add the >>>> native-vlan tag when forwarding the frame to QinQ uplink. Previously with >>>> version 17.3 the switch did add the native-vlan tag along with the S-tag. >>>> It seems that "input-native-vlan-push <enable|disable>" is available as a >>>> hidden command in 18.4R3-S7, but it doesn't seem to have any impact on the >>>> behaviour. >>>> >>>> Any experience from others? >>>> >>>> Antti >>>> >>>> ----- On 22 Mar, 2019, at 19:03, Alexandre Snarskii s...@snar.spb.ru wrote: >>>>> 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