Are you a fan of Putty? What about SuperPutty? Well, this program that I’m about to tell you about, compiles the best of SuperPutty GUI, SecureCRT functionality for FREE!

That’s right, you get SSHv1 & 2, Telnet, VNC, RDP, and many other common terminal protocols all in one program. But lets talk about the best part. mRemoteNG offers tab view – you can have SSH tabs and RDP tabs open in a single program (mRemoteNG) at the same time!

It’s pretty amazing. Lets give these developers some love, download and use their program, donate and spread the word!

Policy Based Routing (PBR)

When a packets enters a router on a particular interface, it route packets based on any source address – even if that packet is sourcing an IP from a different network. The packet is routed either using a configured VRF or the default VRF. With PBR you can modify the direction an IP packet takes based on a criteria (route-map). PBR is performed right before regular routing. If a packet coming into an interface does not match the PBR criteria, then the packet will be routed normally (either in the default routing table or configured VRF). PBR that is applied to an interface does not apply to local generated traffic (aka ping ssh etc). PBR can also be applied globally (all interfaces where routing occurs).

You can accomplish PBR by completing the following high-level tasks:

1. Define match criteria using ACL/Prefix-List (aka what traffic you want to modify routing for)

2. Assign the criteria to a Route-Map sequence, and specify parameters

! Configure ACL for matching Source/Dest IPs

! Configure Route-Map to match on IP/length and set parameters for that packet

#match ip address [ACL]


#match length [length]

! The default keyword simply uses the default routing table FIRST, and if it does not find a route match use the IP/interface specified in the command. The precedence and tos values can be changed for traffic that is routed via PBR.

#set ip next-hop [ip address(es)]

#set ip default next-hop [ip address(es)]

#set interface [interface type/num]

#set default interface [interface type/num]

#set ip precedence [value]

#set ip tos [value]

! Apply PBR to incoming interface

#ip policy route-map [name]

! Apply PBR for local generated traffic

#ip local policy route-map [name]

! Verify PBR

#sh ip policy

#sh route-map

#debug ip policy

Cisco VLAN Trunking Protocol (VTP)

VLAN Trunking Protocol (VTP) is a Cisco proprietary protocol that makes administration of VLANs across a L2 network easier. Simply put, VTP propagates VLANs across trunk links to other switches, so that only one configuration line needs to be changed in one switch, and the rest of the switches configure that VLAN # in their VLAN database.

In VTP, five things must happens for VTP to proporgate VLANs:

  1. The devices must be in the same VTP domain (case sensitive)
  2. The devices must have the same VTP password (case sensitive)
  3. The device receiving a VTP message must have a lower configuration revision number than itself (output in sh vtp status)
  4. VTP messages are only sent on Trunk links, not access ports. A Switch connected to another switch via an access port will not allow VTP to propogate VLANs.
  5. The device must be in server or client mode (not transparent). Transparent participates in the vtp domain, but does not update its configuration register number. It forwards vtp messages out it’s trunk ports.

There are 3 flavors of VTP:

  • v1
  • v2:
    • Supports Token Ring VLANs
    • Supports consistency checks.
    • In transparent mode it will forward the message without checking version information, a transparent switching using vtp will check
  • v3:
    • Supports for the full range of VLANs (Normal AND extended)
    • Support for Propagation of PVLANS
    • Options for cleartext or Hidden VTP Passwords
    • Support for Propagation of 802.1s MST configuration info.
    • Can be turned off globally, or per-port

In all flavors of VTP, the vtp password is never displayed in the running-config

VTP v1 devices (that are v2 capable) will upgrade itself to v2 if:

  1. Detects if it is connected to a v2 neighbor
  2. Detects if it is connected to a v3 neighbor

VTP v2 device will remain as v2 if a v3 neighbor is detected (even if it is v3 capable). VTP v3 must be manually configured, it does not automatically upgrade to v3 from other switches.
VTP v1 and v2 automatically update the VTP domain name on incoming VTP messages if the domain name is not manually set/is NULL. However, VTP v3 does not have this functionality. in VTP v3 you must always manually configure the domain name for it to be joined.
VTP v3 is backwards compatible with v2 (on a per port basis where it is detected).

The other major difference with VTP v3 is that all switches by default are still VTP Servers, but they are considered “secondary servers”. It is very similar to VTP Client mode, because it does not allow manual addition or deletion of VLANs, or not allowed to update other VLAN databases. You then make one of your switches a “primary server”. This is manually configured. There can only be one Primary server per VTP domain. This Server is allowed to make the changes to their VLAN database, and propagate it. 

! Configure a vtp domain (Can be done from privileged EXEC or Configuration Terminal)

#vtp domain [name]

! Configure vtp password (Can be done from privileged EXEC or Configuration Terminal)

! When configured this way, it will display the password in the sh vtp password command. It will also store the password in cleartext in the vlan.dat file.

#vtp password [password]

! When configured this way, the sh vtp password command will instead show a 32-bit hash of the password (effectively hiding it). service password encryption ALSO encrypts the contents of the password. The hidden keyword in addition to scrambling the output of sh vtp password, it also scrambles the cleartext password in the vlan.dat file.

#vtp password [password] hidden

! Once you use the vtp password hidden command, you use the secret keyword to specify the 32 hex character on the OTHER switches

#vtp password [32-hex character] secret 

! Configure vtp version (Can be done from privileged EXEC or Configuration Terminal)

#vtp version [1 | 2 | 3] 

! Setting v3 device to a primary server (Can be done from privileged EXEC or Configuration Terminal)

#vtp primary 

! VTP pruning is disabled by default on cisco switches 

! VTP pruning is how switches in a VTP topology ‘prune’ trunk connections to prevent unnecessary broadcasts. The switches in a topology that do not have an access port in a said VLAN, sends a ‘vtp prune’ message to upstream trunks to prune that vlan off the trunk

!Enable VTP pruning

#vtp pruning

! Verification

#sh vtp status

By default all ports on a cisco catalyst switch start out as access ports (switchport mode dynamic auto), and send DTP messages to negotiate a trunk. The switchport nonegotiate command tells the switch to not send DTP. DTP messages contain a field for the VTP domain. DTP cannot negotiate a trunk if there is a mismatch in the VTP domain between switches

! Disable/enable DTP (on by default on a port)

#sw non

#no sw non

! Configure DTP to passively listen for DTP messages, and will negotiate a trunk if it receives a DTP message. Starts out as access port until it receives other DTP messages.

#sw mode dynamic auto

! Configure DTP to actively send DTP messages, and if it receives a reply it negotiates a trunk

#sw mode dynamic desirable 

Types of VLANs:

  1. Standard VLAN = 1-1005
  2. Extended VLAN = 1005 and above

When a standard VLAN is configured, it is copied into the running configuration and the vlan.dat file located in flash. When a extended VLAN is created it is only copied into the running configuration. You can only create extended VLANs when the switch is in vtp transparent mode. If a switch is operating in vtp server mode and VLAN configuration exists in both vlan.dat and startup config, it will ignore the startup config vlans and use the vlans in the vlan.dat  file for standard vlans.

Bidirectional Forwarding Detection (BFD)

BFD is a lightweight keepalive protocol that runs independently from your routing protocol(s).
When a link goes down on a router (not using any in-between devices like a switch) it re-converges instantaneously. The reason for this is because since there is no L2 connectivity, L3 connectivity obviously cannot happen and therefore the routing protocol can act on it fast. However, if a link does down somewhere upstream (that is, not directly attached to the router) then the routing protocol will have to wait for its dead/hold timer to expire before re converging. The benefit of BFD is that it can detect L2 disconnects somewhere upstream, and then report that to your upper-layer routing protocol to re-converge faster. 

  • RFC 5880 – Bidirectional Forwarding Detection (BFD)
  • RFC 7419 – Common Interval Support in BFD

There are two versions of BFD

  • Version 0 – Echo mode with asymmetry
  • Version 1 – Echo mode with symmetry

BFD Configuration

! Turn on BFD on the interface level. The interval [ms] time is the time frequency that the interface sends out BFD echo packets to it’s neighboring router. The min_rx [ms] time is how often it expects to receive BFD echo packets from it’s neighboring router. Multiplier [interval] is the same as dead time for a routing protocol. If a router does not hear a BFD echo packet from it’s neighbor in [multiplier x min_rx ms] then it will report to the upper layer routing protocol that the link is dead (that is if you have the routing protocol end configured)

#bfd interval [ms] min_rx [ms] multiplier [interval]

! Associate BFD to your routing protocol, and interface

#router eigrp 1

#bfd [all-interfaces | interface {name}]

! Verification commands

#show bfd neighbors

#debug bfd [packet|event]

Virtual Port-Channel (vPC) on Cisco Nexus

Virtual Port-channel (vPC) – What is it?

vPC is a feature on Cisco Nexus switches that allows you to do port channel configuration across two separate switches. The benefit of this is that you can have a server (or a switch – practically any device that does port-channeling) create a port-channel configuration, and one uplink goes to one nexus switch, and the other uplink goes to another nexus switch. Despite the port-channel being physically connected to two different switches, the two vPC peers synchronize their control plain information – which makes their associated member ports part of one of logical switch. In a regular switching design, this would cause MAC Flapping between server port 1 and server port 2. But since vPC is used to synchronize the control plane data and their associated member ports – this type of topology becomes possible. 
vPC consists of 2 physical switches called ‘vPC Peers’. These switches must be identical for a vPC peer to be formed. If it is running a nexus-type chassis, then the two line cards have to be identical.

Cisco Fabric Services Over Ethernet (CFSoE) is a protocol developed by Cisco to facilitate the communication between two vPC peers. the CFSoE is the protocol used to synchronize the MAC, ARP, and IGMP tables. It is also used to compare hardware revisions when in the negotiation phase of the vPC Peers. 

vPC Peers form a vPC Domain. The two vPC peers must match the Domain values to be considered in the same vPC domain. The LAG ID (LACP System ID) is inherited from the Domain ID, that is then shared across the peers. This makes it to where when LACP is found to be on a vPC member, that the two switches advertise the same LAG ID. Additionally, the vPC domain number (that is configured) is used in the LACP System Identifier. The well known MAC of 00:23:04:ee:be:xx is being used by Cisco for the LACP vPC identification. The last 8 bits are encoded with the vPC domain number that is configured. When creating a back to back vPC with nexus switches, the vPC peer domains must not be identical because of the LACP system identifier number that is inherited.

vPC peers also elect a primary and secondary vPC peer. This is elected based on the vPC Role Priority[1-65535]. The default role priority on a switch is 32667. If the Role Priority is the same on both switches the MAC Address between the two is used. Whichever switch with the lower priority/MAC becomes the primary while the other becomes the secondary. Whenever a type 1 consistency mis-match is found on the vPC peers, the secondary box disables their vPC member ports while the primary keeps them up.

There is a feature called “vPC peer switch” that can be enabled on vPC peers. What this does is make it to where both the vPC “Primary” and “Secondary” devices appear and operationally function as the root switch within a spanning tree topology. Essentially when you enable the feature the ‘vPC system MAC’ is inherited into the spanning-tree priority for all VLANs. The priority, however, is not changed. When you set the spanning-tree priority value to be the same as the root bridge(on the other switch), it does not cause a topology change by re-electing the root bridge. Instead both the primary and secondary peers advertise the vPC System MAC and the priority. 

vPC Peers track reach-ability between each other using Peer Keepalives. Peer Keepalive is a UDP Ping to a L3 interface on the other peer. Any type of L3 interface can be created to facilitate this UDP ping communication: Routed Interface, L3 Port Channel, SVI, etc.

