Lesson 46 - EIGRP Fundamentals Part 4 - Troubleshooting

In this post I'd like to show you how problems in EIGRP can manifest themselves and how to find and fix problems that are less conspicuous. All in the scope of the CCNA level.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Let's assume that this is a new system and your colleague who's not experienced enough tried to set it up but with no success. Some work was done and the task at hand is to connect successfully the branches with headquarter accomplishing full reachability.

The first thing I'm going to do is to learn the topology diagram to know the addresses and encapsulations which connect the branches with the HQ network.

I log in to R1 and here's my first finding. Check it out:

Pic. 2 - EIGRP First Error.

The above output sent to the console indicates that R1 receives hello packets on its local S0/2 interface from the wrong address (not on common subnet). The IP address of the sender is: 172.32.14.4. R1's interface S0/2 is configured as 172.31.14.1. Clearly wrong address is assigned onR4.

I jump over to R2 and correct the address on S0/2 and make sure it is EIGRP enabled by typing in a right 'network' statement.

R4 Configuration:

!

R4(config)#int s0/2
R4(config-if)#ip address 172.31.14.4 255.255.255.0
R4(config-if)#router eigrp 1
R4(config-router)#no network 172.32.0.0
R4(config-router)#network 172.31.0.0
R4(config-router)#

!

I perform a simple check: I want to make sure that R4's interface S0/2 is running EIGRP protocol. Here's the output:

Pic. 3 - R4's EIGRP Interfaces.

To my great surprise, the interface is EIGRP-enabled but there R1 is not listed as the neighbor (peer). The ping shows no problems reaching R1 (172.31.14.1).

In this situation I decide to use a 'debug' tool. Be careful using 'debug' commands as they may severely impact the operation of the router. More information on how to use debug in lesson 37.

I disable a timestamps so the output of the debug is clearer. As soon as the first information is sent to the screen, I disable debug using 'u all' command (in case you are in other mode than privileged '#' the 'do u all' is used. It is the alias for: 'undebug all'. Here's what the debug reports.

Pic. 4 - Debug EIGRP Packets.

The output reveals that the local router (R4) has problems with authentication of EIGRP packets. Opcode =  5 (authentication off or key-chain missing).

The 'show key chain' shows ... zilch! There's no key chain defined on R4. I need to do it. I'm going to do to errors while configuring key chain in order to show you how they show in the 'debug ip eigrp' statement.

Here's my first erroneous configuration:

R4 Configuration: 

!

R4(config)#key chain EIGRP
R4(config-keychain)#key 2
R4(config-keychain-key)#key-string cisco
R4(config-keychain-key)#
R4(config-keychain-key)#int s0/2
R4(config-if)#ip authentication mode eigrp 1 md5
R4(config-if)#ip authentication key-chain eigrp 1 EIGRP
R4(config-if)#

!

You noticed that I used the key 2. Since, the neighbor adjacency has not been built, I reach for the 'debug eigrp packets' again. Here's the output now:

Pic. 5 - Another Debug EIGRP Packets.

In the ton of gibberish I fish out the above message: 'key not defined or not live'. This is the cause of  the 'invalid authentication'

I check R1 and see that it uses key 1 and not key 2. The mismatch in the key number prevents theR1 and R4 from establishing adjacency.

I'll make one more mistake so that you can see another error related to authentication. Look at my key chain authentication on R4:

Pic. 6 - Running Configuration - Key Chain.

At first glance, all seems okay. But is it?

Still R1 and R4 are not neighbors. Let's debug one more time.

Pic. 7 - Debug EIGRP Packets.

This time there is no complaints about key number, but authentication still fails. The problem is with the password used. It does NOT match with the other end. Now, displaying configuration on both R1and R4 shows the password 'cisco'. But is it so? Check the below output on R4:

Pic. 8 - Show Key Chain.

A closer inspection shows that the password cisco is followed by a 'space' character which does not show in the 'show running-config'. This a cause of the problem.

One last error that shows without any debug. Check it out:

Pic. 9 - EIGRP Unsolicited Error Message.

The problem is with the K-values used by R5's neighbor (R2). They do not match on both ends. A quick look at R5 shows that default K-values are used.

Pic. 10 - Show IP Protocols on R5.

The same output on R2 reveals that it all K-values are used to calculate the metric. They do not match on both ends which results in lack of neighbor adjacencies between routers.

Pic. 11 - Show IP Protocols on R2.

A look at EIGRP configuration on R2:

Pic. 12 - EIGRP Configuration on R2.

 A quick fix on R2 and all is good!

R2 Configuration: 

!

R2(config)#router eigrp 1
R2(config-router)#no metric weights
R2(config-router)#

!

Incidentally, EIGRP unsolicited error messages are sent to the screen every few seconds which makes it hard to do the diagnostics. You can temporarily disable logging to the console 0 by typing:

R2(config)#no logging console 

To bring back the defaults:

R2(config)#logging console

In the next post, I'll look at the ACLs (Access Control Lists) and how they can serve different purposes in your network.

Lesson 36 - Routing Information Protocol Part2

In this post I'm going to reinforce all the theory discussed in the two previous posts. But I would like to make it more practical this time. This should help you understand RIPv1 better and hone your skills regarding its implementation. RIPv1 is a good prelude to learning RIPv2 as well since the verification commands are identical for both versions of the protocol. I will finish this lesson off by showing you one quick optimization technique used often with both versions of RIP.

Our topology diagram remains the same.

Pic. 1 - Topology Diagram.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

In my previous post I enabled RIP protocol on all the routers and interfaces in the topology presented. Now is the time to verify its operation.

The first RIP verification command I'd like to introduce is the powerful: 'show ip protocols'. It provides information about which dynamic routing protocols are enabled on a router, if any, also displaying specific information about them (here's RIPv1 information).

