BGP Deterministic Path Forwarding (DPF) with EVPN-VXLAN Implementation

Overview

You can use BGP deterministic path forwarding (DPF) to segment a physical network into multiple logical fabrics by assigning fabric colors to BGP sessions. This document provides example spine and leaf device configurations for an IP fabric using BGP DPF with EVPN-VXLAN. It includes device configuration and verification steps as well as general BGP DPF configuration guidance.

BGP-DPF implements color-based routing, which enables you to advertise routes across different colored paths. By configuring fabric colors at the global, group, or neighbor levels you can control which routes are advertised over specific paths. Integrating DPF with EVPN-VXLAN enables more precise control of traffic flows by utilizing colored routes as underlays. This enables traffic segregation at the MAC-VRF level, ensuring that virtualized environments can benefit from isolated and efficient traffic flows. This control over path selection ensures that the network can meet diverse requirements, such as latency sensitivity and redundancy. In addition to assigning colors for the primary paths, you can set up backup paths for resilience, which ensures seamless failover if the primary path becomes unavailable.

You can use the protocols bgp fabric-advertise route destination statement to advertise colored IPv4 and IPv6 routes. This configuration advertises these routes automatically based on the color configurations without needing an export policy. If a route is configured with the color option, the route is advertised over the EBGP neighbors of the same color and the color community is added to the route. Routes with no color configured are advertised to all EBGP peers.

Configuring a backup color using the backup-color option advertises the route over the EBGP neighbors of the backup color. It also adds the backup color community to the route advertised over the backup fabric. When the backup-color option is configured, an accumulated IGP (AIGP) metric of 0 is added to the route advertised over the primary colored fabric to ensure the primary colored fabric is preferred by upstream routers.

You can configure a colored tunnel endpoint for an EVPN MAC-VRF with the routing-instances name vtep-source-interface inet colored-tunnel-address destination statement. This sets the EVPN routes with the colored-tunnel-address as the protocol next hop (PNH). BGP then advertises these EVPN routes with the specified PNH. When the ingress PE receives the EVPN route, it uses the PNH to resolve the route over the desired colored tunnel endpoint. Therefore different colored tunnel addresses must be configured for MAC-VRFs of different colored fabrics. They cannot share the same virtual tunnel endpoint (VTEP) address.

You can configure a tenant MAC-VRF or an EVPN Type 5 (RT-5) instance without any colored fabric configurations. In these instances, the routes have no color configuration and are advertised to all EBGP peers. These instances can use all spine devices and dynamic load balancing (DLB) to optimize network performance.

DPF Configuration Guidelines and Caveats

When configuring DPF, keep these guidelines and caveats in mind:

• You configure the colors for BGP neighbors using BGP extended communities. These configurations must be consistent across the entire physical fabric. For example, if the BGP extended community color:0:1 represents "Blue" on one router, it must represent "Blue" on all other routers in the same physical fabric.

• When you configure fabric-advertise statements and an export policy on the same router, the export policy should not modify the color communities that the fabric-advertise statements specify. Also, the export policy should not originate the AIGP metric for a fabric-advertise route because color-based routing uses the AIGP metric to indicate the primary color when primary and backup colors are configured.

• BGP advertises all colored routes over uncolored BGP neighbors. When you want to restrict certain routes to specific colors, do not mix uncolored fabrics and colored fabrics.

• BGP advertises uncolored routes across all colored fabrics. If you want to allow only matching colored routes over a specific colored fabric, you should avoid using uncolored routes, with the exception of those that solely carry light control traffic.

• A colored BGP receiver will accept uncolored routes and routes matching its color, but routes with a different color are marked as hidden.

• When deploying EVPN VXLAN with DPF, the overlay multihop EBGP peers between leaf devices remain uncolored. Configure these BGP peers with only family evpn signaling. Do not enable family inet or family inet6 on these peers because that configuration allows the advertisement of colored routes over uncolored multihop EBGP sessions. Aside from EVPN VXLAN overlay BGP sessions, do not configure any additional uncolored multihop EBGP or IBGP peers with colored fabrics. Otherwise, you risk advertising colored routes over these uncolored multihop EBGP or IBGP peers.

• Egress Link Protection (ELP) and Assisted Replication features are not supported when BGP DPF is used with EVPN-VXLAN.

The following sections explain how to configure spine and leaf devices for a DPF colored fabric. The configurations in this example are focused on configuring BGP DPF. The configuration examples included here do not provide all the configurations necessary to implement an IP fabric underlay. These configurations implement color-based BGP communities and fabric color assignments to enable color-based traffic engineering and service-level path selection. This enables different traffic types to be routed through designated network paths based on their color assignments.

For information about how to configure IP fabric underlays see IP Fabric Underlay Network Design and Implementation.

Topology Requirements

This example uses the following hardware and software components:

• A QFX5120 that functions as the super spine and route reflector.

• Two QFX5120s, three QFX5130s and a QFX5700 that function as spine devices.

• Three QFX5120s and a QFX5130 that functions as leaf devices.

• All devices are running Junos OS 25.4R1.

• Please refer to BGP support for deterministic path forwarding (DPF) in a CLOS network for a complete list of the products that support this feature.

Topology

In this example, we have a route reflector connected to six spine devices each configured with one of three different fabric colors. The user can choose to load balance the traffic between leaf devices by using different colored spines. The leaf devices are connected to several server devices as multihomed peers.

This example depicts three colored fabrics, (Blue, Red, and Green), and an uncolored fabric connected to servers S4 and S8. The configuration examples that follow do not include the configurations for the uncolored fabric. Because uncolored routes are advertised to all EBGP peers, the instances on servers S4 and S8 can use all the spines and DLB load balancing.

Figure 1: Colored Fabric Topology

Topology overview:

• The super spine is connected to six colored spine devices.

• Each spine is configured with a color (Blue/Red/Green) to divide the physical fabric into multiple logical fabrics.

• Spine 1, Spine 2, and Spine 3 are connected to Leaf 1 and Leaf 2 via the colored BGP underlay.

• Spine 4, Spine 5, and Spine 6 are connected to Leaf 3 and Leaf 4 via the colored BGP underlay.

• Leaf 1 and Leaf 2 are multihomed peers connected to servers S1 through S4.

• Leaf 3 and Leaf 4 are multihomed peers connected to servers S5 through S8.

In addition to the configurations shown in Figure 1 the leaf devices each have multiple loopback interfaces configured for use with VTEP interfaces.

Spine Configuration and Verification

This section provides guidance for configuring and verifying the spine devices for DPF with EVPN-VXLAN to enable color-based routing.

• Spine Configuration
• Spine Verification

Leaf Configuration and Verification

This section provides guidance for configuring and verifying the leaf devices for DPF with EVPN-VXLAN to enable color-based routing and automatic failover between colored paths. We are only including the Leaf 1 configurations in this example for brevity. The configurations on Leaf 2, Leaf 3, and Leaf 4 are similar.

• Leaf Configurations
• Leaf Verification