Application Centric Infrastructure with Python

In application-centric networking, troubleshooting does not mean logging into discrete devices and examining networking state information. If a web application is not performing, you start with the web application. The fact that relevant state information might exist within a router, switch, or even a web server is secondary. You want to gather intelligence on the application itself. That data needs to be collected and correlated. And you aren’t done until the application is up and running as it should.

There are several questions you need to ask: Can you see how applications are talking across your network? For distributed applications, do you have a view of which components are where? Can you see how data is flowing between them?

Here I would like to present a small Python programm that I adapted from the Cisco code repository. 

# Copyright (c) 2015 Cisco Systems #

# All Rights Reserved. 

"""

Simple application that logs on to the APIC and displays all

of the Interfaces.

"""

import sys

import re

import json

import acitoolkit.acitoolkit as aci

def main():

    """

    Main execution routine

    :return: None

    """

    # Take login credentials from the command line if provided

    # Otherwise, take them from your environment variables file ~/.profile

    description = 'Simple application that logs on to the APIC and displays all of the Interfaces.'

    creds = aci.Credentials('apic', description)

    args = creds.get()

    # Login to APIC

    session = aci.Session(args.url, args.login, args.password)

    resp = session.login()

    if not resp.ok:

        print('%% Could not login to APIC')

        sys.exit(0)

    resp = session.get('/api/class/ipv4Addr.json')

    intfs = json.loads(resp.text)['imdata']

    data = {}

    for i in intfs:

        ip = i['ipv4Addr']['attributes']['addr']

        op = i['ipv4Addr']['attributes']['operSt']

        cfg = i['ipv4Addr']['attributes']['operStQual']

        dn = i['ipv4Addr']['attributes']['dn']

        node = dn.split('/')[2]

        intf = re.split(r'\[|\]', dn)[1]

        vrf = re.split(r'/|dom-', dn)[7]

        if vrf not in data.keys():

            data[vrf] = []

        else:

            data[vrf].append((node, intf, ip, cfg, op))

    for k in data.keys():

        header = 'IP Interface Status for VRF "{}"'.format(k)

        print header

        template = "{0:15} {1:10} {2:20} {3:8} {4:10}"

        print(template.format("Node", "Interface", "IP Address ", "Admin Status", "Status"))

        for rec in sorted(data[k]):

            print(template.format(*rec))

if __name__ == '__main__':

main()

With the help of the ACI Toolkit library from Cisco we could define and create many functions and procedures needed to manipulate and programm the ACI Fabric. As an universal data format JSON is used to retrieve data from the APIC controller. The data interested to us are VRFs, IPs, VLANs and so on. In the final function we define a loop that that will search for all of the the values stored inside the dictionary data structure from Python and sort them using a template.

For those wanted to know more about the ACI please checkout the source text from the SDX Central.

Cisco ACI is a tightly coupled policy-driven solution that integrates software and hardware. The hardware for Cisco ACI is based on the Cisco Nexus 9000 family of switches. The software and integration points for ACI include a few components, including Additional Data Center Pod, Data Center Policy Engine, and Non-Directly Attached Virtual and Physical Leaf Switches. While there isn’t an explicit reliance on any specific virtual switch, at this point, policies can only be pushed down to the virtual switches if Cisco’s Application Virtual Switch (AVS) is used, though there has been talk about extending this to Open vSwitch in the near future.

In a leaf-spine ACI fabric, Cisco is provisioning a native Layer 3 IP fabric that supports equal-cost multi-path (ECMP) routing between any two endpoints in the network, but uses overlay protocols, such as virtual extensible local area network (VXLAN) under the covers to allow any workload to exist anywhere in the network. Supporting overlay protocols is what will give the fabric the ability to have machines, either physical or virtual, in the same logical network (Layer 2 domain), even while running Layer 3 routing down to the top of each rack. Cisco ACI supports VLAN, VXLAN, and network virtualization using generic routing encapsulation (NV-GRE), which can be combined and bridged together to create a logical network/domain as needed.

From a management perspective, the central SDN Controller of the ACI solution, the Application Policy Infrastructure Controller (APIC) manages and configures the policy on each of the switches in the ACI fabric. Hardware becomes stateless with Cisco ACI, much like it is with Cisco’s UCS Computing Platform. This means no configuration is tied to the device. The APIC acts as a central repository for all policies and has the ability to rapidly deploy and re-deploy hardware, as needed, by using this stateless computing model.

Feel free to comment.