Broadcast Storms Ahead! What Happens When You Skip Split Horizon in VPLS

-

 Overview 


Virtual Private LAN Service is a Layer 2 VPN technology that lets business sites scattered across the globe appear as if they're connected on the same local Ethernet network. Built over an MPLS or IP backbone, VPLS creates a virtual Ethernet switch across provider edge routers. That lets customer edge devices talk to each other directly over Ethernet frames. Signaling protocols like LDP or BGP help PE routers set up pseudo wires—those are the tunnels that carry Layer 2 frames. The routers also learn MAC addresses dynamically to forward unicast traffic. They flood broadcast and multicast frames as needed. That setup is perfect for enterprises that need seamless Layer 2 connectivity across locations for services like VoIP, video conferencing or legacy systems. But without proper configuration—like split horizon groups—VPLS can run into loops and broadcast storms. That makes precise setup critical to its success.




Split Horizon Group


A split horizon group is a loop prevention mechanism on Provider Edge (PE) routers in VPLS (Virtual Private LAN Service) to prevent traffic received from one remote PE from being forwarded back out to other remote PEs in the same VPLS instance.

 Why It’s Needed:


VPLS is like a big virtual Ethernet switch where multiple PE routers are connected via pseudowires to simulate LAN behavior across geographically dispersed sites. In this setup, broadcast and unknown unicast traffic is flooded across the VPLS domain.

Without control, this flooding can lead to Layer 2 loops which are bad in Ethernet networks and can cause:

• Broadcast storms
• MAC address flapping
• High CPU usage on routers
• Network outages


A split horizon group ensures that:

Any frame received over a pseudo wire from a remote PE is not sent out to another pseudo wire — it’s only sent to local interfaces (toward the customer site).

This is the classic “split horizon” rule in routing: Don’t advertise a route back out the same interface it was learned from.

Split Horizon in Action: Broadcast Storm Prevention Across Cisco, Juniper, and Nokia

1. Junos: -

split horizon groups are configured within the VPLS instance using vendor specific syntax and all remote PEs in the same VPLS domain must have the same split horizon group ID.

R1(edit)#routing-instances {
    VPLS-SERVICE {
        instance-type vpls;
        interface ge-0/0/1.0;
        route-distinguisher 100:1;
        vrf-target target:100:1;
        protocols {
            vpls {
                site SITE-1 {
                    site-identifier 1;
                    interface ge-0/0/1.0;
                }
                bgp-options {
                    split-horizon-group 1;
                }
            }
        }
    }
}

2. Cisco: -

split horizon groups are configured within the VPLS instance using vendor specific syntax and all remote PEs in the same VPLS domain must have the same split horizon group ID.

R1(config) #l2vpn
           #bridge group VPLS-GRP
  bridge-domain VPLS-DOMAIN
   vpn-id 100
   interface GigabitEthernet0/0/0/1
   !
   vfi VPLS-VFI
    vpn-id 100
    neighbor 10.10.10.1 encapsulation mpls
   !
   split-horizon


3. Nokia: -

Split Horizon Groups are configured within the base BGP group configuration, and the corresponding interface must also be set with the appropriate encap-type at the service level."

# Under base router BGP group

router bgp
    group "VPLS-GRP"
        family vpls
        split-horizon-group "VPLS-GRP"

# At the service level

vpls 100 customer 1 create
    description "Corporate-VPLS"
    interface "to-CE1" create
        encap-type vlan
        vlan-id 100
    exit
    bgp
        group "VPLS-GRP"
    exit
exit

Summary 

Split Horizon is one of those unsung heroes of VPLS deployments that keeps your network running smoothly. It's the safeguard against those nasty Layer 2 broadcast storms and traffic loops that can bring your whole setup crashing down. In this post, we'll take a closer look at how different networking vendors—Cisco, Juniper and Nokia—handle Split Horizon in their platforms. We'll walk through their technical configuration examples to show how each one tackles loop prevention in its own way. And what we'll find is that while the core goal of secure and stable VPLS connectivity remains the same, each vendor has its own approach to getting there.

Whether you're a service provider engineer or network architect, this guide is designed to give you a concise, hands-on comparison of how to deploy VPLS in a way that's both robust and—most importantly—loop-free.

Comments

Post a Comment

Popular posts from this blog

Configuring NNI Interface Policies and Container Integration in Nokia SR and Juniper AG Networks

-
Image
 Objective: - This blog aims to give a comprehensive overview of the process for integrating containerized network services in a multi-vendor setting, specifically using Nokia Service Routers (SR) and Juniper Aggregation Routers (AG). It emphasizes the importance of NNI interface policies for facilitating smooth communication between different network segments and provides guidance on configuring management interfaces and routing to optimize connectivity and traffic flow. The goal of this guide is to help network engineers implement scalable and interoperable solutions while making complex network operations easier to manage. Scenario :- In Vodafone ISP, Pune location 2 SR non-production devices need to be launched in production. Router R1 acts as a primary and Router R2 acts as a secondary back up router. Both routers aggregate traffic combines at uplink Nasik Aggregate router. This uplink is connected with IXR router at Mumbai location. To automate process flow AWS containers are...
Read more

Designing a Secure Multi-VPC Architecture with AWS Transit Gateway and IGW

-
Image
 Preface In an AWS cloud Proof of Concept (PoC), Transit Gateway (TGW) and Internet Gateway (IGW) are key to secure, scalable and efficient communication between different VPCs and external networks. Transit Gateway (TGW) is a central routing hub where multiple VPCs can communicate without the complexity of multiple VPC peering connections. It simplifies network management, scales and enforces security policies through route tables to control traffic between connected VPCs. Internet Gateway (IGW) is required for outbound and inbound internet access for resources in public subnets. It allows public facing workloads like web servers and APIs to talk to external services while keeping private subnets secure through NAT Gateways . Together TGW and IGW provide a structured and controlled networking environment, so critical workloads are secure, isolated when needed and connected efficiently in a multi-VPC architecture. POC  The proposed Proof of Concept (PoC) focuses on estab...
Read more

AI in NOC: A New Era for Capacity Planning and Network Management

-
Image
   Introduction :- Predicting router interface traffic in modern network management is critical to achieve optimal network performance, resource allocation, and proactively eliminate bottlenecks. This case study suggests using machine learning on network datasets to develop a model that predicts an actual router’s interface traffic versus an ideal router’s traffic. By evaluating historical data of network traffic and utilizing well-established machine learning API-based algorithms like Neural Networks, Decision Trees, and Ensemble Methods, this analysis reviews the formation possibilities of a strong prediction model with grand accuracy. At the end of the study, this paper reviews multiple factors and features related to the traffic in the interface such as the hour in the day, the day’s sequence in the week, the network protocol, the application, and the structure of the network. Additionally, it explores the machine learning algorithms to compare the accuracy of the ML model...
Read more