Traffic Engineering Basics für ISPs: Pfade per Policy steuern

Traffic Engineering Basics für ISPs bedeutet, Netzwerkpfade nicht dem Zufall zu überlassen, sondern sie gezielt per Policy zu steuern. In Provider-Netzen entscheidet die Pfadwahl darüber, ob Latenz stabil bleibt, ob Peering-Links überlasten, ob Kunden bei Störungen „nur ein bisschen langsamer“ sind oder komplett ausfallen – und ob Sie teuren Transit vermeiden können, ohne neue Risiken wie asymmetrisches Routing oder Blackholing einzubauen. Gleichzeitig ist Traffic Engineering (TE) kein „magischer Knopf“. Es ist eine Kombination aus klaren Zielen (z. B. Kosten, Latenz, Auslastung, Resilienz), einem Datenmodell (welcher Traffic wohin), operativen Regeln (wie und wann Änderungen erfolgen) und technischen Hebeln (BGP-Attribute, IGP-Metriken, Communities, ECMP, ggf. SR/RSVP-TE). Dieser Artikel erklärt Traffic Engineering Basics für ISPs praxisnah: Welche TE-Hebel es gibt, wie man Inbound und Outbound steuert, welche Monitoring-Signale zwingend sind und welche typischen Fallstricke zu vermeiden sind, damit Policy-Steuerung nicht zur Quelle von „mysteriösen“ Drops oder Second Outages wird.

Was Traffic Engineering im ISP-Kontext ist

Traffic Engineering ist die systematische Steuerung von Verkehrsflüssen im Netz mit dem Ziel, definierte Betriebsziele zu erreichen. Im ISP-Betrieb sind diese Ziele häufig:

• Kapazitätsausnutzung: Links gleichmäßiger belasten, Hotspots vermeiden, N-1-Headroom sicherstellen.
• Kostenoptimierung: Transit entlasten, Peering stärker nutzen, teure Wege reduzieren.
• Performance: Latenz und Jitter stabilisieren, regionale Pfade verbessern.
• Resilienz: Failover-Verhalten planbar machen, Konvergenz-Impact reduzieren.
• Risikoreduktion: Routing-Leaks, asymmetrische Pfade und stateful Edge-Probleme vermeiden.

TE setzt dabei auf Routing-Protokolle und Policies. Für BGP-Grundlagen ist RFC 4271 zentral; für Multipath-Verhalten (relevant für ECMP und Lastverteilung) sind RFC 2991 und RFC 2992 hilfreiche Referenzen.

Die wichtigste Unterscheidung: Outbound TE vs. Inbound TE

Viele TE-Probleme entstehen, weil Outbound und Inbound verwechselt werden. Operativ gilt eine einfache Regel:

• Outbound Traffic Engineering: Sie steuern, welchen Ausgang (Exit) Ihr Netz für ausgehenden Traffic nutzt. Das ist relativ gut kontrollierbar.
• Inbound Traffic Engineering: Sie versuchen zu beeinflussen, wie das Internet Traffic zu Ihnen zurückschickt. Das ist grundsätzlich weniger deterministisch, weil andere ASNs entscheiden.

Ein robustes TE-Design arbeitet deshalb mit klaren Erwartungen: Outbound TE kann fein gesteuert werden, Inbound TE ist oft probabilistisch und muss mit Monitoring und Guardrails abgesichert werden.

Baustein: Datenbasis und Traffic-Klassifizierung

Bevor Sie Pfade per Policy steuern, müssen Sie wissen, welchen Traffic Sie überhaupt steuern wollen. Im ISP-Alltag hat sich eine grobe Segmentierung bewährt:

• Nach Ziel-AS oder Zielpräfix: besonders relevant bei Content- und Cloud-ASNs, die viel Volumen erzeugen.
• Nach Region/PoP: welche Access-Region erzeugt welchen Verkehr, und über welche Kanten verlässt er das Netz.
• Nach Serviceklasse: z. B. Latenz-sensitiv (Gaming/VoIP), Bulk (Backups), Business-Kunden.
• Nach Protokoll/Port (vorsichtig): nur wenn es betrieblich sinnvoll und sauber dokumentiert ist (PBR kann riskant sein).

