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

[Olivier Benghozi]

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.ristimaki at 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.ristimaki at csc.fi <mailto: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).