RFC 9786

EVPN Port-Active Redundancy Mode

📅 published June 2025, from ietf

RFC 9786: EVPN Port-Active Redundancy Mode 🦋

  • Authors: P. Brissette, LA. Burdet (Ed.), B. Wen, E. Leyton, J. Rabadan
  • Affiliations listed: Cisco Systems, Comcast, Verizon Wireless, Nokia
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: June 2025
  • Obsoletes/Updates: the header doesn't list any RFCs this one obsoletes or updates 💅

Abstract ✨

Okay so, MC-LAG (Multi-Chassis Link Aggregation Group) lets you make one logical link-aggregation connection across a redundant group of independent nodes 🫶 The whole point is to boost network availability and bandwidth use through different traffic load-balancing modes. RFC 7432 already defines EVPN-based MC-LAG with Single-Active and All-Active multihoming redundancy modes. This doc builds on the redundancy stuff EVPN already has and adds a brand-new active/standby mode called 'Port-Active' 🌸

Status of This Memo

This is an Internet Standards Track document. 🎀

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 📚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9786 🔗

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please actually read these, because they describe your rights and restrictions for this document 👀 Code Components extracted from this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License.

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
  1.2.  Multi-Chassis Link Aggregation (MC-LAG)
2.  Port-Active Redundancy Mode
  2.1.  Overall Advantages
  2.2.  Port-Active Redundancy Procedures
3.  Designated Forwarder Algorithm to Elect per Port-Active PE
  3.1.  Capability Flag
  3.2.  Modulo-Based Algorithm
  3.3.  Highest Random Weight Algorithm
  3.4.  Preference-Based DF Election
  3.5.  AC-Influenced DF Election
4.  Convergence Considerations
  4.1.  Primary/Backup Bits per Ethernet Segment
  4.2.  Backward Compatibility
5.  Applicability
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

So EVPN [RFC7432] already defines the All-Active and Single-Active redundancy modes 💖 All-Active gives you per-flow load balancing for multihoming. Single-Active does service carving, where only one of the Provider Edge (PE) devices in a redundancy relationship is active for each service.

Those two multihoming setups are everywhere in data center and service provider access networks, but there are times when active/standby multihoming at the interface level is actually the better (and necessary) move 🙈 The big thing this new mode is about is determinism: you know exactly which traffic goes through a specific interface, instead of statistical per-flow load balancing across multiple PEs. That determinism is essential for certain QoS features to work correctly. Plus, this mode gives you fast convergence during failure and recovery, which customers totally expect 🔥

This document defines the Port-Active redundancy mode as a brand-new type of multihoming in EVPN, and it details how the mode works and how EVPN supports it 🦋

1.1. Requirements Language

Here's the key-word situation 🧐 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like shown here. If they're lowercase, they're just regular words 💅

Picture a Customer Equipment (CE) device multihomed to a set of PE nodes using the Link Aggregation Control Protocol (LACP) [IEEE_802.1AX_2014]. The PEs have to act like one single LACP entity so the Ethernet links can form and operate as a Link Aggregation Group (LAG) 🎀 To make that happen, the PEs connected to the same multihomed CE have to sync their LACP configuration and operational data with each other. Historically, the Inter-Chassis Communication Protocol (ICCP) [RFC7275] handled that sync. EVPN, as described in [RFC7432], covers the case where a CE is multihomed to multiple PE nodes using a LAG, which simplifies the whole process a lot. But that simplification comes with some assumptions:

  • A CE device connected to EVPN multihoming PEs MUST have a single LAG with all its links connected to the EVPN multihoming PEs in a redundancy group.
  • Identical LACP parameters MUST be configured on peering PEs, including the system ID, port priority, and port key.

This document assumes proper LAG operation as specified in [RFC7432]. Anything that comes from deviating from those assumptions, LAG misconfiguration, and miswiring detection across peering PEs is out of scope here 🙃

                    +-----+
                    | PE3 |
                    +-----+
                 +-----------+
                 |  MPLS/IP  |
                 |  CORE     |
                 +-----------+
               +-----+   +-----+
               | PE1 |   | PE2 |
               +-----+   +-----+
                  I1       I2
                   \       /
                    \     /
                     \   /
                     +---+
                     |CE1|
                     +---+

                         Figure 1: MC-LAG Topology

Figure 1 shows an MC-LAG multihoming topology where PE1 and PE2 are in the same redundancy group, multihoming CE1 through interfaces I1 and I2. I1 and I2 are members of a LAG running LACP. The core (IP or MPLS enabled) provides a wide range of L2 and L3 services. MC-LAG multihoming is decoupled from those core services, and it's all about multihoming the CE ✨ In Port-Active redundancy mode, only one of the two interfaces, I1 or I2, is forwarding, and the other one is on standby. That also means every service on the active interface runs in active mode, and every service on the standby interface runs in standby mode 💜