Pic. 2 - The 'show ip protocols' output on R1.

Get familiar with the output and pay a special attention to the highlighted pieces of information. The output shows us the following (pic.2):

• Outgoing/incoming filter list - currently, there are no filters applied to updates being sent or received (more on ACLs which are used to do filtering in the upcoming posts).
• Sending updates - RIP is advertising its routing table every 30 seconds and the next update is going to be sent in 16 seconds.
• Invalid after - The routing entry is invalidated (can no longer be used) if it is not refreshed by neighbor(s) in 180 seconds.
• hold down - If the router receives a 'route-poison' message from the neighbor(s), it still does not trust it entirely for another 180 seconds (it is possibly down). After that period of time it invalidates the prefix. Meanwhile, the router keeps sending packets to the destination marked as possibly down like everything is 'a-ok'.
• flushed after  - The routing entry is removed from the routing table after 240 seconds if not refreshed by the neighbor(s).
• Default version control - the router is advertising version 1 updates, but able to accept updates from both RIPv1 and RIPv2 enabled routers.
• Automatic Summarization - Automatic summarization is enabled (more on this in 'RIP rules' section later in the post).
• Maximum paths - currently the router can use up to 4 equal cost path (metric identical) to a given destination (configurable: up to 16 in most IOS versions as of writing this post).
• Routing for networks - the router has interfaces in 172.31.0.0 class B networks.
• Routing Information Sources - neighboring router's addresses which the router heard from. The time shows when was the last time R1 received the advertisement from its neighbors (e.g. neighbor 172.31.15.5 sent its update to R1 8 seconds ago). This timer should never show you more than 30 seconds under normal circumstances. If the last update from a neighbor arrived longer than 30 seconds ago, it means that the either the neighbor stopped sending its updates or they do not get through.

As you recall, the 'network' statement we used to enable RIP on the interfaces takes a classful IP address as its argument (like explained in the previous post). There is no other additional keyword available for RIP (others protocols use wildcard mask to accomplish this). In case your router has multiple interfaces configured as subnets of the same major network, they all are going to participate in the RIP domain.

For instance, if on R1 I wanted to enable RIP protocol on S0/2 interface only, with my addressing scheme it is not possible. All interfaces are subnets of the same class B major network (172.31.0.0) and will be automatically encompassed in RIP process. If you try to outsmart it and use the following classless statement, it will be accepted by IOS syntax rules but the resulting configuration is going to look like shown in pic. 3 anyway.

Configuration attempting to enable RIP on S0/2 only:

R1(config)#router rip

R1(config)#network 172.31.14.0

Resulting is the following running configuration:

Pic. 3 - RIP's classless statement result.

