Cisco Switching Basics

Switching is ubiquitous in modern LANs, and having a firm grasp of the essentials is vital for anyone seeking to manage networks effectively. Moreover, the Cisco exams require an in-depth knowledge of switches and switching, including access links, trunking, VLANs, Spanning Tree and layer 2 design. In this first post of a series, I shall cover the essentials of how switches operate to improve network performance at the data-link layer, with a focus on CCNA objectives.

The first thing to say about a switch is that it creates multiple collision domains. Since each device connects to a single port, there is no possibility of any frames colliding. This is in stark contrast to the older shared bus topologies involving backbone cabling and hubs. If a switch receives many frames all destined for the same device, it buffers them at the outgoing port to avoid collisions on the wire. So, as long as you connect a single device to each port, the devices and the switch ports can dispense with all collision detection logic and operate in full-duplex mode, such that the devices can both send and receive simultaneously.

On the older shared bus topologies, any frame sent would be read by all attached devices; only the device whose MAC matched the frame’s destination address would process it—the others would simply discard the frame. Switches do away with the need for all this unnecessary checking. A frame will go straight to the correct destination device and no other devices will even see it. An exception is a broadcast frame, whose MAC address is FF-FF-FF-FF-FF-FF. Switches always flood a broadcast out of all active ports, except the one it entered by. An active port is one to which a device is attached and which is not administratively disabled in some way. True, VLANs add another dimension to this, but I’ll cover that next time.

How do switches perform this selective distribution of frames? Let us explore the core concepts. A switch, out of the box, is ready to do its job. Just plug in the devices and it will work. Here is a simple network with three attached devices, whose MAC addresses are listed. Of course, each device is cabled into a separate switch port; I’ve placed a single arrow to the switch for the sake of neatness. The ports to which each device connects are shown:

When the switch starts up, its MAC address table is empty; it has no clue about which devices are attached to which ports. But, as frames are transmitted, the switch learns where devices (or, rather, MAC addresses) are. You can see the contents of the switch’s MAC address table quite easily. Just log into the console via a terminal and enter privileged EXEC mode, then type:

Switch# show mac-address-table

---Sample output---

Vlan        Mac Address       Type        Ports
----        -----------       ----        -----

At this point, no entries show up, since no traffic has been sent and no addresses stored. Let’s walk through a scenario: Peter sends a frame to Mary. Conceptually, the frame looks something like this:

Destination MAC Source MAC Payload
D8-F5-57-05-AA-78 C8-79-5F-44-24-60 IP packet

I’ve simplified the contents, since the exact makeup of an Ethernet frame isn’t our focus. What’s important here is the addressing information. When Peter sends this frame, it enters the switch via port Fa0/1, the port to which Peter is connected. Now the switch must decide where to send it. To do this, it looks at the destination MAC and tries to find a matching entry in its table. But, in this present instance, the table is empty. It therefore floods the frame, meaning that it sends it out of all active ports except the one it entered through. So, a copy of this frame will be sent from ports Fa0/2 and Fa0/3, to Paul and Mary respectively. Paul will discard his copy, since his MAC does not match the destination address; Mary will process her copy.

But this isn’t all that happens. The switch will read the source MAC from the frame, which is Peter’s, and place it into the MAC address table, along with the port it entered through. If we view the MAC table once more, we will see this entry:

Switch# show mac-address-table

---Sample output---

Vlan        Mac Address             Type        Ports
----        -----------             ----        -----
1           c879.5f44.2460          Dynamic     Fa0/1

Cisco’s IOS groups MACs into three sections, separated by dots, but this is purely aesthetic. You can safely ignore the Vlan field for now (by default, all ports are in VLAN 1). The MAC Address and Ports fields indicate this switch knows that Peter is found on port Fa0/1. The Type field is set to Dynamic, meaning the switch learned this MAC address automatically, as Peter sent a frame. It is possible to make manual entries in this table, in which case they would show up with a type of Static.

In the next phase, Mary responds to Peter with a frame of her own, looking something like this:

