Forum Discussion

Tom_Bell_15050's avatar
Tom_Bell_15050
Icon for Nimbostratus rankNimbostratus
Jun 29, 2010

Issues getting second F5 to answer on real world IP

We have a mirrored configuration. Namely an ASA forwarding traffic to a F5 serving traffic from a pool of nodes behind it.

 

 

At one site we've successfully setup and tested the following.

 

 

(172.b.x.x) (203.x.x.x/32) (172.a.x.x)

 

(INTERNET) <<-->> ASA <<-->> F5 (With real world IP) <<-->> Pool (Different 172 network)

 

 

 

The entire /24 real ip range has been delegated to the ASA and it's forwarding those real IP's on 80 & 443 through to the F5. Between the F5 and ASA is a 172 network we use for routing. The F5 has a VIP listening on one of these real world IP's and happily answers traffic and serves content. This F5 behaves as expected with both SNAT on or off as well as being able to use SNAT pools easily.

 

 

Our second site has the same physical hardware yet is behaving differently.

 

 

Namely we are able to use tcpdump on the F5 .. and see the traffic on the relevant vlan coming in. Yet the traffic is never answered by the VIP or forwarded to the relevant pool. Yes we are using a different /24 subnet of real world IP's. And yes the subnets at each site do point at the relevant kit as their default gateway.

 

 

We've gone through every possible setting on both the firewalls and F5's the only difference being an incredibly minor version difference on firmwares on the F5 namely BIG-IP 9.3.1 Build 69.0 (working) vs BIG-IP 9.3.1 Build 58.0 (not working).

 

 

We are running F5 LTM 9400's.

 

 

To complicate matters .. both F5's are currently serving farms of content just on 172 IP's that have been natted by the ASA's rather then our preferred method of the 203 IP's being on the F5's.

 

 

If there's anything else anyone can think of for me to check that would be awesome.

 

 

Thanks

 

 

Tom

 

6 Replies

  • If you SSH to the actual F5 box, are you able to telnet to its VS IP over 80 and issue GET requests? If you are, then we know the VS is working and it'll just be a matter of confirming VLANs, Trunking, and that your VS is enabled on the appropriate VLANs.
  • You mentioned checking everything on the first F5 (that is working normally), but not the behaviors and configuration of the second F5.

     

     

    Do both F5’s have a Self IP Address assigned on what you have listed as 172.a.x.x?

     

     

    (172.b.x.x) (203.x.x.x/32) (172.a.x.x)

     

    (INTERNET) <<-->> ASA <<-->> F5 (With real world IP) <<-->> Pool (Different 172 network)

     

     

     

    Are there any other Virtual Servers configured on the F5 that you are having problems with, that are using the same 172.a.x.x subnet, and are working properly?

     

     

    Has a route for this subnet been added for the 172.a.x.x Subnet on the broken F5?

     

     

    Is SNAT enabled on the Virtual Server on the device that isn’t working? (When SNAT is enabled, the LTM uses its self IP Address on the subnet in question).

     

  • George_Watkins_'s avatar
    George_Watkins_
    Historic F5 Account
    Hi Tom,

     

     

    I agree with Michael. This smells like a routing/SNAT issue to me. If the virtual is being marked up on the LTM and is receiving traffic destined for that virtual, the LTM should be sending the traffic to the relevant pool. If you are not SNATing traffic at the virtual, only the destination address will be changed (to the selected pool member's IP). If the pool member then receives traffic that has a source address of the virtual IP, it will try to return it via it's default route (unless there is a more specific one specified). The LTM will drop the traffic at this point.

     

     

    I think if you've got the ASA properly forwarding the traffic to the LTM, you've made it over the biggest hurdle. Two last questions: what type of virtual are you using? I'm assuming this is HTTP traffic, did you double check that you have an HTTP profile associated with the virtual?

     

     

    Hope this helps,

     

     

    -George
  • First up, thanx for your replys guys.

     

     

    Chris: From the functioning F5 I'm able to telnet to the VIP on 443 (https) and I get a socket. On the second F5 I'm unable to telnet to port 80 (http) on the VIP I infact get a "No route to host" error even though there's a route in the route table for this address range.

     

     

    Michael: Both F5's have IP's in all of the relevant networks. All other currently configured VIP's function as expected. I've played with SNAT on or off and see no change in behaviour. If I disable the VIP I see the F5 send a RST packet back to the client otherwise nothing. Also with SNAT on, even on working networks, I've noted using automap that the F5 seems to pick random IP's to SNAT behind .. and often these IP's arent even on the network it's SNAT'ing into. I've used static NAT entries in some instances to resolve this.

     

     

    Watkins: Both virtuals in these examples are serving HTTP or HTTPs data I've tried both configurations on either side. The working F5 will do either happily and obviously the borked one will do neither. Out networks are pretty messed up and I've been tasked with their simplification which is why I'm trying to get these IPs onto the F5 in the first place, as a consquence I've been chasing routing loops for a fortnight and have nearly all of them resolved and am basically certain that there isn't one in this case. The pool I'm using as a test case has only 1 node .. and running tcpdump on this host shows that it's not seeing ANY packets related to this query, so I'm kinda certain for some reason the F5 has decided not to answer ? as to why ? Thats why I'm here.

     

     

    Thanks again guys

     

     

    Tom

     

     

     

     

     

  • you see nothing on tcpdump on the borked system when vips are enabled? Have you tried a bigstart restart? Any reason the borked system isn't on the same revision as the working system?
  • It may also be worth looking carefully at L2. You should see the active BigIP respond to arp requests for the Virtual Server in question. If you run a tcpdump on both systems and then issue a fail over you may be able to home in on what is going on and rule corrupt/incomplete/working arp tables in or out.

     

     

    -Matt