{"id":4062,"date":"2026-10-13T10:41:37","date_gmt":"2026-10-13T10:41:37","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/cisco-200-301-cdp-lldp-etherchannel-troubleshooting-lab\/"},"modified":"2026-10-13T10:41:37","modified_gmt":"2026-10-13T10:41:37","slug":"cisco-200-301-cdp-lldp-etherchannel-troubleshooting-lab","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/cisco-200-301-cdp-lldp-etherchannel-troubleshooting-lab\/","title":{"rendered":"Cisco 200-301: CDP, LLDP and EtherChannel Troubleshooting Lab"},"content":{"rendered":"

A switch can report two connected uplinks while a user VLAN still fails between buildings. Perhaps the cables terminate on unexpected ports, LACP never formed a bundle, or the logical port-channel allows the wrong VLANs. In the Cisco CCNA 200-301 exam<\/a>, device discovery and EtherChannel are practical verification skills: you must show which devices are connected and whether multiple physical links behave as the intended single logical connection.<\/p>\n

This lab works through those decisions in sequence. The baseline is a pair of managed switches, SW1 and SW2, each with two intended links between them. A host in VLAN 10 connects on one side; another VLAN 10 host connects on the other. A second VLAN, 20, is carried for a separate department. All names and port numbers are illustrative. Build the topology in a supported isolated Cisco IOS\/IOS XE lab and check actual interface names and feature availability on your platform before applying commands.<\/p>\n

Inventory the physical topology before combining links<\/h2>\n

Draw two connections: SW1 Gi1\/0\/1 to SW2 Gi1\/0\/1 and SW1 Gi1\/0\/2 to SW2 Gi1\/0\/2. Mark expected device IDs, local and remote ports, and the destination VLANs. If the drawing is wrong, an apparently perfect switch configuration can be misleading. The first task is not to create Port-channel 1; it is to prove that the intended physical links terminate where the design says they should.<\/p>\n

Cisco Discovery Protocol (CDP) can show neighboring Cisco device identifiers, the local interface and the neighbor’s reported interface. Start with these read-only commands on SW1:<\/p>\n

SW1# show interfaces status\nSW1# show cdp neighbors\nSW1# show cdp neighbors detail\nSW1# show interfaces description<\/code><\/pre>\n
Compare every reported local port and remote port with your drawing. A neighbor on Gi1\/0\/3 when the design expects Gi1\/0\/2 is a wiring or documentation issue, not necessarily an EtherChannel negotiation failure. A device that appears in CDP may still have the wrong switchport mode, native VLAN, trunk allowed list or operational speed. CDP tells you which neighbor announces itself; it does not establish application connectivity or prove that every advertised fact is trustworthy.<\/p>\n
Device discovery has a trust boundary. In a managed environment, disable unnecessary discovery advertisements on untrusted access ports according to policy, and do not expose management details merely to make a lab output prettier. For the exam, know where a discovery table is useful and where ordinary interface, MAC-table, or cabling evidence is more reliable.<\/p>\n
Check LLDP when the neighbor may not be Cisco<\/h2>\n
Link Layer Discovery Protocol (LLDP) serves a similar neighbor-discovery purpose across multiple vendors. On many Cisco IOS\/IOS XE platforms, you must enable it globally before expecting the normal neighbor table; transmit and receive behavior can also be controlled per interface. In a controlled lab, verify feature support and use the following pattern:<\/p>\n
SW1# configure terminal\nSW1(config)# lldp run\nSW1(config)# end\nSW1# show lldp neighbors\nSW1# show lldp neighbors detail\nSW1# show lldp interface<\/code><\/pre>\n
Enable LLDP on SW2 as appropriate and allow time for advertisements. If CDP sees SW2 but LLDP does not, that is not evidence that the cable is broken. Check whether LLDP is globally enabled, whether the relevant interface is allowed to transmit and receive, and whether the peer implements the feature. Reverse the comparison if LLDP sees a non-Cisco neighbor that does not advertise CDP.<\/p>\n
A summary neighbor table usually provides device and port identifiers. Detailed output can add capabilities, management addresses, system descriptions, and timers. Values and formatting vary by software release, so interpret the fields rather than memorizing one screenshot. The site’s treatment of LLDP in multivendor networks<\/a> provides the protocol context; here the task is to reconcile the discovery evidence with the intended switch-to-switch link.<\/p>\n\n\n\n\n\n\n\n\n
Evidence<\/th>\nIt helps establish<\/th>\nIt does not prove<\/th>\n<\/tr>\n<\/thead>\n
show interfaces status<\/code><\/td>\nLocal port state and negotiated characteristics<\/td>\nCorrect neighbor or VLAN carriage<\/td>\n<\/tr>\n
show cdp neighbors detail<\/code><\/td>\nAnnounced Cisco device and remote port identity<\/td>\nThat the inter-switch trunk forwards user VLANs<\/td>\n<\/tr>\n
show lldp neighbors detail<\/code><\/td>\nAnnounced multivendor neighbor information<\/td>\nThat LACP is negotiated or all peers are trusted<\/td>\n<\/tr>\n
show mac address-table<\/code><\/td>\nWhere MAC addresses were learned<\/td>\nThat the physical drawing is correct by itself<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Form an LACP EtherChannel on matching interfaces<\/h2>\n
Once the physical peers are verified, combine the two links using the IEEE Link Aggregation Control Protocol, or LACP. The resulting EtherChannel should operate as one logical Port-channel interface. On common Catalyst-style switches, both peers can use mode active<\/code> to initiate negotiation. One active and one passive peer can also negotiate, but two passive peers will not initiate LACP with one another. An on-mode static bundle is not a substitute for checking protocol compatibility.<\/p>\n
On SW1 and SW2, confirm that both prospective member links support compatible speeds and Layer 2 settings. The following is an illustrative two-member Cisco IOS switch configuration, applied independently on each peer. Some platforms require matching trunk properties on the physical interfaces before the port-channel is added; others inherit most settings from the logical interface. Use the platform’s documented order and stop if a member is suspended.<\/p>\n
SW1# configure terminal\nSW1(config)# interface range GigabitEthernet1\/0\/1 - 2\nSW1(config-if-range)# switchport mode trunk\nSW1(config-if-range)# channel-group 1 mode active\nSW1(config-if-range)# no shutdown\nSW1(config-if-range)# exit\nSW1(config)# interface Port-channel1\nSW1(config-if)# switchport mode trunk\nSW1(config-if)# switchport trunk allowed vlan 10,20\nSW1(config-if)# end<\/code><\/pre>\n
Configure the corresponding SW2 ports as the intended peer, not as unrelated access ports. The Port-channel’s operational trunk parameters and member consistency must match the design on both ends. Do not configure two independent Layer 2 forwarding paths and disable spanning tree as a shortcut. EtherChannel aggregates the links logically; Spanning Tree Protocol still protects the switched topology, and the exact LACP settings should be validated on actual hardware.<\/p>\n
For switched-link aggregation, LACP and PAgP<\/a> represent different negotiation mechanisms. LACP uses a standards-based exchange; PAgP is Cisco proprietary; static on-mode EtherChannel does not negotiate the same way. The v1.1 CCNA verification objective emphasizes LACP, so practice reading its real status rather than spending time treating every historical bundle mode as equally important.<\/p>\n
Verify the bundle instead of trusting the configuration<\/h2>\n
On both switches, collect the port-channel summary, neighbor state, trunk list, and spanning-tree status after the configuration. The spelling and availability of certain secondary commands vary with Cisco software family, but the core show etherchannel summary<\/code> command is a valuable first check.<\/p>\n
SW1# show etherchannel summary\nSW1# show lacp neighbor\nSW1# show interfaces Port-channel1\nSW1# show interfaces trunk\nSW1# show spanning-tree vlan 10\nSW1# show mac address-table dynamic vlan 10<\/code><\/pre>\n
On many IOS switches, a healthy Layer 2 bundle appears with a logical Port-channel in use and member ports identified as bundled. The display commonly uses status flags such as SU<\/code> for a Layer 2 Port-channel in use and P<\/code> for bundled member ports, but these symbols are platform-specific. Read the legend on your own device. A physical interface may be up even when its LACP state is suspended or individual, which explains why two green link LEDs do not prove that a usable Port-channel exists.<\/p>\n
The next test is VLAN forwarding. An active Port-channel that carries VLAN 20 but excludes VLAN 10 will still disappoint the VLAN 10 hosts. Check the operational allowed VLAN list on both peers, the access VLAN of each test host, the MAC addresses learned, and the spanning-tree state of the logical Port-channel. Understanding Cisco VLANs, trunks and STP<\/a> establishes the switching model; this lab requires you to diagnose how an apparently healthy bundle can still fail the intended traffic.<\/p>\n
Inject failures one at a time and predict the output<\/h2>\n
A controlled fault is more instructive than repeating a successful configuration. Take a baseline of the outputs first, then change only one property in the lab and record how the symptoms differ. Restore the baseline before starting the next fault so the diagnoses do not become ambiguous.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Injected fault<\/th>\nLikely visible result<\/th>\nWhat to inspect first<\/th>\n<\/tr>\n<\/thead>\n
SW1 and SW2 both use LACP passive<\/td>\nAggregation fails to negotiate<\/td>\nshow etherchannel summary<\/code>, LACP modes on each peer<\/td>\n<\/tr>\n
One member has incompatible trunk settings<\/td>\nMember may be suspended or excluded<\/td>\nMember configuration, port-channel consistency<\/td>\n<\/tr>\n
Port-channel omits VLAN 10<\/td>\nLogical bundle may be up while VLAN 10 traffic fails<\/td>\nshow interfaces trunk<\/code>, allowed VLANs on both ends<\/td>\n<\/tr>\n
LLDP disabled globally on one switch<\/td>\nNo LLDP advertisement from that device<\/td>\nshow lldp<\/code>, local and peer transmit\/receive state<\/td>\n<\/tr>\n
One physical cable moved to an unexpected port<\/td>\nNeighbor and link\/member information disagrees with diagram<\/td>\nCDP\/LLDP port IDs and physical port state<\/td>\n<\/tr>\n
Spanning-tree unexpectedly blocks a VLAN path<\/td>\nSwitching reachability differs by VLAN or topology<\/td>\nshow spanning-tree vlan 10<\/code> and physical loops<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Do not assume an incorrect VLAN list and an inactive LACP bundle produce the same evidence. In the first case, the logical interface can be operational and a different VLAN may work. In the second, the bundle formation or member state itself is wrong. A good diagnosis identifies which hypothesis matches all available facts. That distinction is much more valuable than memorizing that a particular error always means one specific command was omitted.<\/p>\n
Understand capacity and redundancy without promising double speed<\/h2>\n
Combining two equal-speed Ethernet links can add aggregate capacity and provide member-level resilience under the right design. It does not guarantee that one individual data flow will run at twice the rate of a single port. EtherChannel typically distributes traffic among eligible members using a hashing algorithm based on selected packet fields. The selected flow can remain on one member, while multiple different flows are shared more broadly across the bundle.<\/p>\n
If one link fails, verify whether the remaining member still carries traffic, whether the logical Port-channel stays usable, and whether the failure affects all VLANs or a particular access segment. Observe interface counters and source\/destination patterns rather than drawing conclusions from a single throughput test. Member count, negotiation, device limits, and the upstream topology all influence the real behavior.<\/p>\n
Finish with an evidence-based CCNA explanation<\/h2>\n
Your final lab report should contain the expected physical port map, one current CDP or LLDP neighbor record, the EtherChannel summary, the Port-channel trunk VLAN list, and a successful host-to-host test on VLAN 10. Add one fault case: state what failed, cite the relevant output, explain why other suspected causes were less likely, and show the verified correction.<\/p>\n
That is how Network Access objectives fit together. Discovery identifies connections. LACP determines whether physical links can operate as one bundle. The Port-channel’s trunk and spanning-tree state determine which Layer 2 traffic actually crosses. A candidate who can keep those layers of evidence separate can solve a new scenario even if its switch model, port numbers, and output format are unfamiliar.<\/p>\n","protected":false},"excerpt":{"rendered":"
Verify Cisco CDP and LLDP neighbors, build an LACP EtherChannel and troubleshoot VLAN, trunk and member failures for CCNA 200-301.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,1],"tags":[],"class_list":["post-4062","post","type-post","status-publish","format-standard","hentry","category-cisco","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/4062","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=4062"}],"version-history":[{"count":0,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/4062\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=4062"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=4062"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=4062"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}