Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Background

EVE supports access VLANs for application instances connected to switch network instances. Virtual interfaces (vifs) corresponding to different applications (attached to the same switch network instance) can be made part of different VLANs with this feature. Access port VLAN support is specified in EVE VLAN support - switch network instances 

This document describes the more complex part which includes using VLANs (and/or Link Aggregation Groups (LAGs), aka “bonds”) for EVE management traffic and for local network interfaces.

Use cases

We want to structure things so that both EVE management traffic and the app instances can access VLANs, LAGs, and VLANs over LAGs. The VLANs and LAGs part of the picture are new, but the other parts are existing. (We might have confusion and bugs due to the common practise of the name of the system adapter, logical label, phylabel, and Linux ifname being identical in most deployments and models.)

...

NOTE:  There are many types of bond interfaces that linux bonding modules support. There are certain types of bond interfaces that will need the upstream network equipment (switch or router) to be configured with corresponding configuration eg: 802.3ad with Link Aggregation Control Protocol (LACP).
And there are other types of bond interfaces that will not need any upstream network equipment configuration eg: active-backup mode, adaptive load balancing mode, etc.
At this point it is not clear what type of bonding interfaces customers might ask for in the future. Within the scope of this document we define placeholder API definitions for bond interfaces and represent how bonds will look in the bigger picture, but not discuss any implementation specific details.



















Object Model

Today’s object model has two layers, and we will discuss a new intermediate layer below: 

...

Current device model has an ioMemberList that describes the various physical IO interfaces present on the device. Two additional lists - vlanAdapters list, bondGroups bondAdapters list will be included in the device model to describe the vlan adapters and bond groups LAGs respectively. Though there are different types of IO adapters like USB, ethernet audio etc, the sample device model  below only shows IO adapters of type ethernet for brevity.

The model file below contains the newly added vlanAdapters list and bondGroups bondAdapters list along with the existing ioMemberList. Each vlan adapter in the vlanAdapters list has a name (typically reflects the lower layer adapter name and vlan id), lowerLayerName (name of the unerlying underlying physical adapter) and vlan id. Similarly each of the bondGroups bondAdapters list entries has a name field, lowerLayerAdapters list (list of underlying member physical IO adapters) and bond parameters. The example model file below shows three Vlan adapters, the first two of them has a physical IO adapter as parent and the third with a bond interface as it’s parent adapter. The bond interface in the example below splices two physical IO adapters (eth2, eth3) into a bond.

...

Code Block
{
   "arch":2,
   "attr":{
      "memory":"4G",
      "storage":"30G",
      "Cpus":"4",
      "hsm":"2",
      "leds":"0",
      "watchdog":"true"
   },
   "vlanAdapters":[
      {
         "name":"eth1.100",
         "lowerLayerName":"eth1",
         "vlan_id":100
      },
      {
         "name":"shopfloor",
         "lowerLayerName":"eth1",
         "vlan_id":200
      },
      {
         "name":"bond0.100",
         "lowerLayerName":"bond0",
         "vlan_id":100
      }
   ],
   "bondGroupsbondAdapters":[
      {
         "name":"bond0",
         "lowerLayerAdapters":[
            "eth2",
            "eth3"
         ],
         "bondParams":{
            
         }
      }
   ],
   "ioMemberList":[
      {
         "ztype":1,
         "phylabel":"eth0",
         "usage":1,
         "assigngrp":"eth0",
         "phyaddrs":{
            "Ifname":"eth0",
            "PciLong":"0000:02:00.0"
         },
         "logicallabel":"eth0",
         "cost":0,
         "usagePolicy":{
            
         }
      },
      {
         "ztype":1,
         "phylabel":"eth1",
         "assigngrp":"eth1",
         "phyaddrs":{
            "Ifname":"eth1",
            "PciLong":"0000:03:00.0"
         },
         "logicallabel":"eth1",
         "cost":0,
         "usagePolicy":{
            
         }
      },
      {
         "ztype":1,
         "phylabel":"eth2",
         "assigngrp":"eth2",
         "phyaddrs":{
            "Ifname":"eth2",
            "PciLong":"0000:04:00.0"
         },
         "logicallabel":"eth2",
         "cost":0,
         "usagePolicy":{
            
         }
      },
      {
         "ztype":1,
         "phylabel":"eth3",
         "assigngrp":"eth3",
         "phyaddrs":{
            "Ifname":"eth3",
            "PciLong":"0000:05:00.0"
         },
         "logicallabel":"eth3",
         "cost":0,
         "usagePolicy":{
            
         }
      }
   ]
}


