[j-nsp] SRX Active/Active

[Brian Spade]

Hi Alexandre,

Thanks for all the details.  I will check with our Juniper team and see
what's the latest on A/A vs A/P.  For most of our sites, we plan to just
use A/P.  But for the largest sites with multi-10Gbps egress, we want to
try A/A.

On Sun, Jun 26, 2016 at 1:58 PM, Alexandre Guimaraes <
alexandre.guimaraes at ascenty.com> wrote:

> Here, we had lot of SRX equipments working as firewall services, you can
> use as routing platform, if u need too.
>
> We had started using A/A mode, but times of times we face a lot of
> problems when the packet arrives at fw01-wan passing through fw1-lan, and
> return using fw2-lan. The firewall drop those packets until the rebalance
> or switchover the cluster/reth
>

Interesting.  I wonder if this was a bug of some sort?  From my readings, I
thought the session synchronization happened on flow setup.  So I would
think the session sync between the SRXs is within milliseconds.  Maybe it's
not so instant?


> The firewall concept, if something enter at interface wan1, have to go out
> using wan1.
>
> There is a reth, I know, but this occurs and JTAC did not explain why
> until today.
>
> Other worst thing was when the packet enters at fw2-lan, cross the
> data/control plane cluster links and go out at fw1-wan.
>
> If you had 10gb ports at wan and lan, but the data/control links are 1g
> you will be shaped at 1g.
>

Yes, we would have 10Gbps per WAN, each link plugged into an SRX node.  We
would use two 10G fabric links.  With the EBGP default route, any packet
coming into the SRX from the LAN side should just go out that egress link
on that same SRX and not cross to the other SRX.  Of course if the EBGP
session is down, it would cross to egress from the other side.


>
> Our traffic are more than 3GBps, and all these traffic has ripped of.
>
> Working with A/P, we never more experienced that painful days, so the
> tshoots are very better this way.
>

I definitely can see the advantage of A/P for easier troubleshooting and
any strange bugs/limitations with A/A.  I'm thinking we might try it and
always have the option of making RG2 active on FW1 to remove the
active/active if it causes issues.

Thanks again for the details on real world experience.  It must sound like
I'm a glutton for punishment!

Thanks.
/bs


> Also, Juniper recommends A/P because of those problem that I'd mentioned.
> Ask to your Juniper representative.
>
> Sorry if mistyped something, typing using mobile.
>
> Att.
> AŁexandre
>
> > Em 26 de jun de 2016, às 15:33, Brian Spade <bitkraft at gmail.com>
> escreveu:
> >
> > Hi Alexandre,
> >
> > On Sun, Jun 26, 2016 at 11:19 AM, Alexandre Guimaraes
> > <alexandre.guimaraes at ascenty.com> wrote:
> >> Brian,
> >>
> >> Sorry about my cent, do not use active/active scenario.
> >>
> >> My recomendation is active/backup
> >>
> >> Att.
> >> AŁexandre
> >
> > Ya, I'm thinking of going to A/P, but due to bandwidth requirements,
> > we'd really like to use both ISP circuits at the same time.  I know we
> > won't be able to achieve a perfect balance.  Are there particular
> > reasons you recommend A/P over A/A?  I know some of the normal
> > arguments, like it's harder to troubleshoot and perhaps harder on the
> > firewalls.
> >
> > Thanks.
> > /bs
> >
> >>
> >>> Em 26 de jun de 2016, às 15:16, Brian Spade <bitkraft at gmail.com>
> escreveu:
> >>>
> >>> 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 juniper-nsp at puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>