Routers and Routing Basics CCNA 2 . Chapter 4. 1. Learning About Other Devices. Discovering Neighbors Using CDP CDP Protocol Operations Information Learned by CDP Configuring and Verifying CDP Operations Creating a Network Map Using CDP Information
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Discovering Neighbors Using CDP
CDP Protocol Operations
Information Learned by CDP
Configuring and Verifying CDP Operations
Creating a Network Map Using CDP Information
Additional CDP Verification and Troubleshooting Commands
Getting Information and Troubleshooting Devices
Verifying Which Networking Layers Are Working
Cisco IOS ping and traceroute Commands
The chapter focuses on four Cisco IOS tools that help you
learn information about other routers and switches
Routers, switches, and other Cisco devices can use the
Cisco Discovery Protocol (CDP) to dynamically discover
information about neighboring devices
R2 can discover information about R1 and SW2, but not
about SW1 or R4
Basic CDP Information on R2
The show cdp neighbors command lists a single line of output per neighboring device with a lot of information.
CDP advertisements sent by neighboring devices.
advertisements, but the figure focuses just on the CDP advertisements
sent by R1 and SW2.
1. R1 sends the first CDP advertisement, which states a (default) holdtime of 180 seconds.
2. R2 receives the CDP advertisement, believes the information, and sets its holdtime for to 180 seconds.
3. R2 counts down from 180 seconds toward 120 seconds.
4. R1 sends next CDP advertisement 60 seconds after the first one.
5. R2 receives the CDP advertisement and resets its holdtime to 180.
6. The serial link fails.
7. R2’s holdtime eventually counts down to 0 and R2 discards its CDP information about R1.
The show cdp Commands
That List Information About Neighbors
The show cdp neighbors detail Command
The show cdp neighbors detail Command (Continued)
The show cdp entry Command
globally and, if so, on which interfaces it is enabled.
2. CDP is then disabled on interface S0/0, which is connected to R2, using the no cdp enable interface subcommand.
3. The show cdp interface command shows that CDP is enabled.
4. CDP is disabled globally using the no cdp run global command.
5. The show commands confirm that CDP is disabled globally and that the traffic counters are not displayed.
6. CDP is then enabled globally and re-enabled on interface S0/0.
7. The show cdp traffic command shows statistics, but the counters were not reset to 0 when CDP was globally disabled.
8. The clear cdp counters command is used to reset the counters.
(See comments on the next slide)
9. The show cdp traffic command’s counters now show low numbers, but they show only global counters, not per-interface counters.
10. To verify that CDP messages are being sent and received on each interface, the debug cdp packet command is used.
Although CDP does provide some convenient and useful
information about other devices,the telnet, ping, and
traceroute provide vital information about an internetwork:
routers and switches and issue commands on the remote devices, learning about the devices’ configuration and current operations.
delivered in an internetwork, and determine the route used by those packets.
Each tool focuses on one layer of the OSI model, while each
can be used to prove whether multiple layers are working.
through 3, because although IP and IP routing are Layer 3
functions, IP cannot deliver packets unless Layers 1 & 2 are functional.
Telnet Client/Server Operation
alternative to telnet. Beyond that, just by entering an IP address or hostname on the command line in EXEC mode—without either the telnet or connect command in front of it—IOS assumes that the user wants to telnet to that name or address.
exit and logout commands.
Although a Telnet connection to a router or switch can fail
for many reasons, three of the reasons are relatively common:
If command in EXEC mode is not recognized by IOS as a
valid command, IOS assumes you want to telnet to a host
of that name.
By default, here is what happens when a user simply
mistypes a command, something as simple as typing shw
interfaces instead of show interfaces:
1. IOS does not recognize the command (in this example, shw).
2. IOS tries to telnet to that name. The first step is to resolve the name (shw) into an IP address.
3. IOS broadcasts DNS resolution requests on all interfaces, looking for a DNS server to resolve the name.
4. Assuming no DNS servers hear the request, the user waits 30 to 40 seconds for IOS to finally time out its DNS request, during which time the user cannot enter any other commands!
To solve the problem in a lab, just add the no ip domain-
lookup global configuration command to the routers’
configurations, and IOS will no longer attempt to broadcast to
find a DNS, and the mistyped commands will fail immediately.
Suspending a Telnet connection means that the user does
not close or terminate the Telnet connection, but instead,
the Telnet connection is temporarily “set aside”.
By suspending a Telnet connection, the user can switch
back and forth between router command prompts very
quickly and easily.
Pay close attention to the command prompts.
Step 1 The user at R1 telnets into R2, logs in, and gets into enable mode.
Step 2 The user enters a command on R2, just to emphasize which router the user is using.
Step 3 The user suspends the Telnet connection, giving the user a command prompt back on R1.
Step 4 The user issues a command on R1, again to emphasize which router the user is using.
Step 5 The user resumes the suspended Telnet connection using the resume 1 command.
Step 6 The user issues a command on R2 again, just to emphasize which router the user is using.
By creating, suspending, and resuming multiple Telnet
connections, a user can easily switch between the CLIs of
IOS uses the following logic when there is at least one
Suspended Telnet connection:
Step 1 The user telnets from R1 to R2.
Step 2 The user suspends the Telnet connection, moving back to R1.
Step 3 The user telnets from R1 to R4.
Step 4 The user suspends the Telnet connection, moving back to R1 again.
Step 5 At R1, the user issues the show sessions command,which lists both suspended Telnet connections.
Step 6 The user resumes the Telnet connection to R4 by using the
resume command, without a session number.
Step 7 The user suspends the Telnet connection, moving back to R1
Step 8 The user resumes the Telnet connection to R2 by using the 1
command, which simply identifies the session number for the
Telnet connection to R2.
Step 9 The user suspends the Telnet connection, moving back to R1
Step 10 At the R1 command prompt, the user simply presses Enter,
resuming the last-suspended
Telnet connection (R2).
There are three methods to restrict the number of Telnet
connections into a router:
request messages (default five messages) to another host.
routed to the remote host, as well as the time for the echo packet to go to the remote host, and the reply to come back.
discards the packets.
The following occurs due to the traceroute command:
1. R1 sends three packets, source 172.16.4.251, destination 172.16.2.254, with TTL=1.
2. R2 receives the packets, decrements the TTL to 0, and discards the packets.
3. R2 also sends an ICMP TTL Exceeded message back to 172.16.4.251 (R1) for each discarded packet.
4. The traceroute command on R1, upon seeing that all the ICMP TTL Exceeded messages came from the same IP address (172.16.4.252), now knows that 2188.8.131.52 is the first router in the route to reach the destination. So, the traceroute command lists 172.16.4.252 as the first router in the route.