Of course, it is possible to filter out what is going to be advertised or which updates are going to be accepted by the RIP process. This however is beyond the scope of this lesson as you do not know necessary tools to accomplish that yet.

Another command that you may find useful if you want to see what is currently in the RIP database is the following:

Pic. 4 - RIP Database.

 

The best entries in the RIP database (normal route selection process applies) are going to populate the routing table. You already know the command 'show ip route' which displays the full routing table including connected and static routes as well. But you can also try to display RIP routing entries only rather than the whole routing table. Here's your command:

Pic. 5 - RIP Routing Table.

The routing table contains two class C network addresses advertised by R4 and R5 respectively: 

• 192.168.4.0
• 192.168.5.0

Also, it tells us that the R1 has seven subnets of 172.31.0.0 class B network. Hang on a second! We can only see three of them listed in pic. 5:

• 172.31.25.0
• 172.31.24.0
• 172.31.2.0

Where are the remaining four subnets?
Take a closer look at pic. 4 which shows the whole RIP database. Can you see the missing four subnets now? In case you can't spot them in pic. 4 look at the following one (pic. 6) which shows all seven of them. For clarity, I have removed class C networks and highlighted the subnets in question.

Pic. 6 - R1's RIP Subnets.

There are seven subnets of 172.31.0.0 class B network indeed! The RIP database shows them all, but the ones that are directly connected subnets, are not making their way to the routing table. Do you still remember why?

The reason is, of course, related to the route selection process already explained in the previous posts. The router knows them as directly connected subnets with the administrative distance of 1,and the same entries are now in the RIP database (as the 'network' statement encompasses them). Recall that RIP's administrative distance value is: 120. The directly connected networks are always the most preferred ones. That is why, we see them as connected rather than RIP generated entries.

Notice the two entries in the routing table: 172.31.24.0 and 172.31.25.0. They both have two equal cost paths (the same metric) which is correct according to our topology. In that case traffic-sharing (load balancing) is going to occur when packets are sent to these destinations.

However, R1 has not learned 172.31.3.0/28 and 172.31.3.16/28 subnets that should be advertised byR3.

What is the explanation to this?

Let's do some diagnostics on R3 in order to find out what is going on. I'm going to start by checking that RIPv1 has been enabled properly on R3. I want to make sure that the loopback1, loopback2, and F1/0 interfaces participate in the RIP domain (the 'network' statement encompasses them). Here is the result of the test.

Pic. 7 - R3's RIP Information.

It seems that configuration is correct! So, let's take a closer look at what R3 is advertising to their neighbors. In order to see that, we must use 'debug ip rip' command.

---

WARNING!
Extreme care must be taken when using any debug commands on the production equipment. After the diagnostics have been completed, the debug command(s) must be turned off immediately.
All 'debug' commands are VERY dangerous if used on the production routers. They have enormous impact on the CPU and can potentially crash the device. They are typically used as the commands of the last resort during troubleshooting of a given technology when problem cannot be resolved without data they provide. So we tend to use them only in situations when we cannot do any more damage than there has already been done :-).

---

However, in the lab it is recommended to learn what information can be obtained using 'debug' commands. They help us gain a deeper understanding of a given technology and may be very helpful in troubleshooting.

Since I use the lab equipment (dynamips/dynagen emulator to be accurate), I can safely enable the following debug command to trace the RIP process without any damage to my gear. In practice, it is best if you redirect the output of the debug commands to RAM memory and then copy its content to a text editor for analysis. Here's how you can do this:

Step 1
Make sure that CPU is not heavily utilized first. Enabling 'debug' commands can create high CPU utilization on the production equipment.

R3#show processes cpu

The first line shows the cpu utilization for the last five seconds, one minute and five minutes. If CPU is not very busy you can proceed to step 2.

Step 2
Disable the time stamp service (optionally) to obtain a better output, disable logging to the console and redirect the output to the RAM memory instead.

R3#configure terminal

R3(config)#no service timestamps

R3(config)#no logging console

R3(config)#logging buffered

R3(config)#end

Step 3
Enable appropriate 'debug' command (here: rip process is being debugged)

R3#debug ip rip

Step 4
Wait a period of time till output is sent to the RAM memory. Nothing will show on a screen as per step 2. Then disable debugging (here, the alias is used which disables debugging of all processes which is the fastest method). You can disable the specific one as well. In case of my debug this could be: 'undebug ip rip', or 'no debug ip rip'.

