Forum Discussion

Dev_56330's avatar
Dev_56330
Icon for Cirrus rankCirrus
May 13, 2014

Using LTM to load-balance applications in geographically different site

I am looking for assistance load balancing a pool in which the pool members reside in a separate geographical location. See below for my scenario. Big IP at SiteA * Virtual Server to load balance SharePoint 2010 * Pool - Pool Members reside at SiteB * While I cannot assign a self ip to the big IP at site A that sits on the same subnet I have a SNAT IP that is routable. * Using ping -s snat_ip ip_of_pool_member in site b is successful (Using netmon capture see icmp traffic on pool member as well as replies on big ip) * From Pool member at site b I can ping the snat IP successfully. * When running tcpdump with tm.rstcause.log enabled, I see resets are being sent from the virtual server ip to the client due to no route to host. Support has confirmed LTM will use the default route which is also being used for ICMP from snat ip to pool member and vice versa.

 

Pool Members at SiteB 3 pool members with routable IP's

 

My question now is even though there is a default route, should I have to create a static route? Any assistance is greatly appreciated.

 

16 Replies

  • While I cannot assign a self ip to the big IP at site A that sits on the same subnet..

     

    Is it because there is no subnet match for your default route and self ip?

     

    • Dev_56330's avatar
      Dev_56330
      Icon for Cirrus rankCirrus
      Kunjan, I apologize as this may have been a little vague. All of other services that are being load balanced by the big ip at site A have a self ip on the SiteA ip space and fall in the same subnet as the pool members it is load balancing at site A. For the the pool members in site B, since I cannot assign an ip address from site B to the big ip at site A, I am relying on the routable ip address I have configured as my snat pool IP. If I did not understand your question correctly let me know and I will try and explain more clearly. Thanks for your response.
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus

    While I cannot assign a self ip to the big IP at site A that sits on the same subnet..

     

    Is it because there is no subnet match for your default route and self ip?

     

    • Dev_56330's avatar
      Dev_56330
      Icon for Cirrus rankCirrus
      Kunjan, I apologize as this may have been a little vague. All of other services that are being load balanced by the big ip at site A have a self ip on the SiteA ip space and fall in the same subnet as the pool members it is load balancing at site A. For the the pool members in site B, since I cannot assign an ip address from site B to the big ip at site A, I am relying on the routable ip address I have configured as my snat pool IP. If I did not understand your question correctly let me know and I will try and explain more clearly. Thanks for your response.
  • Arie's avatar
    Arie
    Icon for Altostratus rankAltostratus

    A few years ago I had a similar scenario, which did indeed require configuring a route on the BIG-IP itself.

     

  • For the the pool members in site B, since I cannot assign an ip address from site B to the big ip at site A,

     

    If you are trying to assign the self ip from Site B subnet, that's not needed. The self IP still can be from site A and you can still can connect. Just need your default gateway(next hop router) reachable from self IP.

     

    • Dev_56330's avatar
      Dev_56330
      Icon for Cirrus rankCirrus
      Understood, this would never work anyway by assigning an ip from a different ip space with no routes in place. However, in this case I am able to ping the default gateway using the self ip address as the source ip.
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus

    For the the pool members in site B, since I cannot assign an ip address from site B to the big ip at site A,

     

    If you are trying to assign the self ip from Site B subnet, that's not needed. The self IP still can be from site A and you can still can connect. Just need your default gateway(next hop router) reachable from self IP.

     

    • Dev_56330's avatar
      Dev_56330
      Icon for Cirrus rankCirrus
      Understood, this would never work anyway by assigning an ip from a different ip space with no routes in place. However, in this case I am able to ping the default gateway using the self ip address as the source ip.
  • You may need to configure a route on the Big IP. Make sure that the server can hit the SNAT IP as well. You may have to enter a route on the server for it to get to the SNAT IP address.

     

  • However, in this case I am able to ping the default gateway using the self ip address as the source ip.

     

    Pinging with self IP or SNAT IP?

     

    • Dev_56330's avatar
      Dev_56330
      Icon for Cirrus rankCirrus
      kunjan, it is with either. I used an ip that already exists as the self ip on the big ip as the snat pool ip and I have also use another unused ip address within the same subnet that is not listed as a self ip on the big ip.
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus

    However, in this case I am able to ping the default gateway using the self ip address as the source ip.

     

    Pinging with self IP or SNAT IP?

     

    • Dev_56330's avatar
      Dev_56330
      Icon for Cirrus rankCirrus
      kunjan, it is with either. I used an ip that already exists as the self ip on the big ip as the snat pool ip and I have also use another unused ip address within the same subnet that is not listed as a self ip on the big ip.
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus

    If not done, may be you verify the routes and arp from tmsh cmd line. So will able to verify the vlans attached to self ips as well.

    tmsh show /net route static
    tmsh show /net arp
    
  • Thank you for everyone's assistance. Indeed, even though I am able to ping the snat IP from the pool member and the pool member from the stat IP I still had to add a static route for the Virtual Server to work correctly. I guess LTM processes the routing tables differently than I expected.