Understanding networking concepts

Category: ARP

ARP protocol

Layer 3 Switches

Trying to explain how a layer 3 switch works is, in my opinion, a very useful exercise when you are starting to learn basic switching and routing concepts. It is an opportunity to review both the layer 2 switching logic and the layer 3 routing logic.

Let’s review the operation of a L3 switch using an example based on the following simple topology:

If the switch receives a frame from PC1 destined to PC2, since both PCs reside on the same network segment (VLAN 10), the switch will behave as a L2 switch while forwarding the receiving frame. It will look for PC2 MAC address in its MAC address table and the frame will be forwarded out the port connected to PC2 (assuming the PC2 address is found in the MAC table).

In this first forwarding scenario, if the destination MAC address belongs to another host in the same VLAN where the receiving port resides, the corresponding layer 2 forwarding process is triggered depending on the type of incoming frame (known unicast frame, unknown unicast frame, broadcast or multicasts).

Now let’s see what happens when PC1 sends a frame to a device in another subnet, for example PC4. In this case, a layer 3 device is needed to communicate hosts in different VLANs. PC1 can’t send the frame directly to PC4 because the destination IP resides in another network. Therefore, PC1 will send the frame to its default gateway, which corresponds to the layer 3 switch in the topology. When the L3 switch receives the frame, it realizes the destination MAC address corresponds to its own MAC address in that VLAN and the layer 3 forwarding process is triggered. Since the frame is destined to the switch itself, the switch acts like an end device in this scenario and cannot behave like a L2 switch. The switch takes the role of a router and performs the following steps to process the incoming frame:

  1. The IP packet is de-encapsulated from the received data-link frame.
  2. The destination IP address is compared to the L3 switch routing table to find a route that matches the destination address.
  3. If a route is found, the packet is encapsulated in a new data-link frame and the frame is transmitted through the outgoing interface specified in the matched routing table entry. If no route is found, the packet is discarded.
  4. In order to send the new frame, the switch must find the destination MAC address using its local ARP cache or through an ARP request.

If the outgoing interface identified at step 3 is a routed interface, the new frame is forwarded out the physical routed interface. If the outgoing interface is a Switch Virtual Interface (SVI), the forwarding process is a bit more complex.

An SVI is a logical interface inside the switch that is bound to a VLAN and allows the switch to send IP packets to that VLAN like another IP device. You can think of an SVI like a physical Netword Card Interface (NIC) of a PC, but the SVI is virtual (which means it is build by software). The SVI allows the switch to send and receive IP packets through the physical ports associated with the corresponding VLAN.

If the outgoing interface identified by the routing table is an SVI, out which physical port is the frame forwarded? The answer to this question depends on the destination MAC address:

  • If the destination MAC address is a broadcast or multicast address, the frame is forwarded out all physical ports assigned to the outgoing VLAN.
  • If the destination MAC address is a unicast address (learned through the ARP process or find in the ARP table), the switch must look for the destination MAC in its MAC address table, like a regular L2 switch. The matched MAC table entry will identify the outgoing physical port that will be used to forward the frame.

During my studies for my CCNA exam preparation, I used to review all these steps and concepts involved in the operation of a L3 switch to make sure I really understand all the fundamentals of routing and switching: MAC address tables, ARP tables, routing tables, layer 2 forwarding logic, SVIs, layer 3 routing logic, etc. In future blog posts, I’ll make a deeper review of some of those specific switching and routing topics.

A unicast ARP request?

After analyzing some Wireshark traffic captures, I noticed that some ARP requests were broadcast frames, as expected, but I randomly found some ARP requests that were unicast frames. I thought ARP requests were always broadcast frames, but I was wrong.

Let’s do a quick review of the ARP protocol using a simple topology in Packet Tracer:

Imagine that PC1 (10.10.10.1) wants to access the Web Server (10.10.10.3). PC1 will generate an IP packet that needs to be encapsulated inside an Ethernet frame. To create the Ethernet frame, PC1 needs to know the MAC address of the Web Server. Now is when the ARP process come into play. PC1 will send an ARP request asking for the MAC address of 10.10.10.3. Since the destination MAC address is unknown, this frame must be a broadcast frame and it will be received by all the devices in the LAN. Only the device with IP 10.10.10.3 (the Web Server) will reply with its MAC address.

The Wireshark capture shown below corresponds to an ARP request. In the Ethernet section of the capture, we can see that it is a broadcast frame (the destination MAC address is FF:FF:FF:FF:FF:FF).

The next Wireshark capture is also an ARP request, but the destination address is a unicast MAC address instead of a broadcast address.

What is, then, the purpose of a unicast ARP request if the destination MAC address is already known? I found the answer of this question in the RFC 1122 – “Requirements for Internet Hosts – Communication Layers”. Section 2.3.2.1 describe four mechanisms for flushing out-of-date ARP entries. One of the mechanisms is called “unicast poll” and is described as: “Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls“.

Following the example shown in the previous capture, the sending host has an entry in its ARP table that matches the IP 192.168.18.31 with the MAC address 60:f2:62:0f:50:a5. In order to verify if the MAC address is still valid, a unicast ARP request is sent using the MAC address recorded in the ARP table. If the destination host is still using that MAC address, it will reply with an ARP reply message. If no reply is received, it means that the MAC address is no longer in use and the sending host will delete the corresponding ARP table entry.

One final observation. In this particular capture of a unicast ARP request, the “Target MAC address” field is filled with a MAC address of all zeros (00:00:00:00:00:00). However, it is possible to find ARP requests that also use the MAC address of the destination host in this field. For example, the capture shown below:

Does it depend on the particular implementation of the ARP protocol running on the sending host? Or maybe another protocol feature? I’ll keep digging into it.

© 2022 Networking Tales

Theme by Anders NorenUp ↑