EVPN ORF
Background
The growing number of services over EVPNs has triggered a proliferation of new users. As a result, BGP-EVPN peers on an EVPN are sending vast quantities of EVPN routes to each other. Even if the remote peer does not have an RT-matching EVPN instance, the local PE still sends it EVPN routes. To reduce network load, each PE needs to receive only desired routes. If a separate export route policy is configured for each user, the cost of O&M goes up. To address this issue, EVPN outbound route filtering (ORF) can be deployed.
Implementation
After EVPN ORF is configured, each PE on the EVPN sends the import VPN target (IRT) and original AS number of the local EVPN instance to the other PEs or BGP EVPN RRs that function as BGP-EVPN peers. The information is sent through ORF routes. Upon receipt, the peers construct export route policies based on these routes so that the local PE only receives the expected routes, which reduces the receiving pressure on the local PE.
Figure 1 shows the basic EVPN ORF network on which each device supports EVPN ORF. PE1, PE2, and PE3 establish BGP-EVPN peer relationships with the RR, and are also clients of the RR. An EVPN instance with a specific RT is configured on each PE.
Before EVPN ORF is enabled, the RR advertises all the routes received from PE1's EVPN instances to PE2 and PE3. However, PE2 only needs routes with an export VPN target (ERT) of 1:1, whereas PE3 only needs routes with an ERT of 2:2. As a result, PE2 and PE3 discard unwanted routes upon receipt, which wastes device resources.
After EVPN ORF is enabled on all devices and BGP-EVPN peer relationships are established between the PEs and RR in the BGP-VT address family view, the BGP-EVPN peers negotiate the EVPN ORF capability. Each device sends the IRT of its local EVPN instance to the BGP-EVPN peers in the form of ORF routes. Each device then constructs an export route policy based on the received ORF routes. Upon construction, PE1 only sends EVPN1's and EVPN4's routes to the RR. The RR then only sends routes with an ERT of 1:1 to PE2 and those with an ERT of 2:2 to PE3.
The BGP-VT address family obtains the IRT configured on the local device regardless of the type of the instance that the IRT comes from. If EVPN ORF is enabled on a network that consists of devices that do not support EVPN ORF, the EVPN service cannot run properly. However, the BGP-VT address family can resolve this problem.
On the network shown in Figure 1, PE1, PE2, and PE3 establish BGP-EVPN peer relationships with the RR. PE1, PE2, and PE3 are clients of the RR. Suppose that PE1, PE2, and the RR all support EVPN ORF but that PE3 does not, as it is running an early version. If EVPN ORF is enabled on the network and the BGP-VT peer relationships are established, PE3 does not send ORF routes to the RR, which means that PE1 does not receive the ORF routes with an ERT of 2:2 from the RR. As a result, PE1 does not send EVPN4's routes to the RR, thereby compromising the services between EVPN4 and EVPN2. Because the BGP-VT address family does not differentiate the type of instance the IRT belongs to, you can configure an L3VPN instance on PE3 and set both IRT and ERT to 2:2. This configuration allows PE3 to advertise an ORF route with an IRT of 2:2 to the RR, which then advertises this route to PE1. Upon receipt, PE1 modifies its export route policy so that it can advertise EVPN2's routes to the other PEs.
In addition to configuring an L3VPN instance, you can also configure the RR to advertise default ORF routes to PE1 and PE3 and delete the BGP-VT peer relationship between the RR and PE3. After the configuration is complete, PE1, PE2, and PE3 advertise all routes to the RR. The RR then advertises routes with ERTs of 1:1 and 2:2 to PE1, routes with an ERT of 1:1 to PE2, and all routes to PE3.
If both EVPN and L3VPN services are deployed on the preceding network, the preceding two ways cannot be used. If you use either of them, the L3VPN service cannot run properly. On the network shown in Figure 2, only PE3 does not support EVPN ORF. After EVPN ORF is enabled on the network, the EVPN service cannot run properly. If an L3VPN instance is created, the new L3VPN instance receives the other PEs' L3VPN routes from the RR, which compromises the L3VPN service. To resolve this issue, you can disable the RR from filtering routes based on the IRT for PE3, thereby ensuring that both EVPN and L3VPN services can run properly.
Benefits
Bandwidth consumption is lowered (because the number of routes being advertised is smaller).
System resources such as CPU and memory are saved.