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
