rstplib-users — Discussions about fetures & bugs in the packege

[Rstplib-users] RE: RSTP Ring Size ?

[Liwei Y. <Liw...@wo...>]

Les,

You did explain things well, but I gauss that you didn't take any =
possible link outage into account.
For example, the 45 bridges ring is only theoretically possible.  =
Because if in worst case, the root bridge lost one of its links, then =
the total age will much more than 23, it will never converge since the =
bpdu aged out at middle of the broken ring !!!

So as a workable ring, the maximum bridges allowed is about 21, unless =
you either assume a perfect ring (why do you need the spanning tree for =
then?) or change the standard on bpdu age calculation. =20

Liwei Yuan

-----Original Message-----
From: Les Bell [mailto:Les...@eu...]
Sent: Monday, February 04, 2002 7:16 AM
To: Robert Petroff
Cc: std...@ie...; rst...@li...
Subject: Re: RSTP Ring Size ?






The 'problem' is caused by the way effective age of a BPDU is =
incremented at
each Bridge, as it is received on its Root Port and subsequently =
propagated on
its Designated Ports - see 802.1w 17.19.19 and 17.19.21.

"IThe effective age of the port information (portPriority and portTimes) =
is
taken as the value of the Message Age parameter carried in a received =
BPDU,
incremented by the greater of (1/16th Max Age) and 1 s, and rounded to =
the
nearest whole second."

This results in the effective age being incremented by 1 at each hop, =
for MaxAge
<=3D 23; an increment of 2 at each hop for 24 <=3D MaxAge <=3D 39; and =
an increment of
3 at each hop for MaxAge =3D=3D 40.

The network size is limited when the effective age of the received info =
from a
BPDU exceeds MaxAge.  The received info must also be refreshed before it =
is aged
and discarded, so the maximum network size is also affected by the value =
of
HelloTime.  The limit of the network is reached when
((effectiveAge+HelloTime)>=3DMaxAge).

With default values of MaxAge (20) and HelloTime (2), the maximum =
network size
18 Bridge hops from the Root Bridge, giving a total of 37 Bridges in a =
chain or
a ring, if the Root Bridge is at the centre.  Setting (MaxAge=3D24) =
causes an
increment of 2 in root times at each hop, so the limit is reached after =
only 11
hops from the Root Bridge, with either (HelloTime=3D1) or =
(HelloTime=3D2).  For
(MaxAge=3D39) and (HelloTime=3D1), the limit is 19 hops from the Root =
Bridge.

The maximum achievable network size is with (MaxAge=3D23) and =
(HelloTime=3D1), with
22 hops from the Root Bridge giving a total of 45 Bridges in a chain or =
a ring.
In practice, you will probably have to reduce this to 21 hops from the =
Root
Bridge (43 in a chain or a ring) to allow for timer variances between =
the
Bridges, as you do not want the Bridges furthest from the Root Bridge to =
age out
the information from its Root Port if the next BPDU is a few =
milliseconds late.

Les...





Robert Petroff <rob...@ya...> on 04/02/2002 11:58:05

Sent by:  Robert Petroff <rob...@ya...>


To:   std...@ie...
cc:   rst...@li... (Les Bell/GB/3Com)
Subject:  Re: RSTP Ring Size ?





Would anyone like to ask on this (see below) my
question, please ?
I realy need it...
Robert

 --- Robert Petroff <rob...@ya...> wrote:
>
> Hi,
>
> We hoped, that IEEE 802.1w (RSTP) will be able
> to solve the problem of a big ring of Bridges.
>
> (In the our legacy STP (IEEE 802.1d) bridges we had
> to "break" the spec.: we allow to exceed the value
> 40
> for MaxAge).
>
> From the first view, we saw, that a new protocol is
> not so sensitive to the LAN diameter, because the
> message age behaves much more like a hop count
> in RSTP than it did in STP.
>
> But now, it seems to us, the state is worse :(
>
> I read the messages in your mailing list:
> a) of Richa Malhotra on
> http://www.ieee802.org/1/private/email/msg00221.html
> with subject "802.1w -- Message/Max age"
> b) of Alex Ruzin on
> http://www.ieee802.org/1/private/email/msg00423.html
> with subject "802.1w: How does LAN diameter depend
> on MaxAge ?"
>
> It seems, that in IEEE 802.1w (RSTP) even our trick
> with MaxAge will not help to increase LAN diameter.
>
> May anyone here provide with clarification, please ?
>
> I humbly thank you in advance, Robert
>
>
>

[Rstplib-users] Re: RSTP Ring Size ?

[<rob...@ya...>]

Fine, but I don't understand, what is
a theoretical vindication of such
nonlinear effective age calculation? From where did
the magic "1/16" come?
Another question: when and for what should we
increase MaxAge more that 24 ?

Thanks, Robert

 --- Les Bell <Les...@eu...> wrote: > 
> 
> 
> 
> The 'problem' is caused by the way effective age of
> a BPDU is incremented at
> each Bridge, as it is received on its Root Port and
> subsequently propagated on
> its Designated Ports - see 802.1w 17.19.19 and
> 17.19.21.
> 
> "IThe effective age of the port information
> (portPriority and portTimes) is
> taken as the value of the Message Age parameter
> carried in a received BPDU,
> incremented by the greater of (1/16th Max Age) and 1
> s, and rounded to the
> nearest whole second."
> 
> This results in the effective age being incremented
> by 1 at each hop, for MaxAge
> <= 23; an increment of 2 at each hop for 24 <=
> MaxAge <= 39; and an increment of
> 3 at each hop for MaxAge == 40.
> 
> The network size is limited when the effective age
> of the received info from a
> BPDU exceeds MaxAge.  The received info must also be
> refreshed before it is aged
> and discarded, so the maximum network size is also
> affected by the value of
> HelloTime.  The limit of the network is reached when
> ((effectiveAge+HelloTime)>=MaxAge).
> 
> With default values of MaxAge (20) and HelloTime
> (2), the maximum network size
> 18 Bridge hops from the Root Bridge, giving a total
> of 37 Bridges in a chain or
> a ring, if the Root Bridge is at the centre. 
> Setting (MaxAge=24) causes an
> increment of 2 in root times at each hop, so the
> limit is reached after only 11
> hops from the Root Bridge, with either (HelloTime=1)
> or (HelloTime=2).  For
> (MaxAge=39) and (HelloTime=1), the limit is 19 hops
> from the Root Bridge.
> 
> The maximum achievable network size is with
> (MaxAge=23) and (HelloTime=1), with
> 22 hops from the Root Bridge giving a total of 45
> Bridges in a chain or a ring.
> In practice, you will probably have to reduce this
> to 21 hops from the Root
> Bridge (43 in a chain or a ring) to allow for timer
> variances between the
> Bridges, as you do not want the Bridges furthest
> from the Root Bridge to age out
> the information from its Root Port if the next BPDU
> is a few milliseconds late.
> 
> Les...
> 
> 
> 
> 
> 
> Robert Petroff <rob...@ya...> on
> 04/02/2002 11:58:05
> 
> Sent by:  Robert Petroff <rob...@ya...>
> 
> 
> To:   std...@ie...
> cc:   rst...@li... (Les
> Bell/GB/3Com)
> Subject:  Re: RSTP Ring Size ?
> 
> 
> 
> 
> 
> Would anyone like to ask on this (see below) my
> question, please ?
> I realy need it...
> Robert
> 
>  --- Robert Petroff <rob...@ya...>
> wrote:
> >
> > Hi,
> >
> > We hoped, that IEEE 802.1w (RSTP) will be able
> > to solve the problem of a big ring of Bridges.
> >
> > (In the our legacy STP (IEEE 802.1d) bridges we
> had
> > to "break" the spec.: we allow to exceed the value
> > 40
> > for MaxAge).
> >
> > From the first view, we saw, that a new protocol
> is
> > not so sensitive to the LAN diameter, because the
> > message age behaves much more like a hop count
> > in RSTP than it did in STP.
> >
> > But now, it seems to us, the state is worse :(
> >
> > I read the messages in your mailing list:
> > a) of Richa Malhotra on
> >
> http://www.ieee802.org/1/private/email/msg00221.html
> > with subject "802.1w -- Message/Max age"
> > b) of Alex Ruzin on
> >
> http://www.ieee802.org/1/private/email/msg00423.html
> > with subject "802.1w: How does LAN diameter depend
> > on MaxAge ?"
> >
> > It seems, that in IEEE 802.1w (RSTP) even our
> trick
> > with MaxAge will not help to increase LAN
> diameter.
> >
> > May anyone here provide with clarification, please
> ?
> >
> > I humbly thank you in advance, Robert
> >
> >
> >
> 
> 
> 
> 
> 
>  

