Re: [j-nsp] Junos 20 - slow RPD

[Luca Salvatore via juniper-nsp]

I've been down the path of very slow RPD with JTAC recently.  In our case
it was due to some mildly complex BGP community stuff that we do which was
exhausting memory limits.
A good fix for us was to bump up the memory allocation using these hidden
commands:

set policy-options as-path-match memory-limit 16m
set policy-options community-match memory-limit 16m

Default memory is 2097152 bytes, so very small.  You can see some
interesting numbers with some other hidden commands:

show policy community-match
show policy as-path-match

Also if you're running EVPN, check out this PR which is a whole world of
fun
https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1616167



On Fri, Mar 25, 2022 at 6:27 AM Mark Tinka via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:

>
>
> On 3/25/22 11:21, Mihai via juniper-nsp wrote:
>
> > In my case I just upgraded one MX204 in the lab to 21.2R2, enabled
> > rib-sharding and increased the JunosVM memory to 24G and things look
> > better now.
>
> Glad to hear!
>
> Mark.
> ___
> 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] MX204

[Luca Salvatore via juniper-nsp]

It is feasible that we'll push more than 200Gb/s
Any idea what performance is like above that level?

On Tue, May 15, 2018 at 12:59 PM Tim Jackson <jackson@gmail.com> wrote:

> I think you're in the ~200gbps range for them if VXLAN is considered
> tunnel services. If not it should be line rate.
>
> ARP scale on 204 is rather large, even when terminating over a VTEP.
>
> That's my exact use case for the MX 204 tbh.
>
> On Tue, May 15, 2018, 11:49 AM Luca Salvatore via juniper-nsp <
> juniper-nsp@puck.nether.net> wrote:
>
>> How is the MX204 for VXLAN routing (routing between VXLANs)
>> Can i expect close to line rate performance for that?
>> Curious how it would stack up against triednt2+ based switches fo VXLAN
>> routing.
>>
>> On Mon, May 14, 2018 at 8:44 PM Mark Tinka <mark.ti...@seacom.mu> wrote:
>>
>> >
>> >
>> > On 15/May/18 02:24, Aaron Gould wrote:
>> > > Does it have lots of MPLS service capability?
>> >
>> > It's the same Trio chip you find in modern MPC's. So I expect so.
>> >
>> > Testing some shortly.
>> >
>> > Mark.
>> > ___
>> > 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] MX204

[Luca Salvatore via juniper-nsp]

How is the MX204 for VXLAN routing (routing between VXLANs)
Can i expect close to line rate performance for that?
Curious how it would stack up against triednt2+ based switches fo VXLAN
routing.

On Mon, May 14, 2018 at 8:44 PM Mark Tinka  wrote:

>
>
> On 15/May/18 02:24, Aaron Gould wrote:
> > Does it have lots of MPLS service capability?
>
> It's the same Trio chip you find in modern MPC's. So I expect so.
>
> Testing some shortly.
>
> Mark.
> ___
> 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] 40G QSFP problems on QFX5100 after 16.1R6

[Luca Salvatore via juniper-nsp]

Also experienced these issues with most versions above 14.1X53.
FWIW I've had no problems with 17.3R2-S1.2, but we did have issues with
17.4R1

We're working with our account team to try and sort this stuff out

On Tue, Apr 24, 2018 at 8:21 AM Sebastian Wiesinger 
wrote:

> * Chris via juniper-nsp  [2018-04-24 09:58]:
> > I can't keep switching firmware around to try and resolve this/isolate
> to a
> > specific revision, but it is interesting that you also note you have not
> > experienced any issues with 16.1, the same as us. If you get a proper
> answer
> > to what this issue is I would really like to know, but it looks like I
> will
> > probably have to downgrade to 16.1 due to these issues as they are
> impacting
> > services.
>
> Interesting stuff, I'm fishing around but I'm suspecting perhaps this
> is some sort of timing issue. Just be aware that 16.1R6 is also a
> "bad" version from our point of view. 16.1R5-S2 is fine.
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> 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] Routing Engine filtering on EX with VRF

[Luca Salvatore via juniper-nsp]

Try putting an loopback interface into the vrf e.g lo0.1 and applying the
filer to that.

On Sat, Mar 19, 2016 at 4:02 PM, Raphael Mazelier  wrote:

>
>
>>
>> On EX, you should be able to protect the RE using a filter on lo0 in the
>> main routing instance (not in the VRF itself).
>> But be aware that this does not work on tha ACX-series (for some strange
>> reason)...
>>
>>
> Yep the firewall filter work for interfaces that are on the main
> routing-instance. But for some reason the filter does not apply on traffic
> coming from interface placed in a vrf to the RE.
>
>
> --
> Raphael Mazelier
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Luca Salvatore
Manager, Network Team | DigitalOcean
Phone: +1 (929) 214-7242
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5200 and other software than JunOS

[Luca Salvatore via juniper-nsp]

Juniper announced a while back (at their NXTWORK conference ) that the
QFX5200 would be open.  Best to reach out to your account rep to see
exactly what the details are.
The QFX5200 isn't shipping just yet, i believe it the 32 port one will be
Q1 2016 and the 64 port will be Q2

We use lots of the QFX5100-24Q and they have been solid.

On Mon, Dec 7, 2015 at 5:17 AM, Raphael Mazelier  wrote:

> Nope you couldn't install Cumulus or other "Open" network os on QFX5200.
> Switch need to support ONIE (Open Network Install Environment) to allow
> the installation of such network oses.
> Afaik Juniper OCX1100-48SX is the only switch that support onie. It was
> pretty much the same hardware as the QFX5100.
>
> --
> Raphael Mazelier
>
>
> Le 05/12/15 12:02, Robert Hass a écrit :
>
> Hi
>> I'm thinking about new QFX5200 and idea of software-less box (whitebox).
>> Please correct me if I'm wrong - can I buy QFX5200 without software and
>> install Cumulus Linux on it as 3rd party software ? (I'm doing this right
>> now on Dell switches for one project)
>>
>> Rob
>> ___
>> 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
>



-- 
Luca Salvatore
Network Engineering Manager | DigitalOcean
Phone: +1 (929) 214-7242
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp