-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Building NAT Gateway in load balancing mode based on ECMP does not work fine #112
Comments
We meet similar problems. A further investigation show that the packet in the same session might be hashed to a different value when tcp session is closing. I'm not sure if |
One more thing, I tested it based on [ OVN 20.12 + OVS 2.15.0 ] 、 [ OVN 21.12 + OVS 2.16.9 ], and the problems described above will appear. In addition when using ECMP, snat action occasionally does not convert. |
@zhanrox2 I suspect that |
Sorry for the long time to get this fixed, it's indeed a problem with dp-hash in the kernel. It's not a "real" stable hash. I posted a fix to change to the L4 symmetric hash algorithm (which now is supported in the kernel too): |
Regular dp-hash is not a canonical L4 hash (at least with the netlink datapath). If the datapath supports l4 symmetrical dp-hash use that one instead. Reported-at: ovn-org#112 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2188679 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: 0-day Robot <robot@bytheb.org>
Regular dp-hash is not a canonical L4 hash (at least with the netlink datapath). If the datapath supports l4 symmetrical dp-hash use that one instead. Reported-at: ovn-org#112 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2188679 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Ales Musil <amusil@redhat.com>
Regular dp-hash is not a canonical L4 hash (at least with the netlink datapath). If the datapath supports l4 symmetrical dp-hash use that one instead. Reported-at: ovn-org#112 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2188679 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Ales Musil <amusil@redhat.com> (cherry picked from commit 596ea7a)
Regular dp-hash is not a canonical L4 hash (at least with the netlink datapath). If the datapath supports l4 symmetrical dp-hash use that one instead. Reported-at: ovn-org#112 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2188679 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Ales Musil <amusil@redhat.com> (cherry picked from commit 596ea7a)
Regular dp-hash is not a canonical L4 hash (at least with the netlink datapath). If the datapath supports l4 symmetrical dp-hash use that one instead. Reported-at: ovn-org#112 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2188679 Signed-off-by: Dumitru Ceara <dceara@redhat.com> Acked-by: Ales Musil <amusil@redhat.com> (cherry picked from commit 596ea7a)
We plan to build two NAT Instances in load balancing mode based on ECMP, but during our testing, we found that ECMP has flaws and needs to be confirmed。Packets from the same session ( based five-tuple) will be assigned to multiple different nexthops by ECMP,this can an be reproduced by the following operations.
1. Build network topology -- Routers And Switches
2. Build network topology -- Simulate VM C01
3. Build network topology -- Build Two NAT Gateway Instances R2&R3
4. Build network topology -- Connected To Underlay Network
Chassis A
Chassis B
5. Build network topology -- Configure ECMP routing on R1, Point to R2&R3 at the same time
6. Test
We test the connection to the remote server 172.16.138.254 in the virtual machine c01 on Chassis A,At the same time, we capture packets on Chaasis A and Chassis B。 We found that the same session (the same source port 55346) discovered from the virtual machine c01 will come out from R2 (external ip 10.1.1.1) and R3 (external ip 10.1.1.5) respectively, resulting in abnormal telnet connection,as follows:
VM C01
Chassis A
Chassis B
Can anyone tell me whether ECMP can be used in this scenario or is there a problem with the configuration ? @hzhou8
The text was updated successfully, but these errors were encountered: