Forum Discussion
Bob_Vance_75936
Altostratus
AltostratusINET 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?
hoolioCirrostratus
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
Bob_Vance_75936Thanks 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
- hoolioHi Bob,
See SOL11003 for some details on this:
http://support.f5.com/kb/en-us/solutions/public/11000/000/sol11003.html
Aaron 
Joel_MosesNimbostratus
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.- hoolioIs 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 
L4L7_53191My $.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- hoolioYeah, 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