Showing results for 
Search instead for 
Did you mean: 

Active Passive Keeptogether

Occasional Contributor

Active Passive Keeptogether

Our Switches do not support Multicast so Active - Active is not an option

We want to deploy Active - Passive. It seems very straight forward from the manual (add both TM in cluster and mark one as passive)

My questions is for 'keeptogether' option:

Is it necessary to have the traffic IP group containing two IP addresses; the front end IP address for incoming traffic, and a back end IP address that resides on the server side network?  I'm not sure how to "Configure each back end server to route all traffic via the back end IP address you configured in the traffic IP group" - as per user guide. My testing seems to work without the back end IP address and just the single Traffic IP address



Re: Active Passive Keeptogether

Hi Yad,

The configuration you describe would be recommended for any services which you run with IP Transparency. When IP Transparency is enabled, your SteelApp will preserve the client source address when it connects to the server. The server will then use it's default gateway to respond. This default gateway must be the server side IP Address in your Traffic IP Group. The Keep-Together option ensures that the Front-End and Back-End VIPs are always raised on the same Traffic Manager.

By default IP Transparency is disabled and SteelApp connects to the server using it's own IP Address. This is probably why your testing works as expected. If you were to enable IP Transparency on the pool, then you would require a Back-End VIP and for your servers to use this VIP as their default gateway.

If you do not require IP Transparency then leave it disabled. If you do want to use it, then you might also want to check out the NAT / IP Forwarding options under System -> Networking. The servers will not be able to use SteelApp as a normal router unless you enable one or more of the options there.