Forum Discussion

Bob_Vance_75936's avatar
Icon for Altostratus rankAltostratus
Apr 22, 2011

INET port exhaustion and ip forwarding VIP




Every now and then we will have an issue with inet port exhaustion being logged for DNS traffic passing thru the LTM using the ip forwarding VIP:




local/tmm crit tmm[9177]: 01010201:2: Inet port exhaustion on to (proto 17)




There are a lot of connections being used but not enough to actual exhaust all possible ports. Also, since this is using the ip forwarding VIP I would think that the ports would be retained and not be translated. However, when I check, I notice that more often than not the source port is translated by the LTM.




VIRTUAL any <-> NODE TYPE any 1/0






PROTOCOL udp UNIT 1 IDLE 287 (300) LASTHOP vlan1625 00:50:56:93:01:46





Could a massive influx of DNS queries cause inet port exhaustion if they are actually being translated by the ipforwarding VIP? And why would the ip forwarding VIP translate the src ports?






7 Replies

  • Hi Bob,



    We discussed optimizing and UDP DNS virtual server configurations in this thread:





    If you follow those tips you should be able to greatly reduce the time that connections are kept for.



  • Thanks hoolio. Very interesting info in that thread.



    Does anyone have a link or info on how the LTM controls the port translation across a VIP? Below is the ip forwarding VIP and I am searching for why the LTM would proxy this connection and change the source ports.






    virtual ip_forwarding {




    limit 0


    rate class none


    mirror disable


    translate address disable


    translate service disable


    srcport preserve




    snat none


    cmp enable


    cmp processor none


    lasthop pool none


    snatpool none


    pool none


    fallback persist none


    destination any:any




    ip protocol any


    partition Common


    rules none


    httpclass none


    persist none


    auth none


    clone pools none


    profiles fastL4 {






    traffic classes none


    vlans none disable



  • Hi Bob,



    See SOL11003 for some details on this:





  • Hoolio: Do you think "srcport preserve strict" might help here? Sounds like the LTM thinks that (for some reason) the source port is already being used in error; i think "strict" will force it to not translate, period, whereas "srcport preserve" does it only if it's not tracking anything it thinks is conflicting.
  • Is it a problem if the source port gets translated? If so, I think reducing the idle timeout (to immediate?) for UDP would alleviate the port reuse. Regardless it would make sense to really trim down the idle timeout for DNS traffic.



  • My $.02: I wouldn't use preserve strict here, as it only really applies to UDP virtual servers (See the warning at the bottom of SOL8227) and DNS can use TCP as well.



  • Yeah, that's another reason separate virtual servers for TCP and UDP make a lot of sense for DNS. I think we covered this fairly well in the past thread I linked to above.