When your organization or business has several branches, you will need to use a second-layer internet platform. VPLS is actually a second-layer VPN with multipoint capability that can be used for this purpose. This article will teach you How to Configure VPLS on Mikrotik. If you intend to buy a Mikrotik VPS server, you can check out the packages offered on our website.
Table of Contents
Tutorial Install VPLS on Mikrotik VPS
What is VPLS?
VPLS stands for Virtual Private LAN Service and is a way to provide an Ethernet-based multipoint to multipoint communication over IP or MPLS networks. This technology enables you to connect geographically dispersed Ethernet local area network (LAN) sites to each other across an MPLS backbone. In fact, For customers implementing VPLS, all sites will be on the same Ethernet LAN. It provides the best solution to create a wide, interconnected, and secure network.
How to Setup VPLS on Mikrotik
We already taught how to Setup MPLS in Mikrotik in previous posts. In this section, you will learn how to configure VPLS on Mikrotik.
You can consider the VPLS interface as a tunnel interface like the EoIP interface. Establish the following tunnels to achieve transparent ethernet segment forwarding between customer sites:
–> R1-R5 (customer A)
–> R1-R4 (customer A)
–> R4-R5 (customer A)
–> R1-R5 (customer B)
Each tunnel setup involves creating VPLS interfaces on both tunnel endpoints.
The LDP protocol negotiates VPLS tunnels – both endpoints exchange tunnel labels to use for the tunnel. To forward data in the tunnel, you need to impose 2 labels on packets which are the tunnel label and the transport label. In fact, this label ensures traffic delivery to the other endpoint of the tunnel.
VPLS tunnel configurations are in the /interface VPLS menu. The vpls-id parameter must be unique for each tunnel between this tunnel and the remote peer and identifies the VPLS tunnel.
Required Setups
- On R1:
/interface vpls add name=A1toA2 remote-peer=9.9.9.5 mac-address=00:00:00:00:00:a1 vpls-id=10 disabled=no/interface vpls add name=A1toA3 remote-peer=9.9.9.4 mac-address=00:00:00:00:00:a1 vpls-id=10 disabled=no/interfacevpls add name=B1toB2 remote-peer=9.9.9.5 mac-address=00:00:00:00:00:b1 vpls-id=11 disabled=no- On R4:
/interface vpls add name=A3toA1 remote-peer=9.9.9.1 mac-address=00:00:00:00:00:a3 vpls-id=10 disabled=no/interface vpls add name=A3toA2 remote-peer=9.9.9.5 mac-address=00:00:00:00:00:a3 vpls-id=10 disabled=no- On R5:
/interface vpls add name=A2toA1 remote-peer=9.9.9.1 mac-address=00:00:00:00:00:a2 vpls-id=10 disabled=no/interface vpls add name=A2toA3 remote-peer=9.9.9.4 mac-address=00:00:00:00:00:a2 vpls-id=10 disabled=no/interface vpls add name=B2toB1 remote-peer=9.9.9.1 mac-address=00:00:00:00:00:b2 vpls-id=11 disabled=noVPLS tunnel configuration creates a dynamic LDP neighbor and establishes a “targeted” LDP session. A targeted LDP session is a session established between two routers that are not direct neighbors. After this setup, R1 LDP neighbors are as follows:
IP route labels are also exchanged between VPLS peers, but none can be used. Routers maintain all of the exchanged labels so that they are immediately ready for use when needed.
To be able to view information about a VPLS interface, you should monitor its status:
As you can see, R1 has assigned label 27 for the tunnel between R1 and R4. The MPLS forwarding table indicates that this label is detected and received on this tunnel instead of forwarding to the next hop:
The remote endpoint (R4) is assigned label 24.
igp-prefix indicates the route used to reach the remote endpoint of the tunnel. That is, when traffic is forwarded to the remote endpoint of the tunnel, this router imposes the transport label – the label distributed by the next hop to 9.9.9.4/32 for route 9.9. 9.4/32 route. So, you can confirm this in R2:
The tunnel label applied to packets is determined by the remote router (R4) for this tunnel.
The imposed labels reflect this configuration: packets generated by the tunnel have 2 labels on them: 21 and 24.
Penultimate Effects of Hop Popping in VPLS Tunnels
The penultimate hop popping of the transport label causes the packets to reach the endpoint of the VPLS tunnel with only one tunnel tag. This causes the VPLS tunnel endpoint to only look for a label to find out what to do with the packet. So, you can observe transport label behavior between tunnel endpoints with the traceroute tool. For example, the traceroute from R1 to R4 is as follows:
In the traceroute output, you can see that the tunnel endpoint is receiving an unlabeled probe. In fact, the same thing happens in VPLS tunnel traffic and the transport label (18) popped on R3 and the packet is switched only with the tunnel label.
The requirement to deliver the tunnel-tagged packet to the tunnel endpoint explains the configuration recommendations for using “Loopback” IP addresses as tunnel endpoints. Since R3 has the 3.3.3.0/24 network as its connected network, if in this case, R4 established LDP sessions with its 3.3.3.4 address, the penultimate hop popping would occur on R2. This causes R3 (and not R4) to receive the packet with only the tunnel label on it, yielding unpredicted results. including dropping the frame or sending it the wrong way if R3 doesn’t recognize the packet.
Another problem that can occur is connecting the endpoints of the VPLS tunnel directly. They cannot use any transport labels between themselves because they both instruct the other to be the penultimate hop popping router for their tunnel endpoint address. For example in R5:
This way the VPLS tunnel will only use the tunnel label when sending packets:
How to bridge Ethernet Segments with VPLS
VPLS tunnels provide a virtual Ethernet link between routers. They should be bridged with a VPLS tunnel to transparently connect the two physical Ethernet segments. In fact, it works like EoIP interfaces.
Run the following commands to transparently bridge the customer B networks connected to R1 and R5:
/interface bridge add name=B/interface bridge port add bridge=B interface=ether1/interface bridge port add bridge=B interface=B1toB2On R5:
/interface bridge add name=B/interface bridge port add bridge=B interface=ether3/interface bridge port add bridge=B interface=B2toB1Because there are no links between segments B1 and B2 except for the single VPLS tunnel between R1 and R5, you do not need to run (R)STP protocol on the bridge.
Split Horizon Bridging
In the example setup, 3 tunnels are set to connect segments A1, A2, and A3, establishing a so-called “full mesh” of tunnels between the involved segments. If bridging was enabled without (R)STP, a traffic loop would occur. If you are looking for some solutions for this, read the following:
Enabling (R)STP
This eliminates the loop, but has a drawback, which is that the (R)STP protocol disables forwarding through one of the tunnels and keeps it only for backup purposes. In this way, the traffic between the 2 segments must pass through 2 tunnels, which makes the setup inefficient.
Use a bridge firewall
This ensures that traffic is not looped and includes setting firewall rules that make bridging less efficient.
Use the bridge horizon feature
The split-horizon bridging basic idea is that traffic arriving over some port is never forwarded to a set of ports. As indicated, the sender of the packet is connected to the target network itself. It means that a packet that arrived through one VPLS tunnel should never be sent to another VPLS tunnel.
For instance, if the device in A1 sends a packet for a broadcast or unknown MAC address (which causes the bridges to flood all interfaces), it is sent to both R5 and R4 through the VPLS tunnels. In a regular setup, for example, when R5 receives such a packet through the VPLS tunnel, sends it to A2 connected to it and also through the VPLS tunnel to R4. So R4 receives 2 copies of the same packet and causes traffic to loop.
You can use the Bridge horizon feature to configure bridge ports with horizon settings so that the packet received from the port with horizon value X is not sent or flooded to any port with the same horizon value X. In the case of a full mesh of VPLS tunnels, you should configure each router with the same horizon value for the VPLS tunnels they are bridged together.
Enable bridging for customer A with the following R1 configuration commands:
/interface bridge add name=A/interface bridge port add bridge=A interface=A1toA2 horizon=1/interface bridge port add bridge=A interface=A1toA3 horizon=1In a similar way, you should configure the bridge on R4 and R5. The physical Ethernet port is not configured with the horizon value. If it did, it would disable the bridge sending data at all.
The horizon value only has meaning locally and is not transmitted over the network, so it does not matter if the same value is configured on all routers participating in the bridge network.
How to Optimize Label Distribution
In the rest of this article, we will teach you how to Configure VPLS on Mikrotik.
Label Binding Filtering
When you implement the given example setup, it becomes clear that not all label bindings are necessary. Since there is no chance they will ever be used, you do not need to exchange IP route label bindings between R1 and R5 or R1 and R4. Also, if a given network core provides connectivity only to the specified client Ethernet segments, there is no real use for distributing labels for networks that connect routers. The only important routes are the /32 routes to the endpoints of the VPLS tunnels.
You can use label binding filtering to distribute only specific sets of labels to reduce resource usage and network load.
Here are Label binding filter types:
–> Label bindings to be advertised to LDP neighbors, configured in /mpls ldp advertise-filter
–> Label bindings to be accepted from LDP neighbors, configured in /mpls ldp accept-filter
Filters are organized into an ordered list and specify the prefix that should contain the prefix tested against the filter and the neighbor (or wildcard).
You can configure all routers to advertise labels only for routes that allow access to tunnel endpoints. For these 2 advertise filters, you need to configure them as follows on all routers:
/mpls ldp advertise-filter add prefix=9.9.9.0/24 advertise=yes/mpls ldp advertise-filter add prefix=0.0.0.0/0 advertise=noThis filter advertises bindings for routes included with the 9.9.9.0/24 prefix that cover the tunnel endpoints (9.9.9.1/32, 9.9.9.4/32, 9.9.9.5/32).
Since the default filter result is to allow the action in question when no rule matches, the second rule is necessary.
In the given configuration, accept filter does not need to be set, because the convention introduced by the 2 rules mentioned above is that no LDP router distributes unnecessary connections.
Filter changes do not affect existing mappings, so connections between neighbors must be reset to apply the filter. You can do this by removing them:
In R1 you will get:
Note that there are still unnecessary bindings. Bindings are distributed due to purposeful LDP sessions distributed with remote endpoints of VPLS tunnels (links 9.9.9.5 and 9.9.9.4).
You must configure the routers to filter them so that they do not distribute any IP bindings to any of the tunnel endpoint routers. For example, in R1, the filter table should be as follows:
This will give the routers minimal label binding tables, for example on R1:
Although they are tunnel endpoints, IP binding distribution should not be disabled between R4 and R5. R4 and R5 do not require an IP binding to the VPLS data tunnel, and doing so does not harm the normal case. But if the link between R3 and R5 goes down, all R5 traffic from R1 must be rerouted through R4. In such cases, R5 does not distribute IP bindings to R4, causing R4 to be unable to forward MPLS traffic to R5.
What are the Effects of Label Binding Filtering on Data Forwarding in the Network?
Now you should notice the traceroute results after these changes. A traceroute from R1 to R5 using R1’s loopback address as the source address still behaves the same. Each hop report received labels:
In traceroute using R1’s network-facing address:
All hops are responded to except the last one. Because there is no label switching path from R5 to R1 (which this time uses address 1.1.1.1) and no label bindings are distributed. So the ICMP response is routed and the routers on the way back (R3 and R2) receive packets with their source address and immediately drop them without routing.
Use their non-loopback addresses to traceroute from R1 to R5 :
There is no label switching to do this traceroute and it works exactly like a network without MPLS.
That’s it!
Conclusion
In this article, we taught you how to configure VPLS on Mikrotik and introduced you to VPLS. I hope you found this tutorial useful and that it helps you to configure VPLS on Mikrotik. If you encounter any issues or have any problems, you can contact us in the Comments section.
