Forum Discussion
unclerico
Nimbostratus
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.
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.
