Re: IERS Lab4 Task1.3 - Loopguard and UDLD

I agree. All I am saying is that loopguard can protect you against
spanning-tree loops CAUSED by uni-directional links. If you have a
uni-directional link on a segment, that means one end (perhaps the
non-designated port) may stop receiving BPDUs from the designated-port
(in this case due to the uni-directional link) and go into forwarding
state, which would cause a spanning-tree loop.

To summarize: I am talking about the exact same thing here -- In your
example the switch stops receiving BPDUs due to high CPU utilization
and goes into forwarding which causes a loop. In my example the
switch still stops receiving BPDUs, it is just due to a
uni-directional link. UDLD detects unidirectional links. Loopguard
prevents against spanning-tree loops. What I am saying is that
loopguard prevents against the spanning-tree loops no matter how they
came about -- It could have come about due to the failure to receive
BPDUs because of high CPU utilization, or it could have come about due
to a uni-directional link it doesn't really matter.

Are we all on the same page now?

On Mon, Jan 25, 2010 at 1:48 AM, Cristian Matei
<cristian.matei_at_datanets.ro> wrote:
> Hi Joe,
>
>
> What Marko tried to explain and I do agree is that UDLD by itself
> does NOT protect you from STP loops; UDLD by itself guarantees only
> unidirectional link discovery and depending on the operating mode
> (aggressive or default) it will/will not put the port in err-disable state.
> UDLD is basically a "hardware" feature while loopguard is more a "software"
> feature (it is solely based on receiving or NOT BPDUs and on the STP
> topology)
> So loopguard does not protect you from unidirectional links, but
> from creating STP loops in the case one member of the STP topology cannot
> send BPDUs (due to high CPU for example).
> Conclusion is that by enabling both features you are protected
> against STP loops and these features are complementary.
>
>
> To answer Mike's initial question, loopguard is enabled/configured
> as the task asks specifically for it (it's just a wording thing):" As an
> additional precaution, configure SW1 so that interface Fa0/15 is not
> mistakenly elected as a designated port in the above case".
>
> A question for Marko, how did you create the loop with that hub? I
> don't see the topology exactly.
>
> Regards,
> Cristian.
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Joe
> Astorino
> Sent: Sunday, January 24, 2010 9:33 PM
> To: Marko Milivojevic
> Cc: Nadeem Rafi; Michael McFarlin; Cisco certification
> Subject: Re: IERS Lab4 Task1.3 - Loopguard and UDLD
>
> Marko,
>
> I do agree that everything here is absolutely correct. I'm simply
> saying that UDLD and loop guard are both technologies that can prevent
> against spanning-tree loops due to unidirectional links. They
> accomplish that in different ways. UDLD does it by detecting the link
> as being unidirectional in the first place and taking action.
> Loopguard does it by taking a different action in spanning-tree (When
> the non-designated port stops receiving BPDUs it goes into inconsitent
> state instead of starting to forward because it assumes it is the new
> DP)
>
> So yes -- two different technologies but two technologies that can be
> used to solve a similar problem.
>
> On Sun, Jan 24, 2010 at 12:56 PM, Marko Milivojevic <markom_at_ipexpert.com>
> wrote:
>> While I hate to disagree with Joe (I usually end up losing those
>> arguments), I have to in this case... at least in one part.
>>
>> UDLD and Loop Guard *do not* solve the same problem. They are designed
>> to solve entirely different issues at different layers, though their
>> functionality overlaps in one single scenario.
>>
>> UDLD is, essentially, L1.5 protocol. It will detect unidirectional
>> links (using its own mechanism) and disable the port if it receives no
>> responses from its UDLD partner on the other side. In a case when
>> there is bidirectional link, you can still have L2 loop...
>>
>> So, what exactly is the L2 loop, then? Imagine having an access
>> network of two access switches, where each is connected to the root
>> switch with one uplink. Access ports are configured with portfast, to
>> make client workstations connect faster. What happens when someone
>> smart comes there and decides to "have 200 megs to his workstation",
>> by connecting two ports to a hub? All links are bidirectional, there
>> are no failures... only one nice STP loop... and mess in your entire
>> network. Now, this is the problem Loop Guard is designed to solve.
>> Granted, it can help with unidirectional links, but... Unidirectional
>> links have another problem...
>>
>> Let's say that we have a link that is unidirectional only ...
>> sometimes. In other words, it's flapping, but only in one direction
>> (long fiber links can do this if optical receiver is burned through,
>> for example). UDLD may or may not detect this, so using Loop Guard as
>> an additional precaution is perfectly legitimate approach.
>>
>> --
>> Marko Milivojevic - CCIE #18427
>> Senior Technical Instructor - IPexpert
>>
>> Mailto: markom_at_ipexpert.com
>> Telephone: +1.810.326.1444
>> Fax: +1.810.454.0130
>> Community: http://www.ipexpert.com/communities
>>
>> On Sun, Jan 24, 2010 at 17:16, Nadeem Rafi <nrafia_at_gmail.com> wrote:
>>> Thanks for this link.. mis-wiring is new to me :) so much to learn in
> this
>>> short period of life.
>>>
>>> Thanks again.
>>>
>>> On Sun, Jan 24, 2010 at 8:08 PM, Joe Astorino
> <jastorino_at_ipexpert.com>wrote:
>>>
>>>> Hello,
>>>>
>>>> UDLD and loopguard are essentially two ways to solve the same problem
>>>> using different methods. Like Nadeem said, UDLD physically detects
>>>> the uni-directional links, whereas loopguard is more geared towards
>>>> STP specifically. Typically you will deploy one or the other. You
>>>> may want to check out the following link which does a nice comparison
>>>> : )
>>>>
>>>>
>>>>
> http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080
> 094640.shtml#loop_guard_vs_uld
>>>>
>>>> On Sun, Jan 24, 2010 at 7:05 AM, Michael McFarlin
>>>> <router.genie_at_gmail.com> wrote:
>>>> > Experts,
>>>> >
>>>> > I have a question about UDLD and Loopguard in one of the IERS labs. I
>>>> don't
>>>> > think that loopguard is needed at all here. Why would you have to
> worry
>>>> > about SW1 making the Fa0/15 a designated port if UDLD has already
> taken
>>>> the
>>>> > port down? By default UDLD acts faster than Loopguard by default
> right?
>>>> >
>>>> >
>>>> > Task
>>>> >
>>>> > Administrators of your network are concerned about SW1 and SW2 not
>>>> > being able to detect a link failure on port Fa0/15.
>>>> >
>>>> > Configure SW1 and SW2 so that port Fa0/15 is brought down in the case
>>>> > that either switch can send traffic, but not receive, or vice versa.
>>>> >
>>>> > As an additional precaution, configure SW1 so that interface Fa0/15
> is
>>>> not
>>>> > mistakenly elected as a designated port in the above case.
>>>> >
>>>> > Answer
>>>> >
>>>> > SW1:
>>>> > interface FastEthernet0/15
>>>> > udld port aggressive
>>>> > spanning-tree guard loop
>>>> > SW2:
>>>> > interface FastEthernet0/15
>>>> > udld port aggressive
>>>> >
>>>> >
>>>> > -Mike
>>>> >
>>>> >
>>>> > Blogs and organic groups at http://www.ccie.net
>>>> >
>>>> >
> _______________________________________________________________________
>>>> > Subscription information may be found at:
>>>> > http://www.groupstudy.com/list/CCIELab.html
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Joe Astorino CCIE #24347 (R&S)
>>>> Sr. Technical Instructor - IPexpert
>>>> Mailto: jastorino_at_ipexpert.com
>>>> Telephone: +1.810.326.1444
>>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>>> eFax: +1.810.454.0130
>>>>
>>>> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA
>>>> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice,
>>>> Security & Service Provider) Certification Training with locations
>>>> throughout the United States, Europe and Australia. Be sure to check
>>>> out our online communities at www.ipexpert.com/communities and our
>>>> public website at www.ipexpert.com
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Regards,
>
> Joe Astorino CCIE #24347 (R&S)
> Sr. Technical Instructor - IPexpert
> Mailto: jastorino_at_ipexpert.com
> Telephone: +1.810.326.1444
> Live Assistance, Please visit: www.ipexpert.com/chat
> eFax: +1.810.454.0130
>
> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA
> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice,
> Security & Service Provider) Certification Training with locations
> throughout the United States, Europe and Australia. Be sure to check
> out our online communities at www.ipexpert.com/communities and our
> public website at www.ipexpert.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Regards,
Joe Astorino CCIE #24347 (R&S)
Sr. Technical Instructor - IPexpert
Mailto: jastorino_at_ipexpert.com
Telephone: +1.810.326.1444
Live Assistance, Please visit: www.ipexpert.com/chat
eFax: +1.810.454.0130
IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA
(R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice,
Security & Service Provider) Certification Training with locations
throughout the United States, Europe and Australia. Be sure to check
out our online communities at www.ipexpert.com/communities and our
public website at www.ipexpert.com
Blogs and organic groups at http://www.ccie.net