R3#u all

Step 5 
Display the content of the debug from the memory buffer and copy it to a text editor for analysis.

R3#show logging

Step 6
Bring back the previous settings (logging to the console and time stamps).

R3#configure terminal

R3(config)#no logging buffered

R3(config)#logging console

R3(config)#service timestamps
R3(config)#end

For clarity's sake, I have broken the output of 'debug ip rip' into pieces so it is easier for us to analyze the information it provides. In practice, either you learn how to properly interpret the output the way it is presented to you by the system or you can rearrange the output in a text editor.

The first debug output (pic. 8) illustrates what R3 is advertising out its Loopback1 interface. It's worth mentioning, that RIPv1 uses broadcast address (255.255.255.255) to announce networks/subnets as explained in lesson 35. RIPv2 will use the multicast address 224.0.0.9.

Pic. 8 - R3's Update out Loopback 1.

Next output (pic. 9) shows what R3 is announcing out its Loopback2 interface. Both loopback interfaces are enabled in RIP so, naturally, the updates are sent out these interfaces. Take a look at the output and analyse both (pic. 8 and pic. 9) comparing them with the topology diagram (pic. 1).

Pic. 9 - R3's Update out Loopback 2.

Finally, what we have waited for is the answer to the question why R1 and R2 do not receive the subnets /28 from R3. Look at the below picture (pic. 10).

Pic. 10 - R3's update out F1/0.

Suprisingly, R3 does NOT advertise ANYTHING out towards R1 and R2 (out F1/0 interface). We understand, that R3 will not advertise out F1/0 what has been learned on this interface (split-horizon). But why does it not advertise both subnets configured on the loopback interfaces (172.31.3.0/28 and 172.31.3.16/28)?

The answer is the rules used in RIP in terms of sending and receiving updates.
However, before I'll show you all the rules RIP uses, let's finish our diagnostics and look at what R3is receiving from one of its neighbors R2 (pic. 11). Notice, that the update R3 receives from R2 does NOT contain network mask, only metric (hop-count) like explained in the previous lesson.

Pic. 11 - R2 Advertisement for R1 and R3.

RIPv1 Sending and Receiving Updates Rules
Now, let me show you the update rules RIP uses which should clarify its behavior shown in this lesson.

Pic. 12 - RIP Rules for Sending Updates.

Clearly, according to pic.12, R3 will not advertise /28 subnets since the egress interface (F1/0) DOES belong to the same major B network, but the network mask on this interface is NOT the same as the subnets being advertised. Egress interface uses /24, whereas the subnet candidates for advertisement use /28.

The only way to resolve this issue is to either re-address the subnets according to what is allowed in RIPv1 or use RIPv2 instead.

As for the receiving updates in RIP protocol, the rules look as follows:

Pic. 13 - RIP Rules for Receiving Updates.

Passive Interface in RIP Protocol

You may have noticed that updates are sent out of all interfaces enabled for RIP. Otherwise routing would not work properly.

But what if there is no router listening to these advertisements? A router can be connected to networks with no other routers in them. They must be advertised out other interfaces still. In such situation it is a waste of the bandwidth to send RIP advertisements every 30 seconds if no router listens to them.

The solution is to use the 'passive-interface' command under the RIP process. When used with RIP protocol, the command will prevent a router from sending advertisements out the passive interface, but the subnet/network address of this interface is going to be included in the updates sent out other interfaces. Also, passive interface in RIP is capable of receiving updates and processing them.

Be careful with making the interface 'passive' while using other routing protocol than RIP. The behavior of the same command will be different. In OSPF or EIGRP routing protocols, the 'passive-interface' command prevents these protocols from sending 'hello' packets which has serious implications. More on that in the upcoming posts.

As an example, in order to stop sending advertisements out R3's loopback interfaces, the configuration will look like the one shown below:

R3#configure terminal

R3(config)#router rip

R3(config-router)#passive-interface loopback1

R3(config-router)#passive-interface loopback2

This configuration optimizes RIP operation preventing it from sending its periodic advertisements out of both loopback interfaces.

Of course, in large systems using RIP is not a common solution. Those who have no other choice, would definitely choose RIPv2 rather than RIPv1. And this is going to be the topic of my next post which finalizes the discussion of RIP fundamentals.

