In massive-scale web architectures (like DNS servers or global CDNs), relying on a single IP address tied to a single physical server creates a single point of failure and terrible geographic latency. If your primary DNS server is in New York, users in Tokyo will suffer 200ms of latency on every query.
The solution is BGP Anycast. Anycast allows you to assign the exact same IP address (e.g., 198.51.100.53) to multiple Linux servers distributed globally across different data centers. The servers use the Border Gateway Protocol (BGP) to advertise this single IP address to the internet routers. When a user in Tokyo queries 198.51.100.53, the internet routers automatically forward the packet to the physically closest server in Tokyo, based on the shortest BGP AS-path. If the Tokyo server crashes, its BGP daemon stops advertising the route, and traffic instantly converges to the next closest server (e.g., in Singapore).
This guide explains how to transform a standard Linux server into an Anycast node using FRRouting (FRR), the industry-standard open-source routing suite.
Understanding the Anycast Architecture
Setting up an Anycast node involves two primary components:
- The Loopback Interface (Dummy Interface): You assign the Anycast IP address (
198.51.100.53) to a virtual loopback interface on the Linux server. Your application (e.g., NGINX or BIND9) binds to this IP address. - The BGP Daemon (FRR): The FRR daemon establishes a BGP peering session with the upstream Top-of-Rack (ToR) switch and injects the Anycast IP into the global routing table.
Step 1: Configuring the Anycast IP on the Loopback Interface
You cannot assign the Anycast IP to your primary physical ethernet interface (eth0), because eth0 needs a unique, local IP address to establish the BGP session with the switch.
Instead, assign the Anycast IP to a dummy interface.
sudo ip link add anycast0 type dummy
sudo ip addr add 198.51.100.53/32 dev anycast0
sudo ip link set dev anycast0 up
Note: It is critical to use a /32 subnet mask (a host route). You are advertising exactly one IP, not a network block.
Step 2: Installing and Enabling FRRouting (FRR)
Install the FRR package. On Debian/Ubuntu:
sudo apt-get update
sudo apt-get install frr
FRR contains many routing daemons (OSPF, IS-IS, RIP). By default, they are all disabled. You must explicitly enable the BGP daemon.
Edit the daemon configuration file:
sudo nano /etc/frr/daemons
Change bgpd=no to bgpd=yes.
bgpd=yes
Restart the FRR service:
sudo systemctl restart frr
Step 3: Configuring the BGP Peering Session
FRR uses a unified configuration shell (vtysh) that mimics the command-line interface of Cisco IOS hardware routers.
Assume your Linux server is assigned Autonomous System Number (ASN) 65001, and its physical eth0 IP is 10.0.0.10. The upstream ToR switch is ASN 65000 with the IP 10.0.0.1.
Enter the FRR shell:
sudo vtysh
Enter global configuration mode and configure the BGP router:
configure terminal
router bgp 65001
Define the upstream switch as a neighbor and establish the peering session:
neighbor 10.0.0.1 remote-as 65000
neighbor 10.0.0.1 description ToR-Switch-A
Step 4: Advertising the Anycast Route
Now that the BGP session is established, you must instruct BGP to advertise the Anycast IP address (which lives on your dummy interface) to the switch.
Still within the router bgp configuration block, use the network command:
address-family ipv4 unicast
network 198.51.100.53/32
exit-address-family
Write the configuration to memory and exit the shell:
exit
write memory
exit
Step 5: Verifying BGP Convergence and Failover
To verify that the Linux server successfully established the BGP session and is actively advertising the route, re-enter vtysh and check the BGP summary:
sudo vtysh -c "show ip bgp summary"
You should see the 10.0.0.1 neighbor with an “Up/Down” time, and the “State/PfxRcd” column should show a number (indicating active routes) rather than “Idle” or “Active” (which indicate failed connections).
To verify the specific Anycast route is being advertised:
sudo vtysh -c "show ip bgp neighbors 10.0.0.1 advertised-routes"
You will see 198.51.100.53/32 actively being pushed to the switch.
The Failover Mechanism:
If this Linux server loses power, the BGP Keepalive packets will stop. Within seconds (based on the BGP Hold Timer), the ToR switch will tear down the session, withdraw the 198.51.100.53/32 route from the global internet table, and the internet will instantly recalculate the path, sending all future traffic to the surviving Anycast nodes in other data centers.
Conclusion
BGP Anycast is the foundation of high-availability, low-latency global infrastructure. By coupling the lightweight FRRouting suite with Linux dummy interfaces, systems engineers can seamlessly integrate bare-metal application servers directly into the BGP routing fabric, achieving instant, network-level failover without relying on complex, software-based load balancers.