Get Hands-on with the Meraki API in the DevNet Sandbox

One of the strongest components of the Meraki platform is the consistent and simplified operational management of the network. The modern API, as an extension to the cloud managed service, makes it amazingly simple to programmatically control and manage all aspects of your network. There are customers that fully automate the onboarding of devices via the Meraki portal using routine automation scripts. Or, front-end systems or operational teams with lookup tools that pull analytics or data from the API. Thus, greatly streamlining operational processes required to support an organization.

This blog will showcase some of the techniques that can be used and built upon to integrate the Meraki API programmatically. To do this we will use the DevNet always-on sandbox lab. With this we will only be making read (get) requests into the always-on sandbox. And to make this easy to use, we are going to use the Google Collaboratory environment, which allows you to use Google cloud to run these examples.

Explore the Meraki API using the DevNet Sandbox

To begin exploring the Meraki API using the DevNet Sandbox, I have created a Collaboratory on Google at the below link. To use this, you will need a few things,

1. A personal Gmail account. This will share a copy of the example that you can modify in drive. If you use your corporate account, it will only allow this if your corporation has drive access.

2. You will then access the link below and file/save a copy into drive, from which point a read only copy will become writable, and modifiable to you.

Here is the link:

https://colab.research.google.com/drive/15qs6TFn8gtsTM0PTUUbuubGLYwHJw8hV

The first thing we will do is save a copy of this read only sheet into your drive, which will make it read/write. From the file menu you can click “save a copy to drive”

Once this is done you can evaluate the sheet. Within this sheet there are text blocks, code blocks, and results blocks. The code blocks are fully modifiable, and represent code running in a real python environment located in the Google cloud. To execute the code within a block, you can click the play button to the left of the block. When you do this, any results will show up.

Where this becomes particularly interesting is when we pair this cloud based development environment with the DevNet always-on Meraki Sandbox. This is a functional Meraki instance sponsored and managed through the DevNet organization. For a list of all Sandboxes, you can evaluate devnetsandbox.cisco.com.

For our particular sandbox, we will be using the always-on sandbox. This is available at the below link, but should this link change, you can find it by selecting networking sandboxes from devnetsandbox.cisco.com. (or searching Meraki, or many other ways :)).

https://devnetsandbox.cisco.com/RM/Diagram/Index/a9487767-deef-4855-b3e3-880e7f39eadc?diagramType=Topology

Setting Variables

What we will do in the below code segments, is we set a few variables we can use further on in the code. This makes it so that you can take your real Meraki environment, and change a few URLS, and search for meaningful information in these variables (such as YOUR device, or YOUR network), and use the code to create tables and graphs that you can modify as you see fit.

After setting the variables, we do a very simple get request from Meraki, that we will do many times for different information throughout the sample on Colab.

We then print the results, which will show up in a text string of JSON data.

To translate this into real JSON we can use, we use the below command and then print it so we can see.

This is exceptionally useful as we have useful data formatted as JSON. Building upon this, we can use a library called Pandas which is well known in the data science and ML communities, and is essentially “Excel on Steroids for Python.” What becomes interesting is its native support for reading in our JSON, into a table.

Using the Pandas module

Below we load the Pandas module as the name pd, which we can reference. We then import the JSON, and print out a table with the columns we are interested in. What is elegant about this is the simplicity, we import the module, read in the JSON in a single intuitive command, and create a table with the headings we are interested in.

After doing a few more operations in the code, following through the colab sheet, we make a few more get requests, store as a few different tables, and do different things. (You can explore the sheet.) We search out the network in the organization that we referenced at the outset of this sheet, and we get the top talkers for this via doing a get on the URI and storing it as JSON. Then importing into Pandas (like below), and spitting out the table.

We now have a list of clients and their bandwidth usage. We can then very easily create graphs for usage. This can also all be done easily via a webapp for your network teams. We do this using the Pandas built-in graph capability, as well as an example of using Seaborn, which is used for data visualization.

This is just a high level of some of the capabilities that can be exposed easily via the Meraki API. The purpose of the colab sheet that was created, as well as the DevNet sandbox, is to enable you to be able to play with and evaluate the API. The examples in the colab sheet are intended to be functional code, and stepping stones that reduce the barrier to leveraging programmability to create meaningful results.

I hope this blog was helpful. It explored using the Meraki API via using the always-on DevNet Sandbox. When you have an always-on sandbox, creating, sharing, and reusing examples in Google Colaboratory is a natural fit.

Source: cisco.com

Continue reading

Exploring the Linux ‘ip’ Command

I’ve been talking for several years now about how network engineers need to become comfortable with Linux. I generally position it that we don’t all need to become “big bushy beard-bearing sysadmins.” Rather, network engineers must be able to navigate and work with a Linux-based system confidently. I’m not going to go into all the reasons I believe that in this post (if you’d like a deeper exploration of that topic, please let me know). Nope… I want to dive into a specific skill that every network engineer should have: exploring the network configuration of a Linux system with the “ip” command.

A winding introduction with some psychology and an embarrassing fact (or two)

