On Wed, Jun 8, 2016 at 2:10 PM, Darrell Ball <dlu...@gmail.com> wrote:
> > > 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. > > 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@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 & >> > should have been: sudo tcpdump -n -e -i lo -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 >> > 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@router-node ~]$ >> >> >> >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
