Re: [j-nsp] VMX integrated FPC

[Nikolas Geyer]

Hi Lukasz.

Went scavenging through documentation and the requirements are not bigger, they 
are actually less.

Memory required is the same (3GB) but nested only requires 3 vCPU to run 
everything, versus the 4 vCPU required for non-nested.

So negligible reduction, but it’s definitely not bigger requirements for a 
basic life mode instance.

Cheers,
Nik. 

Sent from my iPhone

> On Dec 23, 2020, at 10:50 AM, Łukasz Bromirski  wrote:
> 
> Nikolas, Mark,
> 
>> On 23 Dec 2020, at 02:47, Nikolas Geyer  wrote:
>> 
>> vRR is basically just the VCP component of vMX without the vFP, which is why 
>> it’s limited to Linux bridged “management” interfaces.
>> 
>> There is nested vMX which runs the VCP as a nested virtual machine within 
>> the VFP,  not sure if it reduces requirements and iirc it only works on KVM.
> 
> VFP has very specific requirements w/r to cores and memory, it’s a superset 
> of VCP. So no, the requirements will be actually bigger:
> https://www.juniper.net/documentation/en_US/vmx/topics/reference/general/vmx-hw-sw-minimums.html
> 
> -- 
> Łukasz Bromirski
> CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VMX integrated FPC

[Nikolas Geyer]

vRR is basically just the VCP component of vMX without the vFP, which is why 
it’s limited to Linux bridged “management” interfaces.

There is nested vMX which runs the VCP as a nested virtual machine within the 
VFP,  not sure if it reduces requirements and iirc it only works on KVM.

Sent from my iPhone

> On Dec 21, 2020, at 6:43 PM, Mark Tees  wrote:
> 
> That's it. I actually wanted to see MX specific things get spun on up
> on interfaces from some code being developed.
> 
> Currently I have 2 x VMX's squashed into 4G's of RAM running under
> Vmware Fusion which currently does the job but it's a bit messy. I can
> probably fix the mess by generating the Vmware VM config files.
> 
> I should inspect the VRR image to see what it's doing and if there is
> anything that can be mimicked.
> 
> The other thing is if I am happy with just seeing the changes being
> loaded into control plane successfully I can just use a group but not
> apply it.
> 
>> On Tue, 22 Dec 2020 at 02:52, Saku Ytti  wrote:
>> 
>>> On Mon, 21 Dec 2020 at 18:27,  wrote:
>>> 
>>> I guess if you don't want any vfp VM and want to run vcp VM only then vRR or
>>> the cRDP are the possible options?
>> 
>> I suspect the requirement is MX feature/configuration validation, so
>> pps would be traded for simplicity of stack, down to 1pps. vRR and
>> cRPD would not be an acceptable answer for this use-case.
>> 
>> 
>> --
>>  ++ytti
> 
> 
> 
> -- 
> Regards,
> 
> Mark Tees
> ___
> 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] QFX10002 Inline Flow

[Nikolas Geyer]

What version did you upgrade from? Check out 
https://lkhill.com/juniper-qfx10k-ipfix/ as there were some things changed in 
Junos 17 that resulted in broken IPFIX.

Sent from my iPhone

On Dec 1, 2020, at 9:51 PM, Brendan Mannella  wrote:

Curious if anyone else has completely broken Inline flow on QFX10002 in any
of the recent recommended versions. It was running fine with the current
configuration, then we upgraded two different sets and both ended up with
broken flow.

We are running --- JUNOS 19.1R3-S3.2 Kernel 64-bit and --- JUNOS 20.2R2.11
Kernel 64-bit

Is anyone else seeing this?
___
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 OS Evolved

[Nikolas Geyer]

Data Center use cases, except some PTX1 products... albeit the ones that 
are dual personality with their QFX alter ego :-) 

Sent from my iPhone

