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

Seeing unexpected skinny heartbeats when sniffing IP phone's network traffic
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
Seeing unexpected skinny heartbeats when sniffing IP phone's network traffic SplkBarney 08-24-2005
Posted by SplkBarney on August 24, 2005, 1:08 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
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.



Posted by Anthrax on August 24, 2005, 4:24 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
On 8/24/2005 3:08 PM,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?
> (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.
>


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??


--


2nd Law of Thermodynamics: Chaos will Reign.

///////////////////
--Anthrax--
//////////////////


Posted by SplkBarney on September 1, 2005, 10:03 am
If you were  Registered and logged in, you could reply and use other advanced thread options


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!



Posted by Walter Roberson on September 1, 2005, 6:01 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
: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.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers


Posted by on September 2, 2005, 7:11 am
If you were  Registered and logged in, you could reply and use other advanced thread options
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:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml

Re: Walter
Sorry, however as far as I can see:

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.

2.
Spanning tree does not help this at all.

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

Trying to help out:)



Similar ThreadsPosted
Monitoring (sniffing) switch traffic - Back to basics February 26, 2005, 12:30 am
skinny nat problem February 7, 2007, 3:47 am
Cisco 7960 rebild (skinny) October 11, 2005, 12:24 pm
Unexpected exception... October 26, 2005, 9:03 am
Unexpected DOH error September 25, 2007, 4:58 pm
IP-Phone 7960: unexpected reboot January 5, 2005, 9:29 am
VPN log - Received Unexpected InitialContact Notify (PLMgrNotify:886) April 20, 2005, 5:46 pm
Configure switch for sniffing October 3, 2006, 12:56 pm
free network traffic generator February 9, 2006, 6:40 pm
Network traffic problem ---- packet loss October 11, 2005, 8:01 pm

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map