Post Questions and Answers

As per request (look at comments below), I decided to post the explanation for the two very interesting scenarios I received from some anonymous person (forgive me but I did not see your name in the post).

First take a look at the picture below.

Pic. 14 - RIPv1 Scenarios.

Example 1

Notice that in RIPv1 auto-summarization to the class boundary is always in effect.

Also, notice that the update does NOT contain a network mask.

R1 receives two RIPv1 updates:

• 10.0.0.0 from R2.
• 10.0.1.0 from R3.

The result is as per the rules explain above (pic. 13). R1 is going to have only one RIP prefix which is 10.0.1.0 in its routing table. This is because the rule for receiving update is asking the following question (pic. 13):

Do any subnets of the same major class exist in the routing table?

Yes! 10.0.1.0 subnet exists, that is why 10.0.0.0 which is less specific (major class) is IGNORED.

Example 2

Notice that in RIPv1 auto-summarization to the class boundary is always in effect.

Also, notice that the update does NOT contain a network mask.

R1 receives the SAME prefix on two different interfaces F1/0 (10.0.4.1) and S0/1 (10.0.3.1).

If the metric is the same, R1 considers both paths: via F1/0 and S0/1 as equal cost paths and performs a load balance.

I hope that clarifies these two corner case scenarios!

Lesson 16 - VLANs In Practice

Lesson 15 introduced another layer 2 concept called VLANs (Virtual Local Area Networks). If you understand their purpose, it is time to get the juices flow by configuring them.

In this post, I am going to show you how to configure VLANs in a simple design, routing between VLANs and how to verify their operation. I am going to use the following network topology to accomplish our goals (Pic. 1).

Pic. 1 - VLAN Topology

Icons designed by: Andrzej Szoblik - http://www.newo.pl

---

NOTICE!
In my testing topology (pic.1) I have already configured the management VLAN (500), for the purpose of accessing the switches and R1 remotely from my computer.

VLANs 10 and 20 as well as the R1 routing configuration have not been configure yet. This is going to be our main task in this lesson.

---

Before we begin, take a closer look at the the topology (click at the picture to enlarge it). Please, pay a special attention to the IP addresses of the computers. Have you noticed that they belong to two DIFFERENT layer 3 networks? The blue numbers below denote the network address and they are different. If you are not familiar with IP addresses, and you have no clue what I'm talking about, don't worry. I'm going to explain those in the upcoming lessons.  

• PC1 address is 192.168.10.1 255.255.255.0 
• PC2 address is 192.168.20.1 255.255.255.0

For now though, take for granted that if computers are members of different layer 3 networks, the applications installed on them cannot communicate without a router.

Okay, it's time to type in our first command: show vlans.

Pic. 2 - 'show vlans' command.

The output (Pic.2) gives you a plethora of information. Take a closer look and then read on to know what you're looking at.

1. VLAN - This column shows all VLANs that exist in a switch database. In the case of my switch, there is only one VLAN I have created (VLAN 500). I've named it HOME_LAN. I use it be able to access my equipment using Telnet. All other VLANs listed exist on a switch by default. You can safely ignore these as they are not even supported by the switch (VLANs 1002-1005). Important is VLAN 1, which is the default one. All interfaces belong to VLAN 1 by default.
2. Name - This column lists the names given to VLANs. Switches use numbers to differentiate between VLANs, not names. You name VLANs using friendly names, so we know which VLAN number is which group. If you do not give a name to a newly created VLAN, the default name is given (e.g. Vlan0002 for VLAN 2, Vlan0003 for VLAN 3 etc.).
3. Status - It tells you what VLANs are active and supported by a switch. If you delete VLAN from the database, and the port is still configured as member of this VLAN, the port is not going to forward any frames. Default VLAN (VLAN=1) CANNOT be removed. You can try, but it won't work.
4. Ports - The last column, shows which ports belong to VLANs. Simple as that. In order to change VLAN's membership of the interface, you have to do it manually.

Below, you can see some additional parameters related to the VLANs such as MTU (Maximum Transmission Unit), which for Ethernet is 1500 bytes.

A more handy command is: show vlan brief. Take a look at its output (pic. 3).

Pic. 3 - 'show vlan brief' output.

This is probably more often used command if you want to check the VLANs and port membership.

