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 d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
