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

Flaviof flavio at flaviof.com
Wed Jun 8 18:42:19 UTC 2016


On Wed, Jun 8, 2016 at 2:10 PM, Darrell Ball <dlu998 at gmail.com> wrote:

>
>
> On Wed, Jun 8, 2016 at 6:38 AM, Flaviof <flavio at flaviof.com> wrote:
>
>> [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].
>>
>
> It is common to not respond to directed broadcast by default and enable it
> only by configuration;
> adding configuration ability for this would be an added requirement with
> dubious value.
> The reasons are obviously related to DOS.
> It may be here by default for special and/or historical reasons in NSX or
> Openstack.
> Unless there is some "extra specialness" usage or above historical
> reasons, I would
> say the disadvantages outweigh the meager advantages of responding to
> directed broadcasts.
>
>

Make sense; and I agree. I'll propose the simplification in ovs-dev and
bring this up in the
OVN meeting tomorrow (Jun/9); to see if anybody has a diverging opinion
and/or suggestion.



> This would also remove the need for an action to set the ip4.src;
>>
>
> I think you still want to set the src IP in the icmp replies otherwise.
>
>
Heh, you are right. Somewhere the ip src and dest need to be reversed, so
duh... I think I missed that
important detail when looking at the rule. ;)


>
>
>
>
>>
>> * 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).
>>
>>
Just to be clear: in the example below [2] I should have used eth2 when
pinging from a outside my routerVm; and used loopback when pinging withing
the routerVm. Sorry for any confusion that may have caused. Still, the end
result did not change.

THANKS!

-- flaviof




> 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 &
>>
>
should have been:  sudo tcpdump -n -e -i lo -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
>>
> should have been:  sudo ping -b -c 3  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/a4dc0405/attachment-0002.html>


More information about the discuss mailing list