CCNA Data Center – Introducing Overlay Transport Virtualization (OTV)

January 18, 2019 at 12:02 am

Overlay Transport Virtualization

OTV is one of the many exciting new protocols we get to study in the CCNA Data Center. However, what the heck is it? What problems does it address? Let’s tackle that in this post.

Today, we often locate data centers a far distance from each other, and we might often need to make them look like they are the same structure from a Layer 2 perspective. For example, two virtualized services might expect to be able to find each other at Layer 2. In the past, solutions like EoMPLS (Ethernet over MPLS) and dark fiber were attempted. Unfortunately, these solutions present many issues of their own.

Enter the OTV solution. This technology does what we like to call MAC address routing. A control plane protocol exchanges MAC address reachability information between the data centers.

OTV does not require additional configuration to support multihoming and spanning tree protocol domain independence. OTV ensures that if there is an STP failure in one data center, it does not affect the other data center.

One of my favorite facets of OTV is the fact that the routing protocol in use in the control plane to make OTV function is IS-IS! This standards-based, OSPF competitor is making a real comeback. It was selected because it is a standard-based protocol, originally designed with the capability of carrying MAC address information in the TLV. Sadly, OTV does not get the credit in naming it deserves as most call the control plane protocol of OTV simply the OTV Protocol.

Interestingly, most deployments require no specific knowledge of IS-IS configuration (or even theory) since the routing protocol works its magic automatically as OTV is configured on your devices.

I will be back with other follow up posts on this technology including a look at terminology and configuration.

If you want to peek ahead and have some fun – check out the CBT Nugget below from yours truly!

Check out my very latest CCNA Data Center training (Late 2018) at CBT Nuggets:

CCNA Data Center – Fibre Channel Port Types

January 10, 2019 at 7:29 pm

Fibre Channel Port Types

This post ensures you recall the standard Fibre Channel port types. This is important information to master since it is critical for understanding the FCoE protocol that we are tested on in CCNA Data Center. This testing is in addition to the questions we might face on Fibre Channel itself. In fact, let’s face it, Cisco could easily pull from the information we have here in this post!

This is another great area where you want to use Flash Cards in your prep most likely. It might also help you to draw your own diagrams after studying some that you can find via Google. Well, with no further delay – here are the Port Types that we should master:

  • Expansion PortE Port – it connects to another E port in order to form an interswitch link (ISL) between two switches.
  • Fabric PortF Port – it connects to a peripheral device (like a host or disk). Note that the device it connects to has an N port.
  • Fabric Loop PortFL Port – these port types for the arbitrated loop have faded from our networks due to the legacy nature of Fibre Channel hubs. You might still encounter arbitrated loops used inside storage architectures of storage products. The FL port connects to one or more NL ports.
  • Trunking Expansion PortTE Port – these ports connect to other TE ports to create an extended ISL connection. This is used to do things like VSANs and advanced QoS.
  • Node-proxy PortNP Port – an NP Port is a port on a device that is in N-Port Virtualization (NPV) mode and connects to the core switch via an F Port. NP Ports function like node ports (N Ports) but in addition to providing N Port operations, they also function as proxies for multiple physical N Ports.
  • Trunking Fabric PortTF Port – in TF Port mode, an interface functions as a trunking expansion port. This interface connects to another trunking node port (TN Port) or trunking node-proxy port (TNP Port) to create a link between a core switch and an NPV switch or a host bus adapter (HBA) to carry tagged frames. TF Ports are specific to Cisco MDS 9000 Series switches and expand the functionality of F Ports to support VSAN trunking. In TF Port mode, all frames are transmitted in the EISL frame format, which contains VSAN information.
  • TNP Port – in TNP Port mode, an interface functions as a trunking expansion port. This interface connects to a TF Port to create a link to a core N Port ID Virtualization (NPIV) switch from an NPV switch to carry tagged frames.
  • Switched Port Analyzer (SPAN) Destination PortSD Port – in SD Port mode, an interface functions as a SPAN. The SPAN feature is specific to Cisco MDS 9000 Series switches. An SD Port monitors network traffic that passes through a Fibre Channel interface. Monitoring is performed using a standard Fibre Channel analyzer (or a similar Switch Probe) that is attached to the SD Port. SD Ports cannot receive frames and transmit only a copy of the source traffic. This feature is nonintrusive and does not affect switching of network traffic for any SPAN source port.
  • SPAN Tunnel PortST Port – in ST Port mode, an interface functions as an entry-point port in the source switch for the Remote SPAN (RSPAN) Fibre Channel tunnel. ST Port mode and the RSPAN feature are specific to Cisco MDS 9000 Series switches. When a port is configured as an ST Port, it cannot be attached to any device and therefore cannot be used for normal Fibre Channel traffic.
  • Fx Port – an interface that is configured as an Fx Port can operate in either F or FL Port mode. Fx Port mode is determined during interface initialization, depending on the attached N or NL Port.
  • Bridge portB Port – whereas E Ports typically interconnect Fibre Channel switches, some SAN extender devices implement a B Port model to connect geographically dispersed fabrics. This model uses B Ports that are as described in the T11 Standard Fibre Channel Backbone 2 (FC-BB-2).
  • G-PortGeneric_Port – modern Fibre Channel switches configure their ports automatically. Such ports are called G-Ports. If, for example, a Fibre Channel switch is connected to a further Fibre Channel switch via a G-Port, the G-Port configures itself as an E-Port.
  • Auto Mode – an interface that is configured in auto mode can operate in one of the following modes: F Port, FL Port, E Port, TE Port, or TF Port, with the port mode being determined during interface initialization.


