Not all APIs are created equally.

Automation is starting to become the new catch phrase in the networking Industry. It seems like 2014 is the year that marketing groups from different vendors have been touting APIs on their products. Skeptical networking engineers however have claimed that an API does not mean that their jobs are getting easier. In fact it’s been making their jobs a little harder.

Before a networking engineer could strictly focus on pure networking. But now, network engineers are increasingly required to know more and more on how to code or at least know how to read code.

Just because you have an API doesn’t mean all the devices can and will play nice with each other. 

We can see this by looking at three different platforms. 

OpenStack         Contrail        Junos

Now let’s look at their API for data retrieval/configuration

REST                  REST           Netconf

Ok now you have two platforms that use one type of API and a third platform that uses a different API.

Let's look at the resulting Data Structure response

JSON                JSON XML

Again we have two platforms that have the same Data Structure and a third with a different Data Structure.

You might say, ok, at least two of these platforms have the same API and with the same data structure things should be good for both of them right? Actually as they say, the devil is in the details.

I can illustrate this just by looking at a simple IPv4 subnet. 

On Openstack the data abstracted looks like this

{ "networks": [ { "contrail:subnet_ipam":  [  { "subnet_cidr": "12.1.1.0/24",  } ] } ] }

On Contrail it looks like this

{"virtual-network":{ "network_ipam_refs":[ { "attr": { "ipam_subnets": [ { "subnet": { "ip_prefix": "12.1.1.0", "ip_prefix_len": 24 }, } ] }, } ], } }

You can see that one platform combines the subnet with the mask while the other one separates it. For a DevOps engineers and Network Engineers this is annoying. It’s like having to learn different Network Operating systems. The goal of an API should be to allow a simplified abstraction layer.

APIs need to be standardized. Openflow is a good attempt at this. Openflow requires the underlay to have a common protocol in order to allow a controller to programmatically configure them. The networking industry has done a great job at standardizing protocols but a sorry job at creating a common API standard. Maybe the IETF needs to jump in on this. A standardized API could ultimately make our jobs that much more easier.

Exploring the REST API on contrail.

I noticed on github that there was a tutorial on how to access the REST API on Juniper Contrail.

https://juniper.github.io/contrail-vnc/api-doc/html/tutorial_with_rest.html#

The easiest way to access this is by using cURL. Contrail uses tcp port 8082 for accessing it's REST API.

The url http:/contrail-ip/virtual-networks prints out a list of configured virtual networks on Contrail.

$ curl -X GET -H "Content-Type: application/json; charset=UTF-8" http://172.16.1.4:8082/virtual-networks | python -mjson.tool

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100  1229  100  1229    0     0   2129      0 --:--:-- --:--:-- --:--:--  2129

