Lesson 13 - Layer 2 Connectivity Troubleshooting Part 3

By

Lesson 13 - Layer 2 Connectivity Troubleshooting Part 3

This lesson is the last one in the series on how to troubleshoot connectivity issues at the layer 2 of OSI model. Bear in mind, that these do not involve layer 2 technologies such as VLANs or Spanning-Tree Protocol, since we have not talked about those yet.
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 3
New installation as per Pic. 1 shows lack of connectivity between the two computers. Initial diagnostics performed revealed the following facts:
  • Switches are connected via fibre optics cable and the ports show proper status (interface is up, line protocol is up).
  • Computers have proper addresses and subnet masks assigned.
  • Cables connecting computers with switches have been tested and proved to be working correctly.
  • Computers reply to echo requests packets (firewalls disabled).
The technician who set up this new network calls you for help.

Pic. 1 - New design with connectivity problem
Icons designed by: Rajveer innovations 

Dealing with this trouble ticket we are going to collect the tools we used in the previous lessons trying to resolve this issue.

Step 1
First let's try to 'divide and conquer' (concept mentioned in lesson 11) by sending ping packets from PC1 to PC2. Before we do that though, we need to purge the existing ARP cache on PC1 and PC2 to have a fresh information. We do that by opening Command Line Interface window and typing: arp -d host-address (linux), or arp -d (MS Windows).
Test results: 
  • The pings timed out. No reply from PC2.
Step 2
Since the ARP cache entries age out relatively quickly (depending on which operating system you use), we need to quickly check what they contain Alternatively we can send large series of ping packets.
Test results:
  • PC1 does NOT contain expected mac-to-ip mapping. We expected to see
    192.168.1.2 at 00:1e:4f:b0:b2:fc. It is not there, though.
  • PC2 DOES contain the the right mac-to-ip mapping. It shows the following:
    192.168.1.1 at 00:50:bf:9c:45:6a    .
These are very interesting results, don't you think? Before we take the next step let's gather what we know so far.

Since the ping was initiated by PC1, it sent its ARP request broadcast message and that query must have been delivered to PC2. We can conclude that, based on the fact that we have cleared PC2's ARP cache in step 1, and it has the proper mapping now. PC2 did receive ARP request from PC1 and learned what MAC and IP address it uses. 

Step 3
We could omit that step, but we're curious if PC2 replies to the ARP request from PC1. We launch our 'wireshark' tool on PC2, ping again from PC1 to PC2 and capture all packets on PC2. What we discover in this packet trace is that PC2 has replied to ARP request with proper ARP reply unicast message back to PC1.

Step 4
Clearly, something between the computers (switches) does not work properly. It seems that we have some sort of unidirectional communication. What we need to establish is, where this unidirectional communication is taking place. We login to the SW1 and SW2 and issue the following commands ('x' here stands for switch number in Pic. 1):

SWx#show mac address-table interface f0/1
SWx#show mac address-table interface f0/24

Test results: 
  • SW1 learns source MAC address of PC1 (00:50:bf:9c:45:6a) on its Fa0/1 interface. This is expected.
  • SW1 does NOT learn MAC address of PC2 (00:1e:4f:b0:b2:fc) on its Fa0/24 interface. This is unexpected. It should learn it from the ARP reply sent by PC2.
  • SW2 learns source MAC address of PC2 (00:1e:4f:b0:b2:fc) on its Fa0/1 interface. This is expected.
  • SW2 learns source MAC address of PC1 (00:50:bf:9c:45:6a) on its Fa0/24 interface. This is expected.
This way, we have discovered that SW1 has unidirectional link towards SW2 (SW2 sends frames towards SW1 but the latter does not seem to receive those). Probably, the fiber optics connection does not work properly (grease, dirt, a strand is broken etc.).

One more time, this lesson illustrates how useful the commands and knowledge described in the previous posts, can be in real life scenarios. 

In my next post, I will show you how to log system messages so they can be analyzed later. System messages are invaluable pieces information in the process of troubleshooting networking issues.

Comments

Post a Comment

Popular posts from this blog

Lesson 27 - IPv4 Address Dissected - Part 1

By
Image
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: 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).  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.  Layer 2 addresses  -  flat  and most ofte
Read more

Lesson 21 - Spanning-Tree Protocol in Practice

By
Image
Lesson 21 - Spanning-Tree Protocol in Practice Previous post was designed to present in a nutshell the STP operation. However, without some practice it's just academic knowledge. I think it is a good idea to look at the same concepts using real equipment. Here goes... The below topology (pic. 1) uses redundant links which create the loops. Pic. 1 - Network Topology Icons designed by: Andrzej Szoblik -   http://www.newo.pl If there's one thing the administrator should do with such design, that would be configuring the root bridge. Typically, the most powerful switch in the center of the network plays that role. You do not want some access switch to be transmitting the frames between other switches. Access switches are designed to connect your computers to the network, and not to handle the majority of the traffic between the switches which root bridge must deal with. If you do not configure root bridge yourself, the switch with the lowest MAC address becomes th
Read more

Lesson 4 - Introduction to TCP/IP Layers

By
Image
Lesson 4 - Introduction to TCP/IP Layers In this lesson we take a sneak peek at the fundamentals regarding TCP/IP. This is one of the most important aspects to understand in order to follow the upcoming lessons. It is not my ambition to explain everything here as this would turn into a hefty book to read. You can find a lot of them on the market anyway. Instead, I will try to focus on some basic aspects of TCP/IP. They will constitute the minimum knowledge to help us understand how computers communicate. If you feel the urge to learn more on TCP/IP right now please visit the following site:  http://www.tcpipguide.com/free/t_toc.htm NOTICE! Familiarize yourself with ALL terms in red. They will be used throughout the classes. Introduction Computer communication follows some well defined rules and guidelines which we call  protocols . In order for the computers to exchange data they have to agree on using the same rules, otherwise they become incompatible. That was the case in t
Read more