SRX

Greetings.

My company currently uses an SRX550 in packet mode as an internet edge router (the main reason for this was cost versus performance - the SRX worked out the cheapest option). We run a full BGP mesh with two ISP's - pulling the full table from both ISP's and advertising our ASN and IP subnets to both of them.

There's nothing fancy with the routing - I used to AS prepend to one of the ISP's, but I don't even bother with that now.

The crux of the matter is that now the company wants to implement a second SRX550 as a redundancy device.

I'm aware you can't run an SRX cluster in packet mode - my question is if I put the existing device back into flow mode and just add a global any/any security policy, can I still run the BGP mesh like I am now?

If I can, are there any implications of then adding the second SRX550 into a cluster (apart from the obvious reboot and port re-assignment requirements)?

Thanks for any input.

Hi Darren,

Yes - you can do exactly that.

Even easier on the security policy front:

set security policies default-policy permit-all

I've had mixed success with the SRXs (both clustered and stand-alone) as edge devices with large routing tables, though the 550 is definitely the most powerful of the branch units.

Just keep an eye on memory and convergence times when you test this and if the cluster becomes cumbersome, you could always just keep the two units seperate and just run iBGP and VRRP (internally) between them. 

hi Ben.

Thanks for your reply.

The current box seems to manage the BGP tables as setup, but it's running at about 60% memory utilisation for data, so I'm trying to avoid pushing it any further with another set  of BGP information (iBGP).

I had considered doing iBGP and running VRRP, but I've only got a /30 on my outside links, and I don't want to try and negotiate more address space on the link subnets from the uplinks so I can run VRRP across a /29 - I could probably (not sure if Juniper supports this, so I'd be shooting in the dark) run the interfaces on RCFC1918 addresses and just use the /30 address as the cluster address (with accept-data set) - but if I can avoid this by running it in cluster mode without adversly affecting performance I'd rather do that.

One query - the security policy you specified in your answer - that allows everything, both ways (incoming and outgoing) through all reth groups, yes?

I'll likely just start by sticking the existing device back to flow mode, making sure I don't break anything, then work on the clustering. Safer that way, I think.

Thanks again for your help.

Hi Darren,

60% is pretty good for data plane - having an iBGP peering will not increase this much if at all - you'll still only be loading the best route into FIB - whether that be the one from the EBGP peer, or iBGP neighbour, but by all means give the clustering a shot.

With regards to VRRP sorry I should have been more clear - I was referring to VRRP on the "inside", not on the carrier side - the next-hop your clients would use to get to the primary SRX.

In the situation you describe, I'd have a reth interface on the inside (with a member interface from each chassis node), but on the carrier side, I'd have a dedicated interface to each SP (eg: ge-0/0/0 and ge-9/0/0)

The default-policy statement is as close to packet-mode as you can go, so yes - it's just like ANY/ANY on all *zones*.  

You will still have to place your interfaces (reths or whatever) into a zone (can all be in the same zone if you wish) or else they will not forward traffic.

You can also override this behaviour via policy if you wish - policies are consulted first, and if there are none, or no matches the default-action is checked next.

Hi,

Then shouldn't it be better to use selective packet mode via a firewall filter for all traffic and avoid any session table and 

possible side effects of flow mode?

Hi gy,

In terms of memory utilisation, there is no difference.  The jflowd process still consumes the same amount of memory as if if was running configured even when the box is in packet mode (or doing FBF as you suggest).

When you cluster the SRX, a lot of the "issues" such as async flow just go away, because the box is aware of what both sides of the connection are doing: as long as both your upstreams are in the same security zone.

As well as this, you can still perform services such as NAT.

Hi Ben, 

   I think all ALGs should be disabled to be on the safe side . I think Darren doesn't want his SIP traffic to be inspected by SIP ALG on a box which was running in packet mode before. Flow mode itself may not bring extra memory footprint but one should be careful to move from packet mode to flow mode. My opinion is still to use selective packet mode to avoid any unexpected result:)