[Rstplib-users] Re: RSTP Ring Size ?

[Les B. <Les...@eu...>]

The 'problem' is caused by the way effective age of a BPDU is incremented at
each Bridge, as it is received on its Root Port and subsequently propagated on
its Designated Ports - see 802.1w 17.19.19 and 17.19.21.

"IThe effective age of the port information (portPriority and portTimes) is
taken as the value of the Message Age parameter carried in a received BPDU,
incremented by the greater of (1/16th Max Age) and 1 s, and rounded to the
nearest whole second."

This results in the effective age being incremented by 1 at each hop, for MaxAge
<= 23; an increment of 2 at each hop for 24 <= MaxAge <= 39; and an increment of
3 at each hop for MaxAge == 40.

The network size is limited when the effective age of the received info from a
BPDU exceeds MaxAge.  The received info must also be refreshed before it is aged
and discarded, so the maximum network size is also affected by the value of
HelloTime.  The limit of the network is reached when
((effectiveAge+HelloTime)>=MaxAge).

With default values of MaxAge (20) and HelloTime (2), the maximum network size
18 Bridge hops from the Root Bridge, giving a total of 37 Bridges in a chain or
a ring, if the Root Bridge is at the centre.  Setting (MaxAge=24) causes an
increment of 2 in root times at each hop, so the limit is reached after only 11
hops from the Root Bridge, with either (HelloTime=1) or (HelloTime=2).  For
(MaxAge=39) and (HelloTime=1), the limit is 19 hops from the Root Bridge.

The maximum achievable network size is with (MaxAge=23) and (HelloTime=1), with
22 hops from the Root Bridge giving a total of 45 Bridges in a chain or a ring.
In practice, you will probably have to reduce this to 21 hops from the Root
Bridge (43 in a chain or a ring) to allow for timer variances between the
Bridges, as you do not want the Bridges furthest from the Root Bridge to age out
the information from its Root Port if the next BPDU is a few milliseconds late.

Les...





Robert Petroff <rob...@ya...> on 04/02/2002 11:58:05

Sent by:  Robert Petroff <rob...@ya...>


To:   std...@ie...
cc:   rst...@li... (Les Bell/GB/3Com)
Subject:  Re: RSTP Ring Size ?





Would anyone like to ask on this (see below) my
question, please ?
I realy need it...
Robert

 --- Robert Petroff <rob...@ya...> wrote:
>
> Hi,
>
> We hoped, that IEEE 802.1w (RSTP) will be able
> to solve the problem of a big ring of Bridges.
>
> (In the our legacy STP (IEEE 802.1d) bridges we had
> to "break" the spec.: we allow to exceed the value
> 40
> for MaxAge).
>
> From the first view, we saw, that a new protocol is
> not so sensitive to the LAN diameter, because the
> message age behaves much more like a hop count
> in RSTP than it did in STP.
>
> But now, it seems to us, the state is worse :(
>
> I read the messages in your mailing list:
> a) of Richa Malhotra on
> http://www.ieee802.org/1/private/email/msg00221.html
> with subject "802.1w -- Message/Max age"
> b) of Alex Ruzin on
> http://www.ieee802.org/1/private/email/msg00423.html
> with subject "802.1w: How does LAN diameter depend
> on MaxAge ?"
>
> It seems, that in IEEE 802.1w (RSTP) even our trick
> with MaxAge will not help to increase LAN diameter.
>
> May anyone here provide with clarification, please ?
>
> I humbly thank you in advance, Robert
>
>
>

[Rstplib-users] RE: RSTP questions and one 802.1y/D2 issue

[Les B. <Les...@eu...>]

It is taken from the following procedure in 802.1s/d11:

13.27.1 betterorsameInfoCist()
Returns TRUE if the received CIST priority vector is better than or the same as
(13.10) the CIST port priority
vector.

Mick is right, his proposal does cover the (msgPriority != portPriority) case
that I was concerned about.

Les...





Robert Petroff <rob...@ya...> on 04/02/2002 11:54:15

Sent by:  Robert Petroff <rob...@ya...>


To:   mic...@ie..., rst...@li...
cc:   std...@ie... (Les Bell/GB/3Com)
Subject:  RE: RSTP questions and one 802.1y/D2 issue





Mick (or anyone),
Where may I get this "betterorsame" procedure ?
Thanks, Robert

 --- Mick Seaman <mic...@ie...> wrote: >