Destination MAC Source MAC Payload
C8-79-5F-44-24-60 D8-F5-57-05-AA-78 IP packet

This time, of course, the destination address is Peter’s and the source is Mary’s. The frame enters the switch via port Fa0/3, to which Mary is attached. The switch studies the destination MAC and tries to find a match in its table. A match is found: the device with a MAC of C8-79-5F-44-24-60 is located via port Fa0/1. At this point, the switch filters the frame, meaning that it forwards it only from Fa0/1. After all, there is no point in sending it anywhere else.

Next, the switch enters the source address, Mary’s, into its table, along with the port it entered through, Fa0/3. If we confirm this, we will see:

Switch# show mac-address-table

---Sample output---

Vlan        Mac Address             Type        Ports
----        -----------             ----        -----
1           c879.5f44.2460          Dynamic     Fa0/1
1           d8f5.5705.aa78          Dynamic     Fa0/3

In our simple topology, the only device not to have an entry is Paul; that is because he has not sent any frames, and a switch can only dynamically build its table from the source addresses of sent frames. Although it’s rarely done in the wild, let’s add a static entry for Paul, by entering global configuration mode and employing the mac-address-table command:

Switch(config)# mac-address-table static 24a4.a57f.b6b9 vlan 1 interface fa0/2
Switch(config)# do show mac-address-table

---Sample output---

 Vlan        Mac Address             Type        Ports
 ----        -----------             ----        -----
 1           c879.5f44.2460          Dynamic     Fa0/1
 1           24a4.a57f.b6b9          Static      Fa0/2
 1           d8f5.5705.aa78          Dynamic     Fa0/3

That’s all there is to it: just indicate it’s a static entry and give the MAC, VLAN and port. In case you’re unfamiliar with the command do show-mac-address-table, it’s just a bit of syntactic sugar. Normally, you have to be in privileged EXEC mode (also called enable mode) to issue show commands. But, when you’re configuring devices and their interfaces, you might want to issue a show command without exiting configuration mode expressly for that purpose; simply prefix the show command with the word do.

At this point, the switch’s table is complete. Any frame sent between these three devices can be filtered and forwarded appropriately. The only time a frame needs to be flooded is when that frame is a broadcast. Things are now working efficiently at the data-link layer.

Let’s talk about timings. As we’ve seen, when a switch learns a source MAC automatically, it places the address into its table with a type of dynamic. But such entries do not stay around forever. Imagine that Peter stops sending frames: perhaps he’s gone to lunch. After a default period of 300 seconds (5 minutes to you and me), the switch will remove the entry if it hasn’t heard from Peter. This is called aging. Since switches have only a finite amount of memory, this prevents the table from becoming cluttered with addresses for inactive devices.

The system works like this: when Peter first sends a frame, the switch enters his MAC into its table, along with a timestamp indicating when this information was learned. When Peter sends subsequent frames, the switch confirms the entry and updates the timestamp. Periodically, the switch checks the timestamp and, if 300 seconds have elapsed since it was last updated, it removes the entry. This neatly handles the scenario wherein Peter is still connected, but is not sending traffic. If Peter is switched off, or physically disconnected, the switch detects this and removes the table entry right away. Static entries are never timed out.

Let’s wrap up with a couple more commands and variations. To remove an entry from a switch’s MAC table, go into configuration mode and enter clear mac-address-table static | dynamic address. As always, an example:

Switch(config)# clear mac-address-table static 24a4.a57f.b6b9

This will erase Paul’s statically configured entry. Issuing clear mac-address-table static | dynamic on its own will remove all static or dynamic entries. Furthermore, you can remove a dynamic entry by giving its interface instead:

Switch(config)# clear mac-address-table dynamic interface fa0/1

This will remove Peter’s entry. The show mac-address-table command can also use static or dynamic parameters to see only those particular entries; e.g. show mac-address-table dynamic.

Next time, I’ll go over the essentials of switch configuration.

Leave a Reply

Your email address will not be published. Required fields are marked *