Core isolation blackhole avoidance

Figure: Core isolation blackhole avoidance shows how blackholes can be avoided when a PE becomes isolated from the core.

Figure: 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: Core isolation blackhole avoidance 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:

• The oper-group state is determined by the existence of at least one EVPN destination in the EVPN instance.

• The oper-group that is configured under a BGP EVPN instance cannot be configured under any other object (for example, SAP, SDP binding, and so on) of the same or different service.

• The status of an oper-group associated with an EVPN instance goes down in the following cases:

  • the service admin-state is disabled (only for VPLS services, not for Epipes)

  • the BGP EVPN VXLAN or MPLS admin-state are disabled

  • there are no EVPN destinations associated with the instance