Connect MidoNet virtual bridges and routers to physical L2 segments where VLAN tags are widely used to provide L2 isolation in the cloud. In addition to this, this should at least provide a failover capability with 2 virtual ports which could be bound with ports on different hosts.
The Bridge interior port has an optional property vlan_id used to
connect a Vlan-Aware bridge to a Vlan-Unaware bridge. Bridge exterior
ports are used as Trunks. Also, the API now allows connecting interior
bridge ports, as long as one of the two has a "vlan-id" tag in it.
The Bridge will keep all it's previous behaviour and perform MAC learning. The pressence of vlan-ids in frames will imply the following changes:
- FloodBridge actions will include the interior port tagged with the frame's vlan-id (if exists). The frame going into the interior port will also get the vlan-id POP'd.
- For Frames with a vlan-tag, the Bridge will require that the port matched in the MAC table matches the port that is tagged with the frame's vlan-id. Otherwise, it'll drop the frame.
Again, the multicast on a Vlan-Aware Bridge case requires the usage of the ForkAction (the simulation results in a FloodBridge, plus a ToPort towards the VUB). This is similar to the case described above (a multicast at the VUB), however, in that case the PacketContext's match is modified removing the vlan-id as a result of the second simulation in the VAB. But here, the PacketContext modification happens on the first simulation (the VAB is responsible to POP the vlan) so the Coordinator would apply the FlowActionPopVLAN before the frame floods the Bridge (through the trunks). Which is incorrect. This must happen only after the FloodBridge is processed.
Note that during loops it's likely that frames may bounce back from the physical switch into Midolman, causing conflicting mac-port mappings. As a consequence of this, frames ingressing from one port may be forwarded back to the same port after mac-learning. Midolman will detect this case and create a temporary drop, giving time for the network to stabilize the mac on a given port.
Supporting multicast from VUB's connected to a VAB required an additional change in the Coordinator. Note that in a typical topology, a VUB linked to a bunch of VMs will be connected to a single VAB. A multicast frame (e.g.: an ARP request from a VM) will need to flood the frame on its exterior ports, but also to the VAB in order to create L2 connectivity towards the trunks. This is achieved by generating a new type of action ForkAction, that contains a list of actions to be executed sequentially: FloodBridge (locally on the VUB) and a ToPort (towards the VAB).
Note also that after the second simulation is executed on the VAB, it will result in a second FloodBridge on the VAB (sending to all the trunks), that will include a PUSH VLAN action. This has implications on the Flow that should result from the simulation since we'll need to ensure that the output actions to the ports connected to the VUB is made before the PUSH VLAN action. The output actions to the VAB trunks should happen after the PUSH is executed.
This behaviour on the flood of a VLAN tagged frame on a VAB required further changes in the ForkAction, implemented with a new type of action: DoFlowAction. When the VAB simulates the multicast, it'll return a ForkAction containing -in this order- a FloodBridgeAction, a DoFlowAction(FlowActionPopVLAN), and a ToPortAction. When the Coordinator processes the DoFlowAction it'll add an AddVirtualWildcardFlow to the list of results from each part of the fork in the right orden, and also modify the FlowMatch in the PacketContext so that the second simulation (on the VUB) doesn't see the VLAN id in the match. When the results are merged, the output on the VAB's trunk retains the VLAN id, but the outputs generated by the VUB won't.