Forum Discussion

George_32239's avatar
Icon for Nimbostratus rankNimbostratus
Aug 04, 2011

LTM1500 v9.1.3

Hello Again,



OK, I have an LTM 1500 with version 9.1.3 (I know!) of the code. It has been fine for years. Recently added a new virtual server, with necessary pool, pool members, ports, health monitors etc.



What happens is that the virtual server will listen on port 80 for a time and then just stop. On the load balancer I can see the VS, the pools and the nodes as up. I can telnet to the VS on port 80 from the LB itself and I can telnet to each pool member on the necessary port from the LB, but not from a workstation with a browser.



Networking is fine, firewalls are good.



The only way I can get the thing back is to delete the VS and re-create it and it starts working again for a time.



The unit has some 100 virtual servers running various apps and these appear fine, it just seems to be this new one.



I may re-create all of it (someone else created it but looks fine to me), vs, pools, members.



The units have been up for 638 days our support say there is a bug in 2.4 linux kernel where over 497 days it can start behaving oddly and recommend a reboot. It is just weird that older vs's work fine it is just new ones that have this issue.




Anyone seen this before ?








6 Replies

  • Have you performed a reboot to see if that clears the issue? I would certainly start there. If it doesnt, then you could start looking at the possibility of only the new VIPs causing problems. I cant say that I've ever seen that before. Do you have a standby or lab box you could dump that new VIP config on to see if it causes the same issues? When it stops listening have you done a TCPDump or packet capture to see if the traffic is hitting the F5?
  • Hi, thanks. I think first I am going to delete the pool and then the VS and re-create it and see what happens. Then I will try a reboot. I will post back what happens. Weird though never seen that before



  • Regardless, I would recommend a reboot. It's a linux kernel will see problems.





    Furthermore, you could report your issues to F5 Support.



    "Note: These are the only known side effects of the uptime counter wrapping. The issues documented in these Solutions have been patched as noted therein. If you encounter issues that seem related but are not documented here, contact F5 Technical Support."
  • Upgrade! Even if you don't have an active support contact now, you can upgrade to a version that was released when the unit(s) last had support:

    Product Version License Check Date
    BIG-IP 10.2.2 2011-04-02
    BIG-IP 10.2.1 2010-06-05
    BIG-IP 10.1.0 - 10.2.0 2009-11-24
    BIG-IP 10.0.1 2009-04-24
    BIG-IP 10.0.0 2009-01-02
    BIG-IP 9.6.0 - 9.6.1 2007-12-05
    BIG-IP 9.4.8 2009-05-27
    BIG-IP 9.4.6 - 9.4.7 2008-09-15
    BIG-IP 9.4.5 2008-05-01
    BIG-IP 9.4.4 2007-12-07
    BIG-IP 9.4.2 - 9.4.3 2007-09-18
    BIG-IP 9.4 - 9.4.1 2006-10-02
    BIG-IP 9.3.1 2007-10-09
    BIG-IP 9.3.0 2007-03-23

  • Hello,



    I deleted the pools and virtual server and re-created them.



    As per previous tests the VS started to work again. i.e. it would listen on port 80 and pass traffic on to members on 7777, lasted a couple of hours and then died, weird, no indication from the LB that any servers/services are down.



    I have a change in to reboot the balancer and see what happens, I will post the results here.



    Of course the verison is old and no doubt we will have to upgrade at some point (took these over as part of an outsource deal)



    Could be the Linux bug I guess, weird, only breaks newly created stuff about 100 or so legacy are still working fine.



    Out of interest, in terms of quantity of vs's etc, is there an upper limit ?, and how does ARP work on the VS, should I get an ARP on the next physically connected switch/router for the VIP with the MAC of the physical unit ?



    Memory usage looks quite high, and cpu usage to, oh and the fans are knackered !



    Needs some real help the poor unit.








  • Hi folks,



    Firstly thanks very much for all your suggestions. The issue in the end stemmed from someone, allocating themselves a raft of 20 IP addresses without telling anyone else. These overlaped with some of the virtual servers. When I re-created the virtual server I guess I won the ARP war. Eventually, the desktop placed in the same subnet took the arp back and there we have the yoyo effect.



    The person has been suitably slapped around