Als Mindestanforderung sollten Sie TE-Entscheidungen mit Flow-Daten (z. B. NetFlow/IPFIX) und Link-/Queue-Telemetrie korrelieren, damit Sie nicht „blind“ umsteuern und dadurch unbemerkt Congestion verschieben.

Outbound TE: Die wichtigsten Hebel, die ISPs wirklich nutzen

Outbound TE ist in vielen Netzen der schnellste, sicherste Hebel, um Hotspots zu entlasten. Die gängigen Mechanismen greifen meist an der Stelle, wo Ihr Netz den „Best Path“ auswählt oder den Exit bestimmt.

Hebel 1: Local Preference (LocalPref) als primärer Outbound-Schalter

LocalPref ist in der Praxis der wichtigste Outbound-TE-Hebel, weil er innerhalb eines AS wirkt und sehr klar priorisiert: Höherer LocalPref gewinnt. Übliche Strategie: Sie definieren Policy-Klassen (z. B. „Peering bevorzugt“, „Transit normal“, „Transit teuer“) und setzen LocalPref entsprechend.

• Vorteil: sehr deterministisch innerhalb des eigenen AS.
• Risiko: falsche LocalPref-Änderungen können große Traffic-Shifts auslösen; Change-Validation ist Pflicht.
• Best Practice: LocalPref nicht „wild“ pro Prefix anpassen, sondern über kontrollierte Klassen und dokumentierte Ausnahmen.

Hebel 2: IGP-Kosten und Hot-Potato vs. Cold-Potato

Selbst wenn BGP mehrere gleichwertige Exits bietet, entscheidet oft das IGP, welcher Exit intern am „nächsten“ ist. Das führt zu Hot-Potato-Routing: Traffic verlässt das Netz am nächstgelegenen Exit, um das eigene Backbone zu entlasten. Cold-Potato macht das Gegenteil: Sie tragen den Traffic länger selbst, um ihn an einem strategisch günstigeren Exit abzugeben.

• Hot-Potato: spart Backbone-Kapazität, kann aber Inbound/Outbound-Asymmetrie verstärken.
• Cold-Potato: kann Latenz und Pfadstabilität verbessern, braucht aber Backbone-Headroom.
• Best Practice: Hot/Cold-Potato bewusst pro Region und pro Peer-Klasse entscheiden, nicht implizit entstehen lassen.

Hebel 3: ECMP für Outbound-Verteilung, aber mit Betriebsregeln

Wenn mehrere Exits gleichwertig sind, kann ECMP helfen, Last zu verteilen. Allerdings ist ECMP flow-basiert und führt typischerweise zu selektiven Effekten („nur einige Kunden betroffen“), wenn ein Pfad degradiert. Deshalb braucht ECMP gutes Monitoring (per Next Hop, per LAG-Member) und klare Headroom-Regeln.

Hebel 4: BGP Communities als TE-Schnittstelle

Communities sind das „Policy-API“ vieler Provider. Sie werden genutzt, um Exporte zu steuern (z. B. nur an bestimmte Peers announcen), um Prepends auszulösen oder um bestimmte Regionen zu beeinflussen. Der Vorteil: Communities sind skalierbar, wenn sie standardisiert sind. Der Nachteil: Missverständnisse erzeugen Leaks oder unerwartete Pfadwechsel.

• Best Practice: Community-Katalog mit eindeutiger Semantik und Ownership (wer darf was setzen).
• Best Practice: Monitoring auf advertised Prefix Counts und „unexpected spikes“, um Fehlsteuerung schnell zu sehen.
• Risiko: Community-Drift in Multi-Vendor-/Multi-Team-Umgebungen.

Inbound TE: Was wirklich funktioniert (und was oft überschätzt wird)

Inbound TE ist schwieriger, weil Sie externe Entscheidungen nur indirekt beeinflussen. Dennoch gibt es etablierte Mechanismen, die in der Praxis oft wirken – wenn man ihre Grenzen akzeptiert.

Hebel 1: AS-PATH Prepending

Durch AS-PATH Prepending machen Sie einen Pfad „länger“, sodass manche Netze ihn weniger bevorzugen. Das funktioniert jedoch nicht überall gleich, weil viele Netze LocalPref vor AS-PATH priorisieren oder eigene Policies haben.

