# Basic VPLS with LDP

Load **basic.vpls.ldp.init.cfg**

```
#IOS-XE (R1-R6, CE1-3)
config replace flash:basic.vpls.ldp.init.cfg
```

The CE routers CE1-3 are preconfigured with EIGRP.

* Configure VPLS using LDP for signaling and manual discovery.
* Verify that the EIGRP neighborships come up on the CEs.
* All CEs should learn each other’s Lo0 over EIGRP.

## Answer <a href="#id-895dee78-4157-48a0-8f92-8158d466e6ed" id="id-895dee78-4157-48a0-8f92-8158d466e6ed"></a>

```
#R1
int gi4
 service instance 100 ethernet
  encapsulation default
 exit
!
l2vpn vfi context VPLS1
 vpn id 100
 member 3.3.3.3 encapsulation mpls
 member 5.5.5.5 encapsulation mpls
!
bridge-domain 100
 member Gi4 service-instance 100
 member vfi VPLS1

#R3
int gi6
 service instance 100 ethernet
  encapsulation default
 exit
!
l2vpn vfi context VPLS1
 vpn id 100
 member 1.1.1.1 encapsulation mpls
 member 5.5.5.5 encapsulation mpls
!
bridge-domain 100
 member Gi6 service-instance 100
 member vfi VPLS1

#R5
int gi6
 service instance 100 ethernet
  encapsulation default
 exit
!
l2vpn vfi context VPLS1
 vpn id 100
 member 1.1.1.1 encapsulation mpls
 member 3.3.3.3 encapsulation mpls
!
bridge-domain 100
 member Gi6 service-instance 100
 member vfi VPLS1
```

## Explanation <a href="#id-97daa070-74de-4cfb-992c-4ce5ffb39621" id="id-97daa070-74de-4cfb-992c-4ce5ffb39621"></a>

VPLS is an L2VPN service in which the SP core acts as a LAN switch. All CEs see each other as if directly connected to one big broadcast network.

To implement this, the router needs to preforming bridging functions, including MAC address learning/aging and flooding of BUM traffic.

The most basic form of VPLS is using a full mesh of LDP pseudowires between all participating PEs. The data plane works exactly like a VPWS service. But there is a full mesh of pseudowires and MACs are learned via the pseudowires.

A router knows which PEs are paritcipating in the VPLS via manual configuration. This means when a new PE is added, every other PE must be configured with the new PE as a member in the VFI. There is an option for BGP auto-discovery however, and optionally you can use BGP for the control plane as well (signaling the service label).

A VFI is a virtual forwarding instance. This is a virtual interface that represents the collection of the full mesh of pseudowires connecting to other PEs. MACs are learned via the VFI, and a router knows which particular PE the MAC originated from based on the service label. The PE will advertise a different service label for each pseudowire in the VFI. A different service label per-pseudowire allows a PE to know which remote PE an ingress frame was sent from, so that the MAC can be added to the CAM table with the correct outgoing interface.

Because VPLS is a bridged service, there is now the potential for loops. Loop prevention is implemented using split horizon. A router is only allowed to flood BUM traffic out the VFI if it is received from an AC. When flooding out the VFI, the router replicates the frame out each pseudowire to the collection of pseudowire partners. This is ingress replication. If a router receives a BUM frame on a pseudowire, it can only forward it out ACs, not back out another pseudowire. This prevents looping of BUM traffic within the MPLS core.

Configuration of VPLS with LDP is fairly simple. The **vpn id** is the pseudowire ID. When pseudowires are setup via tLDP sessions, they appear identical to VPWS tLDP FEC messages. They are essentially the same thing. The MTU still needs to match, but the MTU is applied under the VFI itself, it is not inherited from any particular ACs.

```
#R1
l2vpn vfi context VPLS1
 vpn id 100
 member 3.3.3.3 encapsulation mpls
 member 5.5.5.5 encapsulation mpls
```

## Verification <a href="#id-9593a08b-338b-4ed2-a592-2f9a4d00fa91" id="id-9593a08b-338b-4ed2-a592-2f9a4d00fa91"></a>

On the CEs, verify that EIGRP neighbors are up and the loopbacks are reachable.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F7noKgoeq155IGC4FCtIn%2Fimage.png?alt=media&#x26;token=e8a79d5b-96db-48a0-8f1f-c4044c40cb00" alt=""><figcaption></figcaption></figure></div>

On the PEs, examine the bridge-domain table. You should see local MACs and remote MACs that are reachable via the VFI.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F99fa7n3yuZtfPvcMYbMc%2Fimage.png?alt=media&#x26;token=6e9237f7-d677-4eef-85a3-4c53f1f54ae3" alt=""><figcaption></figcaption></figure></div>

Both types of MACs are aged out as in normal bridging. The default aging timer is 300 seconds (5 minutes).

You can see which particular PE the pseudoport belongs to using this cryptic show command:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FetfUuyFncLeLbZDEAuD8%2Fimage.png?alt=media&#x26;token=d8d30595-a8f9-411e-ba1c-1ca810ad0b9e" alt=""><figcaption></figcaption></figure></div>

You can see a summary of the pseudowires in the VFI using **show l2vpn vfi**

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FZ9NIWocz9TG7nIpz8kZ5%2Fimage.png?alt=media&#x26;token=6e8c621f-a2c4-487a-85c4-a28c1e56c116" alt=""><figcaption></figcaption></figure></div>

**Update 6-30-24:** Another useful command for this is “show l2vpn service vfi name \<name> detail” which will display the labels used for each peer.

The same **show l2vpn atom vc** command used with VPWS works for VPLS as well, because it is literally the same type of pseudowire. Notice that the VC ID is the VPN ID which was configured under the vfi.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2Fcg5KJFg4v5pqBtNLPEUu%2Fimage.png?alt=media&#x26;token=9d8df196-3c46-4484-a8b1-28d514b1001a" alt=""><figcaption></figcaption></figure></div>

Each PE should have a targeted LDP session with every other PE in the VPLS domain. This is a scalability concern as you add many PEs to the network. You need a full mesh of tLDP sessions between all VPLS PEs.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FxTTUzvB79dVEDCXgKUqU%2Fimage.png?alt=media&#x26;token=90b8beef-836b-4537-b6e7-bd1c26186f55" alt=""><figcaption></figcaption></figure></div>
