Spanning Tree Loopguard

 

Something has always bothered me about Loopguard. First, I've never implemented it in production, so I'm quite ignorant to how it actually works.. Is there a seperate BPDU that is sent between switches running loopguard to act as a keepalive. If a blocked port stops receiving BPDU's, you want the port to transition to forwarding state to provide a redundant path. I guess what I'm trying to ask is, how does Loopguard distinguish between a "real" failure in the network and one that is merely a unidirectional problem between two switches? 

 

Thanks for any help with this very basic concept... I just can't seem to retain a clear picture on this. I'm sure I've learned this before and have just forgotten.. 

Comments

  • I guess if there was an indirect failure, the upstream would actually start advertising Inferior BPDU's (It would advertise itself as root). It wouldn't just stop sending BPDU's. So, basically the only time you would lose all BPDU's is when there is a problem at the link level. e.g. undirectional link 

     

    Does that sound right? 

  • Most often you would combine loop guard with UDLD since both are needed to catch errors in control plane and errors in physical plane.

     

  • mostly loopguard and udld are used togather, but both operate with different approach.

     

    Loop guard will work with BPDUs mechanism, it will use existing STP mechanism to detect unidirectional errors. While UDLD will introduce its own mechanism to detect unidirectional links. UDLD can also detect loops caused by faulty STP algorithms (although chances are very rare).

     

    more from cisco

     



    Understanding UDLD


    UDLD is a Layer 2 protocol that enables devices connected through
    fiber-optic or twisted-pair Ethernet cables to monitor the physical
    configuration of the cables and detect when a unidirectional link
    exists. All connected devices must support UDLD for the protocol to
    successfully identify and disable unidirectional links. When UDLD
    detects a unidirectional link, it administratively shuts down the
    affected port and alerts you. Unidirectional links can cause a variety
    of problems, including spanning-tree topology loops.



    Modes of Operation


    UDLD supports two modes of operation: normal (the default) and
    aggressive. In normal mode, UDLD can detect unidirectional links due to
    misconnected interfaces on fiber-optic connections. In aggressive mode,
    UDLD can also detect unidirectional links due to one-way traffic on
    fiber-optic and twisted-pair links and to misconnected interfaces on
    fiber-optic links.


    In normal and aggressive modes, UDLD works with the Layer 1 mechanisms
    to determine the physical status of a link. At Layer 1, autonegotiation
    takes care of physical signaling and fault detection. UDLD performs
    tasks that autonegotiation cannot perform, such as detecting the
    identities of neighbors and shutting down misconnected interfaces. When
    you enable both autonegotiation and UDLD, the Layer 1 and Layer 2
    detections work together to prevent physical and logical unidirectional
    connections and the malfunctioning of other protocols.


    A unidirectional link occurs whenever traffic sent by a local device is
    received by its neighbor but traffic from the neighbor is not received
    by the local device.


    In normal mode, UDLD detects a unidirectional link when fiber strands in
    a fiber-optic interface are misconnected and the Layer 1 mechanisms do
    not detect this misconnection. If the interfaces are connected correctly
    but the traffic is one way, UDLD does not detect the unidirectional
    link because the Layer 1 mechanism, which is supposed to detect this
    condition, does not do so. In case, the logical link is considered
    undetermined, and UDLD does not disable the interface.


    When UDLD is in normal mode, if one of the fiber strands in a pair is
    disconnected and autonegotiation is active, the link does not stay up
    because the Layer 1 mechanisms did not detect a physical problem with
    the link. In this case, UDLD does not take any action, and the logical
    link is considered undetermined.


    In aggressive mode, UDLD detects a unidirectional link by using the
    previous detection methods. UDLD in aggressive mode can also detect a
    unidirectional link on a point-to-point link on which no failure between
    the two devices is allowed. It can also detect a unidirectional link
    when one of these problems exists:


    imageOn fiber-optic or twisted-pair links, one of the interfaces cannot send or receive traffic.


    imageOn fiber-optic or twisted-pair links, one of the interfaces is down while the other is up.


    imageOne of the fiber strands in the cable is disconnected.


    In these cases, UDLD shuts down the affected interface.


    In a point-to-point link, UDLD hello packets can be considered as a
    heart beat whose presence guarantees the health of the link. Conversely,
    the loss of the heart beat means that the link must be shut down if it
    is not possible to re-establish a bidirectional link.


    If both fiber strands in a cable are working normally from a Layer 1
    perspective, UDLD in aggressive mode determines whether those fiber
    strands are connected correctly and whether traffic is flowing
    bidirectionally between the correct neighbors. This check cannot be
    performed by autonegotiation because autonegotiation operates at Layer
    1.



    Methods to Detect Unidirectional Links


    UDLD operates by using two mechanisms:


    imageNeighbor database maintenance


    UDLD learns about other UDLD-capable neighbors by periodically sending a
    hello packet (also called an advertisement or probe) on every active
    interface to keep each device informed about its neighbors.


    When the switch receives a hello message, it caches the information
    until the age time (hold time or time-to-live) expires. If the switch
    receives a new hello message before an older cache entry ages, the
    switch replaces the older entry with the new one.


    Whenever an interface is disabled and UDLD is running, whenever UDLD is
    disabled on an interface, or whenever the switch is reset, UDLD clears
    all existing cache entries for the interfaces affected by the
    configuration change. UDLD sends at least one message to inform the
    neighbors to flush the part of their caches affected by the status
    change. The message is intended to keep the caches synchronized.


    imageEvent-driven detection and echoing


    UDLD relies on echoing as its detection mechanism. Whenever a UDLD
    device learns about a new neighbor or receives a resynchronization
    request from an out-of-sync neighbor, it restarts the detection window
    on its side of the connection and sends echo messages in reply. Because
    this behavior is the same on all UDLD neighbors, the sender of the
    echoes expects to receive an echo in reply.


    If the detection window ends and no valid reply message is received, the
    link might shut down, depending on the UDLD mode. When UDLD is in
    normal mode, the link might be considered undetermined and might not be
    shut down. When UDLD is in aggressive mode, the link is considered
    unidirectional, and the interface is shut down.


    If UDLD in normal mode is in the advertisement or in the detection phase
    and all the neighbor cache entries are aged out, UDLD restarts the
    link-up sequence to resynchronize with any potentially out-of-sync
    neighbors.


    If you enable aggressive mode when all the neighbors of a port have aged
    out either in the advertisement or in the detection phase, UDLD
    restarts the link-up sequence to resynchronize with any potentially
    out-of-sync neighbor. UDLD shuts down the port if, after the fast train
    of messages, the link state is still undetermined.

     

     

    link.......  http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1_19_ea1/configuration/guide/swudld.html

     

  • Hmm, my question was purely about Portfast.. Thanks though! 

     

    I think I answered my own question.. 

  •  

     If a blocked port stops receiving BPDU's, you want the port to transition to forwarding state to provide a redundant path. I guess what I'm trying to ask is, how does Loopguard distinguish between a "real" failure in the network and one that is merely a unidirectional problem between two switches? 

     

     

     

    the radia or the stp problemo....ok lame joke....

     

    anyhow think REDUNDANT links....you use loopguard on redundant links that are blocking....hense they are blocking in the first place because they are redundant but less desitable paths to the root....

     

     

    if the root port fails directly you are gonna switching to the alternate path immediately and it'll be put in forwarding in 2x fwd delay seconds(w/o uplink fast) even if you have loopguard on it because now its not a redundant path...but the ONLY path...

     

    if the root port fails to receive BPDUs after max age expires (20 seconds...actually max age - message age) the root port will be considered to have failed and the alternating port will transition to fwd in 2 x fwd delay seconds...

     

    loop guard " keeps REDUNDANT/blking paths from going into forwarding if they stop receiving BPDUs" not just any ole port...

     

    HTH

     

    i also think you should take the time to read petrs excellent blogs on STP.....personally i have em printed and bound..

    http://blog.ine.com/2010/09/21/blog-post-catalogue-2/

     

     

    Tox!

     

  • no doubt peter is genius.... This is new idea to print and bind his blogs :)

  • when i do my layer 2 reviews it goes in this order....

    1) kennedy clark....read all of STP

    2) bcmsn book....read all of RSTP

    3) read all of petrs Layer 2 blogs

    4) do all the questions in the workbook1 while looking at my notes...

    5) do a more advanced lab for MSTP cause WB one is not sufficient for that

     

    usually takes around 2 to 2 1/2  days

     

    binding the blogs in one book(costs $5 at staples) gets me away from in front of my computer and  into a library which is a refreshing change from being constantly caged inside my lab room :(

     

     

    Tox!

  • Hey, Good suff! Yeah, I've read through most of these.. Obviously I've forgotten some key points.. I guess it's time for some review.. 

     

    Thanks for the suggestions! 

  • Hey, Good suff! Yeah, I've read through most of these.. Obviously I've forgotten some key points.. I guess it's time for some review.. 

     

    Thanks for the suggestions! 

    read thru is not enough....

     

    you gotta memorize them...

     

    Tox

  • In networking field after Jeff Doyle only Peter can impress me. He is really genius person in this field.

  • In networking field after Jeff Doyle only Peter can impress me. He is really genius person in this field.

    1)you should get a hold of Morris's old netmasters VOD lectures...the guy just stands there in an old teeshirt and rambles on and on and on from memory ad naseum..details within details i doubt few remember

     

    2) watch MaGahans Multicasting VOD...the almost white light level of network awareness he has ..which most of us can do with unicasting...but with multicasting..yeah..thats impressive..

  • I got impressed with so many on these industry. Brian D, Brian M. and Petr L. are just awesome, each one with its style.

    There are so many other guys who really know a LOT ;)

  • There are so many of those, who contributed to this field with their knowledge. And every one of those have some thing better than other. Like Brains are good with structured approach to study and presentations, a great business mind also.

    Scot morris, a very good humorous mind.

    Narbik a walking and talking IOS and no one beat him when he talks about OSPF.

    Anthony always teach in baby step, providing a very strong foundation for any technology to build upon.

     

    But getting impressed by some one is personal choice.................. Plz give me this freedom[:D]

  • actually Morris teaches around 1 hour drive away from me....I intend to to go say hi at some point....

     

     

    Tox

  • You are lucky guy!

  • You are lucky guy!

    I can go shake his hand....I cant afford his classes ...lol...

     

    Tox!

  • If i have to be that lucky, i have to travel just few thousands of miles. [:@]

  • If i have to be that lucky, i have to travel just few thousands of miles. Angry

     

     

    trust me..the highway i have to take to get there (Virginia Route 66 for those who know)....

     

    ...feels like a few thousand miles...  :(

     

    Tox

  • I think we are on same boat [6]

  • nah, I think I have a good handle on it.. 

  • wow, you got 20 points for that post.. I can see why you posted something off topic now.. just kidding around. thanks for all the information! 

  • hope this would explain you:




Sign In or Register to comment.