Certs, because.

I’ve been having a good think about what certifications to renew/take going forward, as being an IT Contractor newbie I feel it can be even more important – as I’m frequently in the shop window.

To Renew

I decided it would be unwise to let my Cisco CCNP lapse, as it took be several years to achieve and that knowledge has certainly come in useful with the handful of my Support, Design & Implementation contracts these past 2 years.

A lot of people tend to go for the Troubleshoot exam to re-certify, but I felt the Switch exam would be more beneficial. Mainly so I could brush up on some of my FHRP knowledge, but also so I could get a taste for what Cisco are putting into their most recent Switch exam (300-115). I was surprised to find nothing on their new 9k switches for example.

I have not, as of yet renewed my Amazon AWS Certified Solutions Architect, but I have until Q2 2019 to do that so I have a little bit of time to determine if it’s worth it or not. I did enjoy learning and labbing the material, so I think I will.

To Take

I’ve been looking at a few different certifications, taking into consideration that I don’t want to have 3, 4, 5 certs that I’m constantly having to re-certify!

Those that I’m leaning towards looking at in 2019 are:

EC-Council Certified Ethical Hacker (CEH)

As my contracts tend to be Networks Support/Design/Security/Architecture a cyber security would be a really useful.

(ISC)2 Certified Cloud Security Professional (CCSP)

As a vendor agnostic cloud security certification this, perhaps, could be even more useful than the AWS cert.

Cisco CCIE Routing and Switching

Although I have the pre-requisite for this certification, and to achieve it would be great my view is that time would be better spent being more of a IT generalist instead of a subject matter expert in the R&S space.

Ish

February 11, 2018 0

Cisco VSS

VSS has been around for some years now, but it allows you to virtualise Cisco 6500 chassis’s and morph them into a single, logical unit. Once configured your single switching system is known as a Virtual Switching System 1440 (VSS1440*).

The main benefits include operational efficiency, a single point of management/configuration and scaling of the system’s bandwidth, i.e. pooling the resources of two chassis’s.

VSS is made up of the following:

Virtual Switch Members – these are your 6500 chassis’s
Virtual Switch Links (VSL) – These are 10Gb Ethernet connections (max of 8) and are the links between the VSM’s.

VSL’s can carry regular traffic in addition to the management comms between the two 6500’s.

VSL Links are required, however you will also want to configure fast-hello links – ideally a pair. These links provide dual active detection, i.e. if a disgruntled employee were to sever all the VSL links, the VSS would still be able to determine which switch is the active member. If these additional links are not configured you can end up with a split-brain scenario.

Split Brain

If the standby switch detects a complete loss of the VSL, it assumes the current active chassis has failed and will take over as the active member.

This is not to say your network will not have an outage, as if the VSL links were to be lost, the active switch (via the fast-hello links) will go into recovery mode. In this mode, ALL ports except the VSL ports are shut down until the VSL links recover and the switch will reload in it’s normal state.

I recently had an issue with a client where the VSL links were temporarily severed, and although we were running fast-hello links a split brain still occurred and caused a widespread outage. After the VSL links were re-patched and the switches rebooted, service was restored.

Troubleshooting this at the time, the switches did not reboot and recover automatically after the VSL links were re-established. I still ponder why…..

*1440 refers to the two Supervisor 720 cards (one in each chassis) being active at the same time, thus combined gives you 720×2 = 1440.

November 30, 2017 0

IP SLA – ICMP

Cisco IOS IP SLA is a network performance and diagnostic utility that uses real time monitoring to check the health of an IP enabled device. This involves the generation of traffic in a reliable and predictable way.

Simple ICMP Monitoring

Topology:

The routers could be geographically far apart or relatively near one another, but I want to utilise IP SLA to continuously monitor the f0/0 link on R2 from R1. Perhaps for failover purposes or the interface is getting over utilised and we want to see if this is leading to dropped packets, and we don’t have any other monitoring tools.

The configuration for your basic ICMP IP SLA is really easy as we’re only sending ICMP packets, so we don’t need to configure the destination host with a responder – we’ll get to that with another post – think VoIP!

