Join David Bombal for an in-depth discussion in this video Microsoft Skype SDN API: High availability of SDN controllers and applications, part of Practical Software-Defined Networking: 4 SDN and OpenFlow Applications.
- [Instructor] Now, in this topology, I'm running a team of controllers. So, there are three controllers controlling the two switches in the topology. Connecting to the console of the 3800 series switch, I can type show openflow instance vlan4, in this example. And I can see that I have three connections to three separate controllers with one of the controllers being the master controller and the other controllers being the slave controllers.
Now, in OpenFlow, the switch doesn't determine which controller is in charge of it. That is determined by the controller team. So, looking at the configuration of the switch, under openflow I have four controllers configured. But for this instance I'm only using three controllers. So, 21, with IP address 10.1.3.21. 22, the 22 controller. And 23 is the 23 controller.
I'm using OpenFlow 1.3 and I've set some parameters to increase the speed of failover between controllers. So, at the moment, through the controller configuration, I've determined that the primary controller's 10.1.3.21, and on the switch that is the master controller of the switch. In other words, the master controller is updating flow tables, whereas the slave controllers are just reading the flow tables.
Network Optimizer is installed and running on this team of controllers. And that provides redundancy. On one of the users I can make a call to the other user, answer the call, call is established, and when I refresh the information within Network Optimizer, I can see that call taking place. DSCP and CoS values are being written to the OpenFlow tables of the switches.
So, in OpenFlow Monitor, if I go to this switch, flows have been written to prioritize the voice traffic between the Lync clients. I'll end the call. Now, just to reiterate, the primary controller of this switch is 10.1.3.21. So, I'm gonna SSH to that controller and log in.
I'm gonna simulate a controller failure by stopping the service on the controller. At the moment in our team, all controllers are active and healthy. And this controller is currently the leader of the team. So, that controller is in charge. But I'm gonna type sudo service sdnc stop to stop the controller service. As we can see, there's a problem on the team. I'll refresh the browser.
And I need to log back in because the team leader has changed. In other words, the controller in charge of the team has changed. We can see that this controller is now unreachable. When I go to Team, we can see that controller is down, it's unreachable. And what's gonna happen now is the controller in charge of the switch will change to another controller. So, previously 21 was the master.
But if I type the command again, we can see that connection is disconnected. And 22 is now the master controller. So, another controller has become the master, or controlling, controller of this region of switches. Which in our example only contains a single switch. So, the 3800 is now being controlled by a separate controller as we can see here.
And that's this controller, 10.1.3.22. And that was determined by the configuration done on the team of controllers. Now, in Network Optimizer, this application has been written to handle a team of controllers. I'll make the call again. So, I'm making a call in this case from Mary to John.
I'll refresh Network Optimizer. And we can see that call made from Mary to John. We can see the DSCP values that have been written to the switch. And to confirm that, we'll look at the flows on that switch. And as an example, traffic from John to Mary, which is UDP traffic with these port numbers, in other words a Lync traffic, is gonna have the DSCP set to 46 and the CoS or PCP that's set to five.
Even though the controller went down, the network can function without any problems. I can end the call, refresh the session, and we can see the end call time. Lync, because it's been written to handle a controller failure, can continue working. I can start up the controller service on the controller that's down. Now, it'll take a while for that controller to join the team, but what we will see is we should see it going through different states such as initializing, and then it'll join the team.
On the 3800 series switch, at the moment that primary controller is still disconnected. The secondary controller is the master. But as it joins the team, that'll flip back. So, we can see the controller is initializing. While that's initializing, I can store my calls and continue without any problems.
There is no degradation in performance. So, within Lync. So, within Network Optimizer for Lync, the DSCP values and CoS values are still being set. You can see now that the status is active. The controller is now active and has joined the team. And the controlling controller has reverted back to 10.1.3.21. So, previously 22 was the master.
If I refresh that information on the switch I can see 21 is the master controller again. In other words, it's the controller that's gonna update the flow entries on the 3800 series switch. So, that's an example of a team of controllers. And Network Optimizer continuing to function even though a controller in the team goes down.
- Microsoft Skype SDN API
- HPE physical switch, OpenFlow tables, and wiretap tunnel
- OVSDB on Mininet
- DNS interception using OpenFlow
- Cisco SDN options
- Cisco APIC-EM path trace