When dealing with mission-critical services like corporate websites, VPN endpoints, or SSH gateways, traditional DNS-based failover mechanisms often fall short. The fundamental limitation arises when your redundant WAN connections (like BT Business Infinity Fiber in this case) provide completely separate IP address pools.

Standard approaches like Round Robin DNS or third-party DNS failover services introduce several problems:

// Example of problematic DNS configuration
example.com. IN A 217.45.201.1
example.com. IN A 92.45.201.1 // Second WAN's IP

This creates inconsistency during failover scenarios, as cached records may point to the offline IP for extended periods (TTL dependencies). The "messy" aspect comes from:

• DNS propagation delays
• TCP connection timeouts during transition
• Potential SSL certificate mismatches

While you're correct that traditional anycast typically requires /24 or larger blocks, there are practical workarounds for dual-WAN scenarios:

# Fortigate BGP configuration example for prefix advertisement
config router bgp
    set as 65123
    set router-id 217.45.201.254
    config neighbor
        edit "192.0.2.1" // BT's BGP peer
            set remote-as 12345
            set route-map-out "WAN1_PREFIX"
        next
        edit "192.0.2.2" // Second BT peer
            set remote-as 12345
            set route-map-out "WAN2_PREFIX"
        next
    end

For organizations that can't obtain a /24, consider these hybrid approaches:

// Using Cloudflare's Load Balancing with health checks
$ curl -X POST "https://api.cloudflare.com/client/v4/zones/:zone_id/load_balancers" \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "failover.example.com",
        "fallback_pool": "backup-pool",
        "default_pools": ["primary-pool"],
        "region_pools": {},
        "pop_pools": {},
        "proxied": true,
        "ttl": 60,
        "steering_policy": "dynamic_latency"
    }'

1. Work with your ISP to establish BGP sessions (most business fiber providers support this)
2. Configure identical health checks on both WAN interfaces
3. Implement route maps that withdraw advertisements during outages
4. Set proper BGP timers for fast convergence (sub-second for critical services)

Use these commands to validate your setup:

# Check BGP neighbor status
get router info bgp summary

# Verify advertised routes
get router info routing-table details

# Test failover (trigger interface shutdown)
execute shutdown port3

The key advantage of this approach is that DNS becomes irrelevant for actual connectivity - clients always reach the nearest/available endpoint through BGP's shortest-path selection.

When running enterprise networks with dual ISP connections (like BT Business Infinity Fibre in this case), maintaining DNS availability during WAN failures presents unique challenges. The core issue emerges when:

• Primary WAN's static IP becomes unreachable
• Secondary WAN has completely different IP ranges (/29 blocks typically)
• Traditional DNS TTL delays cause unacceptable downtime

Common approaches like round-robin DNS or commercial DNS failover services often prove inadequate because:

// Example of problematic round-robin configuration
$ dig example.com

;; ANSWER SECTION:
example.com.     300     IN      A       203.0.113.1
example.com.     300     IN      A       198.51.100.1

The 50% failure rate during outages and TTL caching issues make this unacceptable for critical services.

For Fortigate 100D routers with BGP capability, here's a robust approach:

1. Obtain an AS number from your RIR (ARIN/RIPE/etc.)
2. Configure BGP sessions with both ISPs
3. Announce your /24 (minimum required by most ISPs) to both providers

# FortiOS BGP Configuration Snippet
config router bgp
    set as 64512
    set router-id 192.168.1.1
    config neighbor
        edit "203.0.113.254"
            set remote-as 12345
            set route-map-out "WAN1_OUT"
        next
        edit "198.51.100.254"
            set remote-as 67890
            set route-map-out "WAN2_OUT"
        next
    end
end

Even without a full /24, you can implement near-real-time failover using CloudFlare's API:

#!/bin/bash
# DNS Failover Script for CloudFlare
WAN1_IP="217.45.201.1"
WAN2_IP="92.45.201.1"
CF_API_KEY="your_api_key"
CF_ZONE_ID="your_zone_id"
RECORD_ID="your_record_id"

if ! ping -c 3 $WAN1_IP &> /dev/null; then
    curl -X PUT "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$RECORD_ID" \
    -H "Authorization: Bearer $CF_API_KEY" \
    -H "Content-Type: application/json" \
    --data '{"type":"A","name":"mylesgray.com","content":"'$WAN2_IP'","ttl":60}'
fi

Some ISPs offer anycast services for smaller blocks than /24. Consider:

• BT's Enhanced DNS services (may accept /28 announcements)
• CloudFlare Spectrum for TCP services
• AWS Global Accelerator for hybrid solutions

Implement verification checks to prevent false positives:

# Advanced health check script
#!/bin/bash
check_wan() {
    local ip=$1
    local test_url="http://$ip/healthcheck"
    local http_code=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 3 $test_url)
    [[ $http_code -eq 200 ]] && return 0 || return 1
}