{

    "virtual-networks": [

        {

            "fq_name": [

                "default-domain",

                "default-project",

                "__link_local__"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/4092df7b-997a-4ee7-a5cc-46d5db1187d4",

            "uuid": "4092df7b-997a-4ee7-a5cc-46d5db1187d4"

        },

        {

            "fq_name": [

                "default-domain",

                "default-project",

                "default-virtual-network"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/34579f9a-064e-4048-96a7-a30355c54e44",

            "uuid": "34579f9a-064e-4048-96a7-a30355c54e44"

        },

        {

            "fq_name": [

                "default-domain",

                "default-project",

                "ip-fabric"

            ],

            "href": "http://172.16.100.104:8082/virtual-network/db7d1afe-bcaa-456b-b33a-9a36f6d176fe",

            "uuid": "db7d1afe-bcaa-456b-b33a-9a36f6d176fe"

        },

        {

            "fq_name": [

                "default-domain",

                "demo",

                "Network1"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/380c0f4e-34b6-4901-98b2-61a8ed7afd7d",

            "uuid": "380c0f4e-34b6-4901-98b2-61a8ed7afd7d"

        },

        {

            "fq_name": [

                "default-domain",

                "demo",

                "Network2"

            ],

            "href": "http://172.16.100.104:8082/virtual-network/ffe03354-aaa2-4305-b615-654e14111134",

            "uuid": "ffe03354-aaa2-4305-b615-654e14111134"

        },

        {

            "fq_name": [

                "default-domain",

                "demo",

                "Network3"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/93317422-eea4-4b77-88cb-5aaac3bb58b6",

            "uuid": "93317422-eea4-4b77-88cb-5aaac3bb58b6"

        }

    ]

}

However cURL, at least for me, isn’t capable of abstracting the data structures programatically. It's more like screen scraping. So I dug around the internet and noticed that python has a curl module.

http://pycurl.sourceforge.net/doc/quickstart.html#

Now I can use python to execute cURL to pull data from a REST API. 

There are a few parts to this script.

The first part is a function to issue the cURL command.

The second part is to abstract the route-target from a virtual network created in the Contrail controller.

This could then be used later on with another script to create a template configuration and program the underlay gateway router with a VRF.

In this script I cheated a little by grabbing a specific virtual-network’s url address from the previous curl command. Then parsed the data to grab the information I was looking for.

—————————————

import pycurl

import StringIO

import json

#Function to issue cURL command

def get_url(WEB):

  buf = StringIO.StringIO()

  c = pycurl.Curl()

  c.setopt(c.URL, WEB)

  c.setopt(c.WRITEFUNCTION, buf.write)

  c.perform()

  body = buf.getvalue()

  network = json.loads(body)

  buf.close()

  return network

#URL of virtual network on contrail

SITE = 'http://172.16.1.4:8082/virtual-network/380c0f4e-34b6-4901-98b2-61a8ed7afd7d'

objects = get_url(SITE)

#pretty print the json results

print json.dumps(objects, sort_keys=True, indent=4)

#This part is to grab the path of the Virtual Network name and RT from contrail

print "Name: ", objects['virtual-network']['name'], " RT: ", objects['virtual-network']['route_target_list']['route_target'][0]

Script in action:

——————

$ python contrail.py 

{

    "virtual-network": {

        "fq_name": [

            "default-domain", 

            "demo", 

            "Network1"

        ], 

        "href": "http://172.16.1.4:8082/virtual-network/380c0f4e-34b6-4901-98b2-61a8ed7afd7d", 

        "id_perms": {

            "created": "2014-09-19T19:19:11.650288", 

            "description": null, 

            "enable": true, 

            "last_modified": "2014-09-27T05:22:30.453524", 

            "permissions": {

                "group": "cloud-admin-group", 

                "group_access": 7, 

                "other_access": 7, 

                "owner": "cloud-admin", 

                "owner_access": 7

            }, 

            "uuid": {

                "uuid_lslong": 11002964217786203517, 

                "uuid_mslong": 4038619794410719489

            }

        }, 

        "instance_ip_back_refs": [

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/instance-ip/17b19dc0-b177-4df7-955b-57b8a87caf28", 

                "to": [

                    "17b19dc0-b177-4df7-955b-57b8a87caf28"

                ], 

                "uuid": "17b19dc0-b177-4df7-955b-57b8a87caf28"

            }, 

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/instance-ip/d525ddce-3542-4986-b8d1-56f3831d8678", 

                "to": [

                    "d525ddce-3542-4986-b8d1-56f3831d8678"

                ], 

                "uuid": "d525ddce-3542-4986-b8d1-56f3831d8678"

            }

        ], 

        "is_shared": false, 

        "name": "Network1", 

        "network_ipam_refs": [

            {

                "attr": {

                    "ipam_subnets": [

                        {

                            "default_gateway": "100.1.1.254", 

                            "subnet": {

                                "gw": "100.1.1.254", 

                                "ip_prefix": "100.1.1.0", 

                                "ip_prefix_len": 24

                            }

                        }

                    ]

                }, 

                "href": "http://172.16.1.4:8082/network-ipam/1f24fa35-b7bf-4d0f-8185-746f58e234c9", 

                "to": [

                    "default-domain", 

                    "demo", 

                    "Network1-ipam"

                ], 

                "uuid": "1f24fa35-b7bf-4d0f-8185-746f58e234c9"

            }

        ], 

        "network_policy_refs": [

            {

                "attr": {

                    "sequence": {

                        "major": 0, 

                        "minor": 0

                    }, 

                    "timer": null

                }, 

                "href": "http://172.16.1.4:8082/network-policy/0a1c1776-a323-4c00-959a-aada50b91be8", 

                "to": [

                    "default-domain", 

                    "demo", 

                    "net1<->net2"

                ], 

                "uuid": "0a1c1776-a323-4c00-959a-aada50b91be8"

            }

        ], 

        "parent_href": "http://172.16.1.4:8082/project/3af66afe-3284-40cc-8b04-85c69af512c7", 

        "parent_type": "project", 

        "parent_uuid": "3af66afe-3284-40cc-8b04-85c69af512c7", 

        "route_target_list": {

            "route_target": [

                "target:64512:100"

            ]

        }, 

        "router_external": false, 

        "routing_instances": [

            {

                "href": "http://172.16.1.4:8082/routing-instance/06165761-3b55-417d-acf0-0ad27a9010d0", 

                "to": [

                    "default-domain", 

                    "demo", 

                    "Network1", 

                    "Network1"

                ], 

                "uuid": "06165761-3b55-417d-acf0-0ad27a9010d0"

            }

        ], 

        "uuid": "380c0f4e-34b6-4901-98b2-61a8ed7afd7d", 

        "virtual_machine_interface_back_refs": [

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/virtual-machine-interface/2aefccdc-bf34-4d3b-bd37-41f716274883", 

                "to": [

                    "e432ad9a-8f6e-4f7c-813b-18ada76bfd64", 

                    "2aefccdc-bf34-4d3b-bd37-41f716274883"

                ], 

                "uuid": "2aefccdc-bf34-4d3b-bd37-41f716274883"

            }, 

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/virtual-machine-interface/f20bb145-49cd-43bf-a6e5-9d9c50794244", 

                "to": [

                    "2e775d6f-8043-41df-9295-d1b8d8f705a2", 

                    "f20bb145-49cd-43bf-a6e5-9d9c50794244"

                ], 

                "uuid": "f20bb145-49cd-43bf-a6e5-9d9c50794244"

            }

        ], 

        "virtual_network_properties": {

            "extend_to_external_routers": null, 

            "forwarding_mode": "l2_l3", 

            "network_id": 4, 

            "vxlan_network_identifier": null

        }

    }

}

