IS-IS Route Leaking - Übersicht
Inhalt
Einführung
Das Dokument bietet eine Übersicht über das Auslaufen von IS-IS-Routen (Intermediate System-to-Intermediate System).
Voraussetzungen
Anforderungen
Für dieses Dokument bestehen keine speziellen Anforderungen.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Was ist Route Leaking?
Das IS-IS Routing-Protokoll ermöglicht eine zweistufige Hierarchie von Routing-Informationen. Es können mehrere Layer-1-Bereiche durch einen zusammenhängenden Layer-2-Backbone verbunden sein. Ein Router kann der Stufe 1, der Stufe 2 oder beiden angehören. Die Link-State-Datenbank der Stufe 1 enthält nur Informationen zu diesem Bereich. Die Link-State-Datenbank der Stufe 2 enthält Informationen zu dieser Ebene sowie zu jedem Bereich der Stufe 1. Ein L1/L2-Router enthält sowohl Datenbanken der Stufe 1 als auch der Stufe 2. Er gibt Informationen über den L1-Bereich an, zu dem er gehört. Jeder L1-Bereich ist im Wesentlichen ein Stub-Bereich. Pakete, die für eine Adresse außerhalb des L1-Bereichs bestimmt sind, werden an den nächstgelegenen L1/L2-Router weitergeleitet und an den Zielbereich weitergeleitet. Das Routing zum nächsten L1/L2-Router kann zu einem suboptimalen Routing führen, wenn der kürzeste Pfad zum Ziel über einen anderen L1/L2-Router verläuft. Route Leaking hilft, suboptimales Routing zu reduzieren, indem ein Mechanismus zum Auslaufen oder Neuverteilen von L2-Informationen in L1-Bereiche bereitgestellt wird. Durch detailliertere Informationen zu Interarea-Routen kann ein L1-Router eine bessere Wahl treffen, welcher L1/L2-Router das Paket weiterleitet.
Route Leaking ist in RFC 2966 
für die Verwendung mit den Typen 128 und 130 mit schmalen Metriken Typ, Länge und Wert definiert. IS-IS-Erweiterungen für Traffic Engineering definieren Route Leaking für den weiten metrischen TLV-Typ 135. Beide Entwürfe definieren ein Up/Down-Bit, um anzugeben, ob die in der TLV definierte Route durchgelaufen ist oder nicht. Wenn das Auf/Ab-Bit auf 0 festgelegt ist, wurde die Route innerhalb dieses L1-Bereichs generiert. Wenn das Up/Down-Bit nicht festgelegt ist (es ist 0), wurde die Route in den Bereich von L2 neu verteilt. Das Up/Down-Bit wird verwendet, um Routing-Informationen und Weiterleitungsschleifen zu verhindern. Ein L1/L2-Router kündigt keine L1-Routen, für die das Up/Down-Bit festgelegt ist, in L2 an.
Wie kann ich Route Leaking verwenden?
In der Regel leitet ein L1-Router Pakete, die für eine Adresse außerhalb des lokalen Bereichs bestimmt sind, an den nächstgelegenen L1/L2-Router weiter, was zu suboptimalen Routing-Entscheidungen führen kann. Im folgenden Netzwerkdiagramm leitet Router C den gesamten für Bereich 2 und 3 bestimmten Datenverkehr über die Router X und Y weiter. Wenn wir davon ausgehen, dass alle Verbindungen einen Preis haben, d. h. alle Verbindungen sind kostenpflichtig, d. h. 2 für die Verbindung zu Router X und 5 für die Verbindung zu Router Y. Ebenso leitet Router D den Datenverkehr für die Router X und Y über Router B weiter.
Wenn Sie Route Leaking verwenden, können Informationen zu Area 2 und 3 von den Routern A und B in Bereich 1 neu verteilt werden. So können Router C und Router D optimale Pfade für die Anbindung an Bereich 2 und 3 auswählen. Router C sendet jetzt Datenverkehr über Router A an Bereich 3. Dadurch werden die Kosten auf 3 reduziert, während die Weiterleitung nach Bereich 2 über Router A erfolgt. Ebenso leitet Router D an Bereich 2 über Router C weiter, während er dennoch über Router B zu Bereich 3 weitergeleitet wird.
Durch die Aktivierung der Route Leaking auf Router A und Router B konnten die Router C und D ihre tatsächlichen Kosten für die Erreichbarkeit von Area 2 und Area 3 ermitteln. Das Route Leaking ermöglichte IS-IS das "Shortest Path Exiting" für Pakete, die in andere Bereiche geleitet werden.
In einer MPLS-VPN-Umgebung sind für jede Loopback-Adresse des Provider Edge (PE)-Routers Erreichbarkeitsinformationen erforderlich. Durch das Verlassen von Routen für die PE-Loopbacks kann in dieser Art der Implementierung eine Hierarchie mit mehreren Bereichen verwendet werden.
Route Leaking kann auch verwendet werden, um eine grobe Form der Traffic Engineering. Wenn Routen für einzelne Maschinen oder Services von bestimmten L1/L2-Routern ausgehen, können Sie den Ausgangspunkt aus dem L1-Bereich steuern, über den diese Adressen erreicht werden.
Wie konfiguriere ich Route Leaking?
Route Leaking ist in den Cisco IOS® Software-Versionen 12.0S, 12.0T und 12.1 implementiert und unterstützt. Die Versionen 12.0T und 12.1 verwenden denselben Konfigurationsbefehl. Die Befehlssyntax unterscheidet sich für die Version 12.0S, jedoch werden beide Befehle in der IS-IS-Konfiguration des Routers eingegeben. Sie müssen eine erweiterte IP-Zugriffsliste erstellen, um festzulegen, welche Routen von Stufe 2 in Stufe 1 durchlaufen werden. IOS 12.0S unterstützt nur Route Leaking unter Verwendung von Typ-135-TLVs. Wenn Route Leaking konfiguriert wird, ohne umfassende Stilmetriken zu konfigurieren, wird kein Route Leaking durchgeführt. IOS 12.0T und 12.1 unterstützen Route Leaking mithilfe von engen oder breiten Stilmetriken. Wir empfehlen jedoch die Verwendung von Metriken mit großem Stil.
Die Konfigurationsbefehle für jede IOS-Version sind in der folgenden Tabelle aufgeführt:
| IOS-Softwareversion | Befehl |
|---|---|
| 12,0 S | kündigen Sie ip l2-into-l1 <100-199> Breite im metrischen Stil an. Hinweis: Die zweite Anweisung ist erforderlich. |
| 12.0T und 12.1 | Neuverteilung von isis ip level-2 in distribute-list der Stufe 1 <100-199> metrisch-style wide Hinweis: Die zweite Anweisung ist optional, jedoch empfehlenswert. |
Ausgefallene Routen werden in der Routing-Tabelle als Interarea-Routen und in der IS-IS-Datenbank bezeichnet. Beim Anzeigen der Routing-Tabelle werden durchgelechtete Routen mit einer ia-Kennzeichnung gekennzeichnet.
RtrB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 55.55.55.1 to network 0.0.0.0
i ia 1.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0
i ia 2.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0
i ia 3.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0
i ia 4.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0
55.0.0.0/24 is subnetted, 1 subnets
C 55.55.55.0 is directly connected, Serial1/0
i ia 5.0.0.0/8 [115/30] via 55.55.55.1, Serial1/0
7.0.0.0/24 is subnetted, 1 subnets
C 7.7.7.0 is directly connected, FastEthernet0/0
44.0.0.0/24 is subnetted, 1 subnets
i L1 44.44.44.0 [115/20] via 55.55.55.1, Serial1/0
i*L1 0.0.0.0/0 [115/10] via 55.55.55.1, Serial1/0
In der IS-IS-Datenbank sind durchgelechene Routen mit einer IP-Interarea-Kennzeichnung gekennzeichnet.
RtrB# show isis database detail IS-IS Level-1 Link State Database: LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL rpd-7206g.00-00 0x00000008 0x0855 898 1/0/0 Area Address: 49.0002 NLPID: 0xCC Hostname: rpd-7206g IP Address: 44.44.44.2 Metric: 10 IP 55.55.55.0/24 Metric: 10 IP 44.44.44.0/24 Metric: 10 IS-Extended rpd-7206a.00 Metric: 20 IP-Interarea 1.0.0.0/8 Metric: 20 IP-Interarea 2.0.0.0/8 Metric: 20 IP-Interarea 3.0.0.0/8 Metric: 20 IP-Interarea 4.0.0.0/8 Metric: 20 IP-Interarea 5.0.0.0/8
Vor der Einführung des Route Leaking the up/down Bit for type 128 and 130 TLVs war Bit acht der Standardmetrik für die folgenden Verwendungszwecke reserviert: sie sollte bei der Übermittlung auf Null gesetzt und bei Eingang ignoriert werden. Bit 7, das E/A-Bit, wurde verwendet, um zwischen internen und externen metrischen Typen für neu verteilte Routen in TLV 130 zu unterscheiden. In der IOS-Version 12.0S und früher wurde Bit acht anstelle von Bit 7 als E/A-Bit verwendet. Dies führt zu mehreren Interoperabilitätsdiskrepanzen zwischen den Versionen 12.0S und 12.0T/12.1, wenn enge Metriken verwendet werden.
Ein Router mit IOS 12.0T oder 12.1 erkennt das Auf/Ab-Bit und behandelt die Route entsprechend, unabhängig davon, ob das Route Leaking auf diesem Router konfiguriert ist. Wenn ein L1- oder L1/L2-Router ohne IOS 12.0T- oder 12.1-Code Routen mithilfe von externem Metriktyp umverteilt, legt er Bit acht der Standardmetrik auf 1 fest. Ein L1/L2-Router mit 12.0T oder 12.12.1 erkennt Bit acht (das Up/Down-Bit) und interpretiert es als Route, die durchgesickert wurde. Daher wird die Route im L2 LSP dieses Routers nicht erneut angekündigt. Dies kann dazu führen, dass Routing-Informationen nicht im gesamten Netzwerk verbreitet werden.
Wenn eine Route hingegen von einem Router mit IOS 12.0T oder 12.1 in L1 durchgesickert wurde, setzt sie Bit acht auf 1. Router in der L1-Area mit IOS Release 12.0S oder früher erkennen, dass Bit acht eingerichtet ist, und behandeln die Route als extern metrisch. Ein L1/L2-Router mit IOS Release 12.0S oder früher kündigt die Route in seinem L2 LSP erneut an, da Bit acht nicht als das Up/Down-Bit erkannt wird. Dies kann zur Bildung von Routing-Schleifen führen.
Diese Unregelmäßigkeiten werden im folgenden Beispiel veranschaulicht. RtrA führt IOS Version 12.1 aus und hinterlässt mehrere Routen mithilfe von engen Metriken. RtrB führt IOS 12.0S aus und verteilt mehrere Routen mit einem metrischen externen Typ neu.
Auf RtrA werden die neu verteilten Routen von RtrB fälschlicherweise als Interzonenrouten angesehen:
RtrA# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
i L2 1.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0
i L2 2.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0
i L2 3.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0
i L2 4.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0
55.0.0.0/24 is subnetted, 1 subnets
C 55.55.55.0 is directly connected, Serial1/0
i L2 5.0.0.0/8 [115/20] via 44.44.44.1, ATM3/0
7.0.0.0/24 is subnetted, 1 subnets
C 7.7.7.0 is directly connected, FastEthernet0/0
i ia 110.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0
44.0.0.0/24 is subnetted, 1 subnets
C 44.44.44.0 is directly connected, ATM3/0
i ia 120.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0
i ia 140.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0
i ia 130.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0
i ia 150.0.0.0/8 [115/138] via 55.55.55.2, Serial1/0
Auf RtrB werden die von RtrA durchgesickerten Routen fälschlicherweise als extern angesehen:
RtrB# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter
area
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is 55.55.55.1 to network 0.0.0.0
i L1 1.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0
i L1 2.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0
i L1 3.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0
i L1 4.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0
55.0.0.0/24 is subnetted, 1 subnets
C 55.55.55.0 is directly connected, Serial1/0
i L1 5.0.0.0/8 [115/158] via 55.55.55.1, Serial1/0
7.0.0.0/24 is subnetted, 1 subnets
C 7.7.7.0 is directly connected, FastEthernet0/0
S 110.0.0.0/8 is directly connected, Null0
44.0.0.0/24 is subnetted, 1 subnets
i L1 44.44.44.0 [115/20] via 55.55.55.1, Serial1/0
S 120.0.0.0/8 is directly connected, Null0
i*L1 0.0.0.0/0 [115/10] via 55.55.55.1, Serial1/0
S 140.0.0.0/8 is directly connected, Null0
S 130.0.0.0/8 is directly connected, Null0
S 150.0.0.0/8 is directly connected, Null0
Wenn Sie die Neuverteilung nicht mit einem externen Metriktyp verwenden, ist Bit acht nicht festgelegt. Diese Problemumgehung verhindert, dass ein L1/L2-Router mit IOS 12.1 die neu verteilten Routen in seinem L2 LSP nicht erneut meldet. Wenn Sie Weitformat-Kennzahlen verwenden, können Router mit IOS 12.0S das Up/Down-Bit erkennen. Diese Problemumgehung verhindert die Einführung von Routing-Schleifen von 12.0S-Routern, die das Auf-/Abwärtstrend-Bit in Typ 128 und 130 TLVs nicht erkennen.
Darüber hinaus liegen die Metriken für den schmalen Stil nur bei 6 Bits, verglichen mit den 32 Bits, die bei Metriken für den breiten Stil verwendet werden. Bei Verwendung von Metriken mit schmaler Bauweise können viele Interzonenrouten mit der maximalen internen Metrik von 63 durchlaufen werden, unabhängig von der eigentlichen Metrik. Aus diesen Gründen empfehlen wir, eine Neuverteilung mit metrischen externen Metriken und stattdessen mit breit angelegten Metriken zu vermeiden.
Feedback