Anycast am WAN Edge: Architektur und Routing-Implikationen

Anycast am WAN Edge bedeutet: Mehrere Standorte oder Edge-Knoten announcen dieselbe Service-IP (oder dasselbe Prefix), und das Routing entscheidet, zu welchem „nächsten“ Anycast-Node der Traffic fließt. Das wirkt simpel („eine IP, viele Nodes“), hat aber starke Routing-Implikationen: Pfadwahl hängt von IGP/BGP-Metriken, Policy und Topologie ab; Failover ist oft elegant, aber Session-Stickiness ist nicht garantiert; und Troubleshooting wird ohne saubere Telemetrie schnell schwierig. Dieser Artikel erklärt Anycast-Architektur am WAN Edge, typische Use-Cases und die Designregeln, die im Betrieb wirklich stabil laufen.

Anycast vs. Unicast: Was ist der Kernunterschied?

Bei Unicast gehört eine IP genau einem Ort. Bei Anycast gehört dieselbe IP mehreren Orten. Der Traffic geht „zum nächsten“ Ort – aber „nächster“ bedeutet im Routing nicht geografisch, sondern „best path“ gemäß Metrik/Policy.

Routing-Denkmodell

$\text{Anycast-Ziel}\to \text{BestPath(IGP/BGP Policy)}\ne \text{Geografie}$

• Vorteil: einfaches Failover über Routing
• Risiko: keine Garantie für „Stickiness“ pro Session
• Konsequenz: Health-Checks und Withdrawal-Logik sind Pflicht

Typische Anycast Use-Cases am WAN Edge

Am WAN Edge ist Anycast besonders attraktiv für stateless oder „leicht zustandsbehaftete“ Services. Klassische Beispiele sind DNS-Resolver, Proxies, Security-Stacks oder zentrale Gateways für bestimmte VRFs.

• DNS-Resolver (intern): kurze Transaktionen, gut anycast-fähig
• Recursive DNS / DNS64 Resolver Pools
• HTTP(S) Proxies / Secure Web Gateway (mit Design für Session-Stickiness)
• Anycast VIP für Edge-Firewall/Service-Cluster (mit State-Design)

Architekturvarianten: Global Anycast vs. Domain Anycast

Die wichtigste Entscheidung ist der Scope. Global Anycast (über viele Regionen) liefert maximale Resilienz, erhöht aber das Risiko von Path Shifts. Domain Anycast (pro Region/PoP) ist oft stabiler, weil der Routingraum kleiner und kontrollierbarer ist.

• Global Anycast: ein Prefix in allen PoPs
• Regional Anycast: Prefix pro Region, weniger Cross-Region Shifts
• Site Anycast: mehrere Edges in einem Standort (HA lokal)

Routing-Implikationen: IGP vs. BGP und „Best Path“ Effekte

Am WAN Edge wird Anycast häufig über BGP verteilt (z. B. zwischen Sites/PoPs), während innerhalb eines Standorts IGP oder ECMP die interne Verteilung übernimmt. Die Pfadwahl hängt dann von Attributen wie Local Preference, AS Path, MED, IGP Cost und Next-Hop-Resolution ab.

• IGP: „nächster“ Knoten nach IGP-Metrik (in einer Domäne)
• eBGP: „nächster“ Knoten nach BGP-Policy/Attributen
• iBGP: braucht klares RR-/Policy-Design, sonst überraschende Pfade

Best Path Reihenfolge (vereinfachtes Denken)

• Policy zuerst (LocalPref, Communities, Route-Maps)
• Dann Pfadattribute (AS Path, MED)
• Dann IGP-Nähe zum Next-Hop

Health und Withdrawal: Ohne sauberes Health-Model ist Anycast riskant

Anycast funktioniert nur gut, wenn ein Node ein Prefix zuverlässig withdrawen kann, sobald der Service nicht mehr gesund ist. Ein „Router up, Service down“ darf nicht weiter announcen, sonst wird Anycast zum Blackhole.

