[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@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
