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 19 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. For the subnet gateway and DHCP server, it replies with pre-defined fake MAC address.

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)

Forwards ARP and DHCP to controller and tags src VNI to packets based on in-port of a packet. There is one VM at port 3 in the following example.

priority=40000,arp actions=CONTROLLER:65535,clear_actions
priority=40000,udp,tp_src=68,tp_dst=67 actions=CONTROLLER:65535,clear_actions
priority=30000,ip,in_port=3 actions=set_field:0x3f->tun_id,goto_table:1
priority=0 actions=goto_table:1

ACL Table(table=1)

Forwards only allowed packets to the next table based on security group configurations. 192.168.0.3 and 192.168.1.3 are allowed to access each other in the following example.

priority=30000,ip,nw_src=192.168.0.3,nw_dst=192.168.1.3 actions=goto_table:2
priority=30000,ip,nw_src=192.168.1.3,nw_dst=192.168.0.3 actions=goto_table:2
priority=0 actions=drop

Jump Table(table=2)

Forwards routing packet, which is identified by its destination MAC address of pre-defined one, to routing table, and switching packet to switching table.

priority=30000,dl_dst=fe:00:00:00:00:02 actions=goto_table:3
priority=0 actions=goto_table:4

Routing Table(table=3)

Forwards East-West routing packets to the switching table and North-South packets to a gateway group. For the first two rules in the following example are for allowing a VM to access to its subnet gateway, which are added when the subnet is added to a Neutron router. The last two rules are for allowing external access, which are added when an external gateway is set to the router. The rules in the middle are for East-West routing.

priority=28000,ip,tun_id=0x3f,nw_src=192.168.0.0/24,nw_dst=192.168.0.0/24 actions=set_field:0x3f->tun_id,goto_table:4
priority=28000,ip,tun_id=0x26,nw_src=192.168.1.0/24,nw_dst=192.168.1.0/24 actions=set_field:0x26->tun_id,goto_table:4
priority=28000,ip,tun_id=0x3f,nw_src=192.168.0.0/24,nw_dst=192.168.1.0/24 actions=set_field:0x26->tun_id,goto_table:4
priority=28000,ip,tun_id=0x26,nw_src=192.168.0.0/24,nw_dst=192.168.1.0/24 actions=set_field:0x26->tun_id,goto_table:4
priority=28000,ip,tun_id=0x26,nw_src=192.168.1.0/24,nw_dst=192.168.0.0/24 actions=set_field:0x3f->tun_id,goto_table:4
priority=28000,ip,tun_id=0x3f,nw_src=192.168.1.0/24,nw_dst=192.168.0.0/24 actions=set_field:0x3f->tun_id,goto_table:4
priority=25000,ip,tun_id=0x26,dl_dst=fe:00:00:00:00:02,nw_src=192.168.1.0/24 actions=group:2901605683
priority=25000,ip,tun_id=0x3f,dl_dst=fe:00:00:00:00:02,nw_src=192.168.0.0/24 actions=group:2901605683

Switching Table(table=4)

Forwards packets to final destination. If the location of the destination is not the local machine, take it to the vxlan port. If the destination is a subnet gateway, take it to the gateway node group.

priority=30000,ip,tun_id=0x3f,nw_dst=192.168.0.3 actions=set_field:fa:16:3e:2a:85:30->eth_dst,output:3
priority=30000,ip,tun_id=0x26,nw_dst=192.168.1.3 actions=set_field:10.1.1.163->tun_dst,output:1
priority=30000,ip,tun_id=0x3f,nw_dst=192.168.0.1 actions=group:2901605683
priority=30000,ip,tun_id=0x26,nw_dst=192.168.1.1 actions=group:2901605683

Group table 

Group table for gateway node group.

OFPST_GROUP_DESC reply (OF1.3) (xid=0x2):
 group_id=2901605683,type=select,bucket=actions=set_field:10.1.1.165->tun_dst,output:1

 

 

  • No labels