[ovs-discuss] ovn icmp reply part 2: how should it handle broadcast destination address?

[Flaviof]

[cc: Darrel, Ben, Justin]

Hi folks,

As a continuation of the topic on ICMP reply rules [ml], I could not help
but notice that in the logical flow, there is a match not only for the
logical routers's IP address but also for the L3 broadcast (op->bcast) of
the subnet [1]. So I -- the curious cat --  had to try it out. ;)

With the current implementation, the inport action behavior (at the logical
flow) is not enough when the L2 destination is broadcast. That is so
because in table 22 the rule will set register 7 to flood
(set_field:0xffff->reg7), which will consequently cause the ICMP reply to
go everywhere but to the logical port where the query came in (table 34).

With that, I would like to hear from you about the existing
requirements for the ICMP reply rule when dealing with the L3 broadcast
address. I see a few choices (not listed in any particular order):

* Choice A) leave it alone. Have the expectation that L2 destination is the
mac of the router interface, which will make the existing implementation do
the right thing;

* Choice B) just don't do it. :) Don't handle ICMP queries to the broadcast
L3 and keep logical flow simple. In other words, remove the match on L3
broadcast address from the logical rule [1]. This would also remove the
need for an action to set the ip4.src;

* Choice C) split the existing logical flow rule into 2. (R1) For cases
when L3 broadcast DA is matched, 1) add a clause that matches on the
inport where the router has that subnet and 2) overrides the eth.dest to be
the mac of the router interface. Adding the inport as part of (R1)
is important, because it would only make sense for that given L2 broadcast
domain; (R2) For cases when L3 is the actual IP address of the router,
remove the action to set the ip4.src, just as mentioned in choice B above.

Lastly, I wanted to point out that at from the L3 perspective, the code is
doing the right thing. The undesired behavior here is related to the fact
that when the sender uses broadcast L3 address, it normally accompanies
that with the broadcast L2 destination mac. And that is where "inport"
action is getting 'overruled'.

If I'm not being clear enough and/or a working example could be helpful in
demonstrating this topic, just let me know! I tried this example
using my Linux router VM [2] and it did not care to reply to that ping at
all (use case for option B).

Your valuable thoughts, please!

Thanks,

-- flaviof


[ml]: http://openvswitch.org/pipermail/discuss/2016-May/021172.html

[1]:
https://github.com/openvswitch/ovs/blob/59a0ef1dc329e7700e52f0e60b97b2822e28b2f5/ovn/northd/ovn-northd.c#L1962

[2]:
https://gist.githubusercontent.com/anonymous/a7344d6f98831f6645d5c0b31ec143f5/raw/8a05d6a4eb793f09ae26b1749dea23858082c398/gistify884622.txt

[vagrant at router-node ~]$ ip a s dev eth2

4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP qlen 1000

    link/ether 00:00:5e:00:01:02 brd ff:ff:ff:ff:ff:ff

    inet 192.168.111.254/24 brd 192.168.111.255 scope global eth2

    inet6 fe80::200:5eff:fe00:102/64 scope link

       valid_lft forever preferred_lft forever

[vagrant at router-node ~]$ sudo tcpdump -n -e -i eth2 -vvv &

tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535
bytes


[vagrant at router-node ~]$ sudo ping -b -c 3 -I eth2 192.168.111.255

WARNING: pinging broadcast address

PING 192.168.111.255 (192.168.111.255) from 192.168.111.254 eth2: 56(84)
bytes of data.

13:22:49.215001 00:00:5e:00:01:02 > Broadcast, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1),
length 84)

    192.168.111.254 > 192.168.111.255: ICMP echo request, id 57615, seq 1,
length 64

13:22:50.215250 00:00:5e:00:01:02 > Broadcast, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1),
length 84)

    192.168.111.254 > 192.168.111.255: ICMP echo request, id 57615, seq 2,
length 64

13:22:51.215212 00:00:5e:00:01:02 > Broadcast, ethertype IPv4 (0x0800),
length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1),
length 84)

    192.168.111.254 > 192.168.111.255: ICMP echo request, id 57615, seq 3,
length 64


--- 192.168.111.255 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 12003ms

[vagrant at router-node ~]$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160608/4514c666/attachment-0002.html>