Peers sync their control plane over the Peer Link. A Peer Link is just a layer 2 port-channel between the peers. A miniumum of x2 10GB Links is needed for the vPC Peer Link. This is the link that synchronizes the MAC, ARP, and IGMP tables to each other so that both switches know that a particular MAC lives off both ports – not just one (just like a regular port-channel, but on two different switches)

A member port is the ports that are synchronized together to create the port-channel across the two switches IE. downlink and/or uplink ports.

A orphan Ports are ports that are singly attached connection to a vPC Peer (either by design, or by vPC Peer Failure)

Orphan Ports use modified loop prevention:

  • Traffic from remote Orphan is allowed to enter peer link and exit via local Member
  • Traffic from remote Member is allowed to enter via peer link and exit via local Orphan
  • Traffic from remote Member is not allowed to enter via peer link and exit via local Member

By default two vPC peers running HSRP do active/active forwarding instead of active-standby (by default, no configuration needed). They achieve this by both vPC peers listening for the vMAC of HSRP and from there route the traffic. If the downstream server or switch is hashed to the ‘standby’ hsrp router, the ‘standby’ switch will still listen for the vmac and route the traffic itself (instead of switching the traffic over the peerlink).
The only problem with the above is that HSRP/L3 functions are not communicated down to the vpc (or vice versa). So if a L3 function goes does, the vPC knows nothing about it. If the Peer link goes down, the secondary disables its SVIs and member ports. However, if the routed ports also go down on the primary, then the server is then isolated. In the case of HSRP, if the routed ports go down on one switch, the SVI for HSRP is still actively listening and trying to route traffic (to of which it cannot route). What you would want to do is implement enhanced object tracking to also track the routed ports, so if they do go down, HSRP is switched from A/A to A/S. See below for config.

High-Level Configuration 

1. Turn on the vPC feature

2. Define the vPC Domain

3. Establish a vPC Peer Keepalive connection

4. Establish a vPC Peer Link connection

5. Establish the vPC Member ports

The above steps detail out the order of operations when configuring/bringing up the vPC. A Member Port cannot be established unless, the peer link is established. A Peerlink cannot be established unless the keepalive connection is established. 

! Turn on vPC feature

#feature vpc

! Define the vPC Domain

#vpc domain [1-1000]

! Define the peer keepalive destination (under vPC configuration mode). If you do not specify a VRF, the default management VRF will be used for the destination. If any other VRF is used you need to specify that VRF.

#peer-keepalive destination [IP Address] {vrf [name]}

! Create a port channel between the two vPC peers. Under the port channel you specify the peerlink as a the ‘vpc peer-link’. When configuring a vPC, Spanning Tree Bridge Assurance must be enabled on the peer-link. By default it will configure the port-channel with ‘spanning-tree port type network’ (which essentially enables bridge assurance). The reason for this is because if one VLAN is created on one vPC peer but not the other, bridge assurance will prune that VLAN off the trunk. 

#interface port-channel1

#switchport mode trunk

#vpc peer-link

#int eth1/x

#switchport mode trunk

#channel-group 1

#int eth1/x

#switchport mode trunk

#channel-group 1

! Create Member ports (trunk or access). When you type just ‘vpc’ under the port-channel configuration, it inherits the number of the vpc with the port-channel number itself. So if you configure port-channel 11, and type just vpc, it will create vpc 11. The vpc numbers must match between both peers to form the member ports. The port-channel number between the two vpc peers, however, do not have to match. For simplicities sake it makes sense to match them on both sides. 

#int eth1/x

#channel-group [#] mode active

#int port-channel[#]


#vpc {#}

! Configure peer-switch feature on vPC Peer Switches. This must be configured on both the Primary and Secondary Switch for the feature to work.

#vpc domain [#]

#vpc peer-switch

