Transcript final presentation

RSTP
vs
STP
Instructors :
Submitting :
Assoc’ Prof’ Reuven Cohen
Danny Kalmar 01702821-8
Mr. Itay Dabran
Gilad Wallach 03279719-3
Omer Sharabi 03385662-6
Mr. Mordo Shalom
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
Introduction

Why do we need spanning tree bridges?

At the beginning : 802.1d

But : the rules were changed

RSTP as an evolution of STP.
Goals

Implementing STP and RSTP

Comparing between the performances of the
protocols

Results’ discussion.
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
S/W Modules
General:
We implemented a simulation which runs
both protocols over a variety of randomized
nets

It can run several tests in a single execution
and collect statistics about the building and
recovery abilities of each protocol

Simulation’s parameters : num’ of bridges
and lans , num’ of tests and failures within
each test, bridge’s configuration and packet’s
lost probability.

The Net Manager Module

Simulation’s main loop

Main features :

Creation and initialization of new a randomized net
Running the bridges protocols using the net’s
members’ interfaces and the given parameters

Detection of the tree’s : building , failing and
recovering

The ability to run multiple tests and failures on a
given configuration


Statistics collecting.
The Bridge Module
Supports both protocols due to the mode of
operation


Main features for the 802.1W:

RSTP’s BPDUs mechanism

Rapid Transition to Forwarding State

Proposal / Agreement mechanism

Sync Mechanism

Uplink Fast
RSTP’s Topology Change Detection and
Propagation


Main features for the 802.1D:

STP’s BPDUs mechanism
STP’s Topology Change Detection and
Propagation

The LAN Module

Main features :
Distribution of BPDUs from the previous cycle to
their destinations

The
LAN receives all messages and prepare them
to be sent out the next cycle.
The Testing Module

Main features :
Generation of failures on demand : disconnection
of a forwarding port or connection of a disabled port
while keeping the net with connectivity

Maintenance of failures’ list in order to support
running the same tests for both protocols .

System Arch
Bridge.Tick()
Net
Manager
TestCreateFailure() Testing
Lan.Tick()
received_bpdu
Bridge
LAN
Main Loop (1)
Case: - Packets’ lost probability != 0


For all tests :
•
Set a randomized net
•
Run each protocol till its tree become stable
•
Collect test’s results.
Print statistics.
Main Loop (2)
Case: - Packets’ lost probability = 0
 For all tests :

•
Set a randomized net
•
Run each protocol till its tree become stable
•
Collect initialization’s results
•
For all failures :

Activate the failure

Run each protocol till its tree recover

Collect recovery’s results.
Print statistics.
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
Test’s Parameters
 All the net’s member possibilities are represented as a pair of
(Bridge_Num , LAN_Num ) :
• Dense networks : { (2,6), (5,10) , (8,15) ,(10,17)
, (12,25) , (15,30) }
• Sparse networks : { (2,2), (5,5) , (8,8)
,(10,10) , (12,12) , (15,15)}
 Bridge’s parameters (following the Cisco configuration) :
• Forward delay = 15000 ticks
• Max age = 20000 ticks
• Hello time = 2000 ticks.
Performance's Criteria
Case: - Packets’ lost probability = 0 :
•
Average Initialization time
Average number of BPDUs’ that were sent
during initialization
•
•
Average recovery time
Average number of BPDUs’ that were sent
during recovery
•
Case: - Packets’ lost probability =! 0 :
The same without the recovery information
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
Recover Time In Sparse Networks
Ticks untill stability
W Recover Time
D recover time
Num Bridges=Num Lans
Recover Time in Sparse Networks
Immediate conclusions:
 RSTP recovers much faster than STP
Recover Time In Dense Networks
W recover time
Ticks untill stability
D recover time
NumBridges NumLans
Num Of Bridges
Recover Time in Dense Networks
Immediate conclusions:
 RSTP recovers much faster than STP
 Recover time is similar to that in sparse networks.
Num of BPDU In recover In Sparse
Networks
W Num of BPDU
Num BPDU
W Num of BPDU
Num Bridges=Num Lans
BPDUs Num sent during Recovery Time in
Sparse Networks
Immediate conclusions:
 RSTP requires less BPDU to achieve stability
 This is caused mainly because the recovery time is
much faster .
Num of BPDU In recover In Dense Networks
W Num of BPDU
Num BPDU
D Num of BPDU
NumBridges NumLans
Num Bridges
BPDUs Num sent during Recovery Time in
Dense Networks
Graph Explanation:
 RSTP requires less BPDU to achieve stability
 Dense network requires much more BPDUs to
