Re: [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  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 " 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.ristim...@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_thom...@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=KB35261=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 " 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 s...@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

Re: [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 " 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.ristim...@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_thom...@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=KB35261=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 " 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 s...@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

Re: [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_thom...@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=KB35261=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 " 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 s...@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

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

[Karsten Thomann via juniper-nsp]

--- Begin Message ---
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=KB35261=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 " 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 s...@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

--- End Message ---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[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 " 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 s...@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

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

[Alexandre Snarskii]

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

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

[Alexandre Snarskii]

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

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

[Mark Tinka]

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

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

[Olivier Benghozi]

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

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

[Mark Tinka]

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

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

[Olivier Benghozi]

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

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

[Andrey Kostin]

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

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

[Alexandre Snarskii]

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