> On Oct 13, 2020, at 3:30 PM, Richard McGovern  wrote:
> 
> I am thinking (guessing) you will not see EVO on MX for some time.  EVO is 
> mainly targeted at Data Center use cases, for which MX is used for DC to DC 
> connectivity, but not as a main stay within any DC.
> 
> My 2 cents worth.
> 
> Richard McGovern
> Sr Sales Engineer, Juniper Networks
> 978-618-3342
> 
> I’d rather be lucky than good, as I know I am not good
> I don’t make the news, I just report it
> 
> 
> On 10/11/20, 6:26 AM, "Saku Ytti"  wrote:
> 
>>On Sun, 11 Oct 2020 at 00:24, Colton Conor  wrote:
>> 
>> So is Junos OS Evolved available for the MX routers? How would you go from 
>> regular Junos to Junos OS Evolved on a MX 240/480/960 for example?
> 
>It is not, but expect to see it in future MX REs.
> 
> 
> 
>--
>  ++ytti
> 
> 
> 
> Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Suggestions for Edge/Peering Router..

[Nikolas Geyer]

I have to play devils advocate around “Right this inconsistency between 
configured and operational state in my opinion is THE biggest problem of XR”

Have had this problem occur multiple times in Junos, as recently as Junos 17, 
where what was being advertised did not reflect configured policy. Worse still, 
the only recovery was complete deletion of the policy (and any peers using it) 
then re-adding it.

So it’s definitely not a XR only problem. 

Sent from my iPhone

On Sep 19, 2019, at 8:11 AM, "adamv0...@netconsultings.com" 
 wrote:

>> From: Saku Ytti 
>> Sent: Thursday, September 19, 2019 12:33 PM
>> 
>>> On Thu, 19 Sep 2019 at 14:22,  wrote:
>>> 
>>> Just a few examples when you change export policy it resets the peer
>>> or the cockup with RR clearing all sessions or the fact BGP is part of
>>> very complex RDP monolith -to me that's not really "carrier grade"
>>> implementation
>> 
>> This happens when export policy breaks update-group. It may sometimes be
>> difficult for operator to understand if it will do that or not, so it's fair 
>> concern.
>> Perhaps system should not clear, but tell manual clear is needed for policy
>> change to take effect.
>> 
> Ideally I'd like to see equivalent of Cisco's dynamic update peer-groups in 
> Junos.
> 
>> If monolith is good or bad, I'm not sure. If you thread you have high
>> performance with some risk. If you have process separation you have IPC
>> problem, and you have low performance and many will solve this by
>> duplicating state. Junos is moving towards multi process model with Junos
>> Evolved, if this will be positive or negative direction remains to be seen.
>> 
> I like where XR and Junos Evolved is heading, 
> In future I'd like to have the option to install only stuff I need on a 
> particular type of node/deployment and not worry about the rest all the way 
> to being able to mix and match protocols of different vendors.  
> Although cRPD is also interesting development pathway, but again cBGP would 
> be even better :) 
> 
>> Operationally speaking, BGP in JunOS for us works great, on IOS-XR right now
>> we have sessions where policy isn't what is configured and there is no way to
>> verify which one, and we've propagated leaks because acting configuration
>> isn't the one we've configured. We've not had similar problems in JunOS. This
>> is anecdote, not data.
>> 
> Right this inconsistency between configured and operational state in my 
> opinion is THE biggest problem of XR, I'm afraid it has to be something 
> fundamental since they haven't been able to consistently address these 
> inconsistencies across the board for years now (or ASR9k HW? Not sure if 
> these types of issues can be experienced on other platforms).
> Though usually it's CP state does not trickle down to DP correctly/completely 
> where what you described seems to be CP only. 
> 
> adam
> 
> ___
> 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] "show ip cef exact-route"

[Nikolas Geyer]

Someone at Juniper has kindly reached out and advised that a similar command 
was added in 17.1R1 for the MX;

https://www.juniper.net/documentation/en_US/junos/topics/reference/command-summary/show-forwarding-options-load-balance-ingress-interface.html

Sent from my iPhone

On 14 May 2018, at 8:22 pm, Aaron Gould 
<aar...@gvtc.com<mailto:aar...@gvtc.com>> wrote:

Cisco and iOS xr has been good for me... Show cef (vrf xyz) .

Isn't Junos equivalent for showing FIB/PFE "show route forwarding" ?  This 
usually is good for me too

Aaron

On May 14, 2018, at 6:35 PM, Nikolas Geyer 
<n...@neko.id.au<mailto:n...@neko.id.au>> wrote:

The platforms I have used it on it has been correct, but that doesn’t include 
ASR9k.

Scary to think what you have said could happen, but I guess I shouldn’t be 
surprised.

Sent from my iPhone

