Configuring Virtual Link Extension Redundancy with Clusters
The configuration of redundant vLE pseudo-wires requires the replication of the configuration steps described in the above sections. In addition, the endpoints (for example two switches as in the figure below) need to have link bundling enabled (static or dynamic LACP-based negotiation) in order to manage end-to-end path redundancy.
Figure 9-5: Virtual Link Extension End-to-end Redundancy
In this example, let us assume that both test switches, sw-1 and sw-2, are configured with the LACP active negotiation option.
Then, every vLE configuration step needs to be replicated twice to create VLE-1 and VLE-2 (based on two transparent VLANs and four VTEPs):
- Creation of Layer 3 VLANs that are used as tunnel end points
- Set up of dedicated VXLAN connections
- Creation of VXLAN-mapped transparent VLANs
- Addition of the transparent VLAN’s VXLAN ID to the allocated tunnels.
The distinctive configuration step is the creation of the VTEPs (step 2 above): VTEP HA is not required and not supported in case of vLE redundancy (namely, the virtual IPs cannot be used). The four VTEPs can be created instead with each cluster member’s primary IP address like so:
CLI (network-admin@leaf-1) > tunnel-create scope local name VTEP1 vrouter-name vr-s1 local-ip 10.10.11.1 remote-ip 10.10.15.1
CLI (network-admin@leaf-2) > tunnel-create scope local name VTEP2 vrouter-name vr-s2 local-ip 20.20.22.1 remote-ip 20.20.26.1
CLI (network-admin@leaf-5) > tunnel-create scope local name VTEP3 vrouter-name vr-s3 local-ip 10.10.15.1 remote-ip 10.10.11.1
CLI (network-admin@leaf-6) > tunnel-create scope local name VTEP4 vrouter-name vr-s3 local-ip 20.20.26.1 remote-ip 20.20.22.1
Note that 10.10.11.1 and 10.10.15.1 are primary IP addresses used for VLE-1 on leaf-1 and leaf-5 respectively while 20.20.22.1 and 20.20.26.1 are primary IP addresses used for VLE-2 on leaf-2 and leaf-6.
The remaining four steps are the same as those described in the previous sections, replicated for both VLE-1 and VLE-2.
vLE tracking is also greatly beneficial in order to implement redundancy on Netvisor ONE nodes as it propagates link state changes and helps client side’s LACP with timely link up/link down detection.