> Les,
>
> "betterorsame" fully covers the case "(msgPriority
> != portPriority)that you
> suggested, and further it means that cust don't get
> propagated continually
> and unnecessarily as information gets better.
>
> To Brandon's point, we don't need the enter
> ROOT_PROPOSED and cause a resync
> if the Root POrt already has agree set (agreed in
> .1w).
>
> This is the mechanism in .1s that stops needless
> cuts getting out of a
> region, it works equally well in .1w to not have
> information (which tends to
> get better in stages after a reconfig when all prior
> root information is
> lost) causing repeated resynchronizations together
> with repeated flushes.
>
> Mick
>
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On
> Behalf Of Les Bell
> Sent: Friday, February 01, 2002 1:56 AM
> To: mic...@ie...
> Cc: std...@ie...
> Subject: RE: RSTP questions and one 802.1y/D2 issue
>
>
>
>
>
> Hi Mick,
>
> When a legacy STP v0 Bridge sends a TC-ACK, the
> hold_timer ensures that at
> least
> 1 tick has expired since the last BPDU before it can
> send the BPDU with this
> TC-ACK.  Also, message_age_timer is incremented
> every tick.  This ensures
> the
> msgTimes in the BPDU carrying the TC-ACK differ from
> those previously sent
> (unless this is the Root Bridge, or if HelloTime==1
> and this Bridge has
> received
> another BPDU on its own Root Port, to reset
> message_age_timer).  The
> msgPriority
> in the BPDU with the TC-ACK will be the same as
> previously sent, unless
> other
> changes in the network have been detected.
>
> If the msgPriority is the same as the portPriority,
> then the only reason you
> would enter the PIM:SUPERIOR state is because the
> msgTimes differs from
> portTimes.  This is the case described above.  If
> you clear Agreed and
> synced,
> it will cause the PRT:ROOT_AGREED state to set
> newInfo, which in turn forces
> the
> transition to the PTX:TRANSMIT_TCN to send another
> TCN BPDU.  This causes
> the
> legacy STP v0 Bridge to send another TC ACK, which
> will have a different
> value
> in msgTimes (unless HelloTime==1) hence continually
> repeating the cycle of
> TCN/TC-ACK BPDUs.
>
> So you should not clear synced and agreed if
> msgPriority and portPriority
> are
> the same.
>
> I recommend the following, in the PIM:SUPERIOR
> state:
>
> agreed = agreed && (msgPriority != portPriority);
> synced = synced && agreed;
>
> A similar change should be applied to 802.1s.
>
> Les...
>
>
>
>
>
> "Mick Seaman" <mic...@ie...> on 01/02/2002
> 07:14:46
>
> Please respond to mic...@ie...
>
> Sent by:  "Mick Seaman" <mic...@ie...>
>
>
> To:   "'Tony Jeffree'" <to...@je...>,
> std...@ie...
> cc:    (Les Bell/GB/3Com)
> Subject:  RE: RSTP questions and one 802.1y/D2 issue
>
>
>
>
>
>
> 802.1y/D2 contains a partial implementation of
> changes suggested to fix a
> problem that Les Bell raised (see Brandon's first
> point below). What y/D2
> should have said is that PIM:SUPERIOR is changed so
> that agreed and synced
> are conditionally set FALSE (i.e. not changed from
> always set FALSE is this
> state to never set FALSE.
>
> The correct treatment of agreed and synced in this
> state is specified in
> .1sD11. The comparison is a little confusing since
> .1s introduces the
> variable agree to get around the overloading of the
> agreed variable that
> takes place in .1w. The easiest way to keep our
> sanity going forward is, I
> believe to add the agree variable to .1y/D2, then
> the .1w text can strictly
> follow that of .1s. If we don't do this then
> PIM:SUPERIOR in .1y should have
> the lines:
>
> agreed = agreed && betterorsameInfo();
> synced = synced && agreed;
>
> added, and the procedure defined analagous to .1s.
>
> Mick
>
>
>
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On
> Behalf Of Tony Jeffree
> Sent: Thursday, January 31, 2002 8:32 AM
> To: std...@ie...
> Subject: Fwd: RSTP questions and one 802.1y/D2 issue
>
>
>
>
> >Envelope-to: to...@je...
> >X-Authentication-Warning: io.iol.unh.edu: bbarry
> owned process doing -bs
> >Date: Fri, 4 Jan 2002 10:29:14 -0500 (EST)
> >From: "Brandon W. Barry" <bb...@io...>
> >To: to...@je...
> >Subject: RSTP questions and one 802.1y/D2 issue
> >
> >Tony,
> >
> >It appears to me that The PIM: SUPERIOR state
> optimization proposed in
> >802.1y/D2 could in some cases prevent Designated
> Ports from receiving the
> >confirmation needed in order to transition rapidly
> into the Forwarding
> >Port State.
> >
> >Suppose a Port receives an RST BPDU (indicating the
> Designated Port Role,
> >with the proposal flag set) containing a message
> priority vector better
> >than the port priority vector held for the Port. If
> synced is not set
> >False in the PIM: SUPERIOR state, and the receiving
> Port is both
> >forwarding and synced, the Port will not enter the
> PRT: ROOT_PROPOSED
> >state (assuming the information contained in the
> Superior Designated
> >Message causes the PRS machine to select the Root
> Port Role for said
> >Port).
> >
> >Consequently, the new Root Port would not run the
> setSyncBridge()
> >procedure, and none of the Designated Ports (which
> are no longer
> >synced after their transition through the PIM:
> UPDATE
=== message truncated ===

[Rstplib-users] RE: RSTP & VLANs (MSTP ?)

[<al...@nb...>]

Robert,
[First, don't send RstpLib only related messages to std...@ie...,
please]

On Monday, February 04, 2002 2:04 PM Mr. Robert Petroff asked:

You are right, there are a number of such "allusions".
The RstpLib is a part of a real project, where currently I allow to
build one RSTP instance per tag. It is not 802.1s compatible implementation
while, IMHO, 802.1s is too far from its finish :)

Now I am working for an implementation, where RSTP instance may
be created for a list of tags. It will continue to be 802.1s incompatible :(

There will be 3 types of instances:
1. PortListBased instance
2. TagListBase instance (it will travel toward 802.1s)
3. PortTagListbased instance
I am planning to finish this work in generally until edge of this February;
It will be version 2.xx.yy of rstplib in "rstplib.sourceforge.net".
Let me know, if you are interesting to get definitions of these 3 types of
instances
as I understand them - I will be glad to discuss it on the earliest stages
of the design.

Best wishes, Alex
---------------------
Open Source RSTP  https://sourceforge.net/projects/rstplib/
Optical Access Ltd. http://www.opticalaccess.com

Robert > In a couple of places of your RSTPLib I see
Robert > allusions on VLANs and 'tags' (in data
Robert > structure 'stpm', comments, etc.).
Robert > What do you mean ?
Robert > Does your library support MSTP (.1s) ?
Robert >
Robert > Thanks, Robert

[Rstplib-users] RSTP & VLANs (MSTP ?)

[<rob...@ya...>]

Hi Alex,

In a couple of places of your RSTPLib I see
allusions on VLANs and 'tags' (in data
structure 'stpm', comments, etc.).
What do you mean ?
Does your library support MSTP (.1s) ?

Thanks, Robert

[Rstplib-users] Re: RSTP Ring Size ?

[<rob...@ya...>]

Would anyone like to ask on this (see below) my
question, please ?
I realy need it...
Robert

 --- Robert Petroff <rob...@ya...> wrote:
> 
> Hi,
> 
> We hoped, that IEEE 802.1w (RSTP) will be able 
> to solve the problem of a big ring of Bridges.
> 
> (In the our legacy STP (IEEE 802.1d) bridges we had
> to "break" the spec.: we allow to exceed the value
> 40
> for MaxAge).
> 
> From the first view, we saw, that a new protocol is
> not so sensitive to the LAN diameter, because the
> message age behaves much more like a hop count
> in RSTP than it did in STP.
> 
> But now, it seems to us, the state is worse :(
> 
> I read the messages in your mailing list:
> a) of Richa Malhotra on
> http://www.ieee802.org/1/private/email/msg00221.html
> with subject "802.1w -- Message/Max age"
> b) of Alex Ruzin on
> http://www.ieee802.org/1/private/email/msg00423.html
> with subject "802.1w: How does LAN diameter depend
> on MaxAge ?"
> 
> It seems, that in IEEE 802.1w (RSTP) even our trick
> with MaxAge will not help to increase LAN diameter.
> 
> May anyone here provide with clarification, please ?
> 
> I humbly thank you in advance, Robert
> 
> 
>  

[Rstplib-users] RE: RSTP questions and one 802.1y/D2 issue

[<rob...@ya...>]

Mick (or anyone),
Where may I get this "betterorsame" procedure ?
Thanks, Robert

 --- Mick Seaman <mic...@ie...> wrote: > 
> Les,
> 
> "betterorsame" fully covers the case "(msgPriority
> != portPriority)that you
> suggested, and further it means that cust don't get
> propagated continually
> and unnecessarily as information gets better.
> 
> To Brandon's point, we don't need the enter
> ROOT_PROPOSED and cause a resync
> if the Root POrt already has agree set (agreed in
> .1w).
> 
> This is the mechanism in .1s that stops needless
> cuts getting out of a
> region, it works equally well in .1w to not have
> information (which tends to
> get better in stages after a reconfig when all prior
> root information is
> lost) causing repeated resynchronizations together
> with repeated flushes.
> 
> Mick
> 
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On
> Behalf Of Les Bell
> Sent: Friday, February 01, 2002 1:56 AM
> To: mic...@ie...
> Cc: std...@ie...
> Subject: RE: RSTP questions and one 802.1y/D2 issue
> 
> 
> 
> 
> 
> Hi Mick,
> 
> When a legacy STP v0 Bridge sends a TC-ACK, the
> hold_timer ensures that at
> least
> 1 tick has expired since the last BPDU before it can
> send the BPDU with this
> TC-ACK.  Also, message_age_timer is incremented
> every tick.  This ensures
> the
> msgTimes in the BPDU carrying the TC-ACK differ from
> those previously sent
> (unless this is the Root Bridge, or if HelloTime==1
> and this Bridge has
> received
> another BPDU on its own Root Port, to reset
> message_age_timer).  The
> msgPriority
> in the BPDU with the TC-ACK will be the same as
> previously sent, unless
> other
> changes in the network have been detected.
> 
> If the msgPriority is the same as the portPriority,
> then the only reason you
> would enter the PIM:SUPERIOR state is because the
> msgTimes differs from
> portTimes.  This is the case described above.  If
> you clear Agreed and
> synced,
> it will cause the PRT:ROOT_AGREED state to set
> newInfo, which in turn forces
> the
> transition to the PTX:TRANSMIT_TCN to send another
> TCN BPDU.  This causes
> the
> legacy STP v0 Bridge to send another TC ACK, which
> will have a different
> value
> in msgTimes (unless HelloTime==1) hence continually
> repeating the cycle of
> TCN/TC-ACK BPDUs.
> 
> So you should not clear synced and agreed if
> msgPriority and portPriority
> are
> the same.
> 
> I recommend the following, in the PIM:SUPERIOR
> state:
> 
> agreed = agreed && (msgPriority != portPriority);
> synced = synced && agreed;
> 
> A similar change should be applied to 802.1s.
> 
> Les...
> 
> 
> 
> 
> 
> "Mick Seaman" <mic...@ie...> on 01/02/2002
> 07:14:46
> 
> Please respond to mic...@ie...
> 
> Sent by:  "Mick Seaman" <mic...@ie...>
> 
> 
> To:   "'Tony Jeffree'" <to...@je...>,
> std...@ie...
> cc:    (Les Bell/GB/3Com)
> Subject:  RE: RSTP questions and one 802.1y/D2 issue
> 
> 
> 
> 
> 
> 
> 802.1y/D2 contains a partial implementation of
> changes suggested to fix a
> problem that Les Bell raised (see Brandon's first
> point below). What y/D2
> should have said is that PIM:SUPERIOR is changed so
> that agreed and synced
> are conditionally set FALSE (i.e. not changed from
> always set FALSE is this
> state to never set FALSE.
> 
> The correct treatment of agreed and synced in this
> state is specified in
> .1sD11. The comparison is a little confusing since
> .1s introduces the
> variable agree to get around the overloading of the
> agreed variable that
> takes place in .1w. The easiest way to keep our
> sanity going forward is, I
> believe to add the agree variable to .1y/D2, then
> the .1w text can strictly
> follow that of .1s. If we don't do this then
> PIM:SUPERIOR in .1y should have
> the lines:
> 
> agreed = agreed && betterorsameInfo();
> synced = synced && agreed;
> 
> added, and the procedure defined analagous to .1s.
> 
> Mick
> 
> 
> 
> -----Original Message-----
> From: own...@ma...
> [mailto:own...@ma...]On
> Behalf Of Tony Jeffree
> Sent: Thursday, January 31, 2002 8:32 AM
> To: std...@ie...
> Subject: Fwd: RSTP questions and one 802.1y/D2 issue
> 
> 
> 
> 
> >Envelope-to: to...@je...
> >X-Authentication-Warning: io.iol.unh.edu: bbarry
> owned process doing -bs
> >Date: Fri, 4 Jan 2002 10:29:14 -0500 (EST)
> >From: "Brandon W. Barry" <bb...@io...>
> >To: to...@je...
> >Subject: RSTP questions and one 802.1y/D2 issue
> >
> >Tony,
> >
> >It appears to me that The PIM: SUPERIOR state
> optimization proposed in
> >802.1y/D2 could in some cases prevent Designated
> Ports from receiving the
> >confirmation needed in order to transition rapidly
> into the Forwarding
> >Port State.
> >
> >Suppose a Port receives an RST BPDU (indicating the
> Designated Port Role,
> >with the proposal flag set) containing a message
> priority vector better
> >than the port priority vector held for the Port. If
> synced is not set
> >False in the PIM: SUPERIOR state, and the receiving
> Port is both
> >forwarding and synced, the Port will not enter the
> PRT: ROOT_PROPOSED
> >state (assuming the information contained in the
> Superior Designated
> >Message causes the PRS machine to select the Root
> Port Role for said
> >Port).
> >
> >Consequently, the new Root Port would not run the
> setSyncBridge()
> >procedure, and none of the Designated Ports (which
> are no longer
> >synced after their transition through the PIM:
> UPDATE 
=== message truncated === 

[Rstplib-users] RE: RSTP Lib

[<al...@nb...>]

Charlie,
[First of all, I'd like to ask you to post to
"mailto:rst...@li..."
not to me directly; thanks]

There was a flow in IEEE 802.1w, that was fixed in IEEE 802.1y-d2
(you may  get it from http://www.ieee802.org/1/pages/802.1y.html).
The problem I meet had been discussed in
thread "Question: indirect link fail in 802.1w", you may find this
discussion
in http://www.ieee802.org/1/private/email/msg00370.html and
a conclusion (as far as I remember) in
http://www.ieee802.org/1/private/email/msg00379.html

So, in IEEE 802.1y-d2 you may see:
"17.19.21 updtRolesBridge()
Add bullet item m) to the updtRolesBridge() procedure in 17.19.21 as
follows, immediately
following bullet item l):
m) If the port priority vector was received in a Configuration Message and
is not aged (infoIs =
Received), the root priority vector is not now derived from it, the
designated priority vector is higher
than the port priority vector, selectedRole is set to DesignatedPort and
updtInfo is set."