Example realization in the EVE API

New vlan adapter proto message:

Code Block
languagejs
message VlanAdapter {
	string name = 1;             // name of this VLAN adapter
	string lower_layer_name = 2; // name of the lower layer adapter bond/physicalIO
	uint16 vlan_id = 3;          // VLAN ID
}


New bond group adapter proto message:


Code Block
languagejs
message BondGroupBondAdapter {
	string bond_name = 1;       			  // name of this bond groupadapter
	repeated string lower_layer_adapters = 2; // list of PhysicalIO adapter logical names
	// Add bond parameters below.
}

...

Code Block
languagejs
message EdgeDevConfig {
+ 	repeated VlanAdapter vlanListvlans = 30;
+ 	repeated BondGroupBondAdapter bondListbonds = 31;
}


VlanAdapter and BondGroup BondAdapter messages together comprise the System Adapter L2 layer sandwiched between the SystemAdapter layer and the PhysicalIO layer.

Edge node configuration (config.EdgeDevConfig) will have two additional lists (vlanAdapters listvlans, bondGroups listbonds) in addition to the existing SystemAdapterList and DeviceIoList. The cloud controller shall have an indication flag in config.PhysicalIO that tells edges nodes and user agents that a particular physical IO adapter is either a parent of vlan adapters or is part of another bond adapter.

...

The pictures below show examples for vlan adapter and bond group adapter lists that will be part of EdgeDevConfig.

...

Code Block
EdgeDevConfig {
	...
	...
	SystemAdapterList: [
		SystemAdapter: {
			...
			Name: "eth0",
			NetworkUUID: "xyx", // UUID corresponding to net0 above
			LowerLayerName: "eth0",
			Cost: 0,
			...
		},
		SystemAdapter: {
			...
			Name: "eth1.100",
			NetworkUUID: "123", // UUID corresponding to net1 above
			LowerLayerName: "eth1.100",
			Cost: 0,
			...
		},
		SystemAdapter: {
			...
			Name: "shopfloor",
			NetworkUUID: "321", // UUID corresponding to net2 above
			LowerLayerName: "eth1shopfloor",
			Cost: 0,
			...
		},
		SystemAdapter: {
			...
			Name: "bond0.100",
			NetworkUUID: "abc", // UUID corresponding to net3 above
			LowerLayerName: "bond0.100",
			Cost: 0,
			...
		},
	],
	VlanList: [
		VlanAdapter: {
			Name: "eth1.100",
			LowerLayerName: "eth1",
			VlanId: 100
		},
		VlanAdapter: {
			Name: "shopfloor",
			LowerLayerName: "eth1",
			VlanId: 200
		},
		VlanAdapter: {
			Name: "bond0.100",
			LowerLayerName: "bond0",
			VlanId: 100
		}
	],
	BondList: [
		BondName: "bond0",
		LowerLayerAdapters: ["eth2", "eth3"],
		BondParams: {}
	],
	DeviceIoList: [
		PhysicalIO {
			...
			PhyLabel: "eth0",
			LogicalName: "eth0",
			LogicalType: LOGICAL_LINK_TYPE_NONE,
			...
		},
		PhysicalIO {
			...
			PhyLabel: "eth1",
			LogicalName: "eth1",
			LogicalType: LOGICAL_LINK_TYPE_VLANS,
			...
		},
		PhysicalIO {
			...
			PhyLabel: "eth2",
			LogicalName: "eth2",
			LogicalType: LOGICAL_LINK_TYPE_BONDS,
			...
		},
		PhysicalIO {
			...
			PhyLabel: "eth3",
			LogicalName: "eth3",
			LogicalType: LOGICAL_LINK_TYPE_BONDS,
			...
		}
	]
}

...