cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1175
Views
0
Helpful
3
Replies

Voice broadcasts leaking in data vlan

jeremygenicot
Level 1
Level 1

Hello,

I'm separating voice and data traffic on a LAN by using the "switchport voice vlan" command. All ports are configured with this command.

However, while sniffing traffic on a pc directly connected to a switchport (without phone inbetween) we can see arp-broadcasts originating from the voice-vlan.

This behavior is strange to me since I can see voice traffic on a host in the data vlan.

The used setup:

port config:

interface FastEthernet1/0/x

switchport access vlan 1

switchport mode access

switchport voice vlan 2

test setup:

PC connected to Fa1/0/1 (has ip address in data vlan 1)

Cisco Phone connected to Fa1/0/2 (has ip address in Voice vlan 2)

while capturing traffic on the PC we see arp requests originating from the Cisco-phone on Fa1/0/2 (clearly voice vlan traffic) the arp requests the owner of the default gateway-IP.

In my opinion the traffic should be seperated since it's not acceptable to see voice traffic on a data segment (like demonstrated here).

Question is, can someone explain this behavior and does an alternative exists to prevent voice-arp-broadcasts arriving on the data vlan (while keeping the voice vlan functionality).

Best regards,

Jeremy

3 Replies 3

Peter Paluch
Cisco Employee
Cisco Employee

Jeremy,

Interesting issue. However, how is the PC port Fa1/0/1 configured? Is it also configured with a voice VLAN? If yes then the behavior is understandable, as it basically belongs to the data VLAN as well as into voice VLAN.

Also note that until the phone starts marking its frames with 802.1Q tag (until it learns by CDP or by static configuration what voice VLAN it belongs to) it will send its frames untagged.

Try having a better look on the conversation between the phone and the switch (preferably using a hub so you can see the 802.1Q tags as they really are - the SPAN is not always able to copy the 802.1Q tags of captured frames) and check whether the ARP requests that appear to be leaking into the data VLAN are already 802.1Q tagged with the proper voice VLAN number.

Best regards,

Peter

Hi Peter,

thanks for your answer.

The Fa1/0/1 port is indeed configured with a voice vlan, I'm capturing traffic without SPAN, directly from the nic.

802.1q-tags are not visible, however it is possible that they are stripped by the nic.

I'm also afraid that the switch doesn't make a seperation between ports with only data-hosts connected and ports with voice/data-hosts connected.

However since it's one of the main incentives of creating voice vlans (seperating voice and data traffic) I wondered if there was some way to avoid voice broadcasts arriving on ports without voice-equipment.

Kind regards,

Jeremy

Jeremy,

It is indeed possible that the 802.1Q tags are stripped by the NIC. Are you sniffing under Windows or under Linux? At least under Windows, the Intel (and possibly other) NICs strip the 802.1Q tags so you do not really see them in the sniffer.

I would say that it is right because of the voice VLAN configured also on your PC port that you see those leaked broadcasts. Make a simple test: remove the voice VLAN from the Fa1/0/1 and make it simply a normal access port without any auxiliary VLAN. The leaking should stop.

The idea of voice VLANs is to separate the voice and data traffic as soon as possible if a single port is used both for an IP phone and a PC. In this case, the separation starts on the IP phone itself - it will forward the PC's frames untagged and it will generate and receive tagged frames for itself. If you do not plan connecting an IP phone into a switchport then there is no reason to define a voice VLAN on it.

You are correct that the switch does not do any kind of discovery to see if a dedicated voice equipment such as an IP phone is connected to a switchport, at least not for the purposes of forwarding frames. There is a command "mls qos trust [cos] cisco-phone" or "mls qos trust [cos] cisco-softphone" that conditionally activates the trust of priority marking if the IP phone is connected (using the CDP messaging). However, I do not think this command also applies to forwarding frames within the voice VLAN and I have not seen any similar command regarding that particular function.

So the idea is basically: if you do not have an IP phone or an IP softphone on a port, do not configure the voice VLAN on it. If there is a phone, then define the voice VLAN. The phone will filter out the voice traffic and it will not forward it to the PC.

I'm not sure if this answers your question so please feel free to ask further.

Best regards,

Peter

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card