Firewall and Server Load Balancer Design

I’ve been stuck with a picture in my head relating to Firewall and Server Load Balancer designs. This blog represents my best effort to transmit this picture to your head, to get it out of my brain. I’ve also now seen something like this in print. While that dilutes the novelty some, it also ratifies the concept to a degree. 

Here’s a diagram showing the traditional firewall pair or server load balancer (SLB) pair design, for oh, say, the last 10-15 years:

I call this the square topology. Usually one firewall or SLB is active, the other passive. Or both are pseudo-active-active, i.e. active for some traffic and not the rest. The main drawback is that the stateful firewall or SLB polarizes traffic, i.e. uses only one of the two switches, the one adjacent to the active firewall or SLB. Worse, it tends to do that for the switch pair on either side of it. Then you’re stuck with the cost of redundant switches that you don’t even use. 

This looks like:

Well, Cisco VSS, vPC, or StackWise (3750/3850) technology provides us with an alternative. If you don’t have Cisco gear, any vendor’s MLAG (multi-chassis link aggregation) will do.

Here’s that alternative:

That is, each firewall or SLB is set up with two links in a port-channel to the VSS, vPC, or StackWise switch pair. This is the “bow-tie topology”. The firewall or SLB thinks it is in a port-channel to a single device. The vendor may or may not officially support this, however it seems unlikely anything could go wrong, unless the vendor got creative with protocols somehow. 

The advantages:

1. Port-channel load balancing should cause both switches to be used in both directions.
2. Single switch failure (probably) does not trigger firewall or SLB failover. This may or may not be configurable, depending on device vendor.

Traffic flow now looks like:

Dual-active clustering would of course use both switches and both firewalls or SLBs. One virtue of active-passive is you’ll never unknowingly have joint throughput exceeding what a single device can handle.

Life Log

I’m back from a week of driving and walking (Las Vegas, Grand Canyon, Bryce Canyon). If you’re wondering why the blogging paused, well, I was clearing my desk then aggressively vacationing, and now catching up. 

I’ve got lots more blog ideas and hope to put some of them in front of you soon, along with more from the CCIE R&S prep series. In particular, I’ve got some Pete’s pent up pithy comments on OpenFlow, SDN, and odd notions of QoS I’ve been mulling over, and they’re about ripe for transmission.

Disclosure

The vendors for Network Field Day 5 (#NFD5) paid for my travel expenses and perhaps small items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention!

Stay tuned!

Twitter: @pjwelcher