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
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
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.
--- 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.
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
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
> >
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
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
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
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
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
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
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
13 matches
Mail list logo