If you are like me and started your computing world on a Windows machine, maybe you are familiar with “ipconfig” on Windows. The “ipconfig” command provides details about the network configuration from the command line.

A long time ago, before Hank focused on network engineering and earned his CCNA for the first time, he used the “ipconfig” command quite regularly while supporting Windows desktop systems.

What was the IP assigned to the system? Was DHCP working correctly? What DNS servers are configured? What is the default gateway? How many interfaces are configured on the system? So many questions he’d use this command to answer. (He also occasionally started talking in the third person.)

It was a great part of my toolkit. I’m actually smiling in nostalgia as I type this paragraph.

For old times’ sake, I asked John Capobianco, one of my newest co-workers here at Cisco Learning & Certifications, to send me the output from “ipconfig /all” for the blog. John is a diehard Windows user still, while I converted to Mac many years ago. And here is the output of one of my favorite Windows commands (edited for some privacy info).

Windows IP Configuration

   Host Name . . . . . . . . . . . . : WINROCKS

   Primary Dns Suffix  . . . . . . . :

   Node Type . . . . . . . . . . . . : Hybrid

   IP Routing Enabled. . . . . . . . : No

   WINS Proxy Enabled. . . . . . . . : No

   DNS Suffix Search List. . . . . . : example.com

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : home

   Description . . . . . . . . . . . : Intel(R) Ethernet Connection (12) I219-V

   Physical Address. . . . . . . . . : 24-4Q-FE-88-HH-XY

   DHCP Enabled. . . . . . . . . . . : Yes

   Autoconfiguration Enabled . . . . : Yes

   Link-local IPv6 Address . . . . . : fe80::31fa:60u2:bc09:qq45%13(Preferred)

   IPv4 Address. . . . . . . . . . . : 192.168.122.36(Preferred)

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Lease Obtained. . . . . . . . . . : July 22, 2022 8:30:42 AM

   Lease Expires . . . . . . . . . . : July 25, 2022 8:30:41 AM

   Default Gateway . . . . . . . . . : 192.168.2.1

   DHCP Server . . . . . . . . . . . : 192.168.2.1

   DHCPv6 IAID . . . . . . . . . . . : 203705342

   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-7B-B2-1D-24-4Q-FE-88-HH-XY

   DNS Servers . . . . . . . . . . . : 192.168.122.1

   NetBIOS over Tcpip. . . . . . . . : Enabled

Wireless LAN adapter Wi-Fi:

   Media State . . . . . . . . . . . : Media disconnected

   Connection-specific DNS Suffix  . : home

   Description . . . . . . . . . . . : Intel(R) Wi-Fi 6 AX200 160MHz

   Physical Address. . . . . . . . . : C8-E2-65-8U-ER-BZ

   DHCP Enabled. . . . . . . . . . . : Yes

   Autoconfiguration Enabled . . . . : Yes

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected

   Connection-specific DNS Suffix  . :

   Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network)

   Physical Address. . . . . . . . . : C8-E2-65-A7-ER-Z8

   DHCP Enabled. . . . . . . . . . . : Yes

   Autoconfiguration Enabled . . . . : Yes

It is still such a great and handy command. A few new things in there from when I was using it daily (IPv6, WiFi, Bluetooth), but it still looks like I remember.

The first time I had to touch and work on a Linux machine, I felt like I was on a new planet. Everything was different, and it was ALL command line. I’m not ashamed to admit that I was a little intimidated. But then I found the command “ifconfig,” and I began to breathe a little easier. The output didn’t look the same, but the command itself was close. The information it showed was easy enough to read. So, I gained a bit of confidence and knew, “I can do this.”

When I jumped onto the DevNet Expert CWS VM that I’m using for this blog to grab the output of the “ifconfig” command as an example, I was presented with this output.

(main) expert@expert-cws:~$ ifconfig

Command 'ifconfig' not found, but can be installed with:

apt install net-tools

Please ask your administrator.

This brings me to the point of this blog post. The “ifconfig” command is no longer the best command for viewing the network interface configuration in Linux. In fact, it hasn’t been the “best command” for a long time. Today the “ip” command is what we should be using.  I’ve known this for a while, but giving up something that made you feel comfortable and safe is hard. Just ask my 13-year-old son, who still sleeps with “Brown Dog,” the small stuffed puppy I gave him the day he was born. As for me, I resisted learning and moving to the “ip” command for far longer than I should have.

Eventually, I realized that I needed to get with the times. I started using the “ip” command on Linux. You know what, it is a really nice command. The “ip” command is far more powerful than “ifconfig.”

When I found myself thinking about a topic for a blog post, I figured there might be another engineer or two out there who might appreciate a personal introduction to the “ip” command from Hank.

But before we dive in, I can’t leave a cliffhanger like that on the “ifconfig” command.

root@expert-cws:~# apt-get install net-tools

(main) expert@expert-cws:~$ ifconfig

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255

        ether 02:42:9a:0c:8a:ee  txqueuelen 0  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens160: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 172.16.211.128  netmask 255.255.255.0  broadcast 172.16.211.255

        inet6 fe80::20c:29ff:fe75:9927  prefixlen 64  scopeid 0x20

        ether 00:0c:29:75:99:27  txqueuelen 1000  (Ethernet)

        RX packets 85468  bytes 123667981 (123.6 MB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 27819  bytes 3082651 (3.0 MB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10

        loop  txqueuelen 1000  (Local Loopback)

        RX packets 4440  bytes 2104825 (2.1 MB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 4440  bytes 2104825 (2.1 MB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

There it is, the command that made me feel a little better when I started working with Linux.

Exploring the IP configuration of your Linux host with the “ip” command!

So there you are, a network engineer sitting at the console of a Linux workstation, and you need to explore or change the network configuration. Let’s walk through a bit of “networking 101” with the “ip” command.

First up, let’s see what happens when we just run “ip.”

(main) expert@expert-cws:~$ ip

Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }

       ip [ -force ] -batch filename

where  OBJECT := { link | address | addrlabel | route | rule | neigh | ntable |

                   tunnel | tuntap | maddress | mroute | mrule | monitor | xfrm |

                   netns | l2tp | fou | macsec | tcp_metrics | token | netconf | ila |

                   vrf | sr | nexthop }

       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |

                    -h[uman-readable] | -iec | -j[son] | -p[retty] |

                    -f[amily] { inet | inet6 | mpls | bridge | link } |

                    -4 | -6 | -I | -D | -M | -B | -0 |

                    -l[oops] { maximum-addr-flush-attempts } | -br[ief] |

                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] |

                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] | -a[ll] |

                    -c[olor]}

There’s some interesting info just in this help/usage message. It looks like “ip” requires an OBJECT on which a COMMAND is executed. And the possible objects include several that jump out at the network engineer inside of me.

◉ link – I’m curious what “link” means in this context, but it catches my eye for sure

◉ address – This is really promising. The ip “addresses” assigned to a host is high on the list of things I know I’ll want to understand.

◉ route – I wasn’t fully expecting “route” to be listed here if I’m thinking in terms of the “ipconfig” or “ifconfig” command. But the routes configured on a host is something I’ll be interested in.

◉ neigh – Neighbors? What kind of neighbors?

◉ tunnel – Oooo… tunnel interfaces are definitely interesting to see here.

◉ maddress, mroute, mrule – My initial thought when I saw “maddress” was “MAC address,” but then I looked at the next two objects and thought maybe it’s “multicast address.” We’ll leave “multicast” for another blog post.

The other objects in the list are interesting to see. Having “netconf” in the list was a happy surprise for me. But for this blog post, we’ll stick with the basic objects of link, address, route, and neigh.

Where in the network are we? Exploring “ip address”

First up in our exploration will be the “ip address” object. Rather than just go through the full command help or man page line (ensuring no one ever reads another post of mine), I’m going to look at some common things I might want to know about the network configuration on a host. As you are exploring on your own, I would highly recommend exploring “ip address help” as well as “man ip address” for more details.  These commands are very powerful and flexible.

What is my IP address?

(main) expert@expert-cws:~$ ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether 00:0c:29:75:99:27 brd ff:ff:ff:ff:ff:ff

    inet 172.16.211.128/24 brd 172.16.211.255 scope global dynamic ens160

       valid_lft 1344sec preferred_lft 1344sec

    inet6 fe80::20c:29ff:fe75:9927/64 scope link 

       valid_lft forever preferred_lft forever

3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 

    link/ether 02:42:9a:0c:8a:ee brd ff:ff:ff:ff:ff:ff

    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

       valid_lft forever preferred_lft forever

Running “ip address show” will display the address configuration for all interfaces on the Linux workstation. My workstation has 3 interfaces configured, a loopback address, the ethernet interface, and docker interface. Some of the Linux hosts I work on have dozens of interfaces, particularly if the host happens to be running lots of Docker containers as each container generates network interfaces. I plan to dive into Docker networking in future blog posts, so we’ll leave the “docker0” interface alone for now.

We can focus our exploration by providing a specific network device name as part of our command.

(main) expert@expert-cws:~$ ip add show dev ens160

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether 00:0c:29:75:99:27 brd ff:ff:ff:ff:ff:ff

    inet 172.16.211.128/24 brd 172.16.211.255 scope global dynamic ens160

       valid_lft 1740sec preferred_lft 1740sec

    inet6 fe80::20c:29ff:fe75:9927/64 scope link 

       valid_lft forever preferred_lft forever

Okay, that’s really what I was interested in looking at when I wanted to know what my IP address was. But there is a lot more info in that output than just the IP address. For a long time, I just skimmed over the output. I would ignore most output and simply look at the address and for state info like “UP” or “DOWN.” Eventually, I wanted to know what all that output meant, so in case you’re interested in how to decode the output above…

