Monthly Archives: February 2015

Northbound and Southbound APIs

I regularly hear the packet pushers and others discussing Northbound and Southbound APIs and keep forgetting which does what. Here is a summary, comments and corrections welcome.

First a few definitions for context:

  • SDN – Somewhat Defined Networking ūüėČ Or Software..
  • SDN Management Plane – here is the realm of the applications, where network orchestration takes place
  • SDN Control Plane – interacts with the SDN Management Plane and Data Plane. The realm of APIs. In classic SDN this lives on the SDN Contoller
  • SDN Data Plane – where traffic is forwarded, the realm of hardware
  • SDN Controller – Platform on which Applications run. That platform may be a single server, collection of distributed devices in your network or hosted in the cloud

Southbound API

Communication between the SDN Controller (or possibly simply an administrators workstation running C, Java, Phython,… scripts) and network switches, routers and other devices happens via the Southbound API.

Open Standards

  • Openflow¬†– maintained by the Open Network Foundation (ONF)
  • NETCONF¬†– IETF RFC 6241. Standard for managing Network Device Configuration
    • Often used with the YANG modelling language defined in RFC 6020

As an example I might write a Python Script ‘StandardSNMP’ which takes a switch IP as an argument and uses an appropriate southbound API to retrieve and correct its SNMP config based on my companies best practice.

Vendor Proprietary

Northbound / External API

Communication between applications (possibly running on the SDN Controller) and the controller itself. It is a network abstraction presented to high level applications or management systems. This enables developers to write apps for the network without needing to call the southbound API directly. This could mean the same code could be re-used across multiple network devices, from a variety of vendors.

Disclaimer: This is only an example of how I *think* things may work. It doesn’t reflect operational experience.

Say I am writing a configuration application ‘NetConfPLS'[1] which includes a standardisation feature. In my network are a few switches and routers from multiple vendors, all of which support OpenFlow. Once again, I want to verify whether my companies SNMP¬†standard is adhered to across my network and correct it where it is not.

NetConfPLS would make a Northbound API call to the controller such as ‘give me the SNMP state of all devices’. The Controller then makes a Southbound API call to each network device to pull that config and presents this data to NetConfPLS in a standardised way. NetConfPLS then presents this data to the application user.¬†Perhaps the actual config of each device would be shown together with the proposed replacement if running in debug mode.

The user then selects which devices to standardise. NetConfPLS would issue a second Northbound call to the controller like ‘standardise the following devices’. The controller would then issue a southbound call to each device containing the API version of¬†the appropriate configuration commands.

[1] Potential LawSuit



Screen Shot 2015-02-09 at 12.11.31


Hopefully¬†you can start to see the appeal for developers. Just as we used to write Perl libraries (e.g. Net::Appliance::Session) to communicate with devices, now we can use the device manufacturer’s (or the Open Standard) API to do this. Whereas before the script and library were tightly coupled, now the developer can make use of their programming language of choice to communicate with a network abstraction provided by the controller. Scripts or Applications written in one environment could be more easily ported, given to the community or commercialised.

Of course, as ever, each vendor has their own story to sell. I suspect¬†the road to an Open Source controller playing nicely across all platforms is long and perilous. For example, I can’t imagine Cisco would allow a third party controller access to its Northbound APIs. More likely you’ll be forced to buy a Cisco¬†eXtensible Network Controller (XNC) to program your Openflow switches and onePK switches from one place, protecting that revenue stream for Cisco.


Cisco have confused me a little in the way they have brought their simulator to market. First it was VIRL and free, then CML was announced and the name change blamed on marketing. Now we have both. Here is a birds eye view of each for reference. I’ve also included GNS3 as it is worth considering if you’re in the market for an emulation tool.


  • Part of the /dev/innovate program at Cisco
  • In Beta at the time of writing
  • Community supported
  • Runs on Linux KVM Hypervisor / OpenStack frontend
    • This can be installed bare metal or run via VMWare Fusion / Workstation / Player etc
  • Local hardware model (laptop / desktop)
  • Supports IOS, IOS-XE, IOS-XR and NX-OS
  • No Layer 2
  • Annual Licence either Academic or Personal ($80 or $200)
  • Capped at 15 nodes


  • Corporate Edition
  • TAC Supported
  • Client / Server Model
  • IOSv only today
  • NXOS support roadmapped
  • Heavy server requirements
    • Min: 4 Core CPU / 16 GB RAM for basic 15 node limit
    • 16 Core CPU / 128 GB RAM for full 50 nodes
  • Server runs Ubuntu image
  • Java Client (oh Cisco, why do you try my patience so?)
  • $13,000 Base Install (15 node limit)
  • 5% discount for 50 nodes, 10% for 100
  • More pricing detail and other useful information here

