It has already been discussed that with SOS, special care must be taken to ensure the physical OpenFlow switch is able to perform layer 2 source and destination rewrite if SOS is to be deployed within a non-OpenFlow network with devices that conduct their own MAC learning. This is certainly a concern and something to watch out for, but OpenFlow setups are not immune to MAC learning issues either.
Many OpenFlow controllers implement some form of a device/host manager that learns de- vices that are connected to the OpenFlow network. Oftentimes, as is the case with the Floodlight controller, the device attachment points observed are used for controller-based learning switch im- plementations when inserting flows. Information such as device MAC address and VLAN (and sometimes IP address) are recorded, as would be the case for a traditional MAC learning implemen- tation on an Ethernet switch. If an OpenFlow network, such as an SOS deployment, is to operate on top of another network, such as on a campus or on the GENI network, then the controller might need to know about some characteristics of the network that have been or will be configured out of band from the OpenFlow controller.
VLAN translation is oftentimes used on local and perhaps more often on long-distance layer 2 links that traverse many networks under different administration. Translation is used when using the same VLAN tag across multiple networks is not feasible. If there are OpenFlow switches on each
end of a VLAN-translated link that are connected to an OpenFlow controller that is learning devices and/or implementing a learning switch algorithm, the controller might learn the device on multiple VLANs. Now, a single MAC address should not exist on multiple VLANs on a single network. As such, the controller will likely think the device is moving from say VLAN A on one side of the VLAN translated link to VLAN B on the other side of the link. In such a scenario, if the controller is not “told” about the VLAN translation or does not ignore VLAN tags when learning devices, device attachment point “flapping” might occur between both VLAN A and B. This can result in instability or inaccurate device information. It can also cause controller MAC learning algorithms to fail. The Floodlight controller has the ability for the user to configure what header fields should be used to define logical networks. The simple solution for SOS on the AL2S network where VLAN translation was used was for Floodlight to ignore VLAN tags when learning devices such as clients, servers, and SOS agents.
MAC learning can also become an issue when operating an SDN over top of a traditional network infrastructure. If the logical links between OpenFlow switches consist of non-SDN-enabled (i.e. traditional) forwarding devices, the SDN might need to be aware of this to avoid MAC learning issues. GC is implemented on top of the GENI infrastructure and uses stitched Ethernet links between GENI racks. A stitched Ethernet link is essentially a logical layer 2 link between two GENI racks, which may consist of multiple traditional forwarding device hops in the AL2S network. Stitching programs the traditional forwarding devices along the path of the stitched link, typically performing VLAN forwarding and/or translation where necessary to make the link appear as a layer 2 link between the devices reserved by the GENI experimenter at each rack. When deploying an SDN application with multiple stitched links, such as GC, the AL2S aggregate manager might allocate and reserve link paths through the same physcial forwarding devices. If the SDN application sends a packet with the same source MAC address along multiple stitched links that traverse at least one common forwarding device, that device’s MAC learning algorithm (if not disabled) will become “confused” after observing the given source MAC on more than one VLAN. The typical behavior of a traditional forwarding device when it sees the same MAC on mulitiple VLANs is to allow the MAC to “flap” a few times between the VLANs but if the “flapping” occurs too frequently, shut down all but one of the impacted VLANs. Such a feature is often referred to as loop protection. This problem occurred a few times in GC, since a video stream is flooded from an ingress VLC server to all subscribed egress VLC servers. The paths between the ingress and egress VLC servers
consisted of stitched links. The solution to the problem was to rewrite the source MAC addresses of the stream packets to some link-unique MAC address prior to sending the packet across a given stitched link. Without this workaround solution, stitched links will appear to randomly shut down and cease to forward GC traffic until a timeout of approximately 15 minutes occurred. This is simply another type of MAC learning issue that can occur when deploying SDN applications on a traditional underlay network. The problem and solution required a fundamental understanding of how the traditional networking and SDN elements worked together.