Best regards, Alex
---------------------
Open Source RSTP  https://sourceforge.net/projects/rstplib/
Optical Access Ltd. http://www.opticalaccess.com


> -----Original Message-----
> From: Charlie Wood [mailto:ch...@ur...]
> Sent: Thursday, January 31, 2002 3:45 PM
> To: al...@nb...
> Subject: RSTP Lib
>
>
>
> In your RSTP Library, file rolesel.c you have the follwing:
>
>  /* Note: this important piece has been inserted after
>   * discussion with Mick Sieman and reading 802.1y Z1 */
>
> If you have time, could you fill me in on what you're doing here and
> why?
>
> Thanks for your help.
>
> --
> Charlie Wood
>

Re: [Rstplib-users] RAPID!? Why!?

[Imagine T. <ter...@ya...>]

Ku,

Similar questions I asked two monthes ago.
There are the mail from Alex. It seems to be a reply.
If no - sorry.

------------ Begin of the citation ---
> Imagine,
> 
> As far as I understand and may express myself, there
> are 4 main ideas in
> .1w:
> 1. The idea of edgePort (it becomes Forwarding
> *immediately* and helps
> in Designated Port handshake, see item 3 in this
> list)
> 2. Root port becomes Forwarding *immediately*.
> 3. Designated  Port becomes Forwarding "immediately*
> after special
> (introduced in .1) "downstream handshake"
> 4. Flush Forwarding Database (when  Topology Change
> is detected) instead
> of Fast Ageing.
> 
> All other changes (including Port Path Cost, as you
> ask) in .1w are or
> small, or
> dedicated to supply these main ideas.
> 
> I hope, this brief explanation will help you.
> May you see in rstplib, that when forceVersion is
> "slow", things go slower ?
> That means, that the RSTP is a rapid one, and the
> regular (old? slow?
> legacy? - select correctest name of 802.d) STP is
> not rapid.
> 
> I'd like to advise you to read Annex F.2.3. "RSTP
> performance" in IEEE 802.1w
> 
> Best regards, Alex
------------ End of the citation ---

Concerning MSTP: I don't know. IMHO, it is *dedicated*
for muliple instances of STP on the same device.

Regards, Imagine

--- Ku <is...@ms...> wrote:
> Hi everybody,
> 
>     Sorry for this kind of stupid questions, @_@
>     I just contact the 802.1w, .1s SPEC these days,
> and find out some .1w
> simulator resource.
>     In my opinion, RSTP and MSTP defined new BPDU
> and Priority Vectors (5
> and 8) for bridges communications, SPEC    
> describes state machines for
> changing PORT ROLE respectively,
>     But I still do not understand Why RSTP can
> reconfigure STP "RAPIDLY".
> For OLD SPT Algo., bridge detect LAN         broken
> and then send TCN to the
> ROOT bridge with smallest Bridge ID, and transfer
> its own port to designated
> port. Is     it already simple and rapid?
> 
>     Could anybody explain it in more simple words!?
> or help me to pick out
> the KEY idea!
> 
>     Thanks in advance!!¡@
> 
> --Ku
> 
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
>
https://lists.sourceforge.net/lists/listinfo/rstplib-users


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: [Rstplib-users] Re: [readline] RSTPLIB Installation Question!!

[Imagine T. <ter...@ya...>]

Hi,
IMHO, you should try to delete the flag '-ltermcap' in
your Makefile.

Cheers, Imagine

You wrote:
> Hi Alex and all,
> 
> I just get the patch and fix the source code,
> with CFLAGS include -DOLD_READLINE, I can make
> source OKAY with the
> following environment,
[snipp..]
> ====
> PLATFORM 3:
> However, I tried it with Mandrake 8.1 and readline
> 4.2 is still fail......
> MISS libtermcap!?
> ...
> rm -f libcli.a
> ar cru libcli.a cli.o
> ranlib libcli.a
> gcc  bridge.o stp_cli.o
> stp_to.o -lutil -lreadline -ltermcap -lpthread -L.
> -lrst
> p -luid -lcli -o bridge
> /usr/bin/ld: cannot find -ltermcap
> collect2: ld returned 1 exit status
> make: *** [bridge] Error 1
> ...
> 
> [root@linux lib]# ls -la | grep termcap
> lrwxrwxrwx    1 root     root           19  1¤ë 15
> 23:15 libtermcap.so.2 ->
> libtermcap.so.2.0.8*
> -rwxr-xr-x    1 root     root        11992  7¤ë 31
> 02:49
> libtermcap.so.2.0.8*
> ====
> --Ku
> 


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

Re: [Rstplib-users] RAPID!? Why!?

[<alb...@ya...>]

Ku,

With question you should contact 802.1 WG, mailing
list std...@ie...
From other side, Alex explained me the differences
between 802.1d and 802.1w fine & clearly; I hope he
reads your questions.

Regards, Bina

 --- Ku <is...@ms...> wrote: > Hi everybody,
