The umr originate command enables UMR in a BD.
The undo umr originate command disables UMR in a BD.
By default, UMR is not originated, UMR routes will not be generated and MAC detail routes will not be suppressed.
Usage Scenario
On a standard network, MAC routes of all users are transmitted through RRs on the entire network, which causes heavy pressure on RRs. In addition, the MAC address capacity of aggregation devices limits the number of sending users that can access the network. Therefore, the UMR solution advertises an unknown MAC-route (UMR) route from the access device to the aggregation device, instead of advertising all specific MAC routes in the standard EVPN, reducing the pressure on RRs and MAC address learning on aggregation devices.
After the umr originate command is run in the BD to enable UMR on the sender, the sender generates MAC routes with all-0 MAC addresses and does not add the suppression flag to the specific MAC routes. After the umr originate detail-suppressed command is run in the BD view, the sender adds the suppression flag to the original specific MAC routes after UMR is enabled. By default, BGP EVPN peers do not advertise specific MAC routes with the suppression flag. The peer advertise evpn mac-route detail-only command is run in the BGP-EVPN view to prevent the device from advertising all-0 MAC routes to BGP-EVPN peers and advertise all specific MAC routes, including the specific MAC routes with the suppression flag.The umr originate [detail-suppressed] command and the peer advertise evpn mac-route detail-only command in the BGP-EVPN view are used to control whether to advertise all-0 MAC routes and specific MAC routes to BGP-EVPN peers.
Prerequisites
UMR can only be configuredafter the BD is bound by an EVPN instance.
Precautions
The undo umr originate command will disable detail-suppressed as well. detail-suppressed can only be configuredafter UMR is originated.
EVPN instances on each pair of A-Leaf nodes are different and are isolated by RTs. Different A-Leaf pairs need to be configured with different BDs. In a dual-homing scenario, after the AC interface on an ALeaf node goes down (there are still AC interfaces in the up state), the UMR on the ALeaf node is not withdrawn. Before the ALeaf node learns the user-side MAC address, half of the downstream unknown unicast traffic is discarded.<HUAWEI> system-view [~HUAWEI] evpn vpn-instance 1 bd-mode [*HUAWEI-evpn-instance-1] route-distinguisher 1:1 [*HUAWEI-evpn-instance-1] vpn-target 1:1 export-extcommunity [*HUAWEI-evpn-instance-1] vpn-target 1:1 import-extcommunity [*HUAWEI-evpn-instance-1] quit [*HUAWEI] bridge-domain 1 [*HUAWEI-bd1] evpn binding vpn-instance 1 [*HUAWEI-bd1] umr originate detail-suppressed
<HUAWEI> system-view [~HUAWEI] evpn vpn-instance 1 bd-mode [*HUAWEI-evpn-instance-1] route-distinguisher 1:1 [*HUAWEI-evpn-instance-1] vpn-target 1:1 export-extcommunity [*HUAWEI-evpn-instance-1] vpn-target 1:1 import-extcommunity [*HUAWEI-evpn-instance-1] quit [*HUAWEI] bridge-domain 1 [*HUAWEI-bd1] evpn binding vpn-instance 1 [*HUAWEI-bd1] umr originate