Re: IERS Lab4 Task1.3 - Loopguard and UDLD

Check the AUTORECOVER in the table.

Question " 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."

"Brought Down" meaning Error Disable ! Shouldn't be brought up incase
BPDU's are being received after uni-directional link is detected the
first time!

On Mon, Jan 25, 2010 at 4:39 PM, Cristian Matei
<cristian.matei_at_datanets.ro> wrote:
> Hi Divin,
>
> Thanks but I guess we know the diff; the issue here is different.
>
> Regards,
> Cristian.
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Divin Mathew John
> Sent: Monday, January 25, 2010 1:04 PM
> To: Joe Astorino
> Cc: cristian.matei_at_datanets.ro; Marko Milivojevic; Nadeem Rafi; Michael
> McFarlin; Cisco certification
> Subject: Re: IERS Lab4 Task1.3 - Loopguard and UDLD
>
> Cisco has Tabulated the differences!
> http://www.ciscosystems.com/en/US/tech/tk389/tk621/technologies_tech_note091
> 86a0080094640.shtml#loop_guard_vs_uld
>
> On Mon, Jan 25, 2010 at 2:41 AM, Joe Astorino <jastorino_at_ipexpert.com>
> wrote:
>> 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
>>
>> _______________________________________________________________________
>> 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

Blogs and organic groups at http://www.ccie.net
Received on Mon Jan 25 2010 - 16:47:13 ART