ENAUTO – Traditional vs SDN Network, Controller Based Architecture, SDN Controllers relation to Mgmt / Control / Data Planes, and API directions!

API_Dirs

Like an API Free running through our networks, being driven by software, woohoo!

I will jump right into it as this is still the intro to Network Automation and fundamentals material, which is starting to go from things I’ve already known about SDN Networks, to newer topics so I am excited to keep marching forwarding here 🙂

Different management styles of Networks

Managing Traditional Networks

  • Node by Node management
  • CLI driven or GUI (like ASDM for ASA’s)
  • Extensive use of Telnet, SSH, HTTP, and SNMP
  • Vendor Specific tasks with ASIC’s (Hardware) rather than CPU
  • Devices start with no to very little configuration
  • Possibly Multiple Disparate Servers for different functions like DHCP / SNMP / etc

Managing SDN Managed Networks

  • Dynamic Implementation of devices – Such as Zero-Touch Provisioning or Plug and Play where devices download the running config once they connect to the internet
  • Dynamic pre-configured updates scheduled to be pushed out to devices in network
  • Location the “Control Plane” to the Controller to give your devices more horse power for data-plane functionality of routing traffic
  • “Single Pane of Glass” management where most or all items are on the same page

Next is a critical different between SDN Controller approaches to know both working with them and for exam day I would imagine – So time to pay attention!

Imperative Controller approach (NOT HOW CISCO DOES IT)

All of the “Control Plane” logic is put onto the Controller, so that instead of a Router learning where its destinations / routes are and storing them locally, it only knows about its directly connected links and the path back to the Controller.

The controller would then respond to all devices in that path advising to add this route between the two devices / networks, and unless directly connected, the Controller has to be aware of every path created in the network and in fact make it itself with the devices.

This goes for IP and MAC tables, the Controller tells routing devices about all these tables.

(Hence the Imperative Controller, if removed this network would not route traffic)

Declarative Controller approach (How Cisco does it!)

This is an approach where the Control Plane is left on the Individual Devices, however there is a Controller that tells the devices when it needs a specific Path through the network with least amount of congestion or other requirement, and the devices themselves need to decide how best to execute this order from the Controller.

The devices might dynamically create a customer route, customer QoS / CoS, however they will make it happen among themselves per the Controllers order.

Considerations when Designing an SDN Network

  • Hardware selected must understand the Controllers Protocols
  • NEED redundant paths to the Controller if not Cloud based
  • Plan for dispersed Controllers (geographically) reachability
  • Plan for Controller clustering for Redundancy
  • Must have absolute A+++ Security with the SDN Deployment
  • Training must be readily available, is the product easy to use? Etc

This is not really an exam topic but something I felt was a good idea to put in here for real world network admins who might have to look at updating their own infrastructure, is the decisions like this that go into finding a solution that best fits your goals.

A review of Controller-Based SDN Networks and their components

There are three main components to Controller Based SDN Networks:

  • Underlay Network
  • Overlay Network
  • SDN Fabric

What is the Underlay Network?

Essentially it is the true IP Reachability via Routing Protocols and Services, that allow for communication between Endpoints, much like the DMVPN concept of Underlay.

What is an Overlay Network?

Again like a DMVPN this will be the “Logical” network on top of the Underlay created by software (such as NHRP in the case of DMVPN), though it may be other technologies such as MPLS L3 VPN / VxLAN / Etc.

The SDN Controllers job beyond my DMVPN example is to fine tune the Overlay Path Selection for different routes, or to implement security / segregation between traffic using the same Overlay network, which of course we must tell it to do on the Controller.

The SDN Fabric

This refers to the devices in the “Underlay” Infrastructure that has the  ability to communicate with the SDN controller, ideally ALL Underlay devices would be able to speak to the SDN Controller / Full Mesh some components may not be able to, so they are stilled considered the SDN “Underlay” but not the “SDN Fabric” for the network.

So generally the “Fabric” will mean the “Underlay” in most instances / ideally, however some companies may have old infrastructure that doesn’t speak SDN, so when you are talking SDN “Fabric” it refers to devices that can communicate to the Controller.

SDNs relationship with the Management, Control, and Data Planes

