On Wed, Jun 8, 2016 at 6:38 AM, Flaviof <fla...@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. > 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. > > * 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@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@router-node ~]$ sudo tcpdump -n -e -i eth2 -vvv & > > tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size > 65535 bytes > > > [vagrant@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@router-node ~]$ > > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
