Duplicate IP or legitimate host move

Introduction to EVPN and GARP

Ethernet VPN (EVPN) (RFC 7432, extended by RFC 8365) distributes MAC/IP reachability via BGP. Each leaf learns host bindings locally (ARP/ND/DHCP snooping) and advertises them as Type‑2 routes. The BGP NLRI includes the Ethernet Segment Identifier (ESI) for multi‑homed hosts, the MAC address, the IP address (if present), and an optional MAC Mobility extended community that carries a sequence number and a sticky flag. Upon receipt, a remote leaf installs the binding in its MAC table and programs the corresponding VXLAN tunnel.

EVPN separates the control plane (BGP) from the data plane (VXLAN, MPLS, or bare‑ethernet), enabling fast convergence when a host moves: the new leaf advertises a higher sequence number, prompting peers to withdraw the stale binding and reinstall the new one without ARP flooding.

GARP Timing and Its Role in EVPN

Gratuitous ARP (GARP) is an ARP request where the source and target IP addresses are identical, used to announce or verify address ownership. Hosts emit a burst of GARP packets when configuring an IP, waking from sleep, or detecting a possible address conflict. Linux, for example, sends GARP at 1 s, 2 s, 4 s, 8 s, then repeats every 20 s up to a configurable maximum (/proc/sys/net/ipv4/conf/*/arp_announce and arp_retry).

In an EVPN fabric, GARP serves two functions:

1. Local learning trigger – A leaf that receives a GARP for an unseen IP/MAC pair creates a local binding and originates a Type‑2 route.
2. Conflict detection – If a leaf receives a GARP for an IP/MAC pair it already owns but with a different MAC (or from a different port), it treats the packet as a potential duplicate‑address claim and may invoke the EVPN duplicate‑address detection procedure (RFC 7432 §7.10).

The timing of GARP bursts influences how quickly the control plane converges after a mobility event or detects a duplicate address. Too‑long intervals delay convergence; too‑short intervals cause unnecessary churn.

Understanding EVPN Sequence Numbers

Sequence Number Generation and Tracking

The MAC Mobility extended community (type 0x06) holds a 16‑bit sequence number and a sticky bit. When a leaf originates a Type‑2 route for a MAC/IP binding, it sets the sequence number to the value stored in its local MAC‑mobility table for that MAC (initialized to zero on first learning). Each time the leaf detects a change in the binding’s point of attachment—e.g., the MAC appears on a different local interface or a GARP arrives with a different MAC—it increments the sequence number (wrapping at 0xFFFF) and re‑advertises the route.

Remote leaves store the received sequence number in their remote‑MAC‑mobility table. BGP best‑path selection prefers the route with the highest sequence number (treated as an unsigned integer). Ties are broken by router‑ID/originator‑ID, then cluster‑list length, etc., per the standard BGP path selection algorithm.

Role of Sequence Numbers in Mobility Events

During a legitimate host move:

1. The host sends a GARP (or ARP reply) from its new attachment point.
2. The new leaf learns the binding locally, increments its local sequence number (e.g., from 5 to 6), and advertises a Type‑2 route with seq = 6.
3. Peers receive the new route, compare seq = 6 against the previously stored seq = 5, and select the new route as best.
4. The stale route (seq = 5) is withdrawn implicitly; each peer sends a BGP withdraw for the old NLRI.
5. The forwarding plane updates the MAC table and VXLAN tunnel map, usually within a few hundred milliseconds (depending on BGP keepalive and update timers).

If the host merely sends a GARP to verify address ownership (common during DHCP renew or IPv4LL probing) without changing its attachment point, the sequence number is not incremented. The leaf re‑advertises the same sequence number, causing no best‑path change and thus no churn.

ARP Ownership and Local Learning

ARP Ownership and Its Impact on Mobility

In EVPN, ARP ownership identifies the leaf that is the authoritative source for a given IP/MAC binding. Ownership derives from the MAC Mobility sequence number: the leaf that originated the highest‑sequence‑number Type‑2 route is the current owner. When a leaf receives an ARP request or reply for an IP it believes it owns, it checks the sender’s MAC against its local binding:

• Match – Packet is processed normally (e.g., an ARP reply is generated).
• Mismatch – Packet is treated as a potential duplicate‑address claim. The leaf may silently drop it, generate a local ARP probe, or trigger a MAC‑mobility conflict procedure that can lead to withdrawal of both competing routes if sequence numbers are equal.

ARP ownership prevents a leaf from forwarding traffic to a stale binding after a host moves, because the stale binding ceases to be the owner once a higher sequence number is advertised.

Local Learning and Its Role in Address Resolution

Local learning derives MAC/IP bindings from traffic received on access ports. Common mechanisms:

• ARP snooping – binds an IP to the MAC of the sender in ARP requests/replies.
• ND inspection (IPv6) – similar to ARP snooping for Neighbor Advertisements/Solicitations.
• DHCP snooping – extracts client‑ID and assigned IP from DHCP packets.
• Static bindings – manually configured MAC/IP pairs.

When a leaf learns a binding locally, it:

1. Inserts the MAC into its L2 MAC table with the appropriate VNI (VXLAN) or bridge domain.
2. Creates a host‑route entry in the local RIB for the IP (if IP routing is enabled) pointing to the MAC.
3. Increments its local MAC‑mobility sequence number for that MAC (if the binding is new or the point of attachment changed).
4. Originates or updates a Type‑2 EVPN route carrying the updated sequence number.

Local learning is the foundation that lets EVPN react to host mobility without data‑plane flooding; the control plane propagates the new binding, and all leaves update forwarding state in a coordinated fashion.

Distinguishing Ordinary Mobility from Duplicate Address Claims

Ordinary Mobility Events and EVPN Response

An ordinary mobility event occurs when a single host changes its point of attachment while retaining the same MAC and IP address. Observable EVPN behavior:

• The old leaf stops advertising the Type‑2 route (either after a hold‑time expiry or upon receiving a higher‑seq advertisement from the new leaf). It does not increment its sequence number.
• The new leaf learns the binding via local ARP/ND snooping, increments its sequence number, and advertises a Type‑2 route with the higher seq.
• Peers perform a best‑path comparison, select the new route, and implicitly withdraw the old one.
• MAC tables on all leaves are updated to point to the VNI associated with the new leaf’s VTEP.
• No duplicate‑address alarms are raised because sequence numbers are strictly increasing.

The key indicator is a monotonically increasing sequence number observed in the MAC Mobility extended community across successive updates for the same MAC.

Duplicate Address Claims and EVPN Response

A duplicate address claim arises when two distinct hosts (different MAC addresses) simultaneously use the same IP address (possibly with MAC spoofing) behind different leaves. EVPN response differs:

1. Sequence number equality or conflict – Each leaf learns its own host’s binding and originates a Type‑2 route with its own local sequence number (typically starting at zero and incrementing only on local moves). Because the hosts are independent, their sequence numbers evolve independently. If both hosts are stationary, each leaf continuously advertises the same sequence number (e.g., seq = 0) for the shared IP.
2. Conflict detection – When a leaf receives a Type‑2 route for an IP/MAC pair that it already owns but with a different MAC, it compares sequence numbers:
   • Incoming seq > local seq → treated as a legitimate mobility event; ownership updates.
   • Incoming seq ≤ local seq → flags a duplicate‑address condition (per RFC 7432 §7.10). Possible actions:
     • Send a MAC‑mobility conflict notification (syslog/SNMP trap).
     • Temporarily withdraw its own Type‑2 route to avoid blackholing traffic.
     • Enter a hold‑down state, refraining from re‑advertising the binding for a configurable period.
3. ARP‑level behavior – Both hosts continue to send ARP requests/replies for the shared IP. Leaves see ARP packets with mismatched MACs and may generate ARP probes (RFC 5227) to verify uniqueness. If probes receive no reply, the leaf may reclaim the address; otherwise, the conflict persists.
4. Forwarding impact – Traffic destined for the shared IP may be load‑balanced or hashed between the two leaves according to the ECMP hash of the VNI/VTEP, resulting in packet loss, out‑of‑order delivery, or intermittent connectivity for both hosts.

Thus, the distinguishing signature of a duplicate address claim is the presence of multiple, competing Type‑2 routes for the same IP with equal or non‑monotonically increasing sequence numbers, accompanied by ARP‑level probes and possible conflict notifications.

Troubleshooting Duplicate Address Claims

Identifying Duplicate Address Claims

Follow a systematic control‑plane trace:

1. Verify multiple Type‑2 routes for the same IP

   show bgp l2vpn evpn route-type 2 <ip-address> detail

   Look for more than one path with the same IP but different MAC addresses. Note the sequence number carried in the MAC Mobility extended community for each path.

2. Check sequence number relationships
   If the sequence numbers are identical (or differ only by a small, non‑monotonic amount) and the MACs differ, a duplicate‑address claim is suspected.

3. Inspect ARP tables on the involved leaves

   show ip arp | include <ip-address>
   show mac address-table | include <mac-address>

   Confirm that each leaf believes it owns the IP with a different MAC.

4. Look for conflict logs or syslog messages

   show logging | include duplicate-address
   show logging | include mac-mobility conflict

   Many platforms emit a syslog entry or SNMP trap when duplicate‑address detection is triggered.

5. Validate ARP probe activity

   show arp inspection statistics | include <ip-address>

   An increase in ARP probe requests/replies for the disputed IP supports the duplicate‑address hypothesis.

6. Temporarily disable duplicate‑address detection (if safe) to observe behavior

   configure terminal
   no evpn duplicate-address detection
   end

   Monitor whether the conflicting routes persist or one leaf withdraws its route.

By correlating equal sequence numbers, differing MACs, ARP‑level probes, and conflict notifications, an operator can confidently distinguish a genuine host move from a duplicate‑address claim and take appropriate remediation steps.