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

[Rstplib-users] RSTP questions

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

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 will check the problem and reply in nearest future.
Best regards, 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

[Rstplib-users] RSTPLIB Installation Question!!

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

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] RSTP Library & Simulator version 1.1.01 available

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

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

[Rstplib-users] p2p state machine ?

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

Alex,

I've download your Open Source 802.1w Library &
Simulator.
Now I have a question, and I hope, there will be a
number of questions :)
What is p2p state machine ? It concerns
operPointToPoint valiable, doesn't it ?
Why do you check "duplex" mode of the Port ?
I don't find such machine in .1w :(

Imagine

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

[Rstplib-users] RE: 802.1w: 3 questions about flushing

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

Alex, thank you, but I am not sure, that undesrtand
you :(
How may txHoldTimer "prevent" tcWhile decrementing ?
What do you mean under "driver below STP engine" ?
Why in .1s there is no clarifications about flushing ?
Albina


 --- Alex Ruzin <al...@nb...> wrote: > 
> On Monday, January 07, 2002 Albina Krigma-Lee wrote:
> 
> Albina > Question 1. tcWhile decrementing.
> Albina > When Topology Change is DETECTED, the timer
> tcWhile
> Albina > accepts a value 4 (twice HelloTime). Then,
> the PTM binds
> Albina > "topology change flag" in BPDU. While in
> pure RSTP
> Albina > LAN there are no "topology change
> acknowledgements",
> Albina > this timer is decremented until 0 "by
> natural".
> Albina > So, there are 2 outgoing BPDU with
> "topology change
> Albina > flag": the Albina > first – when tcWhile=4;
> the second
> Albina > – when tcWhile=2.
> Albina > If the considerations above are right, it
> seems, that Alex is
> Albina > optimist: it will be "triple" flushing, not
> double!
> 
Alex> I would like to believe, that txHoldTimer will
Alex> prevent it
> 
> Albina > Question 2. Do we have to make FDB flushing
> for a
> Albina > Port when this Port becomes "Disabled" (or,
> let us
> Albina > say, Albina > macOperational=FALSE).
> Albina >
> Albina > Let us consider a Bridge and 2 stations U1
> and U2.
> Albina > Station U1 is connected to Port P1; station
> U2 - to
> Albina > Port P2.
> Albina > Station U2 sends ping responses to U2 and
> receives
> Albina > ping replies from it.
> Albina >
> Albina > Now we disconnect U2 from P2 and connect it
> to the
> Albina > Port P3.
> Albina >
> Albina > While station U2 is silent (it acts as
> "passive" echo
> Albina > server and doesn't send anything without
> request) and
> Albina > Filtering Database entry that holds U2 on
> Port P2 continues to
> Albina > be valid, the Bridge forwards  responds to
> "disabled" Port P2.
> Albina > So, the poor U1 will not see U2 until ARP
> entry aging Albina > :(
> 
> I think, Bridge does have to make flushing on Link
> Down, but it seems to be
> a business of some driver below STP engine. The same
> problem will be
> without STP, will not it ?
> 
> Albina > Question 3. In 1s: Do we have to make
> flushing per all
> Albina > tags  in an MSTi ?
> 
Alex> IMHO, yes.
> 
> Albina > And what about CSTi ?
Alex> I don't sure, IMHO in CSTi the function flush()
must
Alex> flush *all* entries of
Alex> the Port,
Alex> I mean for all tags. Anyway, let's wait for
Alex> explanations from WG :)
> 
> Albina > Yours truly, Albina
> 
Alex> Best regards, Alex
Alex> ---------------------
Alex> Open Source RSTP 
Alex> https://sourceforge.net/projects/rstplib/
Alex> Optical Access Ltd. http://www.opticalaccess.com
>  

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

[Rstplib-users] RE: 802.1w: double flushing in simplest case ?

[Mick S. <mic...@ie...>]

I agree with Shyam that correctness is the goal here. Efficiency in flushing
is essentially an implementation issue (of a single bridge) and the standard
is not responsible for dumb implementations where every entry has to be
physically removed from a database to flush it (and the databse
reorganized).

At the absolute minimum each entry in a well designed database should have a
DELETED bit, because it is almost a certainty that it will be relearnt
unless the station or bridge has been removed from the net. It is perfectly
possible to design a database such that it can be flushed by changing a
single central variable (just need a couple more bits on each entry).

This really an implementation discussion since the number of options is so
wide, especially with 'flow' based databases that extend the bridges
functionality. Some tradeoff aganist the speed of relearning is also
possible if you are realy stuck. Obviously if you expect two messages
carrying a topology change a little bit more flooding would allow you to
wait for the second before starting learning again. A wide variety of
options are there for anyone who cares to do the performance analysis. This
is of course best done before building your bridge, but a bridge that was
efficient at database operations to support earlier .1D should continue to
be so.

Mick

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Shyam Kaluve
Sent: Sunday, January 06, 2002 11:10 PM
To: Ar...@op...
Cc: std...@ie...; rst...@li...
Subject: RE: 802.1w: double flushing in simplest case ?



Alex,

When a p2p link comes up and becomes part of the active topology, both
ports connected by that link become topology change initiators. The set of
ports that will be flushed for each of the initiators will be different,
but yes, there will be a substantial number of ports common to both the
sets and flushed twice.

For correctness you will need to flush the minimum set of ports only once.
But since this operation is performed by each bridge in its own pace, once
may be not enough. The residual traffic as the topology is converging may
cause some ports to learn wrong destinations. So IMHO the standard should
lean towards correctness than efficiency in this case. Next generation of
bridge hardware will be more 802.1w friendly so this question may become
moot.

-shyam

Note: All disclaimers apply.

At 10:24 AM 1/6/2002 +0200, Alex Ruzin wrote:
>Ladies & Gentlemen !
>Excuse me, routers & brouters are very interesting devices,
>but what about my original question (double flushing in regular bridges) ?
>Best regards, Alex

RE: [Rstplib-users] RE: 802.1w: 3 questions about flushing

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

On Monday, January 07, 2002 Albina Krigma-Lee wrote:

Albina > Question 1. tcWhile decrementing.
Albina > When Topology Change is DETECTED, the timer tcWhile
Albina > accepts a value 4 (twice HelloTime). Then, the PTM binds
Albina > "topology change flag" in BPDU. While in pure RSTP
Albina > LAN there are no "topology change acknowledgements",
Albina > this timer is decremented until 0 "by natural".
Albina > So, there are 2 outgoing BPDU with "topology change
Albina > flag": the Albina > first – when tcWhile=4; the second
Albina > – when tcWhile=2.
Albina > If the considerations above are right, it seems, that Alex is
Albina > optimist: it will be "triple" flushing, not double!

I would like to believe, that txHoldTimer will prevent it

Albina > Question 2. Do we have to make FDB flushing for a
Albina > Port when this Port becomes "Disabled" (or, let us
Albina > say, Albina > macOperational=FALSE).
Albina >
Albina > Let us consider a Bridge and 2 stations U1 and U2.
Albina > Station U1 is connected to Port P1; station U2 - to
Albina > Port P2.
Albina > Station U2 sends ping responses to U2 and receives
Albina > ping replies from it.
Albina >
Albina > Now we disconnect U2 from P2 and connect it to the
Albina > Port P3.
Albina >
Albina > While station U2 is silent (it acts as "passive" echo
Albina > server and doesn't send anything without request) and
Albina > Filtering Database entry that holds U2 on Port P2 continues to
Albina > be valid, the Bridge forwards  responds to "disabled" Port P2.
Albina > So, the poor U1 will not see U2 until ARP entry aging Albina > :(

I think, Bridge does have to make flushing on Link Down, but it seems to be
a business of some driver below STP engine. The same problem will be
without STP, will not it ?

Albina > Question 3. In 1s: Do we have to make flushing per all
Albina > tags  in an MSTi ?

IMHO, yes.

Albina > And what about CSTi ?
I don't sure, IMHO in CSTi the function flush() must flush *all* entries of
the Port,
I mean for all tags. Anyway, let's wait for explanations from WG :)

Albina > Yours truly, Albina

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

Re: [Rstplib-users] RE: 802.1w: 3 questions about flushing

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

Hi All,
I have 3 questions about FDB flushing in .1w & .1s.

Question 1. tcWhile decrementing.
When Topology Change is DETECTED, the timer tcWhile
accepts
a value 4 (twice HelloTime). Then, the PTM binds
"topology
change flag" in BPDU. While in pure RSTP LAN there are
no
"topology change acknowledgements", this timer is
decremented
until 0 "by natural".
So, there are 2 outgoing BPDU with "topology change
flag": the
first – when tcWhile=4; the second – when tcWhile=2.
If the
considerations above are right, it seems, that Alex is
optimist:
it will be "triple" flushing, not double!

Question 2. Do we have to make FDB flushing for a
Port when this Port becomes "Disabled" (or, let us
say,
macOperational=FALSE).

Let us consider a Bridge and 2 stations U1 and U2.
Station U1 is connected to Port P1; station U2 - to
Port P2.
Station U2 sends ping responses to U2 and receives
ping
replies from it.

Now we disconnect U2 from P2 and connect it to the
Port P3.

While station U2 is silent (it acts as "passive" echo
server
and doesn't send anything without request) and
Filtering
Database entry that holds U2 on Port P2 continues to
be
valid, the Bridge forwards  responds to "disabled"
Port P2.
So, the poor U1 will not see U2 until ARP entry aging
:(

Question 3. In 1s: Do we have to make flushing per all
tags
in an MSTi ? And what about CSTi ?

Yours truly, Albina

 --- Shyam Kaluve <sk...@ci...> wrote: > Alex,
> 
> When a p2p link comes up and becomes part of the
> active topology, both
> ports connected by that link become topology change
> initiators. The set of
> ports that will be flushed for each of the
> initiators will be different,
> but yes, there will be a substantial number of ports
> common to both the
> sets and flushed twice.
> 
> For correctness you will need to flush the minimum
> set of ports only once.
> But since this operation is performed by each bridge
> in its own pace, once
> may be not enough. The residual traffic as the
> topology is converging may
> cause some ports to learn wrong destinations. So
> IMHO the standard should
> lean towards correctness than efficiency in this
> case. Next generation of
> bridge hardware will be more 802.1w friendly so this
> question may become
> moot.
> 
> -shyam
> 
> Note: All disclaimers apply.
> 
> At 10:24 AM 1/6/2002 +0200, Alex Ruzin wrote:
> >Ladies & Gentlemen !
> >Excuse me, routers & brouters are very interesting
> devices,
> >but what about my original question (double
> flushing in regular bridges) ?
> >Best regards, Alex
> 
> 
> _______________________________________________
> 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] RE: 802.1w: double flushing in simplest case ?

[Shyam K. <sk...@ci...>]

Alex,

When a p2p link comes up and becomes part of the active topology, both
ports connected by that link become topology change initiators. The set of
ports that will be flushed for each of the initiators will be different,
but yes, there will be a substantial number of ports common to both the
sets and flushed twice.

For correctness you will need to flush the minimum set of ports only once.
But since this operation is performed by each bridge in its own pace, once
may be not enough. The residual traffic as the topology is converging may
cause some ports to learn wrong destinations. So IMHO the standard should
lean towards correctness than efficiency in this case. Next generation of
bridge hardware will be more 802.1w friendly so this question may become
moot.

-shyam

Note: All disclaimers apply.

At 10:24 AM 1/6/2002 +0200, Alex Ruzin wrote:
>Ladies & Gentlemen !
>Excuse me, routers & brouters are very interesting devices,
>but what about my original question (double flushing in regular bridges) ?
>Best regards, Alex

[Rstplib-users] RE: 802.1w: double flushing in simplest case ?

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

Ladies & Gentlemen !
Excuse me, routers & brouters are very interesting devices,
but what about my original question (double flushing in regular bridges) ?
Best regards, Alex

> -----Original Message-----
> From: own...@ma... 
> [mailto:own...@ma...]On Behalf Of Vipin Jain
> Sent: Thursday, January 03, 2002 7:11 PM
> To: Albina Krigma-Lee; Tony Jeffree
> Cc: std...@ie...; rst...@li...
> Subject: RE: 802.1w: double flushing in simplest case ?
> 
> 
> 
> Albina,
> 
> RSTP or bridging does not interfere with routing function. I suspect
> that you are talking about a bridge-router (brouter as it used to be
> called). RSTP is a no-op in a pure router.
> 
> In a brouter, you do not need to unresolve ARP entries or next hop
> information. Typically, you would have a number of bridged ports (part
> of the same layer 2 domain) and an IP interface (virtualized) 
> sitting on
> top of each such set of ports. Next hop in a routing table 
> will point to
> this virtual IP interface as the outbound interface. ARP resolution is
> also above the bridging function and hence does not need to change
> irrespective of what happens to bridge ports in the domain. 
> All it means
> is that a packet will be submitted to an appropriate IP interface for
> forwarding, you also know the MAC address of next hop router, just do
> not know which physical (bridge) port the packet should go out of.
> Because addresses have been flushed on these bridge ports, 
> such a packet
> will be flooded in the corresponding layer 2 domain.
> 
> Of course, if you change the IP address to MAC address 
> association for a
> device, no bridging will help you. That's why you have mechanisms such
> as gratuitous ARP (all layer 3 functions).
> 
> Hope it helps.
> 
> Vipin
> 
> -----Original Message-----
> From: Albina Krigma-Lee [mailto:alb...@ya...]
> Sent: Thursday, January 03, 2002 7:23 AM
> To: Tony Jeffree
> Cc: std...@ie...; rst...@li...
> Subject: Re: 802.1w: double flushing in simplest case ?
> 
> 
> 
> I see, but it seems that learning entries
> flushing/ageing must unresolve ARP entries and
> NextHops in FIB. So I quess, the double
> flushing could be really expencive cost of RSTP.
> Or Alex isn't right ?
> Sincerely, Albina Krigma-Lee
> 
>  --- Tony Jeffree <to...@je...> wrote:
> > The RSTP standard defines the operation of RSTP
> > bridges - it has nothing to 
> > say on the subject of routers.
> > 
> > Regards,
> > Tony
> > 
> > At 00:05 04/01/2002 +1100, Albina Krigma-Lee wrote:
> > 
> > >Hi All,
> > >If RSTP operates in a router and makes flush()
> > >function, do it have to delete Forwarding
> > Information
> > >Base (FIB) entries too ?
> > >
> > >Thanks in advance, albina
> > >
> > >
> > >http://my.yahoo.com.au - My Yahoo!
> > >- It's My Yahoo! Get your own!
> > 
> >  
> 
> http://my.yahoo.com.au - My Yahoo!
> - It's My Yahoo! Get your own!
> 
> 

[Rstplib-users] RE: 802.1w: double flushing in simplest case ?

[Vipin J. <vi...@te...>]

Albina,

RSTP or bridging does not interfere with routing function. I suspect
that you are talking about a bridge-router (brouter as it used to be
called). RSTP is a no-op in a pure router.

In a brouter, you do not need to unresolve ARP entries or next hop
information. Typically, you would have a number of bridged ports (part
of the same layer 2 domain) and an IP interface (virtualized) sitting on
top of each such set of ports. Next hop in a routing table will point to
this virtual IP interface as the outbound interface. ARP resolution is
also above the bridging function and hence does not need to change
irrespective of what happens to bridge ports in the domain. All it means
is that a packet will be submitted to an appropriate IP interface for
forwarding, you also know the MAC address of next hop router, just do
not know which physical (bridge) port the packet should go out of.
Because addresses have been flushed on these bridge ports, such a packet
will be flooded in the corresponding layer 2 domain.

Of course, if you change the IP address to MAC address association for a
device, no bridging will help you. That's why you have mechanisms such
as gratuitous ARP (all layer 3 functions).

Hope it helps.

Vipin

-----Original Message-----
From: Albina Krigma-Lee [mailto:alb...@ya...]
Sent: Thursday, January 03, 2002 7:23 AM
To: Tony Jeffree
Cc: std...@ie...; rst...@li...
Subject: Re: 802.1w: double flushing in simplest case ?



I see, but it seems that learning entries
flushing/ageing must unresolve ARP entries and
NextHops in FIB. So I quess, the double
flushing could be really expencive cost of RSTP.
Or Alex isn't right ?
Sincerely, Albina Krigma-Lee

 --- Tony Jeffree <to...@je...> wrote:
> The RSTP standard defines the operation of RSTP
> bridges - it has nothing to=20
> say on the subject of routers.
>=20
> Regards,
> Tony
>=20
> At 00:05 04/01/2002 +1100, Albina Krigma-Lee wrote:
>=20
> >Hi All,
> >If RSTP operates in a router and makes flush()
> >function, do it have to delete Forwarding
> Information
> >Base (FIB) entries too ?
> >
> >Thanks in advance, albina
> >
> >
> >http://my.yahoo.com.au - My Yahoo!
> >- It's My Yahoo! Get your own!
>=20
> =20

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

[Rstplib-users] Re: 802.1w: double flushing in simplest case ?

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

I see, but it seems that learning entries
flushing/ageing must unresolve ARP entries and
NextHops in FIB. So I quess, the double
flushing could be really expencive cost of RSTP.
Or Alex isn't right ?
Sincerely, Albina Krigma-Lee

 --- Tony Jeffree <to...@je...> wrote:
> The RSTP standard defines the operation of RSTP
> bridges - it has nothing to 
> say on the subject of routers.
> 
> Regards,
> Tony
> 
> At 00:05 04/01/2002 +1100, Albina Krigma-Lee wrote:
> 
> >Hi All,
> >If RSTP operates in a router and makes flush()
> >function, do it have to delete Forwarding
> Information
> >Base (FIB) entries too ?
> >
> >Thanks in advance, albina
> >
> >
> >http://my.yahoo.com.au - My Yahoo!
> >- It's My Yahoo! Get your own!
> 
>  

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

[Rstplib-users] Re: 802.1w: double flushing in simplest case ?

[Tony J. <to...@je...>]

The RSTP standard defines the operation of RSTP bridges - it has nothing to 
say on the subject of routers.

Regards,
Tony

At 00:05 04/01/2002 +1100, Albina Krigma-Lee wrote:

>Hi All,
>If RSTP operates in a router and makes flush()
>function, do it have to delete Forwarding Information
>Base (FIB) entries too ?
>
>Thanks in advance, albina
>
>
>http://my.yahoo.com.au - My Yahoo!
>- It's My Yahoo! Get your own!

[Rstplib-users] Re: 802.1w: double flushing in simplest case ?

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

Hi All,
If RSTP operates in a router and makes flush()
function, do it have to delete Forwarding Information
Base (FIB) entries too ?

Thanks in advance, albina


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

[Rstplib-users] subscribe

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

subscribe

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

[Rstplib-users] RE: Max Bridge Diameter

[Alexandr R. <ter...@ya...>]

Hmmm...
Are the Alex's consideration & conclusion right ?
It seems to be drastic, isn't it ?
May you provide more comments, please ?
Thanx, Imagine 

Apropos, Alex, what is "Open Source RSTP" ?

--- Mick Seaman [mailto:mic...@ie...]:
> 
> The assumption in .1w is that legacy STP  bridges
> may always 
> be present so
> Abnnex B always applies.
>  
> --- On January 02, 2002 3:22 AM Alex Ruzin wrote:

> > Hi,
> > 
> > We didn't find in 802.1w the reason for the upper
> boundaries on
> > Bridge Max Age and Maximum Bridge Diameter. We are
> testing a scenario
> > where there are no legacy STP Bridges in the LAN
> so Annex B is not
> > relevant.
> > 
> > Let's consider a chain of n RSTP Bridges:
> > 
> > B1----B2-----B3-----........ 
> ---------Bx--------........---------Bn
> > 
> > B1 is the Root bridge.
> <snip>
> 
> > 
> > Could you help us with the following questions:
> > 1. Did we make a mistake in the above
> calculations?
> > 2. What is the theoretical background of the
> statement "the greater of
> > (1/16th Max
> > Age) and 1 second, and rounded to the nearest
> whole second" in Clauses
> > 17.19.19 and 17.19.21 ?
> > 3. What is a reasonable limitation of RSTP LAN
> diameter ?
> > 
> > Best regards,
> > Alex
> > 


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

[Rstplib-users] RE: Max Bridge Diameter

[Mick S. <mic...@ie...>]

The assumption in .1w is that legacy STP  bridges may always be present s=
o
Abnnex B always applies.

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Alex Ruzin
Sent: Wednesday, January 02, 2002 3:22 AM
To: std...@ie...
Cc: rst...@li...
Subject:



Hi,

We didn't find in 802.1w the reason for the upper boundaries on
Bridge Max Age and Maximum Bridge Diameter. We are testing a scenario
where there are no legacy STP Bridges in the LAN so Annex B is not
relevant.

Let's consider a chain of n RSTP Bridges:

B1----B2-----B3-----........  ---------Bx--------........---------Bn

B1 is the Root bridge.

Our question is: Which Bridge will be the first to discard the BPDUs?
Or in other words: In which Bridge rcvdInfoWhile<=3DHelloTime
(Let's call this Bridge Bc)

When default configuration is used (MaxAge=3D20), Bridge B2 receives
BPDUs with MessageAge=3D0 and saves in rootTimes.MessageAge
the value 1 (according to 17.19.21.d.2),  because 1/16 of the MaxAge is
equal to 1.
It also updates its rcvdInfoWhile (according to 17.19.19)
with the result of min (MaxAge - EffectiveAge, 3 * HelloTime) where
EffectiveAge=3D1.

Bridge Bx receives BPDU with MessageAge=3D(x-2), calculates
EffectiveAge=3DMessageAge + 1=3Dx-1 (since 1/16 of the MaxAge is equal
to 1) and
rcvdInfoWhile=3Dmin(MaxAge-EffectiveAge, 3*HelloTime)=3Dmin (MaxAge-x+1, =
6).
Based on this calculation, the number of the first Bridge to discard BPDU=
s
(x=3Dc) is
MaxAge - 1 + HelloTime.
So, for default configuration, maximum LAN Diameter is 19.
If we increment MaxAge to 25, it may reach 26+1-2=3D24

However, for values greater then 25, the result of 1/16 of MaxAge
rounded to the nearest whole second, is equal to 2.
Bridge B2 saves now in rootTimes.MessageAge the value 2, etc.
Bridge number x receives BPDU with MessageAge=3D2*(x-2), calculates
EffectiveAge=3DMessageAge + 2=3D2*(x-2) + 2=3D2*x - 2, updates its
rcvdInfoWhile with value (MaxAge - EffectiveAge)=3D (MaxAge - 2*x =96 2)
Based on this calculation, the number of the first Bridge to discard BPDU=
s
(x=3Dc) is
(MaxAge - 2 - HelloTime) / 2
For MaxAge=3D31 the result is 13 which is less then the default configura=
tion
result 19 !!!

For MaxAge values in the range 32 to 40 , Bx receives BPDU with
MessageAge=3D3*(x-2), calculates
EffectiveAge=3DMessageAge + 3=3D3*(x-2) + 2=3D3*x - 4, updates its
rcvdInfoWhile with value (MaxAge - EffectiveAge)=3D(MaxAge - 3*x - 4)
So, the number of the first Bridge to discard BPDUs (x=3Dc) is
(MaxAge - 4 - HelloTime) / 3 and ranges between 8 and 11 !

It seems, that the dependency of LAN diameter on MaxAge is not a linear
function !

Could you help us with the following questions:
1. Did we make a mistake in the above calculations?
2. What is the theoretical background of the statement "the greater of
(1/16th Max
Age) and 1 second, and rounded to the nearest whole second" in Clauses
17.19.19 and 17.19.21 ?
3. What is a reasonable limitation of RSTP LAN diameter ?

Best regards,
Alex

[Rstplib-users] 802.1w: How does LAN diameter depend on MaxAge ?

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

Hi,

We didn't find in 802.1w the reason for the upper boundaries on
Bridge Max Age and Maximum Bridge Diameter. We are testing a scenario
where there are no legacy STP Bridges in the LAN so Annex B is not
relevant.

Let's consider a chain of n RSTP Bridges:

B1----B2-----B3-----........  ---------Bx--------........---------Bn

B1 is the Root bridge.

Our question is: Which Bridge will be the first to discard the BPDUs?
Or in other words: In which Bridge rcvdInfoWhile<=HelloTime
(Let's call this Bridge Bc)

When default configuration is used (MaxAge=20), Bridge B2 receives
BPDUs with MessageAge=0 and saves in rootTimes.MessageAge
the value 1 (according to 17.19.21.d.2),  because 1/16 of the MaxAge is
equal to 1.
It also updates its rcvdInfoWhile (according to 17.19.19)
with the result of min (MaxAge - EffectiveAge, 3 * HelloTime) where
EffectiveAge=1.

Bridge Bx receives BPDU with MessageAge=(x-2), calculates
EffectiveAge=MessageAge + 1=x-1 (since 1/16 of the MaxAge is equal
to 1) and
rcvdInfoWhile=min(MaxAge-EffectiveAge, 3*HelloTime)=min (MaxAge-x+1, 6).
Based on this calculation, the number of the first Bridge to
discard BPDUs (x=c) is
MaxAge - 1 + HelloTime.
So, for default configuration, maximum LAN Diameter is 19.
If we increment MaxAge to 25, it may reach 26+1-2=24

However, for values greater then 25, the result of 1/16 of MaxAge
rounded to the nearest whole second, is equal to 2.
Bridge B2 saves now in rootTimes.MessageAge the value 2, etc.
Bridge number x receives BPDU with MessageAge=2*(x-2), calculates
EffectiveAge=MessageAge + 2=2*(x-2) + 2=2*x - 2, updates its
rcvdInfoWhile with value (MaxAge - EffectiveAge)= (MaxAge - 2*x – 2)
Based on this calculation, the number of the first Bridge to discard BPDUs
(x=c) is
(MaxAge - 2 - HelloTime) / 2
For MaxAge=31 the result is 13 which is less then the default configuration
result 19 !!!

For MaxAge values in the range 32 to 40 , Bx receives BPDU with
MessageAge=3*(x-2), calculates
EffectiveAge=MessageAge + 3=3*(x-2) + 2=3*x - 4, updates its
rcvdInfoWhile with value (MaxAge - EffectiveAge)=(MaxAge - 3*x - 4)
So, the number of the first Bridge to discard BPDUs (x=c) is
(MaxAge - 4 - HelloTime) / 3 and ranges between 8 and 11 !

It seems, that the dependency of LAN diameter on MaxAge is not a linear
function !

Could you help us with the following questions:
1. Did we make a mistake in the above calculations?
2. What is the theoretical background of the statement "the greater of
(1/16th Max
Age) and 1 second, and rounded to the nearest whole second" in Clauses
17.19.19 and 17.19.21 ?
3. What is a reasonable limitation of RSTP LAN diameter ?

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

[Rstplib-users] (no subject)

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

Hi,

We didn't find in 802.1w the reason for the upper boundaries on
Bridge Max Age and Maximum Bridge Diameter. We are testing a scenario
where there are no legacy STP Bridges in the LAN so Annex B is not
relevant.

Let's consider a chain of n RSTP Bridges:

B1----B2-----B3-----........  ---------Bx--------........---------Bn

B1 is the Root bridge.

Our question is: Which Bridge will be the first to discard the BPDUs?
Or in other words: In which Bridge rcvdInfoWhile<=HelloTime
(Let's call this Bridge Bc)

When default configuration is used (MaxAge=20), Bridge B2 receives
BPDUs with MessageAge=0 and saves in rootTimes.MessageAge
the value 1 (according to 17.19.21.d.2),  because 1/16 of the MaxAge is
equal to 1.
It also updates its rcvdInfoWhile (according to 17.19.19)
with the result of min (MaxAge - EffectiveAge, 3 * HelloTime) where
EffectiveAge=1.

Bridge Bx receives BPDU with MessageAge=(x-2), calculates
EffectiveAge=MessageAge + 1=x-1 (since 1/16 of the MaxAge is equal
to 1) and
rcvdInfoWhile=min(MaxAge-EffectiveAge, 3*HelloTime)=min (MaxAge-x+1, 6).
Based on this calculation, the number of the first Bridge to discard BPDUs
(x=c) is
MaxAge - 1 + HelloTime.
So, for default configuration, maximum LAN Diameter is 19.
If we increment MaxAge to 25, it may reach 26+1-2=24

However, for values greater then 25, the result of 1/16 of MaxAge
rounded to the nearest whole second, is equal to 2.
Bridge B2 saves now in rootTimes.MessageAge the value 2, etc.
Bridge number x receives BPDU with MessageAge=2*(x-2), calculates
EffectiveAge=MessageAge + 2=2*(x-2) + 2=2*x - 2, updates its
rcvdInfoWhile with value (MaxAge - EffectiveAge)= (MaxAge - 2*x – 2)
Based on this calculation, the number of the first Bridge to discard BPDUs
(x=c) is
(MaxAge - 2 - HelloTime) / 2
For MaxAge=31 the result is 13 which is less then the default configuration
result 19 !!!

For MaxAge values in the range 32 to 40 , Bx receives BPDU with
MessageAge=3*(x-2), calculates
EffectiveAge=MessageAge + 3=3*(x-2) + 2=3*x - 4, updates its
rcvdInfoWhile with value (MaxAge - EffectiveAge)=(MaxAge - 3*x - 4)
So, the number of the first Bridge to discard BPDUs (x=c) is
(MaxAge - 4 - HelloTime) / 3 and ranges between 8 and 11 !

It seems, that the dependency of LAN diameter on MaxAge is not a linear
function !

Could you help us with the following questions:
1. Did we make a mistake in the above calculations?
2. What is the theoretical background of the statement "the greater of
(1/16th Max
Age) and 1 second, and rounded to the nearest whole second" in Clauses
17.19.19 and 17.19.21 ?
3. What is a reasonable limitation of RSTP LAN diameter ?

Best regards,
Alex

[Rstplib-users] 802.1w: double flushing in simplest case ?

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

Hi,

When two Bridges are connected with one link,
we observe at least double flushing on all other Ports on both of Bridges
in PROPAGATING state of Topology Change state machine.

My explanation (?): the Port causes the first flushing when it becomes
Forwarding, TCM of this Port transitions to DETECTED state ,  and it causes
the transition to PROPAGATING state on other Ports.

The second flushing - when the Port receives TopologyChange flag in the BPDU
and
NOTIFIED_TC state causes the transition to PROPAGATING state on other ports.

May it be avoided (while the flushing is a very expensive operation)?

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

[Rstplib-users] RE: operEdge: per Port or per MSTi in 802.1s ?

[Mick S. <mic...@ie...>]

Alex,

The port is either enabled for all MSTIs, and operEdge or not for all MSTIs
or not.

Pruning of VLANs is not done by the spanning tree, but by GVRP and the
associated controls that either feed into GVRP or manually substitute for
it.

If two bridges disagreed on MSTIs then, for one of them at least, the LAN
that connected them would be in a different region. That would mean frames
for all MSTIs would be delivered to this LAN by one or other of the Bridges.
It follows that a Bridge Port cannot be operEdge for some MSTIs and not for
others.

Mick

-----Original Message-----
From: own...@ma...
[mailto:own...@ma...]On Behalf Of Alex Ruzin
Sent: Thursday, December 13, 2001 4:56 AM
To: 'Tony Jeffree'
Cc: std...@ie...; rst...@li...
Subject: RE: operEdge: per Port or per MSTi in 802.1s ?



But all decision about Port Roles & Port states and
optimizations with Designated Port agreement handshake
we make "per MSTi", don't we ?

Another words: if in all VLANs, mapped to the MSTi,
there is no STP bridges,
connected to the Port, may we think, that operEdge
of this Port is TRUE *in this MSTi* ?

The similar considerations about portEnabled: may the port be
enabled in some MSTi (i.e. for all VLANs from this MSTi) and
disabled in another one ?

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

> -----Original Message-----
> From: Tony Jeffree [mailto:to...@je...]
> Sent: Thursday, December 13, 2001 1:37 PM
> To: Ar...@op...
> Cc: std...@ie...; rst...@li...
> Subject: Re: operEdge: per Port or per MSTi in 802.1s ?
>
>
> The use of operEdge to signal an edge port allows the
> Spanning Tree state
> machines to make optimizations in transitions to Forwarding
> on such ports,
> based on the assumption that because the port is an edge port, there
> is   no bridge attached to the port (which, by definition,
> would mean that
> the port is not an edge port).
>
> Seeing *any* BPDU on a port that had been flagged as an edge
> port means
> that there is a bridge out there - and therefore, that the
> port is not at
> the edge of the bridged LAN, and therefore, any spanning tree
> optimizations
> that were based on the assumption that the port was an edge
> port are no
> longer valid.  Continuing to behave as an edge port in these
> circumstances
> would carry the risk of creating loops in one or more of the
> MSTIs and/or
> CIST. Hence, it is only necessary to have a single instance
> of the variable
> per port for it to do its job.
>
> Regards,
> Tony
>
> At 12:10 13/12/2001 +0200, Alex Ruzin wrote:
>
> >Hi,
> >
> >In 13.25 of 802.1s it is pointed, that the variable operEdge
> is  "single
> >per-Port instance
> >applies to the CIST and to all MSTIs."
> >
> >Why ?
> >If a Port had received BPDU with tag of some MSTi and had
> >not received any BPDU from another,
> >why we have to consider it as operEdge port in this second MSTi ?
> >
> >Best regards, Alex
> >---------------------
> >Open Source RSTP  https://sourceforge.net/projects/rstplib/
> >Optical Access Ltd. http://www.opticalaccess.com
>
>

[Rstplib-users] RE: operEdge: per Port or per MSTi in 802.1s ?

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

But all decision about Port Roles & Port states and
optimizations with Designated Port agreement handshake
we make "per MSTi", don't we ?

Another words: if in all VLANs, mapped to the MSTi,
there is no STP bridges,
connected to the Port, may we think, that operEdge
of this Port is TRUE *in this MSTi* ?

The similar considerations about portEnabled: may the port be
enabled in some MSTi (i.e. for all VLANs from this MSTi) and
disabled in another one ?

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

> -----Original Message-----
> From: Tony Jeffree [mailto:to...@je...]
> Sent: Thursday, December 13, 2001 1:37 PM
> To: Ar...@op...
> Cc: std...@ie...; rst...@li...
> Subject: Re: operEdge: per Port or per MSTi in 802.1s ?
> 
> 
> The use of operEdge to signal an edge port allows the 
> Spanning Tree state 
> machines to make optimizations in transitions to Forwarding 
> on such ports, 
> based on the assumption that because the port is an edge port, there 
> is   no bridge attached to the port (which, by definition, 
> would mean that 
> the port is not an edge port).
> 
> Seeing *any* BPDU on a port that had been flagged as an edge 
> port means 
> that there is a bridge out there - and therefore, that the 
> port is not at 
> the edge of the bridged LAN, and therefore, any spanning tree 
> optimizations 
> that were based on the assumption that the port was an edge 
> port are no 
> longer valid.  Continuing to behave as an edge port in these 
> circumstances 
> would carry the risk of creating loops in one or more of the 
> MSTIs and/or 
> CIST. Hence, it is only necessary to have a single instance 
> of the variable 
> per port for it to do its job.
> 
> Regards,
> Tony
> 
> At 12:10 13/12/2001 +0200, Alex Ruzin wrote:
> 
> >Hi,
> >
> >In 13.25 of 802.1s it is pointed, that the variable operEdge 
> is  "single
> >per-Port instance
> >applies to the CIST and to all MSTIs."
> >
> >Why ?
> >If a Port had received BPDU with tag of some MSTi and had
> >not received any BPDU from another,
> >why we have to consider it as operEdge port in this second MSTi ?
> >
> >Best regards, Alex
> >---------------------
> >Open Source RSTP  https://sourceforge.net/projects/rstplib/
> >Optical Access Ltd. http://www.opticalaccess.com
> 
> 

[Rstplib-users] Re: operEdge: per Port or per MSTi in 802.1s ?

[Tony J. <to...@je...>]

The use of operEdge to signal an edge port allows the Spanning Tree state 
machines to make optimizations in transitions to Forwarding on such ports, 
based on the assumption that because the port is an edge port, there 
is   no bridge attached to the port (which, by definition, would mean that 
the port is not an edge port).

Seeing *any* BPDU on a port that had been flagged as an edge port means 
that there is a bridge out there - and therefore, that the port is not at 
the edge of the bridged LAN, and therefore, any spanning tree optimizations 
that were based on the assumption that the port was an edge port are no 
longer valid.  Continuing to behave as an edge port in these circumstances 
would carry the risk of creating loops in one or more of the MSTIs and/or 
CIST. Hence, it is only necessary to have a single instance of the variable 
per port for it to do its job.

Regards,
Tony

At 12:10 13/12/2001 +0200, Alex Ruzin wrote:

>Hi,
>
>In 13.25 of 802.1s it is pointed, that the variable operEdge is  "single
>per-Port instance
>applies to the CIST and to all MSTIs."
>
>Why ?
>If a Port had received BPDU with tag of some MSTi and had
>not received any BPDU from another,
>why we have to consider it as operEdge port in this second MSTi ?
>
>Best regards, Alex
>---------------------
>Open Source RSTP  https://sourceforge.net/projects/rstplib/
>Optical Access Ltd. http://www.opticalaccess.com

[Rstplib-users] operEdge: per Port or per MSTi in 802.1s ?

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

Hi,

In 13.25 of 802.1s it is pointed, that the variable operEdge is  "single
per-Port instance
applies to the CIST and to all MSTIs."

Why ?
If a Port had received BPDU with tag of some MSTi and had
not received any BPDU from another,
why we have to consider it as operEdge port in this second MSTi ?

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