[ovs-dev] OVN - L3 Design

Han Zhou zhouhan at gmail.com
Thu Aug 27 19:40:06 UTC 2015


Hi,

I love Gal's idea of having IP field, which make it possible for a
pure L3 overlay (i.e. no L2 header encapsulated), with the help of ARP
responders on each transport node.
It would be efficient in cloud env where L3 is sufficient.

Han

On Tue, Jul 14, 2015 at 9:08 PM, Gal Sagie <gal.sagie at gmail.com> wrote:
> This is just an example of a basic L3 design and where it needs the IP:
>
> 1) Traffic is sent to the default gw (logical router) (L2) (every metadata
> (logical switch) has a default flow that
>     identifies the router default gw)
>
> Since i assume we going to implement *distributed virtual routing*:
> 2) At each compute host there are flows representing every logical switch
> (network) connected to this logical router
>     Can logical router be connected to a logical router? i think not as it
> makes things complicated so lets assume the way
> to connect two routers is by a logical switch
>
> 3) We identified the "leg" of the router the traffic needs to be sent
>
> 4) Then the src MAC needs to be changed to the router mac (open flow action)
>
> In this step we need to know how to translate the DST ip to the correct
> mac, so its either ARP responders (which needs IP per lport)
> or something that can inject ARP requests and wait for replies (so we need
> a network stack)
>
> I believe we have to know the mapping between lports and their IP's.
> If we do, the entire above process might not be needed as we potentially
> could know the destination very quickly
> (But its a bit complicated to implement in a fully proactive approach as we
> need to consider the logical
> network topology and overlapping IP's)
>
> Hope it somehow make sense, i wrote it too fast
>
>
> On Wed, Jul 15, 2015 at 6:38 AM, Gal Sagie <gal.sagie at gmail.com> wrote:
>
>> Thanks for taking care of the first item.
>>
>> For the second, it depends and has two uses i could think of:
>>
>> 1) For port security, as discussed in another thread we will need to add
>> the mac-ip pairs, but this of course
>>     can be resolved by adding this to the port_security field.
>>
>> 2) To construct the L3 pipeline, you will need to understand to which
>> chassis/port to send a L3 traffic somehow.
>>      and for that you will need the mapping between the lport and ip
>>     (Of course that depends on the L3 design, but i really wonder how to
>> do it otherwise)
>>
>> On Wed, Jul 15, 2015 at 12:52 AM, Ben Pfaff <blp at nicira.com> wrote:
>>
>>> On Wed, Jul 08, 2015 at 04:23:09PM +0300, Gal Sagie wrote:
>>> > First, i think everyone would love to hear if there are any plans or any
>>> > first ideas
>>> > regarding the L3 design.
>>> >
>>> > Second, i would like to talk about what currently is available in the
>>> > schema and how it differs
>>> > from Openstack Neutron.
>>> >
>>> > 1. The logical router port has no interface IP, from the description i
>>> > understand that the
>>> >     'network' is meant to describe the entire subnet range but we still
>>> > need an IP that is used
>>> >     as the default gateway of the logical switch (or network in terms of
>>> > neutron)
>>> >     (This IP is configurable in Neutron)
>>>
>>> This does seem like an omission.  I'll send a patch.
>>>
>>> > 2. Currently there is no IP information for logical ports in the NB
>>> schema
>>>
>>> Is it useful?
>>>
>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>
>
>
> --
> Best Regards ,
>
> The G.
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list