Wednesday, 30 December 2015

Yersinia Spanning Tree Protocol (STP)

STP is a layer 2 protocol that prevents loops from occurring in a switched network. Each switch involved in the process sends out BPDU packets to elect a root bridge and from here, ports are given a role of either root, designated, alternate, backup or disabled.
Ports that are either root or designated are active ports in the topology, whereas alternate, backup and disabled ports do not forward packets.
The root switch has all designated ports and each other switch has one root port which is the fastest path to the root bridge and any number of other port types.
More details on the STP protocol can be read at: Cisco STP Summary

When the STP protocol screen is opened in Yersinia ncurses, each unique BPDU seen by the active interface is listed. The up and down arrows can be used to click on the BPDU to inspect the contents.

In the example below, the first BPDU seen is from the switch that my linux box is connected to. Opening this BPDU it can be seen that the RootId matches what is on the switch.

Further down, surrounded by green is the details that Yersinia has populated into a BPDU that it will send in an attack. In the example below, it can be seen that the populated RootId is 5080.760F0E14AC58 which is lower than the RootId in the received BPDU (8028.0014A9B0E800). Which means the switch will receive a superior BPDU when this packet is sent.

Clicking 'x' in Yersinia shows the available attacks for the active protocol. In this case, STP has 6 available attacks to choose from.

Yersinia Spanning-Tree Protocol attack options
Attack 0: sending conf BPDU

This attack simply sends a single BPDU of the format shown in the green frame above. It will appear to the switch as a superior BPDU, but because it is only one BPDU the root bridge will only transition until the Max Age times out (in this case 20 seconds).

Switch behaviour when attack 1 is launched
The screenshot above shows the behaviour of the switch when it receives the BPDU. It receives the BPDU, acknowledges the new root bridge on Fa0/31, 20 seconds later it returns to being the root bridge.

Attack 1: sending tcn BPDU

A TCN (Topology Change Notification) BPDU lets the rootbridge know that something has changed in the network. It is always forwarded through the root port until it arrives at the root bridge, which then sends out a BPDU with the TC (Topology Change) bit set. The TC bit is set by the root for a period of max_age + forward_delay seconds, which is 20+15=35 seconds by default.

Further Research:

Looking at the MST protocol
How to take advantage of being the Root bridge (all your broadcasts belong to me)
PVST+ simulation weakness that can be exploited

Yersinia in the Network

"Yersinia is a network tool designed to take advantage of some weaknesses in different network protocols"
I think Yersinia is a pretty cool tool and over the Christmas break I decided to see how easy it is to exploit each of the network protocol it implements.

After installing Yersinia, to run it with the ncurses GUI (which is good for beginners), type:
yersinia -I
 From here you can press "h" to see the options. Basic commands is "g" to select the protocol you want to attack (or use F2 - F9 to click through them). When you are on the protocol page, press "x" to list the available attacks and "l" to list which attacks are currently running.

I'm going to go through each protocol attack and how they work in my subsequent blogs posts. As of writing, in Yersinia v0.7.3 the protocols listed below are implemented. Each protocol will be a link to my blog post with more detail.

Yersinia can be used to test the following protocols on the network:
  • Spanning Tree Protocol (STP)

  • Cisco Discovery Protocol (CDP)

  • Dynamic Trunking Protocol (DTP)
  • Dynamic Host Configuration Protocol (DHCP)
  • Hot Standby Router protocol (HSRP)
  • IEEE 802.1Q
  • IEEE 802.1X
  • Inter-Switch Link Protocol (ISL)

  • VLAN Trunking Protocol (VTP)

  • Multiprotocol Label Switching (MPLS)

After I fully understand the exploitation of all these protocols, I'd like to add to Yersinia. :)

Monday, 28 September 2015

MST and Port Priority on VIRL

I really wanted to cement my knowledge of MST and Port Priorities, and VIRL was perfect for this.  All I did was use two switches connected with dual links. I defined 4 new vlans and then put two in MST 1 and two in MST 2.

What I noticed though was that both MST 1 and MST 2 were using Gi0/1 to forward, even though I had set SW1 as the root for MST1 and SW2 as the root for MST2. So I used port-priorities to configure MST1 to use Gi0/1 and MST2 to use Gi0/2.

The configuration of port-priorities is shown below:

VIRL was perfect to investigate and cement MST and port-priorities for me, and I didn't have to waste any of my INE rack rental time or purchase switches (which seem to be so much more expensive then routers for my CCIE lab)

Sunday, 27 September 2015

VIRL Troubleshooting

VIRL is fantastic to use, but I have had some issues with it lately so I thought I might detail the fairly simple solutions I found.

