I was recently asked to automate the way a client handles Cisco IOS upgrades. As I’ve been using Ansible a lot lately I decided to start there. Basically the steps required to do the upgrade can be broken down into parts which map quite nicely to tasks in an Ansible playbook. Even if you aren’t using IOS you might find it interesting to see how different Ansible modules can be combined in order to complete a set of tasks.
Even if you have tools in place to automate your network configuration, there’s a good chance that someone has made some manual changes. Perhaps some of your routers were overlooked the last time you send out that access-list, or a new site has been deployed using an old template. In those situations you want to audit the configuration of your network devices. Network configuration audit is one of the features of Nelkit.
Until there is a universal standard which states how to access network devices I believe SNMP is the best option when it comes to determining what a device actually is. While SNMP’s glory days might be long gone, if there in fact were any. There are still some instances where SNMP is more handy than the modern APIs we have now. All network devices respond in the same way to SNMP queries. This can be compared to a REST API where you have to know the URL of the API before you can target a device. Even with SSH which is also a standard the implementation differs between various vendors, while this doesn’t matter if you are connecting to the device manually it does if you are using a script. Looking at Netmiko a Python library for SSH, you have to specify device vendor and class when you connect. This is because SSH doesn’t work the same with Cisco devices, compared to HP devices, as prompts and paging work differently. However with SNMP it always works the same, sure all vendors have specific MIBs that they use. But general queries for standard MIBs work the same. Using a standard MIB it’s possible to identify the manufacturer of a device and often it’s version.
The easiest way to describe Ansible is that it’s a simple but powerful it-automation tool. In the words of its creator Michael DeHaan “I wanted a tool that I could not use for 6 months, come back later, and still remember how it worked.” and it really feels like riding a bike. Even years from now when I take a look at an Ansible Playbook I’m sure I will immediately see what it does. Playbooks, which allows you to run several tasks together, are writting in YAML making them easy to read. This guide is too short to teach you everything about Ansible. Instead the aim is to give you an idea of how you can use Ansible, and how it can help you manage your IT environment. Even if you don’t end up using Ansible, learning tools like it as Chef or Puppet can help you to think differently about how you operate your network.
Once you’ve setup your Cisco ASA, you will want to monitor it to ensure that it’s operating normally. The plugin nm_check_asa_connections for Nagios, and compatible products, can warn your if the number of current connections gets too high. A very high connection count might indicate that there’s an attack under way on one of your servers, you have some hosts on your inside which are part of a botnet and is attacking someone else, or perhaps you’re just about to grow out of your current firewall and need an upgrade to a more powerful box.
When you’re setting up your monitoring configuration for Nagios or compatible software it can be a hassle to decide which interfaces you actually want to monitor. Well rather how to monitor those interfaces. The nm_check_admin_up_oper_down plugin (part of Nelmon) checks the configuration of your network devices and reports a problem if you’ve indicated that the interface should be up.
You know those times when you paste innocuous config to a router and it just freezes up on you? Even if you know you’ve done nothing wrong it can be a few scary seconds until the router starts to respond again. While reading up on onePK I was trying to come up with a use case. Though I eventually thought about some other things that would actually be useful. The very first thing that came to mind was something to test just for fun. The prank Picture this; You ask a co-worker to login to a router and shutdown an interface which won’t be used anymore. Your colleague logs into the device and disables the interface and the session hangs. Only it doesn’t just hang, it’s dead and apparently your colleague can’t ping the device now. At this point it can be a good idea to ask your co-worker about what exactly he changed.
Even with people who work in networking, as soon as you say the word “firewall” a lot of people tend to stare at that far away place that only exists in their minds. I think some of this comes from the fact that “it’s not a router”. Another reason is that people just haven’t taken the time to get familiar with firewalls. The ASA is Ciscos firewall or VPN device. Though the ASA can do a lot of things, in this post I will cover the basics such as how you set it up and connect the device to the Internet.
It’s now over 10 years since I released the first version of SYDI-Server, back in August 2004. During the first years I wrote quite a bit of code and kept adding features to the different scripts. However, the last version SYDI-Server 2.3 was released in 2009. So one could say that development has slowed down a bit. However even today it gets a few hundred downloads every week. Even today I keep getting emails from people who’ve just found SYDI for the first time and are loving it.
At times when I look at the tools available for server admins today I long for the times when I didn’t work in networking. Sure we can use tools like Puppet and Ansible for networking too. However the tools are made for servers. Of course there are tie-ins into network automation, but the functionality is rudimentary at best. The current problem as I see it is the lack of decent APIs, granted some vendors are better than others. And I haven’t had the pleasure of working with those who understand XML. Sometime in a not too distant future when we have flying skateboards, SDN and nano bots these problems will disappear, but we’re not there yet. Before I take a deep dive to see what’s actually possible to do with onePK, OpenDaylight and all that good stuff I wanted to see how much is possible to do today. So this post is about Ansible which is really simple to learn and SNMP, where one of the words in the acronym is “simple”. It should be a perfect match, right?