! Configure delay restore for the vPC Peer Link. Delay restore is a ‘wait timer’ for how long the vPC Member ports have to wait until they come up, when the vPC Peer Link is restored/initialized. The reason for this is mainly to let your L3 Routing Protocol to converge first before bring up the vPC Members.

#delay restore [#]

! Configure the vPC Auto Recovery timer

#auto-recovery reload-delay [#]

! Configure the vPC Secondary Device to not disable its SVIs if the Peer Link goes down

#dual-active exclude interface-vlan

!Configure the vPC orphan ports to also be disabled if the peerlink fails and secondary receives a Keepalive ping

#vpc orphan-port suspend

! vPC verification commands

#show vpc

#show vpc keepalive

#show vpc role

#show vpc consistency-parameters

#show port-channel compatibility-parameters 

#show run int po[#] membership

! Displays orphan ports that are attached to a vPC peer. This will only show ports that are not configured for a vpc. It will not show orphaned ports from a failure point of view.

#show vpc orphan-ports

! Configure advanced object tracking for Nexus vPC. What this does is allow other ports (such as uplink L3 ports) to be tracked so that if those interfaces fail, then the secondary vPC will become primary vPC. The same config can be applied to HSRP, where HSRP does A/A. Advanced object tracking can force both of the SVIs to be A/S. See below for failure scenario
! Define the track object and the interface to ‘track’