• Physical interface details
• “ens160” – The name of the interface from the operating system’s perspective.  This depends a lot on the specific distribution of Linux you are running, whether it is a virtual or physical machine, and the type of interface.  If you’re more used to seeing “eth0” interface names (like I was) it is time to become comfortable with the new interface naming scheme.
• “<BROADCAST,MULTICAST,UP,LOWER_UP>” – Between the angle brackets are a series of flags that provide details about the interface state.  This shows that my interface is both broadcast and multicast capable and that the interface is enabled (UP) and that the physical layer is connected (LOWER_UP)
• “mtu 1500” – The maximum transmission unit (MTU) for the interface.  This interface is configured for the default 1500 bytes
• “qdisc mq” – This indicates the queueing approach being used by the interface.  Things to look for here are values of “noqueue” (send immediately) or “noop” (drop all). There are several other options for queuing a system might be running.
• “state UP”- Another indication of the operational state of an interface.  “UP” and “DOWN” are pretty clear, but you might also see “UNKNOWN” like in the loopback interface above.  “UNKNOWN” indicates that the interface is up and operational, but nothing is connected.  Which is pretty valid for a loopback address.
• “group default” – Interfaces can be grouped together on Linux to allow common attributes or commands.  Having all interfaces connected to “group default” is the most common setup, but there are some handy things you can do if you group interfaces together.  For example, imagine a VM host system with 2 interfaces for management and 8 for data traffic.  You could group them into “mgmt” and “data” groups and then control all interfaces of a type together.
• “qlen 1000” – The interface has a 1000 packet queue.  The 1001st packet would be dropped.
• “link/ether” – The layer 2 address (MAC address) of the interface
• “inet” – The IPv4 interface configuration
• “scope global” – This address is globally reachable. Other options include link and host
• “dynamic” – This IP address was assigned by DHCP.  The lease length is listed in the next line under “valid_lft”
• “ens160” – A reference back to the interface this IP address is associated with
• “inet6” – The IPv6 interface configuration.  Only the link local address is configured on the host.  This shows that while IPv6 is enabled, the network doesn’t look to have it configured more widely

Network engineers link the world together one device at a time. Exploring the “ip link” command.

Now that we’ve gotten our feet wet, let’s circle back to the “link” object. The output of “ip address show” command gave a bit of a hint at what “link” is referring to. “Links” are the network devices configured on a host, and the “ip link” command provides engineers options for exploring and managing these devices.

What networking interfaces are configured on my host?

(main) expert@expert-cws:~$ ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

    link/ether 00:0c:29:75:99:27 brd ff:ff:ff:ff:ff:ff

3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 

    link/ether 02:42:9a:0c:8a:ee brd ff:ff:ff:ff:ff:ff

After exploring the output of “ip address show,” it shouldn’t come as a surprise that there are 3 network interfaces/devices configured on my host.  And a quick look will show the output from this command is all included in the output for “ip address show.”  For this reason, I almost always just use “ip address show” when looking to explore the network state of a host.

However, the “ip link” object is quite useful when you are looking to configure new interfaces on a host or change the configuration on an existing interface. For example, “ip link set” can change the MTU on an interface.

root@expert-cws:~# ip link set ens160 mtu 9000

root@expert-cws:~# ip link show dev ens160

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000

    link/ether 00:0c:29:75:99:27 brd ff:ff:ff:ff:ff:ff

Note 1: Changing network configuration settings requires administrative or “root” privileges.

Note 2: The changes made using the “set” command on an object are typically NOT maintained across system or service restarts. This is the equivalent of changing the “running-configuration” of a network device. In order to change the “startup-configuration” you need to edit the network configuration files for the Linux host.  Check the details for network configuration for your distribution of Linux (ie Ubuntu, RedHat, Debian, Raspbian, etc.)

Is anyone else out there? Exploring the “ip neigh” command

Networks are most useful when other devices are connected and reachable through the network. The “ip neigh” command gives engineers a view at the other hosts connected to the same network. Specifically, it offers a look at, and control of, the ARP table for the host.

Do I have an ARP entry for the host that I’m having trouble connecting to?

A common problem network engineers are called on to support is when one host can’t talk to another host.  If I had a nickel for every help desk ticket I’ve worked on like this one, I’d have an awful lot of nickels. Suppose my attempts to ping a host on my same local network with IP address 172.16.211.30 are failing. The first step I might take would be to see if I’ve been able to learn an ARP entry for this host.

(main) expert@expert-cws:~$ ping 172.16.211.30

PING 172.16.211.30 (172.16.211.30) 56(84) bytes of data.

^C

--- 172.16.211.30 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 2039ms

(main) expert@expert-cws:~$ ip neigh show

172.16.211.30 dev ens160  FAILED

172.16.211.254 dev ens160 lladdr 00:50:56:f0:11:04 STALE

172.16.211.2 dev ens160 lladdr 00:50:56:e1:f7:8a STALE

172.16.211.1 dev ens160 lladdr 8a:66:5a:b5:3f:65 REACHABLE

And the answer is no. The attempt to ARP for 172.16.211.30 “FAILED.”  However, I can see that ARP in general is working on my network, as I have other “REACHABLE” addresses in the table.

Another common use of the “ip neigh” command involves clearing out an ARP entry after changing the IP address configuration of another host (or hosts). For example, if you replace the router on a network, a host won’t be able to communicate with it until the old ARP entry ages out and the system tries ARPing again for a new address. Depending on the operating system, this can take minutes — which can feel like years when waiting for a system to start responding again. The “ip neigh flush” command can clear an entry from the table immediately.

How do I get from here to there? Exploring the “ip route” command

Most of the traffic from a host is destined somewhere on another layer 3 network, and the host needs to know how to “route” that traffic correctly. After looking at the IP address(es) configured on a host, I will often take a look at the routing table to see if it looks like I’d expect. For that, the “ip route” command is the first place I look.

What routes does this host have configured?

(main) expert@expert-cws:~$ ip route show

default via 172.16.211.2 dev ens160 proto dhcp src 172.16.211.128 metric 100 

10.233.44.0/23 via 172.16.211.130 dev ens160 

172.16.211.0/24 dev ens160 proto kernel scope link src 172.16.211.128 

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 

It may not look exactly like the output of “show ip route” on a router, but this command provides very usable output.

◉ My default gateway is 172.16.211.2 through the “ens160” device.  This route was learned from DHCP and will use the IP address configured on my “ens160” interface.

◉ There is a static route configured to network 10.233.44.0/23 through address 172.16.211.130

◉ And there are 2 routes that were added by the kernel for the local network of the two configured IP addresses on the interfaces.  But the “docker0” route shows “linkdown” — matching the state of the “docker0” interface we saw earlier.

The “ip route” command can also be used to add or delete routes from the table, but with the same notes as when we used “ip link” to change the MTU of an interface. You’ll need admin rights to run the command, and any changes made will not be maintained after a restart. But this can still be very handy when troubleshooting or working in the lab.

And done… or am I?

So that’s is my “brief” look at the “ip” command for Linux. Oh wait, that bad pun attempt reminded me of one more tip I meant to include. There is a “–brief” option you can add to any of the commands that reformats the data in a nice table that is often quite handy. Here are a few examples.

(main) expert@expert-cws:~$ ip --brief address show

lo               UNKNOWN        127.0.0.1/8 ::1/128 

ens160           UP             172.16.211.128/24 fe80::20c:29ff:fe75:9927/64 

docker0          DOWN           172.17.0.1/16 

(main) expert@expert-cws:~$ ip --brief link show

lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 

ens160           UP             00:0c:29:75:99:27 <BROADCAST,MULTICAST,UP,LOWER_UP> 

docker0          DOWN           02:42:9a:0c:8a:ee <NO-CARRIER,BROADCAST,MULTICAST,UP> 

Not all commands have a “brief” output version, but several do, and they are worth checking out.

There is quite a bit more I could go into on how you can use the “ip” command as part of your Linux network administration skillset. (Checkout the “–json” flag for another great option). But at 3,000+ words on this post, I’m going to call it done for today. If you’re interested in a deeper look at Linux networking skills like this, let me know, and I’ll come back for some follow-ups. 

Source: cisco.com

Continue reading

How to Contribute to Open Source and Why

Getting involved in the open-source community (especially early in your career) is a smart move for many reasons. When you help others, you almost always get help in return. You can make connections that can last your entire career, helping you down the road in ways you can’t anticipate.

In this article, we’ll cover more about why you should consider contributing to open source, and how to get started.

Why Should I Get Involved in Open Source?

Designing, building, deploying, and maintaining software is, believe it or not, a social activity. Our tech careers place us in a network of bright and empathetic professionals, and being in that network is part of what brings job satisfaction and career opportunities.

Nowhere in tech is this more apparent than in the world of free and open-source software (FOSS). In FOSS, we build in public, so our contributions are highly visible and done together with like-minded developers who enjoy helping others. And by contributing to the supply of well-maintained open-source software, we make the benefits of technology accessible around the world.

Where Should I Contribute?

If you’re looking to get started, then the first question you’re likely asking is: Where should I get started? A great starting place is an open-source project that you have used or are interested in.

Most open-source projects store their code in a repository on GitHub or GitLab. This is the place where you can find out what the project’s needs are, who the project maintainers are, and how you can contribute. Because of the collaborative and generous culture of FOSS, maintainers are often receptive to unsolicited offers of help. Often, you can simply reach out to a maintainer and offer to contribute.

For example, are you interested in contributing to Django? They make it very clear: We need your help to make Django as good as it can possibly be.

Finding known issues

Most projects keep a list of known issues. You can find a task that fits your knowledge and experience level. For example, the list of issues for Flask shows the following:

Finding tasks for new contributors

Finally, many maintainers take the time to mark specific issues as being better for new contributors. For example, the Electron project applies a “good first issue” label. Notice the “Labels” selector on GitHub. You can use this to filter, showing you the best issues to start with.

Now you’ve got an issue to work on. How should you get started?

The Contribution Process

The basic process for contributing to open source is fairly uniform across all projects. However, you should still read the contributor guidelines for an individual project to be aware of any special requirements.

In general, the process looks like this:

1. Fork the project repository

2. Solve the issue

3. Submit a pull request

4. Wait for feedback

Let’s examine each of these steps in detail. We’ll use GitHub for our examples; most online repositories will operate similarly.

Fork the Project Repository

When you fork a project repository, you create a local copy of the project to do your work on. After you have your own copy, be sure to read any special instructions in the project README so that you can get the project up and running on your machine.

In GitHub, you can simply use the “Fork” button to start this. You’ll find it in the upper-right part of your screen:

As you save the forked repository to your account, you’ll be prompted to provide a name for it.

Solve the Issue

With a forked local copy up and running, you’re now ready to tackle the issue at hand. As you solve the issue, it’s important to keep a few things in mind:

◉ Pay attention to any coding style guidelines provided for the project.

◉ Make sure the project will run as expected, and that any provided tests pass.

◉ Comment your code as needed to help future developers.

Now that you’ve got a solution in place, it’s time to present your solution to the project maintainers.

Submit a Pull Request

The maintainers of the project need to review your proposed changes before they (hopefully) merge those changes into the main project repository. You kick off this process by submitting a pull request (PR).

Open a new PR

You can start PR creation in GitHub right from the original repository by clicking on New pull request on the Pull requests page.

Set up the branch comparison

On the Compare changes page, click on compare across forks.

Choose the branch to merge

When creating a pull request, it’s very important to pay close attention to which branch you want to merge.

The branch in the original repository

First, select the desired branch that the code changes will merge into. Typically this will be the main branch in the original repository, but be sure to check the contributor guidelines.

The branch in your forked repo

Next, select the branch from your forked repository where you did the work.

Give your PR a title and description

Next, you’ll need to provide a title and description for your pull request. Don’t be overly wordy. You can explain your approach, but you should let your code and comments speak for themselves. Maintainers are often tight on time. Make your PR easy to read and review.

Some repositories provide template content for the PR description, and they include a checklist of items to ensure all contributors adhere to their process and format. Pay attention to any special instructions you’ve been given.

Create the pull request

After making sure you’ve provided everything the maintainers are asking for, click Create Pull Request.

You’ve done it! You have submitted your first PR for an open-source project!

Wait for Feedback

You’re likely anxious to hear back on your PR. Again, check the contributor guidelines for what to expect here. Often, it will be some time until you hear back, and maintainers may not want you to nudge them.

If there are any points to address in your PR, maintainers will probably have that conversation with you as a thread in the PR. Watch your email for notifications. Try to respond quickly to comments on your PR. Maintainers appreciate this.

If you need to refactor your code, do so, and then commit the changes. You likely will not need to notify the maintainer, but you should check the contributor guidelines to be sure. The platform (in our case, GitHub) will notify the maintainers of the commit, so they’ll know to look at the PR again.

Source: cisco.com

Continue reading

Secure and Simplify Your Programmable Edge and Industrial Sensors

The Cisco IoT Operations Dashboard provides operations teams with a centralized, cloud-based dashboard to securely deploy, monitor, and troubleshoot device connectivity. Using this secure connectivity as a foundation, that same dashboard then enables you to extract, transform, govern and deliver data from IoT edge devices to the cloud with Cisco Edge Intelligence, install and manage your containerized edge applications and to deploy a broad range of industrial IoT sensors with Cisco Industrial Asset Vision.

Once your solution is in place, or as part of your solution development process, IoT Operations Dashboard enables you to securely and simply access remote connected equipment and to monitor its connectivity status, using nothing more than your browser.  This simplifies maintenance, solution development and updates, and ensures business continuity without the need for frequent and costly truck rolls to remote sites and locations.

With IoT Operations Dashboard, scaling up is straightforward.  Using the cloud-based dashboard, Cisco Industrial Routers and Gateways can be zero-touch provisioned at remote sites, and automatically configured with proven solution templates and configurations, helping you to streamline configuration of your devices, and reduce errors. You can then deploy your industrial IoT solutions, applications and sensors using that same dashboard. Once in operation, Dashboard provides an Operations Technology (OT) focused user experience and is simple and easy to use. Directly from the browser-based dashboard you can see map-based views of your deployments, equipment status, sensor data, events and alerts, which greatly simplifies monitoring and gaining insights into your operations.

Operations Dashboard offers a rich set of capabilities for developers and systems integrators, as well as custom solutions. And you can start right now on DevNet! The new DevNet IoT Operations Dashboard sandbox includes components such as Edge Device Manager (EDM) and Industrial Asset Vision, and we also offer an IoT Cisco Edge Intelligence (EI) sandbox.

Create templates and test remote access with the Edge Device Manager Sandbox

Custom forms called eCVDs allow you to configure Cisco Industrial Routers and Gateways to meet the exact needs of your solution. Use predefined eCVD configuration forms to leverage Cisco-provided zero-touch provisioning (ZTP) and best security practices. These can then be easily customized using the open-source Freemarker template language on which they are based.  This makes it straightforward for you to create a custom configuration form which is specific to your solution with ZTP, security and solution-specific configuration options and in-form guidance.

