The blog's Content list

---

Disclaimer

The author of the posts will not assume any liability or responsibility to any person or entity with respect to loss or damages incurred from information contained in this blog.

---

 Quickly navigate to lesson ...

L01	L02	L03	L04	L05	L06	L07	L08	L09	L10
L11	L12	L13	L14	L15	L16	L17	L18	L19	L20
L21	L22	L23	L24	L25	L26	L27	L28	L29	L30
L31	L32	L33	L34	L35	L36	L37	L38	L39	L40
L41	L42	L43	L44	L45	L46	L47	L48	L49	L50
L51	L52	L53	L54	L55	L56	L57	L58

                                  The Blog's Content list

1 - Connecting to Cisco Console Port with MINICOM
2 - Navigating in Cisco IOS

3 - Initial Configuration of Cisco Switch and Router

4 - Introduction to TCP/IP Layers

5 - Encapsulation and De-encapsulation Process

6 - Example of TCP/IP Traffic Flow

7 - Building a Home Network

8 - Ethernet and Hub Operations

9 - Bridging/Switching Learning Process

10 - Cisco Discovery Protocol

11 - Layer 2 Connectivity Troubleshooting Part 1

12 - Layer 2 Connectivity Troubleshooting Part 2

13 - Layer 2 Connectivity Troubleshooting Part 3

14 - NTP and Syslog Services

15 - VLANs Overview

16 - VLANs In Practice

17 - Inter VLAN Traffic Flow Analysis

18 - VTP and VLAN Quiz

19 - Spanning-Tree Protocol Overview

20 - Spanning-Tree Protocol Operation

21 - Spanning-Tree Protocol in Practice

22 - Spanning-Tree Cisco Enhancements

23 - Introduction to Rapid STP (802.1w)

24 - Layer 2 Etherchannel

25 - Switch Port Security

26 - Binary World

27 - IPv4 Address Dissected - Part 1

28 - IPv4 Address Dissected - Part 2

29 - IPv4 Subnetting - The Rules

30 - IPv4 Subnetting - Practice

31 - What is a Router ?

32 - Route Selection Process Demystified

33 - Static Routing

34 - Dynamic Routing Protocols Introduction

35 - Routing Information Protocol Part 1

36 - Routing Information Protocol Part 2

37 - Routing Information Protocol Part 3

38 - OSPF Fundamentals Part 1 - Terminology

39 - OSPF Fundamentals Part 2 - Hello Packets

40 - OSPF Fundamentals Part 3 - RouterID and DR/BDR

41 - OSPF Fundamentals Part 4 - Implementation

42 - OSPF Fundamentals Part 5 - The Lab
43 - EIGRP Fundamentals Part 1 - Overview
44 - EIGRP Fundamentals Part 2 - Implementation
45 - EIGRP Fundamentals Part 3 - The Lab
46 - EIGRP Fundamentals Part 4 - Troubleshooting
47 - Packet Filtering with Standard ACL
48 - Standard ACL Examples
49 - Packet Filtering with Extended ACLs
50 - Extended ACL Examples
51 - Network Address Translation Part 1
52 - Network Address Translation Part 2
53 - Network Address Translation Part 3
54 - Network Address Translation Part 4
55 - Introduction to IPv6 - Addresses
56 - Introduction to IPv6 - Address Structure
57 - Introduction to IPv6 - Address Configuration
58 - Introduction to IPv6 - Migration

Lesson 31 - What is a Router?

We take a lot of things for granted. When it comes to technologies it is not necessarily the best idea. The point is to understand. That is why I am going to start my routing section with fundamentals. Knowing them will allow you to learn more advanced topics on your own later. Make sure you are familiar with my previous posts related to binary numbers and IP addressing before you read this and upcoming ones.

Probably the most appropriate question to start with would be ...

What is a router?
A router is a specialized computer which can connect multiple networks to allow exchange of packets between them. Since a router uses IP header information (layer 3 protocol data unit), to transmit the packets between networks, this ability makes it a layer 3 device. Like switches, routers build a special database which serves as the source of information on what to do with incoming packets. This database is formally called Routing Information Base (RIB). But most often people call it a routing table. How a router constructs a routing table and maintains information in it, will be the topics of quite a few upcoming posts.

A router is in many ways similar to a regular PC. It has RAM and ROM memory chips as well as CPU and motherboard etc. But instead of using hard drive, it uses a flash memory to store files such as the operating system (IOS). Also, what makes it distinct, the operating system and hardware are optimized for fast packet transmissions. Typically the router uses at least two interfaces but more often than not, it has a greater number of them. Cisco operating system is called InternetworkOperating System (IOS). The same name is given to OS used by many Cisco Catalyst switches. Although some of them may also use CatOS.

There is a great variety of interfaces routers can use. For instance, they can connect few Ethernet networks together, but also Ethernet with Wide Area Networks (WANs) such as ATM, Frame-Relay, X.25, ISDN, Broadband etc.

Router Functions
In order for the routers to connect multiple layer 3 networks together, they must be able to do the following:

• Learn which networks/subnets are available
• In case there are multiple paths, choose the the best one
• Keep (routing table) must be up-to-date
• Translate layer 2 headers (disparate network connections)
• Keep loop-free paths
• Make forwarding decisions based on layer 3 headers

Routing is primarily based on hop-by-hop paradigm. This means that if there are multiple routers in the path, a router must find the outbound interface and forward the packet to a next hop router. A router could not care less as to what happens to the packet after it has been expedited.

In order to find the outgoing interface an IP destination address of a packet and a routing table are used. The process whereby destination IP address is the key information to find the outbound interface for a packet is called destination-based routing. However, it is possible to influence that decision making process and choose other criteria such as source of IP transmission, size of the packet, importance of the packet in relation to others or some other parameters rather than destination IP address. When used it is referred to as the traffic engineering. For now though, I am going to focus in on the default behavior.

Before I describe the router's principles of operation, I must make sure we are on the same page with the fundamentals related to the traffic flow.

Let's recall what happens with the packets sent between computers residing in different networks. I will use a simple topology (pic. 1) to review a few facts. Please, get familiar with the picture below first. Pay a special attention to the three headers depicted and numbers in green circles. The numbers refer to the steps below. Of course, this is only a ten thousand foot view of what happens here. Before we jump into the deep water we need to warm up a bit by looking at the process from a high perspective.

Pic. 1 - Traffic Flow and Layer 2/layer 3 Encapsulation/Dencapsulation

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

The numbers in green circles mark the important points of the traffic sent from PC1 (left hand side) to the PC2 (on the right side of the picture).

In the explanation presented below I assume that SW1 and SW2 have populated their CAM tables (learned all MAC addresses on the appropriate ports). Here's how it goes.

Step1 

PC1 sends a packet destined to PC2. Since, PC1 has the IP address 192.168.1.1/24, it realizes that the first 24 bits of the destination IP address are different than its own (source: 192.168.1.1, destination: 192.168.3.1). Conclusion: PC2 is NOT in the same layer 3 network, so default gateway (192.168.1.254) must be used to forward the packet to PC2. Knowing it, the IP header is going to use:

• Src IP = 192.168.1.1
• Dst IP = 192.168.3.1
• TTL = 32 (ttl is set by the application, here I use 32 as an example)

IP packet is encapsulation in Ethernet (layer 2) header in order to be put onto the wire. Ethernet header contains source MAC address of the sender, and destination MAC address of R1's F1/0 interface obtained from the computer's arp cache (if not found in the arp cache, arp request is sent):

• Src MAC: 0000.1111.1111
• Dst MAC: 0000.2222.2222

Step 2
SW1 receives the frame on its port F0/1. It locates the outbound port (f0/2) for destination 0000.2222.2222. It sends the frame out towards F1/0 port of R1. Neither of layer 2 or layer 3 headers presented in the pic. 1 change during this transmission (parameters depicted).

Step 3
R1 receives frame on F1/0 port. Layer 2 header is inspected by R1. Since the destination MAC address (0000.2222.2222) is the address of F1/0, R1 concludes it is the destination for the frame. Layer 2 header is removed and the content of the message (packet) is processed by the router.R1 processes IP header, reads the destination IP address (192.168.3.1) and compares it with the entries in its routing table trying to find the longest match. More on this in the upcoming post. Once the best path has been found, the routing table points to the outbound interface (F1/1) and the next-hop router's IP address (192.168.2.2) that should be used to expedite the packet.