> 
>     Sorry for this kind of stupid questions, @_@
>     I just contact the 802.1w, .1s SPEC these days,
> and find out some .1w
> simulator resource.
>     In my opinion, RSTP and MSTP defined new BPDU
> and Priority Vectors (5
> and 8) for bridges communications, SPEC    
> describes state machines for
> changing PORT ROLE respectively,
>     But I still do not understand Why RSTP can
> reconfigure STP "RAPIDLY".
> For OLD SPT Algo., bridge detect LAN         broken
> and then send TCN to the
> ROOT bridge with smallest Bridge ID, and transfer
> its own port to designated
> port. Is     it already simple and rapid?
> 
>     Could anybody explain it in more simple words!?
> or help me to pick out
> the KEY idea!
> 
>     Thanks in advance!!¡@
> 
> --Ku
> 
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
>
https://lists.sourceforge.net/lists/listinfo/rstplib-users 

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

[Rstplib-users] RAPID!? Why!?

[Ku <is...@ms...>]

Hi everybody,

    Sorry for this kind of stupid questions, @_@
    I just contact the 802.1w, .1s SPEC these days, and find out some .1w
simulator resource.
    In my opinion, RSTP and MSTP defined new BPDU and Priority Vectors (5
and 8) for bridges communications, SPEC     describes state machines for
changing PORT ROLE respectively,
    But I still do not understand Why RSTP can reconfigure STP "RAPIDLY".
For OLD SPT Algo., bridge detect LAN         broken and then send TCN to the
ROOT bridge with smallest Bridge ID, and transfer its own port to designated
port. Is     it already simple and rapid?

    Could anybody explain it in more simple words!? or help me to pick out
the KEY idea!

    Thanks in advance!!　

--Ku

[Rstplib-users] Re: [readline] RSTPLIB Installation Question!!

[Y.H. K. <is...@ms...>]

Hi Alex and all,

I just get the patch and fix the source code,
with CFLAGS include -DOLD_READLINE, I can make source OKAY with the
following environment,

