[ovs-dev] [patch_v2 1/3] ovn: Skip logical switch "router type" port arp responder install.

Mickey Spiegel mickeys.dev at gmail.com
Wed Oct 5 00:33:52 UTC 2016

On Tue, Oct 4, 2016 at 4:53 PM, Darrell Ball <dlu998 at gmail.com> wrote:

> On Tue, Oct 4, 2016 at 3:48 PM, Mickey Spiegel <mickeys.dev at gmail.com>
> wrote:
>> On Mon, Oct 3, 2016 at 2:21 PM, Darrell Ball <dlu998 at gmail.com> wrote:

>>> I think you missed the main aspect.
>>> There is a layering violation in doing this and also a modeling issue.
>>> The key idea can be summarized as "A logical router should respond to
>>> arps
>>> to itself" rather than some logical switch proxying that.
>> I don't think this is a layering violation. You are objecting to an ARP
>> response
>> being generated by the switch on a port far away from the actual
>> destination
>> port.
>> Why is it so different whether the endpoint is a router or a VIF?
>> Both routers and VIFs can and do generate their own ARP responses, but
>> that does not rule out the optimization that responds to ARPs immediately
>> at the source switch port.
> I don't think we are going to agree on this one.
> Here we have a case where a logical switch is responding to arp requests
> on behalf
> of the logical router. Meaning these datapaths are not independent.
> We also have both logical switch ports and logical router ports sharing
> the same MAC
> and IP addresses. This apparently is what is done in Openstack.
> We have no test case where we really test this, as usual.
> Maybe you can add one.

I am not following this comment. Of course logical switch ports and
logical router ports share MAC addresses. They have to, or packets
with the destination MAC equal to the router MAC will never reach
the logical router port from the logical switch.

There was a choice in the modeling to specify addresses explicitly
on logical switch ports of type "router", rather than deriving them
from the corresponding logical router port. This puts an obligation
on the user to specify addresses on logical switch ports and the
corresponding logical router ports in ways that make sense. If this
is not configured correctly, then packets won't reach the logical
router port and the logical router port's MAC address will effectively
be unused.


This has implications for cases where an IP address is shared by several
>>> gateways
>>> and then the binding is used to designate the gateway used.
>>> If there are cases where an IP address can appear on the same network
>> with different MAC addresses, then you have a problem. We would need
>> to know more about this use case.
>> Note that you pretty much do have a knob already to control this behavior.
>> If the addresses specified on the switch's "router" type port are only
>> ethernet addresses, then the switch will not generate any ARP replies.
>> If the addresses specified on the switch's "router" type port include both
>> ethernet and IP addresses, then the switch will generate ARP replies for
>> each specified ethernet/IP address combination.
> Yeah, we can assign the same mac and ip to both logical switch and logical
> router ports.
> That is not what I mean about exposing the ability properly or modularity
> of datapaths.

The MAC addresses have to align or it does not work. From a quick scan of
the code,
it looks like the IP addresses on logical switch ports are only used for
and the logical switch ARP responder. At least at first glance, it does not
seem to make
sense to specify an IP address on the logical switch "router" port that is
not present on
the logical router itself. Whether all IP addresses on the logical router
port should be
specified on the logical switch "router" port, that depends on the
implications with
respect to IPAM, DHCP, and the logical switch ARP responder.

> The logical switch arp responder will make the logical router arp
> responder unused, as well.

For ARP from a switch port inside OVN, yes. For ARP from localnet or VTEP,
logical router ARP responder is necessary.

> What is mean by configuration knob is the logical router datapath code
> being
> the master of its own arp responder including early usage and making that
> transparent.
> Meaning, the proxying action in code is initiated from the logical router
> datapath under the
> control of an external knob
> That is not the case today.
> As I mentioned above, the logical router is not master of all relevant
today, in particular requiring corresponding logical switch "router" port
to be configured in a way that matches the logical router configuration. I
how important it is to address this knob in particular.

>> The only other place where it looks like a switch port IP address is used
>> is for IPAM and DCHP. I did not look into this in any more detail, so I am
>> not sure of all the implications of leaving out the IP addresses from the
>> switch "router" type port.

Most of the documentation patch looks good, modulo resolution of skipping
ARP responder for "router" ports.


More information about the dev mailing list