DF State Is Not Endpoint Reachability

Introduction to DF Election Context

In an EVPN multihoming scenario, each Ethernet Segment (ES) is identified by an Ethernet Segment Identifier (ESI) shared by two or more Provider Edge (PE) devices attached to the same customer sites. The multihoming control‑plane state consists of three tightly coupled components:

1. Ethernet Segment Route (RT‑4) – advertised by each PE to announce its participation in a given ES. It carries the ESI, the PE’s own IP address (used as a tie‑breaker), an optional DF‑election priority, and the Ethernet Segment‑Import (ES‑Import) route target that binds the route to the EVPN instance (EVI).
2. MAC/IP Advertisement Route (RT‑2) – advertised by each PE to convey the MAC (and optionally IP) addresses it has learned locally for the ES. RT‑2 is the vehicle for data‑plane reachability of end‑hosts.
3. ES‑Import Route Target – a community value carried in both RT‑4 and RT‑2 that tells other PEs which routes belong to the same ES within a given EVI. The ES‑Import RT is configured per‑ESI and is the key that allows a PE to correlate RT‑4 advertisements from remote peers with its local ES state.

The multihoming control‑plane state is therefore the collection of all RT‑4 routes received for a particular ESI, the local RT‑4 originated by the PE, and the set of RT‑2 routes (both local and remote) that share the same ES‑Import RT. This state is stored in the EVPN instance’s Ethernet Segment table (sometimes called the ESI table) and is consulted whenever the PE needs to decide whether it should act as the Designated Forwarder (DF) for broadcast, unknown‑unicast, or multicast (BUM) traffic on that ES.

Emergence of DF Election Context

The DF election context is not a separate protocol; it is a derived state that emerges when the PE evaluates the Ethernet Segment table against the DF election algorithm defined in RFC 7432 (and its subsequent refinements). The emergence proceeds as follows:

1. Receipt of RT‑4 – When a PE receives an RT‑4 from a remote peer, it extracts the ESI, the advertising PE’s IP address, and any DF‑election priority. The route is inserted into the Ethernet Segment table under the corresponding ESI key.
2. Local RT‑4 Generation – The PE originates its own RT‑4 (if not already done) and inserts it into the same table, marking it as the “local” entry.
3. ES‑Import RT Matching – Both local and remote RT‑4 entries are matched against the ES‑Import RT configured for the ESI. Only routes that carry the correct ES‑Import RT are considered valid for DF election; any RT‑4 lacking this RT is ignored for election purposes (though it may still be used for other functions such as split‑horizon filtering).
4. Election Input Set – The set of valid RT‑4 entries (local + remote) for a given ESI constitutes the input to the DF election algorithm. The algorithm typically selects the DF based on:
   • DF‑election priority (higher value wins, if present)
   • PE IP address (lower IP address wins as a tie‑breaker)
   • ESI (implicitly identical for all entries in the set)
5. State Installation – The winning PE marks itself as DF in its local Ethernet Segment table and installs the corresponding DF‑state flag (often a boolean or a bitmap per VLAN/EVI). All other PEs mark themselves as non‑DF (or backup).
6. Forwarding Consequence – The DF state determines which PE will replicate and forward BUM frames received on the ES toward the local access ports. Non‑DF PEs suppress BUM forwarding to avoid duplication, while still forwarding unicast traffic based on RT‑2 MAC/IP information.

Thus, the DF election context is a direct product of the multihoming control‑plane state: it is the outcome of applying the DF election algorithm to the collection of RT‑4 routes that share a valid ES‑Import RT. No RT‑2 information participates in the election itself.

Understanding RT‑4 Contributions

Role of RT‑4 in DF Election

RT‑4 (Ethernet Segment Route) is the sole carrier of the data required for DF election. Its fields contribute as follows:

When a PE originates its RT‑4, it sets the ESI (configured locally), inserts its own loopback IP, and optionally includes a DF‑Election priority if the operator wishes to influence the outcome. The ES‑Import RT is copied from the ESI’s configuration (often derived from an ESI‑specific route‑target or from a global EVPN import RT). The resulting RT‑4 is then advertised to all BGP peers (including route‑reflectors) that belong to the same EVPN address family.

Impact of RT‑4 on Multihoming Control‑Plane State

The presence or absence of RT‑4 directly shapes the Ethernet Segment table:

