Lesson 2 - Navigating in Cisco IOS

Previous | Home | Next

 LESSON 2 - LAB

Cisco IOS Navigation Part 1

Cisco Navigation Part 2

 

Once, you have connected to your terminal to Cisco switch or router console port power it up and observe startup messages on your screen.

In case your network device does not have startup-configuration saved in NVRAM/Flash memory, you will be greeted with 'Would you like to enter the initial configuration dialog [yes/no]:' message as depicted below:

Pic. 1 - System Configuration Dialog

You can safely cancel this request as its capability to configure the device is not very impressive. Just enter: no and hit enter twice. Wait, as it takes few seconds for the device to give you prompt back.

What follows is bunch of messages sent to the screen and after hitting the Enter key few times you get something like this (here is the router, but a switch would introduce itself as ... Switch> ):

Router>

What you are looking at right now is prompt of IOS operating system. Terminal and commands you type are the primary means of 'talking' (configuring/monitoring) your network node (switch/router).

IOS Modes (contexts)

From the very beginning try to be attentive to details you see on the screen.

The prompt of the device tells you which 'context' you are in.

The prompt that presents '>' character is called 'user exec mode' or 'privilege level 1 mode'. You can't configure much in this mode of operation. It is designed as a 'monitoring' mode not a 'configuration' one. You should also know that even monitoring capability in user exec mode is limited. For instance, you can't see the running configuration of the device. However, it is useful for less experienced users who want to perform basic diagnostics of the device without risking of accidental re-configuring the device and causing a problem.

Make sure that if you are learning networking you DO NOT USE PRODUCTION equipment. You should have some lab gear to experiment on.

Assuming you are using lab equipment let's roll up our sleeves and begin to learn about different IOS contexts.

Type in the following command:

Router>enable

Router#

The prompt changes to '#' which is called 'privileged exec mode', 'enabled mode' or sometimes 'privilege level 15 mode'. I would like to draw your attention to two things here. Both modes of operation (or contexts, if you like) have two things in common:

1. They are used primarily to monitor the device (you will be using 'show' and 'debug' commands in those modes).
2. Using any IOS command and pressing enter will execute the command as long as its syntax is correct. In case you make a typo or command is not available in the context you are in, an error shows up on the screen and the command will not be executed.

NOTICE!
IOS takes a single command per line that must be accepted with Enter.

Now, coming back to those two modes (contexts) here's a somewhat concise explanation of what they are used for and how to use them:

1. User Exec Mode - is limited in terms of what information will be available.
2. Enabled Exec Mode - gives the operator ALL information (like root or Administrator account on a computer).

Question Mark

IOS commands (one per line) can be a single keyword or a keyword followed by one or more arguments. You should learn how to ask IOS for help as there will be a lot of commands to remember and a lot of arguments those commands can take.

Question mark '?' is your best friend in learning commands. It is a built-in help that is a 'context-sensitive help'. This means that depending on which context you use, typing a question mark (?) will display only keywords (commands) available in this particular context.

Configurations

In order to configure things in Cisco IOS (except for some minor changes), you must enter the 'global configuration mode' first which is characterized by the following prompt:

Router(config)#

This context can be accessed by typing the following command in the 'privileged exec mode':

Router#configure terminal

Whatever you configure device in 'global configuration mode' or 'config mode' it is going to be applied to the device as a whole unit (e.g. hostname, default gateway on a switch etc.). Don't worry about details right now. I will explain them in due time.

If you want to enter the context of the interface to add some parameters to it such as ip address, speed, duplex, description etc. , you must enter that interface from the global configuration mode like the one below:

Router(config)#interface fastethernet0/1

REMEMBER!
Watch your prompt to know in which context  your cursor is. If a particular command does not work it is either a typo, or perhaps you are in the wrong mode of operation (wrong context).

If you do not know what interfaces your device has, type the following command in the enabled mode:

Router#show ip interface brief

Here's first 'gotcha'. All 'show' commands can only by typed in either user-exec mode or privileged-exec mode. If you are in the 'config' mode you must precede show command with the 'do' keyword as shown below:

Router(config)#do show ip interface brief

Now look at the whole navigation I just showed here:

Router>enable
Router#configure terminal
Router(config)#interface fastethernet0/1
Router(config-if)#do show ip interface brief

1. Entered the interface type (here: Fast Ethernet).
2. Referenced the module number (here: 0)
3. Referenced the port number in the module 0 (here: 1)

Please, note that routers count ports starting from 0, switches start counting ports from 1.

You'll learn other contexts as we go through numerous labs.

Abbreviations

You don't have to type in the full words of the commands and certain attributes that follow the commands. For instance, instead of typing:

Router#configure terminal

Router(config)#

You can type:

Router#conf t

Router(config)#

As long as the abbreviation uniquely describes which command you want to use, the system has no problem accepting it.

Shortcuts And Keystrokes

When you type enough of the characters that uniquely identify the command in a given context you can use 'tab' key and the system is going to complete the command on the screen (just like it happens in Linux terminal).

I often use the following keystrokes while editing the commands:

• CTRL-z - takes the cursor back to the 'enabled exec' mode from any other context (Router#)
• CTRL-a - takes the cursor to the beginning of the line
• CTRL-e - takes the cursor to the end of the line
• CTRL-k - erases everything to the right of the cursor
• CTRL-u - erases everything to the left of the cursor
• Up Arrow or CTRL-P - displays previous command from the history buffer
• Down Arrow or CTRL-N - displays next command from the history buffer

System keeps the record of up to ten or twenty (default) commands you typed in. That depends on the system you use. You can increase/decrease the history buffer up to 256 commands.

If you want to check the history buffer size, type in:

Router#show terminal | include history

I will describe this pipe character '|' and 'include' keyword in our practice lab later.

Changing the buffer size can be accomplished with the following command in the 'enabled mode'

Router#terminal history size 256

There is another way of doing it, that you will practice in our lab section.

The above command will increase the size of the history buffer to 256 commands.

If you want to see the buffer (which commands were typed) use this command:

Router#show history

If you understand the content of this lesson, let's practice all you have read (and a bit more) in our first lab.

Previous | Home | Next

Lab 3-3: Using ACLs to filter IP based traffic

Previous Lab | Exercises | Next Lab

Lab pre-requisites:

• Packet Filtering Using Standard ACL.
• Standard ACL Examples.
• Packet Filtering with Extended ACL.
• Extended ACL Examples.

Lab 2-1 Packet Tracer Topology Download.

Topology Diagram

This is continuation of the previous lab related to basic security.
  
Task 1: Configuring an ACL (Access Control List).


In this exercise assumptions have been made:

PC1 (IP Address: 10.1.1.100/24) is allowed to to access Server (172.16.1.100) using any protocol.

PC2 (IP Address: 10.1.1.101/24) CANNOT use telnet Server. All other traffic is allowed.

There are few ways of constructing ACL. Here's one of them:

Step 1
Configure ACL statements:

Branch#conf t

Enter configuration commands, one per line. End with CNTL/Z.

Branch(config)#access-list 100 deny tcp host 10.1.1.101 host 172.16.1.100 eq telnet

Branch(config)#access-list 100 permit ip any any

Branch(config)#

Step 2

Apply the ACL on Fas0/0 interface blocking incoming packets.

Branch(config)#int f0/0

Branch(config-if)#ip access-group 100 in

Branch(config-if)#

Branch#show access-list 100

Extended IP access list 100

deny tcp host 10.1.1.101 host 172.16.1.100 eq telnet

permit ip any any

Branch#

Notice
Packet Tracer does not provide us with index number next the ACL statements (on real equipment they are present and can be used to remove statements using 'named' acl syntax. 

Notice
Packet Tracer does not have 'show ip int f0/0' command implemented properly. This command normally displays whether incoming and/or outgoing ACL is applied on the interface.
  
Notice
Packet Tracer is somewhat limited here. We cannot enable http server (ip http server) on HQ router in order to properly test the ACL.


Also 'named' ACLs are not working in the version of Packet Tracer I am using. This does not allow me to show you how to re-sequence statements, remove statements, and squeeze statements between other ones.

Verification:

Notice
I have tested ACL using PC2 and telnet is NOT being blocked as expected. This proves that version of Packet Tracer I use is NOT working properly.

 

Previous Lab | Exercises | Next Lab

Lab 3-1 Improving Device Security

Previous Lab | Exercises | Next Lab

Lab pre-requisites:

• Packet Filtering with Standard ACL.

Lab 2-1 Packet Tracer Topology Download.

Topology Diagram

In this lab there are four tasks that allow apply a basic security on IOS based switches and routers.
 
Task 1: Device password protection.
Task 2: Remote access using Telnet and SSH.
Task 3: Limiting remote access based on source IP Addresses.
Task 4: Creating a login banner page.

Let's rock and roll!

Task 1: Device password protection.

As an example let's protect access to SW1 starting at protecting the console which by default allows access without any password.

Notice
Switches and routers allow access to the console without prompting for the password. There is 'no login' keyword applied on the by default which means that a user is not prompted for the password even if one is configured. In order to protect the console, you must apply both password and 'login' keyword in order to prompt the user for the password.

SW1 Console Password (use cisco as password):


SW1>enable

SW1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW1(config)#line con 0

SW1(config-line)#password cisco

SW1(config-line)#login

SW1(config-line)#

In order to verify this configuration exit session by first typing end and then exit. You will be prompted for the password while creating new console session.

As of now, we only protected console access. We must also protect the privileged exec mode (enabled mode). Let's use password sanfran for a change. The command should be applied in the global configuration mode (if you are still in the console prompt, type in exit to go back to global config mode).

SW1(config)#enable password sanfran

SW1(config)#

Now, if you try to login to enabled mode the system will ask you for password sanfran to grant you access.

The problem is that all the passwords are now showing in clear text format. Check this out:

In order to protect all the existing passwords and the ones you will add in the future, we can encrypt them using Type-7 algorithm known as 'over-shoulder' encryption.

Let's turn on the service now, using global configuraition command as shown below:

SW1(config)#service password-encryption

SW1(config)#

All the passwords are not showing as clear text any more. However, you must still be careful not to disclose those encrypted strings as they can be easily broken on the net. As an example, copy the string below that my system used for sanfran:

08324D400F0B0419

Open the web page below and paste the string into Type-7 box and click 'Crack Password'. See for yourself.

Cisco Password Cracker

However, this protection is making difficult for a person to guess our password while looking at our screen when we display running-config.

It is much smarter to protect our enabled mode, using a properly encrypted password (either MD5 or SHA-256 will be used dependent of the platform). Let's also use password cisco to do it.

SW1(config)#enable secret cisco

SW1(config)#

Now, let's see what encryption Packet Tracer applied:

Since we have both: enable password (sanfran) and enable secret applied, the question is which password is the system going to use upon our attempt to enter 'enabled mode'? The answer is, the password that is more secure (secret). The only problem is that using secret method we can only protect enabled mode but not console or vty lines (used for remote access). We will handle this as our last thing in this lab.

Lastly, in this task let's allow remote access using Telnet. Here's the basic configuration (password cisco again, although on the production equipment each mode such as console, vty, enabled, should have different passwords).

Let's see if we try to access switch (vty lines) using telnet, what happens when login keyword is applied but there is no password used as shown below:

!

line vty 0 4

 login

line vty 5 15

 login

!

Notice

At the moment, my PC1 has IP Address: 10.1.1.100/24.

SW1 has VLAN1 interface configured with IP Address: 10.1.1.11/24

My Telnet session from PC1 results in the following:

Notice

On a real equipment we receive the message:

password required but none set

Task 2: Remote access using Telnet and SSH. 

If we want basic connectivity, assigning password to the first set of vty lines (0-4) can allow up to 5 simultaneous Telnet connections (if more is required apply password on vty lines 5 15 etc.)

SW1(config)#line vty 0 4

SW1(config-line)#password cisco

SW1(config-line)#

Now, Telnet works!

Notice
When you choose password for the production equipment, make sure that they are long (at least 8 characters) and not dictionary keywords. Use upper and lower case with special characters (such as %, ^, & etc.).

However, from security perspective, Telnet connections are not recommended as everything we type (that includes the password) are sent in clear text format. If intercepted, we're in trouble. 

SSH connections are highly recommended. Let's allow SSH support for our remote connections to SW1. These are necessary steps:

Notice
In real network it is recommended to have a centralized login access solution (using AAA server). Here, only local protection is used.

Step 1
Create username and password on the local device (user: ccna, password: cisco)


SW1(config)#username ccna secret cisco

SW1(config)#

Notice
If you want the user account (here ccna) to have access to privileged mode automatically upon connection to vty lines (skipping 'user exec mode'), you can use this instead:

SW1(config)#username ccna privilege 15 secret cisco

SW1(config)#

Step 2
Configure domain name (here cisco.com). 
Without domain name RSA public/private keys cannot be generated (command is rejected)

SW1(config)#ip domain name cisco.com

SW1(config)#

 
Step 3
Generate Public/Private key pair used for encryption/decryption of our transmissions while remotely accessed using SSH. Apply key 1024 bit when asked for modulus.

SW1(config)#crypto key generate rsa

The name for the keys will be: SW1.cisco.com

Choose the size of the key modulus in the range of 360 to 2048 for your

General Purpose Keys. Choosing a key modulus greater than 512 may take

a few minutes.

How many bits in the modulus [512]: 1024

% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]

SW1(config)#

Step 4

Change SSH session version to allow only SSHv2 connection (default 1.99 allows both SSHv1 and SSv2).

Default:

SW1(config)#ip ssh version 2

SW1(config)#

After the change:

Step 5

Allow SSH acces.

SW1(config)#line vty 0 4

SW1(config-line)#transport input ssh

SW1(config-line)#login local

SW1(config-line)#

Notice
The command: transport input ssh, only allows ssh. You can add telnet as well but in my opinion that defeats the purpose of this lab.

Also, the command: login local, allows system to use locally defined user (ccna) to log on.

You can verify this configuration by ssh-ing to itself (notice: -l for login not number 1 below):

SW1#

SW1#ssh -l ccna 10.1.1.11

Exit upon verification

Task 3: Limiting remote access based on source IP Addresses.


As an example let us allow PC1 (IP Address 10.1.1.100) to access SW1 using SSH but no other source IP address.

SW1(config)#access-list 5 permit 10.1.1.100

SW1(config)#line vty 0 4

SW1(config-line)#access-class 5 in

SW1(config-line)#

Notice
The last 'implicit' rule says deny any. That means that no other source IP address can get access to vty lines (ssh/telnet).

On real equipment you could add the following ACL statement

SW1(config)#access-list 5 deny any log

Unfortunately, this 'log' option does not work in Packet Tracer.

Task 4: Creating a login banner page.

Notice
Banner in Packet tracer only supports motd option (banner login does not work)

SW1(config)#banner motd &

Enter TEXT message. End with the character '&'.

*************************************************

* Unauthorized Access Strictly Prohibited! *

* ***********************************************

&

SW1(config)#

Notice
Make sure that you start banner with a delimiting character that is not used in the banner itself (I could not use '*' as a delimiting character). You must end with the same character to mark the ending of the message to be displayed upon connection.



Verification
Since only PC1 can access SW1 remotely I added telnet support (no ssh client on PC1) to see the banner upon connection.

SW1(config)#line vty 0 4

SW1(config-line)#transport input all

SW1(config-line)#

 
The last "security" touch is to use username and password for console 0 access. Since we have username and password locally defined (ccna/cisco), let's use it:

SW1(config)#line con 0

SW1(config-line)#login local

SW1(config-line)#

Previous Lab | Exercises | Next Lab