How to load ballance transparent devices (SMTP transparent proxy)

Just an idea did not think about it too much - what about running each bridge device in separate VLAN and make virtual IPs behind the bridging devices? Someting like this:

 

 

VIP MX has pool of nodes AC1 AC2 AC3 and AC4, these are each in different VLAN each containing one bridging device, which forces LTM to push traffic through given bridging device. AC1-4 are VIPs each having pool of internal SMTP servers.

 

 

To solve:

 

- is it possible to use one F5 or is it needed to have external and internal one? Easiest way is to have two of them with inbound VIP on external and AC VIPs on internal. The same on the way out.

 

- monitoring of bridging devices.

First stab, it should be just like load balancing anything else, except turn IP address translation off. The BIG-IP will translate the MAC address (and vlan) but otherwise leave the L3-L4 headers relatively untouched. If you are further LBing some servers behind it you can use a nexthop pool to LB the transparent proxies while the IP address translation gets you to the desired end server.

 

 

Except you may want to touch some L4 information when LB transparent devices. See RFC 2101 for some hints. Your transparent proxies are masquerading the same client address to the back end servers, the servers could get unhappy when they see timestamps or sequence numbers go backwards because the client went through two different transparent proxies. Very hard to debug, the connections just stall and many OSses don't even have the right counters to debug this. You just turn on timestamp re-writes if using fastL4 on the BIG-IP and you should be okay. (full proxy won't have this issue, and sequence numbers are always re-written)

 

 

I'm assuming you don't need any session persistence (e.g. email from the same client goes through same smtp transparent proxy). If so then you'll need some sort of persistence

 

 

Paul

whups, I see you said "transparent bridge mode". I now think you mean literally then it's not touching the packets, not a transparent proxy. I guess the "bridge" part would be a clue...

 

 

sorry about that, i need to stop posting at midnight.

 

 

I'm generally not fond of completely transparent inspections systems, it's possible to fool them by making headers cross packet boundaries or by finding other holes in the stream reconstruction process used by the transparent device, allowing bad stuff to slip through.

 

 

That critique aside, the previously reply is probably the right way to go (seperate vlans). This avoids bridge loops.

 

 

must.go.to.bed.now.

 

 

Paul