• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

VoIP

Same Data and Voice VLAN

12/24/2014 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Yes, it’s not the best practice to put both data and voice traffic in the same VLAN and subnet, but I’ve recently encountered it in production and caused us some head scratching scenario. While it was probably best to redesign the whole thing since it doesn’t follow best practices, it was not going to fly in this case.

Configuration

The stack’s configuration was copied from an existing Catalyst 3750-X production switch. For the most part, it’s a basic configuration that you will encounter in a lot of production switches. Some of the configurations are the following: AAA, BPDU Guard, PortFast, Storm Control, Access and Voice VLAN (same VLAN number), etc. The 3750-X stack’s configuration was not changed for more than two years. There were no issues or complaints from the clients so it was pretty much safe to copy the configuration to the new Catalyst 2960-X stack. This stack will be the new location of the same users of the 3750-X stack – just moving to a new location.

Issue

The desktop support guy started hooking up Avaya phones and desktops to the switch and noticed that all desktops and phones connected to switch 1 (two in a stack) were not communicating to the network. The desktops and phones weren’t getting IP addresses, but once he connects to switch 2 everything started to work. The interface configurations on both switches were configured the same but for whatever reason it wasn’t working. I rebooted switch 1 and all the desktops and phones connected to it started communicating to the network.

Several hours later, the desktop support guy said that everything connected to switch 2 stopped working. I decided to reboot the whole stack at this point. Before I rebooted the stack, I noticed that one of the switches was in EX4 and the other one was in EX5. Normally, there would be a version mismatch error when there are two different IOS installed and shouldn’t join the stack, but on this particular instance both switches were in the stack. I decided to upgrade the EX4 switch to EX5 since that is the latest code anyway and we’re making that as a standard IOS.

After upgrading and rebooting the stack, I still noticed that computers and phones on switch 2 were not communicating. At that point, our client was now panicking because they were not compliant with their contract to their client. That said, we decided to replace the whole stack with new switches. The switch replacement worked for a while but the issue came back which we kind of suspected anyway – we were not fully convinced that it would resolve the issue. Since we’ve been using the Catalyst 2960-X with EX5 code for several months now, we know it works just fine with our standard configuration. The only thing different with this stack and others was the same voice and data VLAN. While the switch is solid, we’ve hit bugs starting with EX1 all the way to EX4. That said, I begun to suspect that we might be hitting a bug in EX5, so I decided to open a TAC case while it was on the working state.

Troubleshooting

A Cisco TAC engineer contacted via e-mail me to troubleshoot the issue since it was working at the time I opened the case. As usual, the first thing I had to give them was show tech output. I still do not know why I do not include that by default when opening a case.  Anyway, as mentioned, the issue came back and I engaged the TAC engineer as soon as I was informed it stopped working.

The TAC engineer started checking some stuff up to try diagnose the issue. The first thing he mentioned is the voice and data VLAN being the same and it’s not a recommended practice. I agreed with him but I also reminded him that we have this deployed in two locations and were working fine using Catalyst 3750-X. He even asked me to connect to those switches so he could see it in his own eyes.

Upon issuing few show commands, we finally found some clue on what the problem was. There was no spanning tree instance on the interfaces where the phones and desktops were connected to. It acted as if there was nothing connected to the port even though the switch sees something connected to those ports. He decided to take out the switchport voice vlan vlan-id  and the desktop started pinging and spanning tree instance on the port showed forwarding.

While the configuration worked for desktops, I still needed the phones to work. Having only switchport access vlan vlan-id on the port won’t work with the phones even if I separated phones and desktop connections. That said, we needed a way to configure the port for the phones to also work. At the time, I only knew two ways of configuring a port with phones and data connected to the switch: configuring access vlan and voice vlan commands on the interface and configuring the interface as a trunk with native VLAN set for data. Essentially, they will act the same thing so we didn’t want to do that.

Upon him talking to his colleague(s) and probably done his research, he came back and said we’re going to try the switchport voice vlan dot1p command. That solved the issue! While he explained what the command did, I was not quite happy with his explanation because I felt it was incomplete, so I decided to read the configuration guide and was quite disappointed it didn’t have more information about it.

If you do a search, you will find plenty of information about the command, which I hoped the configuration guide would have. From what I’ve gathered both online and from the TAC engineer, if configured, the switch will instruct the phone to use VLAN 0 for its voice traffic and also mark its voice traffic with their proper CoS values, 5 or 3 depending on what traffic it is. Once the frame is received, the voice traffic with VLAN 0 will be accepted and drop the voice and data traffic in the same VLAN configured on the port – access vlan command.

Thoughts

While the dot1p configuration worked, I still would’ve preferred to have two different VLANs for both data and voice which is the standard configuration anyway in our environment. But, for whatever reason, they decided to design it this way and it’s going to stay that way. Maybe when it breaks that’s when they are going to decide to separate it, but at this point we had to choose the battle we were going to fight.

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Cisco IP Phone Boot Process

11/27/2011 By Andrew Roderos Leave a Comment

Knowing how something works is always beneficial. Having said that, I believe network engineers should know the boot process of the Cisco IP phones so they can assist with troubleshooting.

  • The Cisco IP phone connects to an Ethernet switchport. If the IP phone and switch support PoE, the IP phone receives power through either Cisco-proprietary PoE or 802.3af PoE.
  • As the Cisco IP phone powers on, the Cisco switch delivers voice VLAN information to the IP phone using CDP as a delivery mechanism. The Cisco IP phone now knows what VLAN it should use.
  • The Cisco IP phone sends a DHCP request asking for an IP address on its voice VLAN. The router connecting to the voice VLAN receives this DHCP request and, through the ip helper-address command, forwards the request directly to the DHCP server.
  • The DHCP server responds with an IP address offer. When the Cisco IP phone accepts the offer, it receives all the DHCP options that go along with the DHCP request. DHCP options include items such as default gateway, DNS server information, domain name information, and so on. In the case of Cisco IP phones, a unique DHCP option is included, known as Option 150. This option directs the IP phone to a TFTP server (you learn more about this in the upcoming section, “Configuring a Router-Based DHCP Server”).
  • Once the Cisco IP phone has the IP address of the TFTP server, it contacts the TFTP server and downloads its configuration file. Included in the configuration file is a list of valid call processing agents (such as Cisco Unified Communications Manager or CME agents).
  • The Cisco IP phone attempts to contact the first call processing server (the primary server) listed in its configuration file to register. If this fails, the IP phone moves to the next server in the configuration file. This process continues until the IP phone registers successfully or the list of call processing agents is exhausted.

I hope this has been helpful and I thank you for reading!

Reference

CCNA Voice Official Exam Certification Guide

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use