2. Port-Active Redundancy Mode 🌈

2.1. Overall Advantages

Using Port-Active redundancy in EVPN networks gets you these perks:

  • a. It gives you open-standards-based active/standby redundancy at the interface level, instead of VLAN granularity [RFC7432].
  • b. It gets rid of the need for ICCP and LDP [RFC5036]. (For example, Virtual eXtensible Local Area Network (VXLAN) [RFC7348] or Segment Routing over IPv6 (SRv6) [RFC8402] may be used in the network.)
  • c. It doesn't care about the underlying technology (MPLS, VXLAN, and SRv6) or the services on top of it (Layer 2 (L2), Layer 3 (L3), Bridging, E-LINE, etc.) 🧚
  • d. It enables deterministic QoS over MC-LAG attachment circuits.
  • e. It's fully compliant with [RFC7432] and doesn't need any new protocol enhancements to the existing EVPN RFCs 🫶
  • f. It can use various Designated Forwarder (DF) election algorithms, like modulo [RFC7432], Highest Random Weight (HRW) [RFC8584], etc.
  • g. It replaces legacy MC-LAG ICCP-based solutions and comes with these extra benefits:
    • Efficient support for 1+N redundancy mode (with EVPN using a BGP Route Reflector), whereas ICCP needs a full mesh of LDP sessions among PEs in the redundancy group.
    • Fast convergence with mass withdraw is possible with EVPN, which ICCP has no equivalent for 🏃‍♀️

2.2. Port-Active Redundancy Procedures

Here's the proposed procedure for supporting Port-Active redundancy mode with EVPN LAG 📝

  • a. The Ethernet Segment Identifier (ESI) MUST be assigned per access interface, as described in [RFC7432]. The ESI can be auto-derived or manually assigned, and the access interface MAY be an L2 or L3 interface.
  • b. The Ethernet Segment (ES) MUST be configured in Port-Active redundancy mode on peering PEs for the specified access interface.
  • c. When the ESI is configured on an L3 interface, the ES route (Route Type-4) can be the only route the PEs in the redundancy group exchange 🌸
  • d. PEs in the redundancy group use the DF election defined in [RFC8584] to figure out which PE keeps the port in active mode and which PE(s) keep it in standby mode. Even though the DF election in [RFC8584] works per [ES, Ethernet Tag], in Port-Active redundancy mode the DF election happens per [ES] instead. The details of this algorithm are in Section 3.
  • e. The DF router MUST keep the corresponding access interface up and forwarding in the active state for that ES 💖
  • f. Non-DF routers SHOULD implement a bidirectional blocking scheme for all traffic, comparable to the Single-Active redundancy mode described in [RFC7432], but across all VLANs 🙈
    • Non-DF routers MAY bring the peering access interface attached to them up and keep it in an operational down state.
    • If the interface is running the LACP protocol, the non-DF PE MAY set the LACP state to Out of Sync (OOS) instead of setting the interface to a down state. This approach allows for better convergence during the transition from standby to active mode 🚀
  • g. The primary/backup bits of the EVPN Layer 2 Attributes (L2-Attr) Extended Community [RFC8214] SHOULD be used to achieve better convergence, as described in Section 4.1 🦋

3. Designated Forwarder Algorithm to Elect per Port-Active PE ✨

okay so the ES routes running in Port-Active redundancy mode get advertised with the new Port Mode Load-Balancing capability bit in the DF Election Extended Community, as defined in [RFC8584] 💖. The ES on that port also uses the existing Single-Active procedure and signals the Single-Active multihomed site redundancy mode along with the Ethernet A-D per-ES route (see Section 7.5 of [RFC7432]) 🎀. And lastly, the ESI label-based split-horizon procedures from Section 8.3 of [RFC7432] SHOULD be employed to stop transient echo packets when L2 circuits are involved 🦋.

There are a few DF election algorithms covered in Sections 3.2 to 3.5, and honestly the one you pick doesn't change the complexity or performance much compared to the other redundancy modes 💅.

3.1. Capability Flag

[RFC8584] gives us a DF Election Extended Community with a 2-octet bitmap called "DF Election Capabilities," which goes with the DF algorithm field 🌸. Here's the layout, bestie:

                         1 1 1 1 1 1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |D|A| |T| |P|                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: Amended DF Election Capabilities in the DF Election
                          Extended Community

The bits we already know about are:

  • Bit 0: the D bit, or 'Don't Preempt' bit, as described in [RFC9785] 🧚
  • Bit 1: AC-Influenced DF (AC-DF) election, as described in [RFC8584] 💜
  • Bit 3: Time Synchronization, as described in [RFC9722] ⭐