• Addition of a valid RT‑4 expands the election input set, potentially changing the DF if the new route has higher priority or a lower IP address than the current winner.
• Withdrawal of an RT‑4 (due to link failure, ESI mis‑configuration, or BGP session tear‑down) removes an entry from the set; if the withdrawn route was the current DF, a re‑election occurs immediately, promoting the next‑best peer.
• Incorrect ES‑Import RT causes the RT‑4 to be ignored for election purposes, effectively making the advertising PE invisible to the DF process. The PE may still forward unicast traffic (based on RT‑2) but will never be selected as DF, leading to asymmetric BUM forwarding.
• Duplicate ESI with conflicting ES‑Import RTs can partition the Ethernet Segment table into disjoint subsets, each running its own independent DF election. This results in multiple DFs for the same logical ES, causing BUM duplication and possible loops unless split‑horizon mechanisms intervene.

Because RT‑4 is the only vehicle that conveys the PE’s identity and priority to remote peers, any error in its origination, transmission, or reception directly corrupts the DF election context, while RT‑2 remains unaffected.

RT‑2 Correctness and False Confidence

Relationship Between RT‑2 and DF Election Outcome

RT‑2 (MAC/IP Advertisement Route) carries endpoint reachability information. Its fields (MAC address, IP address, MAC mobility sequence number, etc.) are used by the data plane to:

• Install MAC entries in the local forwarding table (FIB) for unicast forwarding.
• Trigger MAC move detection when the same MAC appears with a different sequence number or from a different PE.
• Support ARP/ND proxy and symmetric IRB functions when configured.

The DF election algorithm does not inspect any RT‑2 fields. Consequently:

• A PE can be elected DF even if it has zero local MAC/IP entries (i.e., no RT‑2 originated for that ES).
• Conversely, a PE can possess a perfectly correct set of RT‑2 routes (reflecting all locally learned MACs) yet lose the DF election because its RT‑4 is less favorable (lower priority or higher IP address).

Thus, the DF election outcome is orthogonal to RT‑2 correctness.

Pitfalls of Reading DF Outcome as Proof of RT‑2 Correctness

Interpreting a successful DF election as evidence that RT‑2 is correct introduces several failure modes:

1. Silent MAC/IP Loss – If a PE’s local learning process fails (e.g., due to a mis‑configured MAC learning limit, ACL blocking, or hardware fault), it may stop originating RT‑2 for certain MACs. The DF election continues unchanged because it relies solely on RT‑4. Traffic destined to the missing MACs will be blackholed or incorrectly flooded, yet the DF appears healthy.
2. Stale RT‑2 Advertisements – A PE might continue to advertise outdated RT‑2 entries (e.g., after a MAC move) due to a stuck MAC mobility sequence number. The DF election remains unaffected, but forwarding may send frames to the wrong PE, causing duplicate delivery or loss.
3. RT‑2 Filtering Misconfiguration – Import or export policies that inadvertently drop RT‑2 for a given ES‑Import RT will not affect the DF election (since RT‑4 still passes). The PE will believe it is DF, but the remote PEs will not receive the MAC advertisements, leading to unicast blackholes.
4. Asymmetric ES‑Import RT – If the ES‑Import RT used for RT‑4 differs from that used for RT‑2 (a mis‑match in the ESI‑to‑RT mapping), RT‑4 may be considered for DF election while RT‑2 is excluded from the EVI. The DF election will succeed, but the PE will not install any MAC entries for that ES, resulting in a DF that forwards BUM but cannot forward unicast.

These scenarios illustrate that DF election is a necessary but not sufficient condition for correct multihoming operation. Operators must validate RT‑2 state independently.

Troubleshooting DF Election Context Issues

Identifying Common Issues in Multihoming Control‑Plane State

A systematic troubleshooting approach begins with verifying the Ethernet Segment table:

Key checks include:

• ESI consistency – Verify that the ESI configured on the physical/logical port matches the ESI carried in RT‑4.
• ES‑Import RT match – Confirm that the RT‑4’s ES‑Import RT equals the ESI’s import RT (often derived from esi or configured under routing-instances <evn> protocols evpn ethernet-segment).
• RT‑4 validity – Ensure the RT‑4 carries a non‑zero Ethernet Segment length and a valid PE address.
• BGP session health – Check for BGP flaps, stale timers, or inbound/outbound filter drops affecting RT‑4.

Debugging RT‑4 Contributions to DF Election Context

When RT‑4 is suspected, the following drill‑down steps isolate the problem:

1. Confirm local RT‑4 generation

   # Juniper
   show configuration routing-instances <evn> protocols evpn ethernet-segment
   # Look for: esi <value>; df-election-priority <prio>;

2. Verify the RT‑4 is installed in the local BGP table

   # Juniper
   show route table <evn>.evpn.0 detail | match