Forum Discussion

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

INET port exhaustion and ip forwarding VIP

Hello,

 

 

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 10.1.1.7 to 10.1.2.20:53 (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 10.1.2.20:domain TYPE any 1/0

 

CLIENTSIDE 10.1.1.7:32786 <-> 10.1.2.20:domain

 

SERVERSIDE 10.1.1.7:32789 <-> 10.1.2.20:domain

 

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:

     

     

    http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/52/aft/1168069/showtab/groupforums/Default.aspx

     

     

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

     

     

    Aaron
  • 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 {

     

    enable

     

    limit 0

     

    rate class none

     

    mirror disable

     

    translate address disable

     

    translate service disable

     

    srcport preserve

     

    fastl4

     

    snat none

     

    cmp enable

     

    cmp processor none

     

    lasthop pool none

     

    snatpool none

     

    pool none

     

    fallback persist none

     

    destination any:any

     

    mask 0.0.0.0

     

    ip protocol any

     

    partition Common

     

    rules none

     

    httpclass none

     

    persist none

     

    auth none

     

    clone pools none

     

    profiles fastL4 {

     

    all

     

    }

     

    traffic classes none

     

    vlans none disable

     

     

  • Hi Bob,

     

     

    See SOL11003 for some details on this:

     

     

    http://support.f5.com/kb/en-us/solutions/public/11000/000/sol11003.html

     

     

    Aaron
  • 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.

     

     

    Aaron
  • 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.

     

     

    -Matt
  • 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.

     

     

    Aaron