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.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