On 14 May 2018, at 7:32 pm, Saku Ytti <s...@ytti.fi<mailto:s...@ytti.fi>> wrote:

Have you found cef exact-route to be correct?

Last time I used this (ASR9000), it was giving wrong results to me. I
think there is entirely separate piece of code for LAG result in
software code and the CSCO EZChip microcode, and different people code
IOS-XR than ezchip, so I think there is failure mode where one code is
updated, and another is not, I hope I'm wrong.

But if I'm right, then the only way to do this, is actually ask the
microcode 'hey i have this packet, do a lookup for it', or like in
CAT7600/ELAM, get lookup results for real traffic.

On 15 May 2018 at 02:27, Nikolas Geyer 
<n...@neko.id.au<mailto:n...@neko.id.au>> wrote:
Unless it’s changed in newer releases there is no equivalent which is annoying.

I believe you can drop to the FPC vty and extract the information card by card 
similar to the link you shared, but it’s not exactly a workable solution, nor 
“officially supported” by Juniper.

The lack of this command is literally my biggest frustration with Juniper.

Sent from my iPhone

On 11 May 2018, at 4:40 am, James Bensley 
<jwbens...@gmail.com<mailto:jwbens...@gmail.com>> wrote:

Hi All,

Does anyone know of a command like the Cisco CEF "exact-route" command
on Juniper?

I've seen this older thread: https://lists.gt.net/nsp/juniper/50645

Which links to a post on using JSIM but for DPC cards, but I'm
interested in MPC cards:
http://junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html

Does anyone have any details on using JSIM on MPC cards on MX
platforms? Or is there "another way" ?

I'm going to open a JTAC case as well as asking here however, in the
past they have rejected requests to explain PFE commands to me or
provide documentation for them. I have managed it a few times but only
after a couple of weeks of non-stop screaming. So I'm not holding my
breath for that option.

Kind regards,
James.
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp



--
++ytti
___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto: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] "show ip cef exact-route"

[Nikolas Geyer]

The benefit of exact-route is it lets you input the 5 tuples to see what egress 
link a packet will get hashed onto, which is useful when doing LACP bundles or 
ECMP.

Sent from my iPhone

> On 14 May 2018, at 8:22 pm, Aaron Gould <aar...@gvtc.com> wrote:
> 
> Cisco and iOS xr has been good for me... Show cef (vrf xyz) .
> 
> Isn't Junos equivalent for showing FIB/PFE "show route forwarding" ?  
> This usually is good for me too
> 
> Aaron
> 
>> On May 14, 2018, at 6:35 PM, Nikolas Geyer <n...@neko.id.au> wrote:
>> 
>> The platforms I have used it on it has been correct, but that doesn’t 
>> include ASR9k.
>> 
>> Scary to think what you have said could happen, but I guess I shouldn’t be 
>> surprised.
>> 
>> Sent from my iPhone
>> 
>>> On 14 May 2018, at 7:32 pm, Saku Ytti <s...@ytti.fi> wrote:
>>> 
>>> Have you found cef exact-route to be correct?
>>> 
>>> Last time I used this (ASR9000), it was giving wrong results to me. I
>>> think there is entirely separate piece of code for LAG result in
>>> software code and the CSCO EZChip microcode, and different people code
>>> IOS-XR than ezchip, so I think there is failure mode where one code is
>>> updated, and another is not, I hope I'm wrong.
>>> 
>>> But if I'm right, then the only way to do this, is actually ask the
>>> microcode 'hey i have this packet, do a lookup for it', or like in
>>> CAT7600/ELAM, get lookup results for real traffic.
>>> 
>>>> On 15 May 2018 at 02:27, Nikolas Geyer <n...@neko.id.au> wrote:
>>>> Unless it’s changed in newer releases there is no equivalent which is 
>>>> annoying.
>>>> 
>>>> I believe you can drop to the FPC vty and extract the information card by 
>>>> card similar to the link you shared, but it’s not exactly a workable 
>>>> solution, nor “officially supported” by Juniper.
>>>> 
>>>> The lack of this command is literally my biggest frustration with Juniper.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 11 May 2018, at 4:40 am, James Bensley <jwbens...@gmail.com> wrote:
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Does anyone know of a command like the Cisco CEF "exact-route" command
>>>>> on Juniper?
>>>>> 
>>>>> I've seen this older thread: https://lists.gt.net/nsp/juniper/50645
>>>>> 
>>>>> Which links to a post on using JSIM but for DPC cards, but I'm
>>>>> interested in MPC cards:
>>>>> http://junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>>>>> 
>>>>> Does anyone have any details on using JSIM on MPC cards on MX
>>>>> platforms? Or is there "another way" ?
>>>>> 
>>>>> I'm going to open a JTAC case as well as asking here however, in the
>>>>> past they have rejected requests to explain PFE commands to me or
>>>>> provide documentation for them. I have managed it a few times but only
>>>>> after a couple of weeks of non-stop screaming. So I'm not holding my
>>>>> breath for that option.
>>>>> 
>>>>> Kind regards,
>>>>> James.
>>>>> ___
>>>>> 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
>>> 
>>> 
>>> 
>>> -- 
>>> ++ytti
>> ___
>> 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] "show ip cef exact-route"