PLATFORM 1: mandrake 8.0 kernel 2.4.3-20 with readline 4.1
====
...
gcc  bridge.o stp_cli.o
stp_to.o -lutil -lreadline -ltermcap -lpthread -L. -lrstp -luid -lcli -o
bridge
./libuid.a(uid_sock.o): In function `UiD_SocketInit':
/home/sam/rstplib/uid_sock.c:95: the use of `tmpnam' is dangerous, better
use `mkstemp'
gcc  -g -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 -DOLD_READLINE   -c -o
mngr.o mngr.c
gcc  mngr.o -lutil -lreadline -ltermcap -lpthread -L. -luid -lcli -o mngr
./libuid.a(uid_sock.o): In function `UiD_SocketInit':
/home/sam/rstplib/uid_sock.c:95: the use of `tmpnam' is dangerous, better
use `mkstemp'
...
====
====
PLATFORM 2: mandrake 7.0 kernel 2.2.14 with readline 4.0
...
gcc  -g -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 -DOLD_READLINE   -c -o
cli.o cli.c
cli.c: In function `rl_read_cli':
cli.c:394: warning: passing arg 2 of `rl_callback_handler_install' from
incompat ible pointer type
cli.c: In function `cli_private_completion':
cli.c:485: warning: implicit declaration of function `completion_matches'
cli.c:485: warning: assignment makes pointer from integer without a cast
cli.c: In function `rl_init':
cli.c:499: warning: passing arg 2 of `rl_callback_handler_install' from
incompat ible pointer type
cli.c:500: warning: passing arg 2 of `rl_bind_key' from incompatible pointer
type
cli.c:501: warning: assignment from incompatible pointer type
rm -f libcli.a ar cru libcli.a cli.o
ranlib libcli.a
gcc  bridge.o stp_cli.o
stp_to.o -lutil -lreadline -ltermcap -lpthread -L. -lrst p -luid -lcli -o
bridge
gcc  -g -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 -DOLD_READLINE   -c -o
mngr.o mngr.c
gcc  mngr.o -lutil -lreadline -ltermcap -lpthread -L. -luid -lcli -o mngr
...
====
PLATFORM 3:
However, I tried it with Mandrake 8.1 and readline 4.2 is still fail......
MISS libtermcap!?
...
rm -f libcli.a
ar cru libcli.a cli.o
ranlib libcli.a
gcc  bridge.o stp_cli.o
stp_to.o -lutil -lreadline -ltermcap -lpthread -L. -lrst
p -luid -lcli -o bridge
/usr/bin/ld: cannot find -ltermcap
collect2: ld returned 1 exit status
make: *** [bridge] Error 1
...

[root@linux lib]# ls -la | grep termcap
lrwxrwxrwx    1 root     root           19  1月 15 23:15 libtermcap.so.2 ->
libtermcap.so.2.0.8*
-rwxr-xr-x    1 root     root        11992  7月 31 02:49
libtermcap.so.2.0.8*
====

I think the readline must have some problem with compatibility,
I am a newbie for 802.1w, still confused for status machine...... @_@||

thank you, Alex,

best regards,
--Ku

> Attached is a patch to solve readline version incompatibility problem.
> If you work with RedHat 7.2 and/or readline 4.2, delete the definition
> OLD_READLINE in CFLAGS in Makefile.
> In future there will be configure in our project, is there volunteer[s]?
>
> Best regards, Alex

[Rstplib-users] RE: [readline] RSTPLIB Installation Question!!

[<al...@nb...>]

On Sunday, December 02, 2001 12:16 PM Ku wrote:

Ku> Hi all,
Ku> 
Ku>     I want to install RSPTLIB on mandrake 7.2 kernel 
Ku> 2.2.14-15 platform
Ku>     I have also installed READLINE libe version 4.2 correctly.
Ku> 
Ku>     But I still fail with the folloeing situations,
Ku>     Could somebody tell me what is up!?
Ku>     thanks in advance,
Ku> 
Ku> --Ku   

Attached is a patch to solve readline version incompatibility problem.
If you work with RedHat 7.2 and/or readline 4.2, delete the definition
OLD_READLINE in CFLAGS in Makefile.
In future there will be configure in our project, is there volunteer[s]?

Best regards, Alex

[Rstplib-users] FW: [bzeeb+zebra@zabbadoz.net: [zebra 11865] [PATCH] updates libreadline support in vtysh, small bug in bgp_vty.c]

[<al...@nb...>]

It seems, that *readline* versions compatibility problem
is a well known one :(

----- Forwarded message from "Bjoern A. Zeeb"
<bze...@za...> -----

Date: Sat, 12 Jan 2002 19:23:27 +0100 (CET)
From: "Bjoern A. Zeeb" <bze...@za...>
X-Sender:  <bz...@no...>
To: Zebra ML <ze...@ze...>
cc: Kunihiro Ishiguro <kun...@ze...>
Reply-To: ze...@ze...
Precedence: bulk
X-Distribute: distribute [version 2.1 (Alpha1) patchlevel=26]
X-Sequence: zebra 11865
Subject: [zebra 11865] [PATCH] updates libreadline support in vtysh, small
bug in bgp_vty.c
Errors-To: own...@ze...

Hi,

attached patches fixes:

o small bug in bgp_vty.c introduced this afternoon in CVS tree
o libreadline support in vtysh
  seems there were some api changes there. make configure recognize
  which one is on the system (FreeBSD 4.4-STABLE only supprts the
  old one :( )
  please run autotools after applying

--
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Content-Description: zebra-cvs-20020112-003-bgp_vty.c-20020112-01.diff
--- zebra-cvs-20020112-003/bgpd/bgp_vty.c.orig	Sat Jan 12 19:07:28 2002
+++ zebra-cvs-20020112-003/bgpd/bgp_vty.c	Sat Jan 12 19:07:43 2002
@@ -8530,7 +8530,7 @@
   install_element (ENABLE_NODE, &clear_ip_bgp_as_vpnv4_soft_cmd);
 #ifdef HAVE_IPV6
   install_element (ENABLE_NODE, &clear_bgp_all_soft_cmd);
-  install_element (bgpm, ENABLE_NODE, &clear_bgp_instance_all_soft_cmd);
+  install_element (ENABLE_NODE, &clear_bgp_instance_all_soft_cmd);
   install_element (ENABLE_NODE, &clear_bgp_peer_soft_cmd);
   install_element (ENABLE_NODE, &clear_bgp_peer_group_soft_cmd);
   install_element (ENABLE_NODE, &clear_bgp_external_soft_cmd);

Content-Description: zebra-cvs-20020112-001-readline-fixes-20020112-02.diff
--- zebra-cvs-20020112-001.vanilla/./vtysh/vtysh.c	Mon Aug 20 08:35:35 2001
+++ zebra-cvs-20020112-001/./vtysh/vtysh.c	Sat Jan 12 17:06:44 2002
@@ -728,7 +728,12 @@
 {
   char **matches;

+#ifdef OLD_LIBREADLINE
   matches = completion_matches (text, command_generator);
+#else
+  matches = rl_completion_matches(text,
+			(rl_compentry_func_t *)command_generator);
+#endif

   if (matches)
     {
@@ -1580,7 +1585,12 @@
 {
   /* readline related settings. */
   rl_bind_key ('?', vtysh_rl_describe);
+#ifdef OLD_LIBREADLINE
   rl_completion_entry_function = vtysh_completion_entry_fucntion;
+#else
+  rl_completion_entry_function =
+		(rl_compentry_func_t *)vtysh_completion_entry_fucntion;
+#endif
   rl_attempted_completion_function = (CPPFunction *)new_completion;
   /* do not append space after completion. It will be appended
      in new_completion() function explicitly */
--- zebra-cvs-20020112-001.vanilla/./acconfig.h	Thu Aug 30 09:04:12 2001
+++ zebra-cvs-20020112-001/./acconfig.h	Sat Jan 12 17:07:23 2002
@@ -100,6 +100,9 @@
 /* Define if one-vty option is specified. */
 #undef VTYSH

+/* Define if we only find old libreadline */
+#undef OLD_LIBREADLINE
+
 /* Define if interface aliases don't have distinct indeces */
 #undef HAVE_BROKEN_ALIASES

--- zebra-cvs-20020112-001.vanilla/configure.in	Tue Oct 23 10:43:55 2001
+++ zebra-cvs-20020112-001/configure.in	Sat Jan 12 18:17:02 2002
@@ -200,9 +200,20 @@
          AC_CHECK_LIB(readline, main)
          if test $ac_cv_lib_readline_main = no; then
            AC_MSG_ERROR([vtysh needs libreadline but was not found on your
system.])
+	 else
+	   AC_CHECK_LIB(readline, rl_completion_matches)
+	   if test $ac_cv_lib_readline_rl_completion_matches = no; then
+		AC_CHECK_LIB(readline, completion_matches)
+		if test $ac_cv_lib_readline_completion_matches = no; then
+			AC_MSG_ERROR([vtysh needs libreadline but no supported version was found
on your system.])
+		else
+			AC_DEFINE(OLD_LIBREADLINE)
+			AC_MSG_WARN([your libreadline is old. please contact your vendor for
updates.])
+		fi
+	   fi
          fi
 	 AC_CHECK_HEADER(readline/history.h)
-	 if test $ac_cv_header_readline_history_h = no;then
+	 if test $ac_cv_header_readline_history_h = no; then
            AC_MSG_ERROR([readline is too old to have readline/history.h,
please update to the latest readline library.])
 	 fi
          ;;


----- End forwarded message -----

Re: [Rstplib-users] dot1dStpPortEnable/MAC Enabled/portEnabled/non-stp ports ?

[<alb...@ya...>]

I want to add to this list "Link status of the Port" -
Up/Down.
Albina

--- Imagine Talk <ter...@ya...> wrote: > Hi
All,
> 
> I would like to ask the clarifications for
> relations between these ideas:
> - dot1dStpPortEnable from BRIDGE-MIB (RFC 1493)
> - MAC Enabled from 6.4.2 of 802.1t
> - Disabled Port (802.1d, Clause 7.4 and Figure 8-3)
> - portEnabled (802.1w, Clause 17.18.15)
> - 'non-stp' port in "Open Source 802.1w Library &
> Simulator"
> 
> Actualy, I guess:
> does disabled Port participate in
> Forwarding process and is excluding only from STP
> operation,
> or it is exculding from the LAN, i.e. it is "dead"
> at
> all ?
> 
> Thanx, Imagine
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
>
https://lists.sourceforge.net/lists/listinfo/rstplib-users 

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

Re: [Rstplib-users] RSTPLIB Installation Question!!

[<alb...@ya...>]

Hi,
I have no problems with readline 2.2.1.
I suggest you to read "info readline" on you system -
it may help to find the workaround for your version.
Let me know, pls, the results: I probably will want
to install rstplib on a couple of stations.

Bina

 --- Ku <is...@ms...> wrote: > Hi all,
> 
>     I want to install RSPTLIB on mandrake 7.2 kernel
> 2.2.14-15 platform
>     I have also installed READLINE libe version 4.2
> correctly.
> 
>     But I still fail with the folloeing situations,
>     Could somebody tell me what is up!?
>     thanks in advance,
> 
> --Ku   
> 
> ====
> .
> .
> .
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 
>  -c -o p2p.o p2p.c
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 
>  -c -o edge.o edge.c
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 
>  -c -o pcost.o pcost.c
> rm -f librstp.a
> o pcost.o
> ranlib  librstp.a
> c
> rm -f libuid.a
> ar cru libuid.a uid_sock.o
> ranlib libuid.a
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1 
>  -c -o cli.o cli.c
> cli.c: In function `rl_read_cli':
> ible pointer type
> cli.c: In function `cli_private_completion':
> cli.c:470: warning: implicit declaration of function
> `completion_matches'
> cli.c:470: warning: assignment makes pointer from
> integer without a cast
> cli.c: In function `rl_init':
> ible pointer type
> e
> cli.c:483: warning: assignment from incompatible
> pointer type
> rm -f libcli.a
> ar cru libcli.a cli.o
> ranlib libcli.a
> cli -o bridge
> /usr/lib/libreadline.a(display.o): In function
> `rl_redisplay':
> display.o(.text+0xb6e): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(display.o): In function
> `update_line':
> display.o(.text+0x10de): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(display.o): In function
> `_rl_update_final':
> display.o(.text+0x16a7): undefined reference to
> `tputs'
> display.o(.text+0x16e8): undefined reference to
> `tputs'
> display.o(.text+0x177c): undefined reference to
> `tputs'
> puts' follow
> /usr/lib/libreadline.a(display.o): In function
> `delete_chars':
> display.o(.text+0x2059): undefined reference to
> `tgoto'
> display.o(.text+0x2068): undefined reference to
> `tputs'
> display.o(.text+0x2095): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(display.o): In function
> `insert_some_chars':
> display.o(.text+0x20c7): undefined reference to
> `tgoto'
> display.o(.text+0x20d7): undefined reference to
> `tputs'
> display.o(.text+0x210a): undefined reference to
> `tputs'
> display.o(.text+0x2138): undefined reference to
> `tputs'
> display.o(.text+0x216b): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(display.o): In function `cr':
> display.o(.text+0x2194): undefined reference to
> `tputs'
> puts' follow
> /usr/lib/libreadline.a(terminal.o): In function
> `_rl_get_screen_size':
> terminal.o(.text+0x8e): undefined reference to
> `tgetnum'
> terminal.o(.text+0xea): undefined reference to
> `tgetnum'
> /usr/lib/libreadline.a(terminal.o): In function
> `_rl_init_terminal_io':
> terminal.o(.text+0x1f3): undefined reference to
> `tgetent'
> terminal.o(.text+0x2d5): undefined reference to
> `tgetstr'
> terminal.o(.text+0x30c): undefined reference to `PC'
> terminal.o(.text+0x311): undefined reference to `BC'
> terminal.o(.text+0x31b): undefined reference to `UP'
> terminal.o(.text+0x36f): undefined reference to
> `tgetflag'
> terminal.o(.text+0x385): undefined reference to
> `tgetflag'
> terminal.o(.text+0x3d9): undefined reference to
> `tgetflag'
> terminal.o(.text+0x3ed): undefined reference to
> `tgetflag'
> /usr/lib/libreadline.a(terminal.o): In function
> `ding':
> terminal.o(.text+0x636): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(terminal.o): In function
> `_rl_backspace':
> terminal.o(.text+0x711): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(terminal.o): In function
> `_rl_enable_meta_key':
> terminal.o(.text+0x765): undefined reference to
> `tputs'
> /usr/lib/libreadline.a(terminal.o): In function
> `_rl_control_keypad':
> terminal.o(.text+0x796): undefined reference to
> `tputs'
> collect2: ld returned 1 exit status
> make: *** [bridge] Error 1
> ====
> 
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
>
https://lists.sourceforge.net/lists/listinfo/rstplib-users 

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

