What is Switchboard?
Switchboard is a web application designed to allow researchers to quickly set up and tear down links across an SDN network that bypasses the core campus network — think of this as a high-speed expressway that you might take to avoid the congestion of downtown.
To do this, Switchboard allows authorized users to request links (routes) to be configured across an SDN network. Because links may cross administrative boundaries, Switchboard supports a simple workflow for approving link requests. After a given link request has been approved, Switchboard makes REST web services calls to an SDN controller running the RYU REST web services controller code to configure the SDN switches.
Switchboard is a user-facing service for researchers and others who are not SDN network experts that
- accepts users’ network configuration change requests
- routes the requests for authorization
- logs approvals of requests
- updates the configuration of the SDN network
- logs changes to the SDN network configuration
How does Switchboard work?
To properly authorize link requests, Switchboard maintains in it’s database, a map of users/groups who can authorize link requests for specific IP addresses/subnets. This map is created by the Switchboard application administrators, although it could also be driven from an external database of roles and address space ownership.
Users typically request a link by specifying the hostnames for the endpoints of the link in a web form.
Switchboard link request form
Once the form is submitted, Switchboard looks up the hosts to determine their IP addresses, and from the IP addresses determines who can authorize each end of the connection. The approvers are then notified via e-mail and can visit Switchboard to approve or reject the request.
In some cases, the person making the requests may be an authorized approver for one or both subnets on which the two host endpoints reside. In this scenario, Switchboard marks the request as tacitly approved for the subnet(s) that the requestor can approve.
On the Switchboard home page, users can both see any requests awaiting their approval, and the status of their requests
Switchboard home page where uses can see status of their requests – and request new links
SDN configuration
Because researchers from different groups will be making requests on an ad-hoc basis, we expect the SDN configuration to change frequently, so understanding both the history of the configuration changes and the current state of the configuration is crucial to the success of this project.
Switchboard takes several approaches to address these issues. User requests and approvals are logged and a request history is maintained in the Switchboard database. In addition, Switchboard logs the REST calls to the SDN controller and RYU’s responses to the calls, so in the event of problems it is possible to reconstruct what happened.
detailed log of all transactions with the RYU controller
Switchboard app administration
The Admin page is restricted to designated Switchboard application administrators, and is where several maintenance functions are performed:
- mapping of IP subnets to managers/owners for these subnets
- defining group memberships for managers
- querying the database for currently valid links
- querying the RYU controller for the current state of the SDN configuration
- initializing the SDN configuration to bootstrap the system
Switchboard application admin screen
Visualizing the SDN network
One of the challenges of developing and testing the code that calls the RYU REST web services is understanding the current state of the SDN configuration. RYU returns that status of the SDN network in a JSON-encoded format that is efficient for computer-to-computer transactions but less than compelling for human consumption.
To address this issue, Switchboard uses the d3.js “Data Driven Documents” library’s force based network layout to visualize the state of the SDN network. When the network is first started and the the three switches have not been given any route information the visualization look like this:
SDN network before configuration – no IP routes
After running the app admin’s initialization function to configure routes and subnets, the visualization changes. You can see that switch 1 if connected to the 10.185.47.0/30 and 10.138.96.0/25 networks. In this example, the 10.185.47.0/30 network is used to link Switch 1 and 2, and the 10.138.96.0/25 network is intended to hold the hosts that users would connect to the switch.
SDN network initial configuration
Note that the default layout is driven by a force simulation, which has the advantage that it can accommodate significant changes in the number of links. Nodes in the diagram can be dragged to rearrange the layout. Double clicking on a node pins it in place.
drag to move nodes, double-click to pin them in place
To see details of a given switch configuration, you can mouseover the switch. In the example below, switch 2 has been configured to be on three networks: 10.185.47.2/30, 10.185.0.62/26, and 10.185.47.5/30
mouseover for configuration details
All Switchboard users have access to this visualization from a link on the home page.
External access to the SDN configuration
We expect that applications outside of Switchboard will want read-only access to the state of the SDN network configuration, and Switchboard now has preliminary support for this in both JSON and CSV formats. The d3.js visualization in Switchboard uses the CSV call to fetch the data that drives the force-based network graph.
JSON-format SDN network status – good for computers, but not entirely human-friendly
CSV-format SDN config information
Running Switchboard
Switchboard is a Ruby-On-Rails application which we run under Ruby 2.1.2 and Rails 4. The database is MySQL.
The Switchboard source is at git@gitorious.oit.duke.edu:switchboard/switchboard.git
For test and development, we run a copy of the SDNHub RYU tutorial Ubuntu Linux image found at http://sdnhub.org/tutorials/sdn-tutorial-vm/
The Switchboard source includes notes on how to configure MiniNet and the RYU REST controller software for use with SDNHub.
