The LB may choose the connection with the different destination port under the following conditions.
Here is a simple scenario where the issue could happen.
1. There are two virtual servers with the same VIP and different Ports.
VirtualServer#1 : <VIP>:<VS_PORT1>
VirtualServer#2 : <VIP>:<VS_PORT2>
There is one server pool with one member server and no port assigned.
This server pool is used by two virtual servers, and TCP multiplexing is enabled.
Server Pool : <MEMBER_SERVER>
2. The first connection is successfully created between a client and VirtualServer#1,
but the second connection between the client and VirtualServer#2 will not be created properly.
In reality, the output of the second connection would be the same as that of the first connection.
For example, from the output of "get load-balancer <LB UUID> session-tables", you might see the following.
Session-Tables TABLE ID PROTO CADDR CPORT VADDR VPORT SADDR SPORT DADDR DPORT l7lb-0 0000000000000003 http <CLIENT_IP> <CLIENT_PORT1> <VIP> <VS_PORT1> <SNAT_IP> <SNAT_PORT> <MEMBER_SERVER_IP> <VS_PORT1> l7lb-0 0000000000000005 http <CLIENT_IP> <CLIENT_PORT2> <VIP> <VS_PORT2> - 0 - 0 |
VMware NSX-T Data Center
It is because when we choose a connection between LB and the backend server, the destination port might not be considered.
Workaround:
To address this issue, customers avoid sharing the same server pool among different virtual servers. Instead, they create individual server pools for each virtual server.