Seeing unexpected skinny heartbeats when sniffing IP phone..

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

I am doing research to see if an application on a computer that is
connected to the network port of an IP phone (7940/60/70/etc) can "see"
the attached phone. I am doing this by using a packet sniffer to look
for skinny heartbeats between the phone and CallManagers in a cluster.
I am seeing the skinny heartbeats for my attached phone, but I am also
seeing heartbeats and acks between other phones and other CallManager
clusters. These are TCP packets with IPs and MACs that do not match my
phone or PC. I don't understand why I am even able to see these
packets. My phone (and the others that I see heartbeats from) are all
attached to a 3548 switch which is connected to a core Catalyst 6000
switch.

Does anyone know what could be causing my sniffing application
(Ethereal) on my PC to be able to see TCP traffic that is not even
directed to my phone or PC?
(There are no SPAN sessions on the switch. There is no hub between my
PC, the phone, and the switch. This is recreatable and persistent.) I
can provide additional information if needed.

Thanks in advance.

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

SplkBarney wrote:
> I am doing research to see if an application on a computer that is
> connected to the network port of an IP phone (7940/60/70/etc) can "see"
> the attached phone. I am doing this by using a packet sniffer to look
> for skinny heartbeats between the phone and CallManagers in a cluster.
> I am seeing the skinny heartbeats for my attached phone, but I am also
> seeing heartbeats and acks between other phones and other CallManager
> clusters. These are TCP packets with IPs and MACs that do not match my
> phone or PC. I don't understand why I am even able to see these
> packets. My phone (and the others that I see heartbeats from) are all
> attached to a 3548 switch which is connected to a core Catalyst 6000
> switch.
>
> Does anyone know what could be causing my sniffing application
> (Ethereal) on my PC to be able to see TCP traffic that is not even
> directed to my phone or PC?

Probably the fact that Ethereal is sniffing with its interface put in
"promiscuous mode", and your switches are (mis-?)configured to work as
non-switching hubs...

Enzo

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

SplkBarney <david.barnish@spanlink.com> wrote:
> I am doing research to see if an application on a computer that is
> connected to the network port of an IP phone (7940/60/70/etc) can "see"
> the attached phone. I am doing this by using a packet sniffer to look
> for skinny heartbeats between the phone and CallManagers in a cluster.
> I am seeing the skinny heartbeats for my attached phone, but I am also
> seeing heartbeats and acks between other phones and other CallManager
> clusters. These are TCP packets with IPs and MACs that do not match my
> phone or PC. I don't understand why I am even able to see these
> packets.

Are they directed to broadcast addresses?

miguel
--
Hit The Road! Photos from 36 countries on 5 continents: http://travel.u.nu
Latest photos: Queens Day in Amsterdam; the Grand Canyon; Amman, Jordan

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

In reply to Enzo's message:
I am sniffing in promiscuous mode so I can see the traffic going to and
coming from the attached IP phone. I do not believe the switches are
misconfigured. They are not acting like hubs (except in the cases where
I am seeing these misdirected packets).

In reply to Miguel:
The packets that I am seeing are not broadcast packets. They are
directed to specific IP addresses and MACs that do not include the IP
phone or the PC I am using for sniffing. I am seeing other broadcast
traffic, but I am ignoring that.

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!

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

SplkBarney <david.barnish@spanlink.com> 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. I am continuing to
> look at the switch settings and Unicast Flooding to see if I can find
> an answer.

If the MAC table is not full then this seems unlikely. Also, unless there is
nothing else happening on your network, you would see other traffic also
coming out all interfaces, not just the VoIP stuff.

miguel
--
Hit The Road! Photos from 36 countries on 5 continents: http://travel.u.nu
Latest photos: Queens Day in Amsterdam; the Grand Canyon; Amman, Jordan

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

We are seeing a smattering of other TCP packets that I shouldn't be
able to see. I've been concentrating on the skinny heartbeats because
that is what I was more interested in.