stabilize.
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
Conclusions
 Recovery – RSTP recovers significantly faster than
STP , less significantly better in BPDUs count
 Dense and Sparse networks – We did not find any
critical differences except the expected gap between
BPDUs count
 Packet Lost Probability – both protocols act as usual
as long as the the probability is less than 10%. Both
protocols stability is not guaranteed over ~60%.
Agenda

Project Definition

Implementation

Test Plan

Results

Main Conclusions

General Observations
Observations
 The uplink fast feature in the RSTP can improve if it
will use the “Back Up” port feature in addition to the
“Alternate” port feature
 RSTP’s initialization’s performances can be increased
significantly through appropriate configuration (“slow”
transition avoidance)
 Attention to the fact that RSTP recovers faster than
STP which is a very important thing in today networks.
RSTP “pays” in increased BPDUs count which is less
important due to today possible band width.
 Additional tests could explore more deeply the affects
and the exact legal range of values of Packet Lost
Probability for each protocol .
Old Foils
cycles untill stability in initialization
INITIALIZATION TIME IN NOT BUSY NETWORKS
D Initilalization time with fd
W initialization with fd
D Initilalization time with fd
W initialization with fd
D initialization with fd
W Initilalization time with fd
Num Bridges=Num Lans
Initialization Time in not busy Networks
Graph Explanation:
 Similar initialization times in medium and large size
Networks,with slight advantage to the RSTP protocol
 In small Networks RSTP builds the tree much faster
 As expected, a long Forward Delay lengthens the
initialization time.
INITIALIZATION TIME IN BUSY NETWORKS
D initialization with fd
cycles untill stability in initialization
W initialization with fd
D initialization with fd
W initialization with fd
D initialization with fd
W initialization with fd
# Bridges
# Lans
Bridge Num
Initialization Time in busy Networks
Graph Explanation:
 Similar initialization times in medium and large size
Networks,with slight advantage to the RSTP protocol
 In small Networks RSTP builds the tree much faster
 As expected, a long Forward Delay lengthens the
initialization time.
 Initialization time is similar to that in not busy
networks.
cycles untill stability in recover
RECOVER TIME IN NOT BUSY NETWORKS
D recover with fd
W recover with fd
D recover with fd
W recover with fd
D recover with fd
W recover with fd
num bridges=num lans
RECOVER TIME IN BUSY NETWORKS
D recover with fd
cycles untill stability in recover
W recover with fd
D recover with fd
W recover with fd
D recover with fd
W recover with fd
# Bridges
# Lans
Bridge num
BPDU NUM IN INITIALIZATION IN NOT BUSY
NETWORKS
D in initialization with fd
W in initialization with fd
Num Of BPDU m essages
D in initialization with fd
W in initialization with fd
D in initialization with fd
W in initialization with fd
Num Bridges=Num Lans
BPDUs Num sent during Initialization Time
in not busy Networks
Graph Explanation:
 Linear growth in bpdu sent during initialization in
relation to the network size in both protocols
 RSTP sends much more BPDUs because of levels
of distribution.
BPDU NUM IN INITIALIZATION IN BUSY NETWORKS
D in initialization with fd
W in initialization with fd
Num Of BPDU messages
D in initialization with fd
W in initialization with fd
D in initialization with fd
W in initialization with fd
#Bridges
#Lans
Bridges Num
Bpdus Num sent during Initialization Time in
busy Networks
Graph Explanation:
 Linear growth in bpdu sent during initialization in
relation to the network size in both protocols
 the gap between the number of BPDUs in RSTP and
STP is not as big in busy networks.
Num Of BPDU messages
BPDU NUM IN RECOVER IN NOT BUSY NETWORKS
D in recover with fd
W in recover with fd
D in recover with fd
W in recover with fd
D in recover with fd
W in recover with fd
Bridge Num=Lan Num
BPDU NUM IN RECOVER IN BUSY NETWORKS
D in recover with fd
W in recover with fd
Num Of BPDU messages
D in recover with fd
W in recover with fd
D in recover with fd
W in recover with fd
#Bridges
#Lans
Bridge Num
BPDU NUM IN RECOVER IN BUSY NETWORKS
D in recover with fd
W in recover with fd
Num Of BPDU messages
D in recover with fd
W in recover with fd
D in recover with fd
W in recover with fd
#Bridges
#Lans
Bridge Num