Mailing List Archive

Hi Alexandre,

Did it pass frames without C-tag in Junos versions < 18?

Kind regards,
Andrey

Alexandre Snarskii ????? 2019-03-22 13:03:
> 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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
> Hi Alexandre,
>
> Did it pass frames without C-tag in Junos versions < 18?

Yes.

tcpdump from upstream side when switch running 17.4R1-S6.1:

tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 262144 bytes
17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46

exactly the same setup, switch upgraded to 18.3R1-S2.1:

18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46

as you see, packets that were transferred with only S-vlan tag
now encapsulated with both S-vlan and 'native' vlan..


>
> Kind regards,
> Andrey
>
> Alexandre Snarskii ????? 2019-03-22 13:03:
> > 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
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

4 months old thread, but (since I'm starting to test some QinQ stuff just now), I found both this thread and its «solution»:

PR1413700
«Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms»
«On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, untagged traffic over S-VLAN is forwarded with a single tag, whose processing behavior is not in line with other products (e.g., the MX platforms) and other providers (e.g., Cisco). If Q-in-Q is configured between these devices with different processing behavior of untagged traffic, this might cause the untagged traffic loss.»

So if I understand well, they suddenly chose compatibility with Cisco & MX instead of compat with old EX (whereas an option would have been fine).
The problem is: I'm not sure at all that it's really the case on Cisco gears...


> Le 24 mars 2019 à 16:36, Alexandre Snarskii <snar@snar.spb.ru> a écrit :
>
> On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
>> Hi Alexandre,
>>
>> Did it pass frames without C-tag in Junos versions < 18?
>
> Yes.
>
> tcpdump from upstream side when switch running 17.4R1-S6.1:
>
> tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> 17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
>
> exactly the same setup, switch upgraded to 18.3R1-S2.1:
>
> 18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> 18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
>
> as you see, packets that were transferred with only S-vlan tag
> now encapsulated with both S-vlan and 'native' vlan..
>
>
>>
>> Kind regards,
>> Andrey
>>
>> Alexandre Snarskii ????? 2019-03-22 13:03:
>>> 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

On 23/Jul/19 01:45, Olivier Benghozi wrote:

>
> So if I understand well, they suddenly chose compatibility with Cisco & MX instead of compat with old EX (whereas an option would have been fine).
> The problem is: I'm not sure at all that it's really the case on Cisco gears...

The main reason we dropped all our Juniper EX's and went to Arista.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Can you confirm Arista behaviour on this point? :)

On our side we now have a working config on EX4600 18.4R2 here (one NNI interface with simultaneous ethernet-switching-family unit 0 plus multiple QinQ vlan-bridge tagged units, and a bunch of extended-vlan-bridge UNIs interfaces), but the native-vlan isn't a problem here.

> Le 23 juil. 2019 à 07:57, Mark Tinka <mark.tinka@seacom.mu> a écrit :
>
> On 23/Jul/19 01:45, Olivier Benghozi wrote:
>
>> So if I understand well, they suddenly chose compatibility with Cisco & MX instead of compat with old EX (whereas an option would have been fine).
>> The problem is: I'm not sure at all that it's really the case on Cisco gears...
>
> The main reason we dropped all our Juniper EX's and went to Arista.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 23/Jul/19 17:31, Olivier Benghozi wrote:
> Can you confirm Arista behaviour on this point? :)

2 lines:

interface Ethernet25
   switchport access vlan 100
   switchport mode dot1q-tunnel

Arista still don't tunnel as many protocols in L2PT as Juniper and Cisco
do, but they are adding support.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Tue, Jul 23, 2019 at 01:45:19AM +0200, Olivier Benghozi wrote:
> 4 months old thread, but (since I'm starting to test some QinQ stuff just
> now), I found both this thread and its «solution»:
>
> PR1413700
> «Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms»
> «On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, untagged
> traffic over S-VLAN is forwarded with a single tag, whose processing behavior
> is not in line with other products (e.g., the MX platforms) and other providers
> (e.g., Cisco). If Q-in-Q is configured between these devices with different
> processing behavior of untagged traffic, this might cause the untagged traffic
> loss.»
>
> So if I understand well, they suddenly chose compatibility with Cisco & MX
> instead of compat with old EX (whereas an option would have been fine).
> The problem is: I'm not sure at all that it's really the case on Cisco gears...

According to our SE, this behaviour will be configurable in 18.3R3, 18.4R3
and 19.1R2.

>
>
> > Le 24 mars 2019 à 16:36, Alexandre Snarskii <snar@snar.spb.ru> a écrit :
> >
> > On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
> >> Hi Alexandre,
> >>
> >> Did it pass frames without C-tag in Junos versions < 18?
> >
> > Yes.
> >
> > tcpdump from upstream side when switch running 17.4R1-S6.1:
> >
> > tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 262144 bytes
> > 17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > 17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> >
> > exactly the same setup, switch upgraded to 18.3R1-S2.1:
> >
> > 18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > 18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> >
> > as you see, packets that were transferred with only S-vlan tag
> > now encapsulated with both S-vlan and 'native' vlan..
> >
> >
> >>
> >> Kind regards,
> >> Andrey
> >>
> >> Alexandre Snarskii ????? 2019-03-22 13:03:
> >>> 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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Fri, Jul 26, 2019 at 03:13:52PM +0300, Alexandre Snarskii wrote:
> On Tue, Jul 23, 2019 at 01:45:19AM +0200, Olivier Benghozi wrote:
> > 4 months old thread, but (since I'm starting to test some QinQ stuff just
> > now), I found both this thread and its «solution»:
> >
> > PR1413700
> > «Untagged traffic is single-tagged in Q-in-Q scenario on EX4300 platforms»
> > «On EX4300 platforms except for EX4300-48MP with Q-in-Q configured, untagged
> > traffic over S-VLAN is forwarded with a single tag, whose processing behavior
> > is not in line with other products (e.g., the MX platforms) and other providers
> > (e.g., Cisco). If Q-in-Q is configured between these devices with different
> > processing behavior of untagged traffic, this might cause the untagged traffic
> > loss.»
> >
> > So if I understand well, they suddenly chose compatibility with Cisco & MX
> > instead of compat with old EX (whereas an option would have been fine).
> > The problem is: I'm not sure at all that it's really the case on Cisco gears...
>
> According to our SE, this behaviour will be configurable in 18.3R3, 18.4R3
> and 19.1R2.

19.3R1: set interface ... input-native-vlan-push disable

> >
> > > Le 24 mars 2019 à 16:36, Alexandre Snarskii <snar@snar.spb.ru> a écrit :
> > >
> > > On Fri, Mar 22, 2019 at 04:21:47PM -0400, Andrey Kostin wrote:
> > >> Hi Alexandre,
> > >>
> > >> Did it pass frames without C-tag in Junos versions < 18?
> > >
> > > Yes.
> > >
> > > tcpdump from upstream side when switch running 17.4R1-S6.1:
> > >
> > > tcpdump: listening on ix1, link-type EN10MB (Ethernet), capture size 262144 bytes
> > > 17:59:15.742379 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > > 17:59:16.773827 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 171, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > >
> > > exactly the same setup, switch upgraded to 18.3R1-S2.1:
> > >
> > > 18:19:28.535143 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > > 18:19:29.598700 0c:c4:7a:93:a6:8e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 68: vlan 171, p 0, ethertype 802.1Q, vlan 1, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.11.1.2 tell 10.11.1.1, length 46
> > >
> > > as you see, packets that were transferred with only S-vlan tag
> > > now encapsulated with both S-vlan and 'native' vlan..
> > >
> > >
> > >>
> > >> Kind regards,
> > >> Andrey
> > >>
> > >> Alexandre Snarskii ????? 2019-03-22 13:03:
> > >>> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

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@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@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@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

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@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@csc.fi <mailto:antti.ristimaki@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@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@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