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 [email protected] 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 [email protected] > 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 [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
