Jump to: navigation, search

Difference between revisions of "TricircleDiscuzZone"

(VxLAN L2 networking across Neutron)
Line 2: Line 2:
  
 
=== JunSik experiment ===
 
=== JunSik experiment ===
 
+
For the automation of VXLAN networking in Multi-region OpenStack, we configure virtual network inside a server as shown in the below picture.
+
wait for Junsik's confirmation whether it's ok to publish it.
<br />
 
[[File:Junsik-experiment.png|frameless|center|x400px|Junsik-experiment]]
 
<br />
 
 
 
To connect Multi-region OpenStack instances, I add an additional bridge named "br-cap" and configure tunnel ports on the bridge. And the bridge "br-cap" is controlled by ONOS SDN controller.
 
To automate the configuration, I introduced a concept of template-based automation . I defined a self-defined template format to describe virtual network topology over multiple servers.
 
Then my tool automates the configuration of OVS bridges and VXLAN ports via OVSDB protocol, and calls ONOS APIs to down OpenFlow rules to "br-cap" bridges.
 
As the basic flow rules, we just set broadcast flow rules not fine-grained flow rules. For example, a packet arrives br-cap from br-int, then "br-cap" broadcast the packet to all tunnels.
 
  
 
=== tunnel termination point as part of the binding details  ===
 
=== tunnel termination point as part of the binding details  ===

Revision as of 01:12, 15 December 2016

VxLAN L2 networking across Neutron

JunSik experiment

wait for Junsik's confirmation whether it's ok to publish it.

tunnel termination point as part of the binding details

Kevin recap for the Barcelona design summit session: http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html

L2pop calculates information on the fly to determine tunnel termination endpoints. This is racey (out of order tunnel notifications are not handled) and leads to lots of complexity involving lookups to agent tables, etc. This also makes it very difficult to integrate external devices because they have no way of informing the agents of their tunnel termination endpoint.

We'd like to formalize the tunnel termination point by adding it to the port binding data model just like other encapsulation details (bound segment, segmentation id, etc). This will allow mech drivers to bind ports not based on agents and allow seamless integration with agent-based ports. The L2pop server-side logic would go away since agents would setup forwarding entries just based on the latest data on the port models delivered via push notifications.

This will require some changes on the server side in the port binding process to have the mech drivers provide the tunnel termination point as part of the binding details. The agent side will also require a few changes to have its tunnel forming logic be derived from push notifications instead of tunnel and fdb notifications.