Using the built-in Secure Equipment Access (SEA) feature of IoT Operations Dashboard, you can then use RDP, VNC, SSH or HTTP/S to securely access remote connected equipment using just the dashboard and your browser.  SEA provides this ability for simple and secure remote access even if you are in a different organization and network to your customer’s solution, for example as a solution developer or equipment vendor.  This greatly simplifies solution development, especially for those real-world proof-of-concepts and in-field development and update activities that are often so challenging and time consuming.

Reserve our all-new EDM sandbox today for access to a real Cisco IR1101 and your own IoT Operations Dashboard organization! Test on-boarding, deploy applications, and connect via the dashboard to the Linux DevBox without any VPN configuration.

Extract all your IoT sensor data via MQTT with Industrial Asset Vision

Cisco Industrial Asset Vision (IAV) provides a complete full-stack solution that includes all hardware and software components, pre-integrated and delivered as a cloud SaaS offer. IAV includes an end-user dashboard application, network management tools, LoRaWAN network devices, and Cisco industrial sensors for collecting environmental and GPS location data.

Cisco IAV exposes APIs through which global independent software vendors (ISVs) and applications developers can integrate with systems such as enterprise resource planning (ERP), service management, manufacturing execution systems, and analytics. Asset and sensor information can also be published to 3rd party data brokers via MQTT and to Azure IoT Hub.

Industrial Asset Vision – IoT Operations Dashboard Documentation

Simplify IoT Edge-to-Multi-Cloud Data Flow with Cisco Edge Intelligence

As part of IoT Operations Dashboard, the IoT data orchestration software, Cisco Edge Intelligence, connects assets at the edge to multi-cloud application destinations in a very easy way for the user and can even extend its functionality with a transformation engine at the edge.

Source: cisco.com

Continue reading

Create, Document, and Share Live Code Examples with Jupyter Notebook

Q: How do you eat a whale?

A: One bite at a time… or so the saying goes. Admittedly, I don’t know of anyone who eats whale one bite at a time (or any way otherwise for that matter). But we can all agree that breaking large problems into smaller pieces is a valuable arrow in the quiver of problem-solving techniques. It’s a practice that certainly applies in the world of programming.

Once the problem is broken down and implemented, however, how can we convey what we learned to others? One way is using Jupyter Notebook to combine documentation authored in markdown together with live code. As an example, a developer writes small blocks of Python to vet an algorithm, a function, or syntax. Once verified, it is documented, saved, and the code is then added to the IDE, such as VSCode, where the main Python code is developed.

This post shows a simple Python example that retrieves physical compute inventory claimed in Cisco Intersight. In this example, the items in the inventory are UCS X-Series compute nodes managed by IMM (Cisco Intersight Managed Mode).

What is Jupyter Notebook?

Jupyter Notebook is an open-source web application used to create and share code along with narrative text. It’s used extensively in academia especially by data scientists. If you have experience with Python you may be familiar with IDLE (see the screenshot below). IDLE lets you execute Python code directly from the command line without needing to run a *.py file. You run your line(s) of code and verify things work and when you are finished, you close your session with <cntrl><d> and you move on with life. What if you wanted to share what you tried with someone else? Assuming you copy/pasted the contents of your shell session, would someone else be able to understand what the flow of what you were trying? Could you refer to it later and understand the flow of what you did?

IDLE does the job but it has limitations when it comes to documenting and sharing ideas. Enter Jupyter Notebook, an interactive way of documenting and executing live code from a web-based interface. It runs as an interactive web application supporting markdown and code execution with support for over 100 programming languages (called “kernels”) including Python, PowerShell, and Matlab just to name a few. I’ll show you examples in both Python and PowerShell since those are commonly used to interface with Cisco compute API’s.  

How Jupyter Notebook works – A very simple tutorial

First, be sure to first install Jupyter Notebook if it’s not already on your machine. Once installed, you can launch the browser by entering the command jupyter notebook from the command line. When the command is executed a new browser tab opens with the Jupyter notebook interface. 

In the example below, we use Python 3 as our language of choice with the first entry authored with markdown and the second “hello world” passed to the print function. For the first entry, select Markdown as the type of content to run, enter markdown syntax, followed by simultaneously pressing the <shift> and <enter> keys and voila! The markdown is rendered.

In the next entry, select Code from the highlighted pulldown, enter one or more lines of code, followed by simultaneously pressing <shift> and <enter>. The code runs and the results are displayed just below the code. Well, that was easy!

Pro Tip: Not sure what to pass else you can pass to print? Select the field where you entered the print function and followed by simultaneously pressing the <shift> and <tab> keys. You will see a documentation snippet describing the function.

Show Me a Real-World Example

The examples above are right up there with the ‘hello world’ examples you undoubtedly encountered when learning a new language. Next, let us dive into the real-world scenario of calling the Intersight API to retrieve a list of physical compute items from claimed inventory while documenting how you accomplished it.

The specifics of how to go about making the code authenticate and such are covered in the file itself for this post, the example is cut back for brevity, but you can download the code from DevNet’s Code Exchange if you would like to follow along and try it. The examples available in Python and PowerShell.

