EVPN host mobility configuration

Figure: Host mobility within the same R-VPLS – initial phase shows an example of a host connected to a source PE, PE1, that moved to the target, PE2. The figure shows the expected configuration on the VPRN interface, where R-VPLS 1 is attached (for both PE1 and PE2). PE1 and PE2 are configured with an ‟anycast gateway”, that is, a VRRP passive instance with the same backup MAC and IP in both PEs.

Figure: Host mobility within the same R-VPLS – initial phase

In this initial phase:

  1. PE1 learns Host-1 IP to MAC (10.1-M1) in the ARP table and generates a host route (RT5) for 10.1/32, because Host-1 is locally connected to PE1. In particular:

    • arp-learn-unsolicited triggers the learning of 10.1-M1 upon receiving a GARP from Host-1 or any other ARP

    • arp-proactive-refresh triggers the refresh of host-1’s ARP entry 30 seconds before the entry ages out

    • local-proxy-arp makes sure PE1 replies to any received ARP request on behalf of other hosts in the R-VPLS

    • arp-host-route populate dynamic ensures that only the dynamically learned ARP entries create a host route, for example, 10.1

    • no flood-garp-and-unknown-req suppresses ARP flooding (from CPM) within the R-VPLS1 context and reduces significantly the unnecessary ARP flooding because the ARP entries are synchronized through EVPN

    • advertise dynamic triggers the advertisement of MAC/IP routes for the dynamic ARP entries, including the IP and MAC addresses, for example, 10.1-M1; a MAC/IP route for M1-only that has been previously advertised as M1 is learned on the FDB as local or dynamic

  2. PE2 learns Host-1 10.1-M1 in the ARP and FDB tables as EVPN type. PE2 must not learn 10.1-M1 as dynamic, so that PE2 is prevented from advertising an RT5 for 10.1/32. If PE2 advertises 10.1/32, then PE3 could select PE2 as the next-hop to reach Host-1, creating an unwanted hair-pinning forwarding behavior. PE2 is expected to have the same configuration as PE1, including the following commands, as well as those described for PE1:

    • no learn-dynamic prevents PE2 from learning ARP entries from ARP traffic received on an EVPN tunnel.

    • populate dynamic, as in PE1, makes sure PE2 only creates route-table ARP-ND host routes for dynamic entries. Hence, 10.1-M1 does not create a host route as long as it is learned via EVPN only.

The configuration described in this section and the cases in the following sections are for IPv4 hosts, however, the functionality is also supported for IPv6 hosts. The IPv6 configuration requires equivalent commands, that use the prefix "nd-" instead of "arp-". The only exception is the flood-garp-and-unknown-req command, which does not have an equivalent command for ND.

Parent topic: EVPN host mobility procedures within the same R-VPLS service