An Example of a Security Exploit Due to the Native VLAN

January 18, 2018 at 8:24 pm

Native VLAN

In many of our Cisco courses, we learn that networking best practices often point to the non-use of the Native VLAN. But why is this?

It turns out there are security vulnerabilities that could result from having a VLAN not tagged across your trunk links. For example, there is the VLAN hopping attack.

Here is how this attack could work:

Step 1: A bad person at a customer site wants to send frames into a VLAN that they are not part of.

Step 2: This person double tags the frame (Q-in-Q) with the outer frame matching the native VLAN in use at the provider edge switch.

Step 3: The provider edge switch strips off the outer tag (because it matches the native VLAN), and send this frame across the trunk.

Step 4: The next switch in the path examines the frame and reads the inner VLAN tag and forwards the frame accordingly.

Notice this attack is unidirectional. The attacker can send traffic into the VLAN, but traffic will not return. Even still, this is obviously not something we want taking place.

What are possible solutions?

  • Use ISL trunks in the cloud – this becomes less and less possible as ISL trunks fade away.
  • Use a Native VLAN that is outside of the range permitted for the customer.
  • Tag the native VLAN in the cloud.


The OSI Model Challenge – Quiz 1

August 6, 2017 at 8:51 am

Enjoy this challenge regarding the OSI model. This quiz maps to many different certification exams including, CCENT, CCNA, A+, N+, and many more!  Good luck!

The OSI Model Challenge

Enjoy this challenge regarding the OSI model. This quiz maps to many different certification exams including, CCENT, CCNA, A+, N+, and many more!

Congratulations - you have completed The OSI Model Challenge.

You scored %%SCORE%% out of %%TOTAL%%.

Your performance has been rated as %%RATING%%

Your answers are highlighted below.
Shaded items are complete.

Store and stream video tutorials, study materials and practice online tests at your convenience using a cloud hosted virtual PC by using Visit today to know how cloud technology can boost your productivity.

CCDA 200-310 at CBT Nuggets – Revised Outline

December 22, 2015 at 10:13 pm


The New CCDA Date:

In addition to the CCDA outline changing, I have a revised completion date. This course completes on 12/31/2015 just in time for the new year! As you can see below – the outline grew considerably based on author and student feedback. Remember, current subscribers can enjoy many of the Nuggets that are completed right now:


The New and Improved CCDA Outline :

  1. Course Introduction
  2. Plan, Build, Manage
  3. The PPDIOO Network Lifecycle
  4. Characterizing the Existing Network
  5. IP SLA
  6. Top-Down Versus Bottom-Up
  7. Case Study: Top-Down Design
  8. Building a Modular Network
  9. Applying Modularity
  10. Campus Network Design
  11. Designing Enterprise Network Security
  12. Designing the Edge Module
  13. WAN Design
  14. Branch Design
  15. Data Center Design
  16. IP Addressing
  17. Routing Protocols
  18. Case Study: IGPs
  19. Case Study: BGP
  20. QoS
  21. Wireless
  22. Case Study: Wireless
  23. Collaboration
  24. Case Study: Collaboration
  25. SDN

EIGRP’s Composite Metric for CCDAs

December 14, 2015 at 11:50 pm

An EIGRP Overview:

Are you like me? Are you intrigued by the Cisco invention of EIGRP? Here is an excellent text you should consider for your Holiday Reading List:
EIGRP for IP: Basic Operation and Configuration by Russ White and Alvaro Retana

This book is an excellent supplement to my latest CCDA course at CBT Nuggets.

It is always great to visit with Russ White each Cisco Live, and I have read many of his works. His text does a fine job clearing many of the misconceptions regarding the composite metric of EIGRP. Having taught this subject for decades now, I have seen so many students willing to argue on many of these points. Let’s review some of these here in this post.

The Merry Metric:

  • While we are taught since CCNA days that the EIGRP metric consists of 5 possible components – BW, Delay, Load, Reliability, and MTU; we realize when we look at the actual formula for the metric computation, MTU is actually NOT part of the metric. Why have we been taught this then? Cisco indicates that MTU is used as a tie-breaker in a situation that might require it. To review the actual formula that is used to compute the metric as well as other great information, click here.
  • Here is the basic formula – EIGRP Metric = 256*((K1*BW) + (K2*BW)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))
  • Notice from the formula that the K (constant values) impact which components of the metric are actually considered. By default K1 is set to 1 and K3 is set to 1 to ensure that Bandwidth and Delay are utilized in the calculation. For example, if you wanted to make Bandwidth twice as significant in the calculation, you could set K1 to 2. The metric weights command is used for this manipulation. You should note that the metric weights command starts with a TOS parameter that should always be set to 0. Cisco never did fully implement this functionality.
  • The Bandwidth that effects the metric is taken from the bandwidth command used in interface configuration mode. Obviously, if you do not provide this value – the Cisco router will select a default based on the interface type.
  • The Delay value that effects the metric is taken from the delay command used in interface configuration mode. This value depends on the interface hardware type, e.g. it is lower for Ethernet but higher for Serial interfaces. Note how the Delay parameter allows you to influence EIGRP path selection decisions without the manipulation of the Bandwidth value. This is nice, since other mechanisms could be relying heavily on the bandwidth setting. For example, EIGRP bandwidth pacing or absolute QoS reservation values for CBWFQ.
  • The actual metric value for a prefix is derived from the SUM of the delay values in the path, and the LOWEST bandwidth value along the path. This is yet another reason to use more predictive Delay manipulations to change EIGRP path preference.

CCDA – Building a Modular Network

December 13, 2015 at 10:45 pm


Enjoy this Nugget from the latest course here at CBT Nuggets! This Nugget attacks the subject of modularity when you are designing a modern network. This Nugget sets up the next CCDA Nugget in the course which is entitled Applying Modularity.

Modular network designs provide great enhancements when it comes to simplicity, ease of troubleshooting, and ease of understanding. This is hugely important, especially since networking today is more complex than ever. So anything we can do to make the network and its functions easier to understand, sounds like a great idea to me!

As you will see in this Nugget, Cisco proposes a nice Enterprise Design idea. It consists of four major areas – the Campus, the edge, the service provider and the remote module. What is really powerful is the fact that you can then divide these major sections into more detailed and modular sub sections. For example, the campus can be broken down into an access layer module, a distribution layer, and a core layer. Many networks today also feature a data center as part of this major network segment.

The CCDA Nugget:

Quick CCDA Nugget Review:

1. What does MTTR mean in computer networking?

a. Mean Time To Repair
b. Main Terminal To Register
c. Median Time To Respond
d. Modular Test To Record
2. What is not a major advantage to making a network modular?
a. Scalability
b. Resiliency
c. Ease of understanding
d. Cost
e. Ease of troubleshooting
3. What is another reference for a convergence domain?
a. Fault domain
b. Summarization boundary
c. Optimization segment
d. Prototype domain
4. What dynamic routing protocol features modularity in its implementation through the use of areas?
a. RIP
d. RIPv2
5. Which is not a major module of the Cisco Enterprise Network model?
a. Campus
b. Edge
c. Remote
d. Service Provider
e. Data Center
The Latest CCDA from CBT Nuggets