Re: RSTP problem

Hi Petr,

I can understand that why a full duplex link cannot connect to shared
topology with this reason
When three switches are connected to a hub, then u cant use a full duplex
because Hubs support just a one way traffic all the time. either send or
receive. so its basically half duplex. So i agree with that

With the Count to infinity problem in RSTP, What is the main factor that
makes counting to infinity possible with RSTP? Is it their information
exchange quickly to their unlike normal STP which checks out for the
original information and waits for it and times out the old information
before sending out . So there is no timing out logic in RSTP.
Am i right with that point ?

Is it possible to use diffused computations DUAL alogrithm which we use in
EIGRP to implement RSTP ?
Because DUAL always checks that the backup path should not use the original
local router as a best path to be loop free.

If this is a problem with RSTP ( Counting to infinity problem ) why not can
we go with normal legacy STP . Why cant legacy STP converge faster than
2xForward_Time?

Is there any solution for it ?

On Sat, Dec 17, 2011 at 12:25 PM, Petr Lapukhov <petr_at_internetworkexpert.com
> wrote:

> Counting to infinity might be a problem with classic RSTP in certain
> topologies, e.g. those having multiple loops. More accurately,
> counting to infinity behavior might be observed in a situation where
> network failure isolates a part of the network from the root bridge,
> and the isolated part has loop. In this situation, stale information
> would circulate for a long as MaxAge is not exceeded. This is typical
> to any distance-vector protocol.
>
> For the second question, it is normally not possible to connected a
> full-duplex link to a shared topology. However, this could be done
> when using L2 protocol tunneling and interconnecting multiple links
> into a stretched L2 domain. In this situation, RSTP behavior is not
> very well predictable and may exhibit certain race condition behavior.
>
> In most cases, the above configurations could and should be avoided.
> This being said, there has been theoretical work to make RSTP
> resistant to counting to infinity problem by adding root bridge
> information version tracking, similar to AODV protocol. For more
> information, I would suggest looking up papers on AODV and RSTP, e.g.
> http://research.yahoo.com/files/ToN.pdf
>
> Regards,
>
> --
> Petr Lapukhov, petr_at_INE.com
> CCIE #16379 (R&S/Security/SP/Voice)
> CCDE #20100007
>
> Internetwork Expert, Inc.
> http://www.INE.com
> Toll Free: 877-224-8987
> Outside US: 775-826-4344
>
> 2011/12/16 Routing Freak <routingfreak_at_gmail.com>:
> > In RSTP, it will work fine only for Poin to Point ethernet link. In a
> > shared sthernet space ( ie a Hub is present in between the domain , then
> > one of the bridge will be designated and the synchronisation ripple
> follows
> > .
> >
> > Full duplex link can be connected to a Hub . But Hub doesnt support full
> > duplex transmission of data.
> >
> >
> > On Fri, Dec 16, 2011 at 5:41 PM, CCIE KID <eliteccie_at_gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> I am going through the doc cd of RSTP and saw a point whihc i cant
> >> understand. Can anyone shed some light on it
> >> The doc cd states that
> >> Counting to Infinity problem is a factor in RSTP .
> >> Could a full-duplex link connect to a shared topology in RSTP?
> >>
> >>
> >> --
> >> With Warmest Regards,
> >>
> >> CCIE KID
> >> CCIE#29992 (Security)
> >>
> >>
> >> 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
> >
> >
> >
> >
> >
> >
> >
>

--
With Warmest Regards,
CCIE KID
CCIE#29992 (Security)
Blogs and organic groups at http://www.ccie.net