All-in-One Virtual Machine

  • Free
  • Limited version of VIRL
  • 3 Node Development Environment for the Open Network Environment Platform Kit (onePK)
  • Designed to allow would-be app writers to develop and test their Apps


  • Free
  • Community Supported via the GNS3 Jungle
  • Multi-Vendor – Cisco, Juniper, HP, Arista, Citrix and Brocade
  • L2 Supported using Cisco L2IOU Images (native on Linux / Solaris only, VMs on Windows / Mac)
    • Although features relying on L3 Hardware such as¬†¬†L3 Etherchannel, ISL trunks, DHCP snooping, Private VLAN, SPAN/RSPAN/ERSPAN, Port-security, Voice VLANs, MLS QoS and QinQ won’t work
  • Supports any Cisco platforms available as a virtual machine using VitualBox or Qemu



Network Cable and Optic Distances

Here is a list of common network cable and optic types, together with their distances. The costs are very rough and a little on the low side, I’ll try and update them.

Speed / Base Media Distance Cisco Part Rough Cost
10/100/1000BaseT Cat 5e 100m GLC-T SFP £150
10GBaseT Twinax Passive 1 to 5m SFP-H10GB-CU<N>M £50-£100
10GBaseT Twinax Active 7 or 10m SFP-H10GB-ACU<N>M
10GBaseT Cat 6 55m N/A N/A
10GBaseT Cat 6a (may be too thick for flood wiring) 100m N/A N/A
1000BaseSX OM1 (62.5/125) 220m GLC-SX-MMD £200
1000BaseSX OM3 (50/125) 550m GLC-SX-MMD £200
1000BaseSX OM4 (50/125) 1000m GLC-SX-MMD £200
10GBaseSR OM1 (63.5/125) 26m SFP-10G-SR £400
10GBaseSR OM3 (50/125) 300m SFP-10G-SR £400
10GBaseSR OM4 (50/125) 400m SFP-10G-SR £400
10GBaseLRM OM1 with mode conditioning patch cord (62.5/125) 220m SFP-10G-LRM £400
10GBaseLRM OM3 (50/125) 220m SFP-10G-LRM £400
10GBaseLRM SM 300m SFP-10G-LRM £400
10GBaseLR SM 10km SFP-10G-LR £1500
X2 to SFP+ Converter OneX N/A CVR-X2-SFP10G £80
40GBaseCR4 -> 4x10GBaseT Twinax Passive Breakout 1-5m QSFP-4SFP10G-CU<N>M
40GBaseCR4 -> 4x10GBaseT Twinax Active Breakout 7 or 10m QSFP-4SFP10G-AC<N>M
40GBaseCR4 Twinax Passive 1-5m QSFP-H40G-CU<N>M
40GBaseCR4 Twinax Active 7 or 10m QSFP-H40G-ACU<N>M
40GBaseAOC -> 4x10G Optical Active Breakout 1-10m QSFP-4X10G-AOC<N>M
40GBaseAOC Optical Active 1-15m QSFP-H40G-AOC<N>M
40GBaseSR4 OM3 (50/125) 100m QSFP-40G-SR4
40GBaseSR4 OM4 (50/125) 150m QSFP-40G-SR4
40GBaseCSR4 OM3 (50/125) 300m QSFP-40G-CSR4 £800
40GBaseCSR4 OM4 (50/125) 550m QSFP-40G-CSR4 £800
40GBaseSR BiDi (Bi-Directional over one fibre pair) OM3 (50/125) 100m QSFP-40G-SR-BD £400
40GBaseSR BiDi OM4 (50/125) 150m QSFP-40G-SR-BD £400
40GBaseLR4 SM 10km QSFP-40GE-LR4