The Voice VLAN and Layer 1 troubleshooting

IP Phone connectivity to the network

In most enterprise networks today, almost every desk or cubicle has an IP Phone. IP Phones differ from analog voice phones because the audio signal is digitized and sent across the network as IP packets. That’s the basic idea behind Voice over IP (VoIP).

Since the phone is now a network device, it needs a network connection. On a typical desk, you’ll usually have:

• A PC (or laptop)
• An IP Phone

Both need access to the network, which means both need to connect to a switch.

Originally, the phone and the computer were each plugged into separate switchports. That works, but it doesn’t scale well: every desk with a computer and a phone consumes two switchports, and you can run out of ports quickly.

Modern IP Phones and switches solve this by conserving switchport usage. Most IP Phones include two RJ-45 ports:

• One port connects to the switch (often labeled LAN)
• The other port connects to the computer

(Image 103)

Image Title - Ports on an IP Phone

This setup is often described as “daisy-chaining” the computer through the IP Phone. Both devices reach the network using a single switchport. Conceptually, it looks like this:

(Image 104)

Image Title - Ports on an IP Phone

There’s one more important design issue to consider. If you place all IP Phones in the same VLAN as the computers, you create a larger, busier broadcast domain. That’s especially problematic for voice traffic because VoIP packets have very strict latency requirements.

For that reason, best practice is to separate phones and computers into different VLANs.

That leads to a key question: how can the phone and the computer be in two different VLANs if they share one physical switchport?

One option is to make the switchport a trunk. That works, but there’s also a more elegant approach supported by Cisco switches: the Voice VLAN feature.

The voice VLAN

On Cisco switches, you can configure a switchport as an access port for data traffic and also specify a separate VLAN as the “Voice VLAN.” In this model:

• The VLAN configured as the “Data VLAN” is the normal access VLAN. This is where the PC’s frames are handled.
• The VLAN configured as the Voice VLAN is where the IP Phone’s voice traffic is handled.

Even though the port is configured as an access port, there is a little “trunking” happening behind the scenes. The IP Phone behaves somewhat like a small switch.

Here’s what happens when the PC sends frames into the network:

• Since the PC is connected to the IP Phone, whenever it sends a Frame to the phone, the phone will pass those Frames along to the Switch unmodified.

• The Switch will receive the Frames from the PC as normal, as if they were connected directly and send Frames back unmodified as it normally does.

• The IP Phone will receive the untagged Frames from the Switch and pass them over to the PC

When the IP Phone sends frames into the network:

• The IP Phone will tag its Frames with the Voice VLAN so that when the Switch receives it, it knows that the Frame came from the IP Phone and belongs in the Voice VLAN.
• When the Switch needs to send Frames back to the phone, it will also tag those Frames with the Voice VLAN so that the IP Phone knows that those Frames are meant for the phone to process.

From the user’s perspective, this is seamless. It behaves as if the phone and computer were connected to separate switchports, but you don’t have to configure the switchport as a trunk.

A natural follow-up question is: how does the phone learn which Voice VLAN the switchport is using?

• You can configure the Voice VLAN manually on the phone.
• Or the switch can tell the phone using “Cisco Discovery Protocol” (CDP) (covered in more detail in later chapters).

Once the IP Phone learns the Voice VLAN, it can tag frames sourced by the phone with that VLAN.

From a configuration perspective, the steps are straightforward. First, create the VLAN you want to use as the Voice VLAN.

configure terminal
vlan 5

Optionally, you can give it a name, such as “VOICE-VLAN”, using the command:

name VOICE-VLAN

Sidenote

Naming your VLANs

It is not always required to add a name/description to your VLANs and it is only used to make the VLAN easier to identify for the person reading the config.

Don’t forget that this change will not take effect until you exit out of the VLAN Configuration sub-configuration mode by typing exit.

Then configure the interface as an access port and specify the Data VLAN where frames from the PC should be received. For example, if the Data VLAN is VLAN 2:

interface gigabitethernet 0/2 switchport mode access switchport access vlan 2

Now, while you’re still in interface configuration mode, specify the Voice VLAN. In this example, that’s VLAN 5:

switchport voice vlan 5

After you enter the “switchport voice vlan [VLAN ID]” command, the switchport can accept and interpret both:

• Untagged data frames from the PC (Data VLAN)
• Tagged voice frames from the IP Phone (Voice VLAN)

The image below shows the command sequence:

(Image 105)

Image Title - Configuring the Voice VLAN on a Switch

You can verify the configuration with:

show interface gigabitethernet 0/2 switchport

(Image 106)

Image Title - show interface gigabitethernet 0/2 switchport output

In the image above, the “Access Mode VLAN” (the Data VLAN for the PC) is VLAN 2, and the “Voice VLAN” is VLAN 5.

Layer 1 troubleshooting on an Ethernet LAN

When there’s a network problem, a common approach is to start at the bottom of the OSI (or “TCP/IP”) model and work upward.

If you manage a LAN and users report connectivity issues, one of the first checks is the Layer 1 status and counters on the switchport the endpoint uses. You can view these details with the **show interface [Interface Name] [Slot] / [Port #] **command.

Let’s examine the output from running:

show interface gigabitethernet 0/2

command on SW1:

(Image 106)

Image Title - show interface gigabitethernet 0/2 output on SW1

In the highlighted parts of the output, several fields can provide clues when something is wrong.

Duplex

In the example output, the Duplex mode is set to Auto. Switches can auto-detect duplex, but you may run into cases where duplex is explicitly configured with different modes on both ends and the settings conflict (for example, Full Duplex vs. Half Duplex or Auto). This creates a Duplex Mismatch.

A duplex mismatch can cause input/output errors on the switchport. If you run “show interface” repeatedly, you’ll typically see those counters increment. In the screenshot above, there’s no evidence of that, which is a good sign.

To avoid duplex mismatch issues, make sure duplex settings on both ends are either:

• Auto/Auto, or
• Manually set to the same mode (“Full” or “Half”) on both ends

Port Speed

Some switches support multiple Port Speed settings, often depending on what the connected device and cabling can support. For example, you can hard set a GigabitEthernet interface to 100Mbps for backward compatibility with a 100Mbps device.

Like duplex, speed can also be set to auto-detect. However, auto speed detection may not work as expected in some situations, or you may have a true speed mismatch between the two ends.

When speed is mismatched, users often experience poor network performance. You may also see input and output error counters increment when you repeat the “show interface” command.

Runts

A Runt is an Ethernet frame that is less than 64 Bytes. A normal Ethernet frame ranges from 64 - 1518 Bytes.

Runts are typically caused by:

• A faulty NIC card on a computer, or
• A bad Ethernet cable

Giants

A Giant is an Ethernet frame that is larger than 1518 Bytes.

Giant Frames are more commonly referred to as “Jumbo” Frames.

You’ll commonly see giants when the Maximum Transmission Unit (MTU) setting is configured incorrectly. If the MTU on one interface is set higher than the MTU of the receiving device on the other end of the link, the receiving device may report giants.

The standard MTU setting is 1500 Bytes.

Collisions

Collisions occur when devices attempt to transmit and receive simultaneously and frames interfere with each other.

If the collisions counter increments, that is an indication of a Duplex Mismatch. You typically see collisions where devices are running in Half-Duplex mode. It can also indicate a bad Ethernet cable.

Late Collisions

Late collisions occur when the switch doesn’t detect the collision until after the first 512 bits of the frame have already been transmitted.

This is typically caused by:

• A Duplex Mismatch, or
• An Ethernet Cable that has exceeded the maximum length