[Nikolas Geyer]

The platforms I have used it on it has been correct, but that doesn’t include 
ASR9k.

Scary to think what you have said could happen, but I guess I shouldn’t be 
surprised.

Sent from my iPhone

> On 14 May 2018, at 7:32 pm, Saku Ytti <s...@ytti.fi> wrote:
> 
> Have you found cef exact-route to be correct?
> 
> Last time I used this (ASR9000), it was giving wrong results to me. I
> think there is entirely separate piece of code for LAG result in
> software code and the CSCO EZChip microcode, and different people code
> IOS-XR than ezchip, so I think there is failure mode where one code is
> updated, and another is not, I hope I'm wrong.
> 
> But if I'm right, then the only way to do this, is actually ask the
> microcode 'hey i have this packet, do a lookup for it', or like in
> CAT7600/ELAM, get lookup results for real traffic.
> 
>> On 15 May 2018 at 02:27, Nikolas Geyer <n...@neko.id.au> wrote:
>> Unless it’s changed in newer releases there is no equivalent which is 
>> annoying.
>> 
>> I believe you can drop to the FPC vty and extract the information card by 
>> card similar to the link you shared, but it’s not exactly a workable 
>> solution, nor “officially supported” by Juniper.
>> 
>> The lack of this command is literally my biggest frustration with Juniper.
>> 
>> Sent from my iPhone
>> 
>>> On 11 May 2018, at 4:40 am, James Bensley <jwbens...@gmail.com> wrote:
>>> 
>>> Hi All,
>>> 
>>> Does anyone know of a command like the Cisco CEF "exact-route" command
>>> on Juniper?
>>> 
>>> I've seen this older thread: https://lists.gt.net/nsp/juniper/50645
>>> 
>>> Which links to a post on using JSIM but for DPC cards, but I'm
>>> interested in MPC cards:
>>> http://junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>>> 
>>> Does anyone have any details on using JSIM on MPC cards on MX
>>> platforms? Or is there "another way" ?
>>> 
>>> I'm going to open a JTAC case as well as asking here however, in the
>>> past they have rejected requests to explain PFE commands to me or
>>> provide documentation for them. I have managed it a few times but only
>>> after a couple of weeks of non-stop screaming. So I'm not holding my
>>> breath for that option.
>>> 
>>> Kind regards,
>>> James.
>>> ___
>>> 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
> 
> 
> 
> -- 
>  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] "show ip cef exact-route"

[Nikolas Geyer]

Unless it’s changed in newer releases there is no equivalent which is annoying.

I believe you can drop to the FPC vty and extract the information card by card 
similar to the link you shared, but it’s not exactly a workable solution, nor 
“officially supported” by Juniper.

The lack of this command is literally my biggest frustration with Juniper.

Sent from my iPhone

> On 11 May 2018, at 4:40 am, James Bensley  wrote:
> 
> Hi All,
> 
> Does anyone know of a command like the Cisco CEF "exact-route" command
> on Juniper?
> 
> I've seen this older thread: https://lists.gt.net/nsp/juniper/50645
> 
> Which links to a post on using JSIM but for DPC cards, but I'm
> interested in MPC cards:
> http://junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
> 
> Does anyone have any details on using JSIM on MPC cards on MX
> platforms? Or is there "another way" ?
> 
> I'm going to open a JTAC case as well as asking here however, in the
> past they have rejected requests to explain PFE commands to me or
> provide documentation for them. I have managed it a few times but only
> after a couple of weeks of non-stop screaming. So I'm not holding my
> breath for that option.
> 
> Kind regards,
> James.
> ___
> 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] Difference between MPC4E-3D-32XGE-RB and MPC4E-3D-32XGE-SFPP ?

[Nikolas Geyer]

Can’t remember the exact numbers but the non-RB card is targeted at MPLS core 
applications where it’s just high density label switching. Won’t take a full 
routing table and has reduced L3VPN numbers. Ask your AM/SE for the specifics.

Sent from my iPhone

> On 30 Apr 2018, at 10:34 am, Brijesh Patel  wrote:
> 
> Hello Members,
> 
> Any idea what is Difference between MPC4E-3D-32XGE-RB  and
> MPC4E-3D-32XGE-SFPP ?
> 
> Juniper PDf says :
> 
> MPC4E-3D-32XGE-SFPP 32x10GbE, full scale L2/L2.5 and *reduced scale L3
> features*
> and
> MPC4E-3D-32XGE-RB 32XGbE SFPP ports, full scale L2/L2.5,
> * L3 and L3VPN features*
> 
> now question is *what is reduced scale L3 featurs and L3vpn features ?*
> 
> *Many Thanks,*
> 
> *Brijesh Patel*
> ___
> 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] BGP EVPN, VXLAN and ECMP

[Nikolas Geyer]

A quick word of caution, if you use third party optics be very careful moving 
to Junos 17. We have found a bunch of ours unusable in Junos 17 and while our 
account team has been fantastic in trying to find out what’s changed in the 
code the official response has been “non Juniper optic, go away” and we 
literally run hundreds if not thousands of the QFX5ks which has put us in a 
difficult position.

That said, I was recently doing QFX5100 testing of VXLAN on various trains from 
Junos 14 through Junos 16 (17 bombed out due to above mentioned optic issue) 
and cant recall a problem with ECMP. I’ll pull the configs in the morning and 
send them through off list.

As someone else has mentioned are you sure you have per-packet load balancing 
policy exported in forwarding-options for all protocols?

Sent from my iPhone

> On 28 Mar 2018, at 3:45 pm, Nitzan Tzelniker  
> wrote:
> 
> Not sure I understand you but both can run 17.3R2 (just time of
> installation )
> 
> 
>> On Wed, Mar 28, 2018 at 10:16 PM Vincent Bernat  wrote:
>> 
>> ❦ 28 mars 2018 19:06 GMT, Nitzan Tzelniker  :
>> 
>>> The 5100 run 15.1X53-D63 and the 5110 17.3R2
>> 
>> Do you mean the other way around? No 15.1X53 for the 5100.
>> --
>> Use statement labels that mean something.
>>- The Elements of Programming Style (Kernighan & Plauger)
>> 
> ___
> 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] Experience with two-tier MC-LAG?

[Nikolas Geyer]

Yes, I have experience with multiple layers of back-to-back MC-LAG as you are 
describing with a similar product set, EX9200 (basically an MX) as core and 
QFX5k as aggregation and access.

It worked “ok” for the most part however, we were pushing numbers on this setup 
beyond what 99% of customers ever would which meant we got to experience the 
weird and wonderful failures, mostly related to memory leaking or buffer 
exhaustion (and when it went bang it REALLY went bang).

In 2018 I couldn’t in good faith advocate this back-to-back MC-LAG over 
multiple tiers setup to anyone. If you need L2 adjacency between your access 
switches then stitch it up using EVPN on your QFX’s. 

Nik.

Sent from my iPhone

> On 13 Mar 2018, at 12:21 pm, Karl Gerhard  wrote:
> 
> Hello
> 
> I would like to know whether anyone has deployed a two-tier MC-LAG:
> MC-LAG #1 between the aggregation switches
> MC-LAG #2 between the core routers
> This would allow for a network design with "active/active everything".
> 
> Our current setup is the following: Access (Juniper EX), Aggregation (Juniper 
> QFX), Core (Juniper MX).
> Our access switches use Redundant Trunk Groups to connect to two aggregation 
> switches.
> Each aggregation switch has an AE where the first cable of the AE goes the MX 
> #1 and the second cable of the AE goes to MX #2. To make this possible we 
> have an MC-LAG between the MXs.
> Pic: https://abload.de/img/single-mc-lag2io7w.jpg
> With this setup only one uplink of the access switch is utilized, the other 
> one is idle due to the nature of redundant trunk groups (active/passive).
> 
> If we had a second MC-LAG between the QFXs we could utilize both uplinks of 
> the access switch.
> Pic: https://abload.de/img/double-mc-lag4ppfd.jpg
> 
> Does anyone have experience with such a setup? Is this the highway to 
> debugging hell or is it a good idea that increases bandwidth available to the 
> access layer?
> 
> Regards
> Karl
> ___
> 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] L2ALD_MAC_MOVE_NOTIFICATION

[Nikolas Geyer]

You’ve probably got a layer 2 loop in your topology somewhere. OSPF probably 
went down due to the RE CPU utilization going through the roof.

Sent from my iPhone

> On 22 Feb 2018, at 11:23 pm, Brijesh Patel  wrote:
> 
> Hello Friends,
> 
> We have switch EX4300 which is connected to EX4500. .
> 
> Receving an erroe message : *2ald[1299]: L2ALD_MAC_MOVE_NOTIFICATION: MAC
> Moves detected in the system*
> 
> *and system went down and ospf flap . ANy idea ?*
> ___
> 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] Experience with Junos 15.1 on MX960?

[Nikolas Geyer]

We’re running 16.1R4 and it’s been stable for the most part, aside from a few 
annoying cosmetic problems.

Running it on MX480’s and 960’s, a variety of RE’s, a variety of 
MPC2/MPC3/MPC4/MPC7, usual protocols such as BGP, OSPF, MPLS, RSVP and a few 
Tbps of traffic. No MC-LAG unfortunately though.

Will probably schedule moving up to 17 some time early 2018.

Sent from my iPhone

On 12 Dec 2017, at 2:20 pm, Niall Donaghy 
> wrote:

Hello,

We are running 15.1F6-S6.4 on MX480 and MX960. No MC-LAG.
We rolled this out after Juniper PIIR and SURR, and our own internal 
type-certification process.
We needed F6 for EVPN and streaming telemetry features.
Several scary service-affecting bugs came out in the PBN notices, so we 
upgraded twice from the initial version and, hence, now on S6.4.

There are a number of threatening bugs in S6.4 still, but so far the experience 
has been good.

We are running RE-S-1800x4 so are immune to PR1312308.
Your REs are affected, therefore you should check the PR and TSB, which 
recommends 15.1F6-S10 or 15.1F7-S3.

TSB17205 
http://kb.juniper.net/InfoCenter/index?page=content=TSB17205=SUBSCRIPTION
 - PR1312308 - All protocols time out and FPCs are restarting after transient 
SSD freeze
PR1312308 
https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1312308 - All 
protocols time out and FPCs are restarting after transient SSD freeze

I strongly recommend you do your due diligence in researching bugs affecting 
your proposed hardware and software versions; there be dragons.

I can tell you for 15.1F6-S6.4 we got 10 PBNs in October this year, thankfully 
none in November, and for December, let's see what we get for Xmas..
Br,
Niall

Niall Donaghy
Senior Network Engineer
GÉANT
T: +44 (0)1223 371393
M: +44 (0) 7557770303
Skype: niall.donaghy-dante
PGP Key ID: 0x77680027
nic-hdl: NGD-RIPE

Networks • Services • People
Learn more at www.geant.org​
​GÉANT is the collective trading name of the GÉANT Association and GEANT 
Limited.

GÉANT Vereniging (Association) is registered in the Netherlands with the 
Chamber of Commerce in Amsterdam. Registration number: 40535155. Registered 
office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands.
GEANT Limited  is registered in England & Wales. Registration number: 2806796. 
Registered office: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK.



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Karl Gerhard
Sent: 12 December 2017 09:53
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Experience with Junos 15.1 on MX960?

Hello

we've had very bad experience with Junos 15.1 on our switches (EX4550, EX4300, 
EX4200).
Now we're getting new MX960s with 2xRE-S-X6-64G and unfortunately the minimum 
required Junos version for this RE is 15.1. Can anyone share their experience 
with Junos 15.1 on MX960? Is it as bad as it is on the switches? Would it be 
wiser to jump directly to 16.1/16.2/17.1/17.2/17.3?

We're especially interested in bugs/problems related to MC-LAG.

Regards
Karl
___
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