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

Discussion in 'Cisco' started by SplkBarney, Aug 24, 2005.

  1. SplkBarney

    SplkBarney Guest

    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.
     
    SplkBarney, Aug 24, 2005
    #1
    1. Advertisements

  2. SplkBarney

    Anthrax Guest


    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--
    //////////////////
     
    Anthrax, Aug 24, 2005
    #2
    1. Advertisements

  3. SplkBarney

    SplkBarney Guest

    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!
     
    SplkBarney, Sep 1, 2005
    #3
  4. :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.
     
    Walter Roberson, Sep 1, 2005
    #4
  5. SplkBarney

    anybody43 Guest

    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:)
     
    anybody43, Sep 2, 2005
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.