This document adds one new value and extends the bitmap with it:

  • Bit 5: Port Mode Designated Forwarder Election 👑. This bit tells everyone that the DF election algorithm SHOULD be modified so it only looks at the port ES and ignores the Ethernet Tags 🔥.

3.2. Modulo-Based Algorithm

The default modulo-based algorithm, the one from [RFC7432] and updated by [RFC8584], gets applied here at the granularity of ES only 🍓. The ES-Import Route Target extended community can be auto-derived, and its auto-derived value comes straight from ESI bytes 1-6. So lots of operators tell their ESIs apart mainly within those bytes. That's why bytes 3-6 are used to pick the DF with modulo-based DF assignment, which gives nice entropy across ESIs 🌈.

If you've got a redundancy group of N PE nodes, the PE with ordinal i becomes the DF for an <ES> when (Es mod N) = i, where Es is bytes 3-6 of that ESI ✨.

3.3. Highest Random Weight Algorithm

[RFC8584] defines how Highest Random Weight (HRW) gets applied to EVPN DF election, and it MAY be used and signaled 💖. For Port-Active, it's modified to work at the granularity of <ES> instead of per <ES, VLAN> 🦋.

Section 3.2 of [RFC8584] describes computing a 32-bit Cyclic Redundancy Check (CRC) over the concatenation of Ethernet Tag (V) and ESI (Es) 🎀. For Port-Active redundancy mode, the Ethernet Tag gets left out of the CRC computation, and every (V, Es) reference gets replaced with (Es) 💅.

The algorithm for the DF and Backup Designated Forwarder (BDF) from Section 3.2 of [RFC8584] is repeated below, using only (Es) in the computation 🧚:

  1. DF(Es) = Si| Weight(Es, Si) >= Weight(Es, Sj), for all j. If there's a tie, pick the PE whose IP address is numerically the least. Note that 0 <= i,j < number of PEs in the redundancy group.
  2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, Sk) >= Weight(Es, Sj). If there's a tie, pick the PE whose IP address is numerically the least.

Where:

  • DF(Es) is the address Si (index i) with the highest Weight(Es, Si), where 0 <= i < N-1.
  • BDF(Es) is the PE with address Sk whose computed Weight is the next highest after the Weight of the DF. j is the running index from 0 to N-1, and i and k are the selected values 🌸.

3.4. Preference-Based DF Election

When the new 'Port Mode' capability is signaled, the preference-based DF election algorithm from [RFC9785] gets modified to look at just the port and not any associated Ethernet Tags 🌟. Port Mode works fine alongside the 'Don't Preempt' bit, and you can signal both together 👑. When an interface comes back up, a peering PE that signals the D bit turns on non-revertive behavior at the port level 🫶.

3.5. AC-Influenced DF Election

The AC-DF bit from [RFC8584] MUST be set to 0 when you're advertising the Port Mode Designated Forwarder Election capability (P=1) 🙈. When an AC (sub-interface) goes down, any Ethernet A-D per EVI withdrawal that comes out of it doesn't affect the DF election 💀.

If you receive the AC-DF bit set (A=1) from a remote PE, it MUST be ignored when you're doing Port Mode Designated Forwarder Election 🚫.

4. Convergence Considerations

Okay, convergence during failure and recovery is where Port-Active gets interesting ⚡. To make it faster, it can help a lot if peering PEs sync up beforehand 🫶.

The thing is, Port-Active is kinda tricky for syncing, because the "standby" port might be down. Getting a "standby" port back up and the network stable takes time ⏳. For Integrated Routing and Bridging (IRB) and L3 services, syncing the ARP / Neighbor Discovery (ND) caches beforehand is recommended 🌸. The associated Virtual Routing and Forwarding (VRF) tables might also need syncing 💜. For L2 services, syncing MAC tables is something you may want to consider 🍓.

Also, for LAG members running LACP, you can put the "standby" port into an "out-of-sync" state, also called "warm-standby," to speed up convergence times 🎀.

4.1. Primary/Backup Bits per Ethernet Segment

The EVPN L2-Attr Extended Community from [RFC8214] SHOULD be advertised in the Ethernet A-D per ES route, so you get fast convergence ⚡.

Only the P and B bits in the Control Flags field of the L2-Attr Extended Community matter for this document, specifically for Ethernet A-D per ES routes 🦋:

  • When it's advertised, the L2-Attr Extended Community SHALL have only the P or B bits set in the Control Flags field, and every other bit and field MUST be zero 💅.
  • A remote PE that receives the optional L2-Attr Extended Community in Ethernet A-D per ES routes SHALL consider only the P and B bits and ignore everything else 🧚.

