1 / 16

Verification of RSTP Convergence and Scalability by Measurements and Simulations

Verification of RSTP Convergence and Scalability by Measurements and Simulations. I stv án Moldován, Saad Abuguba, Csaba Lukovszki 1 1-14 Decembe r 2006. Background. Metro Ethernet, Ethernet Access, Ethernet aggregation All using Spanning Tree Protocol In the LAN

Patman
Download Presentation

Verification of RSTP Convergence and Scalability by Measurements and Simulations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verification of RSTP Convergence and Scalability by Measurements and Simulations István Moldován, Saad Abuguba, Csaba Lukovszki 11-14December 2006

  2. 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?

  3. 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

  4. 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

  5. Root R R R D D D A A A B B B D Spanning Tree Basics Loop-free Connectivity • 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

  6. Bridge Protocol Data Unit (BPDU)

  7. Proposal Agreement Proposal Proposal Agreement Agreement 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 Forward Edge port Forward Forward Block Block

  8. 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

  9. 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

  10. 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 Basically limited by the bridge BPDU processing time Measured BPDU processing time on real bridge: - 0.025s, std. deviation of 0.001s

  11. 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

  12. 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

  13. 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!

  14. 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

  15. 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)

  16. Thank you for your attention! Questions?

More Related