- [Instructor] Let's look at troubleshooting
some device management methods starting with the console.
Using the console is the initial method that you'll use
with a Cisco router or switch
in order to gain access
and begin your configuration.
This requires physical access to the device.
So you need to be able to connect with a physical cable.
The first place to start troubleshooting
is going to be the cable itself.
Here you can see a picture of the standard console cable
that comes with many Cisco devices,
and that consists of a DB-9
female serial connector on one end
and an RJ45 connector on the other.
If you have a newer device,
rather than an RJ45 connector,
you may have the option to use a mini USB connector
as we see here.
The cable that you use
is going to depend on which device you have.
So that's the first consideration.
You'll also want to make sure
that you have the correct drivers installed
in order to use this cable,
which should be documented
with the cable that you've purchased.
Probably far more common is the serial connection.
And that's going to require you to have
some sort of USB to serial adapter
such as the one we see here.
Now, I use these myself
and they do have the necessary drivers included
in order to get those communicating properly.
Once you're sure that the cable or adapter
has any necessary drivers
and that you're able to see the hardware
connected to your PC,
the next step is to check your terminal program settings.
One of the most popular clients for this use is PuTTY,
but there are many similar options out there
for different operating systems,
or you can certainly use built-in terminal programs as well.
The first thing to check out within the terminal program,
you can see that I have PuTTY open here,
is the COM port setting.
If we go to the very bottom with PuTTY open,
you see that bottom menu option is serial.
And you can see this presents us with the ability
to choose a specific COM port.
On my Windows machine,
I've also opened my Device Manager here on the right.
And if we look through that list,
under there we see that we do have a list
of available COM ports.
In my case, I only have a single COM port at the moment,
and that is COM port number seven.
You can see that is my prolific
USB to serial COM port adapter.
If we right click that and choose Properties,
and then we go under Port Settings,
here we can see more specific settings
that we need to check out.
And these are very important to get right.
Cisco devices use the default values that we see here.
They use 9,600 baud or bits per second,
they have eight data bits,
they use a parity setting of none,
and they use one stop bit.
So this definitely needs to be configured correctly
on the hardware itself.
Also, if we look back in the PuTTY window here on the left,
we also have settings in here
that need to be configured correctly.
You'll want to make sure that this is likewise configured
with the correct COM port number.
If I close out of this in my Windows Device Manager,
again, you can see that I'm using COM7.
So we want to make sure in PuTTY
that we do have the correct COM port selected in here.
And again, all of those Cisco defaults
are likewise available in PuTTY as well.
So be sure those are configured
to match the Cisco default values.
Next up we want to consider,
is there a configure line password
for console authentication?
If this is a brand new device,
some of those have no authentication in place by default.
But often in a lot of new equipment that we're seeing,
that is set to the default username and password of Cisco
in all lower case.
So if you're trying to connect
to a device that's been around a while,
you'll need to know some valid credentials for this.
With existing equipment,
if you have a line password being used,
the login command
needs to be configured for the console as well.
It's also possible with existing equipment
that you have an external AAA database being used
such as RADIUS or TACACS+.
And if that's the case,
you'll obviously need to have
some valid credentials for that.
And also have a method list defined properly
for the console.
Remember we talked about these
login methods and method lists
in the AAA troubleshooting module.
So go back and check that out if you need a refresher.
The most common way that I access devices
is by the VTY lines,
which are virtual terminal lines
that allow for Telnet and SSH to be used for remote access.
By the way, it's a best practice
to never use Telnet in a production environment.
And that's because it sends information out in plain text.
So always use SSH when possible.
If you can't gain VTY line access,
then you'll want to connect via the console cable,
you'll want to connect
physically to the device in other words,
and you'll want to start troubleshooting some common issues.
So let's discuss what some of those could be.
A few obvious places to check first
would be am I using the correct IP address
or is the IP address reachable?
And of course we can check that
with a simple ping to the remote device.
Next, we want to check to make sure
that the correct transport protocols are defined.
We can do that with a show command,
so let's say show line VTY
and we'll follow that with a line number.
In my case, I'm going to say VTY line zero.
I'm going to hit Enter.
And that's going to give us a list of our allowed inputs.
We can see that in my case, those are Telnet and SSH.
If say show run pipe to section VTY,
we'll be able to see the specific command
here that I've entered.
And that is transport input Telnet SSH.
So in my case,
I'm allowing both Telnet and SSH as input methods.
So let's say you don't see the SSH on there,
let's say the only thing you see is transport input Telnet.
You would see the same thing up here.
You would see allowed input transports are Telnet.
If you see that and you're trying to connect via SSH,
that obviously isn't going to work.
So you want to make sure that your input method
is properly defined.
We also would want to check our login method.
We can see in this output that mine is set to login local.
And that's going to allow me
to use a locally configured user to access the VTY lines.
So if you're able to communicate,
but maybe you're getting an authentication issue,
you want to check and make sure
what your login method is set to
or check in your login method list.
Now, if you see the error message
password required but none set,
if you see that on your remote device
when you're trying to connect,
that means that there is no password configured.
By default on the lines
when the login command is enabled,
it will still require a password to be configured.
So if you receive that message,
the password required but none set message,
that means you need to configure a password.
If you're using login local,
then you will be prompted for a username and password
from the local database.
So if all of that looks good,
if you have a password configured,
if your lines are configured for login local,
then you can ping the devices as well.
If all that's working,
I would turn to start looking at access control issues.
In other words,
is there an access control list
blocking me from accessing this device?
So you would start looking at your VTY lines.
You can see that in my output of my show run,
it tells me access-class 1 in.
So that means that I have access list number one applied
in the inbound direction to my VTY lines.
Based on this, I would say show IP access-lists 1
to take a look at that.
And you can see that I have a single permit statement here,
permitting an SSH host.
And so that's a place you would want to look.
If you have an ACL attached to your VTY lines,
make sure that it's not blocking your hosts in any way.
That would include the IP address
and also protocols and port numbers.
In other words, is there a line in your ACL
that's blocking port 22 for example,
which is what SSH uses.
One final thing to be aware of
is that there is a finite number of VTY lines.
In my case, I have lines zero through four.
So if I run the command show users,
we can see if my VTY lines are in use, or if they're open.
Now, in my case, I've personally never ran into this issue,
but it is certainly a possibility
if you have a large number of users or administrators
that are accessing a device.
This is going to show you any active console
or VTY line connections that you have.
Of course here we only see the single line
that's in use on my device, which is my console.
I don't have any VTY line connections
currently taking place.
If you need to manually clear those,
if those do appear to all be in use,
you can run the clear line command,
and you would follow that by the line number
such as VTY zero for example.
So that's a look at troubleshooting console
and VTY line connections on a Cisco device.