Interfaces have default settings which are not seen in the running configuration:
show running-config.

In order to verify what are the default settings of the interface use the following command (here interface f0/1 is used):
show interface f0/1 switchport.

Familiarize yourself with the output of this command. Pay a special attention to the lines I highlighted.

Pic. 4 - 'show interface f0/1 switchport' output.

Recall from the previous lesson (Lesson 15) the two types of the ports used in VLAN infrastructure: trunk and access. I need to ramble a tad more before we proceed to the configuration.

1. Administrative Mode: dynamic desirable - This option means that the port is running Dynamic Trunk Protocol (DTP). Port int this mode (the default setting on this particular switch), will send special frames to the device connected to it, trying to negotiate trunk connection. If the other end responds to this proposal, both interfaces become trunks. Since in my case, it is a PC that is connected to port F0/1, and did not respond to this negotiation (no DTP), the port became a 'static access' (member of one VLAN only).
2. Operational Mode: static access – This tells you what the real mode of the port is. Here, the interface did not negotiate trunk connections so automatically became an 'access' interface.
3. Negotiation of Trunking: On – This option informs you, that the DTP protocol is active on the interface. The port will be sending DTP frames out trying to negotiate trunk mode.
4. Access Mode VLAN: 1 (default) – Since the interface did not become trunk, and there is no manual configuration regarding the VLAN it should belong to, the interface ended up as a member of the default VLAN (VLAN 1).
5. Trunking VLANs Enabled: All – In case the interface transitions to a trunking mode, ALL VLANs are going to be allowed on this interface (1-4094).

Now, it is time to define our configuration tasks and complete our mission.

CONFIGURATION STEPS

Given the topology diagram (pic. 1), configure the following:

1. Configure end-to-end VLANs (the same set of VLANs on all switches).
2. Assign ports to VLANs.
3. Create an unconditional trunking between the switches.
4. Enable routing between VLANs using 'router on a stick' (yes, it is a real name of this method).

SOLUTION

Step 1
Configure end-to-end VLANs (the same set of VLANs on all switches).

On SW1:

SW1#configure terminal

SW1(config)#vlan 10,20

SW1(config-vlan)#exit

SW1(config)#

On SW2:

SW2#configure terminal

SW2(config)#vlan 10,20

SW2(config-vlan)#exit

SW2(config)#

On SW3:

SW3#configure terminal

SW3(config)#vlan 10,20

SW3(config-vlan)#exit

SW3(config)#

Verification

On all switches you should see the VLANs created (here SW1 output).

Pic. 5 – VLANs in the database

Steps 2
Assign ports to VLANs.

Since we are going to use port-to-vlan assignment (recommended in most cases) , this option puts the ports permanently in a given VLAN and disables DTP.

On SW1:

SW1(config)#interface f0/1

SW1(config-if)#switchport mode access

SW1(config-if)#switchport access vlan 10

SW1(config-if)#exit

SW1(config)#

On SW2:

SW2(config)#int f0/1

SW2(config-if)#switchport mode access

SW2(config-if)#switchport access vlan 20

SW2(config-if)#exit

SW2(config)#

Explanation!
The command: 'switchport mode access' puts the port in an unconditional 'access mode' in which DTP is turned off. The port CANNOT become trunk anymore.

The command: 'switchport access vlan 10' places the interface in VLAN 10 (broadcast domain). From now on, the port can communicate with other hosts in VLAN 10 but not other VLANs.

Verification (here only SW1 output)

Pic.6 – show vlan brief

As you can see the port f0/1 is now a member of VLAN 10.

Step 3
Create an unconditional trunking between the switches. 

---

NOTICE!
The trunking should be enabled on ports f0/15, f0/16 and also on f0/1 since this port will use trunking mode to connect multiple R1's sub-interfaces ('router on a stick') for the purpose of routing unicast between VLANs 10 and 20.

Also, in my case SW3 is Catalyst 2950 which supports only DOT1q protocol. That is why the command 'switchport trunk encapsulation' does NOT exist on this switch. I will use that command on SW1 and SW2 though, in order to select this type of trunking protocol.

---

On SW1:

SW1(config)#interface range f0/13 - 15

SW1(config-if-range)#switchport trunk encapsulation dot1q

SW1(config-if-range)#switchport mode trunk

