You are on page 1of 41

Cabrillo College

Ch. 4 – Router Components – Part II


CCNA Semester 2
Rick Graziani, Instructor
Feb. 14, 2002
CDP–Cisco Discovery Protocol

 Cisco Discovery Protocol is a proprietary protocol that runs on


top of the data link layer.
– Layer-3 independent
– Allows Cisco devices to exchange configuration information
with each other without having Layer-3 connectivity
CDP–Cisco Discovery Protocol

 The primary use of CDP is to discover platforms and protocols on


your neighboring devices (adjacent neighbors only).
 Notice that the lowest router in the figure is not directly connected to
the administrator's console router.
 To obtain CDP information about this device, the administrator
would need to Telnet to a router that is directly connected to this
target.
show cdp interface

 Displays layer 2 encapsulation and status (“up” and “up”).


 Displays CDP information for all CDP enabled interfaces.
– Frequency of CDP packets – default 60 seconds
– Holdtime – default 180 seconds – If a CDP has not received a CDP
packet in 180 seconds, CDP will no longer display the information
for that neighbor. (no affect on routing table).
show cdp entry router-name

Remote router’s interface

This router’s
interface

 show cdp entry * - shows all CDP neighbors


Shows:
Remote IP Address Model Capabilities: Router, switch, etc.
This router’s interface Remote router’s interface Holdtime
IOS version
show cdp neighbors

E0 not shown

This router’s interface Remote router’s interface

 Nice listing.
show cdp neighbors detail

Remote router’s interface


This router’s
interface

Shows:
Remote IP Address Model Capabilities: Router, switch, etc.
This router’s interface Remote router’s interface Holdtime
IOS version
Testing Process Overview
Layer 7 to Layer 7 Testing
Telnet From Router to Router
RouterA>telnet 10.1.1.1
Trying 10.1.1.1 ... Open

Password required, but none set

[Connection to 10.1.1.1 closed by foreign host]


RouterA>
RouterB(config)#line vty 0 4
Configure vty password RouterB(config-line)#login
on RouterB RouterB(config-line)#password cisco

RouterA>telnet 10.1.1.1
Trying 10.1.1.1 ... Open

User Access Verification

Password:cisco Telnet works! Enter vty password


RouterB>
RouterB>exit Exit closes (ends) telnet session

[Connection to 10.1.1.1 closed by foreign host]


RouterA>

 You must have the vty password set on the remote routers.
 We will always use cisco as our vty passwords!
Telnet From Router to Router
RouterA>telnet 10.1.1.1
Trying 10.1.1.1 ... Open

User Access Verification

Password:cisco
RouterB>ena Cannot enter privilege mode because there is no privilege
% No password set password (enable secret). Can only enter this mode from
RouterB>exit the console until the password is created.

Configure vty password


on RouterB RouterB(config)#enable secret class

RouterA>telnet 10.1.1.1
Trying 10.1.1.1 ... Open

User Access Verification

Password:cisco
RouterB>ena
Password:class
RouterB#exit
[Connection to 10.1.1.1 closed by foreign host]
RouterA>

 If there is no privilege password on the remote router, you cannot enter


privilege mode!
Telnet Operations
Telnet From Router to Router
RouterA>connect
Host: 10.1.1.1
Or the “telnet” command
Trying 10.1.1.1 ... Open

User Access Verification

Password:cisco
RouterB>
RouterB> <control-shift-6, x>

RouterA>show sessions
Conn Host Address Byte Idle Conn Name
* 1 10.1.1.1 10.1.1.1 0 0 10.1.1.1

RouterA> <enter>
[Resuming connection 1 to 10.1.1.1 ... ]

RouterB>exit

[Connection to 10.1.1.1 closed by foreign host]


RouterA>show sessions
% No connections open
RouterA>

 If there is no privilege password on the remote router, you cannot enter


privilege mode!
Telnet From Router to Router
RouterA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RouterA(config)#ip host RouterA 10.1.1.1 Does not have to be the router-name
RouterA(config)#exit
but it is generally a good idea.
RouterA#telnet routera Not case sensitive.
Trying RouterA (10.1.1.1)... Open

User Access Verification

Password:
RouterB>

 This is where the ip host commands can be helpful.


Testing at Layer 3
Is B Reachable? Yes, I am here!

 If you can’t ping, you won’t be able to telnet or traceroute to the router (or
other device).
 We will cover ping in much more detail with the presentation: ICMP –
