Dear Ben: When I added a"Linux balance-alb bond" to an OVS bridge, I had a problem. Some machines can ping the bridge‘s IP, but some can not. My procedure would look something like this:
1. configure "bond0", mode is balance-alb. 2. add an ovs bridge "ovsbr0" in "machine-x", and add a port "bond0"(linux balance-alb bond). $ ovs-vsctl add-br ovsbr0 $ ovs-vsctl add-port ovsbr0 bond0 $ ip addr flush dev bond0 $ ip addr add ip-x/24 dev ovsbr0 $ ip link set ovsbr0 up 3.many machines ping the bridge's IP at the same time. Some machines can ping the bridge‘s IP, but some can not. I tried to analyze the cause of the problem. I found that any machine with HWaddress "mac-x1" in the ARP table could ping "machine-x", while others with HWaddress "mac-x2" could not. The description of the balance-alb in the bonding documentation(https://www.kernel.org/doc/Documentation/networking/bonding.txt) is as follows: Different peers use different hardware addresses for the server. So I wonder if the destination MAC address of the message sent from "machine-n" is not in the CAM table of ovs bridge, so ovs bridge discarded the message? If this is the case, does it mean that the ovs bridge does not support bonding of specific receive load balancing function? And, is there any way to solve this problem? I tested linux bridge, which has no such problem. I found that the destination MAC address of the message eth2 received was mac-x2, but after the message was sent to bond0, the MAC address was changed to mac-x1. Is this the reason why the Linux bridge doesn't have this ping problem? If so, what can I do to make ovs bridge work? I used the "tcpdump" tool to grab packages for "eth1", "eth2", "bond0", and linux bridge "br0", as below: tcpdump -i br0 -n -e -p src 13.10.12.102 or dst 13.10.12.102 11:49:32.843719 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3357, length 64 11:49:32.843744 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3357, length 64 11:49:33.843731 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3358, length 64 11:49:33.843754 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3358, length 64 11:49:34.843745 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3359, length 64 11:49:34.843768 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3359, length 64 11:49:35.843841 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3360, length 64 11:49:35.843869 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3360, length 64 tcpdump -i bond0 -n -e -p src 13.10.12.102 or dst 13.10.12.102 11:49:32.843713 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3357, length 64 11:49:32.843747 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3357, length 64 11:49:33.843724 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3358, length 64 11:49:33.843757 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3358, length 64 11:49:34.843738 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3359, length 64 11:49:34.843771 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3359, length 64 11:49:35.843834 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1e, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3360, length 64 11:49:35.843873 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3360, length 64 tcpdump -i eth1 -n -e -p src 13.10.12.102 or dst 13.10.12.102 11:49:32.843752 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3357, length 64 11:49:33.843762 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3358, length 64 11:49:34.843776 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3359, length 64 11:49:35.843878 ac:1f:6b:12:4c:1e > 0c:c4:7a:c1:64:3a, ethertype IPv4 (0x0800), length 98: 13.10.12.26 > 13.10.12.102: ICMP echo reply, id 4921, seq 3360, length 64 tcpdump -i eth2 -n -e -p src 13.10.12.102 or dst 13.10.12.102 11:49:32.843703 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1f, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3357, length 64 11:49:33.843717 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1f, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3358, length 64 11:49:34.843730 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1f, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3359, length 64 11:49:35.843828 0c:c4:7a:c1:64:3a > ac:1f:6b:12:4c:1f, ethertype IPv4 (0x0800), length 98: 13.10.12.102 > 13.10.12.26: ICMP echo request, id 4921, seq 3360, length 64 At 2018-04-29 03:01:53, "Ben Pfaff" <[email protected]> wrote: >On Fri, Apr 27, 2018 at 11:44:46AM +0800, netsurfed wrote: >> There is a "balance-alb" bond0 in my linux host, like this: >> >> >> Can I add this as a port to ovs bridge? like this: >> ovs-vsctl add-br ovsbr0 >> ovs-vsctl add-port ovsbr0 bond0 >> >> >> I know ovs can create bond using "ovs-vsctl add-bond BRIDGE PORT IFACE...". >> However, that requires removing the original bond first. I don't want to do >> that. > >Usually it works fine to add a Linux bond to an OVS bridge.
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
