I have a question regarding setting up inbound access to my companies webserver [forgive me if this is too basic for this forum but I have read the appropriate manuals in the knowledgebase and couldnt get a satisfactory answer. I recently took over this role and I'm new to F5's]. For outbound traffic we currently have multihoming setup on out F5s with a primary 100MB link and a backup 4MB link. All internet traffic is routed out the 100MB, if this link goes offline we failover to the 4MB link and this works as required. For inbound traffic we want to be able to be able to assign 2 IP addresses to our web server [one from each ISP] and have all inbound traffic connect via the primary ISP address [lets call it 100.100.100.100] and if that goes offline users will still be able to connect to the same URL via the backup ISP IP address [lets call it 4.4.4.4]. I have setup the appropriate virtual servers linking 100.100.100.100 and 4.4.4.4 to the internal ip address of our web server and both ip addresses can be pinged from the web. I can HTTP to 100.100.100.100 ok but if I try to HTTP to 4.4.4.4 it fails [internet explorer cannot display the web page]. [Both servers have exactly the same access through our firewall]. Will the 4.4.4.4 address only be accessible from the web once we have failed over to the 4MB link or should I be able to HTTP to it from the web at anytime? Also do I need to setup an Inbound Wide IP to be able to access this server via the same URL? [i.e. web users connect to www.whatever.com which resolves to 100.100.100.100. Then our primary ISP goes offline and 100.100.100.100 is no longer accessible. Will www.whatever.com now resolve to 4.4.4.4 because the Inbound Wide IP advertises it or will BGP still be needed?] Any advice would be much appreciated. Thanks

Since you mentioned Inbound Wide IPs, are you using Link Controller? Or GTM? Have you done a tcpdump from the F5 box when trying to HTTP to 4.4.4.4? I'd be curious whether your F5 is trying to send the server's response out the 100.100.100.x link.

Im using Link Controller, I will run a tcpdump and check the output

Posted By biglouie on 01/14/2011 07:52 AM Im using Link Controller, I will run a tcpdump and check the output So your setup is like this: Link 1 - 111.111.111.x Link 2 - 4.4.4.x Virtual Server 1 - 111.111.111.111:80 Pool for Virtual Server 1 - Let's say 10.1.1.1 Virtual Server 2 - 4.4.4.4:80 Pool for Virtual Server 2 - Let's say same as Pool for Virtual Server 1 How do you have your links defined so that outbound only uses Link 1? It's been a little while since I've been in Link Controller so am curious. Also, LC should be able to use DNS to handle the Link Failure you described.

Put the ISP router IP addresses for both links into a pool called "pool_default_gateways" and have this as the default gateway for the LC. Give the primary link a priority of 5 and give the backup link a lower priority and set priority group activation = less than 1. So all outbound traffic goes through the higher priority link until that fails, then it goes through the lower priority link.

Gotcha. That makes sense and handles outbound just fine but can definitely cause issues with inbound. For inbound, you'll define a wide ip and have it use your Virtual Servers from each link. I can't remember how to have it only hand out the Virtual Server from link 1 though...

Inbound Web access | DevCentral

11 Replies

Chris_Miller
Altostratus
Jan 14, 2011
Since you mentioned Inbound Wide IPs, are you using Link Controller? Or GTM?

Have you done a tcpdump from the F5 box when trying to HTTP to 4.4.4.4? I'd be curious whether your F5 is trying to send the server's response out the 100.100.100.x link.
biglouie_102731
Nimbostratus
Jan 14, 2011
Im using Link Controller, I will run a tcpdump and check the output
Chris_Miller
Altostratus
Jan 14, 2011
Posted By biglouie on 01/14/2011 07:52 AM

Im using Link Controller, I will run a tcpdump and check the output

So your setup is like this:

Link 1 - 111.111.111.x

Link 2 - 4.4.4.x

Virtual Server 1 - 111.111.111.111:80

Pool for Virtual Server 1 - Let's say 10.1.1.1

Virtual Server 2 - 4.4.4.4:80

Pool for Virtual Server 2 - Let's say same as Pool for Virtual Server 1

How do you have your links defined so that outbound only uses Link 1? It's been a little while since I've been in Link Controller so am curious.

Also, LC should be able to use DNS to handle the Link Failure you described.
biglouie_102731
Nimbostratus
Jan 14, 2011
Put the ISP router IP addresses for both links into a pool called "pool_default_gateways" and have this as the default gateway for the LC. Give the primary link a priority of 5 and give the backup link a lower priority and set priority group activation = less than 1.

So all outbound traffic goes through the higher priority link until that fails, then it goes through the lower priority link.
Chris_Miller
Altostratus
Jan 14, 2011
Gotcha. That makes sense and handles outbound just fine but can definitely cause issues with inbound.

For inbound, you'll define a wide ip and have it use your Virtual Servers from each link. I can't remember how to have it only hand out the Virtual Server from link 1 though...
biglouie_102731
Nimbostratus
Jan 17, 2011
Ive just done a tcpdump and you were correct, the traffic received on the 4.4.4.4 [backup] interface is being routed out the 100.100.100.100 [primary] interface, so I guess this is why the connections to 4.4.4.4 are failing. Do you know how to remedy this? Looking through the manuals it may need a persistence profile setup but I'm not too sure.

thanks
Chris_Miller
Altostratus
Jan 17, 2011
Posted By biglouie on 01/17/2011 07:20 AM

Ive just done a tcpdump and you were correct, the traffic received on the 4.4.4.4 [backup] interface is being routed out the 100.100.100.100 [primary] interface, so I guess this is why the connections to 4.4.4.4 are failing. Do you know how to remedy this? Looking through the manuals it may need a persistence profile setup but I'm not too sure.

thanks

I had the same setup as you - multiple links, default gateway pool, and Virtual Servers on the different links. Two difference though - I was using inbound wide ips to direct the traffic to the Virtual Servers and I also didn't have all traffic going out only one link.

Since the Virtual Server is automatically mapped to the proper link, the inbound part is working fine. Now, it's up to the pool member (web server) to respond. The pool member should respond to the inside interface of the Link Controller whose job it is to send the response out the proper link.

Assuming you're using the default Auto Last Hop settings (http://support.f5.com/kb/en-us/solu...r=12151666), Link Controller should response to the mac address from which it received the request which I'd expect to be the router for link 4.4.4.4. If you're not using Auto Last Hop, I'd expect Link Controller to use its routing table which likely says to use the 100.x link as long as it's available.

You haven't made any changes to that default behavior, have you? I'm hoping I'm being accurate...it's been a bit since I've used Link Controller. Since you asked about persistence, shall I assume you aren't using any at all right now? Also, are you testing 4.4.4.4 from an outside network?

Finally, might be wise to make a case with support and run them through what you're seeing as I'm confident this has been encountered before.
biglouie_102731
Nimbostratus
Jan 17, 2011
Yep, Auto Last Hop was turned off. I've turned it on and now can connect to the server on both 100.100.100.100 and 4.4.4.4 [I'm testing from a wireless broadband connection we have in the office so its a good way of testing external users access].

Thanks a lot for your help!
Chris_Miller
Altostratus
Jan 17, 2011
Posted By biglouie on 01/17/2011 09:07 AM

Yep, Auto Last Hop was turned off. I've turned it on and now can connect to the server on both 100.100.100.100 and 4.4.4.4 [I'm testing from a wireless broadband connection we have in the office so its a good way of testing external users access].

Thanks a lot for your help!

My pleasure. Unfortunately (fortunately for you,) I ran into quite a few quirks when installing Link Controller at my last company. It's an amazing piece of equipment but requires a fair amount of time and effort to tailor to a "complex" environment.

If you run into any issues when setting up your listeners or inbound wide ips, feel free to post them and I'll see if I can help.
biglouie_9849
Nimbostratus
Jan 18, 2011
Hi again

I've been looking at/testing our ability to failover our website from the primary ISP IP address to the backup ISP IP address whilst still using the same URL. I have 1 virtual server for each ISP IP address and they are both in an Inbound Wide IP for the URL.

If I disable the virtual server for the primary ISP I cannot access the website via the URL anymore [I tried for 10 mins], so I guess DNS entries are not being updated on local internet name servers. Looking in Statistics>Local Traffic>Local DNS there are "no records to display" [I guess this means local name servers are not making any DNS requests to my F5's?].

I found the following information on another site:

"The F5 Link Controller has a built in Dynamic DNS server called Zonerunner. You make it the Authoritative Sever for the FQDN you need load balanced. You then configure Listeners on the LC for each link (NS1, NS2). The LC will have WideIP's, which are A records with addresses on both links address space. The LC will receive DNS requests on either link and respond with the IP address of the active links address space. "

Is this correct? The only other reference I can find to Zonerunner is on GTM not LC. If so, how do I go about making zonerunner the Authoritative Sever for my FQDN? Also, is 10minutes enough time for the DNS entries to be updated? I realise worldwide propagation may take significantly longer, but all I really need in a short-term outage is for users in the London area to be able to access the URL via its new backup IP address [our server room is in London as are all the administrators/managers who are going to be the ones jumping up and down if they cant access the VPN at 2am!]

Thanks