[ovs-dev] OVN: Guest VLAN Tagging proposal

Ankur Sharma ankur.sharma at nutanix.com
Tue Aug 13 02:28:07 UTC 2019


Gentle reminder.

From: Ankur Sharma
Sent: Tuesday, August 6, 2019 3:33 PM
To: ovs-dev at openvswitch.org <ovs-dev at openvswitch.org>
Subject: OVN: Guest VLAN Tagging proposal


OVN does not provide support for guest vlan tagging, i.e where a VIF can vlan tag the packets.
         a. This feature can also be addressed as Trunking support as well (from logical switch port perspective).
         b. Main use case would be scenarios like Nested hypervisors.

Leverage on the "container inside VM" support that OVN has already.
i.e following will be done:

a. For each "allowed" tagged vlan we will create a logical switch port and add it to the corresponding (based on allowed vlan id) logical switch.

b. These logical switch ports share the same openflow port (the one to which VM is attached), and hence will have the VMs vif id as parent port.

c. For a packet coming from the VM, both OVS port id and tagged packet's vlan id will be used to determine packet's logical switch pipeline and corresponding logical ingress port.
    This will happen at OVS table=0.

d. Packet passes through rest of logical switch pipeline, like any regular packet.

e. Similarly, same packet can pass through logical router pipeline like a regular packet.

f. During egress in table=65, vlan header is added back and packet is directed to openflow port corresponding to logical egress port's parent.

GUEST VLAN TAGGING/TRUNKING SUPPORT IN OVN<https://docs.google.com/document/d/1SH0DaDGMi_Dknp0C5v4OvDNrZMAGIufylDTyQ7OPt9c/edit?usp=sharing>
GUEST VLAN TAGGING/TRUNKING SUPPORT IN OVN Drawings 1 Figure 1 1 Figure 2 2 Drawings Figure 1 Figure 2 \u000B Read vlan id from packet and do following: set metadata to corresponding logical switch pipeline. Strip vlan header. Packet enters logical router pipeline. Routed packet ent...

All the steps mentioned above are exactly what OVN does for containers inside VM scenario.

a. No code changes needed for packet flow mentioned above.
b. Documentation.
c. Unit tests/ovn-nbctl CLIs specific to guest vlan tagging/trunking.

a. Main limitation is that it would more work for CMS.
b. i.e for each allowed vlan id, CMS will have to create LSP on corresponding logical switch and mark the VIF port as parent.
c. Deployments where there are multiple logical switches with same vlan id, CMS would have to take LS name as input from the user.

Main benefit is that logical router can be used without requiring any changes/workarounds to its pipeline.

Please let me concerns/feedback on the proposal.



More information about the dev mailing list