This topic describe controllers used in network programming. Start learning CCNA 200-301 for free right now!!
Note: Welcome: This topic is part of Module 13 of the Cisco CCNA 3 course, for a better follow up of the course you can go to the CCNA 3 section to guide you through an order.
Table of Contents
SDN Controller and Operations
The previous topic covered SDN. This topic will explain controllers.
The SDN controller defines the data flows between the centralized control plane and the data planes on individual routers and switches.
Each flow traveling through the network must first get permission from the SDN controller, which verifies that the communication is permissible according to the network policy. If the controller allows a flow, it computes a route for the flow to take and adds an entry for that flow in each of the switches along the path.
All complex functions are performed by the controller. The controller populates flow tables. Switches manage the flow tables. In the figure, an SDN controller communicates with OpenFlow-compatible switches using the OpenFlow protocol. This protocol uses Transport Layer Security (TLS) to securely send control plane communications over the network. Each OpenFlow switch connects to other OpenFlow switches. They can also connect to end-user devices that are part of a packet flow.
Within each switch, a series of tables implemented in hardware or firmware are used to manage the flows of packets through the switch. To the switch, a flow is a sequence of packets that matches a specific entry in a flow table.
The three tables types shown in the previous figure are as follows:
Flow Table – This table matches incoming packets to a particular flow and specifies the functions that are to be performed on the packets. There may be multiple flow tables that operate in a pipeline fashion.
Group Table – A flow table may direct a flow to a Group Table, which may trigger a variety of actions that affect one or more flows
Meter Table – This table triggers a variety of performance-related actions on a flow including the ability to rate-limit the traffic.
Video – Cisco ACI
Very few organizations actually have the desire or skill to program the network using SDN tools. However, the majority of organizations want to automate the network, accelerate application deployments, and align their IT infrastructures to better meet business requirements. Cisco developed the Application Centric Infrastructure (ACI) to meet these objectives in more advanced and innovative ways than earlier SDN approaches.
Cisco ACI is a hardware solution for integrating cloud computing and data center management. At a high level, the policy element of the network is removed from the data plane. This simplifies the way data center networks are created.
Click Play to view a video about the evolution of SDN and ACI.
Core Components of ACI
These are the three core components of the ACI architecture:
Application Network Profile (ANP) – An ANP is a collection of end-point groups (EPG), their connections, and the policies that define those connections. The EPGs shown in the figure, such as VLANs, web services, and applications, are just examples. An ANP is often much more complex.
Application Policy Infrastructure Controller (APIC) – The APIC is considered to be the brains of the ACI architecture. APIC is a centralized software controller that manages and operates a scalable ACI clustered fabric. It is designed for programmability and centralized management. It translates application policies into network programming.
Cisco Nexus 9000 Series switches – These switches provide an application-aware switching fabric and work with an APIC to manage the virtual and physical network infrastructure.
The APIC is positioned between the APN and the ACI-enabled network infrastructure. The APIC translates the application requirements into a network configuration to meet those needs, as shown in the figure.
The Cisco ACI fabric is composed of the APIC and the Cisco Nexus 9000 series switches using two-tier spine-leaf topology, as shown in the figure. The leaf switches always attach to the spines, but they never attach to each other. Similarly, the spine switches only attach to the leaf and core switches (not shown). In this two-tier topology, everything is one hop from everything else.
The Cisco APICs and all other devices in the network physically attach to leaf switches.
When compared to SDN, the APIC controller does not manipulate the data path directly. Instead, the APIC centralizes the policy definition and programs the leaf switches to forward traffic based on the defined policies.
The Cisco Application Policy Infrastructure Controller – Enterprise Module (APIC-EM) extends ACI aimed at enterprise and campus deployments. To better understand APIC-EM, it is helpful to take a broader look at the three types of SDN.
In this type of SDN, the devices are programmable by applications running on the device itself or on a server in the network, as shown in the figure. Cisco OnePK is an example of a device-based SDN. It enables programmers to build applications using C, and Java with Python, to integrate and interact with Cisco devices.
This type of SDN uses a centralized controller that has knowledge of all devices in the network, as shown in the figure. The applications can interface with the controller responsible for managing devices and manipulating traffic flows throughout the network. The Cisco Open SDN Controller is a commercial distribution of OpenDaylight.
This type of SDN is similar to controller-based SDN where a centralized controller has a view of all devices in the network, as shown in the figure. Policy-based SDN includes an additional Policy layer that operates at a higher level of abstraction. It uses built-in applications that automate advanced configuration tasks via a guided workflow and user-friendly GUI. No programming skills are required. Cisco APIC-EM is an example of this type of SDN.
Each type of SDN has its own features and advantages. Policy-based SDN is the most robust, providing for a simple mechanism to control and manage policies across the entire network.
Cisco APIC-EM is an example of policy-based SDN. Cisco APIC-EM provides a single interface for network management including:
discovering and accessing device and host inventories,
viewing the topology (as shown in the figure),
tracing a path between end points, and
APIC-EM Path Trace
The APIC-EM Path Trace tool allows the administrator to easily visualize traffic flows and discover any conflicting, duplicate, or shadowed ACL entries. This tool examines specific ACLs on the path between two end nodes, displaying any potential issues. You can see where any ACLs along the path either permitted or denied your traffic, as shown in the figure. Notice how Branch-Router2 is permit all traffic. The network administrator can now make adjustments, if necessary, to better filter traffic.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.