上QQ阅读APP看书，第一时间看更新

Controller-based network fabric

As we come out of the legacy hardware era in which each physical path was connected and designed to take traffic from one point to another, and where a packet had limited availability to reach from one device to another, SDN is ensuring that we have a network fabric for our data to reach between different sources and destinations.

A network fabric is a collection of different network devices connected to each other by a common controller ensuring that each component in the network is optimized to send traffic among each of the nodes. The underlying switch fabric, which is a physical switchboard with ports (like Ethernet, ATM, and DSL), is also controlled and programmed by a controller which can ensure (by creating a path or specific port(s)) that a particular type of data can traverse through to reach its destinations.

In a typical network design we have Layer 2 (or switching domains) and Layer 3 (or routing domains). If we do not have a controller-based approach, each network component can learn the behavior of traffic from its next connected component (like Spanning Tree Protocol (STP) for Layer 2) or some routing protocol (like OSPF for Layer 3). In this case, each device acts as its own controller and only has limited visibility to devices that it is directly connected to (also termed neighbor devices). There is no single view of the entire network on any device, and additionally, each component (or individual controller) acts as a single point of failure for its neighbor devices. A failure on any component would result in its neighbor devices reconverging or even getting isolated owing to the failure of their connected component.

Comparing that to a controller-based environment, theoretically each device has as many connections as it has number of ports connected. Hence, if we think of even three devices connected in a controller-based environment, we have multiple connections between each device owing to their physical connectivity to each other. In case of the failure of a component (or device), the controller can quickly make an intelligent decision to reconfigure a new path and alter the behavior of the other two network devices to ensure minimal disruption to traffic, keeping the same throughput and distributed load on all the other available links. A controller in theory eliminates the control plane behavior of each device and ensures an optimized forwarding table (to forward data to specific destinations) is updated on each device the controller is managing. This is because the controller starts acting as the main component which has the visibility of every device, with every entry and exit point of each device and the granularity of the data type that is flowing from each managed network device.

Going by the vendors, major players such as Cisco (with its open network environment), Juniper (with its QFabric switch), and Avaya (with its VENA switch), have provided the ability to act as controllers or be configured to be managed by a controller. Additionally, with the introduction of controller-to-manager network components, each network device can now virtually become a dump client with the controller making all the intelligent decisions, from learning to forwarding tables.

A controller acts as an abstraction layer between multi-vendor network devices and network tasks. As an end user, someone can configure specific tasks to be performed by the controller, and, using the underlying API model from different vendors (using JSON or XML), the controller can convert those specific tasks into various vendor-specific API calls, and devices can be configured by sending those specific instructions using those APIs to each of the vendor devices. The Application Policy Infrastructure Controller (APIC) component is responsible for controlling and programming the fabric on each network device component.

Let's see an example of Cisco APIC and some basics on how we can use it. Cisco APIC is used to manage, automate, monitor, and program Application Centric Infrastructure (ACI). ACI is a collection of objects with each object representing a tenant. A tenant can be called a group of specific customers, groups, or business units based upon the business classifications. As an example, a single organization may covert its entire infrastructure into a single tenant, whereas an organization can separate out its tenants based upon its functions like HR and Finance. Tenants can further be divided into contexts, with each context as a separate forwarding plane, hence the same set of IP addresses can be used in each context as each set of IP addresses will be treated differently in each context.

Contexts contain Endpoints (EPs) and Endpoint Groups (EPGs). These EPs are physical components like hardware NICs, and EPGs are collections of items like DNSs, IP addresses, and so on, that dictate a similar functionality for a specific application (like a web application).

For programming with APIC, the major components required are as follows:

APIC Rest Python Adaptor (ARYA)

This is a tool created by Cisco to convert the APIC object returned in XML or JSON to direct Python code. Underlying, this leverages the COBRA SDK to perform this task. This can be installed in Python using pip install arya.

ACI SDK

This is the SDK that contains the API to directly call the APIs of the controller. We need to install acicobra, which can be found at https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/api/python/install/b_Install_Cisco_APIC_Python_SDK_Standalone.html, from Cisco to be able to call it into Python.

Once we have this installed, here are some examples from Cisco which can be found at the URL https://github.com/CiscoDevNet/python_code_samples_network/blob/master/acitoolkit_show_tenants/aci-show-tenants.py. This can help us understand creating an object:

#!/usr/bin/env python
"""
Simple application that logs on to the APIC and displays all
of the Tenants. 
Leverages the DevNet Sandbox - APIC Simulator Always On 
    Information at https://developer.cisco.com/site/devnet/sandbox/available-labs/data-center/index.gsp 
    
Code sample based off the ACI-Toolkit Code sample
https://github.com/datacenter/acitoolkit/blob/master/samples/aci-show-tenants.py 
"""

import sys
import acitoolkit.acitoolkit as ACI

# Credentials and information for the DevNet ACI Simulator Always-On Sandbox
APIC_URL = "https://sandboxapicdc.cisco.com/"
APIC_USER = "admin"
APIC_PASSWORD = "C1sco12345"

def main():
    """
    Main execution routine
    :return: None
    """

    # Login to APIC
    session = ACI.Session(APIC_URL, APIC_USER, APIC_PASSWORD)
    resp = session.login()
    if not resp.ok:
        print('%% Could not login to APIC')
        sys.exit(0)

    # Download all of the tenants
    print("TENANT")
    print("------")
    tenants = ACI.Tenant.get(session)
    for tenant in tenants:
        print(tenant.name)

if __name__ == '__main__':
    main()

Looking at the preceding concepts, we can enhance and ensure that our managed nodes in the controller can be controlled based on the application requirements rather than hardware limitations. This also ensures that the infrastructure is now tweaked as per application, and not vice versa, with the application performance restricted by hardware.