IP SLA für Path Validation: NAT/IPv6/Provider Checks automatisieren

IP SLA ist auf Cisco Routern das Standardwerkzeug, um Pfade aktiv zu validieren – nicht nur „Link up/down“, sondern echte Erreichbarkeit über NAT, IPv6 oder einen Provider hinweg. Genau dafür ist IP SLA im Betrieb so wertvoll: Du misst kontinuierlich, ob ein definierter Zielservice erreichbar ist (z. B. DNS, HTTP, ICMP), und kannst daraus automatisierte Entscheidungen ableiten (z. B. Default-Route Failover, Alarmierung, Policy Switch). In modernen Designs ersetzt IP SLA damit viele „Blind-Failover“-Mechanismen, die nur Interface-Status betrachten und bei Provider-Teilausfällen falsch reagieren. Dieser Artikel zeigt praxisnahe IP-SLA Patterns für Path Validation – mit Fokus auf NAT, IPv6 und Provider-Checks.

Warum „Interface up“ nicht reicht

Ein WAN-Link kann physisch up sein, während Internetzugang, NAT oder IPv6 gebrochen sind (BGP-Blackhole, Provider-DNS down, PMTUD kaputt). IP SLA prüft den End-to-End Zustand und reduziert falsche Failovers.

• Link up, aber Routing/Provider down
• NAT-State/Port-Exhaustion: Internet wirkt down, Interface up
• IPv6: Default Route ok, aber ICMPv6/PMTUD blockiert

IP SLA Bausteine: Operation, Schedule, Tracking

IP SLA besteht aus einer Operation (was wird getestet?), einem Schedule (wie oft?) und optional Object Tracking (wie wird das Ergebnis für Routing/Policies genutzt?). Für Automatisierung ist Tracking der Schlüssel.

• Operation: icmp-echo, udp-jitter, tcp-connect, http-get u. a.
• Schedule: Start und Frequenz
• Track: boolean Status (up/down) oder Schwellenwerte

Merker

$\text{Decision}=\text{Track(IP SLA)} \to \text{Route/Policy}$

Designregel: Tests müssen die echte Failure Domain abdecken

Ein guter IP-SLA Test zielt nicht auf den Provider-Gateway (zu nah), aber auch nicht auf einen einzelnen externen Host (zu zufällig). Ideal sind 2–3 Ziele: Provider Edge, ein „stabiler“ Internet-Anchor (z. B. Resolver), und optional ein Applikationsziel (HTTP).

• Ziel 1: Provider Next-Hop (schnell, lokale Fehler)
• Ziel 2: Internet Anchor (z. B. Public DNS, Anycast)
• Ziel 3: Applikationsziel (HTTP/TCP, wenn relevant)

Pattern 1: Provider Check (ICMP Echo) mit Source Interface

Der Standard-Check ist ICMP Echo mit festem Source Interface, damit du wirklich den gewünschten Uplink testest. Ohne Source kann CEF/ECMP den Test „falsch“ routen.

IP SLA ICMP Echo (Beispiel)

ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now

Tracking binden

track 10 ip sla 10 reachability

Pattern 2: NAT Path Validation (Proof of NAT) mit TCP Connect

Für NAT-Validierung reicht ICMP oft nicht, weil ICMP anders behandelt wird als TCP. Ein TCP Connect auf Port 443 ist ein guter „Proof“, dass NAT, Routing und ein realistischer Internetpfad funktionieren. Wichtig: Ziel muss stabil erreichbar sein.

TCP Connect über WAN (NAT Proof)

ip sla 20
 tcp-connect 1.1.1.1 443 source-interface GigabitEthernet0/0
 frequency 10
 timeout 1500
ip sla schedule 20 life forever start-time now

track 20 ip sla 20 reachability

Pattern 3: IPv6 Provider Check (icmp-echo ipv6)

Für Dual-Stack und IPv6-only Designs brauchst du separate v6 Checks. IPv6 kann unabhängig von IPv4 kaputt sein (RA/ND/PMTUD/Default). IP SLA erlaubt IPv6 Echo mit Source Interface.

IPv6 Echo Check (Pattern)

ip sla 30
 icmp-echo ipv6 2001:4860:4860::8888 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 30 life forever start-time now

track 30 ip sla 30 reachability

Pattern 4: DNS Check indirekt (UDP Echo / TCP Connect als Proxy)

IP SLA hat keine „DNS Query“ im einfachsten Grundset. In der Praxis validierst du DNS über TCP/HTTP zu einem Resolver-Endpoint oder du prüfst einen internen DNS-Forwarder, der wiederum extern auflösen muss. Ziel ist: DNS-Ausfälle nicht mit „Internet down“ zu verwechseln.

• Check interner Resolver per ICMP/TCP 53
• Check externer Resolver per TCP 53 (falls erlaubt) oder TCP 443 (Proxy)

TCP Connect auf DNS (wenn erlaubt)

ip sla 40
 tcp-connect 8.8.8.8 53 source-interface GigabitEthernet0/0
 frequency 15
 timeout 1500

Pattern 5: Multi-ISP Failover mit Floating Static Routes

Der klassische Einsatz ist Dual-WAN Failover. IP SLA steuert eine Default Route über Tracking: Solange Track up ist, bleibt die primäre Route aktiv. Bei Ausfall wird eine sekundäre Route mit höherer AD genutzt.

Default Route mit Tracking

ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 10
ip route 0.0.0.0 0.0.0.0 198.51.100.1 200

IPv6 Default mit Tracking (Pattern)

ipv6 route ::/0 2001:db8:feed::1 track 30
ipv6 route ::/0 2001:db8:beef::1 200

Pattern 6: „Composite Health“ – mehrere SLAs als Entscheidungslogik

Ein einzelner SLA-Test kann false positives erzeugen (Zielhost down). Stabiler ist ein Composite: z. B. Track gilt als „up“, wenn mindestens 2 von 3 Tests erfolgreich sind. Das erreichst du über Track Listen (boolean AND/OR Logik).

Track List OR (mindestens einer up)

track 101 list boolean or
 object 10
 object 20
 object 30

Track List AND (alle müssen up)

track 102 list boolean and
 object 10
 object 20

Tuning: Frequency, Timeout, Thresholds und Dampening

Zu aggressive Checks verursachen Flapping und unnötige Failovers. Zu langsame Checks erkennen Ausfälle zu spät. Ein praxistauglicher Start ist 5–10 Sekunden Frequency, 1–2 Sekunden Timeout und ein Down-Delay (Dampening) via Track Delay.

Track Delay (Flap-Schutz)

track 10 ip sla 10 reachability
 delay down 10 up 5

Troubleshooting: Wenn IP SLA „lügt“

IP SLA muss denselben Pfad nehmen wie echter Traffic. Die häufigsten Fehler sind fehlendes Source Interface, falsche VRF, Policy Routing, oder Firewall-Regeln, die SLA-Traffic anders behandeln als Nutzertraffic.

• Source Interface fehlt → SLA nimmt falschen Uplink
• VRF fehlt → Test läuft im globalen Routing, nicht im VRF
• ACL/QoS priorisiert SLA-Traffic → „gesund“, obwohl Nutzer leiden
• NAT Exemptions → SLA umgeht NAT-Realität

Status prüfen

show ip sla summary
show ip sla statistics
show track brief

Praxis-Runbook: Path Validation automatisieren (Copy & Paste)

Dieses Beispiel kombiniert Provider-ICMP, NAT-Proof via TCP 443 und IPv6 Echo, plus Composite Track und Failover-Routes. Passe IPs und Interfaces an.

ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now
ip sla 20

tcp-connect 1.1.1.1 443 source-interface GigabitEthernet0/0

frequency 10

timeout 1500

ip sla schedule 20 life forever start-time now
ip sla 30

icmp-echo ipv6 2001:4860:4860::8888 source-interface GigabitEthernet0/0

frequency 5

timeout 1000

ip sla schedule 30 life forever start-time now
track 10 ip sla 10 reachability

delay down 10 up 5

track 20 ip sla 20 reachability

delay down 10 up 5

track 30 ip sla 30 reachability

delay down 10 up 5
track 101 list boolean or

object 10

object 20
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 101

ip route 0.0.0.0 0.0.0.0 198.51.100.1 200

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.