Posted By ltp on 07/04/2011 07:59 PM
Hi Bhattman,
I see how this would work, but it is not going to work for my configuration as I am not NATing/SNATing incoming client requests to the VIP's.
In my configuration, the client request will be passed through to the backend nodes with the real client IP address intact - PBR routes the response back via the F5's whom are then able to SNAT the response to the VIP address. Having an access list that excludes traffic originating from the backend nodes to the client network (ip access-list TEST_deny \n 10 permit tcp 10.4.0.0/16 10.2.0.0/16) will have the effect of never forcing return traffic back via the F5's.
I should reiterate that I can see the reply traffic from a client request directly to a backend node hitting the F5's and it appears to be matched by the wildcard virtual server - it appears that the F5's then attempt to route the response using the default gateway on that network, which matches the PBR rules and redirects it back to the F5's resulting in a loop (I see the same sequence numbers in the packet dump) until the packets are eventually dropped.
Hi Ltp,
It doesn't require NATing/SNATing from the VIP. This would work if you were attempting to directly route towards the client and back via the switch using the real IP address. This is assuming that the switch is connected on the same VLAN as the node and the node's default gateway is the switch.
Here are 2 examples
Client to node communication:
1. Source: 10.2.0.12 (Client) --> Destination: 10.4.0.21 (Node) ; Request Leaves the client towards the host
2. Source: 10.2.0.12 (Client) --> Destination: 10.4.0.21 (Node); Request hits the Nexus Switch router
3. Source: 10.2.0.12 (Client) --> Destination: 10.4.0.21 (Node); Nexus Switch router then forwards the traffic towards the host on TEST_VLAN since it's directly attached (Layer 2)
4. Source: 10.2.0.12 (Client) --> Destination: 10.4.0.21 (Node); Host receives the request and then returns a response
5. Source: 10.4.0.21 (Node) --> Destination: 10.4.0.21 (Client); Nexus Switch receives the response because node's gateway is 10.4.0.1
6. Nexus applies PBR matches Test_deny ACL statement, exits out of the route map and then the Nexus switch router forwards response to client perserving the node's real IP addresses.
Client to node communication via VIP
1. Source: 10.2.0.12 (Client) --> Destination: 10.3.0.10 (vip) ; Request Leaves the client towards the VIP
2. Source: 10.2.0.12 (Client) --> Destination: 10.3.0.10 (vip); Packet hits the Nexus Switch router
3. Source: 10.2.0.12 (Client) --> Destination: 10.3.0.10- (vip); Nexus Switch router then forwards the traffic towards the VIP
4. Source: 10.2.0.12 (Client) --> Destination: 10.3.0.10 (vip); F5 receives the response
5. Source: 10.4.0.10 (SNAT/CLIENT) --> Destination: 10.4.0.21 (NODE); F5 SNATs the client's IP address and sends it towards the selected node
6 Source: 10.4.0.10 (SNAT/CLIENT) --> Destination: 10.4.0.21 (Node); Node receives the request and returns a response
5. Source: 10.4.0.21 (Node) --> Destination: 10.4.0.x (SNAT/Client); Nexus Switch receives the response because node's gateway is 10.4.0.1
6. Source: 10.4.0.21 (Node) --> Destination: 10.4.0.x (SNAT/Client); Nexus applies PBR matches Test_Allow ACL statement which states the next HOP is 10.4.0.10. Response is sent to F5
7. Source: 10.3.0.10 (vip) --> Destination: 10.2.0.12 (Client); F5 receives the response on 10.4.0.10 and then retranslates back to client
8. Source: 10.4.0.21 (Host) --> Destination: 10.4.0.21 (Client); Client receives the response.
I hope this clarifies what the test pBR example will do.
Bhattman