[ovs-dev] [patch_v2 1/3] ovn: Skip logical switch "router type" port arp responder install.
dlu998 at gmail.com
Wed Oct 5 01:19:32 UTC 2016
On Tue, Oct 4, 2016 at 5:33 PM, Mickey Spiegel <mickeys.dev at gmail.com>
> 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>
>>> 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
>>>> to itself" rather than some logical switch proxying that.
>>> I don't think this is a layering violation. You are objecting to an ARP
>>> being generated by the switch on a port far away from the actual
>>> 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.
I think you got the point - presumably one should inherit from the other.
> This has implications for cases where an IP address is shared by several
>>>> 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
>>> 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
>>> 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
> IPAM, DHCP,
> 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.
An IP address explicitly configured/exposed on a logical switch port rather
than just a
logical router port is strange. A hidden implementation inheritance for
this part would have been
> 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
>> the master of its own arp responder including early usage and making that
>> 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.
Hence, my earlier comment.
>>> 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
>>> 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