SW1(config-if-range)#exit

SW1(config)#

On SW2:

SW2(config)#interface range f0/13 - 14 , f0/16

SW2(config-if-range)#switchport trunk encapsulation dot1q

SW2(config-if-range)#switchport mode trunk

SW2(config-if-range)#exit

SW2(config)#

On SW3:

SW3(config)#interface range f0/1 , f0/15 - 16

SW3(config-if-range)#switchport mode trunk

SW3(config-if-range)#exit

SW3(config)#

Verification (here SW1 only):

Pic. 7 – show interface trunk

An alternate method of verifying trunk ports is shown below. However, this way you can see one port at a time. But the output is more verbose.

Pic. 8 – 'show int f0/15 switchport'

Step 4
Enable routing between VLANs using 'router on a stick'.

On R1:

R1(config)#

R1(config)#int f0/0

R1(config-if)#no ip address

R1(config-if)#no shutdown

!

! Create sub-interface with IP address to be gateway for VLAN 10.

R1(config-if)#int f0/0.10

R1(config-subif)#encapsulation dot1q 10

R1(config-subif)#ip address 192.168.10.254 255.255.255.0

R1(config-subif)#

!

! Create sub-interface with IP address to be gateway for VLAN20.

R1(config-subif)#int f0/0.20

R1(config-subif)#encapsulation dot1q 20

R1(config-subif)#ip address 192.168.20.254 255.255.255.0

R1(config-subif)#end

R1#

Verification
The ultimate test to verify the connectivity between VLANs is to use ping utility and check if PC1 talks to PC2. If successful, it is proving that our configuration is correct.

The routing table on R1 should show you that router knows both networks: 192.168.10.0/24 and 192.168.20.0/24 (pic. 9). So it can transmit the packets between these two.

Pic. 9 - Routing Table on R1

Soon, video is going to be available with the above configuration and additional options for inter-VLAN routing.

In my next post, we will look at what is really happening 'behind the curtain'. I will show you the traffic flow using our VLAN's configuration step by step.

How to : Basic Router Configuration

Initial Router Configurations: This post shows how to configure the router initially from router
 boot process to optimizing router for best user experience to securing routers console and telnet ports.
 I am using GNS3 and router 2691 image in gns3.

Initial Router Boot Process : Router boot Process consist of

1> POST : Power On Self Test

2> Booting IOS (operationg system of cisco devices) from routers flash memory.

3> Initial Configuration Setup : I basically prefer not to set up router from initial config

When you chose no to initial config dialog router will enter into user mode which is designated as

Router> This mode is known as user mode, you can do ?
For the commands you can enter in this mode. you can only use very general show commands
 from this mode.

Router>?

Exec commands:

access-enable Create a temporary Access-List entry

access-profile Apply user-profile to interface

clear Reset functions

connect Open a terminal connection

disable Turn off privileged commands

disconnect Disconnect an existing network connection

enable Turn on privileged commands

exit Exit from the EXEC

help Description of the interactive help system

lock Lock the terminal

login Log in as a particular user

logout Exit from the EXEC

modemui Start a modem-like user interface

mrinfo Request neighbor and version information from a multicast

router

mstat Show statistics after multiple multicast traceroutes

mtrace Trace reverse multicast path from destination to source

name-connection Name an existing network connection

pad Open a X.29 PAD connection

ping Send echo messages

ppp Start IETF Point-to-Point Protocol (PPP)

resume Resume an active network connection

rlogin Open an rlogin connection

show Show running system information

slip Start Serial-line IP (SLIP)

ssh Open a secure shell client connection

systat Display information about terminal lines

tclquit Quit Tool Command Language shell

telnet Open a telnet connection

terminal Set terminal line parameters

tn3270 Open a tn3270 connection

traceroute Trace route to destination

tunnel Open a tunnel connection

udptn Open an udptn connection

where List active connections

x28 Become an X.28 PAD

x3 Set X.3 parameters on PAD

To Enter into privilege mode do

Router>en

Router# In this mode you can do some show commands, copy commands to save your
 running-configuration to your routers startup configuration

To enter to the main configuration mode do

Router#configure terminal

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

Router(config)# (This is the main mode for configuring basically everything in the router)

So lets start configuring the router

How to change the hostname of router

