BigIp LTM V11.3 Load balancing on non local servers

It's certainly doable. The most important thing you have to do is make sure your BIG-IP has access to the Internet and can successfully route out to the Google IP (ie. set a default outbound route).

 

 

At some point however, you may come to find that configuring specific IP addresses for remote services like Google is maybe not the best idea, as you have no control over those IPs which can change without warning. An alternative approach is to use DNS and the RESOLVE::lookup and node commands to dynamically steer traffic. Take a look at the examples on the RESOLVE::lookup wiki page:

 

 

https://devcentral.f5.com/wiki/iRules.resolv__lookup.ashx

 

 

Of course now you must also ensure that the BIG-IP can resolve the remote host names as well.

 

Hello !

Thank you for your reply :).

In my case, i'm doing a very temporary configuration on my LTM, so I don't have to maintain this configuration for a long time.

However, even if I have the right configuration for the route to google's IP, I get a strange behaviour.

When I am on my CLI in SSH and I do a "curl" command on the IP I set in my pool, everything work fine (If I don't miss something, it means that my route configuration are correct). But when I am trying to use my virtual server with my client machine, I can't reach anything.

This the configuration of my virtual server:

 ltm virtual /Common/rab_google {
    destination /Common/172.42.17.8:80
    disabled
    ip-protocol tcp
    mask 255.255.255.255
    pool /Common/google_pool
    profiles {
        /Common/fastL4 { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vlans-disabled
}

And here is my pool

ltm pool /Common/google_pool {
    members {
        /Common/173.194.34.56:80 {
            address 173.194.34.56
        }
    }
    monitor /Common/gateway_icmp
}
 

In my opinion, it should work. Do you think I am missing something ?

Thank you for your time ! 🙂

Hello !

 

 

Thank you for your reply :).

 

 

In my case, i'm doing a very temporary configuration on my LTM, so I don't have to maintain this configuration for a long time.

 

 

However, even if I have the right configuration for the route to google's IP, I get a strange behaviour.

 

When I am on my CLI in SSH and I do a "curl" command on the IP I set in my pool, everything work fine (If I don't miss something, it means that my route configuration are correct). But when I am trying to use my virtual server with my client machine, I can't reach anything.

 

 

This the configuration of my virtual server:

 

 

[code]ltm virtual /Common/rab_google {

 

destination /Common/172.42.17.8:80

 

disabled

 

ip-protocol

 

tcp mask 255.255.255.255

 

pool /Common/google_pool profiles { /Common/fastL4 { } }

 

source 0.0.0.0/0 source-address-translation {

 

type automap

 

}

 

translate-address enabled

 

translate-port enabled

 

vlans-disabled

 

}

 

 

 

 

In my opinion, it should work. Do you think I am missing something ?

 

 

Thank you for your time ! :)

 

 

 

EDIT: Sorry for the double post... I didn't find how to remove one...

 

Not sure if this is a typo, but your configuration indicates that the VIP is disabled.

It was a typo, indeed.

Sorry about that. Here is the right configuration:

 ltm virtual /Common/rab_google {
    destination /Common/172.42.17.8:80
    ip-protocol tcp
    mask 255.255.255.255
    pool /Common/google_pool
    profiles {
        /Common/fastL4 { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vlans-disabled
}

it seems okay to me here.

e.g.

[root@ve11a:Active:Changes Pending] config  tmsh list ltm virtual bar
ltm virtual bar {
    destination 172.28.20.111:80
    mask 255.255.255.255
    pool foo
    profiles {
        fastL4 { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vlans-disabled
}
[root@ve11a:Active:Changes Pending] config  tmsh list ltm pool foo
ltm pool foo {
    members {
        173.194.34.56:80 {
            address 173.194.34.56
        }
    }
}

[root@ve11a:Active:Changes Pending] config  curl -I http://172.28.20.111
HTTP/1.1 200 OK
Date: Thu, 25 Jul 2013 12:14:36 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: NID=67=ptia1ULuwH1L5U12tuyAI22OMDMDuBUlllH_1TWP2N9n636kDa8MhMP-4pQTgp1hO2M65v3lb3IqZ0X4Z5uBYVVE9U8nYyEfLAFxCavZATnjo1Pz4ut0l0ahqJm4jgsa; expires=Fri, 24-Jan-2014 12:14:36 GMT; path=/; domain=.; HttpOnly
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Transfer-Encoding: chunked

you may run tcpdump on bigip to see what wrong is.

 

 

e.g.

 

tcpdump -nni 0.0 host 172.42.17.8 or host 173.194.34.56 and port 80

 

tcpdump -nni 0.0:nnn -s0 -w /var/tmp/output.pcap host 172.42.17.8 or host 173.194.34.56 and port 80

I would also try, as Nitass shows, to test access through the VIP with cURL. Google could be sending you redirects that your VIP and browser are not equipped to handle. I'd also have the TCPDUMP capture running and listening for traffic leaving towards the remote IP while you do the cURL test.

what is "ip-protocol" in your vitual server detail ?

 

and what's your virtual server type ?