Understanding ping and trace.
Testing with the trace Command

 If you can’t ping, you won’t be able to telnet or traceroute to the router (or
other device).
 We will cover ping in much more detail with the presentation: ICMP –
Understanding ping and trace.
Note: Trace Route

 The trace command is the ideal tool for finding where data is being sent in
your network.
 The trace command is similar to the ping command, except that instead of
testing end-to-end connectivity, trace tests each step along the way.
– Along the way there, however the packets may take a different route on
the way back, which is very common with Internet packets.
 This operation can be performed at either the user or privileged EXEC
levels.
 The trace command takes advantage of the error messages generated by
routers when a packet exceeds its Time To Live (TTL) value.
 The trace command sends several packets and displays the round-trip time
for each.
 The benefit of the trace command is that it tells which router in the path
was the last one to be reached.
 This is called fault isolation.
Key Troubleshooting Command

 The router offers some powerful tools at this point in the search.
 You can actually look at the routing table - the directions that the router
uses to determine how it will direct traffic across the network.
 The routing table focuses on the network layer.
 Use the show ip route command to determine whether a routing table
entry exists for the target network and what the next-hop is.
 More on routing tables in Ch. 11 Routing and Ch. 12 Routing Protocols.
Testing at Layer 1 and 2

The interface has two pieces, physical (hardware) and logical


(software):
 The hardware -- such as cables, connectors, and interfaces --
must make the actual connection between the devices.
 The software is the messages -- such as keepalive messages,
control information, and user information -- that are passed
between adjacent devices. This information is data being passed
between two connected router interfaces.
Testing at Layer 1 and 2

When you test the physical and data link, you ask these questions:
 Is there a Carrier Detect signal?
 Is the physical link between devices good?
 Are the keepalive messages being received?
 Can data packets be sent across the physical link?
Key Troubleshooting Command

 The line status in this example is triggered by a Carrier Detect signal, and
refers to the physical layer status.
 However, the line protocol, triggered by keepalive frames, refers to the
data link framing.
 Must be “up” and “up” to be operational.
 A point-to-point serial link will not show “up” and “up” unless both sides are
properly configured – I.e. It might not be this end by the other side of the
serial link which is causing the problem.
Interface Statistics
Interface Statistics
RouterA#show inter serial 0
Serial0 is up, line protocol is down
Hardware is HD64570
Internet address is 10.1.1.2/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:08, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair

<text omitted>

DCD=up DSR=up DTR=up RTS=up CTS=up


RouterA#

 What might be the cause of this “line protocol is down”?


 The interface itself is up, as are the output leads RTS, DSR and
DTR (Request To Send, Data Set Ready, and Data Terminal
Ready: See data communications books or )
 The input leads DCD and CTS are also up (Data Carrier Detect and
Clear To Send).
 All five of these indicates that the DSU (part of the CSU/DSU) is
visible to the router.
 Line protocol is down, so HDLC keepalives are not being received
from the other end of the serial link.
 Next step would be to check the other end of the serial link.
Lab Examples:
DCE cable, router uses
No CSU/DSU, clock rate command
instead one
end of the
cable is DCE
(router uses
clock rate
command) and
DTE cable, no clock
the other end rate command
is DTE.
Lab Examples
 Here are some examples for our lab:
 NOTE: We are not using a CSU/DSU so these examples may
only pertinent to our lab setting using only a clock rate setting on
the router with the DCE cable.
 Note: The idea here is not to memorize these situations, but
know how to troubleshoot.
Interface Statistics
RouterB#show inter serial 0
Serial0 is down, line protocol is down
Hardware is HD64570
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:49, output 00:00:49, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair

<text omitted>

DCD=up DSR=up DTR=down RTS=down CTS=up


RouterB#

Example #1 – Line status is down, line protocol is down


 What might be the cause?
 Notice DTR, and RTS are down, but DCD, DSR and CTS are up.
Possible Cause:
 Remote router’s serial link is administratively down (shutdown) or
the cable is not connected.
Interface Statistics
RouterB#show inter serial 0
Serial0 is down, line protocol is down
Hardware is HD64570
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:01:51, output 00:01:51, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair

<text omitted>

DCD=down DSR=down DTR=down RTS=down CTS=down


RouterB#

Example #2 – Line status is down, line protocol is down


 What might be the cause?
 Notice DCD, DSR, DTR, RTS, CTS are all down.
Possible Cause:
 Check the cable on this router’s serial interface, it may be
disconnected.
Interface Statistics
RouterB#show inter serial 0
Serial0 is up, line protocol is down
Hardware is HD64570
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:19, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair

<text omitted>

DCD=up DSR=up DTR=up RTS=up CTS=up


RouterB#

Example #3 – Line status is up, line protocol is down


 What might be the cause?
 Notice DCD, DSR, DTR, RTS, CTS are all up.
Possible Cause:
 Different layer 2 encapsulations on both routers. One router may
be using HDLC where the other one is using PPP.
 Another problem may be that the clock rate was not set on the
router with the DCE cable.
RouterB#show inter serial 0
Serial0 is administratively down, line protocol is down Interface
Hardware is HD64570
Internet address is 10.1.1.1/24
Statistics
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:22, output 00:00:16, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair

<text omitted>

DCD=down DSR=down DTR=up RTS=up CTS=down


RouterB#

Example #4 – Line status is administratively down, line protocol is


down
 What might be the cause?
 Notice DCD, DSR and CTS are down, but DTR and RTS are up.
Possible Cause:
 This router’s serial interface is administratively down (shutdown).
Clearing the Interface Stats
RouterB#show inter serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:09, output 00:00:09, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
9285 packets input, 540033 bytes, 0 no buffer
Received 8592 broadcasts, 0 runts, 0 giants, 0 throttles
5 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored, 5 abort
9216 packets output, 536779 bytes, 0 underruns
0 output errors, 0 collisions, 84 interface resets
0 output buffer failures, 0 output buffers swapped out
148 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
RouterB#clear counters
Clear "show interface" counters on all interfaces [confirm]
21:26:05: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
RouterB#

The statistics for an interface can be cleared with the command:

clear counters
Clearing the Interface Stats
RouterB#show inter serial 0
Serial0 is up, line protocol is up
Hardware is HD64570
Internet address is 10.1.1.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:09, output 00:00:09, output hang never
Last clearing of "show interface" counters 00:00:12
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2 packets input, 44 bytes, 0 no buffer
Received 2 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
2 packets output, 44 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
RouterB#

Counters cleared in blue


Key Troubleshooting Command

 Only use debug while troubleshooting


– Processor-intensive
– May severely impact performance
 Debug output:
– Displayed at console only by default
– Can be displayed via telnet with command:
terminal monitor
Debug
RouterB#debug ?
aaa AAA Authentication, Authorization and Accounting
access-expression Boolean access expression
all Enable all debugging
apple Appletalk information
arap Appletalk Remote Access
arp IP ARP and HP Probe transactions
async Async interface information
<text omitted>

RouterB#debug ip rip
RIP protocol debugging is on
<debug output>
RouterB#undebug ip rip Turning off the specific debug.
RIP protocol debugging is off
RouterB#undebug all
OR Turning all debugging off, easier to use.
RouterB#un all
All possible debugging has been turned off
RouterB#

 Must be in privilege mode to use debug.


 We will be using debug throughout CCNA and CCNP classes.
 Not only excellent for troubleshooting but for learning and seeing what
is happening on the router.
 Let’s us see the routing protocol packets and other neat stuff!
 Don’t forget to turn debugging off when finished.
Key Troubleshooting Command
logging buffered Command
Logging Messages to an Internal Buffer
 The default logging device is the console; all messages are displayed
on the console unless otherwise specified.
 To log messages to an internal buffer, use the logging buffered router
configuration command.
 The full syntax of this command follows:
Router(config)#logging buffered
 The logging buffered command copies log messages to an internal
buffer instead of writing them to the console. The buffer is circular in
nature, so newer messages overwrite older messages.
 To display the messages that are logged in the buffer, use the
privileged EXEC command show logging. The first message displayed
is the oldest message in the buffer. You can specify the size of the
buffer as well as the severity level of the messages to be logged.
 Tip: Make sure enough memory is available in the box before entering
the buffer size. Use the IOS command show proc mem to see
memory available.
 The no logging buffered command cancels the use of the buffer and
writes messages to the console (the default).
Router(config)# no logging buffered
 There is more to these commands, see:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/dbook/
dintro.htm
terminal monitor Command
Displaying debug messages when connected via telnet

 If you are connected via via telnet, type the command:

Router(config)# terminal monitor

 This will send debug and error messages to your telnet session.
 This will send these messages to all telnet sessions, anyone who is
logged into the router via telnet.
 Also verify that the no logging on command has not been used.

 To redirect all messages back to the console use:

Router(config)# no terminal monitor

.
Logging <ip address> Command
Logging Messages to a Syslog Server

 To log messages to the syslog server host, use the logging router
configuration command.
 The full syntax of this command follows:
Router(config)#logging <ip-address>
Router(config)#no logging <ip-address>

 The logging command identifies a syslog server host to receive


logging messages.
 The <ip-address> argument is the IP address of the host.
 By issuing this command more than once, you build a list of syslog
servers that receive logging messages.
 This can be very useful for troubleshooting problems and for
investigating security issues in your network – ie track what was
happening and when.
 The no logging command deletes the syslog server with the specified
address from the list of syslogs.

.
Syslog software

 Syslog software comes with many operating systems, like unix


or linux, but can also be downloaded.
 Kiwi Enterprises provides downloadable syslog software for
Microsoft operating systems.
 http://www.kiwisyslog.com/index.htm
logging synchronous Command
Making it easier to view debug and error messages

 When debugs are running, you don't usually see the router prompt,
especially when the debug is intensive.
 However, in most cases, you can use the no debug all or undebug all
commands to stop the debugs.
 You can also use the logging synchronous command to ensure that
the router prompt is returned in the midst of the debug output.
 This will make debugs much easier to read and also make it easier for
you to type commands when debugs are in process.
 Otherwise, the router prompt and your command input will be mixed in
with the debug output.
 Your commands will still work, but it will make it harder to type in as the
individual characters will be interrupted and mixed in with the output.
 A sample configuration on the console port is provided:

Router(config)#line con 0
Router(config-line)#logging synchronous
Router(config-line)#
Example:
Router# debug ip packet
IP: s=172.16.13.44 (Fddi0), d=10.125.254.1 (Serial2), g=172.16.16.2, forward
IP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, forward
RouIP: s=172.16.1.6 (Ethernet4), d=255. ter>255.255.255, rcvd 2
IP: s=172.16.1.55 (Ethernet4), d=172.16.2.42 (Fddi0), g=172.16.13.6, forward
IP: s=172.16.89.33 (Ethernet2), ud=10.130.2.156n (Serial2), g=172.16.16.2, forward
IP: des=172.16.1.27 (Ethernet4), d=172.16.43.126 (Fddi1), g=172.16.23.5, forward
IP: s=172.16.1.27 (Ethernet4), d=172.16.43.126 (Fddi0), g=172.16.13.6, forward
IP: s=172.16.20.32 (Ethernet2), d=255.255.255.255, rcvd 2
IP: s=172.16.1.57 (Ethebugrnet4), d=10.36.125.2 (Serial2), g=172.16.16.2, access
denied
IP: s=172.16.13.44 (Fddi0), d=10.125.254.1 (Serial2), g=172.16.16.2, forward
IallP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, forward
IP: s=172.16.1.6 (Ethernet4), d=255.255.255.255, rcvd 2
Router#

 We are entering the command “undebug all”


 The debug output continuously interrupt and mixes in with our
command-line input.
 This does not affect our input, but makes it more difficult to do.
Example:
Router(config)#line con 0
Router(config-line)#logging synchronous
Router(config-line)#end
Router# debug ip packet
IP: s=172.16.13.44 (Fddi0), d=10.125.254.1 (Serial2), g=172.16.16.2, forward
IP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, forward
Router>
IP: s=172.16.1.6 (Ethernet4), d=255. 255.255.255, rcvd 2
IP: s=172.16.1.55 (Ethernet4), d=172.16.2.42 (Fddi0), g=172.16.13.6, forward
IP: s=172.16.89.33 (Ethernet2), d=10.130.2.156 (Serial2), g=172.16.16.2, forward
Router> und
IP: s=172.16.1.27 (Ethernet4), d=172.16.43.126 (Fddi1), g=172.16.23.5, forward
IP: s=172.16.1.27 (Ethernet4), d=172.16.43.126 (Fddi0), g=172.16.13.6, forward
Router> undebug
IP: s=172.16.20.32 (Ethernet2), d=255.255.255.255, rcvd 2
IP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, access denied
Router> undebug all
IP: s=172.16.13.44 (Fddi0), d=10.125.254.1 (Serial2), g=172.16.16.2, forward
IP: s=172.16.1.57 (Ethernet4), d=10.36.125.2 (Serial2), g=172.16.16.2, forward
IP: s=172.16.1.6 (Ethernet4), d=255.255.255.255, rcvd 2
Router#

 With logging synchronous.


 I suggest having this command as part of every standard router
config.
Cabrillo College

Ch. 4 – Router Components – Part II


CCNA Semester 2
Rick Graziani, Instructor

You might also like