• Vorteil: relativ einfach, weit verbreitet.
• Nachteil: unpräzise; kann zu unerwünschten globalen Shifts führen.
• Best Practice: Prepending eher grob und gezielt einsetzen (z. B. pro Region/Peer), nicht als Dauerlösung für jedes Problem.

Hebel 2: MED (wo es Sinn ergibt)

MED kann Inbound-Pfade beeinflussen, aber in der Praxis ist es stark von Peer-/Upstream-Policy abhängig. Viele Provider ignorieren MED oder nutzen es nur in bestimmten Beziehungen. Wenn Sie MED einsetzen, müssen Sie genau wissen, ob und wie der Gegenpart es bewertet.

Hebel 3: Selektive Announcements (Scope steuern)

Ein sehr wirkungsvoller Inbound-TE-Ansatz ist, nicht überall alles gleich zu announcen. Stattdessen announcen Sie bestimmte Prefixe nur an ausgewählte Peerings oder in ausgewählten Regionen. Das erfordert gutes Prefix-Management, saubere Filter und sehr gute Dokumentation.

• Vorteil: kann sehr präzise sein, wenn sauber umgesetzt.
• Risiko: falsches Scope-Handling kann Reachability reduzieren oder regionale Blackholes erzeugen.
• Best Practice: Change-Validation mit End-to-End-Probes aus mehreren Regionen vor „All Clear“.

Hebel 4: Anycast als Spezialfall von Inbound-TE

Anycast ist eine Form von „Routing-gesteuerter Inbound-Lastverteilung“. Viele ISPs nutzen Anycast für DNS, Security-Services oder bestimmte Edge-Funktionen. Anycast kann Inbound-TE stark vereinfachen, bringt aber eigene Failure Modes (Traffic Drift, Cold Cache, regionales Blackholing). Für Anycast-Betrieb ist RFC 4786 eine hilfreiche Referenz.

TE-Risiken: Warum Policy-Steuerung neue Probleme erzeugen kann

Traffic Engineering ist mächtig, aber jedes Eingreifen verändert die Netzrealität. Typische Risiken sind nicht theoretisch, sondern gehören zu den häufigsten Ursachen für „Second Outages“ nach Maintenance oder Routing-Fixes.

Risiko 1: Congestion wird nur verschoben

Wenn Sie einen überlasteten Link entlasten, kann der Traffic auf einen anderen Link wandern, der nicht genügend Headroom hat. Das ist besonders gefährlich, wenn Sie nur Durchschnittsauslastung betrachten und Mikrobursts ignorieren.

• Mitigation: Queue Drops und High-Resolution Telemetrie beobachten, nicht nur 5-Minuten-Averages.
• Mitigation: N-1-Headroom als Policy-Regel: TE darf keinen Link dauerhaft in eine „Failover-gefährliche“ Zone bringen.

Risiko 2: Asymmetrisches Routing und stateful Edge

TE kann Hin- und Rückwege auseinanderziehen. Für reine IP-Weiterleitung ist das oft ok, für Firewalls/CGNAT/LBs kann es Sessions brechen. Deshalb sollten TE-Änderungen an Edges immer prüfen, ob sie Symmetrie-Annahmen verletzen.

Risiko 3: ECMP-Rehashing und Mikrobursts

Wenn TE Änderungen ECMP-Gruppen verändern (Next-Hop rein/raus), werden Flows neu verteilt. Das kann kurzfristige Bursts erzeugen, die Drops verursachen, obwohl die Links „eigentlich“ genug Kapazität haben.

Risiko 4: Route Leaks durch falsch gesetzte Policies

Wenn TE über Communities oder Export-Policies gesteuert wird, kann ein Fehler schnell zu einem Route Leak werden. Rollenbasierte Modelle helfen, das Risiko zu senken; als Referenz ist RFC 9234 relevant. Ergänzend sind Routing-Security-Best-Practices aus dem MANRS-Programm hilfreich: MANRS.

Monitoring für Traffic Engineering: Welche Signale zwingend sind

TE ohne Monitoring ist wie Autofahren ohne Tacho. Sie brauchen Signale, die sowohl die Ursache (Routing-Entscheidung) als auch die Wirkung (Traffic, Latenz, Loss) zeigen.

Pflichtsignale

