Site icon bintorosoft.com

MED richtig nutzen: Grenzen, Fallstricke und Provider-Realität

Red Snapper

internet concept

MED (Multi-Exit Discriminator) ist eines der am meisten missverstandenen BGP-Attribute. In der Theorie ist MED ein eleganter Hinweis an den Nachbar-AS: „Wenn du mehrere Übergänge zu mir hast, nimm bitte diesen hier bevorzugt.“ In der Praxis scheitert MED oft an drei Realitäten: Es wirkt nur in sehr bestimmten Topologien (meist gleicher Nachbar-AS), es kann durch Provider-Policy ignoriert oder überschrieben werden, und es erzeugt schnell unerwartete Pfade, wenn du es als „Inbound-Traffic-Steuerung für das ganze Internet“ missbrauchst. Dieses Tutorial zeigt, wann MED wirklich hilft, welche Grenzen du akzeptieren musst und wie du typische Fallstricke auf Cisco vermeidest.

Was MED ist (und was nicht)

MED ist ein „Hint“ an den Nachbarn, welchen Eingang er wählen soll, wenn er mehrere Möglichkeiten hat, dein AS zu erreichen. MED ist nicht dein primärer Hebel für globales Inbound-Traffic-Engineering. Dafür sind Provider-Communities und AS-Path Prepending meist relevanter.

Merker

Low MED  →  bevorzugter Eingang   (beim Nachbarn)

Die wichtigste Grenze: MED wird meist nur innerhalb eines Nachbar-AS verglichen

Viele Router (und viele Provider-Policies) vergleichen MED standardmäßig nur zwischen Routen, die aus demselben Nachbar-AS gelernt wurden. Das bedeutet: MED ist typischerweise nur dann sinnvoll, wenn du mehrere Links zum gleichen Provider-AS hast (z. B. zwei Übergänge zum ISP A).

Provider-Realität: Warum dein MED oft ignoriert wird

Provider nutzen MED häufig nur in bestimmten Produkten (z. B. Dual-Homing im selben AS) oder überschreiben es durch interne Policies (LocalPref, Traffic Engineering, Hot-Potato). Selbst wenn MED akzeptiert wird, kann er durch weitere Kriterien im Best-Path-Prozess „überstimmt“ werden.

Wann MED in Enterprise-Edges wirklich sinnvoll ist

MED lohnt sich, wenn du mit einem Provider zwei Übergänge hast und du den Inbound-Pfad innerhalb dieses Providers steuern willst – z. B. damit Traffic aus Norddeutschland in Hamburg reinkommt und nicht in München, oder um Last zwischen zwei PoPs zu verteilen.

MED-Design: Wertebereiche und ein klares „Intent“-Modell

Wie bei LocalPref gilt: ohne Governance wird MED Chaos. Definiere daher einen kleinen Wertebereich und eine klare Bedeutung. MED ist „low wins“, also ist eine kleine Skala oft ausreichend.

MED setzen auf Cisco: Route-Map am Outbound

MED wird typischerweise outbound gesetzt, weil du dem Nachbarn damit einen Hinweis gibst. Du setzt MED per Route-Map auf die Prefixes, die du über diesen Link announcen möchtest.

Prefix-List + MED per Route-Map

ip prefix-list PL_APP_CRIT seq 10 permit 203.0.113.0/24
ip prefix-list PL_APP_BULK seq 10 permit 198.51.100.0/24

route-map RM_OUT_ISP_A permit 10

match ip address prefix-list PL_APP_CRIT

set metric 50


route-map RM_OUT_ISP_A permit 20

match ip address prefix-list PL_APP_BULK

set metric 200

Am Neighbor anwenden

router bgp 65000
 neighbor 192.0.2.1 remote-as 64500
 neighbor 192.0.2.1 route-map RM_OUT_ISP_A out

Fallstrick 1: MED wirkt nicht zwischen unterschiedlichen Providern

Wenn du zwei verschiedene Provider hast, ist MED als Inbound-TE meist wirkungslos. Selbst wenn beide Provider MED akzeptieren, vergleichen sie MED nicht gegeneinander, weil sie aus verschiedenen Neighbor-AS kommen. Für Multi-Provider nutzt du LocalPref (Outbound) und Communities/Prepending (Inbound).

Fallstrick 2: MED wird „überschrieben“ oder normalisiert

Viele Provider setzen eigene MEDs, um interne Traffic-Engineering-Modelle durchzusetzen. Dann siehst du zwar lokal deine MED-Werte, aber sie haben beim Provider keinen Effekt. Du erkennst das nur durch Messung von extern (Looking Glass/Traceroutes).

Fallstrick 3: MED + Hot-Potato: Erwartung vs. Realität

Hot-Potato bedeutet: Provider liefert Traffic zum nächstgelegenen Exit zu dir. Das kann MED-Effekte überlagern, besonders wenn der Provider sein IGP/TE so gebaut hat, dass bestimmte PoPs immer „näher“ sind. MED ist dann nur eine weiche Feinsteuerung.

Fallstrick 4: Inkonsequente MED-Policy erzeugt Instabilität

Wenn du MED pro Prefix ständig änderst oder unterschiedliche Teams unterschiedliche Werte setzen, entsteht Route-Churn. Das kann sich wie „BGP flapt“ anfühlen, obwohl nur Attributwerte wechseln. Governance und Change-Disziplin sind daher Pflicht.

Verifikation: Wirkt MED wirklich?

Du musst drei Dinge prüfen: (1) MED wird outbound gesendet, (2) der Provider akzeptiert es, (3) der Traffic folgt dem erwarteten Eingang. Punkt (3) erfordert externe Sicht.

Outbound MED auf dem Router prüfen

show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp 203.0.113.0/24

Externe Validierung (Praxis)

Best Practices: MED als „Feinwerkzeug“ einsetzen

MED ist kein Ersatz für sauberes Multi-Homing-Design. Nutze MED als Feinsteuerung innerhalb eines Providers, und setze für grobes Inbound-TE eher Communities/Prepending ein. Damit bleibt dein Design robust.

Quick-Runbook: MED Troubleshooting in 5 Minuten

Diese Kommandos zeigen dir, ob du MED korrekt sendest und ob lokale Policies es überschreiben. Für die Provider-Wirkung brauchst du externe Messung.

show ip bgp summary
show ip bgp 203.0.113.0/24
show ip bgp neighbors 192.0.2.1 advertised-routes
show route-map RM_OUT_ISP_A
show ip prefix-list PL_APP_CRIT

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

Sie erhalten

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.

Exit mobile version