Virtual Interface Creation Failed Error on launching simulation:

First one happened when I clicked yes to the update prompt. It ran through updates and then when I open Maestro and tried to launch a simulation I got the following error:

Node "R1" state changed from BUILDING to ERROR with message: Virtual Interface creation failed:   File "/usr/lib/python2.7/dist-packages/nova/compute/", line 297, in decorated_function

The correct way to do the upgrade can be found here. But since I was stuck in some quasi-half upgrade stage, all I had to do was run the following commands:

sudo vinstall vinstall

sudo salt-call saltutil.sync_all

sudo vinstall salt

sudo salt-call state.sls openstack

sudo salt-call state.sls openstack.setup

sudo salt-call state.sls openstack.restart

Now my VIRL is launching simulations properly again.

Connection Refused to console:

This one is so annoying, because it appears like everything is working but when you try to get to the console of the running devices you get the following error:

This had a crazy simple solution. I had a VPN running on the VM which was interfering with the routes to the console. The easiest way to fix this was to disable the VPN. And now I can get to the console again. :)

WAN Circuits

- default serial encapsulation
- no advanced features
- problems with vendor interoperability
- very easy config "no shut", configure clockrate


- negotiation, authentication (PAP, CHAP), PPPoE
- easy to configure, 'encapsulation ppp'
- debug ppp negotiation
- pap: password authentication protocol
- challenger: "ppp authentication pap"
- reponse: "no ppp pap refuse", "ppp pap sent-username... password"


MST Revision

Required information for an MST instance:

  • instance name
  • revision number
  • mst to vlan mappings

intra region:
vlan to stpis are manually defined
undefined vlans fall into CIST (MST 0)

inter region:
details between regions are not know

MST is backwards compatible with legacy CST and PVST+
behaves like inter-region MST
CST root must be within the MST domain

migration, start from root bridge and work your way out

Config Steps:
1. define the following in MST config mode:
region name
revision number
VLAN to isntance mappings
2. Enable MST globally

Same election process as CST/PVST+

Changing BID priority, port cost, port priority - all done for the instance
eg. spanning-tree mst [instance] priority

BEST PRACTICE: 3 spanning-tree instances in MST

Sunday, 30 August 2015

Layer 2 Final Revision

This weekend I consolidated my Layer 2 knowledge by finishing off the first 3 chapters of the Official CCIE Study Guide. I was pretty confident in Layer 2 stuff, but I still managed to pick up a few reminders of gotchas below.

Etherchannel Notes from this weekend:

To check the load balancing accross the links use the following command:
show port-channel traffic

Reminder - for Layer 3 port-channels, configure 'no switchport' on the physical interfaces first before configuring the port-channel

Layer 2 reminders:

Ethernet V2 and IEEE802.3 frames are different.
Ethernet V2 have a 2-byte Type field.
IEEE802.3 have a 2-byte Length field & 3 x 1-byte fields - Destination Service Access Point (DSAP), Source Service Access Point (SSAP) and Control. These are called LLC fields.

VTP gotchas this weekend -

without any configuration, the default is server mode
without any domain name a switch will assume the domain name of the first received VTP update
Although VTPv3 supports extended vlans, it does not prune them :O
VLAN database mode ALWAYS only allows manipulating normal range VLANs, regardless of the VTP version and VTP mode

PPP header = 2 bytes
PPPoE header = 6 bytes

Private VLANs can always communicate with trunk ports

STP: port costs are only applied to RECEIVED BPDUs, not sent BPDUs

Here are my results from the post chapter quizzes... not stunning, but mostly just misreading questions or forgetting something small:

Switched Networking Basics Quiz

Virtual LANs and VLAN Trunking Quiz

Spanning Tree Protocol Quiz

Saturday, 18 July 2015

IP Routing

I have VIRL installed on my HP Microserver running ESX, but having a few problems with running the simulations. :( I can't seem to telnet to the console port when the simulation is running. But that's a problem for another post and day. I really needed to do some solid lab work so went back to INE labs for a bit.

Today I reviewed static IP routing and the differences between setting next-hop, exit interface or both.

A few points I learnt are:
  • in DMVPN the hub can not use only exit-interface, it must use next-hop;
  • static routes using exit interface on a multipoint interface can have ARP issues;
I also reviewed the use of SLAs in creating redundancy in the routing table.

Monday, 6 July 2015

Basic ASA VIRL Lab

Today I tried out the ASA - and it worked pretty well. It doesn't support context switching, which is a bit sad - but other than that, it seemed to do everything else I tried.

I figured, from now on I'll share my VIRL file and if people are really interested they can download and try it out themselves. Maybe I'll even write a blog post on how to open a virl file, but it's pretty easy.

Basic ASA Configuration & Failover Lab

You know this is working when you can ping R6 Lo0 ( from R4 - bring down ASA1 and it continues to work.
Click here to download VIRL file

In this lab I've configured standby and failover on the ASAs, ASA1 is the Primary, ASA2 is the Secondary. The VIRL lab looks like this:
But with the configuration of an inside and outside vlan on SW1, it looks logically like this:
When you load the VIRL file, the network is fully configured to work. To practice configuring the ASAs I recommend you open the console for both of the ASAs and run: "clear config all" (take a copy of the working running-config before doing this if you want)

Then the following steps should get the ASAs back to a working state:

  • Configure a hostname on ASA1
  • Configure the IP addresses on Gi0/0 and Gi0/1 as shown above, naming them outside and inside respectively. Configure a default route pointing at the R6 IP address.
  • Configure OSPF between ASA1 and R4
  • Configure NAT on the ASA
  • Configure ASA1 as a routed firewall
  • Configure ASA for active/standby failover
I should give more detail, but I'm new at this =P  I will admit that the majority of my working life as a network engineer I've used ASDM to configure firewalls (boo! hiss!) - this gave me an opportunity to run through the basics on the CLI.

Sunday, 5 July 2015

A Little More VIRL

So I have spent a bit of time this week playing around with VIRL. I have trialed 3 instances:

  • local on my 8GB laptop in VMware
  • at work on an ESX, assigned 32GB
  • at home on my ESX - currently assigned 8GB but working on improving this
I think my takeaway points are:

Don't use VIRL for the NX-OS image!
I was pretty excited to do some NX-OS topologies but I found out pretty quickly that some of the technologies I wanted to play around with aren't support. Below shows the problems I had in trying to establish vPC.
After googling I realised that Layer 2 functionality is not supported in NX-OSv and there is no timeline for the features to be released. I don't think this is made very clear when VIRL is acquired.
Click here for a comprehensive list of what is available on NX-OS.

After this disappointment, I went back to switching and routing and was pretty happy with what I could do again. I tried out some various routing scenarios with multiple IGPs and VLANs. It worked very nicely with 32GB of memory.

I then tried to push it a little more to the limits, so I grew my network to something along the line of a service provider network. At this point I ran out of memory again. :( So I used the option of disabling some of the router from the configuration. See below the option to highlight nodes and click a box to exclude them from the simulation:

After I did this, the simulation launched without problem, with the two routers excluded. I thought this was pretty good, considering how many CSR routers I put into the network. You can see below on the right the routers that didn't launch are represented with an [ABSENT] tag next to them.

I guess at this point I'm still just feeling my way around, but would I buy it again? Considering how much I've spent on hardware, and with the current $50 off special making VIRL very cost effective comparatively. So yes, I despite some limitations, I think VIRL is a very good investment for anyone wanting to practice and trial network configurations.

Previous VIRL Post

Wednesday, 1 July 2015

DMVPN Part 2

Go to DMVPN Part 1

4. DMVPN Routing Configuration

So each router doesn't know about the other routers attached networks (in this case its the loopback addresses). The routing can be completed using either static routes.

Because  "ip nhrp map multicast" command was used on the spoke routers they can only broadcast hellos to the hub router, so OSPF becomes a hub and spoke configuration. This means the hub router must become the DR and using the OSPF broadcast network type must be used.

It should look like this:

Pretty cool.

My First-Run VIRL Review

I have been so slack in blogging lately, the truth is I've been a bit slack in my CCIE study. Though I have been sidetracked in learning a heap about Cisco UCS - but that was for work.

Anyway, I have embarked on a new adventure - which is VIRL. This stands for Virtual Internet Routing Lab. I love my hardware lab, but I just had to try this virtualisation method. Installing it was pretty easy, it downloads as an OVF which you deploy as either standalone on a PC/Mac or onto an ESX. I used VMware Player and installed it on my laptop.

Here's what it looks like:

This was great and all you have to do is click on the VMMaestro icon to fire up the software that allows you to place virtual routers and do all sorts of network configurations. However, I ran into this error a lot:

It generally happens when stopping a simulation and restarting it or another simulation. I'm not 100% sure, but it feels like it takes a bit of time to release the memory once a simulation is stopped. This simulation above was 6 IOSv routers - I didn't even bother trying to run CSR1000vs which apparently use up 3GB of memory.

So my first bit of advice is... don't run VIRL on a PC with only 8GB. Although 8GB is the minimum requirement, you may get frustrated quickly.

I've since moved my installation to an ESX server, assigning the VM 32GB... and this is seamless. I've been running through the tutorials and am really enjoying the features that are available that you wouldn't get from using the VMs directly in KVM or whatever... or from using hardware. These features are things like the AutoNetkit which allows you to very quickly deploy configurations across a large network. So you can setup your test environment much faster than if you were setting it up on hardware or standalone VMs. I'll show you a screenshot here of auto configuring EIGRP on a bunch of routers - but this is directly from the tutorial mentioned above.

And secondly, the views allow you to troubleshoot so quickly what is going on in the network. You can click on various different configs to highlight what you expect to see.

Below is the eBGP neighbour relationships highlighted... but you can see the options on the left.

I am going move my installation one more time to my home ESX so that I can use it in the evenings. It has 16GB which I'm hoping is sufficient. But watch this space for some more VIRL fun. =)

Thursday, 18 June 2015

DMVPN Part 1

So I briefly covered some points about DMVPN here from a night when I did a lab and wanted to remember some of it. I thought for my own sake I'd step back and really examine DMVPN. So back to the textbook.

DMVPN stands for "Dynamic Multipoint VPN". It is a way of creating dynamic VPNs for an organisation. This should remove the overhead of configuring individual VPNs. DMVPNs are ALWAYS setup in a hub & spoke configuration.

I've gone through the steps in the book using my home lab:

1. Basic Configuration of IP Addresses

Pretty easy... my routers are all connected to my switch and have range IP addresses on their fast ethernet interfaces.

2. GRE Multipoint Tunnel configuration on all routers (for spoke-to-spoke connectivity).

This can be broken down further into two steps. Setup NHRP and setup mGRE - both of these are done under the tunnel interface.

An example of this is:

This is done on each router, however you don't have to do the nhrp map command to the hub router on the spoke routers. These are the commands underlined in red. They are not required on the hub router.
The authentication command is optional.
This can be verified using the following command:

The coolest thing about this is that we have two tunnels from the hub router to the spoke routers, but if the spoke routers decide to communicate, they will dynamically build a tunnel between them. Imagine in a DMVPN network, this is pretty useful.

Could do this all day!! It's so cool. However, the default operation of DMVPN is to send traffic as clear text. :O

3. Configure IPsec to Encrypt mGRE Tunnels

Apply IPsec to the configuration involves:
  1. Setting up the crypto isakmp policy
  2. Setting a key with the ip address (because of the dynamic IP setting)
  3. Setting up a transform set
  4. Setting up an IPsec profile
  5. Applying the profile to the tunnel interface

Wednesday, 17 June 2015

OSPF Basics

Taking advantage of my serial ports, doing some OSPF.

There are two ways to setup OSPF:

  1. Under the interface using "ip ospf <process-id> area <area-id>"
  2. Under the routing process using the network command
If both are configured, the interface command supersedes the setting under the routing process. So for example if an interface is configured both ways with different areas, the area given under the interface will be the one used.

OSPF Cost = Reference/Bandwidth

New rack!

This post has nothing to do with my CCIE journey... but a bit about my home lab. I'm changing jobs this week after 6 years and the guys at work (knowing my CCIE lab and study) decided to buy me a rack as a farewell gift. *sob*

At first I thought assembling it was some sort of punishment for leaving:

Tossed up mounting it on the wall (it has a wall mount), putting it on wheels (it has wheels too!) but opted to keep it on my buffet just so I have fast easy access to re-cable and power the routers and switches as often as I want to.

Here is the back. I still haven't put on the side panels, the back or the front.

And here is the front:

I think technically the rack costs more than the equipment in it. I'm not sure I'll include its price in my CCIE lab setup since I didn't pay for it. :)

Monday, 15 June 2015

Serial, serial... :(

Having problems with my serial ports at the moment, I think one of the network modules I received last week has a hardware fault. I've tried unbelievable number of combinations, but whether its the DCE, DTE and in multiple different routers, whenever I bring up the port it takes a few seconds and then it throws a "Level 2 Watch Dog Timeout" error and reboots the router.

See exhibit A below :(
I guess you win some and lose some. $55 wasted.

Friday, 12 June 2015

DMVPN Phase 1

DMVPN Phase 1 uses mGRE and NHRP.

To setup DMVPN Phase 1 do the following steps on each router:
1. setup mGRE config, use "tunnel mode gre multipoint" on the hub router
2. configure NHRP - network ID & mapping

Wednesday, 10 June 2015

Smartport Macros

I vaguely remember using these as a younger network engineer and possibly not understanding them well. It was just our SOP (Standard Operating Procedure) to apply the macro to the interface as the switch was set up or modified.

These are pretty simple to understand and save heaps of time. :)

The old way is below. Here you define the macro first and apply them to the ports that require it.

The new way (which I think seems a lot less intuitive), firstly you define the ports you want and then apply to macro to them.

Tuesday, 9 June 2015

Spanning-Tree BPDUs

Firstly introducing the newest member to the "Kylie's CCIE Lab" family. I found it really hard to find an affordable Layer 3 switch for my at home lab. Layer 3 switches seem to be a lot more expensive than routers. This 3560 cost me $90 plus $10 postage. I also got a second serial card for $55. This brings the total cost of my lab up to $430 so far. Things are getting serious.

Here's a photo of my new switch sitting on my routers. :)

I spent a bit of time today reviewing spanning tree protections.

BPDU Guard

Can be enabled globally or per interface (for portfast ports)
Puts a port into err-disable status if a BPDU is received on it

BPDU Filter

Drops BPDUs both inbound and outbound on an interface.
If enabled per interface, it can cause a switching loop because it will just silently and continually drop BPDUs both inbound and outbound. This is a way of terminating a STP domain.
Enabling it globally is safer. It is only enabled on portfast ports and will terminate when a BPDU is received. The port will go into STP negotiation.

Root Guard

Similar to BPDU Guard, except it only errdisables the port if the BPDU is declaring that it is coming from a superior root bridge.

LoopGuard & UDLD 

'nuff said :P

Something new... (for me)

How cool is the errdisable recovery feature. In production this could cause a lot of flapping on a port, but when testing BPDUguard it is great. Using "errdisable recovery interval 120", the interface comes back up every 2 minutes and errors again.

Monday, 8 June 2015

STP Timers, Uplinkfast, Backbone fast

Tonight was a revision of standard STP, 802.1D
(PS - I hope over the year my studying will become more insightful :P)


The default timers for Spanning Tree are:
Hello = 2s
Max-age = 20s
Forward-delay 15s

To speed up spanning-tree convergence, these timers can by modified. 
Interesting points:
  • Timers are always learnt from the root bridge.
  • The forward-delay is how long the port stays in each the listening and learning states. So if the forward-delay is set to 15s it will take 30s for the port to move to the forwarding state


Portfast makes a port go straight to forwarding. It can be enabled on an interface or set as the default in global configuration, only affecting access ports.
Interesting points:
  • You can force portfast on a trunk port by using the command "spanning-tree portfast trunk". This is useful for servers such as ESX which may have a trunk to it. 
  • Portfast should never be used on a port connecting to another switch, but if a port configured for portfast receives a BPDU it will process it and can move into blocking if needed.
An example below of bringing up a port that is configured as a trunk for portfast. Each VLAN goes directly to forwarding.


This is a Cisco propriety feature only available for use with 802.1D because all of the rapid spanning tree protocols have their own means for speeding up convergence of STP
This is set with a global configuration command and speeds up convergence for a direct failure of the root port happens.
The example below shows how when the root port is shut down a new root port is immediately moved into forwarding.


BackboneFast is similar to UplinkFast in that it is Cisco Proprietry, also only useful with 802.1D and is a global configuration command. It speeds up convergence when an indirect failure occurs by sending our Root Link Queries (RLQ)

Something else I learnt today while reading about RPVST+ is that portfast is a necessity, not just something that is nice to have.

Friday, 5 June 2015

Serial, serial, oh my!!

So I ordered a serial network module for my routers which arrived today.
This isn't the greatest value purchase. At $55 including delivery, it actually cost the same amount as the routers. :( But it does give me 5 times as many ports to play with.
Anyway... I only bought one so I actually can't connect to anything. :( But it works and I've ordered another one to compliment it.
This takes the total cost of my home lab to $280 + $110 = $390. So far! Things are getting serious.


I took the time tonight to review setting up neighbour relationships in BGP. I have to admit, the 2811 routers with the latest IOS in my home lab work brilliantly for this.
I went over IBGP neighbours, eBGP neighbours (above). Re-acquainted myself with the output of "sh ip bgp" and had a quick go at version 4 peer-group config.
Tonight I reviewed the basics of BGP which I really needed. :(

Incidentally, I did the Cisco BGP course about 4 years ago with a scary little CCIE who reminded me a lot of Ben Chang from Community. If someone in the class forgot something like the AD of a routing protocol he would yell at them, 'This is an advanced course!!'. He scared me into being pretty good at BGP and I sat the exam 2 days after the course. I can just imagine how mad he'd be at me now. :P