Issues connecting to a VIP on the Brocade ADX from a Server

John Finnegan — Thu, 11 Jan 2018 00:24:17 +0000

If you are going to be creating a VIP on the Brocade that would need to be accessible from another Server behind the Brocade, there will be some things to consider. For example, if a VIP has Servers that it is loadbalancing too that are in the same segment as a Server that needs to connect to this VIP, it will not function without something called Source NAT.

Real Servers in the same Segment as Client Server

Without Source NAT

Lets use an example that you have a segment of 10.10.10.0/24 behind the Brocade. All of your Servers are in this segment and you need these Servers to connect to a VIP on the Brocade which loadbalances to these servers.

We will use the configuration below:

server real WEB1-10.10.10.5 10.10.10.5
port http
port http keepalive
port http url "HEAD/"
port ssl
port ssl keepalive

server real WEB2-10.10.10.6 10.10.10.6 
port http 
port http keepalive 
port http url "HEAD/" 
port ssl 
port ssl keepalive

server virtual VS-10.10.10.100 10.10.10.100
port http
port http reset-on-port-fail
port ssl
port ssl reset-on-port-fail
bind http WEB1-10.10.10.5 http WEB2-10.10.10.6 http
bind ssl WEB1-10.10.10.5 ssl WEB2-10.10.10.6 ssl

Lets say we need our App Server with IP 10.10.10.50 to connect to the 10.10.10.100 VIP. If you try to connect to this VIP from the App Server, the connection will never complete. The flow would look like the following TCP flow below.

Source IP ———- Destination IP
10.10.10.50 —> 10.10.10.100 (VIP)
10.10.10.50 —> 10.10.10.5 (Member)
10.10.10.5 —> 10.10.10.50 (Client)

Notice that the Server responds back to the Client and not the VIP. The Client Server did not connect to the 10.10.10.5 but rather the VIP at 10.10.10.100. The Server will drop this traffic since it never had made a connection to the 10.10.10.5 so the TCCP connection will never complete.

With Source NAT

To correct the issue from before, we would need to enable Source NAT. This will allow the Brocade to translate the Source IP for any connections to the VIP as the closest egress interface IP. For the sake of the example, the IP on the Brocade is 10.10.10.1 and it is the gateway for these Servers. To enable Source NAT, you will add the source-nat keyword to the real servers.

server real WEB1-10.10.10.5 10.10.10.5 
source-nat

server real WEB2-10.10.10.6 10.10.10.6 
source-nat

With the addition of source-nat keyword to the real servers, the flow will now look like the following TCP flow.

Source IP ———— Destination IP
10.10.10.50 —> 10.10.10.100 (VIP)
10.10.10.1 —> 10.10.10.5 (Member) <–Notice that the Source IP became the Brocade IP
10.10.10.5 —> 10.10.10.1 (Brocade IP -Source-Nat)
10.10.10.100 —> . 10.10.10.5 (Client)

Notice that the VIP is now what responded back to the Client Server. Now that the traffic is coming back from the VIP, the TCP connection is valid and will complete the handshake.

You can find more details about Brocade Real Servers and Remote Server configurations in my other Brocade article here.

Please feel free to reach out to me via my contacts page if you have any requests on more content or if you have any questions. If you want any help with an ADX in your Office, please feel free to contact me as well and I will work with you on configuring, upgrading or migrating the ADX.

The post Issues connecting to a VIP on the Brocade ADX from a Server appeared first on Think Netsec.

issues Archives - Think Netsec

Issues connecting to a VIP on the Brocade ADX from a Server

Real Servers in the same Segment as Client Server

Without Source NAT

With Source NAT