[j-nsp] SRX650 cluster - ethernet switching issue

[Pavel Lunin]

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.