Hi Aaron, On Sun, Jun 26, 2016 at 2:08 PM, Aaron Dewell <[email protected]> wrote:
> > Hi Brian, > > Those all are good mitigation steps for an RG0 failover. There are some > caveats about graceful restart on the SRXs, but those should have been > fixed a while ago. Just to be sure, I’d get a recommendation on Junos > version from your local SE. > > Another option is to not use a cluster at all, and make them active/active > via routing protocols. Then, a control plane failure only kills one side. > But then failovers are stateless which has more impact. > > However, control plane failures are rare, so it’s chasing a very small > probability in the end. > > Aaron > > Wow, very good idea. I actually didn't consider using them independently. This might be a good way to achieve our goals. Like you mention, I will be trading one type of failure over another. But I like this idea since I'd have more control with standard routing protocols. Thanks. /bs > On Jun 26, 2016, at 12:40 PM, Brian Spade <[email protected]> wrote: > > Hi Aaron, > > On Sun, Jun 26, 2016 at 11:19 AM, Aaron Dewell <[email protected]> > wrote: > > > > You are correct - RG0 will always be active/passive. A full control > plane failover will always be painful. > > > > SRX active/active is more about the interfaces in use. You can arrange > for half of your traffic to prefer FW1 vs. FW2 and achieve active/active in > that way so you’ll take less of a hit when an interface fails (or a > neighbor device goes down). So that’s really what you are protecting > against, which seems like you’ve done that. > > > > Thanks for your feedback. It will be a lot of configuration, but was > thinking I could do the following to limit RG0 failure (or southbound Core > failure): > > - /31 transit VLAN per link (per VRF). So the total number of /31 > transit's needed will be 4 * # of VRFs (28 /31's in my case). > - Graceful restart configured on the SRX to limit RG0 failure. > - Core1 failure (or Core2 failure) should be limited with graceful > restart and all uplinks having an OSPF adjacencies. > > Anyways, just wondering your thoughts on this. I will probably just have > to lab it to see how it performs. > > If active/active is not a good way, I might have to add in two MX border > routers... That seems like a waste since I just need a default route via > BGP. > > Thanks. > /bs > > >> On Jun 26, 2016, at 12:15 PM, Brian Spade <[email protected]> wrote: > >> > >> Hi, > >> > >> I'm trying to figure out the best way to setup an SRX cluster as > >> active/active. I have attached a diagram of the topology, but it's a > >> full mesh of links. The ISP links are local interfaces and the > >> southbound interfaces to the core routers are reth's. Core1 is HSRP > >> primary for all VLANs. FW1 is primary for RG1 and FW2 is primary for > >> RG2. The IGP is OSPF but have many VRFs that are connected to the FW > >> with transit VLANs to bind the sub-interface to virtual router & zone. > >> > >> The issue I have is Core2 has no active OSPF neighbors in this setup. > >> Therefore, if Core1 fails, there will be a control outage as Core2 > >> establishes OSPF adjacencies. > >> > >> So I'm thinking it might be better to remove the reth's and use local > >> interfaces on the FW/CORE links. This way I can have a full mesh of > >> OSPF adjacencies and no control plane loss when Core1 fails. > >> > >> Does anyone have thoughts on this or recommend the best way to achieve > >> this active/active full mesh setup? If there's good reason to not use > >> active/active, I'd welcome the feedback. > >> > >> Thanks. > >> /bs > >> _______________________________________________ > >> juniper-nsp mailing list [email protected] > >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
