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?
If you’ve decided to try Nagios and install it through your distributions packaging system, you might notice that the version you get is quite old. Some features or addons you want might not work with earlier releases. So you decide to download the Nagios tarballs and install the old fashioned way. Though not as simple as just typing ‘yum install nagios’ or ‘apt-get install nagios3’, you really get the sense that you’ve done something. A problem with this approach is if you have to replicate it later, you might have forgotten some configure option you used or lost the list of prerequisites for various plugins. In a perfect world you would always document your setup. Unfortunately a lot of people don’t live in that perfect world. However on the bright side, there are tools like Ansible which lets you automate a lot of tasks. Another benefit in this case is that Ansible Playbooks also can serve as s system documentation.
RANCID is a config differ. In itself that’s just as boring as it sounds. However picture this; you’ve just arrived at the office after a maintenance window. End users have started to complain about systems which have stopped working. The technicians who worked during the night are sleeping and they seemed to have forgotten to document what they did. If you had it installed RANCID could have told you exactly what configuration the technicians changed. Aside from showing you what changed during last night RANCID shows you all the changes since it was introduced. So if you hade been using RANCID for three years it could show you all the changes on all your network devices since that time. Having all your configurations stored on the RANCID server also works as a backup. Though great for collecting device configurations you can also use RANCID to get specific information from your devices by sending a command to several nodes, such as “show ip route” or “show crypto pki certificates”. Taking it a step further you can use it to change configurations, so if you need to change an access list on all firewalls or routers you can use RANCID to do so. Though RANCID might not be perfect, it’s really simple to use. If you don’t have anything like it RANCID will be a great tool for you.