Basic H-VPLS
Last updated
Last updated
Load basic.vpls.ldp.init.cfg
Configure H-VPLS using LDP. Do not use BGP for autodiscovery.
R1, R3, and R5 are the U-PEs, and R2, R4, and R6 are the N-PEs. Each U-PE should only peer to the N-PE one number higher (i.e. R1 to R2, etc).
H-VPLS (Hierarchical VPLS) is a scalability technique that eliminates the need for a full mesh of PWs between PEs. In this small lab, we cannot fully appreciate the benefit as clearly, but imagine if there were 100 U-PEs. We would have 100*99/2 PWs in the network, which is not scalable. Additionally, packet replication becomes an issue, as the more PEs that are added, the more times a BUM frame must be replicated and delivered to all remote PEs in the VPLS domain.
Instead, we can create a hierarchy. In H-VPLS, PEs are classified as either U-PEs or N-PEs. U-PEs are user facing, directly attaching to a CE. N-PEs are network facing, and connect to U-PEs and other N-PEs.
There is a standalone “core” VPLS that consists of only N-PEs. N-PEs form a full mesh of PWs with other N-PEs. N-PEs treat U-PEs like an AC. N-PEs must turn split-horizon off for PWs that face U-PEs. This is achieved by specifying the U-PE manually under the BD, instead of specifying it under the VFI. (Note that with the new l2vpn vfi context configuration, you cannot disable split horizon for manual neighbors). It helps to imagine that the U-PE PW is kind of an AC from the N-PE’s point of view, instead of a PW peer.
The U-PEs only need to form a PW with a minimum of one N-PE. This greatly helps reduce the amount of PWs in the core as the number of U-PEs grows. U-PEs can treat the N-PEs as a normal PW, keeping split-horizon on. The U-PEs can even treat this as a single VPWS xconnect. This allows you to use lightweight devices in the access layer that don’t have bridging capabilities.
H-VPLS is more of a “technique” than a “configuration.” H-VPLS is implemented based on how you form PWs, and by turning off split horizon on PWs that are N-PE to U-PE. There is nowhere that you explicity configure “H-VPLS” versus normal “VPLS.”
It is important to note that split horizon is enabled independently on each end of a PW. So on a N-PE ↔ U-PE PW, the N-PE turns split horizon off, but the U-PE leaves split horizon on, as the PW belongs to a VFI on the U-PE.
On any N-PE we should see a full mesh of PWs to other N-PEs with split-horizon enabled. We should also see U-PEs as having split-horizon disabled. This is because the U-PE PW was configured under the BD instead of under the VFI.
This heirarchy spreads the CAM table at more “levels” now. The N-PEs will learn MACs via other N-PEs and also via U-PEs. The CAM table is spread among all U-PEs and N-PEs.
We can see how R1’s configuration is simpler in H-VPLS compared to VPLS. R1 only has one PW peer, which is a N-PE. If we add more U-PEs to the network, R1 still will have only one PW peer. R1’s CAM table will see all remote MACs as via the PW to R2.
The data plane becomes more complex in H-VPLS. Previously in VPLS we had a single end-to-end LSP. An ingress PE would push two labels: a transport label representing the egress PE, and the egress PE’s service label.
However, with H-VPLS, we have several LSPs that are stitched together. For example, trace the data path for traffic from CE1 to CE2. First it follows an LSP from R1 to R2. R2 makes a bridging decision and transports the packet via an LSP to R4. R4 makes a bridging decision and transports the packet to R3 via another LSP. So we can say that while we made the control plane more scalable, we added some complexity to the data plane. The N-PEs now have to preform bridging functions which were previously only preformed at the edge of the network.
Additionally, MAC scalability is a factor. The N-PEs must learn the MACs of all CEs in total in the network. With a full mesh of PEs, each PE only learns MACs for VPLS domains for which is participates in. But an N-PE now pariticipates in all VPLS domains.
