Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »


Overall Architecture

Software Components

SONA is composed of three ONOS applications, openstackNode, openstackNetworking, and vRouter. In the current implementation, openstackNode and openstackNetworking run on a central ONOS, and vRouter runs on a separate ONOS at each gateway node due to the limitation of vRouter, which does not support multiple switches. Once the limitation is gone, all the applications could run on a single ONOS cluster.

OpenstackNode

OpenstackNode application is in charge of managing and bootstrapping compute and gateway nodes. The node bootstrap procedure includes the following steps. It leverages OVSDB to configure OVS on a node. 

  • Connect to OVSDB at each node
  • Create an integration bridge, typically “br-int”, and set its OpenFlow controller to ONOS cluster
  • Add VXLAN port to br-int with "flow" key and "flow" remote IP 
  • Add VLAN interface to br-int if specified

OpenstackNetworking

OpenstackNetworking application is in charge of managing virtual network states and providing a network connectivity to virtual machines by setting flow rules to compute and gateway node's OVS. As it plays a role of Neutron ML2 mechanism driver and L3 plugin backend, it exposes REST APIs that networking-onos(https://github.com/openstack/networking-onos) calls. More specifically, when a user (or Nova agent) requests a virtual network changes to OpenStack, the reqeust is post-commited to openstackNetworking app via networking-onos driver. When a port is added or removed to/from OVS, openstackNetworking app identifies the port by its port name, which includes port UUID, and then installs or removes flow rules based on the virtual network states related to the port including network, subnet, router and gateways. All kinds of East-West traffic is handled at compute nodes and only North-South traffic is forwarded to gateway nodes, which have an access to both internal and external network, and NATed there to public IP before leaving the virtual world. The application is also in charge of replying to ARP and DHCP requests from virtual machines.

vRouter

SONA makes use of vRouter application at gateway node for providing a network connectivity between SONA controlled virtual network and legacy external networks. For more details of vRouter and SDN-IP use cases, refer to SDN-IP this page. One notable thing here is that SONA allows more than one gateway nodes for load distribution and HA. As a gateway node does not keep any states locally, packets for a same session does not have to be handled in a same node. More specifically, 1:1 NAT rule for floating IP is installed proactively to all gateway nodes when floating IP is associated to fixed IP by user request. 1:n NAT rules are installed reactively when a gateway node receives unknown external packets. Gateway nodes are realized by OpenFlow select group at each compute node and all outbound packets are sent to this gateway node group indirectly instead of one particular gateway node directly. If there’s an outage of one gateway node, the node is automatically excluded from the group. Each gateway node establishes a peering with external router and the external router enables multi-path so that inbound traffic is distributed as well. Any gateway node fails to keep peering with the router is excluded from available routes.

SONA Pipeline

VNI table (table=0)

Tags src VNI to packets based on in-port of a packet.

table=0,ip,in_port=3,actions=set_field:0x402->tun_id,goto_table:1

ACL Table(table=1)

 cookie=0x390000bf93c83a, duration=429273.498s, table=1, n_packets=0, n_bytes=0, send_flow_rem priority=30000,ip,nw_src=192.168.0.6,nw_dst=192.168.1.7 actions=goto_table:2
 cookie=0x3900003eb6ef21, duration=429273.498s, table=1, n_packets=0, n_bytes=0, send_flow_rem priority=30000,ip,nw_src=192.168.1.7,nw_dst=192.168.0.6 actions=goto_table:2
 cookie=0x390000ac0dadb4, duration=429270.998s, table=1, n_packets=0, n_bytes=0, send_flow_rem priority=30000,ip,nw_src=192.168.0.5,nw_dst=192.168.0.6 actions=goto_table:2
 cookie=0x390000db9d08b2, duration=429270.998s, table=1, n_packets=0, n_bytes=0, send_flow_rem priority=30000,ip,nw_src=192.168.0.6,nw_dst=192.168.0.5 actions=goto_table:2
 cookie=0x6d00005e1912a6, duration=436423.951s, table=1, n_packets=263, n_bytes=23050, send_flow_rem priority=0 actions=drop

 

Filters out packets based on security group configuration.

 

  • ACL table
    - Flow rules for Security Group
    - Flow rules for Connection Tracking : due to the architecture of the OVS connection tracking feature the ACL should be located to prior to the switching tables.
  • Routing table
    - Check if routing is required by looking at the eth_dst. If not go to switching table.
    - Flow rules for routing between different subnets
    - Flow rules for external network connections, i.e rules to gateway nodes.
  • Switching table
    - Flow rules to forwarding packets to VM ports
    - Flow rules to forwarding packets to VxLAN tunnel port.



  • No labels