Step 4
The packet is moved to F1/1 port and the TTL number is decremented by 1 (now TTL=31). Then, the packet is encapsulated in the layer 2 header.The following source and destination MAC addresses are used now:

• Scr MAC: 0000.3333.3333
• Dst MAC: 0000.44444.4444

The destination MAC address is obtained from R1's arp cache. If R1 does not know the MAC address for 192.168.2.2 (next-hop router), arp request is sent asking for its MAC address.

Step 5
R2 receives the frame on F1/0 port. It performs the same job R1 has done. It reads the destination MAC address. Since it is the recipient (0000.4444.4444), it dumps the layer 2 frame and processes IP header. It performs layer 3 lookup in its routing table and finds the outbound interface for destination 192.168.3.1. In our example it turns out that the destination network is connected directly to F1/1 interface. In such case, R2 checks arp cache for MAC address of the destination (192.168.3.1) if one is not found, arp request is sent (who's 192.16.8.3.1 ?, I need you MAC address!).

Step 6
The packet is moved to F1/1 interface and before it gets encapsulated, the TTL number is decremented by 1 (TTL=30). The packet is encapsulated in an Ethernet frame header using the following addresses:

• Src MAC: 0000.5555.55555
• Dst MAC: 0000.6666.66666

The frame is sent out F1/1 interface.

Step 7
SW2 receives the frame and finds the outbound interface for the MAC address: 0000.6666.6666 int its MAC address table. It is port is F0/2.

Step 8
The frame is sent out F0/2 towards PC2. Fields in the layer 2 and layer 3’s headers remain the same.

The above is just a quick review in case you've forgotten that.

The interesting bit for us now is the router's process of finding the outgoing interface and layer 2 addresses of the next hop device. I'm going to elaborate on this in my next post. Now, let me quickly present the routing table components that are essential in this traffic flow.

Pic. 2 - Routing Table Components.

Components of Routing Table:

• C and S - point how a router obtained the information (C = connected, S=static route)
• 192.168.3.0/24 - Example of prefix (destination network/subnet)
• [1/0] - square brackets show two numbers. First (1) is Administrative Distance, second (0) is Metric
• via 192.168.2. - the next-hop-router address

How router populates the routing table, what these terms in red mean and how router uses these parameters to pick the longest match and as a result of that the best path, are going to be the main topics of my next post.

Lesson 27 - IPv4 Address Dissected - Part 1

If you already feel comfortable with binary-to-decimal and decimal-to-binary conversions you're up to this post's challenge: learning more about IP version 4 address (IPv4). If you need to brush upon the numeral conversions, check my previous post.

In one of the earlier posts on TCP/IP traffic flow, I briefly described the importance of the addresses. In order for devices to communicate they must be uniquely identified in the network after all. There are typically three such identifiers we use to distinguish between devices:

1. Names - These are used by humans. Applications use addresses not names. Hence, DNS services out there (DNS service is used to resolve names-to-ip, and ip-to-names).
2. Layer 3 addresses - logical and hierarchical unique identifiers of devices in the network. All layer 3 protocols such as IPX, Apple-Talk, IP etc. use different forms of layer 3 addresses. 
3. Layer 2 addresses - flat and most often fixed identifiers of devices (see lesson 6).

DNS Names
Names are used to simplify communication between devices for people. Instead of typing something like this in your web browser: http://72.163.4.161/, which will open the Cisco web server's main page, you prefer to type something like that: http://www.cisco.com/, don't you? If you do the latter, before your web browser sends the request to the Cisco's web server, it will need to ask your local DNS server about the IP address that is associated with the name www.cisco.com. 

Layer 2 addresses 
Since the communication between computers is loosely based on well known OSI model (TCP/IP model is based on it which I described in lesson 4), all upper layers are ultimately encapsulated in a layer 2 header which uses flat form of the address. Such addresses are Ethernet MAC addresses, Frame-Relay DLCI numbers, ATM VCI/VPI pair of numbers etc. What these are depends on what layer 2 technology you use.

Layer 3 addresses

Layer 3 addresses are logical and hierarchical. This post is about IP addresses, but keep in mind that in the past we used to use other routed protocols as well (such as Apple-Talk, IPX and others). These other protocols also used layer 3 addresses that were logical and hierarchical.

IP address (which in OSI terminology is an example of layer 3 address ) is logical. This means, that you can easily change it either manually or using dynamic address assignment (DHCP) service. Consider your private laptop that you use at home. It, most likely, gets an IP address from the DHCP server configured on your broadband router. Then, the following day you take it to work with you. The moment you hook it up to your corporate network its current IP address will be replaced by a new one provided by the corporate DHCP server. It is almost for sure going to be different than IP address your computer uses at home. So the word: logical, describes the volatile nature of the address. The same device can use a different layer 3 address (identifier in the network) depending which network it resides on.

IP address is hierarchical. It is a bit similar to a telephone number as it has a structure. In telephony we use similar concept of hierarchy. Consider this phone number:
001 201 555 1234.

The structure of this phone number has the hierarchy which looks as follows:
00 - the number identifying an international call
1 - the prefix denoting country. Here: it is USA.
201 - number denoting the state in the US. Here: it is New Jersey.
555 - number of the telephone exchange in New Jersey (here it is a fictitious one)
1234 - number of the subscriber connected to this fictitious exchange.

The reason I show you this, is that what seems to be a simple and flat 13-digit phone number, in fact has a hierarchy built in it. The numbers carry special meaning. The same is true about layer 3 addresses in computer networks.

IP address structure consists of two components:

1. Network or subnet address (identifier).
2. Host address (identifier) in the network or subnet.

Let us dissect both components using your computer's IP address as an example. Open the command line window and type in the following command:

in Microsoft Windows:

c:\ipconfig

in Linux/Unix/Mac OS:
$ifconfig eth0

Look at my computer's address below.

Pic. 1 - Output of 'ifconfig eth0' command.

Can you find MAC address, IP address and Netmask in the above output?

MAC address: 00:1e:4f:b0:b2:fc
IP address: 192.168.1.2
Netmask: 255.255.255.0

An IP address uses four numbers and dots as the delimiter. Each number is a one byte number which means that it must be in the range of 0 through 255 using decimal notation.

IP address uses another four byte number that follows it called: network mask (aka netmask). It is the netmask that creates the hierarchy in the IP address. It separates the bits in the address to tell us which ones denote the address of the network/subnet and which ones denote the host address in the network/subnet. In order to see that, check my IP address in the pic. 2 below. The first three bytes (24 bits) denote the address of the network, and the remaining byte (8 bits) denotes the host address in the network.

Pic. 2 - IP address in decimal notation.

In order to actually see the hierarchy presented in pic. 2, let us convert the IP address into binary first.

Pic. 3 - IP address decimal-to-binary conversion.

Now, convert the decimal netmask we use in the example (255.255.255.0) into its binary equivalent. What is it going to be?

 Pic. 4 - Network mask decimal-to-binary conversion.

Network mask bits correspond to the IP address bits. The bits in the IP address which are masked by the network mask bits (1s) denote the network portion of the address. The bits in the IP address that are not masked (corresponding bits in the netmask are 0s), are denoting the host address in the network. Let us combine the IP address bits with the netmask bits to see the hierarchy now.

Pic. 5 - IP address and the network mask create hierarchy.

Clearly, the first three bytes (192.168.1) in the IP address are masked (255.255.255). Those twenty four bits are the NETWORK bits, the remaining eight bits in the address (2) are not masked (netmask bits are all 0) and become the HOST bits in the address.

The hierarchy in my computer's IP address could be depicted like this:

Pic. 6 - IP address Hierarchy.

There is a bit more we need to know about IP addresses.

In my next post I will continue on explaining what IP address classes are and how they are used today. Also, I will describe the concept of network and subnet and the difference between them. I will finish IP address description by telling you about certain reservations in the IP address range we must be aware of. This and the next post will be the pre-requisites for the upcoming lesson about calculating subnets.

Lesson 12 - Layer 2 Connectivity Troubleshooting Part 2

In the previous lesson I attempted to show you how to go about a performance problems we might experience due to the duplex mismatch. It was our first trouble ticket in the series on layer 2 problems.

In this lesson I am going to create another issue to show you how your current skills can be practically useful in diagnosing network connectivity problems.

---

NOTICE
The steps presented in this lesson are not the ALL possible diagnostics you can do. And they do not have to be done in this specific order. I am merely listing some logical steps which might be useful in order to 'nail down' the root cause of the problem.

---

Trouble Ticket 2
Some client computers have problems accessing FTP server located in the same network 192.168.1.0/24. This behavior is very intermittent. 

We need to collect a bit more data related to this problem. A good starting point might be to take down the following pieces of information:


FTP Server
IP address  = 192.168.1.4
MAC address = 00:10:5a:d3:e4:e0

FTP Client1 (with no connectivity to FTP server)
IP address = 192.168.1.2
MAC address = 00:10:4f:b0:b2:fc

Here is one way of doing basic diagnostics.

Step 1
We want to make sure we have layer 1-3 connectivity between the Client1 and the server first (remember 'divide and conquer' method from the previous lesson?).

jr@mandala:~$ ping 192.168.1.4
PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.
64 bytes from 192.168.1.4: icmp_seq=1 ttl=64 time=0.372 ms
64 bytes from 192.168.1.4: icmp_seq=2 ttl=64 time=0.349 ms
64 bytes from 192.168.1.4: icmp_seq=3 ttl=64 time=0.371 ms
64 bytes from 192.168.1.4: icmp_seq=4 ttl=64 time=0.374 ms

It seems we have layer 3 connectivity working just fine.

Here's an interesting question for you. How do you know, you have received the replies from the FTP server in question (192.168.1.4)?

Now, you may have very confused expression on you face as in 'what do you mean?'. Have I not just gotten the reply from it?

Well, let me show you something to address this question.

Step 2
In order to be absolutely sure I got the reply from the FTP server (192.168.1.4) I need to verify my computer's ARP cache (Client1). Recall, that every time a host sends the packets, it encapsulates them in layer 2 frames (here Ethernet ones). In order to do that, the Client must have a valid destination MAC address (00:10:5a:d3:e4:e0) mapped to its IP address (192.168.1.4). If this mapping entry is not found in the APR cache, the Client1 will send ARP request to learn MAC address of 192.168.1.4. Knowing it let's check the ARP cache after we have sent ping packets. Here's what we find in (Pic. 1):

Pic. 1 - ARP Cache Entries

Pay attention to the highlighted entry. Is the MAC address mapped to our FTP server's IP address correct? 

NO! 

This MAC address does not belong to the server. FTP server's MAC address is: 00:10:5a:d3:e4:e0.

That test proved that getting echo replies to our echo packets (ping) must also be verified in the sender's ARP cache.

So, which device does this MAC address 00:10:0f:a3:3b:e6 belong to? And how on earth did it end up in our Client's ARP cache?

Well, in order to answer the second question, the reasons for this wrong mapping might be different. There could be the device with the duplicate address (same as the FTP server). Then, when the clients send ARP request for the MAC address of the server, this 'rouge' device (not the legitimate FTP server), also responds to the query. And if its answers arrives later than from the legitimate server, the override the legitimate MAC address mapping in the ARP cache. If some other clients get the reply for their ARP query from the 'rouge' device first and then from the FTP server, they create the mapping correctly. That would explain why some computers can still FTP to the server and others can't. Another reason for this wrong mac-to-ip mappings might be ARP poisoning attack in the network (eg. using Ettercap tool).

As for the answer to the first question, if this is not an ARP poisoning attack, you can use your knowledge from the lesson 9 about switching which helps you understand CAM table creation. Then, send uninterrupted ping towards the 'rouge' device and try to trace the mac addresses from switch to switch to find out where the device with duplicate IP address is located. MAC address table should help you find it relatively quickly.

There might be one more question I would like to clarify. Why the duplicate address was not detected by the 'rouge' device? Answer to that question may surprise you. The duplicate address detection uses so called 'gratuitous arp'. This is an unsolicited advertising of the MAC address upon computer startup. If some computers use the same MAC or IP, the newly computer cannot use its IP in the network. Unfortunately, some operating systems may not use this mechanism. They 'trust' what the operator does. If she or he wants this address, there will be no protest on their part.

I hope you are now beginning to see how much you already know!

In my next lesson you are going to analyze the third trouble ticket for layer 2 connectivity. This is going to be the last troubleshooting lesson. The upcoming lessons will describe other tools and interesting technologies such as VLANs, Spanning-Tree Protocol. Once we finish with foundations related to layer 2, we'll start discussing layer 3 technologies and concepts such as IP addressing, subnetting, routing etc.

Lesson 11 - Layer 2 Connectivity Troubleshooting Part 1

The last two lessons I tried to explain the foundations related to layer 2 operation. I discussed very important switching process and CDP protocol which comes in handy at times. If you also have watched the video in the lesson 10, you got a glimpse of few commands explained in the theory earlier on.

In this lesson, we'll focus on practical application of the layer 1 and layer 2 concepts which could be helpful in troubleshooting networking issues.

Even though we're capable of creating lots of great things we're still human beings. And 'to err is human' adage is as conspicuous in the networking field as anywhere else. This means, that occasionally things won't work as expected. In such situations we need to be able to isolate and fix the problems quickly.

Reactive troubleshooting almost always uses the following work flow:

1. A problem is reported.
2. Data and facts are collected.
3. Data analysis must be performed.
4. Potential causes are eliminated.
5. Hypothesis is drawn.
6. Hypothesis is verified. 

In some situations the steps 3 and 4 could be omitted. But it depends on the nature of the problem reported, severity of issue, skills of the technician etc.

As we have yet to learn layer 2 technologies such as Vlans and Spannig-Tree Protocol which add complexity to troubleshooting process, let us, for now, focus on simple cases. This way we're going to build our troubleshooting skills step by step given the knowledge we posses.

Recall the process of moving data from one computer to another. Everything sent from the application layer goes down to the physical layer. That teaches us one important thing: if the layer 1 is not operational, nothing else will work! 

So, we could start diagnosing the networking problems by checking the layer 1 connectivity first. Then, we could move on to the layer 2 and work our way up till we isolate the problem. This makes perfect sense. However, a lot of technicians use other method known as 'divide and conquer'.  In networking diagnostics that might be checking the layers in the middle. For instance using the 'ping' utility we can check the layer 1 through layer 3 status as a starting point. Of course, you already know how the 'ping' works, don't you? 'Ping' uses ICMP protocol which is a layer 3 messaging mechanism encapsulated directly in IP headers.

---

NOTICE
Ping utility is a layer 3 reachability checking mechanism. It sends a number of ICMP echo messages to the destination host. If the destination host receives echo messages, it sends ICMPecho reply messages back to the sender. Of course, assuming that there are no mechanisms implemented that would filter those messages along the path (like local firewall for instance), the sender should receive those replies and thus effectively checking layer 1 through layer 3 reachability. Thus, the path is verified in BOTH directions.

---

If you aim at the layer 3 reachability using 'ping' utility, you may get one of the two results:

1. You get the reply from the destination. This leads to a conclusion that all layers 1 through 3 are working properly. And the connectivity problems might be related to upper layers (layer 4 upward).
2. You do not get the reply from the destination. In that case, this step is not enough to determine the nature of the issue. In this case, you must perform some additional diagnostics.

Now, I am going to show you a few of such steps.

---

NOTICE
The steps presented in this lesson are not the ALL possible diagnostics you can do. And they do not have to be done in this specific order. I am merely listing some logical steps which might be useful in order to 'nail down' the root cause of the problem.

---

Trouble Ticket 1
Data transfer from PC1 toward PC2 is very slow (refer to Pic 1).

Pic. 1 - Simple Topology

 

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

As you see, without the topology diagram, it is much more challenging to do diagnostics. If we know the topology and the path between the source and destination devices in question, we can focus on all components that participate in the data transmission and isolate the issue.

First, let us determine what we know.


The transmission succeeds, but is slow. Verify that yourself. Do not assume it's true or properly tested by the person who reported that. Most users cannot properly describe the nature of the problems.

So, you have done the tests and the transfer proves to be slow indeed.


Some questions you might ask:

• Has this problem occurred recently?
• Is this a new client computer or destination server?
• Has any configuration/update/cable replacement/or any other changes been done on any devices in the path before the problem manifested itself?
• Are other computers experiencing the same problem, or is this individual case?
• etc.

Further data and fact collection may depend on the answers to those questions. For the argument's sake let's assume, that the server is a brand new computer installed the day before the problem occurred. All clients sending files to the server suffer from slow data transfer. When you connected the same client to the server directly, the transfer is very fast (computer-to-server through cross over cable).


Given those facts, we're going to take a quick look at the status of the interface where our server computer is connected. The command that is very useful to check both the layer 1 and layer 2 status is:

SW2#show int f0/2 

Pic. 2 - show interface command

This output deserves some explanation.

FastEthernet is up,

This is the status of the layer 1 connectivity (your cable seems to be attached right?).

line protocol is up

This is the status of the layer 2. It looks like the keepalive packets sent every 10 seconds are working back and forth (do not trust it entirely though; look at the trouble ticket 2 in the next lesson).

half-duplex, 100Mb/s

Duplex negotiated is HALF duplex. Most network adapters used in the computers use AUTO negotiation. This means, that the NIC (Network Interface Card aka network adapter), sends special signals to the port of the switch trying to negotiate FULL duplex and the highest speed supported. Unfortunately, some NIC manufacturers do not follow the specification regarding this signaling. This causes some "misunderstanding" between the port of the switch and the NIC. Switch typically drops down the duplex from FULL to HALF. That causes the switch port to enable the Carrier Sense, Multiple Access with Collision Detection mechanism (CSMA/CD) which is used on SHARED not dedicated connections (for details look at the lesson 8).

What we end up having is the NIC working in FULL duplex but the port of the switch runs HALF duplex. It 'thinks' it can either send or receive data but not do both at the same time. When server begins to 'push' data across the network, the port of the switch cannot send anything out towards the server. When it finally 'thinks' it can (medium free) and sends data towards the server, the latter begins to send data down towards the port as it is allowed in FULL duplex connections. The switch must stop immediately as the frames are experiencing collision. At least that is how the switch works under the circumstances. Then it waits till the carrier is free again (no data from the server down the port). This problem is known as: DUPLEX MISMATCH. That results in great number ofcollisions and late collisions recorded on the port of the switch like shown in the above output.

The solution to that problem could be the following actions:

1. Try to upgrade the NIC driver using your server/computer vendor's web site.
2. If the problem persists, you may try to hard code speed and duplex. You have to do this on both ends of the connections. This disables the AUTO NEGOTIATION feature (do not listen to people who say you should do this on one end of the connection).
3. Sometimes, though very unlikely in our situation, the cable can cause that sort of behavior. Replacing it to the one that is proven to be good, might help. Again, typically we would see some other layer 1 errors (CRC errors, carrier loss).
4. Replace the NIC on the server to the one that you are sure is working well.

Hard Coding Speed and Duplex

SW2#configure terminal

SW2(config)#interface fastethernet0/2

SW2(config-if)#speed 100

SW2(config-if)#duplex full

As for the computer, you have to refer to the manual of your operating system  how to set speed and duplex on the NIC manually. Perhaps google this. Google are the best!

In the next lessons, we will resolve two more connectivity issues given the skills we obtained in previous lessons.

Lesson 9 - Bridging/Switching Learning Process

In the previous lesson we looked at the Ethernet and a hub operation. We classified hub to be a layer 1 device as it does not understand any headers used by upper layers of our networking model. It simply forwards the bits it receives out all remaining ports. Even though, they do provide basic connectivity to our hosts, they also reveal a lot of weaknesses. For details look at the lesson 8.

A more intelligent and robust device that can replace a hub is a layer 2 switch. You've already learned how to navigate in IOS, and provide the switch with a simple configuration. With this lesson we begin a more serious exploration of layer 2 through layer 4 functions starting with Layer 2. This is good enough excuse to brush upon encapsulation/de-encapsulation process, and the structure of the headers.

Enapsulation Process Re-Visited
This is a quick review of encapsulation process I would present to my nine year old son (if he wanted to learn more).

1. Assuming that TCP session is already complete, the application is forming the request (data) which is sent down to the layer 4. Layer 4 process places source and destination port numbers in the header (Pic. 1).

Pic. 1 - Application sends data to the Transport layer.

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

2. Transport layer sends the segment down to the layer 3 for processing. This payload ends up encapsulated in an IP header with the source and destination IP addresses added in the header (Pic. 2).

Pic. 2 - Transport layer sends the segment to the Internet layer.

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

3. The layer 3 sends the packet down to the layer 2 (Data-Link) for processing. Layer 2 adds its own header (here the Ethernet header) with the source and the destination MAC addresses (Pic. 3).

Pic. 3 - Internet layer sends packet down to Data-Link layer.

Then, this whole 'thing' is converted into bits and put onto the wire.

Now, we can see what happens when the bits are sent to the port of the switch to reach the destination computer. Let's bring back the Ethernet header to see what we find in it (Pic. 4).

Pic. 4 - Ethernet Header

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

In this header there are two pieces of information that switches use to build their mac-address-table (CAM) and make forwarding decisions. Those are: source and destination MAC addresses. And here is how it works.

Initially, the mac-address-table (aka CAM) is completely empty (Pic. 5).

Pic. 5 - Content Addressable Memory (CAM) initially is empty.

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

Sooner or later, some computers begin to transmit something across the network. In my example, the PC1 (source MAC address: 1111.1111.1111) begins transmission to PC3 (destination MAC address: 3333.3333.3333). Below is the sequence of events.

1. PC1 with the source MAC address of 1111.1111.1111 sends the Ethernet frame to the destination MAC address of 3333.3333.3333 (PC3).

2. SW1 receives the frame on port F0/1. It 'reads' the source MAC address and maps it to the receiving port in its CAM (like shown in the Pic. 6).

---

NOTICE
Switches learn MAC addresses by reading the SOURCE MAC from the INCOMING frames (going towards the switch) only. They do not learn anything when the frame leaves the switch.

---

Pic. 6 - SW1 learns dynamically 1111.1111.1111 by reading the source MAC address from the incoming frame.

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

3. SW1 then, reads the destination MAC address and will try to find the outbound port for that destination. Since 3333.3333.3333 has not yet been mapped to any port, the switch will performflooding (Pic. 7).

Flooding is the act of sending a frame out of all active ports except the port where the frame arrived. 

There are few reasons why switch decides to flood a frame:

• Switch does not know where the destination host is = unknown MAC address.
• The destination MAC address is broadcast: FFFF.FFFF.FFFF.
• The destination MAC address is multicast.

 Pic. 7 - SW1 Floods unknown destination MAC address 3333.3333.3333.

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

4. Computer with MAC address other than 3333.3333.3333 drop the incoming frames. PC3 is the destination of the frame so it further processes it (de-encapsulation). Meanwhile, the SW2 learns the source MAC address on the receiving port F0/12 and maps it in its CAM. Since, as of right now, it does not know where 3333.3333.3333 resides, it also floods the frame (Pic. 8).

Pic. 8 - SW2 is learning 1111.1111.1111 on F0/12 and flooding the frame.

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

5. PC3 (3333.3333.3333) responds the PC1 (1111.1111.1111). SW2 receives the frame sourced with 3333.3333.3333 on port F0/2. It puts this in its mac-address-table (CAM), mapping it to the inbound port F0/2. Next, it will read the destination MAC address in the frame (1111.1111.1111) and consults it with its CAM entries. It finds the outbound port F0/12 where this address has already been learned from the incoming frame. This time, the transmission is not flooded as SW2 has the mapping in the table. SW1 receives the frame on its port F0/12. It reads the source MAC address (3333.3333.3333) and maps it to the receiving port F0/12 in its CAM table. Then it looks at the destination MAC address (1111.1111.1111) and finds the outbound port which is F0/1. NO FLOODING THIS TIME on either switch! All illustrated in the Pic. 9.

Pic. 9 - Port-to-Port transmission in the reply as all MAC addresses in question have already been learned.

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

Since all computers 'speak' now and then, the switches will learn their MAC addresses from the incoming frames by reading the source MAC address field in the headers. They will populate the CAM and like depicted in Pic. 10.

---

NOTICE
All entries in the CAM table (mac-address-table) have a default aging timer which is 300 seconds (5 minutes). If the host do not refresh those entries by sending frames toward the port, the entries will be removed after 5 minutes. Of course, if the host transmits the frames again the incoming ports will map them again.

---

Pic. 10 - Content Addressable Memory (CAM) full.

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

In the next lesson we will look at Cisco Discovery Protocol.In lesson 11, we're going to put all the pieces together to show you the practical applications of what you have learned.