In this case, the host does not send a GARP/ARP packet when moving to the target PE. Only regular data packets are sent. The steps are illustrated in Figure 1.
Host-1 moves from PE1 to PE2 and issues a (non-ARP) frame with MAC SA=M1.
When receiving the frame, PE2 updates its FDB and starts the mobility procedures for M1 (because it was previously learned from EVPN). At the same time, PE2 also creates a short-lived dynamic ARP entry for the host, and triggers an ARP request for it.
PE2 advertises a RT2 with M1 only, and a higher sequence number.
PE1 receives the RT2, updates its FDB and withdraws its RT2s for M1 (this includes the RT2 with M1-only and the RT2 with 10.1-M1).
PE1 issues an ARP request for 10.1, triggered by the update on M1.
In this case, the PEs are configured with flood-garp-and-unknown-req and therefore, the generated ARP request is flooded to local SAP and SDP-binds and EVPN destinations. When the ARP request gets to PE2, it is flooded to PE2’s SAP and SDP-binds and received by Host-1.
Host-1 sends an ARP reply that is snooped by PE2 and triggers a similar process described in Host initiates an ARP/GARP upon moving to the target PE (this is illustrated in the following).
Because passive VRRP is used in this scenario, the ARP reply uses the anycast backup MAC that is consumed by PE2.
Upon receiving the ARP reply, PE2 updates its ARP table to dynamic.
Because the route-table entry for 10.1/32 now changes from EVPN to type arp-nd (based on populate dynamic), PE2 advertises a RT5 with 10.1/32. Also, M1 is now learned in ARP as local, therefore a RT2 for 10.1-M1 is sent (the sequence number follows the RT2 with M1 only).
Upon receiving the route, PE1:
Updates the ARP entry 10.1-M1, from type local to type evpn.
Because the populate dynamic, removes its arp-nd host from the route-table and withdraws its RT5 for 10.1/32.
