Today we are going to discuss on a very hot topic which is booming in the networking industry and that is SDN. But we are not going to understand SDN here but we will be seeing what is Cisco's solution to SDN. Before we start our discussion, lets understand what SDN means and how it works?
SDN (Software Defined Networking) as the name suggests means managing the network the way you want by writing a small piece of code to achieve the task. As per ONF (Open Network Foundation), "Software-Defined Networking (SDN) is an emerging architecture that is dynamic, manageable, cost-effective, and adaptable, making it ideal for the high-bandwidth, dynamic nature of today's applications". With the implementation of SDN, the networking industry has taken the next step towards promoting innovation and cost-efficiency at the same time providing organizations to control their network in the way they want rather than compromizing on the feature set available with the software.
With SDN, its also important to understand what programmable networks means.
The concept of programmable networks has been proposed as a way to facilitate network evolution. In particular, SDN is a new networking paradigm, in which the forwarding hardware (for example, specialized packet forwarding engines) is decoupled from the control decisions (for example, the protocols and control software). The migration of control logic, which used to be tightly integrated in the networking devices (for example, Ethernet switches) into accessible and logically centralized controllers, enables the underlying networking infrastructure to be abstracted from the application's point of view.
OpenFlow is an open interface for remotely controlling the forwarding tables in network switches, routers, and access points. Upon this low-level primitive, researchers can build networks with new high-level properties. We shall not be discussing much deeper into OpenFlow here as it is itself a huge topic of discussion. We shall now see what is the problem with the 1st Generation SDN architecture.
Problem with SDN
The biggest problem the first generation SDN faces is that every packet in the network hits the SDN controller which in-turn adds to the latency due to time consumed by the controller to perform actions on the packet. Also, the challenge is when the SDN controller fails. The packets start either to drop or go unprocessed which again defeats the purpose of SDN. We need an infrastructure that is capable of handling even 100% failure of the controllers thus you define the policy once and you are done forever whether the controller is present or not.
The second biggest challenge that is faced is even with SDN and other network virtualization technologies like VMWare NSX, we are still forcing the applications to work as per network but not the other way around. Now lets think of this situation where an application programmer always has to rely on the network team or other team for that matter and then program or modify its application matching those environments. If we had an infrastructure that is flexible enough to respond based on the application which actually makes the life easier of a programmer and removes the dependency.
Cisco ACI (Application Centric Infrastructure) Solution
Cisco has taken SDN to a new level with its ACI solution. Now the question is what is ACI? As the name suggests, infrastructure that adjusts itself based on the application. The Cisco Application Centric Infrastructure (ACI) allows application requirements to define the network. Implemented as a part of Nexus 9000 fabric architecture known as the ACI fabric, along with APIC controller to run in the leaf/spine ACI fabric mode. In the leaf/spine architecture, each spine node is connected to all the leaf nodes and each leaf node has a connectivity to all the spine nodes providing multiple redundancy. Please note that in this architecture, the spines are not connected to each other. Also, the fabric is so designed that you need to define the policies via the APIC controller just once and they will run forever even if the controller goes down. Thus, in order for traffic to move smoothly in this architecture, one doesn't have to rely or depend on the APIC controller.
In the above diagram, the top nodes are the Spine and the second level nodes are called the leaf. All the services are deployed on the leaf switches. Nexus 9500 switches are used at the Spine layer where as Nexus 9300 is used at the leaf level. The APIC provides both Northbound and Southbound APIs to manage the fabric as well as 3rd party vendor devices like VMWare VSphere, Microsoft Hyper-V, etc.
The ACI fabric provides low-latency forwarding across high-bandwidth links like 40 Gbps. Traffic with the source and destination on the same leaf switch is handled locally, and all other traffic travels from the ingress leaf to the egress leaf through a spine switch. Although this architecture appears as two hops from a physical perspective, it is actually a single Layer 3 hop because the fabric operates as a single Layer 3 switch. Thus a highly scalable environment.
Application Policy Infrastructure Controller (APIC) manages ACI multitenant fabric architecture. It provides single point of policy management, automation, policy programming, monitorring and application deployment services for the fabric. Since it provides an infrastructure to define optimal networks for applications, it makes it easier to troubleshoot, isolate any problem related to any application or infrastructure and also monitor the resource utilization by that application.
Hope this post gives you a overview of how the ACI infrastructure looks like.
We shall discuss the components of ACI in another post.
Feel free to reach out to me for further queries.