[Rstplib-users] dot1dStpPortEnable/MAC Enabled/portEnabled/non-stp ports ?

[Imagine T. <ter...@ya...>]

Hi All,

I would like to ask the clarifications for
relations between these ideas:
- dot1dStpPortEnable from BRIDGE-MIB (RFC 1493)
- MAC Enabled from 6.4.2 of 802.1t
- Disabled Port (802.1d, Clause 7.4 and Figure 8-3)
- portEnabled (802.1w, Clause 17.18.15)
- 'non-stp' port in "Open Source 802.1w Library &
Simulator"

Actualy, I guess:
does disabled Port participate in
Forwarding process and is excluding only from STP
operation,
or it is exculding from the LAN, i.e. it is "dead" at
all ?

Thanx, Imagine




__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

[Rstplib-users] RE: RSTP questions

[<al...@nb...>]

Albina,

{First, as Loren asked, could you avoid from posting pretty rstplib oriented
questions to 802.1 mailing list, please].

Now your questions:

On Monday, January 14, 2002 5:24 PM Albina Krigma-Lee asked:

Albina> 1. What does command 'ring' of 'mngr' do?

This command is an easy tool to organize a ring from virtual "bridges".
Its implementation has 2 states. On the first stages all ports on all
'bridges'
are being disconnected (I mean, 'mngr' calls command 'unlink'
in loop). On the second stage the second port on every  'bridge' (if it is
not last one) is connected to first port of next 'bridge'  and the second
port of the last 'bridge ' is connected to the first port of the first
'bridge'.
(sorry for so complicated definition).

Albina> 2. What do variables 'tev' and 'nev' in stp_in.c mean?

These variables I use for the debugging.
'tev' describes the type of event, that caused the current state machines
recalculation. All possible values of 'tev' you may find in the definition
of
enum RSTP_EVENT_T, defined in stp_In.c
The variable 'nev' is a circular counter of such event.
In RSTP simulator I don't show these variables, but in the real product
I print them as part of the prefix of  'stp_trace'. Example of the trace:

16:48:49.28:T:30:topoch  (_SNGL_-1.04): INACTIVE=>TCACTIVE
16:48:51.38:r:34:sttrans (_SNGL_-1.04): DISCARDING=>LEARNING
16:48:51.45:r:34:sttrans (_SNGL_-1.04): LEARNING=>FORWARDING
16:48:51.52:r:34:topoch  (_SNGL_-1.04): TCACTIVE=>DETECTED
16:48:51.58:r:34:DETECTED: tcWhile=4 on port 1.04
16:48:51.63:r:34:clearFDB (1.04, _SNGL_, other ports, 'DETECTED')
16:48:51.70:r:34:topoch  (_SNGL_-1.04): DETECTED=>TCACTIVE
16:48:53.01:r:36:topoch  (_SNGL_-1.04): TCACTIVE=>NOTIFIED_TC
16:48:53.07:r:36:clearFDB (1.04, _SNGL_, other ports, 'NOTIFIED_TC')
16:48:53.15:r:36:topoch  (_SNGL_-1.04): NOTIFIED_TC=>TCACTIVE
16:48:53.26:T:37:tcWhile=2 =>tx TOPOLOGY_CHANGE_BIT to port 1.04

Albina> 3. What does 802.1y mean?

It is a maintenance of IEEE 802.1w. Its full name is:"DRAFT IEEE Standard
for Local and Metropolitan Area Networks—Media
Access Control (MAC) Bridges—Amendment 3: Technical and
Editorial Corrections". This standard documents technical and editorial
corrections to IEEE Std 802.1D, 1998Edition, as modified
by IEEE Std 802.1t-2001 (Amendment 1) and
IEEE Std 802.1w-2001 (Amendment 2).

Albina> 4. Why the command set of 'bridge' does not contain
Albina> an option to change 'dot1dStpPathCostDefault' ?

You are right, the RSTP-MIB draft contains it. I have two justifications:
a) this MIB is a draft and has not been accepted as an official standard
b) IEEE Std. 802.1w doesn't not contain this object in 14.8.
Anyway, I'm going to implement it, but in the future.

Albina> 5. Why the format of reply on command "show port"
Albina> is different from format of reply on command
Albina> "show port 1".

OK, when you ask state of one port, the reply contains a detail information
of this port. When you don't define a port number, the reply contains
a brief information about all ports of the 'bridge'.

Albina> 6. What are "RSTP BPDU rx", "CONFIG BPDU rx" and
Albina> "TCN BPDU rx" ?

These are counters of all types of BPDUs, received on the port

Albina> 7. How many 'bridges' may RSTPlib simulate?

The 'mngr' contains a list of 'bridges' and doesn't have a limitation.
As far as I see, the may be only regular system limitations of memory
and number of opened sockets.
From other side, I suppose, that every 'bridge' will be opened in separate
shell; how mane shells can you open and watch ?

Best regards, Alex

[Rstplib-users] RE: RSTP Library & Simulator version 1.1.01 available

[<al...@nb...>]

Dear Mr. Ken,

[First, I forward your question to the mailing list while
it may have interest for other rstplib users. Let me know
if you would like to avoid it]

It seems, that you don't have readline installed.
Try to ask:
"rpm -q readline" from your shell and send me the reply.
(may be your version is specific one, and I have to find
a solution for it).
You may also ask "man readline" and "info readline".

I didn't think, that 'readline' will cause problems (see, also the thread
"[Rstplib-users] RSTPLIB Installation Question!!" of Ku; he has mandrake 7.2
kernel
2.2.14-15 platform, readline version 4.2).
As I replied to Ku, I work in RedHat 6.2 with readline 2.2.1.

Since there is so many problems with readline, I have to propose
a "gets()"-oriented simpler version, haven't I ? It will be more system
independent,
by less nice and comfortable. So, I guess and would like to put off the
conclusion

Best wishes, Alex

On Tuesday, January 15, 2002 3:14 AM Ken Lin wrote:

Ken> Alex,
Ken>
Ken> Good job!
Ken>
Ken> I tried to build it in netBSD and got the following
Ken> unresolved. Would you mind mail me the source of these
Ken> routines so that I
Ken> get it built. Thanks.
Ken>
Ken> bsd/config/stp/rstp/bridge/bridge.c:274: Undefined symbol
Ken> `_rl_callback_read_char'
Ken>  referenced from text segment
Ken> bsd/config/stp/rstp/uid/uid_sock.c:95: warning: tmpnam()
Ken> possibly used unsafely, u
Ken> se mkstemp() or mkdtemp()
Ken> bsd/config/stp/rstp/cli/cli.c:377: Undefined symbol
Ken> `_rl_callback_handler_remove'
Ken> referenced from text segment
Ken> bsd/config/stp/rstp/cli/cli.c:388: Undefined symbol
Ken> `_rl_callback_handler_install'
Ken>  referenced from text segment
Ken> bsd/config/stp/rstp/cli/cli.c:460: Undefined symbol
Ken> `_rl_on_new_line' referenced f
Ken> rom text segment
Ken> bsd/config/stp/rstp/cli/cli.c:481: Undefined symbol
Ken> `_rl_callback_handler_install'
Ken>  referenced from text segment
Ken>
Ken> Ken

> > On Wednesday, January 09, 2002 11:10 PM Alex Ruzin wrote:
>  > Hi All,
> > I am happy to announce, that first
> > stable release of single
> > instance RSTP after successful
> > (I hope so) alpha & beta testing
> > stages is available from
> > https://sourceforge.net/project/showfiles.php?group_id=39646
> >
> > I want to thank all of you for your questions/remarks/feedbacks.
> >
> > Best regards, Alex

RE: [Rstplib-users] RE: RSTP questions

[<al...@nb...>]

Hi,

Mr. Loren is completely right.
I would like to ask all RSTPlib users to forbear from
posting RSTPlib related command to 802.1 mailing list.
Sorry, Alex

On Monday, January 14, 2002 6:50 PM Loren Larsen wrote:

Loren > Would it be inappropriate to suggest taking discussion of the 
Loren > RSTPLIB off the 802.1 mailing list since presumably there is 
Loren > an rstplib-users mailing list and if one cared about that 
Loren > they would subscribe to it?
Loren > 
Loren > Thanks,
Loren > 
Loren > Loren
> 
> 
> -----Original Message-----
> From: Albina Krigma-Lee [mailto:alb...@ya...]
> Sent: Monday, January 14, 2002 7:24 AM
> To: rst...@li...
> Cc: std...@ie...
> Subject: RSTP questions
> 
> 
> 
> Hi All,
> I have questions about RSTP:
> 1. What does command 'ring' of 'mngr' ?
> 2. What do mean variables 'tev' and 'nev' in stp_in.c
> 3. What does mean 802.1y and 'relevant' changes ?
> 4. Why the command set of 'bridge' does not contain
> an option to change 'dot1dStpPathCostDefault' ?
> 5. Why the format of reply on command "show port"
> is different from format of reply on command
> "show port 1".
> 6. What are "RSTP BPDU rx", "CONFIG BPDU rx" and
> "TCN BPDU rx" ?
> 7. How many 'bridges' may RSTPlib simulate ?
> 
> Thanks, Albina
> 
> http://my.yahoo.com.au - My Yahoo!
> - It's My Yahoo! Get your own!
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
> https://lists.sourceforge.net/lists/listinfo/rstplib-users

[Rstplib-users] RE: RSTP questions

[Loren L. <Lor...@wo...>]

Hello Albina,

As far as I can tell all your questions are pretty specific to rstplib =
and don't appear to impact the work of 802.1.  Would it be appropriate =
for me to suggest not sending issues about this specific implementation =
to the 802-1 list?  I'm sure that those .1 members interested in rstplib =
can join the rstplib mailing list if they would like.

Thanks,

Loren

-----Original Message-----
From: Albina Krigma-Lee [mailto:alb...@ya...]
Sent: Monday, January 14, 2002 7:24 AM
To: rst...@li...
Cc: std...@ie...
Subject: RSTP questions



Hi All,
I have questions about RSTP:
1. What does command 'ring' of 'mngr' ?
2. What do mean variables 'tev' and 'nev' in stp_in.c
3. What does mean 802.1y and 'relevant' changes ?
4. Why the command set of 'bridge' does not contain
an option to change 'dot1dStpPathCostDefault' ?
5. Why the format of reply on command "show port"
is different from format of reply on command
"show port 1".
6. What are "RSTP BPDU rx", "CONFIG BPDU rx" and
"TCN BPDU rx" ?
7. How many 'bridges' may RSTPlib simulate ?

Thanks, Albina

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

[Rstplib-users] RE: RSTP questions

[Loren L. <Lor...@wo...>]

Would it be inappropriate to suggest taking discussion of the RSTPLIB =
off the 802.1 mailing list since presumably there is an rstplib-users =
mailing list and if one cared about that they would subscribe to it?

Thanks,

Loren


-----Original Message-----
From: Albina Krigma-Lee [mailto:alb...@ya...]
Sent: Monday, January 14, 2002 7:24 AM
To: rst...@li...
Cc: std...@ie...
Subject: RSTP questions



Hi All,
I have questions about RSTP:
1. What does command 'ring' of 'mngr' ?
2. What do mean variables 'tev' and 'nev' in stp_in.c
3. What does mean 802.1y and 'relevant' changes ?
4. Why the command set of 'bridge' does not contain
an option to change 'dot1dStpPathCostDefault' ?
5. Why the format of reply on command "show port"
is different from format of reply on command
"show port 1".
6. What are "RSTP BPDU rx", "CONFIG BPDU rx" and
"TCN BPDU rx" ?
7. How many 'bridges' may RSTPlib simulate ?

Thanks, Albina

http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!

RE: [Rstplib-users] RSTPLIB Installation Question!!

[<al...@nb...>]

Hi,
I work in RedHat 6.2 with readline 2.2.1.
I will try to compile rstplib with readline 4.2 and
will let you know about the results in a few days.
Best wishes, Alex

> -----Original Message-----
> From: rst...@li... 
> [mailto:rst...@li...]On Behalf Of Ku
> Sent: Sunday, December 02, 2001 12:16 PM
> To: rst...@li...
> Subject: [Rstplib-users] RSTPLIB Installation Question!!
> 
> 
> Hi all,
> 
>     I want to install RSPTLIB on mandrake 7.2 kernel 
> 2.2.14-15 platform
>     I have also installed READLINE libe version 4.2 correctly.
> 
>     But I still fail with the folloeing situations,
>     Could somebody tell me what is up!?
>     thanks in advance,
> 
> --Ku   
> 
> ====
> .
> .
> .
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1   -c -o 
> p2p.o p2p.c
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1   -c -o 
> edge.o edge.c
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1   -c -o 
> pcost.o pcost.c
> rm -f librstp.a
> o pcost.o
> ranlib  librstp.a
> c
> rm -f libuid.a
> ar cru libuid.a uid_sock.o
> ranlib libuid.a
> gcc  -g  -Wall -D_REENTRANT -D__LINUX__ -DSTP_DBG=1   -c -o 
> cli.o cli.c
> cli.c: In function `rl_read_cli':
> ible pointer type
> cli.c: In function `cli_private_completion':
> cli.c:470: warning: implicit declaration of function 
> `completion_matches'
> cli.c:470: warning: assignment makes pointer from integer 
> without a cast
> cli.c: In function `rl_init':
> ible pointer type
> e
> cli.c:483: warning: assignment from incompatible pointer type
> rm -f libcli.a
> ar cru libcli.a cli.o
> ranlib libcli.a
> cli -o bridge
> /usr/lib/libreadline.a(display.o): In function `rl_redisplay':
> display.o(.text+0xb6e): undefined reference to `tputs'
> /usr/lib/libreadline.a(display.o): In function `update_line':
> display.o(.text+0x10de): undefined reference to `tputs'
> /usr/lib/libreadline.a(display.o): In function `_rl_update_final':
> display.o(.text+0x16a7): undefined reference to `tputs'
> display.o(.text+0x16e8): undefined reference to `tputs'
> display.o(.text+0x177c): undefined reference to `tputs'
> puts' follow
> /usr/lib/libreadline.a(display.o): In function `delete_chars':
> display.o(.text+0x2059): undefined reference to `tgoto'
> display.o(.text+0x2068): undefined reference to `tputs'
> display.o(.text+0x2095): undefined reference to `tputs'
> /usr/lib/libreadline.a(display.o): In function `insert_some_chars':
> display.o(.text+0x20c7): undefined reference to `tgoto'
> display.o(.text+0x20d7): undefined reference to `tputs'
> display.o(.text+0x210a): undefined reference to `tputs'
> display.o(.text+0x2138): undefined reference to `tputs'
> display.o(.text+0x216b): undefined reference to `tputs'
> /usr/lib/libreadline.a(display.o): In function `cr':
> display.o(.text+0x2194): undefined reference to `tputs'
> puts' follow
> /usr/lib/libreadline.a(terminal.o): In function `_rl_get_screen_size':
> terminal.o(.text+0x8e): undefined reference to `tgetnum'
> terminal.o(.text+0xea): undefined reference to `tgetnum'
> /usr/lib/libreadline.a(terminal.o): In function 
> `_rl_init_terminal_io':
> terminal.o(.text+0x1f3): undefined reference to `tgetent'
> terminal.o(.text+0x2d5): undefined reference to `tgetstr'
> terminal.o(.text+0x30c): undefined reference to `PC'
> terminal.o(.text+0x311): undefined reference to `BC'
> terminal.o(.text+0x31b): undefined reference to `UP'
> terminal.o(.text+0x36f): undefined reference to `tgetflag'
> terminal.o(.text+0x385): undefined reference to `tgetflag'
> terminal.o(.text+0x3d9): undefined reference to `tgetflag'
> terminal.o(.text+0x3ed): undefined reference to `tgetflag'
> /usr/lib/libreadline.a(terminal.o): In function `ding':
> terminal.o(.text+0x636): undefined reference to `tputs'
> /usr/lib/libreadline.a(terminal.o): In function `_rl_backspace':
> terminal.o(.text+0x711): undefined reference to `tputs'
> /usr/lib/libreadline.a(terminal.o): In function `_rl_enable_meta_key':
> terminal.o(.text+0x765): undefined reference to `tputs'
> /usr/lib/libreadline.a(terminal.o): In function `_rl_control_keypad':
> terminal.o(.text+0x796): undefined reference to `tputs'
> collect2: ld returned 1 exit status
> make: *** [bridge] Error 1
> ====
> 
> 
> _______________________________________________
> Rstplib-users mailing list
> Rst...@li...
> https://lists.sourceforge.net/lists/listinfo/rstplib-users