Note IOS version used – C3725-ADVENTERPRISEK9-M, Version 12.4(25d)

Configure R1’s f0/0 interface with the following:

Once this config has taken we can run some commands to see the information we’re receiving.

Those I find most useful:

show ip sla monitor operational-state 1

Entry number – The number we configured for our ICMP IP SLA
Operations attempted – How many ICMP packets have been attempted to be sent
Operational state of entry – Is our IP SLA working or not
Latest RTT – How long in milliseconds did the last IP SLA test Round Trip Time take
Latest operation return code – Did the latest test return ok – yes!

show ip sla monitor statistics 1

Number of successes – How many packets have been sent in total
Number of failures – How many packets have failed in tot

As you can see, there’s quite a lot of good information, even with just a simple ICMP IP SLA configured.

As well as ICMP you can also configure tests such as DNS, Specific UDP + ports, TCP + ports, HTTP (really cool) and a really important one if you’re looking to roll out VoIP – UDP Jitter!

November 19, 2017 0

My Tech Visits

During the working day – over lunch usually, and when I have some time to waste I’ll frequent a number of tech related sites so I thought I’d jot them down here for reference.

Packet Pushers

http://packetpushers.net/

I don’t visit the Packet Pushers website too often, but they are probably my most frequently listened to podcast. There are some informative blog posts on their site and you can also access all of the podcasts there too.

The Register

https://www.theregister.co.uk/

The Register is easily my number one IT news website I visit. It not only has up to date news, but the writers add their own satirical/comical slant on the news, which I really like. Highly recommended.

IPSpace

http://www.ipspace.net/

IPSpace is an networking orientated blog not affiliated to any vendors (for the record) that’s run by CCIE #1354 Ivan Pepelnjak. On this blog you’ll find excellent articles, webinars, books relating to architectures, real-life solutions, technologies and more.

Packet Life

http://packetlife.net/

Packet Life is a blog by Jeremy Stretch, an extremely knowledgeable network engineer who enjoys sharing what he’s learned with his readers.

There are some fantastic networking cheat sheets on this site, along with lots of great tech posts, packet capture trace files, software and book recommendations and much, much more. Definitely worth a look.

October 22, 2017 0

Ansible & GNS3 Lab

With the constantly moving landscape in IT it’s always worth your while to get to know new stuff, if nothing more than to know what someone in a meeting is talking about.

To that extent I’ve recently been playing around with Ansible, which is a method to automate IT infrastructure – Networking kit in my realm. I’d read through a few articles on the web and so far I’ve built the beginning of a Cisco Ansible lab within GNS3 so wanted to share this with you.

Taken from the Ansible website:

“Ansible delivers simple IT automation that ends repetitive tasks and frees up DevOps teams for more strategic work.”

Or, for me as a Network Engineer, it can stop me having to log into 30 different switches to create a new vlan :p.

What I Have

At the moment I have the following setup, which I’ll run through:

2 Routers setup in GNS3
an Ubuntu server VM
Ansible comms from VM into GNS3 and the ability to run Ansible code on the Ubuntu server and retrieve output from the Routers in GNS3

How It’s Setup

Firstly I downloaded the latest Ubuntu Desktop image off their website and created myself a VM within VM Workstation in my case, but you can you Oracle Virtual Box or VM Player.

You will then want to update the VM with the latest repository code and install Ansible, so you’ll need to make sure the VM has internet access.

Update all of your packages

sudo apt-get update -y

Sudo will raise your privileges to a root user and the -y switch will accept any forthcoming yes/no prompts during the update.

2. Update your VM firewall – May be required depending on Ubuntu version

sudo ufw allow 22

3. Install Ansible on your Ubuntu VM

sudo apt-get install software-properties-common

sudo apt-add-repository ppa:ansible/ansible

sudo apt-get update -y

sudo apt-get install ansible

4. Create your lab within GNS3

Create a new project and drag a Cloud onto your topology window. Then configure your Cloud to reside on the same subnet as you plan to have your 2, 3, 4, 20 routers on.

