Cisco IP phones deregistering/registering sporadically (STP switch problem)....

Discussion in 'Cisco' started by wr, May 21, 2004.

  1. wr

    wr Guest

    The source of the problem is related to a spanning tree
    issue, coupled with a bad phone/switchport configuration.

    Spanning-tree: I have a core-access layer network model. The
    distribution layer is combined with the access or core,
    depending on how you look at it. All access layer switches
    are uplinked to the core switch pair redundantly. The problem
    source is related to the way in which this redundant
    connection works. I have sets of access layer switches daisy-
    chained via their gig ports. So, for example the top access
    switch in the stack goes to the second one down, etc. Both
    the bottom and top switches have one uplink to redundant
    cores.

    These uplinks and daisy chain switch ports are nothing more
    than gig switchports. They are not special stacking ports, or
    real stacking ports, like you might see in 3com switches or
    newer cisco switches. (Yes cisco marketing has bastardized
    this term). 3750 switches with the wire-speed stacking cable
    (in the back) have real staking ports. 3com 3300's with the
    stacking module have real stacking ports. Cisco 3550's with
    two gig uplinks don't have real stacking ports. In my case, I
    am relying on the 3550's uplink ports kind of as my stacking
    ports at the access layer.

    So how does this cause the problem? Spanning tree is designed
    to have maximum switch hop counts (bridge hops). This is
    either 7 or 14 depending on the definition (I am still
    confused on this piece). So as you add more switches into
    your access "stack", and if spanning tree is configured
    correctly, you will get a natural division in the stack, with
    the top half going to the core on the top switch core uplink,
    and the bottom half going to the core on the bottom switch
    core uplink. If you add in another stack, the same behavior
    will occur. Your config may look like this:


    ----switch11----switch12-- | --switch13----switch14----
    | |
    | |
    -------------- --------------
    (core1---------------core2)
    -------------- --------------
    | |
    | |
    ----switch21----switch22-- | --switch23----switch24----

    So to get to from a pc on switch23 from to a pc on switch12,
    you may have to traverse 5 hops (sw12->sw11->core->sw24-
    >sw23). Note the break on switch 12/13 and switch 22/23. To

    get this break, you have to run STP on the access switches.
    Under failure scenarios, and/or if you run STP only on the
    core switch, your network may look like this. (note: breaks
    in switch14 and switch 21 uplink.

    ----switch11----switch12-------switch13----switch14- | -
    | |
    | |
    -------------- ---------------
    (core1---------------core2)
    -------------- --------------
    | |
    | |
    - | -switch21----switch22-------switch23----switch24----

    So what went from a nice network, just went to a bad one. To
    get to from a pc on switch14 from to a pc on switch21, you
    may have to traverse 9 hops (sw14->sw13->sw12->sw11->core-
    >sw21->sw22->sw24->sw23).


    9 hops from a repeater (bridge) perspective is not that bad,
    but from an STP perspective is not that good. STP starts to
    break down because it cannot converge. So the alternative is
    to take STP off of the access switches, and live with 9
    switch hop counts, because the break will be at one of the
    core uplinks. You get no load balancing on the uplinks in
    this scenario. You also don't get any protection from a user
    short-circuiting one of the access layer switches by uplink
    to it twice from two cube drops.

    The problem only worsens as you add more switches into the
    stack, such as switch15, switch16, etc. The problem may also
    worsen if you have rouge switches plugged into your access
    layer and no bpdu guard enabled on all access switchports. I
    like the idea of keeping STP on the access switches but
    cannot handle STP not converging (or recalculating) during
    peak periods of the day.

    Phone Switchports: It turns out that phone switchports at the
    access layer are a bit tricky. Since the phone is essentially
    a switch doing trunking, it could pose problems due to its
    desire to trunk any vlan supported on that switch. For
    example, if I have 10 vlans on the switch, and 1 is PC data
    and 1 is phone voice, and follow a simple switch port config,
    vlan trunking will occur and traffic will not be pruned. Here
    is switchport config before and after:

    interface FastEthernet0/1
    switchport trunk encapsulation dot1q
    switchport trunk native vlan 303
    switchport mode trunk
    switchport voice vlan 304
    spanning-tree bpduguard enable
    ===========
    interface FastEthernet0/1
    switchport trunk encapsulation dot1q
    switchport trunk native vlan 303
    switchport trunk allowed vlan 303,304
    switchport mode trunk
    switchport voice vlan 304
    storm-control broadcast level 15.00
    spanning-tree bpduguard enable

    Note: I have manually allowed VLAN's in the after scenario.
    Without this a sh span showed this port was forwarding all
    vlan traffic. Even though there was no node on the other side
    support that vlan traffic. What this means is your phone port
    essentially forwards all VLAN's broadcasts. Probably not a
    big deal, but seems like its worth stopping through vlan
    filter. The broadcast config item is just something extra i
    added in for safety. this doesn't actually stop the sending
    of BC's out the port. the spanning-tree bpduguard enable
    command disables port if it receives a bpdu--prevents port
    from becoming a root uplink accidentally.

    Anyone have any comments, ideas on how to properly configure
    a port or access switch to meet all requirements. thanks, will
     
    wr, May 21, 2004
    #1
    1. Advertising

  2. wr

    Andrew Riley Guest

    Re: Cisco IP phones deregistering/registering sporadically (STP switchproblem)....

    Hi there,

    Ive had similar problems with stacked switches. I recommend not running
    the phone access ports as trunks either. You can successfully run the
    Phones with

    switchport access vlan XXX
    switchport voice vlan YYY
    switchport nonegotiate


    switch port no negotiate will limit the DTP protocol memory usage on the
    stack.. I had a problem with this in a switch stack of 13 and the memory
    usage on this 'show proc mem' was over a meg.. this was bad according
    to 'output' interpretor. So the switchport nonegotiate brought the DTP
    usage down to about 7k.

    Cheers
    Andrew

    wr wrote:
    > The source of the problem is related to a spanning tree
    > issue, coupled with a bad phone/switchport configuration.
    >
    > Spanning-tree: I have a core-access layer network model. The
    > distribution layer is combined with the access or core,
    > depending on how you look at it. All access layer switches
    > are uplinked to the core switch pair redundantly. The problem
    > source is related to the way in which this redundant
    > connection works. I have sets of access layer switches daisy-
    > chained via their gig ports. So, for example the top access
    > switch in the stack goes to the second one down, etc. Both
    > the bottom and top switches have one uplink to redundant
    > cores.
    >
    > These uplinks and daisy chain switch ports are nothing more
    > than gig switchports. They are not special stacking ports, or
    > real stacking ports, like you might see in 3com switches or
    > newer cisco switches. (Yes cisco marketing has bastardized
    > this term). 3750 switches with the wire-speed stacking cable
    > (in the back) have real staking ports. 3com 3300's with the
    > stacking module have real stacking ports. Cisco 3550's with
    > two gig uplinks don't have real stacking ports. In my case, I
    > am relying on the 3550's uplink ports kind of as my stacking
    > ports at the access layer.
    >
    > So how does this cause the problem? Spanning tree is designed
    > to have maximum switch hop counts (bridge hops). This is
    > either 7 or 14 depending on the definition (I am still
    > confused on this piece). So as you add more switches into
    > your access "stack", and if spanning tree is configured
    > correctly, you will get a natural division in the stack, with
    > the top half going to the core on the top switch core uplink,
    > and the bottom half going to the core on the bottom switch
    > core uplink. If you add in another stack, the same behavior
    > will occur. Your config may look like this:
    >
    >
    > ----switch11----switch12-- | --switch13----switch14----
    > | |
    > | |
    > -------------- --------------
    > (core1---------------core2)
    > -------------- --------------
    > | |
    > | |
    > ----switch21----switch22-- | --switch23----switch24----
    >
    > So to get to from a pc on switch23 from to a pc on switch12,
    > you may have to traverse 5 hops (sw12->sw11->core->sw24-
    >
    >>sw23). Note the break on switch 12/13 and switch 22/23. To

    >
    > get this break, you have to run STP on the access switches.
    > Under failure scenarios, and/or if you run STP only on the
    > core switch, your network may look like this. (note: breaks
    > in switch14 and switch 21 uplink.
    >
    > ----switch11----switch12-------switch13----switch14- | -
    > | |
    > | |
    > -------------- ---------------
    > (core1---------------core2)
    > -------------- --------------
    > | |
    > | |
    > - | -switch21----switch22-------switch23----switch24----
    >
    > So what went from a nice network, just went to a bad one. To
    > get to from a pc on switch14 from to a pc on switch21, you
    > may have to traverse 9 hops (sw14->sw13->sw12->sw11->core-
    >
    >>sw21->sw22->sw24->sw23).

    >
    >
    > 9 hops from a repeater (bridge) perspective is not that bad,
    > but from an STP perspective is not that good. STP starts to
    > break down because it cannot converge. So the alternative is
    > to take STP off of the access switches, and live with 9
    > switch hop counts, because the break will be at one of the
    > core uplinks. You get no load balancing on the uplinks in
    > this scenario. You also don't get any protection from a user
    > short-circuiting one of the access layer switches by uplink
    > to it twice from two cube drops.
    >
    > The problem only worsens as you add more switches into the
    > stack, such as switch15, switch16, etc. The problem may also
    > worsen if you have rouge switches plugged into your access
    > layer and no bpdu guard enabled on all access switchports. I
    > like the idea of keeping STP on the access switches but
    > cannot handle STP not converging (or recalculating) during
    > peak periods of the day.
    >
    > Phone Switchports: It turns out that phone switchports at the
    > access layer are a bit tricky. Since the phone is essentially
    > a switch doing trunking, it could pose problems due to its
    > desire to trunk any vlan supported on that switch. For
    > example, if I have 10 vlans on the switch, and 1 is PC data
    > and 1 is phone voice, and follow a simple switch port config,
    > vlan trunking will occur and traffic will not be pruned. Here
    > is switchport config before and after:
    >
    > interface FastEthernet0/1
    > switchport trunk encapsulation dot1q
    > switchport trunk native vlan 303
    > switchport mode trunk
    > switchport voice vlan 304
    > spanning-tree bpduguard enable
    > ===========
    > interface FastEthernet0/1
    > switchport trunk encapsulation dot1q
    > switchport trunk native vlan 303
    > switchport trunk allowed vlan 303,304
    > switchport mode trunk
    > switchport voice vlan 304
    > storm-control broadcast level 15.00
    > spanning-tree bpduguard enable
    >
    > Note: I have manually allowed VLAN's in the after scenario.
    > Without this a sh span showed this port was forwarding all
    > vlan traffic. Even though there was no node on the other side
    > support that vlan traffic. What this means is your phone port
    > essentially forwards all VLAN's broadcasts. Probably not a
    > big deal, but seems like its worth stopping through vlan
    > filter. The broadcast config item is just something extra i
    > added in for safety. this doesn't actually stop the sending
    > of BC's out the port. the spanning-tree bpduguard enable
    > command disables port if it receives a bpdu--prevents port
    > from becoming a root uplink accidentally.
    >
    > Anyone have any comments, ideas on how to properly configure
    > a port or access switch to meet all requirements. thanks, will
     
    Andrew Riley, May 24, 2004
    #2
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    5,832
    Erik Tamminga
    May 21, 2005
  2. joseph
    Replies:
    3
    Views:
    1,346
  3. Dave
    Replies:
    1
    Views:
    1,092
    Capri-Sun
    Apr 16, 2007
  4. Nicholas Sherlock

    Tray icons display only sporadically?

    Nicholas Sherlock, Sep 17, 2003, in forum: NZ Computing
    Replies:
    11
    Views:
    429
    T-Boy
    Sep 17, 2003
  5. lbbss
    Replies:
    3
    Views:
    421
    Meat Plow
    Jul 29, 2010
Loading...

Share This Page