Router(config)#hostname testrouter

testrouter(config)#

here above you can see the change in hostname from default hostname Router to testrouter

How to configure log on banner on router

testrouter(config)#banner motd *

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

Personal Router Unauthorized access Restricted

*

Above motd means message of the day and this banner is displayed at first log on.
 You have to enter the same Character at the start and end of each motd in this case it is *.

Below you can see how the banner is displayed

testrouter con0 is now available

Press RETURN to get started.

*Mar 1 00:24:00.555: %SYS-5-CONFIG_I: Configured from console by console
Personal Router Unauthorized access Restricted

How to Secure the console login of router : ( When you connect your router to P.C with console cable,
 this console password is required)

testrouter(config)#line console 0

testrouter(config-line)#password cisco

testrouter(config-line)#login (The opposite of login i.e no login will not ask for password when loggin
through console of the router , which can be very risky)

How to secure telnet login of the router : This will secure the login when telneting from the remote P.C

testrouter(config)#line vty 0 ?

<1-935> Last Line number



The above command shows that this router supports 936 vty ports (virtual tele terminal i.e 936 connections )

testrouter(config)#line vty 0

testrouter(config-line)#line vty 0 4

testrouter(config-line)#login

% Login disabled on line 66, until 'password' is set

% Login disabled on line 67, until 'password' is set

% Login disabled on line 68, until 'password' is set

% Login disabled on line 69, until 'password' is set

% Login disabled on line 70, until 'password' is set

testrouter(config-line)#password test

The commands allows the telnet login for vty 0 4 and requires password test to enter
 to the router through telnet.

How to secure privelege/enable mode on router : This configuration will ask for the password 
when entering from the user mode to privilege mode

testrouter(config)#enable secret test

testrouter(config)#exit

testrouter#exit

Below shows how this router asks for the password

testrouter con0 is now available

Press RETURN to get started.

*Mar 1 00:37:34.707: %SYS-5-CONFIG_I: Configured from console by console

Personal Router Unauthorized access Restricted

User Access Verification

Password:

testrouter>en

Password:

testrouter#

How to optimize router for best user experience:

Below command should be entered both for line console and for line vty, I will be showing in console,
 you can do the same in line vty

testrouter(config)#line co

testrouter(config)#line console 0

testrouter(config-line)#log

testrouter(config-line)#logg

testrouter(config-line)#logging sy

testrouter(config-line)#logging synchronous

loggin synchronous will keep the status messages from interrupting what you are typing

testrouter(config-line)#exec-timeout 20 0 : exec timeout will give the timeout interval i.e here if
 no command is typed for 20 minutes the router will throw the user to user mode

Thank You,

In my next post of cisco basics I'll be configuring interfaces. Hope this will be informative for you

How to Configure Interface on Routers :

There may be various kinds of interfaces on the router like fastethernet, serial etc, but for all the 
interface, configuration are basically similar. I am going to show you here the commands
 for configuring the most popular interfaces i.e fastethernet and serial

testrouter#show ip interface brief (This command will show you all the interface, configured ip address,
 interface status, protocol status etc)

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 unassigned YES unset administratively down down

FastEthernet0/1 unassigned YES unset administratively down down

If you want more detailed description then you can do

testrouter#show interfaces ( This will show you detailed view of the interfaces like MTU size,
 Encapsulation on the interface, Erros etc which will be discussed later on other topics.)

you can also do

testrouter#show interfaces fastEthernet 0/0

for detailed configuration of specific interfaces.

To configure interface goto the interface in your routers

testrouter#config t

testrouter(config)#interface fastEthernet 0/0

testrouter(config-if)#ip address 192.168.1.20 255.255.255.0

testrouter(config-if)#no shutdown

*Mar 1 00:07:17.667: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Mar 1 00:07:18.667: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0
changed state to up

testrouter(config-if)#do show ip interface brief

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 192.168.1.20 YES manual up up

FastEthernet0/1 unassigned YES unset administratively down down

As you can see from the above that now FastEthernet0/0 is configured with ip address 192.168.1.20 and its status and protocol are both up. Any time you see status up but protocol down then it means the interface is administratively down and you have to issue no shutdown commands on the interface. If status is down then you have to check your physical connection as Status deals with physical layer. By the way , you can use show commands from any mode, but you have to use it with do.