[j-nsp] SRX650 cluster - ethernet switching issue

[Paulhamus, Jon]

Thanks for the reply.

The case what not that I was connecting end points directly to the SRX, it's that I wanted 2 trunk links between each SRX node and the switch stack (there is only 1 switch stack),  each of the 2 links supporting different VLAN's.  So - 2 links from the primary node to the  switch stack, and 2 links from the secondary node to the switch stack as well...  this does not work with STP enabled as 3 of the 4 links get blocked by STP.   I needed a setup like this as I'm pushing over 1Gb through each switch link. 





 

-----Original Message-----
From: Pavel Lunin [mailto:plunin at senetsy.ru] 
Sent: Monday, January 16, 2012 9:32 AM
To: Paulhamus, Jon
Cc: Ben Dale; juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] SRX650 cluster - ethernet switching issue



Sorry, missed this reply because of the new year holidays.

>> BTW, never could understand people running L2 on srx650 coupled with a normal switch. Especially in srx-cluster + ex-vc. What for?
> Why not?  If you have more devices that need access to specific vlan zones on the SRX, and you're low on physical interfaces, why not use a switch.  This can be extremely handy when bringing trunks into a VMWare server(s).
>

When you build a FW cluster, you anyway must have a pair of supporting switches in almost all sorts of design. Either each SRX connected to its own switch (I prefer this) or full mesh (people like this but there is no much sense, imho). So in terms of the number of physical ports, it seems like this is not the SRX's job (in most cases). Although in case of port deficit, this can be a kind of workaround, I agree.

> I'm not sure what you're saying about especially in a cluster either - clustering of the firewalls is soley for redundancy in my situation.

If you physically connect something to SRX in cluster mode, not to the supporting switches, it becomes complicated to teach the device to switch traffic to a different SRX node in case of a failure. Say, you have SRX1 and SRX2 in cluster. SRX1 connected to SW1 and SRX2 connected to SW2. SRX1 is primary for RG0 and RG1. Say, SW1 and SW2 form a VC. You have some devices connected to the VC (most probably using LAGs) and some devices connected to the SRXes itself (LAG is not supported here, AFAIR). Let's say SW1 fails and SRX1-SW1 link does so as well. RG1 switches to the backup node SRX2. But how the directly connected device will know it should forward traffic to the second node? In case it still send it to SRX1, this will lead to h-shape forwarding through the swfab link (not good). xSTP can help, but it moves the solution further from best (I don't even want to think of what can happen with STP in case of SRX's RG0 switchover). You anyway must run xSTP though, since you now have two switch nodes instead of one.

Add here operational expenses of managing and troubleshooting switching stuff of SRXs instead of just on VC and lack of some switching features. 
I think, it's cheaper overall to just add port-capacity to the switch cluster. So, while it does work in principle, as a design for a new setup, I'd say, it's a bit clumsy.