Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Confirmed as a bug. AE interfaces flap when master switch in VC reboots. Fixed in 11.4r6 (not released yet) or 12.1 Luca -Original Message- From: Luca Salvatore Sent: Thursday, 1 November 2012 12:51 PM To: Luca Salvatore; Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: RE: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Just an update on this after some more troubleshooting today. I'm only seeing the issue on my EX4500-VC switches. On my EX4200-VC switches, when the master reboots my OSPF neighbours stay up - i drop about 2 pings but that's it. The EX4500 switches have the exact same configuration. All switches are running 11.4r2.14 Probably log this with JTAC - looks to me like a bug. Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Luca Salvatore Sent: Thursday, 1 November 2012 7:32 AM To: Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches I see the 60 sec delay when crashing master. It seems the backup switch takes a while to notice the master is gone. But my main delay is the fact that my OSPF neighbours are lost when master crashes. @Doug, nonstop bridging is also configured. Luca On 01/11/2012, at 7:25 AM, Morgan McLean wrx...@gmail.commailto:wrx...@gmail.com wrote: Did you see the failover times I mentioned? Is that expected timing? 8 seconds using VC-LAG w/ LACP to a third switch when pulling masters power over 60 seconds when crashing master Morgan On Wed, Oct 31, 2012 at 1:20 PM, Doug Hanks dha...@juniper.netmailto:dha...@juniper.net wrote: Don't forget to configure NSB to help with LACP and other L2 stuffs. set ethernet-switching-options nonstop-bridging On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net mailto:sfou...@shortestpathfirst.netmailto:sfouant@shortestpathfirst .net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
On 11/02/2012 02:21 AM, Luca Salvatore wrote: Confirmed as a bug. AE interfaces flap when master switch in VC reboots. Fixed in 11.4r6 (not released yet) or 12.1 Luca Do you have the PR# by chance, or any info I can read up on at juniper.net? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
I was told PR/677087 but its currently marked as internal so not public On 02/11/2012, at 11:24 PM, Billy Sneed bi...@middlebury.edu wrote: On 11/02/2012 02:21 AM, Luca Salvatore wrote: Confirmed as a bug. AE interfaces flap when master switch in VC reboots. Fixed in 11.4r6 (not released yet) or 12.1 Luca Do you have the PR# by chance, or any info I can read up on at juniper.net? ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
31.10.2012 10:38, joel jaeggli wrote: On 10/30/12 5:49 PM, Pavel Lunin wrote: When it comes to ethernet switching, routing protocols means what? :) spanning-tree/trill/l2vpn/NVO and so on. Right, but if we get back to the particular case of DC/enterprise core, consisting of two EX boxes, this list gets a bit reduced. Moreover I'd say this application needs bridging, not lots of pseudo-wires, so l2vpn won't go as well. Well, not so many options in realty :) And. As of my understating of Trill (I know something about Brocade's implementation and almost zero of other vendors) the idea is also to hide routing and most of the control-plane from the user. Which is not that different from EX Virtual-Chassis approach (which is also IS-IS inside) from the point highlighted by RAS. So Trill is not less for people who can't figure out routing protocols. Yes, it's completely different in technical details how control-plane state is synchronized in NSR/NSB in contrast to what I know about Trill, let alone VPLS or, say, MAC-VPN. But while I also find the way of using protocols and standalone control-plane processing more elegant from theoretical point of view (especially when geographically distributed), in the few-box case everything rather depends on a particular verndor's implementation, number of bugs and user's ability to maintain. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
It's an EX4500-VC running Junos 11.4r2.14 You can't configure GRES + NSR - they are mutually exclusive right? Config is attached. Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 4:27 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Make sure the platform + software + configuration supports GRES + NSR + NSB and you're good to go. On 10/30/12 8:58 PM, Luca Salvatore l...@ninefold.com wrote: Yep I'm aware, but why are my OSPF neighbours going down when one switch reboots? Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 2:42 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx 2 0 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx 2 0 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Tried this with 12.2, it took eight seconds to switch over. I had eight seconds where my traffic was not reaching the next switch. Typically with the way my network is setup now, I lose maybe one ping when set to 1s interval, so I can assume 1 second. Seems like quite a bit more down time associated with a device failure, which happens usually when a dumb coworker bumps one of my two redundant top of rack switches I was running an AE with LACP over one link per chassis to another single switch, both set to fast. Had nonstop routing, nonstop bridging, no split detection. This is with no routing, just straight L2 forwarding. Eight seconds isn't bad, but still a pretty significant gap. I also noticed it took *63* seconds to recover from a catastrophic failure of the master node. I can induce a lights on but nobody home situation by killing process 43 under an EX3300 switch, which is devrt_kernel_thread. This is useful since it could replicate a total crash of a switch. Link states seem to remain up when this happens, so its a pretty good method. Is there maybe a timeout that I could tweak to get that number lower? I haven't had many devices crash before, but it happens. Thanks, Morgan On Tue, Oct 30, 2012 at 10:27 PM, Doug Hanks dha...@juniper.net wrote: Make sure the platform + software + configuration supports GRES + NSR + NSB and you're good to go. On 10/30/12 8:58 PM, Luca Salvatore l...@ninefold.com wrote: Yep I'm aware, but why are my OSPF neighbours going down when one switch reboots? Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 2:42 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On 10/30/12 5:49 PM, Pavel Lunin wrote: Richard A Steenbergen r...@e-gerbil.net wrote: IMHO multi-chassis boxes are for people who can't figure out routing protocols When it comes to ethernet switching, routing protocols means what? :) spanning-tree/trill/l2vpn/NVO and so on. And the same observation applies, stacked switches while popular might not be the best approach from an availability standpoint. ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
How many vmembers do you have configured on this set? I've seen serious issues with having trunk ports and a lot of vlans configured in terms of reconvergence time. Tim On 31-10-12 00:06, Morgan McLean wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks On Oct 31, 2012, at 2:07 AM, Luca Salvatore l...@ninefold.com wrote: It's an EX4500-VC running Junos 11.4r2.14 You can't configure GRES + NSR - they are mutually exclusive right? Config is attached. Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 4:27 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Make sure the platform + software + configuration supports GRES + NSR + NSB and you're good to go. On 10/30/12 8:58 PM, Luca Salvatore l...@ninefold.com wrote: Yep I'm aware, but why are my OSPF neighbours going down when one switch reboots? Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 2:42 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx 2 0 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx 2 0 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Sent from my iPad On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks On Oct 31, 2012, at 2:07 AM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: It's an EX4500-VC running Junos 11.4r2.14 You can't configure GRES + NSR - they are mutually exclusive right? Config is attached. Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 4:27 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.aumailto:bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Make sure the platform + software + configuration supports GRES + NSR + NSB and you're good to go. On 10/30/12 8:58 PM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yep I'm aware, but why are my OSPF neighbours going down when one switch reboots? Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 2:42 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.aumailto:bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.commailto:wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Don't forget to configure NSB to help with LACP and other L2 stuffs. set ethernet-switching-options nonstop-bridging On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.com wrote: Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Did you see the failover times I mentioned? Is that expected timing? 8 seconds using VC-LAG w/ LACP to a third switch when pulling masters power over 60 seconds when crashing master Morgan On Wed, Oct 31, 2012 at 1:20 PM, Doug Hanks dha...@juniper.net wrote: Don't forget to configure NSB to help with LACP and other L2 stuffs. set ethernet-switching-options nonstop-bridging On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.com wrote: Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
I see the 60 sec delay when crashing master. It seems the backup switch takes a while to notice the master is gone. But my main delay is the fact that my OSPF neighbours are lost when master crashes. @Doug, nonstop bridging is also configured. Luca On 01/11/2012, at 7:25 AM, Morgan McLean wrx...@gmail.commailto:wrx...@gmail.com wrote: Did you see the failover times I mentioned? Is that expected timing? 8 seconds using VC-LAG w/ LACP to a third switch when pulling masters power over 60 seconds when crashing master Morgan On Wed, Oct 31, 2012 at 1:20 PM, Doug Hanks dha...@juniper.netmailto:dha...@juniper.net wrote: Don't forget to configure NSB to help with LACP and other L2 stuffs. set ethernet-switching-options nonstop-bridging On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Just an update on this after some more troubleshooting today. I'm only seeing the issue on my EX4500-VC switches. On my EX4200-VC switches, when the master reboots my OSPF neighbours stay up - i drop about 2 pings but that's it. The EX4500 switches have the exact same configuration. All switches are running 11.4r2.14 Probably log this with JTAC - looks to me like a bug. Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Luca Salvatore Sent: Thursday, 1 November 2012 7:32 AM To: Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches I see the 60 sec delay when crashing master. It seems the backup switch takes a while to notice the master is gone. But my main delay is the fact that my OSPF neighbours are lost when master crashes. @Doug, nonstop bridging is also configured. Luca On 01/11/2012, at 7:25 AM, Morgan McLean wrx...@gmail.commailto:wrx...@gmail.com wrote: Did you see the failover times I mentioned? Is that expected timing? 8 seconds using VC-LAG w/ LACP to a third switch when pulling masters power over 60 seconds when crashing master Morgan On Wed, Oct 31, 2012 at 1:20 PM, Doug Hanks dha...@juniper.netmailto:dha...@juniper.net wrote: Don't forget to configure NSB to help with LACP and other L2 stuffs. set ethernet-switching-options nonstop-bridging On 10/31/12 1:05 PM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yes so GRES and NSR is configured am correctly then? The AE is a VC-lag with one member on each switch. Luca On 01/11/2012, at 3:56 AM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net wrote: On Oct 31, 2012, at 10:01 AM, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com wrote: Yep my mistake. However I do have 'set chassis redundancy graceful-switchover' configured as well as 'set protocols nonestop-routing' On 31/10/2012, at 11:24 PM, Stefan Fouant sfou...@shortestpathfirst.netmailto:sfou...@shortestpathfirst.net mailto:sfou...@shortestpathfirst.netmailto:sfouant@shortestpathfirst .net wrote: I think you are confusing GRES w/ GR. NSR and GRES are NOT mutually exclusive and in fact NSR requires it to function. 'set chassis redundancy graceful-switchover' is GRES, not GR. What I actually see when the master switch robots is that the AE interfaces between my devices flaps. I think this causes my OSPF neighbours to go down. I see this in the logs: rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from Full to Down due to KillNbr (event reason: interface went down Which device is the ae interface tied to? Is it a VC-LAG with members tied to multiple physical devices, or is it comprised of only links belonging to a single device? Stefan Fouant JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI Systems Engineer, Juniper Networks ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
Should be hitless. You need to configure GRES + NSR + no-split-detection. On 10/30/12 4:06 PM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ #specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Have no split detection, I'll try for the GRES and NSR. Thanks, Morgan On Tue, Oct 30, 2012 at 4:24 PM, Doug Hanks dha...@juniper.net wrote: Should be hitless. You need to configure GRES + NSR + no-split-detection. On 10/30/12 4:06 PM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ #specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Also will need the 'set commit sync' command under the 'edit system' This is needed for nonstop-bridging Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ben Dale Sent: Wednesday, 31 October 2012 10:31 AM To: Morgan McLean Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Richard A Steenbergen r...@e-gerbil.net wrote: IMHO multi-chassis boxes are for people who can't figure out routing protocols When it comes to ethernet switching, routing protocols means what? :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Seriously, routing protocol ain't my problem here. Sent from my iPhone On Oct 30, 2012, at 5:49 PM, Pavel Lunin plu...@senetsy.ru wrote: Richard A Steenbergen r...@e-gerbil.net wrote: IMHO multi-chassis boxes are for people who can't figure out routing protocols When it comes to ethernet switching, routing protocols means what? :) ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx20 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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 ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
Yep I'm aware, but why are my OSPF neighbours going down when one switch reboots? Luca -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Wednesday, 31 October 2012 2:42 PM To: Luca Salvatore; Morgan McLean; EXT - bd...@comlinx.com.au Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches GR is mutually exclusive with NSR. You want NSR. On 10/30/12 5:44 PM, Luca Salvatore l...@ninefold.com wrote: I'm just playing around with this now since I have a few new EX switches not in production just yet Have a pretty simple setup with two EX4500 in VC connected to another two EX4500 in VC mode. I'm running OSPF between them. I rebooted the master member while running a ping an it took around 40 seconds to come back up. I noticed that my OSPF adjacency went down and the delay was waiting for the OSPF neighbours to come back up. I have: nonstop-routing configured under routing options graceful-switchover configured under chassis redundancy nonstop-bridging configured under ethernet-switching-options Would graceful-restart be a better config than non-stop routing? Luca -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Morgan McLean Sent: Wednesday, 31 October 2012 11:00 AM To: Ben Dale Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches Neither of these two options show up as a configurable flag: set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging I'm running 11.4R2.14 on the ex3300-48t switches. Granted, right now the VC is broken so maybe it doesn't allow me to configure it? I can head to the datacenter and upgrade these two devices to recommended release and report back tomorrow as well. Morgan On Tue, Oct 30, 2012 at 4:30 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Morgan, On 31/10/2012, at 9:06 AM, Morgan McLean wrx...@gmail.com wrote: Can anybody give me an idea regarding typical failover times if the master in a two switch pair were to die? The quickest I've seen in my testing with EX3300's is 45 seconds, just for L2 forwarding to continue working, no routing. All the ports drop link as well on the secondary switch while things switch over. I can have my laptop connected to the secondary switch, passing traffic up an uplink on the secondary, and if the master dies it creates a 45 second interruption. Normal? Yes, but add the following to your configuration: set virtual-chassis no-split-detection(you may already have this) set routing-options nonstop-routing set ethernet-switching-options nonstop-bridging and try again. In your testing, put a 3rd switch in place with LACP and one leg to each member. My testing (45/42xx) has shown L2 should be pretty much hitless under most circumstances (except if your STP topology needs to re-converge), and L3 should around the 1-4 seconds mark (for violent failures of master RE). The worst case scenario though is re-merging a split VC, which can take the best part of 45 seconds, so avoid split-brain scenarios whenever possible with redundant VCP/VCPe or schedule their repair during planned outage windows. Cheers, Ben Morgan On Sun, Oct 28, 2012 at 2:24 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 0 00/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2 0 00/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? 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 ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Any idea where i could test out the EX8200 VC in a lab somewhere? Think our vendor insight would have some I could fly out and mess with? Unfortunately the only two we have are for production, and they're a bit expensive to buy as lab toys. Morgan On Sun, Oct 28, 2012 at 10:47 AM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Robert, It was released by juniper one or two weeks ago I think. Take a look: https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/ MX2010 MX2020 https://www.juniper.net/us/en/products-services/routing/mx-series/mx2000/#specifications But I really don't know if it will support virtual chassis without JCS. Att, Giuliano On Sun, Oct 28, 2012 at 3:47 PM, Robert Hass robh...@gmail.com wrote: On Fri, Oct 26, 2012 at 11:44 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L Hi What is new MX-L - can you write a little mort ? MX80 successor ? Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On 27/10/2012, at 12:15 PM, Craig Askings caski...@ionetworks.com.au wrote: On Saturday, October 27, 2012, Richard A Steenbergen wrote: I'm still sad that I couldn't get Juniper to bless the XRE200 as an external route reflector, since it's an infinitely more useful form factor than a JCS, but alas lack of common sense knows no bounds. :) I'm glad I'm not the only one who looked at XRE200 and thought it would make a great RR. Like you I didn't have much luck in getting juniper to agree with that. Ditto. I'll be sticking to the O-Series for now ; ) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Morgan, We have some cases running EX8200 as a Virtual Chassis, but you will need the XRE200 External Routing Engines: http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/ Don't forget that you will need the 8 ports (10 gig) for chassis inter x connections - EX8200-8XS It is a very good topology and we have very good performance with not bad uptime (196 days) right now. Without STP problems. We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis for Client Access. 2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet Interfaces to both EX8200 (10 gig modules) I really recommend it for you. Att, Giuliano On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean wrx...@gmail.com wrote: Hey guys, So I run SRX as my core firewalls, with EX8200's doing core switching and EX3300's doing access switching. I have two SRX's, two 8208's, and two 3300's at every cabinet. Spanning tree is a pain in my ass, especially since I have other environments setup the same way, just with smaller switches. Right now the SRX reth interfaces only come down as legs, not full mesh. The top of rack switches have only one link active at a time, legs. The interconnects between the core switches of different environments are legs, not full mesh due to spanning tree constraints (it closes the lag center trunk between the core switches). It would be a lot easier if I could just VC the core and VC the access switch pairs so that multi-chassis lags can be run everywhere and I can for the most part cut spanning tree out of the picture and have greater link fault tolerance. How reliable is VC? I've really done my best to avoid it up to this point as I try to keep redundant systems as separate as possible so one doesn't take down the other. Then again, when it comes down to it my edge and core firewalls are all SRX clusters, so... :) lol I'm not really sure what kind of information I'm looking for here. I would just run 20G lags eveywhere instead of having 10G forward/blocking STP pairs. I don't really know how things work when a device fails, how fast convergence is, split brain scenarios etc. Any major lessons learned with this technology? I am aware that with the 8200's I would need the external SRE. Thanks, Morgan ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
I know I need the XRE200, but my question would be why? Why is this the only EX product requiring external RE's? And also, it looks like you need two local RE's to be able to connect to two external RE's? Seems unnecessarily expensive. Also, are the 8XS required for inter connects? Right now I only have two 8208's each with an 8XS and the 40 port 10g card, but I plan on adding another 40 port and in the future two additional EX8208's at another site with two 40 port 10gig cards each, no more 8XS cards. I would like to spread the interconnections across two cards to protect against a module failure. Morgan On Fri, Oct 26, 2012 at 2:19 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Morgan, We have some cases running EX8200 as a Virtual Chassis, but you will need the XRE200 External Routing Engines: http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/ Don't forget that you will need the 8 ports (10 gig) for chassis inter x connections - EX8200-8XS It is a very good topology and we have very good performance with not bad uptime (196 days) right now. Without STP problems. We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis for Client Access. 2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet Interfaces to both EX8200 (10 gig modules) I really recommend it for you. Att, Giuliano On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean wrx...@gmail.com wrote: Hey guys, So I run SRX as my core firewalls, with EX8200's doing core switching and EX3300's doing access switching. I have two SRX's, two 8208's, and two 3300's at every cabinet. Spanning tree is a pain in my ass, especially since I have other environments setup the same way, just with smaller switches. Right now the SRX reth interfaces only come down as legs, not full mesh. The top of rack switches have only one link active at a time, legs. The interconnects between the core switches of different environments are legs, not full mesh due to spanning tree constraints (it closes the lag center trunk between the core switches). It would be a lot easier if I could just VC the core and VC the access switch pairs so that multi-chassis lags can be run everywhere and I can for the most part cut spanning tree out of the picture and have greater link fault tolerance. How reliable is VC? I've really done my best to avoid it up to this point as I try to keep redundant systems as separate as possible so one doesn't take down the other. Then again, when it comes down to it my edge and core firewalls are all SRX clusters, so... :) lol I'm not really sure what kind of information I'm looking for here. I would just run 20G lags eveywhere instead of having 10G forward/blocking STP pairs. I don't really know how things work when a device fails, how fast convergence is, split brain scenarios etc. Any major lessons learned with this technology? I am aware that with the 8200's I would need the external SRE. Thanks, Morgan ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
On Fri, Oct 26, 2012 at 2:46 PM, Morgan McLean wrx...@gmail.com wrote: fault tolerance. How reliable is VC? I've really done my best to avoid it I can't speak to EX3300 specifically, but on EX4200 the VC works very well. I have many stacks running for many years, and have had no stacking-related problems since before Junos 10.4R. We configure no-split-detection on VCs of two units (like TOR) based on our guess that it is much more likely one unit will fail completely, than the likelihood of split-brain happening where both switches are still working. If it did happen we would have a fast time-to-repair, and we think good MTTR is too often overlooked. -- Jeff S Wheeler j...@inconcepts.biz +1 502-523-6989 Mobile Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Morgan, I really dont know why JUNIPER did this kind of crazy environment with EX8200. Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L I think you do not need the external routing engines for virtual chassis. About the line card ... the information I have is that you need 8 port line card to interconnect chassis. Take a look: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/line-cards-ex8200.html You cannot use 40 port 10 gig to interconnect.. maybe in future with a new JUNOS code you could use it. I will try to check it. Att, Giuliano On Fri, Oct 26, 2012 at 7:36 PM, Morgan McLean wrx...@gmail.com wrote: I know I need the XRE200, but my question would be why? Why is this the only EX product requiring external RE's? And also, it looks like you need two local RE's to be able to connect to two external RE's? Seems unnecessarily expensive. Also, are the 8XS required for inter connects? Right now I only have two 8208's each with an 8XS and the 40 port 10g card, but I plan on adding another 40 port and in the future two additional EX8208's at another site with two 40 port 10gig cards each, no more 8XS cards. I would like to spread the interconnections across two cards to protect against a module failure. Morgan On Fri, Oct 26, 2012 at 2:19 PM, Giuliano Medalha giuli...@wztech.com.brwrote: Morgan, We have some cases running EX8200 as a Virtual Chassis, but you will need the XRE200 External Routing Engines: http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/ Don't forget that you will need the 8 ports (10 gig) for chassis inter x connections - EX8200-8XS It is a very good topology and we have very good performance with not bad uptime (196 days) right now. Without STP problems. We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis for Client Access. 2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet Interfaces to both EX8200 (10 gig modules) I really recommend it for you. Att, Giuliano On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean wrx...@gmail.com wrote: Hey guys, So I run SRX as my core firewalls, with EX8200's doing core switching and EX3300's doing access switching. I have two SRX's, two 8208's, and two 3300's at every cabinet. Spanning tree is a pain in my ass, especially since I have other environments setup the same way, just with smaller switches. Right now the SRX reth interfaces only come down as legs, not full mesh. The top of rack switches have only one link active at a time, legs. The interconnects between the core switches of different environments are legs, not full mesh due to spanning tree constraints (it closes the lag center trunk between the core switches). It would be a lot easier if I could just VC the core and VC the access switch pairs so that multi-chassis lags can be run everywhere and I can for the most part cut spanning tree out of the picture and have greater link fault tolerance. How reliable is VC? I've really done my best to avoid it up to this point as I try to keep redundant systems as separate as possible so one doesn't take down the other. Then again, when it comes down to it my edge and core firewalls are all SRX clusters, so... :) lol I'm not really sure what kind of information I'm looking for here. I would just run 20G lags eveywhere instead of having 10G forward/blocking STP pairs. I don't really know how things work when a device fails, how fast convergence is, split brain scenarios etc. Any major lessons learned with this technology? I am aware that with the 8200's I would need the external SRE. Thanks, Morgan ___ 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] How reliable is EX multichassis? 3300 and 8200 switches
On Fri, Oct 26, 2012 at 07:44:27PM -0200, Giuliano Medalha wrote: Morgan, I really dont know why JUNIPER did this kind of crazy environment with EX8200. Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L I think you do not need the external routing engines for virtual chassis. An external routing engine is actually a really good idea, you should ask them to do it more, not less. There is absolutely no reason the RE needs to be in the chassis, all it does it drive up the cost and slow down upgrade cycles. When was the last time you saw a several year old off the shelf PC that cost $32k? In the EX's case, the EX8200 is vastly underprovisioned on the stock RE (one of the worst design decisions of all times), so it REALLY benefits from an external RE. I never actually tried it in production though, so no comments about the reliability (IMHO multi-chassis boxes are for people who can't figure out routing protocols, I'd personally rather have two independant control-planes instead). I'm still sad that I couldn't get Juniper to bless the XRE200 as an external route reflector, since it's an infinitely more useful form factor than a JCS, but alas lack of common sense knows no bounds. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
Obviously the external RE has its benefits, but I still need two RE per chassis to make use of it? Morgan Sent from my iPhone On Oct 26, 2012, at 3:03 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Fri, Oct 26, 2012 at 07:44:27PM -0200, Giuliano Medalha wrote: Morgan, I really dont know why JUNIPER did this kind of crazy environment with EX8200. Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L I think you do not need the external routing engines for virtual chassis. An external routing engine is actually a really good idea, you should ask them to do it more, not less. There is absolutely no reason the RE needs to be in the chassis, all it does it drive up the cost and slow down upgrade cycles. When was the last time you saw a several year old off the shelf PC that cost $32k? In the EX's case, the EX8200 is vastly underprovisioned on the stock RE (one of the worst design decisions of all times), so it REALLY benefits from an external RE. I never actually tried it in production though, so no comments about the reliability (IMHO multi-chassis boxes are for people who can't figure out routing protocols, I'd personally rather have two independant control-planes instead). I'm still sad that I couldn't get Juniper to bless the XRE200 as an external route reflector, since it's an infinitely more useful form factor than a JCS, but alas lack of common sense knows no bounds. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches
On Saturday, October 27, 2012, Richard A Steenbergen wrote: I'm still sad that I couldn't get Juniper to bless the XRE200 as an external route reflector, since it's an infinitely more useful form factor than a JCS, but alas lack of common sense knows no bounds. :) I'm glad I'm not the only one who looked at XRE200 and thought it would make a great RR. Like you I didn't have much luck in getting juniper to agree with that. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
