On Wed, Oct 23, 2019 at 06:58:16PM +0200, Matteo Croce wrote: > On Wed, Oct 23, 2019 at 12:01 PM Simon Horman > <simon.hor...@netronome.com> wrote: > > > > On Mon, Oct 21, 2019 at 10:09:48PM +0200, Matteo Croce wrote: > > > The bonding uses the L4 ports to balance flows between slaves. > > > As the ICMP protocol has no ports, those packets are sent all to the > > > same device: > > > > > > # tcpdump -qltnni veth0 ip |sed 's/^/0: /' & > > > # tcpdump -qltnni veth1 ip |sed 's/^/1: /' & > > > # ping -qc1 192.168.0.2 > > > 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 315, seq 1, > > > length 64 > > > 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 315, seq 1, > > > length 64 > > > # ping -qc1 192.168.0.2 > > > 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 316, seq 1, > > > length 64 > > > 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 316, seq 1, > > > length 64 > > > # ping -qc1 192.168.0.2 > > > 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 317, seq 1, > > > length 64 > > > 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 317, seq 1, > > > length 64 > > > > > > But some ICMP packets have an Identifier field which is > > > used to match packets within sessions, let's use this value in the hash > > > function to balance these packets between bond slaves: > > > > > > # ping -qc1 192.168.0.2 > > > 0: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 303, seq 1, > > > length 64 > > > 0: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 303, seq 1, > > > length 64 > > > # ping -qc1 192.168.0.2 > > > 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 304, seq 1, > > > length 64 > > > 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 304, seq 1, > > > length 64 > > > > > > Signed-off-by: Matteo Croce <mcr...@redhat.com> > > > > I see where this patch is going but it is unclear to me what problem it is > > solving. I would expect ICMP traffic to be low volume and thus able to be > > handled by a single lower-device of a bond. > > > > ... > > Hi, > > The problem is not balancing the volume, even if it could increase due > to IoT devices pinging some well known DNS servers to check for > connection. > If a bonding slave is down, people using pings to check for > connectivity could fail to detect a broken link if all the packets are > sent to the alive link. > Anyway, although I didn't measure it, the computational overhead of > this changeset should be minimal, and only affect ICMP packets when > the ICMP dissector is used.
So the idea is that by using different id values ping could be used to probe all lower-devices of a bond? If so then I understand why you want this and have no particular objection.