In my case I have all of my devices on the Host-only network 1, however I have also given my Ubuntu server a second NIC, which is NAT’d to my local host so it has internet access. Oh and I changed the icon of my cloud to be a server, as it looks prettier……

5. Configure your end-hosts that you want to pull config from using Ansible. In our case these are our routers.

*Your IP’s will obviously relate to the subnet your hosts reside in and your interface will be whatever you’ve chosen.

conf t

interface fa0/0

ip address 192.168.134.25 255.255.255.0

no shut

You should now, all being well be able to ping between your Ubuntu VM and your routers, and vice versa.

R1#ping 192.168.134.131

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.134.131, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
R1#

R2#ping 192.168.134.131

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.134.131, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/12 ms
R2#

ish@ubuntu:~$ ping 192.168.134.25
PING 192.168.134.25 (192.168.134.25) 56(84) bytes of data.
64 bytes from 192.168.134.25: icmp_seq=1 ttl=255 time=9.18 ms
64 bytes from 192.168.134.25: icmp_seq=2 ttl=255 time=4.23 ms
^C
— 192.168.134.25 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.230/7.758/11.212/2.658 ms
ish@ubuntu:~$
ish@ubuntu:~$ ping 192.168.134.30
PING 192.168.134.30 (192.168.134.30) 56(84) bytes of data.
64 bytes from 192.168.134.30: icmp_seq=1 ttl=255 time=9.48 ms
64 bytes from 192.168.134.30: icmp_seq=2 ttl=255 time=11.1 ms
^C
— 192.168.134.30 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 4.042/7.733/11.194/2.785 ms
ish@ubuntu:~$

* If ping doesn’t work it’s always worth turning off your Windows firewall temporarily a re-check.

6. Configure SSH on your end-hosts

I am using 3725 series Cisco Routers in my lab – IOS c3725-adventerprisek9-mz.124-25d.bin, but you should be OK using any router image as long as it supports K9 – just remember to set that Idle PC!

conf t

ip domain name lab

crypto key generate rsa general-keys modulus 1024

aaa new-model

aaa authentication login default local

username cisco secret cisco

enable secret cisco

7. Add your end-host IP addresses to the /etc/ansible hosts file within your Ubuntu VM

ish@ubuntu:~$ cd /etc/ansible/

ish@ubuntu:/etc/ansible$ sudo nano hosts

[Routers]

R1 ansible_host=192.168.134.25

R2 ansible_host=192.168.134.30

Ctrl + x + y to save your edited file and exit out

ish@ubuntu:/etc/ansible$ cat hosts

R1 ansible_host=192.168.134.25
R2 ansible_host=192.168.134.30

ish@ubuntu:/etc/ansible$

8. Test your configuration

We can run the following command from the command line of our Ubuntu VM.

cd /etc/ansible

ansible all -m raw -a ‘show version | i uptime’ -u cisco -k

You should be prompted for the device password and if that’s entered correctly the following should be printed.

ish@ubuntu:/etc/ansible$ ansible all -m raw -a ‘show version | i uptime’ -u cisco -k
SSH password:
R2 | SUCCESS | rc=0 >>
R2 uptime is 2 hours, 4 minutes
Shared connection to 192.168.134.30 closed.

R1 | SUCCESS | rc=0 >>
R1 uptime is 2 hours, 4 minutes
Shared connection to 192.168.134.25 closed.

ish@ubuntu:/etc/ansible$

There we have it. I plan to delve into this much more and the use of Ansible Playbooks, but to simply test Ansible commands over SSH this should do nicely.

Router Config, if required, can be found here.

September 10, 2017 0

The First (of Many)

Hi, welcome to my blog. I hope in the coming weeks, months and years this blog will be filled with useful posts to interest a wide range of tech readers.

The main focus will involve aspects of my job, as a Network Security & Support Engineer, and notably revolve around Cisco, but also a few other vendors. I tend to lab plenty, therefore I plan to share these with you.

I am a Cisco Certified Networking Professional, hence the Cisco focus, but also an AWS Certified Solutions Architect, therefore expect some post on the current king of the cloud too.

Thanks for coming by.

June 5, 2017 0

Category: Cisco