There is some debate as to the benefit of supporting STP (Spanning Tree Protocol) within a Layer 2 VPN.
The idea is that STP protocols can be used to provide redundant VPN data paths that can be unblocked if the STP detects a spanning tree topology failure. In general, it is believed that introducing STP to VPLS increases network complexity with very little real benefit.
MPLS (Multiprotocol Label Switching) already provides a significant level of redundancy for the LSP over which a PW is carried. For example, if a PW is using an LDP established LSP, provided there are parallel routed paths to the PW endpoint, the PW automatically shifts from a withdrawn or failed LSP to the next best available LSP. For transport LSPs established using RSVP-TE, secondary LSPs can be configured that can be hot-swapped in the event of a primary LSP failure. Fast-reroute detour LSPs can also be used to protect RSVP-TE LSPs. Thus, even though the underlying transport LSP might have changed, the Layer 2 VPN data plane remains unaffected.
For these reasons, VPLS and STP are not normally enabled on the same VLAN (Virtual LAN). The exception is for local customer network redundancy such as shown in VPLS STP Redundancy Overview.
When STP is not enabled on a VPLS VLAN, the BPDU functional address is not inserted into the FDB (forwarding database) for this VLAN and all received BPDU packets are flooded across the Layer 2 VPN. In this scenario, a single large spanning tree topology spanning all interconnected Layer 2 VPN service sites is constructed. Note that this is not a recommended configuration for a Layer 2 VPN service. Depending on the packet latency within the backbone network, STP timers might need to be tuned to build and maintain reliable topologies.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB