How Split Horizon Keeps VPLS Stable: Design and Configuration Across Vendors

Overview

VPLS is a Layer 2 VPN technology that lets business sites scattered across the globe appear as if they are 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. However, 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 in VPLS can be defined as a loop prevention mechanism on the Provider Edge routers to prevent traffic received from one remote PE being forwarded out to other remote PEs belonging to the same VPLS instance.

Why It's Needed:

A VPLS essentially is an enormous virtual Ethernet switch where several PE routers are interconnected using pseudo wires to simulate the behaviour of a LAN across geographically dispersed sites. In such a scenario, broadcast and unknown unicast traffic is flooded across the VPLS domain.

This, when flooding without control leads to Layer 2 loops, which is bad in Ethernet networks and can cause:

• Broadcast storms

• MAC address flapping

• High CPU usage in routers

• Network outages

A split horizon group makes sure 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 the local interfaces, toward the customer site.

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;
                }
            }
        }
    }
}

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

# 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 behind-the-scenes VPLS technology heroes that keeps your network running like a dream. It is the solution for those pesky Layer 2 broadcast storms and traffic loops that could potentially destroy your entire system. In this blog, we'll examine what each of the major networking companies, including Cisco, Juniper, and Nokia, does with their respective solutions for what is called Split Horizon for VPLS. We'll explore their configuration examples for each to better understand what they do differently in regard to traffic loop avoidance. And what we'll learn is that though their end solution is the same—the need for a safe, functioning VPLS connection—each company does it differently.

If you are either a service provider engineer or network architect, it is hoped that this guide can provide you with a practical comparison of deploying VPLS in a robust but more significantly loop-free manner.