Very well buggued. I had lots of issues using VC and also bug on MCLAG. If I need to do a VC with any vendor, I will need 4 equipments 2*2VC and redundancy on the server / router side. I had in production around 20 QFX5100 on a single customer and most of the bug we had : VCHASSIS with SNMP / Upgrade / RPD / split. I also had in production around 50 MX's on one single network really stable with no issue except on issu and when I tried the Vchassis stuff :) I'm a a Juniper guy / shop, but I also know the limitation and try to not play with Fire
But this ML is not the right place to troll on this topic ^^
2015-10-17 20:28 GMT+02:00 Michael Loftis mloftis@wgops.com:
On Fri, Oct 16, 2015 at 10:31 PM, Raphael Maunier < raphael.maunier@gmail.com> wrote:
Envoyé de mon iPhone
Le 17 oct. 2015 à 01:50, Aaron Finney aaron.finney@openx.com a écrit :
Ah, latest in 13.x train...13.2X51-D38.
Question - what are your polling times like for your 96s? Do you have any stacks with > 2 members?
I really like Juniper but I don't trust any vendor on stacking technology. There is always something wrong during upgrade / services issue. So I don't have any stack in production and I will not ! 96s are pretty fast. I'm only doing layer3 and mpls raw interfaces on my qfx, no layer 2 ( layer2 is bad :) )
On a previous release I had a nice bug. I was able to snmp read if-out and if-in traffic and I was able to see the traffic locally with monitor interfaces but snmp-get was polling a value of zero. I had to upgrade. I had to upgrade to the latest 14.x train because of mpls bugs and feature I needed that was only available in 14.x at that time ( mostly mpls ). So I don't have any experience on 13.x train since the bug I had :)
Just a sort of side note..."stacking" in JunOS is NOT an afterthought, unlike everyone else. It's merely a different physical layer for what they're already doing in the big MX and EX chassis routers, and that overall topology goes back to the previous generation M series. Very well proven, very robust. Rarely do you see bugs that are related to stacking itself in JunOS (I actually cannot recall any) and that's because of what it is. When strange things happen they behave as configured. It's not remotely like a lot of others "stacking" implementations. It really is 1st class citizen with a control plane designed for this type of work from the get go.
For JunOS a "stacked" configurations really are just more ports being handled the same way it already handles the hardware. There's never been any sort of monolithic (which isn't the right term but I can't think of a better one) JunOS where the control plane CPU is tightly coupled to the forwarding plane. It's always been loosely coupled with an independent forwarding and control plane.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium