Getting Started With Ansible for Cisco IOS

Ansible is well-known for it’s low entry threshold. All what’s required to get started is just one inventory file. However Cisco IOS devices require special considerations. Passwordless SSH RSA-based authentication is still a novelty and in most cases users are authenticated based on their passwords. Another problem is the lack of Python execution environment on IOS devices, which seriously limits the choice of Ansible modules that can be used. In this post I will show how to setup Ansible environment to control Cisco IOS devices

Windows-Linux File Synchronisation

My development environment usually consists of a host machine running Windows and a development Linux “headless” virtual machine. I create and edit files in a Notepad++ text editor and then transfer them over to the Linux VM. Until recently I’ve been using a hypervisor-enabled “shared” folder. However, Windows file system emulators in Linux do not support symbolic links and therefore breaks a lot of applications that rely on them. This prompted me to start looking for a new way to sync my files. That’s how I came across this new amazing file syncing app called Syncthing. Why is it amazing?

• It uses peer-to-peer architecture. User traffic is not uploaded to a centralised server and is transferred directly between peers.
• It is open-source. It doesn’t use any proprietary syncing protocols like BTSync.
• As the result of open-source nature it has big community support with clients, wrappers and extension available for any major platform.
• It is secure. All transfers are TLS-encrypted.
• It’s simple to use. Windows version installs like any other Windows app, Linux version, like any other Linux app, will take a little tinkering.
• It’s written in Golang, an extremely popular language amongst professional programmers and surely these guys can’t be Continue reading

Development Environment Setup

Before we proceed with TDD framework build it is important to have the development environment setup. In our case it will consist of two major components:

• Network Simulation Environment
• Ansible Development Environment

To simplify things I will run both of these environments on the same Virtual Machine. For network simulation I will use UnetLab, a wonderful product developed by Andrea Dainese. Currently, UnetLab is distributed as an OVA package and is available for free download on the website. To simulate network devices I will run IOU which will be interconnected to form a simple network. Finally, I will show how to setup development environment with Ansible, git and Python.

Building a Simple Network TDD Framework

In the following series of posts I will show how to build a simple Test-Driven Development framework for Cisco devices. This framework will allow a network engineer to define traffic patterns in a human-readable format and automatically check if those assumption hold. It will be built as a series of Ansible modules and playbooks. The idea is to show an example of how programming can be used by network engineers even now, before all devices acquire their own APIs as well as introduce some well-known programming paradigms and best practices to network engineers thereby making a small step towards networking nirvana a.k.a. SDN. The reader is assumed to have only a basic networking, linux and python programming skills.

iBGP Fall-over Trick

BGP fall-over is a neat BGP convergence optimisation technique whereby BGP peering is brought down as soon as the route to neighbor disappears from a routing table. The difference between external and internal BGP is that the former usually peers over a directly-attached interface so that when the interface to neighbor is disconnected, route is withdrawn from the routing table which triggers eBGP fall-over to bring down the neighborship. iBGP, on the other hand, normally uses device loopbacks to establish peering sessions. What this means is if a summary or a default route is present in the routing table (either static or learned via IGP), there is always a route to iBGP neighbor. In this case BGP has to wait for default 180 seconds (3 x keepalive timer) to bring down the neighborship and withdraw all the routes learned from dead neighbor.
To overcome that there’s a route-map option for a neighbor fall-over command which allows user to specify the exact prefix for which to look in the routing table. In the example below, the router will look for specific host routes representing neighbor’s loopbacks and will trigger reconvergence as soon as those routes disappear.

Structured Approach to Troubleshooting of L3VPN Networks

With the amount of configuration involved in a typical L3VPN configuration, troubleshooting process can get pretty chaotic, especially in a time-constrained environments like CCIE lab. That’s why it is extremely important to have a well-structured approach to quickly narrow down the potential problem area. I used the below algorithm while preparing for my lab exam. Like most of the networking problems, troubleshooting of L3VPNs can and must be split into two different phases - control plane and data plane. All steps must be done sequentially with each next step relying on the successful verification of all previous steps.

Problem definition

CE-1 (10.0.0.1) can not reach CE-2 (10.0.0.2)

Enterprise IP Routing Best Practices

What motivated me to write this post is a state of the IP routing of some of the enterprise networks I’ve seen. A quick show ip route command reveals a non-disentanglable mixture of dynamic and static route with multiple points of redistribution and complex, rigid filtering rules, something you’d only see in your bad dream or a CCIE-level lab. It certainly takes a good engineer to understand how it works and even that can take up to several hours. I think the reason for that is that people have generally been concentrated on learning about the routing protocol, how it works, all the knobs you can twist to influence a routing decision logic. However, one thing often overlooked is the routing protocols best practice design, i.e. when and how to use a particular protocol. And since the latter is often an acquired skill, a lot of not-so-lucky engineers end up with wrong ideas and concepts in the heads. Below I’ll try to list what I{:.underline} consider a best practice design of today’s enterprise networks.

Enterprise IP Routing Best Practices

What motivated me to write this post is a state of the IP routing of some of the enterprise networks I’ve seen. A quick show ip route command reveals a non-disentanglable mixture of dynamic and static route with multiple points of redistribution and complex, rigid filtering rules, something you’d only see in your bad dream or a CCIE-level lab. It certainly takes a good engineer to understand how it works and even that can take up to several hours. I think the reason for that is that people have generally been concentrated on learning about the routing protocol, how it works, all the knobs you can twist to influence a routing decision logic. However, one thing often overlooked is the routing protocols best practice design, i.e. when and how to use a particular protocol. And since the latter is often an acquired skill, a lot of not-so-lucky engineers end up with wrong ideas and concepts in the heads. Below I’ll try to list what I{:.underline} consider a best practice design of today’s enterprise networks.