For a quick review of the different Planes:

  • Management Plane – Accessing the device through various protocols
  • Control Plane – Where traffic forwarding decisions are made
  • Data Plane – Where the actual traffic itself lives

The Management Plane

This is the Plane in which you as the Network Admin gain access to the device for Configuration / Monitoring / Troubleshooting purposes via Console / Telnet / SSH / HTTP / HTTPS / SNMP, basically HOW you access the device, which in an SDN Network may use all these protocols (hopefully the secure ones) only it will be the Controller doing the Managing and not you!

There are some new protocols that SDN Controllers speak for Management including NETTCONF/YANG and XML, though these are for the very new SDN technologies, so the older Management Plane protocols will still be in use in many SDN Networks.

The Control Plane

This is the plane which Routing Protocols / ACLs / Features that effect traffic forwarding exist, ARP runs here to dynamically learn MAC Addresses, and this all works together at the Control Plane to tell the device what to do with the traffic in its Data Plane.

This plane is only used to configure the Mechanisms to GATHER that data, however the actual execution of Data Forwarding resides within the Data Plane, as explained below.

The Data Plane

This Plane encompasses anything logical or physical on a device that is part of the Data Forwarding process, such as MAC Table / IP Forwarding Tables / NICs / TCAM / Cables / Packet Buffers are all part of this plane, literally anything a data packet touches while being forwarded is considered part of the “Data Plane” in a network.

Although the “Control Plane” is responsible for learning all of this information relevant for traffic forwarding, the “Routing Table” itself or perhaps CEF belongs to the Data Plane because it is part of the Data Forwarding process!

So what does all this have to do with SDN Controllers / Networks?

This brings us back to Imperative SDN Controllers vs Declarative SDN Controllers.

Imperative Controllers are known as “Stateful SDN” and remove the Management / Control Plane from the device all together, and program the devices “Data Plane” for it, which can seem like a pretty good deal to get “zero-touch provision” devices with no brains except to talk to the SDN Controller to get its Data Plane information.

But what happens if something happens that the Imperative “Stateful” controllers becomes unreachable via connectivity, loses power, just ceases functioning? Every site with an Imperative “Stateful” SDN Controller goes down as well until it comes back up, because the individual devices have no ‘brains’ to gather their own routing information.

Declarative Controllers are known as “Stateless SDN” and they keep both the Control and Data Planes on the individual devices, with the Controller only declaring to devices how it would like the network to function, and the network devices making their own decisions on how best to implement the will of the SDN Controller through the network.

What is an API?

API = Application Programming Interface

This means we have an Application that needs to be programmed, which needs an Interface to the network, the code that performs this function is called an API.

Two examples generic types of API:

  • These can be on your PC, allowing your Web Browser to call another program used by a function in the Web Browser to perform another task on the PC
  • Some use IP Networking to communicate between to allow two remote applications to communicate across the network

Two more specific SDN examples of API:

  • Applications connecting to an SDN Controller
  • SDN Controllers connection to network devices

Both type of SDN API’s use IP and HTTP or HTTPS for communication, and use a Client / Server model, where the device trying to extract Data is the “Client” and the device holding the data to be extracted is considered the “Server” in the relationship.

So an Application talking to a Controller would be Application (Client) and Controller (Server), whereas a Controller trying to extract info from a router would make the Controller the “Client” and the router containing the Data the “Server” in this instance.

What are Southbound and Northbound APIs?

This is a fairly easy concept, Northbound API’s are any API that is “above” the controller meaning Applications that connect to the Controller to program it, those are Northbound.

Southbound APIs are any APIs “below” the controller that will generally be facing the Network devices Overlay or Underlay as shown here:

API_Dirs

REST API’s are considered “Northbound” APIs, while Southbound APIs include RESTCONF/YANG / NETCONF/YANG / SNMP / OpFlex / OpenFlow / CLI, so lots more SouthBound APIs flowing toward the devices than back up Northbound to Controller Applications!

That will do it for this article on continuing down fundamentals lane

I am also studying some Python programming on the side so when it comes time to start jamming I will hopefully be ready to rock, until next time fellow Automation Geeks! 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s