track [#] interface [interface name/num] line-protocol

! Combine each track object created and type them to a boolean operatortrack [#] list boolean [OR|AND]object [#]object [#]

! Tie the Tracking group to the vpc

#vpc domain [#]

#track [#]

! Tie the tracking to HSRP

#int vlan [#]

#hsrp [#]

#track [#]

! Enable self-isolation in vPC under domain config (must be enabled on both peers)


vPC Initialization Order of Operations:

1. vPC Process Starts

2. IP/UDP 3200 Peer Keepalive connectivity established

3. Peer-Link adjacency forms

4. vPC Primary/Secondary role election

5. vPC Performs consistency checks

6. Layer 3 SVIs move to up/up

7. vPC Member ports move to up/up state

vPC Consistency Checks

The vPC Peers perform ‘consistency checks’ to bring the vPCs link and member ports up. 

1. vPC Peers sync control plane over Peer Link with Cisco Fabric Services (CFS)

2. Verifying hardware and configuration match (e.g speed, duplex, STP config, LACP mode etc.)
Three types of consistency checks:

Type 1 Global

  • Mismatch results in vPC failing to form (e.g hardware not matching, STP config not matching)

Type 1 Interface

  • Mismatch results in VLANs being suspended on vPC member (e.g STP port type network vs. normal)

Type 2

  • Mismatch results in syslog message but not vPC failure
  • Can result in failures in the data plane (e.g MTU mismatch)

vPC Failure Scenarios

vPC Member Port Failure Detection

  • vPC Peers exchange vPC member status over the peerlink
  • Failed Member Ports result in “orphan ports”
    • Orphan Ports are single attached ports that use a vPC VLAN
    • vPC VLANs are any VLANs allowed on the Peer Link
    • show vpc orphan-ports

vPC Peer Link Failure

  • vPC Secondary Pings Primary over Peer Keepalive
    • If vPC Primary responds
      • Disables vPC member ports on secondary
      • Disables SVIs on Secondary
      • Goal is to force end host to forward via primary
    • if vPC Primary is dead
      • Promote vPC Secondary to Operational Primary
      • Continue to forward traffic on new Primary
  • Peer Keepalive and PeerLink must not share fate in order to prevent Split Brain
    • e.g seperate MGMT Switch, seperate port channels on seperate line cards

vPC Auto Recovery

  • Certain Failures can result in neither vPC Peers forwarding
  • Power Outage with node failure problem case
    • Power outage on both Peers
    • Only one Peer is restored
    • vPC Peer Keepalive never comes up
    • Means vPC Peer Link can never come up
    • Means vPC Member Ports can never come up
    • vPC Members are isolated
  • vPC Auto Recovery allows a single Peer to promote itself to Primary
    • If Peer Link does not initialize before auto recovery timeout, promote myself to primary and bring up Member ports
  • Gradual Failure problem case
    • vPC Peer Link goes down
    • vPC Secondary pings vPC Primary and gets response
    • vPC Secondary Disables vPC Member Ports
    • vPC Primary completely fails
    • vPC Secondary does not re active Member Ports
    • Member ports are isolated
  • vPC Auto Recovery Allows Secondary to detect this over Peer Keepalive
    • vPC Primary is continually tracked over vPC Peer Keepalive
    • Peer Keepalive failure at a later time results in Secondary promoting itself to Primary
    • Secondary re-activates its Member Ports

The default timeout for vPC Auto Recovery is 240s. After 240s, if the other peer is still not detected or reachable, it brings up the vPC member ports/the vPC (in both cases stated above).

vPC Orphan Port Failures Problem case:

  • vPC Primary And Secondary are Default Gateways for vPC VLAN hosts
  • Orphan Port exists on Secondary
  • vPC Peer Link fails, but Primary remains up
  • Secondary Pings Primary, gets a response
    • Disables vPC Member Ports
    • Disables SVIs
  • Orphan is now isolated from its Default Gateway

The above is only a problem if the orphan is connected to the secondary when the failure of the Peer Link occurs. However, it is hard to predict when vPC Peers will be secondary or primary in a topology based on previous failures, updates etc.
Fixes to the above problem:

  • Dual home the orphaned port
  • Single attached hosts connect to a single access switch, and then dual home the access switch to the vPC peer.
  • Single attached ports could use non-vPC VLANs
    • Port only counts as orphan if it is using a vPC VLAN
    • Non-vPC VLANs require additional east/west trunk between vPC Peers
  • Don’t disable SVI when Peer Link fails on Secondary
    • enable under vpc domain config:”dual-active exclude interface-vlan’

Problem Case:

  • Active/Standby Failover Device connects via orphan ports on to vPC Peers
  • Active Device Connects to vPC (operational) Secondary 
  • vPC Peer Link Fails, but primary remains up
  • Secondary Pings Primary, gets response
    • Disables vPC Member Ports
    • Disables SVIs
    • Active device sees port as still up/up and does not failover
    • Active device is now isolated from it’s default-gateway, and potentially L2

Fixes to the above problem:

  • Run Active/Active
  • Dual home each device to vPC Peers
  • Force the active device to failover to the vPC Primary
    • interface level “vpc orphan-port suspend”

Problem Case:

  • Peer Link and northbound routing links share same linecard
  • Peer Keepalive does not fate share with peerlink
  • vPC Primary linecard fails
    • Peer Link is Lost
    • Northbound routing lost
  • Secondary pings primary, gets reponse
    • Disables vPC Member Ports
    • Disables SVIs
  • Layer 2 traffic is collected via primary, but cannot route to WAN
  • Servers Isolated

Fixes to the above problem:

  • Keepalive, peerlink, and routing links do not share fate
  • Enhanced object tracking on primary
    • If Peer link && WAN == Down, failover to secondary
  • vPC Self-Isolation
    • If peerlink && WAN == Down, tell secondary over keepalive
    • Available in nx-os 7.2 and later

Cisco Certification rebuild!

It’s official! Cisco has finally decided to do a complete rebuild of their certificate program.

Check out the famous network blog by Kevin Wallace:

This is all the information we have right now, but stay tuned and keep learning!

Forest – Habit app

Forest Productivity App

Looking to “Gamify” your study habits? Or maybe you just want to feel artifically good about yourself while putting in the hours to study? I did, which is why I stumbled upon “Forest”, which is a study/habit building application.

Each time I study, I start a timer, 15, 25, or whatever I want. 15 minutes will get you a bush while 25 minutes will land you a tree. Cut your time short? You’re virtually killing your tree. Don’t be that guy/gal.

Objective Study Partner

Look, there are many areas of life where having a partner is the best, and the worst. When studying, with two people setting common objectives and targets, makes for a successful partnership.

Just like this blog, it’s a place for us to dump projects, resources, and roadblocks that we identified throughout our journey. Luckily, we have different paths but a similar journey.

Daniel called me one day and asked me if I’d be interested in setting real objective goals. Well… I’m an MBA (humble brag), aspiring Network guru and I know Daniel is amazing at what he does, but he’s gonna have to write about that… With all of this said, what could I lose? It’s obviously in my blood to set goals and achieve them.

Daniel and I both have CCNA’s – to date. So, we set our first goal. In two weeks we will jump on a conference call (day 2 of my first real vacation!) to cover EIGRP and OSPF at the NP level. This means that we will both study independently, come together on a call and share what we both learned. Sounds a lot like your moms book club doesn’t it? Cringy…

But it works.

Get the emotions out of your head so that you can maintain peak clarity! This is a long road to travel (we’re coming for you ‘Pan-American Highway’), so find a reliable partner, fuel up and start rolling.

CDP Neighbor – 6.2.2019

Technology: CDP Neighbor

What does this technology do? CDP Neighbor is used to identify directly connected devices on a Cisco system.  

Use case? If you don’t have physical access to an adjacent switch, you can use CDP Neighbor to identify the device on a specific port. 

Basic Command:
#show cdp neighbors

Full Command:
#show cdp neighbors [ interface { ethernet slot/port | mgmt mgt-num}][ detail]
  • interface – Shows CDP neighbor info for that specified interface. 
  • ethernet – Shows CDP neighbor info for an Ethernet interface. 
  • mgmt – Shows CDP neighbor info for management interface. 
  • detail – Shows the detailed information about CDP neighbors. 

My lab: 

How I used it: 

In todays lab, we will use CDP Neighbor commands to determine which devices are directly connected to the MainDistribution switch from within the CLI of the MainDistribution.  It’s obvious that the AccessLayer switch and the EdgeRouter are directly connected, however, we are not always working in lab environments. In a real world application, the AccessLayer switch may be several hundred feet away. Understanding CDP Neighbor commands will help us determine the exact adjacently attached devices that we have in our network. 

To start, I started all of my network devices. Once booted, I decided to login and run the CDP Neighbor command

#show cdp neighbors

From here you can see the “Local Intrfce” and the “Port ID”. The Local Interface identifies the current switch that you are currently working on and the port that is locally attached to the remote device. The Port ID identifies the remote device port number. So, MainDistribution (Gig 02 from the “Local Intrfce”) is directly connected to the AccessLayer (Gig2/1 from the Port ID) switch. 

Now, you may be asking, how do you know that the adjacent device is the “AccessLayer”? Well, based on the previous image, you cannot unless you know the environment very well. Let me explain. 

The “Device ID” column shows the adjacent device “Hostname”. If the hostname is configured and you understand the name, then you will be able to identify the adjacent switch. Take a look: 

I changed the hostname of the adjacent device so that you can see the difference between screenshots. In my first image, the Device ID said “Switch”, which is the default hostname. Since I changed it, you can now see “AccessLayer” as the Device ID for the connected device. 

Now that you can identify the adjacent device, the local port number and the adjacent port number, we can now spend some time to understand the “Holdtme” column and what to do if the CDP command isn’t showing anything. 

“Holdtme” means Hold Time, this is the length of time that the switch will hold that information before it discards it. You can use the following command to specify the time (Default = 180s). (Think “Time To Live”) 

(config)#CDP holdtime <60>

I personally prefer the shorter times, but if you have a ton of management traffic, you can cause CPU/RAM overload… You can always set the time when you are troubleshooting and reset it when you’re done. 
Finally, if CDP neighbors is not working, you may need to enable it on your devices. This is a very easy command.  

(config)#CDP enable