ccie blog

Loop Guard and UDLD

Loop guard and UDLD are two ways to protect your fiber cables from causing loops in the network.  In short, loop guard is a spanning-tree optimisation, and UDLD is a layer 1/2 protocol (unrelated to spanning-tree) that protects your upper layer protocols from causing loops in the network.  To explain these features clearly, see the diagrams below.  The first diagram is the layer 2 spanning-tree topology, and the second diagram is the actual physical wiring used in the topology. You will need to use both diagrams as a reference point simultaneously in order to understand how loop guard and UDLD work in the examples I will provide.

Loop Guard and UDLD

In case you are not familiar with fiber, you need to make sure you understand the connection between Sw2 and Sw3 in the diagram on the right hand side.  This is two physical cables, one is to transmit data and the other is to receive data. These fiber cables are usually plugged into an SFP such as the one shown below, and then the SFP is inserted into the switch. On the switch, this is shown as one physical port. In my diagram, it’s shown as Gi0/1 on Sw2 and Sw3.

SFP

Read the rest of this entry »

RSTP Alternate and Backup Ports

This post identifies differences between the legacy spanning-tree (PVST+) non-designated port & the new RSTP replacement ports.

RSTP brought about a couple of new port roles compared to legacy spanning-tree, see below.

Legacy PVST+                      RSTP

Root                    ———->   Root
Designated          ———->   Designated
Non-Designated   ———->   Now uses Alternate and Backup ports

In PVST+ we said that anything that was in a blocking port state, was a spanning-tree a non-designated port.  RSTP has broken this blocking port down into two separate functions in order to provide faster convergence in a couple of difference scenarios. Read the rest of this entry »

Native VLAN

Growing a little tired of reading numerous useless posts about the native VLAN, I decided to do one that describes exactly what it is.  The native VLAN has two main functions:

  1. Tags incoming un-tagged traffic on trunk links with the native VLAN.
  2. Un-tags outgoing traffic that has already been tagged with same VLAN that is being used for the native VLAN on the trunk.

Let me elaborate on this a little bit with aid of the diagram shown below.

Native VLAN

A normal design would use the same native VLAN both sides of the trunk.  But to understand the native VLAN properly, I’ve designed it this way instead.  So going back to the bullet points above (specifically bullet point 2), when the switchport connecting to Host A has been configured to use the same access VLAN (vlan 50) that is being used as the native VLAN on the trunk, the data sent from Host A is un-tagged as it leaves Switch 1 towards switch 2.  This leads us up to bullet point 1 (above), where switch2 now receives an un-tagged frame (i.e. a frame without a VLAN tag on it). Switch2 will always tag this, currently tag-less frame with the configured native VLAN on the trunk, in this case VLAN 60. So this actually leaks VLAN 50 into VLAN 60’s broadcast domain.

Read the rest of this entry »

Classic EIGRP Metric Calculation

I’ve hated this formula and avoided it for about 5 years. I just buckled down and figured it out, and actually it’s pretty easy providing we are using default K values K1=1 and K3=1 (i.e. BW and Delay,) are used for the metric. The entire metric formula can actually just become BW + Delay. Bare with me, see the math below:

 

The actual formula is below

Metric=[K1* BW + (K2*BW)/(256*load) + K3 * Delay]

Since K2 = 0, this means the whole line of (K2*BW)/(256*load) can be completely removed (because 0 divided by anything is 0). So the formula becomes

Metric= K1*BW + K3*Delay

Since K1=1 and K3=1, the formula can be simplified again to

Metric= BW + Delay

 

So that’s it. Although there is a catch, which is how all the exam questions always try and catch you out. In the EIGRP metric calculation, the BW is not actually the BW & the delay is not actually the delay. How annoying is that? See below

  • Bandwidth = Inverse lowest bandwidth along a path in Kbps x 10^7 * 256.
  • Delay = Lowest cumulative delay along the path x 256

My first question was, what the heck is inverse bandwidth? Actually it just means 1/BW.  Let do a real life example of the calculation then. Take a look at the show output below, we will calculate how EIGRP came up with the metric as being 28160 for this network.

UKINTR1#sh ip eigrp topology 200.70.80.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.66.255.1) for 200.70.80.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
  Descriptor Blocks:
  0.0.0.0 (GigabitEthernet0/1), from Connected, Send flag is 0x0
      Composite metric is (28160/0), route is Internal
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
        Originating router is 10.66.255.1

So we simplified the metric formula to BW + Delay. We’ve only got 2 values to work out, so let’s start by working out the bandwidth.

Bandwidth = Inverse lowest bandwidth along a path in Kbps x 10^7 x 256.
Bandwidth = 1/100000 x 10^7 x 256
Bandwidth = 25600

Now lets work out the delay

Delay = Lowest cumulative delay along the path x 256
Delay = 10 x 256 (remember delay is in “Tens of Microseconds”, whereas the output above shows only microseconds).
Delay = 2560

Now lets put this into the Metric

Metric = BW + Delay
Metric = 25600 + 2560
Metric = 28160

LCP, CHAP, and PPP

This post will discuss Link Control Protocol (LCP),  Challenge Handshake Authentication Protocol (CHAP), and Point-to-Point Protocol (PPP).

Read the rest of this entry »

RSTP Synchronization – A detailed guide

I got bored with reading stuff that doesn’t go into enough detail about the RSTP synchronization process on the web, so I’m making my own guide and notes about it.  I’m going to start by identifying the port states and roles, then go through the RSTP synchronization process and explain how they are used.

RSTP port states and roles

Port Roles

  • Root port
  • Designated port
  • Edge port
  • Alternate port
  • Backup port

Port States

  • Discarding
  • Learning
  • Forwarding

 

RSTP Synchronization Process

I’m going use the topology below to go through the synchronization process.

RSTP

Read the rest of this entry »

Spanning-Tree Backbonefast

This is a 6 minute video that talks in detail about how backbone fast works and how it can reduce convergence time with spanning-tree

MPLS VPN

In this lab I’m going to go over the config for an MPLS VPN.

MPLS VPN

Read the rest of this entry »

EIGRP Leak-Map

The leak-map just allows you to advertise a specific prefix within the range of a summary advertisement, as well as the summary itself. We can see in the diagram below that we are advertising the 10.0.0.0/13 network out to R5 & R6, however, we are also advertising the 10.1.0.0/24 network out to R5 using a leak-map.

EIGRP Leak-Map

I’ve configured everything but the leak-map so far. Basically all routers just have EIGRP 100 running & auto-summary disabled. R3 has been configured to summarise 10.0.0.0/13 out to R5 & R6. Below is the current routing tables of both R5 and R6.
Read the rest of this entry »

EIGRP Query Scoping Using Summarisation

I didn’t understand how this worked, so I took a practical example and put it in for testing. In the diagram below on R3 I’ll advertise a summary route to R5 and R6. From there we’ll shutdown interfaces to the 10.1.0.0/24 network, and see how the query scope is limited from this summarisation.

EIGRP Query Scoping Using Summarisation

Read the rest of this entry »