Building network automation solutions

9 module online course

Start now!

Category: labs

Using Virtual Labs When Developing Network Automation Solutions

One of the fundamentals I always emphasize in introductory parts of my network automation workshops and online courses is the fact that we’re about to develop software that will control the most-mission-critical part of IT infrastructure, and should therefore use software development methodologies like version control, testing…

However, there’s a “small” glitch. While it’s perfectly possible to test most software in some virtual environment you can spin up on-the-fly using Vagrant, Docker, Jenkins, Travis, or some other CI/CD tool, testing a network automation solution requires access to network devices.

read more see 3 comments

Network Automation Development Environments

Building the network automation lab environment seems to be one of the early showstoppers on everyone’s network automation journey. These resources might help you get started:

Hint: after setting up your environment, you might want to enroll into the Spring 2019 network automation course ;)

add comment

Isn’t Quagga extinct?

Those readers that have been discussing technical issues with me probably know that I rarely write something without testing it first. Somehow I didn’t feel like powering up our spare CRS, so you might wonder how I’ve tested the interoperability between four-byte AS implementations and Cisco IOS. Fortunately, there’s open-source routing protocol software suite named Quagga (which is an extinct subspecies of zebra in the real world) that has already implemented the new BGP standards and allowed me to do all the tests with just a router and a Linux host.

To help you get started, I wrote an article in the CT3 wiki describing the Quagga installation and configuration process on Fedora Linux.

[email protected]: Quagga is also available as binary package (RPM) for Red Hat/CentOS/Fedora, Solaris, Debian and Gentoo, but you'll most probably get at least a year old version. Vitaliy Gladkevitch provided RPM installation instructions.

see 8 comments

Free testing of IINS remote lab exercises

Our remote lab team has made the Implementing Cisco IOS Network Security remote lab exercises available free-of-charge to ten students. To get access to them, fill in the registration form using 2CE00A as the promotion code (and be quick). You'll get access to all 12 IINS remote lab exercises that you can launch until October 12th. The only thing we expect in return is that you actually use them and report your opinion using the "customer satisfaction" surveys that will be mailed to you after each exercise.

The IINS course is the recommended training for the CCNA Security certification.

add comment

Create initial router configurations from dynagen topology

I've always considered building (almost identical) initial router configurations a waste of time, more so when I had to enter them manually, enabling interfaces, configuring IP addresses and Frame Relay subinterfaces on the fly … as well as entering dozens of commands that I feel should be present in every router configuration.

When I finally had enough, I've stopped my non-critical lab tests for a few weeks (that's why there's still no answer on the very good question whether the NBAR started by NAT is of any use) and wrote configMaker: a PERL script that parses dynagen lab topology and produces initial router configurations based on a template file that you can adjust to your own needs. Read more about it in the CT3 wiki.

see 5 comments

UDP flood in Perl

If you'll ever find yourself in a situation where you'll need UDP flooding (serial line or device stress testing) but won't have a dedicated flood program available (they're usually just a few click away if you consult uncle Google), here's a Perl version of UDP flood:

# udp flood.
use Socket;
use strict;
if ($#ARGV != 3) {
  print " <ip> <port> <size> <time>\n\n";
  print " port=0: use random ports\n";
  print " size=0: use random size between 64 and 1024\n";
  print " time=0: continuous flood\n";
my ($ip,$port,$size,$time) = @ARGV;
my ($iaddr,$endtime,$psize,$pport);
$iaddr = inet_aton("$ip") or die "Cannot resolve hostname $ip\n";
$endtime = time() + ($time ? $time : 1000000);
socket(flood, PF_INET, SOCK_DGRAM, 17);

print "Flooding $ip " . ($port ? $port : "random") . " port with " .
  ($size ? "$size-byte" : "random size") . " packets" .
  ($time ? " for $time seconds" : "") . "\n";
print "Break with Ctrl-C\n" unless $time;
for (;time() <= $endtime;) {
  $psize = $size ? $size : int(rand(1024-64)+64) ;
  $pport = $port ? $port : int(rand(65500))+1;
  send(flood, pack("a$psize","flood"), 0, pack_sockaddr_in($pport, $iaddr));}
see 7 comments

Simplify your lab work

If you do a lot of tests in a router lab, you're probably getting upset when you have to retype the login and enable password whenever you log into a router. What I do in my labs is to disable VTY login, set the default privilege level to 15 and disable exec timeout (to stop the router from terminating my session).

line con 0
 exec-timeout 0 0
 privilege level 15
line vty 0 4
 exec-timeout 0 0
 privilege level 15
 no login

Obviously, this would not bring you additional points on the CCIE lab exam :)

see 2 comments