For the L2-Attr Extended Community that gets sent and received in Ethernet A-D per EVI routes used in [RFC8214], [RFC7432], and [RFC9744] 💜:

  • P and B bits received SHOULD be considered overridden by the "parent" bits when they're advertised in the Ethernet A-D per ES 👑.
  • Other fields and bits of the extended community follow the procedures in the referenced documents 🌈.

Following these procedures keeps the L2-Attr Extended Community handled properly, so convergence across Ethernet Segments stays robust and efficient 🫶.

4.2. Backward Compatibility

Implementations that only comply with [RFC7432] or [RFC8214] (aka implementations that came before this spec) and that receive an L2-Attr Extended Community in Ethernet A-D per ES routes will just ignore it 🙈. They keep using the default path resolution algorithms of those two specs:

  • The L2-Attr Extended Community in the Ethernet A-D per ES route gets ignored 💀.
  • The remote ESI Label Extended Community [RFC7432] signals the Single-Active redundancy mode (Section 3) 🍓.
  • The remote Media Access Control (MAC) and/or Ethernet A-D per EVI routes stay unchanged, and the P and B bits in the L2-Attr Extended Community in Ethernet A-D per EVI routes are still used 🎀.

5. Applicability

A really common setup is giving L2 or L3 services on PE devices that have multihoming capabilities 🌸. The services can include any L2 EVPN solution, like EVPN Virtual Private Wire Service (VPWS) or standard EVPN as defined in [RFC7432] 💖. L3 services can also run inside a VPN context, as specified in [RFC4364], or inside a global routing context 🌈. When a PE provides first-hop routing, EVPN IRB can be deployed on the PEs too 🧚. The mechanism in this document applies to PEs providing L2 and/or L3 services where active/standby redundancy at the interface level is needed 👑.

Another option instead of this document's solution is MC-LAG with ICCP active/standby redundancy, as detailed in [RFC7275] 🦋. The catch is that ICCP needs LDP enabled as a transport for its messages 😭. Lots of setups don't need LDP at all, like deployments using VXLAN or SRv6 🍓. The EVPN solution in this document doesn't require LDP or ICCP, and it stays independent of the underlay encapsulation 🫶.

6. IANA Considerations

IANA added the following entry for this document to the "DF Election Capabilities" registry, which lives under the "Border Gateway Protocol (BGP) Extended Communities" registry group 🎀:

    +=====+=========================================+===========+
    | Bit | Name                                    | Reference |
    +=====+=========================================+===========+
    | 5   | Port Mode Designated Forwarder Election | RFC 9786  |
    +-----+-----------------------------------------+-----------+

                               Table 1

7. Security Considerations

Okay, security time, and it's serious 🚨. The security considerations in [RFC7432] and [RFC8584] apply to this document too 🔒.

Introducing a new capability means every PE has to agree on it 🤝. If there's no consensus on the new DF election procedures and Port Mode, the DF election algorithm falls back to the procedures in [RFC8584] and [RFC7432] 😱. That fallback could get exploited by an attacker who messes with the configuration of just one PE in the ES 💀. That manipulation could force every PE in the ES to drop back to the default DF election algorithm and capabilities 🙈. Then the PEs could end up with unfair load balancing, service disruption, and potential problems like traffic loss or duplicate traffic, as mentioned in the security sections of those documents 🚨.

8. References ✨

8.1. Normative References

okay bestie, this is the reading list the spec needs you to have done before it'll make sense 📚💅 these are the docs it leans on hardest, so no skipping!

8.2. Informative References

these ones are the background reading 🧠✨ super useful for context, but the spec doesn't depend on them the way it does on the ones above.

Acknowledgements ✨

big thank-yous 🫶 the authors shout out Anoop Ghanwani for his comments and suggestions, plus Stephane Litkowski and Gunter Van de Velde for their careful reviews. the people who check your work so carefully are literally the MVPs.

Contributors 🎀

the authors on the front page aren't the only ones who helped build this. these people also contributed:

Ali Sajassi
Cisco Systems
United States of America
Email: sajassi@cisco.com


Samir Thoria
Cisco Systems
United States of America
Email: sthoria@cisco.com

Authors' Addresses 💅

and here are the people who actually wrote it, with how to reach them 📬

Patrice Brissette
Cisco Systems
Ottawa ON
Canada
Email: pbrisset@cisco.com


Luc André Burdet (editor)
Cisco Systems
Canada
Email: lburdet@cisco.com


Bin Wen
Comcast
United States of America
Email: Bin_Wen@comcast.com


Edward Leyton
Verizon Wireless
United States of America
Email: edward.leyton@verizonwireless.com


Jorge Rabadan
Nokia
United States of America
Email: jorge.rabadan@nokia.com
📦 where this page comes from