Name:  Network1  RT:  target:64512:100

As you can see I was able to pull the "name" of the virtual network and the route-target of the virtual network. Later I can then create a script template to build the VRF on the Router Gateway like a MX.  That's one step closer to network automation.

Using CURL to access Openstack

So I'm exploring the API for Openstack to see how I can extract information from an Openstack platform.

I found the examples can be found here.  While the API is located here.

This could be useful as in the future I could script a networking device (Switch, Router, Firewall, etc) to automate and provision services whenever a new tenant is built.

The idea is to self provision itself. For example when a new tenant is created, a switch can access Openstack, find out what network name was configured, which vlan id assigned and a what ip subnet configured.

So the first step is to authenticate to the Openstack Server and retrieve a temporary token.

host1#curl -d '{"auth":{"passwordCredentials":{"username": "admin","password": "mypassword"},"tenantName": "admin"}}' -H "Content-Type: application/js
on" http://x.x.x.x:5000/v2.0/tokens | python -mjson.tool

What comes back is a json response that needs to be parsed.  I piped the python module "python -mjson.tool"  to parse the contents.

What I get in return looks similar to this:

{
    "access": {
        "metadata": {
            "is_admin": 0,
            "roles": [
                "3e2b3771096e4a95b39f3832c19679df"
            ]
        },
        "serviceCatalog": [
            {
                "endpoints": [
                    {

             ....
            }
        ],
 "token": {
            "expires": "2014-07-10T19:31:10Z",
            "id": "14213fjgiod2341vcrt46b9674f",
            "issued_at": "2014-07-09T19:31:10.700433",
            "tenant": {
                "description": "admin tenant",
                "enabled": true,
                "id": "3a10de8a82444118865a6398b336ee68",
                "name": "admin"
            }
        },
        "user": {
            "id": "be246bdf3e01493d8d75bf3938e1bffc",
            "name": "admin",
            "roles": [
                {
                    "name": "admin"
                }
            ],
            "roles_links": [],
            "username": "admin"
        }
    }
}

Now you can see that the token "expires" and this will mean that you will need to request tokens every so often for security purposes.

After this you'll need the token id so you can make further requests.

Next assign your token to a variable.

host1# MyToken=14213fjgiod2341vcrt46b9674f

host1# echo $MyToken
14213fjgiod2341vcrt46b9674f

Then you can use the token to request further information:
host1#curl -s  -H "X-Auth-Token: $MyToken"  http://x.x.x.x:9696/v2.0/networks | python -mjson.tool
{
    "networks": [
        {
            "admin_state_up": true,
            "id": "0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48",
            "name": "Network1",
            "provider:network_type": "local",
            "provider:physical_network": null,
            "provider:segmentation_id": null,
            "router:external": false,
            "shared": false,
            "status": "ACTIVE",
            "subnets": [
                "d4bf516f-135c-4c7f-ba7e-363cb6c7d307"
            ],
            "tenant_id": "3a10de8a82444118865a6398b336ee68"
        }
}

With this information I can do a get on the subnet:

/v2.0/subnets/​{subnet_id}

 # curl -s  -H "X-Auth-Token: $MyToken"  http://x.x.x.x:9696/v2.0/subnets/d4bf516f-135c-4c7f-ba7e-363cb6c7d307 | python -mjson.tool
{
    "subnet": {
        "allocation_pools": [
            {
                "end": "20.20.0.20",
                "start": "20.20.0.10"
            }
        ],
        "cidr": "20.20.0.0/24",
        "dns_nameservers": [
            "198.6.1.1"
        ],
        "enable_dhcp": true,
        "gateway_ip": "20.20.0.1",
        "host_routes": [],
        "id": "d4bf516f-135c-4c7f-ba7e-363cb6c7d307",
        "ip_version": 4,
        "name": "Network1",
        "network_id": "0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48",
        "tenant_id": "3a10de8a82444118865a6398b336ee68"
    }
}

So with this information I can basically extract the cidr and  gateway_ip to populate a gateway router.