Forum Discussion
NimbostratusIncorrect vserver being chosen
Hi all. Suppose I have the following IP Forwarding vservers in my LTM (v17.1.0.3):
ltm virtual vserv-coa {
creation-time 2023-10-30:08:44:12
destination 10.0.0.0:1700
ip-forward
ip-protocol udp
last-modified-time 2024-01-25:07:54:02
mask 255.0.0.0
profiles {
fastL4 { }
}
serverssl-use-sni disabled
source 10.10.40.0/24
source-address-translation {
pool coa-snat-pool
type snat
}
translate-address disabled
translate-port disabled
vlans {
internal
}
vlans-enabled
vs-index 2
}
ltm virtual vserv-outbound {
creation-time 2023-10-11:15:24:29
destination 0.0.0.0:any
ip-forward
last-modified-time 2023-10-11:15:24:29
mask any
profiles {
fastL4 { }
}
serverssl-use-sni disabled
source 10.10.40.0/24
translate-address disabled
translate-port disabled
vlans {
internal
}
vlans-enabled
vs-index 4
}
Why is it that when my nodes 10.10.40.5 and .6 send RADIUS CoA traffic using udp/1700 that the LTM chooses to use the less specific vserv-outbound vserver rather than the more specific vserv-coa vserver?
Based on K14800, the defined order of precedence for NEW connections should be matched based on most specific destination, most specific source, most specific port. In this case a sample connection would be:
destination: 10.100.1.234
source: 10.10.40.5
port: udp/1700
vserv-coa: Destination = 10.0.0.0/8, Source = 10.10.40.0/24, Port = udp/1700
vserv-outbound: Destination = *, Source = 10.10.40.0/24, Port = *
Both my SE and F5 TAC are saying that because there are existing UDP connections matching the vserv-outbound vserver then all other UDP traffic will just end up using that vsever as well. This makes absolutely zero sense. All CoA flows are 100% unique connections, so why would the LTM not evaluate them individually? Please, someone help me make it make sense.
2 Replies
Hello,
There is an article mentioning this issue, you can check it out and try deleting the old entries and check if there is a difference.
https://my.f5.com/manage/s/article/K04199440
# tmsh show sys connection cs-server-addr "IP"
# tmsh delete sys connection cs-server-addr "IP"
Thanks,
Mohamed Salah
unclericoHello Mohamed. Thank you for responding. I took a look at the KB article and at first I thought it was exactly what I was after, but the article references existing connections sticking to the same vserver. These connections are new, unique connections being established from 10.100.40.5 and .6 to devices within my 10/8 range. Since they are new and unique, they should be evaluated as such as opposed to being lumped in with other UDP traffic that doesn't even use the same ports. I hope I'm making sense.
