Maybe it’s just me - but I feel like when we want to demonstrate product APIs to someone, we usually jump into Postman first. It’s not without good reason though. Postman is a very easy to use platform for running API calls against REST endpoints & see the nicely formatted output.

That being said, often times I’ve seen that we stop there. We might mention Python as an advanced method of using our APIs, or maybe we talk about how “if APIs are the new CLI, Postman is the new PuTTY”. I’ve seen some engineers who hear these statements and feel like Postman is being pushed on them - even when they’re perfectly happy with an SSH-based CLI.

Network automation isn’t usually accomplished with just one tool - it’s a whole storage closet full of different tools & utilities, each with their own use cases or specializations. In this particular example - learning Python allows you to move beyond one-off API calls in Postman, and into being able to accomplish much more complex automation.

So the purpose of this post is to explore how to get beyond just Postman, and into using Python for REST API calls. This isn’t going to be a complete run-down of all the capabilities of both tools - but rather a few examples of simple GET requests using both methods.

If you don’t have Postman yet, go ahead and snag the download here.

Note: Much of the code below is minimal and does not contain any error handling. Therefore, it should not be used in a production network. Full example code here.

Postman: Simple GET Request

So first, let’s start off with an example of using Postman for a simple GET request.

In this example, we’ll keep things simple & use a non-authenticated API endpoint. We’ll accomplish this using a free website called JSON Placeholder.

Let’s go ahead and start up Postman, and we’ll see a blank workspace:

What we’ll need to pay attention to first, is what type of HTTP request we’re sending - as well as the URL we want to send our request to. If we expand the request type dropdown, we’ll see a handful of options - but we’ll only be using a GET request for now:

In order to create our first request, we’ll just need to enter our API endpoint URL. We’ll use the users endpoint offered by JSON Placeholder, which is located at: https://jsonplaceholder.typicode.com/users

In the screenshot above, you’ll see in the highlighted box that we entered our URL. Next, we just click the big Send button on the right side.

I already sent the GET request, so in the screenshot you’ll also notice that we have our JSON response from the API. The mock data offered by this API provides us with a list of 10 different users, along with the data that’s been entered for each user.

What if we only wanted to get data for one specific user? Well, our test API site supports using query parameters to filter our response. Let’s say we want to find information for a user named Delphine. We would append ?username=Delphine to our URL:

So as we can see above - now our JSON response only contains the data for a single user. If we needed to find a user’s phone number, this could be an easy way to quickly filter our data & get to what we need.

This is really where Postman is great. We’re able to quickly & visually test out an API call. We can see what the response data looks like, and understand the structure of requests & responses.

But what about when we want to iterate through a number of users and pull only a specific few statistics? Or maybe we need a way to take a list of user information, and automatically upload or convert that data into another system.

For use cases like that, we’ll jump over to Python.

Python: Simple GET Request

In this section, we’ll walk through the same example from above - but this time using Python.

First thing we’ll need to do, is install the Python requests library. While there are a handful of libraries that can accomplish this work, requests is fairly popular & easy to use.

So we’ll kick things off by using pip to install our library:

pip install requests

Then, we’ll create a very simple Python script to perform the same initial GET request from earlier. So we’ll pull a list of ALL users from the API.

import requests

URL = "https://jsonplaceholder.typicode.com/users"

response = requests.get(URL)

print(response.text)

The code above should be pretty straightforward. First we’ll import our requests library. Then, just to keep the code clean, we’ll create a variable called URL to hold the URL for the API endpoint.

Next, we send that GET request, using requests.get. Last but not least, we’ll go ahead and print out the text payload that we receive back. That output looks pretty similar:

matt@DESKTOP:~/postman-python$ python3 simpleGET.py 
[
  {
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "Sincere@april.biz",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough",
      "zipcode": "92998-3874",
      "geo": {
        "lat": "-37.3159",
        "lng": "81.1496"
      }
    },
    "phone": "1-770-736-8031 x56442",
    "website": "hildegard.org",
    "company": {
     -- output truncated --

Now, let’s add a little extra logic to our next step. Rather than just specifying a static username that we want to search for, let’s ask our user to specify a username:

import requests

URL = "https://jsonplaceholder.typicode.com/users"

print("Search by Username:")
user = input("> ")
queryURL = URL + f"?username={user}"
response = requests.get(queryURL)

print(response.text)

In the code above, we made just a few changes. One is printing out a prompt to “Search by Username”. Then we use the Python input function to collect input from our user, then store that in the user variable.

Next, we create a queryURL - which is similar to the URL we used in the Postman example. Except in this case, we’re supplying a dynamic username input based on whatever the end user wants to search for. We use a Python f-string to inject the username into our query parameters.

Let’s see what that looks like:

matt@DESKTOP:~/postman-python$ python3 simpleGET.py 

Search by Username:
> Delphine
[
  {
    "id": 9,
    "name": "Glenna Reichert",
    "username": "Delphine",
    "email": "Chaim_McDermott@dana.io",
    "address": {
      "street": "Dayna Park",
      "suite": "Suite 449",
      "city": "Bartholomebury",
      "zipcode": "76495-3109",
      "geo": {
        "lat": "24.6463",
        "lng": "-168.8889"
      }
    },
    "phone": "(775)976-6794 x41206",
    "website": "conrad.com",
    "company": {
      "name": "Yost and Sons",
      "catchPhrase": "Switchable contextually-based project",
      "bs": "aggregate real-time technologies"
    }
  }
]

Perfect! We get the result we expected, which is the single dataset from the user that we specified.

Let’s take this one step further! Maybe we want to build a quick utility to search for a user’s contact information. We can take the raw JSON output, pull out a few pieces of info, then apply some formatting to make it more user-friendly.

In the following example, we’ll update our code to search that JSON response & collect the user’s name, email address, and phone number.

import requests
import json

URL = "https://jsonplaceholder.typicode.com/users"

print("Search by Username:")
user = input("> ")
queryURL = URL + f"?username={user}"
response = requests.get(queryURL)

userdata = json.loads(response.text)[0]

name = userdata["name"]
email = userdata["email"]
phone = userdata["phone"]

print(f"{name} can be reached via the following methods:")
print(f"Email: {email}")
print(f"Phone: {phone}")

So a few things have changed in the above example. First thing you may notice, is that we’ve added an additional import: the json library. We use this in line 11, where we convert the JSON output into a native python object using the json.loads function.

What this allows us to do is easily pull individual data values from the JSON output. In the original JSON data that we received, we saw a bunch of user data organized into key-value pairs. So once we load that JSON into a Python dictionary, we can pull out individual values and assign them to variables.

Finally - we can print all of that data out to our terminal:

matt@DESKTOP:~/postman-python$ python3 simpleGET.py

Search by Username:
> Delphine
Glenna Reichert can be reached via the following methods:
Email: Chaim_McDermott@dana.io
Phone: (775)976-6794 x41206

Nothing super fancy here - but this could be the beginnings of building out a user search web page, or maybe importing certain data fields into another system. Once we get the basics of working with REST APIs out of the way, there are a ton of possibilities for what can be built.

Okay - What About Network Automation?

Many new network technologies are now API enabled. Nearly every cloud-hosted platform or management controller offers some method of interacting programmatically. In fact, most routers & switches even offer a REST-based API that can be used for automated configuration or monitoring.

So let’s take the following example: We have a couple of Meraki networks, and we’ve been tasked with providing a report of how many total clients have connected to our network in the last 30 days. In addition, it would be nice to see a breakdown of the distribution of operating systems.

Let’s take a look at the following screenshot from Postman:

Using Meraki’s API docs, we can determine the exact URL endpoint we need to query. This URL requires that we know the exact network ID for the network we want to get info from, which we’ll pretend we already know. Also not shown here, we have an additional HTTP header that includes our API key - which was generated in Meraki Dashboard.

In addition, we have a few query parameters to help make sure we get the data we need. By default, this API endpoint will return 10 devices. In this particular network, we already know we have more than 10 - so we use the perPage query parameter to request up to 100 devices. We also wanted to query the last 30 days of devices, so we use the timespan parameter. This parameter expects the lookback to be in seconds, so we specify 43,200 seconds.

So we got back a list of devices - and specifically in the example shown, it looks like we have an Android device on our network. Easy enough to spot that info, right?

Well - maybe we have more than a handful of devices. We don’t want to manually sort through all of that data & assemble a list. Or maybe this task needs to be run more than once. This is where we can use Python to automatically assemble that report with just a few lines of code.

import requests
import json

URL = "https://api.meraki.com/api/v1"
APIKEY = {"X-Cisco-Meraki-API-Key": "xxxxxxxxxxxxxxxxx"}

--- Code omitted ---

def getClients(orgID, networkList):
    """
    Query clients for each network, return client list
    """
    clientCount = {}
    total = 0
    # Query Parameters: Return up to 100 devices seen in the past 43,200 seconds (30 days)
    q = {"perPage": "100",
         "timespan": "43200"}
    for network in networkList:
        # Query clients for each network
        queryURL = URL + f"/networks/{network}/clients"
        response = requests.get(queryURL, params=q, headers=APIKEY)
        data = json.loads(response.text)
        # Grab client OS from each device & append to clientCount dictionary
        for client in data:
            try:
                clientCount[client["os"]] += 1
            except KeyError:
                clientCount[client["os"]] = 1
            except TypeError:
                continue
            total += 1
    # Append final count of all devices & return dict
    clientCount["Total Devices"] = total
    return clientCount

def printReport(clientOS):
    """
    Print final output to terminal
    """
    print("Count of clients by operating system:")
    for OS in clientOS:
        print(f"{OS}: {clientOS[OS]}")
        
--- Code omitted ---

To keep things simple - we’ll only look at a snippet of the code. The entire example will be posted to GitHub, and contains two additional functions that will automatically find our Organization ID & Network ID.

In our getClients function, we create an empty Python dictionary to hold our list of client operating systems - and we also create a total variable which we’ll increment for every client in the list.

The HTTP GET request should look fairly similar to what we used previously. The big difference is that we’re creating a dictionary called q to hold our perPage & timespan query parameters. Then we include that in our GET request by adding params=q to the request.

Next - we convert the JSON response into a Python object, and walk through every device in that list. For each device in the list, we look at the “os” value to determine the operating system detected by Meraki. We then use a try/except block to see if we can increment the counter for that operating system. If we get a KeyError, then we know the OS isn’t currently on the list & we can just add it with a new value of 1.

After all that has been completed, we return our clientCount dictionary - which our primary function passes to the printReport function. This just prints out a header, then iterates through our clientCount dictionary and prints each operating system & count.

Let’s take a look at that output below:

matt@DESKTOP:~/postman-python$ python getOScount.py
Count of clients by operating system:
None: 9
Sailfish OS: 2
Nokia: 1
Windows 10: 2
Raspberry Pi: 2
Android: 4
Meraki OS: 1
Total Devices: 21

In the list above, we can see that we have a total of 21 devices in our network - and 7 different operating systems were found as well.

That output may not be the prettiest of reports, but it was accomplished with ~50 lines of Python & takes less than a few seconds to run. If we wanted to format the data in another way, or include data from a non-Meraki source, we absolutely could.

That’s part of what’s exciting about using Python for network automation - most anything we could think of doing is possible.

TIP: Use Postman to Generate Python Code

Okay - so I wanted to save this bit for last. Now that you’ve seen examples in both tools, I wanted to make sure we cover a feature in postman that can save some time.

So over in the right-hand side of your Postman window, you’ll see an icon that looks like this: </>

If you click that, you’ll see a dropdown menu of various languages & tools. Select one of those options and Postman will auto-generate code you can use. This auto-generated code will execute the same request you have built in the Postman GUI.

For example, our last Postman request we used to get Meraki clients:

I wanted to save this for last, because I feel like it’s important to understand how to write the code manually first - then take advantages of shortcuts after having a good understanding of what the code is doing.

That’s about all I had for this example. Again, my intent here wasn’t to create an all-inclusive resource for how to use Postman & Python - but rather to give some examples for each one & show where/why each would be used.

I’ve met a handful of people over the years who have seen many API demos using Postman, but aren’t sold yet on the value of learning Python & getting into network automation.

Hopefully these examples help bridge that gap a little bit 😄

So if you’ve read some of my recent posts - you may have seen that I purchased a NetGear LB 1121 LTE Cellular modem to use for home internet backup.

Well - I decided to upgrade!

After using the NetGear modem for a while, I started having some issues where it would disconnect from the cellular connection intermittently. Since it’s not necessarily intended for the purpose I’m using it for, there wasn’t any good way to set up monitoring for it either.

So I opted to upgrade to a Meraki MG21. This is one of the latest additions to the Meraki family of network devices & is available with internal (MG21) and external (MG21E) antenna.

I was pretty excited to get one, since Meraki tends to have decent analytics & configuration - and they make everything so easy!

We’ll walk through the setup of the MG below - but if you’re interested in seeing what the device looks like as well, definitely check out the video above!

MG Setup - Changing the APN

Okay - so after I got the SIM card inserted into the MG, the first configuration step is making sure we have the correct APN configured. As a reminder, I’m using Google Fi as my cellular provider.

This change will need to be done on the local web management interface - not from Meraki Dashboard.

When the MG powers on, by default it will hand out DHCP addresses to any device connected to port 1. At the time of writing, these addresses were in the 192.168.5.x range.

Connecting a PC directly to the MG port, we should be able to reach the local management web page - either by typing in the IP address into our web browser, or using mg.meraki.com:

In my case, I could see that the MG had auto-detected my Carrier as Google Fi. However, it still had the incorrect APN.

Using the Configure tab, we can change that setting. You’ll be prompted for a username & password. By default, the username will be the serial number of the device (including dashes) with a blank password.

As shown in the screenshot above, we have a handful of options - though we’ll only care about APN.

First - change the Cellular Override option to Override SIM Settings. Then type in your APN. In my case, it’s h2g2 for Google Fi. Lastly, hit save at the bottom (just outside the view in the screenshot above).

With any luck, the modem will connect and you’ll see something like this:

The modem connects, gets an IP from the provider, and is able to validate connectivity to both the internet & Meraki Cloud.

When I originally set up my MG, I did run into some issues with this. My MG connected to the internet successfully, but said it couldn’t reach the Meraki Cloud. Not sure what caused it, but it shortly resolved itself within a few minutes. Just gotta be patient sometimes, I suppose!

Configuring the MG in Meraki Dashboard

Note: I won’t get into how to claim your device in dashboard or how to attach it to a network. If you need help, please check out the video above where I did show how to accomplish these steps

Okay! Now that our MG is configured for the correct cell network, we can log into the Meraki Dashboard and begin configuring it.

After we’ve added the MG to our network, we’ll see a new Cellular Gateway menu:

We’ll start first by going over to Configure > Settings

First section we’ll see is for Addressing & NAT:

As of today, the MG doesn’t support any form of direct internet pass-through. Instead, our only option is routed mode - where the MG will hold the IP provided by our Carrier & NAT any requests from the devices behind it.

We can change the DHCP subnet configuration here, which will affect what IP addresses are handed to clients behind the MG. In my case, I’m connecting this directly to a firewall as a secondary internet uplink - so the addressing & subnet doesn’t matter as much. By default, the MG will always consume the first available address as it’s own.

Next, we have a section for DHCP & subnets:

Here we can change our DHCP lease time, and what DNS servers are provided to our clients. The DNS setting does have pre-defined options for Umbrella DNS, Google DNS, or using whatever the upstream carrier provides. You’re also welcome to manually specify which DNS servers to use.

We can also configure reserved & fixed IP addresses here.

Reserved IP ranges are IP addresses that we don’t want the MG to provide via DHCP. So if we had any statically configured IP addresses, we could reserve them here.

Fixed IP addresses are for any client that needs a DHCP address, but we want that IP assignment to be permanent. We’ll enter the client name & MAC Address here, as well as the IP we want assigned to that device. In my case, I went ahead and inserted my firewall MAC address - and I’ll just allow the firewall to get its IP via DHCP from the MG.

By default, the MG will block all inbound traffic from the cellular network. If we need to allow any traffic inbound, we can change the Port Forwarding settings:

This allows for a light configuration of an inbound NAT. Right now, I probably won’t be using this. However, I may permit VPN access into my network via the MG at a later date.

If I needed to add anything here, the MG allows us to translate an external / public IP & port to any internal IP / port combination. It appears we can even add a IP filter to permit only trusted source addresses.

Lastly - We can configure settings for Traffic Shaping:

In this section, we can throttle our cellular throughput & configure uplink monitoring.

By default, the cell bandwidth is set to unlimited - but we can drop this down if needed. In my case, I am not using an unlimited cell data plan - so I will throttle cellular speeds to preserve data & reduce charges.

In addition, we can configure one or more IP addresses to check uplink connectivity. These addresses will be used to collect loss & latency data via the cellular connection. The MG monitoring dashboard will collect & graph this data for easy insight into the performance metrics.

Note: As a word of warning, these uplink monitors are constantly sending ICMP/ping requests. If you have a limited amount of cellular data, this may consume more data than you would like. In my testing, using only one IP for uplink monitoring consumed about 70-100M per day. More on this below…

Monitoring the MG

Now we get to the good stuff! The primary reason I opted to buy an MG was for monitoring & analytics.

Back on the dashboard, if we use the lefthand menu - we’ll go over to Cellular Gateway > Monitor > Cellular Gatways. Then select our MG out of the list.

The primary summary page isn’t too exciting:

The MG does have two gigabit ethernet ports - and we’ll see the status here.

We’ll also see the connectivity history to the Meraki cloud - which in my case is nearly 100%. Seems like one very minor blip just after 4am.

We can also see the current network utilization on the MG. This is great to have - though my current utilization is pretty low… (I am using this as a backup modem, after all).

On the left side of the page, we’ll see some of the usual info we expect from a Meraki device. Current IP, location, Serial number, and IMEI. Just below the view of the screenshot, there is also an indicator for firmware version.

Onto the Uplink tab! Let’s see what we have:

First we’ll see the Configuration section. This just gives us a quick view into what settings the MG currently has.

We’ll see the current IP info provided by our carrier, and also some statistics on our cellular connection.

Just below that info, we’ll see our cellular graphs:

This is what I wanted! It’s great to see a quick view into what our active uplink traffic is - as well as look back historically at what our LTE signal quality has been.

Not pictured here - but there is also a section of graphs on this page for our uplink monitor. This is where we can see our current & historical loss & latency stats for the cellular connection. After a few days of use - I disabled the uplink monitor due to the amount of data the feature consumes.

Finally, we also have the DHCP tab:

This will show our current DHCP subnet & any clients that have been provided an address. In my case, there isn’t any current leases here - because my firewall has a fixed IP.

Performance && Considerations

I’ve had the MG running for about a week now, and wanted to provide some things to think about.

First - How does the modem perform? Well, the first day I had it set up - I was able to get ~150M download speeds using the MG’s built-in speed test utility:

That being said - I’m lucky if I get 30-50M on an average day. I might have just gotten lucky that day with some light cellular utilization in my area. Overall though, I’m pleased with the speeds I get - they’ll certainly fit my needs.

For the few days that I had the uplink monitoring running, I saw good results. Usually 0% packet loss, with a rare spike of 5-10%. Latency was a little less reliable, but usually bounced between 50-150ms. This was also much less than the NetGear modem I had been using, which averaged 200-250ms.

Speaking of uplink tests! Let’s talk about data usage….

By default, the MG communicates intermittently with the Meraki cloud - which consumes some data. By my measurement, this is usually less than 10Mb/day. No problem here.

The uplink tests, on the other hand, do consume a bit of data. I’m not sure what frequency these run on, but it’s fairly often. Even with one uplink monitor to 8.8.8.8 configured, I was seeing data usage of 70-100Mb a day.

While seeing those metrics is valuable to me, it’s also not worth the data charges. If I was using a SIM card with an unlimited data plan - no doubt I would keep this feature enabled. However, since I am paying for the cell data used - I opted to disable this feature.

The MG does still perform it’s check-ins to the Meraki Cloud - so you’ll have availability statistics & monitoring… But disabling the uplink monitor means you’ll lose the granular data on loss & latency.

Lastly, and another word of warning, when you’re actively viewing the MG monitoring page - this also consumes additional data. To demonstrate - I’ll post a snippet of the screenshot from earlier:

If you notice, all the way on the far left there was barely any activity. However, once I loaded the MG monitoring page - you begin to see minor spikes in data usage as the Meraki Cloud starts actively polling the MG for data.

In my experience so far, this isn’t a ton of data. I’ve checked in to see how the MG has been performing a few times this week, and each time has totaled around 10-15Mb of data usage.

To sum up - I’m cheap and want to avoid excess data usage. Just wanted to provide some of that info as something to be aware of.

Final Thoughts

I’m only a week in, but pretty pleased with the MG’s performance. It’s maintained a very solid & stable connection compared to the NetGear modem it replaced. The device is intended to provide LTE connectivity or backup service for business networks, so I would certainly hope it would meet my home needs :)

Outside of that, I do wish there was a little better documentation & clarity from the Meraki team on data usage. Right now their documentation only mentions the 6-8Mb of usage due to backend data to/from the Meraki Cloud:

I would be happy to see additional settings on the uplink monitor to allow me to choose the polling frequency. I feel like throttling down the amount of requests could reduce data to a point where I would be comfortable re-enabling that feature.

Oh - and currently there are no native email alerts for the MG. So if the MG goes offline, etc… there is no alerting from the Meraki Dashboard. This kinda sucks. I’m sure this is coming soon, but for the time being I’m inclined to write my own monitor using the Dashboard APIs. (see note below!)

Overall, I’m happy with the device. Definitely looking forward to future feature & firmware updates to see where the Meraki team takes this platform!

Update 08/28/2020 - Looks like in the week since I posted this, Meraki added alerting for the MG! Now you can be notified if the cell gateway goes offline: