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

[Antti Ristimäki]

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.ristimaki at 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_thomann at 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 snar at 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).
>>> > 
>>> > _______________________________________________