Seeing unexpected skinny heartbeats when sniffing IP phone's network traffic

Well, as Kevin says it does seem strange (in Netpro). Allegro (is an app developed by cicso for a pc to get info from the ip phone) does precisely what you say, it sees the phone but only for troubleshooting purposes. How is your 3500 port configured??

The latest theory on this is that it is Unicast Flooding. This is supposedly a normal occurance when the switches MAC table gets filled up. When the switch has a packet for a MAC, but can't find the MAC in its table, it sends it out all its ports; not as a broadcast packet, but essentially a broadcast because it is sent out every port. We have looked at the MAC table in both switches and they are far from being full, so I don't know about this being the cause. I am continuing to look at the switch settings and Unicast Flooding to see if I can find an answer.

Thanks for your responses!

In article , SplkBarney wrote: :The latest theory on this is that it is Unicast Flooding. This is :supposedly a normal occurance when the switches MAC table gets filled :up. When the switch has a packet for a MAC, but can't find the MAC in :its table, it sends it out all its ports; not as a broadcast packet, :but essentially a broadcast because it is sent out every port. We have :looked at the MAC table in both switches and they are far from being :full, so I don't know about this being the cause.

That same kind of flooding occurs when the tables are not full but the MAC is unknown. Since unmanaged switches do not have IP addresses, they can't buffer packets for unknown hosts, send out ARP requests, and receive replies that implicitly tell them which port to use [by seeing the destination MAC as a packet source on that port.] Thus unmanaged switches send unknown MACs to every port in the same VLAN (and very few unmanaged switches have more than one VLAN!), expecting that eventually there will be a reply and that it will learn the appropriate port at that time.

This algorithm does not, however, work at all well if you have asymmetric links -- if the port on which the MAC is seen as the source is not the port that you have to transmit to in order to reach the MAC, then packets are going to get lost. Spanning tree helps -some- on this, but traditional spanning tree is not designed to detect undirectional links (e.g., broken wire, faulty connector, odd VLANing).

Cisco has a Unidirectional Link Detection Spanning Tree extension; it is proprietary, though. Cisco is, if I recall, offering to license it "for low cost", but I don't have the foggiest what Cisco would consider low cost.

Hello,

Re: OP If these unicast packets are infrequent then it may be normal operation

as discussed however if you are seeing a lot of traffic then you may be experiencing the problem described in:

1. This assymetric route behaviour will occur irrespective of whether the switch is managed or not. All you need are 'Learning-forgetting bridges'. i.e. an 802.1d bridge.

1. Spanning tree does not help this at all.

2. Also I cannot see that assymetric routing is relevant to the discussion either.

Trying to help out:)