In a VPLS service to which multiple EVPN PEs and BGP-VPLS PEs are attached, single-active multihoming is supported on two or more of the EVPN PEs with no special considerations. All-active multihoming is not supported, because the traffic from the all-active multihomed CE could cause a MAC flip-flop effect on remote BGP-VPLS PEs, asymmetric flows, or other issues.
Figure 1 illustrates a scenario with a single-active Ethernet-segment used in a service where EVPN PEs and BGP-VPLS are integrated.
Although other single-active examples are supported, in Figure 1, CE1 is connected to the EVPN PEs through a single LAG (lag-1). The LAG is associated with the Ethernet-segment 1 on PE1 and PE2, which is configured as single-active and with oper-group 1. PE1 and PE2 make use of lag>monitor-oper-group 1 so that the non-DF PE can signal the non-DF state to CE1 (in the form of LACP out-of-synch or power-off).
In addition to the BGP-VPLS routes sent for the service ve-id, the multihoming PEs in this case need to generate additional BGP-VPLS routes per Ethernet Segment (per VPLS service) for the purpose of MAC flush on the remote BGP-VPLS PEs in case of failure.
The sap>bgp-vpls-mh-veid number command should be configured on the SAPs that are part of an EVPN single-active Ethernet Segment, and allows the advertisement of L2VPN routes that indicate the state of the multihomed SAPs to the remote BGP-VPLS PEs. Upon a Designated Forwarder (DF) switchover, the F and D bits of the generated L2VPN routes for the SAP ve-id are updated so that the remote BGP-VPLS PEs can perform a mac-flush operation on the service and avoid blackholes.
As an example, in case of a failure on the Ethernet-segment sap on PE1, PE1 must indicate PE3 and PE4 the need to flush MAC addresses learned from PE1 (flush-all-from-me message). Otherwise, for example, PE3 continues sending traffic with MAC DA = CE1 to PE1, and PE1 blackholes the traffic.
In the Figure 1 example:
Both ES peers (PE1 and PE2) should be configured with the same ve-id for the ES SAP. However, this is not mandatory.
In addition to the regular service ve-id L2VPN route, based on the sap>bgp-vpls-mh-ve-id configuration and upon BGP VPLS being enabled, the PE advertises an L2VPN route with the following fields:
ve-id = sap>bgp-vpls-mh-ve-id identifier
RD, RT, next hop and other attributes same as the service BGP VPLS route
L2VPN information extended community with the following flags:
D=0 — if the SAP is oper-up or oper-down with a flag MHStandby (for example, the PE is non-DF in single-active MH)
D=0 also if there is an ES oper-group and the port is down because of the oper-group
D=1 — if the SAP is oper-down with a different flag (for example, port-down or admin-down)
F (DF bit) =1 — if the SAP is oper-up, F=0 otherwise
Upon a failure on the access SAP, there are only mac-flush messages triggered in case the command bgp-vpls-mh-ve-id is configured in the failing SAP. In case it is configured with ve-id 1:
If the non-DF PE has a failure on the access SAP, PE2 sends an update with ve-id=1/D=1/F=0. This is an indication for PE3/PE4 that PE2's SAP is oper-down but it should not trigger a mac-flush on PE3/PE4.
If the DF PE has a failure on the SAP, PE1 advertises ve-id=1/D=1/F=0. Upon receiving this update, PE3 and PE4 flushes all their MACs associated with the PE1's spoke SDP. Note, that the failure on PE1, triggers an EVPN DF Election on PE2, which becomes DF and advertises ve-id=1/D=0/F=1. This message does not trigger any mac-flush procedures.
Other considerations:
PE3/PE4 are SR OS or any third-party PEs that support the procedures in draft-ietf-bess-vpls-multihoming, so that BGP-VPLS mac-flush signaling is understood.
PE1 and PE2 are expected to run an SR OS version that supports the sap>bgp-vpls-mh-veid number configuration on the multihomed SAPs. Otherwise, the mac-flush behavior would not work as expected.
The procedures described above are also supported if the EVPN PEs use MC-LAG instead of an ES for the CE1 redundancy. In this case, the SAP ve-id route for the standby PE is sent as ve-id=1/D=1/F=0, whereas the active chassis advertises ve-id=1/D=0/F=1. A switchover triggers mac-flush on the remote PEs as described earlier.
The L2VPN routes generated for the ES and SAPs with the sap bgp-vpls-mh-veid number command are decoded in the remote nodes as bgp-mh routes (because they do not have label information) in the show router bgp routes l2-vpn command and debug.