CCNA Exam Simulation Practice Exercises – Just $19.95!

January 1, 2019 at 12:28 am

Are you looking for an affordable way to practice for the CCENT or CCNA simulations you might receive in your actual exams? Look no further.

The CCENT/CCNA Exam Simulation program emails you at least three Packet Tracer* challenges per week! The next day you receive the solution! This program is currently available at an introductory rate of $19.95 (one-time fee). The completed bundle of practice labs will sell after the introductory rate for $49.95. Get started studying and save money now!

* Packet Tracer 7.2.1 is used for these simulations. Raw config files are also provided for those students using GNS3 or some other lab prep tool!

NOTE: This is a solution for those ACTIVELY pursuing their CCENT and/or CCNA certifications and need the means to verify their grasp of the material learned elsewhere.

The solution is a working lab for you to verify and test as well as a write-up document that provides you with valuable hints, tips, and simulation tricks! The exercises also provide tips on additional practice ideas for each challenge.


CCNA Exam Simulation

Did you know that the amazing Packet Tracer tool is free and legal for all to use for CCENT and CCNA prep? You just create a free account (enroll) and download it here:

If you have already created your Packet Tracer account, here is a link to the direct download of Packet Tracer. Note that Packet Tracer supports 32 and 64-bit Windows installs, as well as 64-bit Linux:

Are you ready to get started today on your first Simulator Challenge? Just use the PayPal button below! Questions? Email

Email Address for Lab Delivery

Simulation Exercises in your challenges include:


  1. Configuring IPv4 Addressing
  2. Configuring IPv6 Addressing
  3. Configure IPv6 Stateless Address Auto Configuration
  4. Configure VLANs
  5. Troubleshoot VLANs
  6. Configure Trunks
  7. Trunk Troubleshooting
  8. Configuring and Verifying Port Security
  9. Configure Inter-VLAN Routing (ROAS)
  10. Inter-VLAN Routing (SVIs)
  11. Configure IPv4 Static Routing
  12. Configuring IPv6 Static Routing
  13. Configure RIPv2
  14. RIPv2 Troubleshooting
  15. DHCP Configuration
  16. NTP Configuration
  17. Configure ACLs
  18. Configure NAT
  19. Configuring Syslog
  20. Configure Device Management
  21. Configure Basic Device Hardening


  1. Configure STP
  2. Configure EtherChannels
  3. Configure OSPFv2
  4. Configure OSPFv3
  5. Troubleshooting OSPF
  6. Configure EIGRP for IPv4
  7. Configure EIGRP for IPv6
  8. Troubleshooting EIGRP
  9. Configuring the WAN
  10. Configuring HSRP
  11. Configuring SNMP
  12. Configuring SPAN

Email Address for Lab Delivery

Looking for other great CCNA content – be sure to visit that AJSnetworking category!

CCNA Exam Simulation

CCNA Data Center – The Finite State Machine in UCS

December 20, 2018 at 12:46 pm

Finite State Machine

A key element of the Cisco UCS system you should understand is called the Finite State Machine (FSM). The FSM is a workflow model that is composed of the following:

  • A finite number of stages (states)
  • Transitions between those stages
  • Operations

The current stage in an FSM is determined by past stages and the operations performed to transition between the stages. A transition from one stage to another is dependent on the success or failure of an operation.

Cisco UCS Manager uses FSM tasks that run in the Data Management Engine (DME) to manage endpoints in the Cisco UCS object model. For your CCNA Data Center studies, it is very important that you realize what types of tasks fall under this FSM workflow model. These include:

  • Physical components – examples include the chassis, I/O module, and servers
  • Logical components – examples include the LAN cloud and policies
  • Workflows – examples include server discovery, service profile management, downloads, upgrades, and backups

The DME manages the FSM stages and transitions and instructs the Application Gateway (AG) to perform operations on the managed endpoints. Each stage can be considered to be an interaction between the DME, AG, and managed endpoint. The AGs do the real work in interacting with managed endpoints, such as the CIMC, adapter, or I/O module.

When all of the FSM stages have run successfully, Cisco UCS considers the FSM to be successful. If the FSM encounters an error or timeout at a stage, the FSM retries that stage at scheduled intervals. When the retry count has been reached for that stage, the FSM stops and Cisco UCS Manager declares the change to have failed. If an FSM task fails, Cisco UCS Manager raises faults and alarms.

Multiple FSM tasks can be associated with an endpoint. However, only one FSM task at a time can run. Additional FSM tasks for the same end point are placed in a queue and are scheduled to be run when the previous FSM task is either successfully completed or fails. You can view the FSM details for a particular endpoint to determine if a task succeeded or failed. You can also use the FSM to troubleshoot any failures.

IoT Edge and Fog Computing

December 5, 2018 at 7:52 pm

In my CBT Nuggets course – Cisco CCIE Evolving Technologies – we tackle IoT in some decent depth as required of us by Cisco Systems. In this post, I wanted to warm you up for some of that by introducing you to two terms – Fog and Edge Computing.

Fog Computing

These days, all we seem to hear about is cloud computing. And cloud computing certainly plays into IoT, as we’ll discuss. But there’s also edge and fog computing that is quite popular when it comes to the Internet of Things.

Fog Computing

Let’s actually start with fog computing. You’re going to note that both fog and edge computing refer to having processing taking place that is much closer to the actual devices than the cloud. So think about the cloud, public or private. It’s kind of way up there in the stack.

So we might have all of these IoT devices running at a local location. And we want computing to take place closer to them than that faraway cloud. So fog computing is an example of this. And where the processing takes place with fog computing is in the network devices, such as gateways and routers and switches that make up the network.

If we can do some of the processing there, closer to the actual devices– thus, the concept of fog, which is closer to the ground instead of a full-blown cloud– then this is going to do wonders for the IoT implementation. Typically, notice that we’re processing or storing information for the higher levels and those higher levels might actually exist in the cloud. We often do this in a hierarchical type format.

An example I want to give you is temperature monitoring. So let’s say we have these IoT devices that are monitoring temperatures.
If we can have intelligence in our network devices and do some fog computing, one of the things that we might have those devices do is see, inside the data, if there’s actually been any temperature change and, if there hasn’t been a temperature change, to stop the flow right there. Otherwise, the device can alert the cloud, and then have the cloud trigger some type of temperature alarm.
 So in this case, it’s reducing the amount of bandwidth we consume, and even reducing processing that we might need to do somewhere else in the stack, based on the fact that there’s been no temperature change.

Edge Computing

Edge computing takes the computing horsepower or the processing horsepower and it moves it even closer to the smart things by actually building the intelligence into the smart things themselves. We sometimes refer to this as mist computing because it’s even closer to the actual devices than fog computing. Typically, it’s intelligence built into those smart devices.

Notice that we could structure this in a very hierarchical fashion. If it’s time-sensitive information, we should be analyzing it as close to the source as possible. We could then use our fog nodes, things like gateways and network devices, that can aggregate the information taken from the actual smart things themselves.

Notice you might want to store information locally in your data center initially and then move it to the cloud for the ultimate storage and for more long-term things, like trend analysis and more detailed analysis. This might even include some machine learning.

So remember, fog computing is intelligence and processing that we’re going to do pretty close to the devices themselves. But edge computing would be an IoT reference, where we’re even closer to those devices. In fact, this is often implemented in the devices themselves, making them smart devices that are capable of computing and processing.

Thanks for reading!

Interested in more great information on this fascinating topic? Check out this article:

Do We Need To Replace The Cloud With Edge Computing?