Its still a bad idea, though, since it introduces a lot of additional surface area for software bugs and indeed a larger device for human error to cause fail.
Adam's rule #1 of networking is : don't stack!
Adam.
Sent with AquaMail for Android
http://www.aqua-mail.com
On 17 October 2015 19:28:32 Michael Loftis <mloftis@wgops.com> wrote:
_______________________________________________On Fri, Oct 16, 2015 at 10:31 PM, Raphael Maunier <raphael.maunier@gmail.com> wrote:
Envoyé de mon iPhoneAh, 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