{"id":16139394,"url":"https://github.com/networkop/rarp-replay","last_synced_at":"2025-04-06T17:43:19.228Z","repository":{"id":83590195,"uuid":"585279838","full_name":"networkop/rarp-replay","owner":"networkop","description":"capture reverse ARP and send an ARP back (Probe VM after migration)","archived":false,"fork":false,"pushed_at":"2023-01-07T13:41:57.000Z","size":38,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-12T23:45:06.137Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/networkop.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-01-04T19:16:45.000Z","updated_at":"2023-01-07T13:40:30.000Z","dependencies_parsed_at":"2023-07-07T21:45:43.246Z","dependency_job_id":null,"html_url":"https://github.com/networkop/rarp-replay","commit_stats":null,"previous_names":[],"tags_count":8,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/networkop%2Frarp-replay","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/networkop%2Frarp-replay/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/networkop%2Frarp-replay/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/networkop%2Frarp-replay/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/networkop","download_url":"https://codeload.github.com/networkop/rarp-replay/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247526675,"owners_count":20953141,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-09T23:48:54.532Z","updated_at":"2025-04-06T17:43:19.205Z","avatar_url":"https://github.com/networkop.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# rarp-replay\n\nThe goal of this application is to assist a physical network with MAC and IP address discovery of a migrated VM.\n\n## Problem statement\n\nWhenever a VM gets migrated to another host, the receiving hypervisor issues a reverse ARP (RARP) request containing the MAC address of the virtual NIC belonging to the VM. The purpose is to update the MAC address forwarding tables of the physical network connecting all hypervisors together. This is true for both [Vmware ESXI](https://kb.vmware.com/s/article/90045) and [Libvirt/Qemu](https://docs.openstack.org/nova/zed/configuration/config.html#workarounds.enable_qemu_monitor_announce_self).\n\nIn most cases, this is enough to restore network connectivity to the migrated VM. However, in some cases, this may not be enough. Consider the following situation, when the fabric is running the EVPN-VXLAN with ARP suppression enabled:\n\n1. A VM gets migrated from a host attached to `switch-1` to a host attached to `switch-2`.\n2. `switch-2` receives a RARP, updates its forwarding table and EVPN process generates a BGP Update containing (only) the MAC address of the VM (RARP requests do not contain IP addresses). \n3. When this Update reaches `switch-1`, it triggers a BGP route withdrawal, removing any prior MAC and/or MAC-IP routes in the fabric.\n4. In case the migrated VM is silent or not actively sending any packets, external connectivity to it from other subnets will be disrupted since the fabric is not aware of the new MAC-IP binding. The connectivity is restored when the VM sends the next ARP request to refresh its local neighbor cache.\n\nThis is similar to a [problem](https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-08#section-8.8) described in the extended MAC mobility RFC draft. \n\n## Solution\n\nThe solution to this is to issue an ARP request from the switch that receives the RARP request, before the MAC-IP withdrawal. Taking the situation described above as the baseline, here's how it changes with the help of `rarp-reply` application:\n\n1. A VM gets migrated from a host attached to `switch-1` to a host attached to `switch-2`.\n2. `switch-2` receives a RARP, updates its forwarding table and EVPN process generates a BGP Update. \n3. Each switch is running a special process that listens to incoming RARP packets and generates an ARP request to the VM for each received RARP request.\n4. To build the ARP request, the switch uses its local ARP/ND cache to lookup the existing MAC-IP binding. This happens way before the Withdrawal arrives back from `switch-1`.\n5. The ARP request triggers a reply from the migrated VM, which updates the local MAC-IP binding and generates another BGP Update containing both MAC and IP addresses of the VM.\n\n## Applications\n\nThe current repository contains two packages.\n\n### rarp-req\n\nThis is a Linux binary that can issue RARP requests with user-provided MAC address. It's only supposed to be used for testing of the `rarp-reply` application.\n\n```\nsudo ./rarp-req -mac 44:38:39:22:01:23 -intf eth0\n```\n\n### rarp-reply\n\nThis is a long-running, blocking process that connects to all available interfaces and starts listening to incoming RARP packets. As soon as it sees a RARP request, it builds a normal ARP, using its local MAC-IP as the source and VM's MAC-IP as the ARP target addresses. The ARP request is sent back over the same interface with the destination MAC extracted from the source MAC of the RARP request.\n\n```\nsudo ./rarp-reply\n```\n\nThis should result in the following sequence of packets:\n\n![](./rarp-reply.png)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnetworkop%2Frarp-replay","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnetworkop%2Frarp-replay","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnetworkop%2Frarp-replay/lists"}