[j-nsp] ACX Questions
For the ACX line, what is the Maximum number of MPLS labels in a packet’s label stack (push, pop, and swap operations)? Specifically, mostly interested in the ACX5048 and ACX2200's I found the following chart for the QFX line, and it was extremely helpful. I haven't been able to find the same information for the ACX Line however: https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-scaling-values-qfx-series.html Can anyone confirm or deny if the ACX5048's hardware is identical to the QFX5100? My understanding is they run a different JUNOS load on them, but hardware wise they are extremely similar. On the hardware side, is there anything in the ACX5048 that would allow more MPLS labels in a packet’s label stack than the QFX5100? For the ACX line, do they support streaming telemetry? I am not sure exactly what to look for on the streaming telemetry support for the ACX. I basically just want to see realtime interface and optical stats. Which JTI feature is that? For the ACX5000, there are only 3 items listed under the Junos Telemetry Interface section. https://apps.juniper.net/feature-explorer/select-platform.html?category=Routing=1#family==10105000=ACX5000=20.4R1=1093=0.42180881218269106=Junos%20OS For comparison, the QFX 5100 shows 21 different features under the JTI Section: https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1#family==31705100=QFX5100=20.4R1=1093=0.566764714896294=Junos%20OS Which feature am I looking for? Yes, I know this will require a collector of some sort. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Integrate different DC technology over VXLAN
Dear experts, do you have any suggestion where I can find useful information over www in order to provide DC interconnection of my two merging customers where one is running MPLS/VPLS with Juniper technology and the other one EVPN/VXLAN with Cisco ? The customer would like to explore the possibility to use VXLAN to extend L2... Also any recommendation/hint/experience can be shared is appreciated. Thanks in advance for your help Cheers James ___ 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.
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.
--- 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.
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
