Forum Discussion

jeremy_newman_4's avatar
jeremy_newman_4
Icon for Nimbostratus rankNimbostratus
Jul 24, 2006

im guessing really really simple problem

Hi people,

 

 

I am a complete newby so please excuse me

 

Have a big ip which is doing some simple loadbalanceing on port 80

 

 

It was also doing NAT on some addressed (bacily directt translation from

 

 

 

202.91.x.y --> 192.168.x.y

 

 

we did not set this up internaly and really have very basic skill in this area

 

 

our problem is that we had a catastrophic power outage today which has left the natting not working from the outside world (we can ping a public ip from within the network, but not from outside). But the load balanced ip for http is still working (the primary one one the external nic)

 

and anyone suggest where we can begin looking

 

 

our version is BIG-IP Kernel 4.2PTF-10 Build95Cpu-0

 

 

any held would be so greatly appreciated

 

 

thanks

 

 

Jeremy
dev
devops
iControl
v4
  • Mark_Harris_608's avatar
    Mark_Harris_608
    Icon for Cirrus rankCirrus
    Jul 24, 2006
    Hi -

     

     

    I'm guessing your question should go to websupport.f5.com instead of devCentral. ;-) All kidding aside, I just happened to jump on and see your question and thought I'd give you some "free support" and suggest you forward your case to F5 tech support.

     

     

    As for the pinging of a NAT, don't expect a standard response from the node. NATs will not forward ICMP requests to the node. At most, the BIG-IP's external interface will respond, not the node. That could be why the HTTP VIP still works but NAT doesn't respond to pings.

     

     

    Also, if you had a power outage, the active BIG-IP could have changed on bootup (the other box came up first and became active), so the MAC address has changed, and the upstream device (usually a FW with a long ARP cache) has an other MAC address still in it's cache.

     

     

    Finally, a myriad of other factors could be involved on a power outage / reboot of both BIG-IP controllers. Do a trace route to from the outside in and find the last device that responds. The most likely cause if it ends with the device before BIG-IP is that the NAT is missing, incorrectly configured, or different on the currently active device (devices were not synced prior to the outage), or the ARP cache issue I mentioned above.

     

     

    /mh