Core isolation blackhole avoidance

Figure 1 shows how blackholes can be avoided when a PE becomes isolated from the core.

Figure 1. Core isolation blackhole avoidance

In this example, consider that PE2 and PE1 are single-active multihomed to CE1. If PE2 loses all its core links, PE2 must somehow notify CE1 so that PE2 does not continue attracting traffic and so that PE1 can take over. This notification is achieved by using oper-groups under the BGP-EVPN instance in the service. The following is an example output of the PE2 configuration.

*[ex:configure service vpls ”evi1"]
A:admin@PE-2# info
    admin-state enable 
    bgp-evpn { 
        evi 1 
        mpls 1 { 
            admin-state enable 
            oper-group ‟evpn-mesh”
            auto-bind-tunnel { 
                resolution any 
            } 
        } 
    } 
    sap lag-1:351 { 
        monitor-oper-group ‟evpn-mesh”
            } 
*[ex:configure service oper-group ”evpn-mesh"]
A:admin@PE-2# info detail 
    hold-time { 
        up 4 
    } 

With the PE2 configuration and Figure 1 example, the following steps occur.

  1. PE2 loses all its core links, therefore, it removes its EVPN-MPLS destinations. This causes oper-group ‟evpn-mesh” to go down.

  2. Because PE2 is the DF in the Ethernet Segment (ES) ES-1 and sap lag-1:351 is monitoring the oper-group, the SAP becomes operationally down. If ETH-CFM fault propagation is enabled on a down MEP configured on the SAP, CE1 is notified of the failure.

  3. PE1 takes over as the DF based on the withdrawal of the ES (and AD) routes from PE2, and CE1 begins sending traffic immediately to PE1 only, therefore, avoiding a traffic blackhole.

Generally, when oper-groups are associated with EVPN instances: