BUDAPEST UNIVERSITY OF TECHNOLOGY AND ECONOMICS Budapest University of Technology and Economics Verification of RSTP Convergence and Scalability by Measurements

BUDAPEST UNIVERSITY OF TECHNOLOGY AND ECONOMICS

Budapest University of Technology and Economics

Verification of RSTP Convergence and Scalability by Measurements and Simulations

István Moldován, Saad Abuguba, Csaba Lukovszki11-14 December 2006

WPC1 — 2 Broadband Europe, Geneva 2006Budapest University of Technology and Economics

Background

Metro Ethernet, Ethernet Access, Ethernet aggregation All using Spanning Tree Protocol

In the LAN No special requirements, just simplicity

In the provider’s network Carrier grade requirements!

Carrier Grade Questions: How fast is the restoration? Does it scale?


STP – Why needed?

Ethernet does not have TTL field Loop protection is required

Spanning Tree Protocol reduces the active topology to a tree

Alternatives Disable STP – not needed on tree topologies VLAN based trees

VLAN topologies configured as p2p or p2mp connections management is responsible for loop control

a configuration error becomes FATAL


Spanning Tree standards, problems

Basic STP – IEEE 802.1D – 1998 timer based operation slow (~1minute restoration) does not scale

Rapid STP – IEEE 802.1w - 2001 – IEEE 802.1D - 2004

much faster but still no upper bound on convergence several problems revealed (like count to infinity)

Scalability?

Multiple STP – IEEE 802.1s - 2002 multiple regions multiple trees within regions scalable


Loop-free Connectivit

y

Spanning Tree Basics

One root bridge per network One root port per non-root bridge One designated port per segment Non-designated ports are blocked

Root Port (Fwd): Port receiving the best BPDU for the bridge – shortest path to the Root in terms of path cost

Designated Port (Fwd): Port sending the best BPDU on a segment

Alternate Port (Disc): Port blocked by BPDUs from a different bridge – redundant path to the Root

Backup Port (Disc):Port blocked by BPDUs sent from the same bridge – redundant path to a segment

A

B

D

R

Root

A BR R

D D

DA B


Bridge Protocol Data Unit (BPDU)


Proposal

Block Block

Proposal

Agreement

Agreement

Forward

Edge port

Proposal

Agreement

Forward

Forward

IEEE 802.1w sequence of events

Receive a proposal Block all other non-edge ports

Send an agreement back Put the new root port to forwarding

Send out proposals on other ports

Receive agreement from others Put ports into forwarding


Simulations on convergence

We used OPNET Modeler 10.5 simulation tool RSTP supported by default RSTP standard compliance verified (bug removed)

Simulations on different resilient topologies Dual Homing topologies

deep: multiple levels wide: high aggregation

Ring topologies Mixed ring and dual homing

Simulation objective: restoration time after failure


Dual-homing scenarios

Dual homing connections for resilience Simulations with increasing number of

layers

Traffic between node_5 and node_8 primary path fails we measure restoration time

Recovery happens almost instantaneously by accepting a proposal sent earlier on the other link

We have found similar results for all investigated dual-homing topologies-no matter of the width, depth and failure location, since there is always an alternate port to the root


RSTP restoration on ring topology

Different ring sizes from 6-14

Different bridge BPDU processing times 10-5000 BPDU/s

Recovery time observed From port state changes

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

6 7 8 9 10 11 12 13 14

# of bridges

Rec

ove

ry ti

me

[s]

10

50

100

500

1000

5000

Basically limited by the bridge BPDU processing timeMeasured BPDU processing time on real bridge:

- 0.025s, std. deviation of 0.001s


Hold Timer

TxHoldCount At least one BPDU per

HelloTime interval, and not more than (TxHoldCount + 1) BPDUs in one second

By Standard selectable Between 1-10

The value of 1 introduces delays Hello BPDU + other

BPDU can not go in the same second

0

0,5

1

1,5

2

2,5

6 7 8 9 10 11 12 13 14

# of bridges

Re

co

ve

ry t

ime

[s

]

TxHoldCount = 6

TxHoldCount = 1


Count to infinity problem

Documented behavior

On failure of root long failover times Several seconds!

Reason: Old information persists and circulates Until

message ages out or Root path costs reaches maximum value

Root


RSTP scalability issues

Big ring BPDU

information ages ports where

BPDU ages out becomes forwarding (standard says so)

Two spanning trees formed! 2 roots

LOOP CONDITION!


Maximum Bridge Diameter

IEEE 802.1D – 2004 does not contain this statement Diameter limit is given by the value of Maximum Age value 20 by default, up to 40

Thus theoretically topologies with diameter up to 40 hops can be created

Diameter distance from root! Diameter = the maximum length path in the network Important since in case of failure longer paths may be formed

2 trees, possible loops


Conclusions

RSTP convergence is limited by BPDU processing speed Fast convergence in typical topologies (below 1 second) No upper limit on convergence Depends on topology and bridge BPDU processing speed Vulnerable to count to infinity problem

Limited scalability By default up to diameters of 20 Can be tuned up to 40 (theoretical limit)


Thank you for your attention!

Questions?

Documents

BUDAPEST UNIVERSITY OF TECHNOLOGY AND ECONOMICS Budapest University of Technology and Economics Verification of RSTP Convergence and Scalability by Measurements