This topic is to discuss the following lesson:
2 Likes
Hello Rene!
First of all nice post on SDN.My question is will it be difficult for network engineers in future? How this can affect any network engineers Job? since we don’t know any programming languages how we will sustain in market.so we will have to upgrade ourselves in this regard.so now the main question arise how to start and from where to start learning these stuffs??
You will be starting your own tutorials on SDN technology in future?? Thank You!
Hi Renee,
As far as I understand, routers and switches incorporate hardware functions to manipulate the data-stream, in Uni I was told that these hardware functions are 10 times faster than the software functions. How does this work with SDN?
Best regards,
Hans de Roode.
Hi Rene,
Waiting for your answer Sir
Thank You
Deepak
I have read many posts on SDN , and this is the most simplest yet effective article. kudos !!
1 Like
@Deepak SDN is getting more popular in datacenters because of some of the reasons I described in this lesson. The same thing probably applies to (large) Enterprise networks.
You don’t have to become a super programmer, after all a programmer is also not a network engineer. It is a good idea however to get familiar with scripting and some simple programming languages like Python. Learning how APIs work and how to interact with them is also a good idea. Python is something that I will add here…you can learn the basics of it in a few hours. I will also add more SDN material.
@Hans The actual forwarding of traffic is done in hardware by ASICs which is much faster compared to a “software” lookup where we use the CPU. The forwarding is a task performed by the “data plane”. Feeding the data plane with information with information from the routing table, ARP table, access-list entries, etc. is done by the “control plane”. Most SDN solutions take the control plane out of the hardware and put it in the SDN controller. We still forward our traffic with ASICs.
@Abhishek - I agree. The first simple explanation after trawling many pages. Should have come here first.
Rene - is it true to say
- REST is an API accessible via the northbound interface
- The northbound interface provides access to the SDN from above
- The southbound interface provides access to lower levels e.g. network hardware (also from above) to the SDN
Many thanks for any reply. I cannot believe the waffle I have been trying to read elsewhere. You save me time sir. That is appreciated.
In some other lessons, I will give you some configuration examples of SDN solutions like Open SDN, Openflow, OpenDayLight, Cisco ACI and Cisco APIC-EM.Hi Rene Is Openflow an SDN solution as quoted as well as the most popular SBI? Many thanks
Hi Shaunl,
OpenFlow is not a “complete” SDN solution, it’s a SBI protocol that is used between/on the controller and switches. A lot of SDN controllers do support OpenFlow though.
Rene
Hi Rene,
just a quick question, I think it fit here.
What about the new Cisco DNA Solution?
What is you oppinion about this?
Maybe you want to make a short lesson 
Hello Konstantinos,
Good question, I wrote something about Cisco SD-access and SD-WAN. Take a look at this lesson:
Both are interesting. I like the idea about having an overlay and underlay network in the SD-access solution. Cisco SD-WAN (viptela) also looks pretty interesting.
Rene
HI Rene,
First of all thanks for making it very clear about SDN. Thanks and Kudos for this post.
Shall we get similar post separately for SD-WAN?
Also in detail about how SD-WAN makes user benefits by cost reduction?
Hello MURUGESH
Rene shared a link a few days ago to a new lesson that includes SD-WAN. Take a look:
I hope this has been helpful!
Laz
Hi Rene,
Can you build a lab on SD-WAN Cisco Viptela and show us exactly how it works, if possible?
Hi Deepak,
I might sometime, I played around a bit with Viptela SD-WAN when I wrote this post:
https://networklessons.com/cisco/evolving-technologies/cloud-connectivity
I’m not sure how easy it is to get the images and licenses for a lab. If you want to see it in action, there are some labs in Cisco Dcloud or Cisco Devnet. You can access those for free.
Rene
Rene, can you please clarify what is the difference from between APIC and APIC-EM.
The way I understand it is that APIC is the Cisco SDN controller and APIC-EM is the SBI solution for cisco infrastructure that is not SDN capable (ei: Cisco 3560, 3570 et al.) Am I correct?
I modified your diagrams in my own notes so that I could make sense of all these ideas. Please let me know if this is correct as well.
My other question are what is Cisco ACI? And what is Service Abstraction Layer?
Regards,
-G
Hello Martha
Yes, you are essentially correct. APIC uses OpenFlow and other such protocols to communicate with network devices, while APIC-EM is able to communicate with traditional devices that do not speak these protocols. APIC-EM communicates to network devices through the southbound interface using TELNET, SSH, or SNMP. So where APIC typically uses OpenFlow, APIC-EM uses the more traditional services described.
In general, APIC is typically used in datacenters while APIC-EM is used on campuses, LANs and WANs. This is not a strict distinction, but just a general trend.
Now Cisco ACI stands for Application Centric Infrastructure. It is Cisco’s SDN solution architecture. It provides automation tools for network administration, and centres around the Nexus series of devices and the APIC controller for the hardware component. It also includes virtual components as well. You can find out more about it here:
Concerning the Service Abstraction Layer (SAL), this is a component of the OpenDayLight open source SDN controller. Cisco also provides a commercial distribution of the OpenDayLight controller. Below you can see an example of its components.
Note the SAL is part of the Core Infrastructure. According to OpenDayLight:
In OpenDaylight, the service abstraction layer (SAL) is the key design that enables the abstraction of services between the services’ consumers and producers. SAL acts like a large registry of services advertised by various modules and binds them to the applications that require them. Modules providing services, or producers, can register their APIs with the registry. When an application, or a consumer, requests a service via a generic API, SAL is responsible for assembling the request by binding producer and consumer into a contract, brokered and serviced by SAL. SAL has two architecturally different ways of implementing this registry: application-driven SAL and module-driven SAL. In Section III, we will describe this service abstraction in detail.
Here a producer is a module providing a service, while a consumer is a network device that requires that service. SAL essentially acts as a middle man that can translate the command/requirements between service modules and network devices via a generic API.
I hope this has been helpful!
Laz
Hi Rene,
can you Explain me the difference between SDN and SDN-WAN?
Hi
This question is related to CISCO ACI - Bridge Domains.
Want to know when to use the ACI specific ARP flooding option and Traditional ARP flooding in Bridge Domain Configuration ?
Hello Gowthamraj
SDN stands for Software Defined Networking, which strictly speaking, is a general umbrella term used to describe all types of networks that are designed using a central controller for the control plane.
SD-WAN is a type of SDN network which applies the principles of SDN on WAN connections. Similarly, SD-LAN is a LAN built around the principles of SDN.
But as we often see, terms are not always used as they were originally meant to be used. Sometimes, the term SDN is used to refer to an SD-LAN, so you must know the context in which the terms are being used.
I hope this has been helpful!
Laz