Use Ansible Tags to Organise your Plays & Tasks

The Ansible tag documentation does a great job of explaining tags, tag re-used and tag inheritance.  However, I’d like to dive a little deeper to show you just how useful they can be.

To get the most out of this post you’ll need to be familiar with the ways in which you can structure your Playbooks. If you don’t know how they can be structured, or if you need a refresher, I covered this topic in both my The Anatomy of an Ansible Playbook and Ansible Playbook Structure posts.

Continue reading

Finding a Host’s Switchport

In this post I will demonstrate how we can find out which of SW3’s switchports PC1 is connected to in the topology diagram below. To make things more fun though I’ll begin my search from R1.

Note that apart from R1 and PC1’s IP addresses, we do not have nor need any other information such as intermediate device IPs or port numbers in order to get started. Also note that the diagram is only used to show you, the reader what the topology looks like. As explained below, when doing this in a real topology you do not need a topology diagram to be able to successfully locate the host’s corresponding switchport.

top1 Continue reading

A Deep Dive in OSPF LSAs, Part 7

So far in this series I’ve covered Type 1, 2 and 3 LSAs. Next I’m going to cover Type 4 and Type 5 LSAs with the help of this topology.


Before we get started though, let’s have a quick refresher on what these LSAs are used for:

  • Type 4 – ASBR-Summary LSA – this is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.
  • Type 5 – External LSA – these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas unchanged (except stub and NSSA areas). For “External Metric Type 1″ LSAs routing decisions are made using the Type 1 metric cost sent, as the total cost to get to the external destination and includes the cost to the ASBR; while for “External Type 2″ LSAs the metric sent is the cost from the ASBR to the External destination network and must be added to the OSPF cost to the ASBR advertising the Type 5. The link-state ID of the type 5 LSA is the external network number.

Continue reading

A Deep Dive in OSPF LSAs, Part 6

Up until this point I have only covered Type 1 and Type 2 LSAs in this series. I’m guessing by now you must be quite familiar with them and are interested to hear about the other LSAs, so let’s move onto Type 3’s.

This is what Wikipeda has to say about Type 3 LSAs:

  • Type 3 – Summary LSA – an Area Border Router (ABR) takes information it has learned on one of its attached areas and summarizes it before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, helping scalability. The link-state ID is the destination network number for type 3 LSAs.

While the above is true, the summarisation must be configured manually on the ABR, so I’ll delve deeper into it later on in this post. For now let’s just focus on the fact that an ABR is used to share routes between the areas which it is connected. Let’s use the topology below to demonstrate this:



Continue reading

A Deep Dive in OSPF LSAs, Part 5

In Part 3 I demonstrated how you can use Type 1 and Type 2 LSAs to map the topology an OSPF area. In this post we’ll do the reverse. By looking at a network diagram below, you should be able to determine the following:

  1. Who will be sending Type 1 LSAs?
  2. How many Type 1 LSA entries will there be?
  3. What will the “Link Count” be for each of the Type 1 LSA entries?
  4. Who will be sending Type 2 LSAs?
  5. How many Type 2 LSA entries will there be?

Topology Diagram


Continue reading

A Deep Dive in OSPF LSAs, Part 4

As mentioned a couple of times in this series, Type 1 LSAs differ between Broadcast and Point-to-Point segments. To demonstrate this, I’ll be using the same topology as before. The only difference is that each interface has had the “ip ospf network point-to-point” command applied to it.


You may recall that the reason why I’m talking only about Type 1 LSAs is because Type 2 LSAs are only present in broadcast segments. In case you need it, here’s a quick refresher:

  • Type 1 – Router LSA – each router announces its presence and lists the links to other routers or networks in the same area, together with the metrics to them. Type 1 LSAs are flooded across their own area only. The link-state ID of the type 1 LSA is the originating router ID.
  • Type 2 – Network LSA – the designated router (DR) on a broadcast segment (e.g. Ethernet) lists which routers are joined together by the segment. Type 2 LSAs are flooded across their own area only. The link-state ID of the type 2 LSA is the IP interface address of the DR.

Continue reading

A Deep Dive in OSPF LSAs, Part 3

In my previous post I covered Type 1 and Type 2 LSAs in relation to broadcast networks. In this post I’ll demonstrate how you can use these LSAs to map the topology an OSPF area.

Broadcast Networks – Type 1 + Type 2 LSAs = Area Diagram

First, let’s take a look at which LSAs exist in this area:

R1(config-if)#do sh ip ospf database

            OSPF Router with ID ( (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count         1850        0x8000000C 0x003FB9 1         370         0x8000000D 0x00278E 2         339         0x80000004 0x0001EA 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum         823         0x80000003 0x0055C4         370         0x80000002 0x006C9F

Continue reading

A Deep Dive in OSPF LSAs, Part 2

In my previous post I covered the inspiration for this series of posts as well as many of OSPF’s LSAs. Now that we’ve got the boring stuff out of the way, let’s jump into the fun stuff :)

In this post I’ll cover Type 1 and Type 2 LSAs in broadcast networks. The reason why I highlight the fact that this information applies only to broadcast networks is because, as you will see in Part 4, Type 1 LSAs are slightly different in point-to-point networks. Further to this, Type 2 LSAs don’t exist in point-to-point networks.

Let’s get started…

Broadcast Networks – Type 1 LSAs

Topology #1


Continue reading

Guide: Building a Self-Contained Virtual Steelhead Lab – Part 4

Note: This post carries on from Part 3.

Testing & Reporting

Now that you’ve set up your lab, you can start working on the VSHs.

 Test #1 – TCP Options

Usually when telnetting between two routers (e.g PC-A-01 and PC-B-01), the MSS negotiated is 536 and no other options are specified. However, after configuring the VSHs to optimise telnet traffic, you can see the VSHs and Enhanced Auto discovery in action:


These enhanced settings won’t make much of a difference where Telnet traffic is concerned, but this sort of test can be useful for those who cannot run the Windows XP VMs due their PC’s performance.

Continue reading

Guide: Building a Self-Contained Virtual Steelhead Lab – Part 3

Note: This post carries on from Part 2.

Virtual Steelhead


Now that the vSwitches are set up, the next thing you will need to do is install the VSHs.

1) Through the vSphere client, install the VSH by clicking on “File” > “Deploy OVF Template”.

2) When asked for the name of the VM, type “VSH-A”.

3) When configuring the NICs, match the “Source Networks” to their appropriate “Destination Networks”, as per the image below.


Continue reading