Ticket #1

Define the problem

The first ticket we are going to face is for the PCs in the Sales department that cannot print. This
definition is way far from a punctual problem statement. After calling users, we clarify that they cannot
access printers, servers and file share on the network. Based on that, we know that it is unlikely to be a
print problem. Both users have the same problem, but the two PCs can communicate with one another.

It’s time for you to gather technical details. You ask the users to open the command prompt (from the
Start or with Win+R, then cmd for Windows users) and type ipconfig /all. We need to gather four
items: IP address, default gateway, subnet mask and Physical address (mac address). The two devices
having problem are Laptop0 and Laptop1, so here is an example of Laptop 0 output.

This is the output from Laptptop0

After talking with the user, here is what we have learnt.

 User 1 is using a laptop with IP 10.100.2.10 and subnet mask of 255.255.255.0. Its default
gateway is 10.100.20.1 and the MAC address is 00-D0-FF-66-C6-A1.
 User 2 is also using a laptop, with IP 10.100.2.11 and subnet mask of 255.255.255.0. Its
default gateway is still 10.100.20.1 and the MAC address is 00-E0-8F-E1-5D-8B.

From that, we know that IP configuration on the two laptops is correct. This is likely to be a network
issue, and we need to find where in the network the issue is.

Gathering more information

When we face this kind of problem, we need to find out where the isolation is. In other words, we know
that these two PCs are somehow isolated, but we need to know if they can reach at least their gateway,
or if there is a problem with L2 segmentation. So, we jump on the TopSwitchL3, which is the default
gateway, and we try to ping these two IP addresses. Both pings will fail.
 Both laptops are not reachable from their default gateway (TopSwitchL3).

Verify ARP cache

Since pings are failing, and we are in the same subnet, we need to verify if data-link layer is working as
expected. To verify data-link layer, we start by issuing show ip arp just after those pings. With this
command, we are checking if our switch was able to resolve the IP addresses to MAC addresses.

This is the content of the ARP table.

The command show ip arp presents you the content of the ARP table. In other words, you can find all
the bindings between IP addresses and MAC addresses the switch know. It may contain hundreds, or
even thousands of entries in a real-world switch performing routing. This command presents you several
columns, here’s their meaning.

 Protocol – Internet stands for IP, identifies the protocol that triggered the ARP request/response
process
 Address – IP address
 Age – Time in minutes since the entry is in the table
 Hardware Addr – MAC address associated to the IP address in the same row
  Type – ARP encapsulation type, generally “ARPA”, way out of scope for this article
 Interface – On which interface the switch learnt the MAC address

Entries that has no age (but a dash instead) are the ones associated switch’s IP addresses. Moreover, note
that this table is populated only from ARP requests the switch made. As as a result, ARP requests made
from other devices and passing through the switch will be ignored.

Checking the previous output, we didn’t find any MAC address but the ones of the local switch. This
mean that ARP requests have been failing, so we have a problem at the data-link layer or even below.

Verify MAC address table

The MAC address table on a switch remembers the association between a MAC address and a physical
port of the switch. The switch will populate that table and keep it up-to-date every time it receives an
ethernet frame. In other words, to see the MAC address of these laptops on the Top switch, laptops must
generate traffic and that traffic must reach the Top switch. Even ARP responses are traffic, but we don’t
know if our requests made it to the client. In case they didn’t, the device won’t have generated any
traffic. Just to be sure, jump on Laptop0 and ping the default gateway, 10.100.2.1.

Ping fails as expected.

Even if ping fails, our PC has generated some traffic, so we can check the ARP table on the Top switch
to see if they made it. We do it by typing show mac address-table from the privileged exec prompt.
 This is the content of the MAC address table.

We are looking for the MAC address of the Laptop0, which is 00d0.ff66.c6a1 (in Cisco notation).
Nevertheless, we cannot find this MAC address here. Now we are sure that communication with the
device doing routing is broken. We need to find if we can reach the peripheral switch, at least. Since we
don’t know to where in the network Laptop0 is, we need to check all the switches. Our objective is to
find a switch having that MAC address in the MAC address table.

Checking MAC address table on peripheral switches

To continue with our switch troubleshooting, we are going to connect to LeftSwitch. To do it, remain on
TopSwitchL3 in privileged exec, then type telnet 10.80.0.2 and enter the password as required. Then,
once again, issue show mac address-table and check the results.

This time we found the device we were looking for (highlighted).

Here we are! We found our device, it is connected to the FastEthernet 0/10 port on LeftSwitch. At this
point, we know that the connection between Laptop0 and LeftSwitch is working fine, but there might be
some problems between LeftSwitch and top switch. Before we check that, try to discover where Laptop1
is connected on your own. Just for the sake of learning, here’s the explanation of show mac address-
table output.
  Vlan – the VLAN associated to the MAC address, this comes from the VLAN associated to the
port
 Mac Address – the MAC address itself
 Type – How the MAC address was learnt, dynamic means from an ethernet frame, static means
it was hardcoded
 Port – Physical port this MAC address was seen on

Tip: if you don’t see the MAC address even there, it means the MAC address table aged out. Try again
the ping from the Laptop and, as soon as it finishes, immediately check the MAC address table.

Checking trunks
This problem involves two devices on the same VLAN, so it could be potentially a problem of that
VLAN. We issue show vlan brief to check if the VLAN exists, and we find that VLAN 102 is the one
for Laptops. Consequently, we need to check if this VLAN goes on the trunk toward TopSwitchL3. We
do that with show interfaces trunk.

VLAN 102 is missing from the trunk to TopSwitchL3.

This must be the problem. Therefore, all we need to do is enter in configuration mode, go under the
interface GigabitEthernet 0/1 and add the missing VLANs. Below, the needed commands.

interface GigabitEthernet 0/1

switchport trunk allowed vlan add 102
end

Once you typed that, try to ping the default gateway from both Laptop1 and Laptop2. This problem
prevented all the traffic from devices on LeftSwitch to reach the TopSwitch, the routing core. As a
result, all devices inside VLAN 102 on LeftSwitches, was isolated from everything else. Review this
configuration, and when you feel confident with what we did move to the next ticket.