Sounds good. On the server side of things I would look into NIC teaming in independent mode/Active/standby mode or IP bonding where no switch awareness will be required. If you really want to get fancy, you could see about running OSPF locally on the servers as well as the pfSense.
Has there been any considerations on a fully L3 design?
Running L3 switches with OSPF back to your routers/firewalls would be good solution too. You could organize different regions of your farm by IP subnet. i.e. Cluster-1 uses 10.0.1.x/24, Cluster-2 uses 10.0.2.x/24, etc.
This way you’d have total L2 segregation. (I’m just not much of a L2 guy - I move everything L3 where possible)
This also depends on your server connectivity architecture. Are you working with large clusters of identical configuration systems or are we looking at more of a small enterprise setup with one’si-two’si type systems?
Only concern I have with running L3 on the switch is allowing inter-vlan routing. Even though you can use ACLs I would want my network security centralized on the firewall only.
Fair enough. My largest concern(s) would be about common points of failure and scale of the network(s) (broadcast domain size, and bandwidth availability (e.i. server X to route via the firewall to talk to server Y if it could just route via the local Top of Rack L3 switch - would save bandwidth on upstream links)).
Again, I don’t know how large your environment is, but just a few thoughts.
Unless we start talking about micro segmentation products such as NSX, ACI, or ISE, I would say very minimal since you can only filter IPs and ports. Even for very large environments, a centralized firewall for east/west traffic filtering is very common.
Totally makes sense.
I suppose I was thinking more along the lines of “if you can afford to route on your L3 switch, do it. Otherwise, utilize the firewall to handle the inter-vlan routing”