Re: IERS Lab4 Task1.3 - Loopguard and UDLD

Agreed : )

Also, I don't believe the scenario discussed here with the hub would
cause a STP loop because, even with portfast on we are still sending
BPDUs. There may be a loop for a very short period of time...right up
until one side realizes the guy on the other side is the designated
port and goes into blocking mode. The non-designated port side would
go into blocking after receiving BPDUs from the other side.

Now, if you turned on BPDUfilter thats another story : )

On Mon, Jan 25, 2010 at 5:59 AM, Cristian Matei
<cristian.matei_at_datanets.ro> wrote:
> Hi Joe,
>
> The page seems to be the same number; conclusion being in order to
> successfully protect against STP loops, both features are needed
> concurrently enabled; this is because loopguard works ONLY on root/alternate
> ports; how about the DSG ports? Here you would need UDLD.
>
> Regards,
> Cristian.
>
> -----Original Message-----
> From: Joe Astorino [mailto:jastorino_at_ipexpert.com]
> Sent: Monday, January 25, 2010 12:42 PM
> To: cristian.matei_at_datanets.ro
> Cc: Marko Milivojevic; Nadeem Rafi; Michael McFarlin; Cisco certification
> Subject: 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
>
>

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