BGP and routing policy extensions for EVPN

SR Linux supports Multi-Protocol BGP with AFI/SAFI EVPN. The following BGP features are relevant to EVPN in a VXLAN network:

• The EVPN address family can use eBGP or iBGP.

• eBGP multihop is supported on SR Linux; local-AS override can be used for iBGP per session.

• A supported configuration or design with eBGP is eBGP with local-as override on the session to an iBGP RR.

• Rapid-update and rapid-withdrawal for EVPN family are supported and are always expected to be enabled, especially along with multihoming.

  Note: Rapid-update is address-family specific, while rapid-withdrawal is generic for all address families.

• The BGP keep-all-routes option is supported for EVPN to avoid route-refresh messages attracting all EVPN routes when a policy changes or BGP-EVPN is enabled.

• The receive-ipv6-next-hops option does not apply to the EVPN address family.

• The prefix-limit max-received-routes and threshold options are supported for EVPN.

• The command network-instance protocols bgp route-advertisement wait-for-fib-install does not apply to EVPN.

• SR Linux BGP resolves BGP-EVPN routes’ next-hops in the network-instance default route-table. If the next-hop is resolved, BGP can mark the route as u*> where u is used, * is valid, and > is best) and send the route to evpn_mgr if needed or reflected to other peers.

• BGP dynamic neighbors for IPv4 and IPv6 families are fully supported in SR Linux. EVPN-VXLAN routes can be resolved to the IPv4 addresses advertised by the dynamic neighbors.

• The command default-received-encapsulation <mpls|vxlan>, added to the BGP configuration in the default network-instance, indicates the encapsulation considered when the EVPN routes are received without a BGP encapsulation EC.

  Most EVPN routes are usually received with a BGP encapsulation extended community (EC) that indicates the encapsulation and therefore how to interpret the value in the received Label fields of the NLRI. If no encapsulation is received, BGP validates the route as MPLS or VXLAN, depending on how this command is configured. The default is vxlan.

The SR Linux fib_mgr makes the route selection across owners for the same prefix in the network-instance route-table based on the following:

1. route-table PREFERENCE
2. METRIC
3. source_id (which is always zero for BGP-based routes)
4. src_instance_id (for leaked routes, the ID of the source network-instance)
5. owner_id, where bgp is preferred over bgp-evpn, and bgp-evpn is preferred over bgp-ipvpn.

For example, if the same prefix 10.0.0.0/16 is received on the same IP-VRF route table via BGP PE-CE (IPv4 family) and via EVPN-IFL, the route with lowest route table PREFERENCE wins. If both routes have the same PREFERENCE (for example, the default 170), the route with lowest METRIC wins (assuming combined-ecmp is not configured). The metric is a measurement of the distance to the next-hop, typically obtained from the IGP protocol that resolves the route.

As another example, if prefix 10.0.0.0/8 is received via BGP PE-CE and via EVPN IFL on the same IP-VRF, with same PREFERENCE and METRIC, the router typically selects the PE-CE route based on the lowest owner_id.

When an IP-VRF network-instance has multiple BGP paths to the same destination, the selection of the best path to install in the FIB is based on the criteria in "BGP best path selection" in the SR Linux Routing Protocols Guide.

SR Linux includes support for applying routing policies to EVPN routes. You can specify the following match conditions in a policy statement:

• match routes based on EVPN route type

• match routes based on IP addresses and prefixes via prefix-sets for route types 2 and 5

• match routes based BGP encapsulation extended community

• match routes based on configured internal-tags

For information about configuring routing policies on SR Linux, see the SR Linux Configuration Basics Guide.

The following considerations apply to routing policies for EVPN:

• For IBGP neighbors, EVPN routes are imported and exported without explicit configuration of any policy at either the BGP or network-instance level.

• For EBGP neighbors, by default, routes are imported or exported based on the ebgp-default-policy configuration.

• When an explicit import/export route-target is configured in a network-instance bgp-instance, and an import/export policy is also configured on the same bgp-instance, the configured policy is used, and its route-target is added to the imported/exported route.

• When a network-instance policy and a peer policy are applied, they are executed as follows:

  • For export, the network-instance export policy is applied first, and the peer policy is applied afterwards (sequentially).

  • For import, peer import policy is applied first and network-instance import policy is applied afterwards (sequentially).

• Only one network-instance export and import policy is supported.

For EVPN AD per-EVI routes, BGP best path selection orders routes using selected BGP attributes, including when candidates have different route distinguishers (RDs).

This ordering applies to EVPN AD per-EVI route handling across all service types that include MAC-VRF (Layer 2 aliasing), VPWS (Ethernet tag ID selection and Layer 2 aliasing), and IP-VRF (Layer 3 aliasing, including non-zero-ESI EVPN-IFL-HOST and non-zero-ESI EVPN-IFL routes).

The BGP best path selection for AD per-EVI routes includes a configurable ECMP break-off behavior with stricter ECMP candidate selection for AD per-EVI routes. Specifically, ECMP only includes routes tied on the winning priority attributes, instead of taking top-N valid routes regardless of attribute mismatch. This is enabled by the ecmp-strict-path-selection command.

Only routes tied on the best priority attributes (local preference and AS-PATH-length) are eligible for ECMP set construction. If fewer than the configured ECMP-width are tied at best attributes, only the smaller tied set is used.

--{ * candidate shared default }--[  ]--
# info with-context system network-instance protocols
    system {
        network-instance {
            protocols {
                evpn {
                    routes {
                        ad-per-evi {
                            ecmp-strict-path-selection {
                            }
                        }
                    }
                }
            }
        }
    }

When ecmp-strict-path-selection is disabled, lower-priority but valid AD per-EVI routes can appear in the ECMP set (up to the ECMP width).

When ecmp-strict-path-selection is enabled, only best-tied routes are included.

When one route has a higher local preference, that route must be selected over alternatives even if those routes have a shorter AS-PATH.