EVPN-VPWS Multihomed IOS-XR (Single-Active)
Last updated
Last updated
Load multi.service.init.cfg
The CEs now have two subinterfaces: BE1.10 and BE1.20.
Configure two separate VPWS, one per VLAN.
Configure the PEs so that PE1 and PE3 are active for VLAN 10 and PE2 and PE4 are active for VLAN 20.
Single-Active multihoming adds some complexity but has better utilization of link bandwidth. With single-active, all links in the bundle are always up. However, the PEs only forward traffic for a certain set of EVIs (services).
To configure single-active, you simply specify the load-balancing-mode as single-active:
Additionally, we can manually specify which PE should be active for which service using the following configuration. The service is based on the service command in the xconnect, not the EVI number.
We can see the results of the carving election using the following command. Below we see that PE1 is primary for EVI 10 but backup for EVI 20:
These values are not signaled in a BGP update as we saw previously, when using preference weights with port-active. Instead, this is manually configuring each PE to be primary and backup on a specific list of EVIs.
We see on PE1 that it puts the xconnect using EVI 20 in standby mode:
This posses a potential problem for the CE. The CE always sees both links as active in the bundle when using single-active. Therefore the CE needs to also manually map VLAN 20 to the link towards PE2 as primary. For this reason, traffic may or may not work between CE1 and CE2.
Just as before, the PEs indicate whether they are active or standby for a given VPWS in the BGP update. PE4 sees that PE1 is standby for EVI 20.
To get traffic to work, we need to manually map each VLAN to each link on the CE. One quick way to do it is to just create two separate BE interfaces.
Each CE now has two single-interface bundles:
Traffic is now working:
However, we have lost redundancy now. If the CE1-PE1 link goes down, the operator would need to manually move the be1.10 interface to be2.10.
For this reason, I would think that port-active is more widely-deployed than single-active.
The hrw mode (highest random weight) is another option for automatic load sharing for the DF election. By default, with the modulo based election, uneven distribution can occur if all EVIs are even or odd. By using HRW mode, the election is based on a more random calculation that should produce more optimal load distribution.
There is a new multihoming mode called single-flow-active. This is used with bridged EVPN. The PE that first advertises the host MAC for a VLAN is the one that will forward traffic for that specific flow. This feature helps with fast reconvergence as well. The primary PE learns the MAC through the data plane and advertises it with LP=100. The standby PE learns the MAC through the control plane, and reoriginates it with LP=80. If the standby PE later learns the MAC through the data plane, it advertises it with LP=100.
The use case for this is a ring topology. First, CE1 forwards traffic through CE3 and PE2 originates all MACs:
Then the CE1-CE3 link goes down, and PE1 learns the MAC in the data plane, advertising them with LP=100.
The key idea behind this seems to be that the active PE is driven by receiving the traffic in the data plane, not by DF election. Note that this mode cannot be used with EVPN-VPWS.