• Health-Check: Service-Probe (DNS/HTTP/TCP) statt nur Interface-Status
• Withdrawal: Prefix/Route wird bei Failure entfernt oder de-prefered
• Dampening: Flap-Schutz, sonst Routing-Flaps

Health-Check Pattern mit IP SLA + Track + Route Control

ip sla 10
 tcp-connect 10.10.10.10 53 source-interface Loopback10
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability

delay down 10 up 5
ip route 10.10.10.0 255.255.255.0 Null0 track 10

Session-Stickiness: Der häufigste Betriebs-Fallstrick

Anycast garantiert nicht, dass Hin- und Rückweg immer zum gleichen Node gehen, oder dass ein Flow bei einem Routing-Shift am gleichen Node bleibt. Für DNS ist das meist egal. Für stateful Services (Proxy, Firewall, NAT) kann das katastrophal sein, wenn State nicht geteilt wird.

• Stateless Services: Anycast ideal (DNS, einfache UDP/TCP-Checks)
• Stateful Services: nur mit State-Sync oder Flow-Steering betreiben
• NAT/Firewall: Anycast ohne State-Design führt oft zu Asymmetry-Problemen

Anycast und NAT: Warum das schnell gefährlich wird

Wenn du Anycast als „Internet-Gateway“ nutzt, entstehen schnell asymmetrische Rückwege: Ein Flow geht zu Edge A, der Rückweg landet bei Edge B. Ohne gemeinsamen NAT-State wird Rücktraffic gedroppt. Deshalb ist Anycast für NAT nur sinnvoll, wenn du State konsequent beherrschst.

• Option 1: State Sharing (Cluster/HA, wenn Plattform unterstützt)
• Option 2: Flow-Pinning (Policy, Hash-Steering, symmetrisches Routing)
• Option 3: Anycast nur für stateless Frontends, nicht für NAT-State

Anycast und Security: Policy-Konsistenz und „Rogue Announcements“

Anycast erhöht die Bedeutung von Routing-Governance. Ein falsches Announcement kann Traffic großflächig umleiten. Deshalb brauchst du strikte Filter und klare Ownership für das Anycast-Prefix.

• Prefix-Lists: nur definierte Anycast-Prefixes erlauben
• Max-Prefix/Route-Maps: Schutz vor Route Leaks
• Monitoring: Announcement-Drift und Pfadänderungen

Operational Observability: Ohne Telemetrie ist Anycast „magisch“

Im Betrieb musst du jederzeit beantworten können: Welcher Node ist aktuell „best“ und warum? Dafür brauchst du BGP/IGP Sichtbarkeit, Traffic-Metriken pro Node und Logs über Health-Transitions.

• Routing: BGP best path, IGP cost, Next-Hop
• Service: Health-Checks, Error Rates, Latency
• Traffic: NetFlow/Telemetry pro Edge, Drops/Queues

Verifikation (Router)

show ip bgp <anycast-prefix>
show ip route <anycast-ip>
traceroute <anycast-ip>
show ip cef <anycast-ip> detail

Design-Patterns, die im Betrieb stabil laufen

Diese Patterns sind in WAN-Edge Umgebungen besonders robust, weil sie Failover kontrollieren und Session-Risiken reduzieren.

• Anycast für DNS/Resolver: stateless, sehr stabil
• Regional Anycast statt global: weniger Path Shifts
• Health-gesteuerte Withdrawals: keine Blackholes
• Stateful Services nur mit Cluster/State-Sync oder bewusstem Steering

Quick-Runbook: Anycast Incident Isolation

Diese Checkliste hilft, schnell zu klären, ob das Problem Routing (Best Path), Health (Withdrawal) oder State (Session-Stickiness) ist.

show ip bgp <anycast-prefix>
show ip route <anycast-ip>
show ip cef <anycast-ip> detail
traceroute <anycast-ip>
show ip sla summary
show track brief
show interfaces | include drops|error

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.