• Link- und Queue-Telemetrie: Utilization, Queue Drops, Discards, Errors, per LAG-Member.
• BGP-Pfadänderungen: Best Path Changes für wichtige Prefixe, LocalPref/AS-PATH/MED-Indizien.
• Prefix Counts: received/accepted/advertised, um Leaks und Policy-Fehler schnell zu sehen.
• Flow-Daten: Traffic nach Ziel-AS/Region, Top Talkers, um TE-Effekte zu quantifizieren.
• End-to-End-Probes: Latenz und Loss aus mehreren Regionen (nicht nur Core), um QoE zu belegen.

Traffic-Shift-Quote als einfache Wirkungsmessung (MathML)

$\mathrm{ShiftShare}=\frac{\mathrm{|Traffic}\_\mathrm{after}-\mathrm{Traffic}\_\mathrm{before|}}{\mathrm{Traffic}\_\mathrm{before}}$

Diese Kennzahl zeigt, wie groß der Eingriff war. Bei großen Shifts sollten Sie besonders wachsam sein (Queue Drops, Latenzspitzen, stateful Edge-Effekte).

Operatives Vorgehen: TE-Changes sicher durchführen

Traffic Engineering ist Change Management. Ein sicheres Vorgehen reduziert Risiko und beschleunigt Recovery, wenn etwas schiefgeht.

Pre-Check: Bevor Sie Policy ändern

• Ziel definieren: Was soll sich ändern? (z. B. Link X von 80% auf 60% entlasten)
• Scope definieren: Welche Prefixe/ASNs/Regionen sollen betroffen sein?
• Risiken prüfen: stateful Devices? MTU-Unterschiede? ECMP/LAG-Kanten?
• Baseline sichern: Auslastung, Queue Drops, Latenz/Loss, BGP-Path-Infos, Prefix Counts.
• Rollback definieren: exakte Gegenmaßnahme, die in Minuten umsetzbar ist.

Change: Schrittweise statt „Big Bang“

• Stufenweise Policy: erst kleine Depräferenzierung, Wirkung messen, dann weiter.
• Beobachtungsfenster: zwischen Stufen warten, bis Telemetrie stabil ist (Drops/Queues/Probes).
• Dual Stack getrennt: IPv4 und IPv6 separat betrachten; Pfade können unterschiedlich reagieren.

Post-Check: Bevor „All Clear“ gilt

• Wirkung erreicht: Zielmetriken (Utilization, Drops) im gewünschten Band.
• Keine neuen Hotspots: Alternativpfade nicht in Congestion, per-member ok.
• QoE ok: Latenz/Loss-Probes stabil, keine neuen Kundenbeschwerden in betroffenen Regionen.
• Routing-Hygiene ok: keine unerwarteten advertised Prefix Spikes, keine RPKI/Filter-Anomalien.

Praktische TE-Checkliste für ISPs

• Outbound TE zuerst: LocalPref-Klassen und IGP-Exit-Design klar, dokumentiert, konsistent.
• Inbound TE realistisch: Prepending/Scope-Announcements nur mit Monitoring und klaren Erwartungen.
• ECMP-Transparenz: per Next Hop/per LAG-Member Telemetrie, sonst bleiben Partial Failures unsichtbar.
• Headroom-Regel: TE darf keine N-1-Failover-Katastrophe bauen.
• Stateful Awareness: Änderungen am Edge auf Asymmetrie-Risiko prüfen (Firewall/CGNAT).
• Guardrails: Prefix Filtering, Max-Prefix, RPKI-Strategie, um Leaks/Hijacks nicht zu verstärken.
• Evidence Packs: jede TE-Änderung mit Baseline, Wirkung, Timeline und Rollback dokumentieren.

Outbound-Ressourcen

• RFC 4271 (BGP-4: Grundlagen für Policy-Steuerung)
• RFC 1997 (BGP Communities: Policy-Schnittstelle)
• RFC 2991 (Multipath Issues: Auswirkungen von ECMP auf Traffic)
• RFC 2992 (ECMP Algorithm Analysis)
• RFC 4786 (Anycast Services: Inbound-Verteilung und Betriebsrisiken)
• RFC 9234 (BGP Roles: Rollenmodell als Guardrail gegen Leaks)
• MANRS (Best Practices für Routing-Sicherheit und Operations)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.