traffic flow from new vlan

Hi Dwight,

 

 

Thanks for the complete problem statement. I'd guess that the non-local servers don't have a route back to LTM's self IP or virtual server IP which points to the same VLAN the packet went out of LTM from. Can you create a custom SNAT pool for the virtual server and ensure there is a route on the servers or the intermediate router(s) to get the reply back to LTM over the same VLAN?

 

 

Aaron

Hi Aaron,

 

 

Thank you for your response. I did more reading trying to make sure I understand the SNAT concept correctly. While I understand the various concepts and examples I have seen for SNATs I am having trouble translating it to what I have on my F5. So, I'll add some the specific IP address examples (some numbers changed to protect the innocent).

 

 

The F5's external VLAN is on the 10.38.92.0 subnet. Internal VLAN is 10.38.141.0. The subnet with the VM's that we are trying to load balance are on the 10.38.158.0 subnet with netmask of 255.255.254.0.

 

 

I am attempting to load balance two VM machines on the 10.38.158.0 subnet (10.38.159.xx and 10.38.159.xx). I created a pool with the above two ips in them using port 8080. We setup a virtual server with an ip address of 10.32.92.109 that points to the pool with the above two servers. Client requests to these two will also come from the 10.38.158.0 subnet. For example when I do the wget command I am coming from 10.38.159.12 to the virtual server of 10.38.92.109 and attempting to reach one of the two servers in the pool.

 

 

I believe your assessment that the two servers in the pool are routing around the F5 is correct. The default gateway on all of these VMs is 10.38.158.1. When you suggested using a SNAT pool I attempted to put the two VMs I'm trying to load balance into the SNAT pool. That didn't work. As I read more I felt like I was understanding less and less about how I should setup a SNAT pool for these two VMs. I also tried going into the Route section of the F5 and tried to setup something that would route the 10.38.158.0 subnet to the 92 subnet which didn't work.

 

 

I'm putting this info out here so you can give me some concrete suggestions and guidance about how I should setup this SNAT configuration.

 

 

Dwight

Think of SNAT as a proxy.

 

 

The connection comes into the LTM. The LTM opens a separate connection to the poolmember. The LTM then proxies all your traffic from client over to the pool member. Transforming it as it goes according to the settings of your VS (e.g. iRules).

 

 

The pool member therefore sees the clientip of the connection as the IP address of the LTM (Floating selfIP if configured, IP from a SNATPool if configured).

 

So when using SNAT, the pool member doesn't need to be able to route back to the actual clientIP. Just like your web proxy at work. (Except the connection is kind of in reverse because the proxy is local to the server, and not local to the client :)

 

 

 

H

if you run tcpdump, traffic flow should look like this.

192.168.204.8 is client

172.28.19.79 is virtual server

200.200.200.10 is selfip

200.200.200.101 is pool (server)

(1) client sends SYN to virtual server

(2) virtual server sends SYN+ACK to client

(3) client sends ACK to virtual server, so client-side's 3-ways handshake is completed.

(4) bigip (selfip) sends SYN to pool

(5) pool sends SYN+ACK to bigip

(6) bigip sends ACK to pool, so server-side's 3-ways handshake is completed.

[root@ve1023:Active] config  b virtual bar list
virtual bar {
   snat automap
   pool foo
   destination 172.28.19.79:80
   ip protocol 6
}
[root@ve1023:Active] config  b pool foo list
pool foo {
   members 200.200.200.101:80 {}
}
[root@ve1023:Active] config  b self 200.200.200.10 list
self 200.200.200.10 {
   netmask 255.255.255.0
   vlan internal
   allow default
}

[root@ve1023:Active] config  tcpdump -nni 0.0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 108 bytes
(1) 01:05:56.745896 IP 192.168.204.8.49551 > 172.28.19.79.80: S 1485823336:1485823336(0) win 8192 
(2) 01:05:56.745928 IP 172.28.19.79.80 > 192.168.204.8.49551: S 3652669928:3652669928(0) ack 1485823337 win 3780 
(3) 01:05:56.749901 IP 192.168.204.8.49551 > 172.28.19.79.80: . ack 1 win 4410
(4) 01:05:56.749954 IP 200.200.200.10.49551 > 200.200.200.101.80: S 1586067383:1586067383(0) win 4380 
(5) 01:05:56.750925 IP 200.200.200.101.80 > 200.200.200.10.49551: S 2303747747:2303747747(0) ack 1586067384 win 5840 
(6) 01:05:56.750933 IP 200.200.200.10.49551 > 200.200.200.101.80: . ack 1 win 4380

this is very good article about how tcp connection is set.

 

 

sol8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types

 

http://support.f5.com/kb/en-us/solutions/public/8000/000/sol8082.html

 

 

hope this helps.

Thanks to everyone who responded to my last post. I finally got a chance to do a little testing based on the info presented. What I have discovered using tcpdump is that the virtual server is never actually talking to the servers in the pool. So, we are never getting to the issue of routing back from the servers in the pool. To this point I have not figured out with the limited time I have spent on this why the virtual server cannot talk to these servers in the pool.

What I have discovered using tcpdump is that the virtual server is never actually talking to the servers in the pool.does the virtual server use http profile? if yes, bigip has to receive HTTP request ,e.g. GET, before sending SYN packet to pool member. if not, after finishing 3 way handshake, bigip should send SYN packet.

Good News! I finally got it working. Using tcpdump I tried a couple of different configs till I got F5 to acutally route traffic to the VMs in the pool (which is were I erroneously thought I was at when I started this conversation). The config that solved this part was setting up a route for the 158 subnet that routed to the default gateway on the 92 subnet (which is also the external VLAN). Then I set the SNAT Pool for the Virtual Server to Auto Map and it all started working. Thank You once again to everyone that responded and gave me insight into my problem and debugging suggestions.