Here are the steps taken to retrieve physical compute inventory:

◉ Import the necessary Python modules

◉ Populate the AUTH variable and define the base URL

◉ Run a GET operation on the URI of compute/PhysicalSummaries

◉ Inspect the JSON data returned by the call

◉ Print the results

Documenting and Executing Code

In step 1 below, you see these steps in action broken apart into smaller pieces along with documentation explaining what each step does along with the live code. If fact, we do not need to discuss the steps in this blog since it is already contained in the Jupyter Notebook. Instead, we pass along a few pro tips.

In Step 2, instructions for installing the Python SDK and importing modules are provided with the code for each just below it. Pressing <shift><enter> runs the code and produces a result. The number of lines to execute is up to you and the instructions executed remain in memory.

Pro tip: JSON responses are often lengthy. To manage how you view the output, click the output cell, in this case cell 23. Click once and you see the smaller scrollable window, click twice and you see the full-length listing. If you double-click, the data is hidden. The screenshot below shows the cells with the results hidden.

Finally, if you skip ahead to step 6 you will see the number of UCS X-Series compute nodes currently in our inventory along with how the hardware is completely managed by Intersight by virtue of its management mode also known as IMM (Intersight Management Mode).

Source: cisco.com

Continue reading

How To Simplify Cisco ACI Management with Smartsheet

Have you ever gotten lost in the APIC GUI while trying to configure a feature? Or maybe you are tired of going over the same steps again and again when changing an ACI filter or a contract? Or maybe you have always asked yourself how you can integrate APIC with other systems such as an IT ticketing or monitoring system to improve workflows and making your ACI fabric management life easier. Whatever the case may be, if you are interested in finding out how to create your own GUI for ACI, streamline and simplify APIC GUI configuration steps using smartsheets, and see how extensible and programmable an ACI fabric is, then read on.

Innovations that came with ACI

I have always been a fan of Cisco ACI (Application Centric Infrastructure). Coming from a routing and switching background, my mind was blown when I started learning about ACI. The SDN implementation for data centers from Cisco, ACI, took almost everything I thought I knew about networking and threw it out the window. I was in awe at the innovations that came with ACI: OpFlex, declarative control, End-Point Groups (EPGs), application policies, fabric auto discovery, and so many more.

The holy grail of networking

It felt to me like a natural evolution of classical networking from VLANs and mapped layer-3 subnets into bridge domains and subnets and VRFs. It took a bit of time to wrap my head around these concepts and building underlays and overlays but once you understand how all these technologies come together it almost feels like magic. The holy grail of networking is at this point within reach: centrally defining a set of generic rules and policies and letting the network do all the magic and enforce those policies all throughout the fabric at all times no matter where and how the clients and end points are connecting to the fabric. This is the premise that ACI was built on.

Automating common ACI management activities

So you can imagine when my colleague, Jason Davis (@snmpguy) came up with a proposal to migrate several ACI use cases from Action Orchestrator to full blown Python code I was up for the challenge. Jason and several AO folks have worked closely with Cisco customers to automate and simplify common ACI management workflows. We decided to focus on eight use cases for the first release of our application:

◉ Deploy an application

◉ Create static path bindings

◉ Configure filters

◉ Configure contracts

◉ Associate EPGs to contracts

◉ Configure policy groups

◉ Configure switch and interface profiles

◉ Associate interfaces to policy groups

Using the online smartsheet REST API

You might recognize these as being common ACI fabric management activities that a data center administrator would perform day in and day out. As the main user interface for gathering data we decided to use online smartsheets. Similar to ACI APIC, the online smartsheet platform provides an extensive REST API interface that is just ripe for integrations.

The plan was pretty straight forward:

1. Use smartsheets with a bit of JavaScript and CSS as the front-end components of our application

2. Develop a Python back end that would listen for smartsheet webhooks triggered whenever there are saved Smartsheet changes

3. Process this input data based on this data create, and trigger Ansible playbooks that would perform the configuration changes corresponding to each use case

4. Provide a pass/fail status back to the user.

The “ACI Provisioning Start Point” screen allows the ACI administrator to select the

Site or APIC controller that needs to be configured.

Once the APIC controller is selected, a drop down menu displays a list of all the use

cases supported. Select to which tenant the configuration changes will be applied,

and fill out the ACI configuration information in the smartsheet.

Selecting the checkbox for Ready to Deploy, and saving the smartsheet, will trigger a webhook event that will be intercepted by the backend code and the Ansible configuration playbook will be run.

A big advantage to using Smartsheets compared to the ACI APIC GUI is that several configuration changes can be performed in parallel. In this example, several static path bindings are created at the same time.

Find the details on DevNet Automation Exchange

You can find all the details and the public repository for this application on the DevNet Automation Exchange.

You can also find hundreds of similar use case examples in the DevNet Automation Exchange covering all Cisco technologies and verticals and all difficulty levels.

Drop me a message in the comments section if you have any questions or suggestions about this automation exchange use case.

Source: cisco.com

Continue reading