[ovs-dev] VLAN tenant network patches

[Mark Michelson]

Thanks for the summary Guru. I have one question down below.

On 11/09/2018 02:45 PM, Guru Shetty wrote:
> I have tried to summarize the problem statement that Numan and Ankur are
> trying to solve here based on my understanding so far. Please correct me
> and I will revise it along.
> 
> Current feature set in OVN.
> ==========================
> 
> A logical switch should only have one localnet logical port. If a logical
> switch has a logical port of type "localnet",then all traffic for that
> logical switch avoids overlays. So in essence, this is only useful when all
> the hypervisors are in the same broadcast domain.  Currently there are no
> known problems as long as logical switches are not connected to any logical
> routers.
> 
> 
> When 2 logical switches (each with a localnet port) is connected to a
> logical router, we still push all east-west traffic to the underlay. The
> source hypervisor executes the pipeline of all 3 logical datapaths and then
> pushes the traffic to the underlay via the localnet port (with its
> corresponding vlan tag) of third logical switch.
> 
> The above topology creates a problem for the underlying hardware switch.
> Because now it can see the same mac address of the distributed router
> coming from 2 different hypervisors as a source mac address of the packet
> on wire. According to Ankur, there are physical switches which can detect
> source mac address coming from differnet ports and limit it. But this looks
> like it is configurable in physical switches.
> 
> 
> For N/S traffic, currently traffic is punted to gateway chassis via a
> overlay tunnel. There is a use case where you want to avoid overlay
> tunnels. This is because for "localnet" topology you can keep the the MTU
> of inner VM to be the same as underlay MTU. But when you have overlays just
> for one class of traffic, this becomes a problem.
> 
> So both Ankur's and Numan's patches tries to tackle the above 2 problems.
> 
> To re-summarize
> Problem 1: External switch getting confused about the machine on which OVN
> router mac address resides. But this is only source mac address coming from
> different hypervisors (not destination mac).
> 
> Problem 2: When packet has destination IP address outside OVN router known
> subnets, it is being currently sent via overlay tunnel. This would need MTU
> configuration for inner VMs.
> 
> Numans patch:
> ============
> 
> Numans patches tries to solve the above 2 problems by doing the following.
> 1. When VM-A (on Hyp-A) in switch-A tries to talk to VM-B in switch-B
> (Hyp-B) (switch-A and switch-B are connected with router), Hyp-A will
> execute switch-A pipeline and push the traffic out of localnet port with
> router's mac address as destination.
> 2. Router chassis will receive the packet, execute switch-A pipleline
> again, router pipeline and then switch-B pipeline and push packet out of
> switch-B's localnet port.  Now Hyp-B receives the traffic, executes
> switch-B pipeline again and packet gets delivered.
> 
> The result is that all east west traffic is centralized and has an extra
> hop.
> 
> 
> Ankur's proposal:
> ==============
> 
> Though the complete patches do not exist, Ankur wants to solve the problem
> 1 by having a chassis specific MAC. So when packet leaves a hypervisor for
> east-west routing, it uses a unique mac. The disadvantage with this
> proposal is that the VM (i.e logical port) will see the mac of its first
> hop router change continuously which may have some yet to be clearly
> defined side-effects (leads to more ARP requests from the VM).

I'm having trouble understanding this. Can you elaborate a little bit? 
Is this not a problem with the current implementation too?

> 
> Problem 2 is solved similar to what Numan has in patches, although there
> are small changes in implementation. It is not clear whether one code is
> more complicated than other. But it looks like Ankur’s patches will avoid
> the extra hop for east-west traffic.
> 
> Numan is perfectly fine with Ankur’s patches (after it is sent, reviewed
> and tested) if they satisfy his problem statements. But he does prefer his
> patches reviewed and merged if there is delay in Ankur's patches (and
> possibly reverted later, if there is an alternative).
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>