Difference between revisions of "File:BP ML2 MD.pdf"

Latest revision as of 18:50, 4 April 2014

Cisco DFA mechanism driver sends information to DCNM (Data Center Network Management) when a network is created/updated/deleted. It also sends information related to network and instance to an external process running VDP which is used to communicate to the DFA fabric edge switch, when an instance is created/deleted.

This is for topologes where Openstack compute nodes are connected to the external switches or fabrics. The fabric comprising of the switches support more than 4K segments. In some of these architectures network based overlay (and not host based overlay) is deployed. So, one should be able to create more than 4K networks in Openstack. But, the VLAN to be used for communication with the switches is assigned by the switches using 802.1QBG (VDP) protocol. The VM's sends .1q frames to the switches and the switches associate it to the segment (VNI in case of VXLAN). With the current model: 1. One cannot use a type driver of VLAN because of the 4K limitation. Also a type driver of VXLAN or GRE cannot be used because that may mean host based overlay. 2. Also the programming of flows should be done after communicating the vNIC information to lldpad and lldpad communicates with the leaf switches and return the VLAN to be used by this VM. The Openstack module running in the compute communicate with VDP module (Opensource lldpad) running there. The VLAN is of local significance between the compute node and the switch to which it is connected.

In order to achieve this, an integrated functionality is required. The type driver can still be Tunnel. But, we need extra configuration parameters as below: HOST_OVERLAY=True/False /* By default this will be True retaining the existing behavior */ 802_1_QBG_VDP=True/False /* By default this will be False retaining the existing behavior */

When Host Overlay is set to False, then changes need to be done in ovs_neutron_agent code to not create the br-tun bridge. When VDP Parameter is set to True, the add_flow should not create the flow for VLAN translation. Rather flow should be created where communication with LLDPAD happens and VLAN is retrieved. Additionally, more VDP configuration parameters will be defined for the protocol like the Manager ID, VSI Type etc.

File history

Click on a date/time to view the file as it appeared at that time.

	Date/Time	Dimensions	User	Comment
current	18:49, 4 April 2014	(20 KB)	Nlahouti (talk \| contribs)

You cannot overwrite this file.

File usage

There are no pages that link to this file.

@@ Line 1: / Line 1: @@
+Cisco DFA mechanism driver sends information to DCNM (Data Center Network Management) when a network is created/updated/deleted. It also sends information related to network and instance to an external process running VDP which is used to communicate to the DFA fabric edge switch, when an instance is created/deleted.
+This is for topologes where Openstack compute nodes are connected to the external switches or fabrics. The fabric comprising of the switches support more than 4K segments. In some of these architectures network based overlay (and not host based overlay) is deployed. So, one should be able to create more than 4K networks in Openstack. But, the VLAN to be used for communication with the switches is assigned by the switches using 802.1QBG (VDP) protocol. The VM's sends .1q frames to the switches and the switches associate it to the segment (VNI in case of VXLAN).
+With the current model:
+. One cannot use a type driver of VLAN because of the 4K limitation. Also a type driver of VXLAN or GRE cannot be used because that may mean host based overlay.
+. Also the programming of flows should be done after communicating the vNIC information to lldpad and lldpad communicates with the leaf switches and return the VLAN to be used by this VM. The Openstack module running in the compute communicate with VDP module (Opensource lldpad) running there. The VLAN is of local significance between the compute node and the switch to which it is connected.
+In order to achieve this, an integrated functionality is required. The type driver can still be Tunnel. But, we need extra configuration parameters as below:
+HOST_OVERLAY=True/False /* By default this will be True retaining the existing behavior */
+_1_QBG_VDP=True/False /* By default this will be False retaining the existing behavior */
+When Host Overlay is set to False, then changes need to be done in ovs_neutron_agent code to not create the br-tun bridge.
+When VDP Parameter is set to True, the add_flow should not create the flow for VLAN translation. Rather flow should be created where communication with LLDPAD happens and VLAN is retrieved. Additionally, more VDP configuration parameters will be defined for the protocol like the Manager ID, VSI Type etc.