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

[Antti Ristimäki]

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).
>> > 
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>> > 
>> > 
>> > --
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp