Konfigurieren von PCE-basiertem (nicht Path Computation Element) Inter-Area Segment Routing Traffic Engineering (SR-TE)
Inhalt
Einführung
In diesem Dokument werden die Aspekte des Verständnisses, der Konfiguration und der Überprüfung des SR-TE (Inter-Area) ohne Path Computation Element Controller beschrieben.
Unterstützt von Elvin Arias, Cisco TAC Engineer.
Voraussetzungen
Für dieses Dokument bestehen keine Voraussetzungen.
Anforderungen
Für dieses Dokument bestehen keine speziellen Anforderungen.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf Cisco IOS-XR® und IOS-XE®.
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Einführung in mehrere Domänen: SR-TE
Das Segment Routing Traffic Engineering (SR-TE) bietet Funktionen zur Steuerung des Datenverkehrs durch den Core, ohne dass im Core Staatssitzungen stattfinden müssen. Eine SR-TE-Richtlinie wird als Liste von Segmenten ausgedrückt, die einen Pfad angibt, der als Segment-ID (SID)-Liste bezeichnet wird. Es ist keine Signalisierung erforderlich, da der Status in der Paketliste vorhanden ist und die SID-Liste von den SR-fähigen Transit-Routern als eine Reihe von Anweisungen verarbeitet wird.
Mehrdomänenumgebung wird traditionell mit Resource Reservation Protocol Traffic Engineering (RSVP-TE) über die Verwendung einer losen Next-Hop-Erweiterung in einer expliziten Pfadoption implementiert. Bei Berechnungen würde ein Administrator einen Pfad erstellen, in dem IP-Adressen (Inter-Area Internet Protocol) lose definiert sind, um eine End-to-End-Berechnung über CSPF (Constrained Shortest Path First) zu ermöglichen.
SR-TE hat nicht das Konzept von Loose Next-Hops, also und bei Multi-Domain-Berechnungen ist die Frage, wie dies durchgeführt werden kann. Es sind Berechnungen möglich, und das faktische Design besteht darin, einen zentralen Controller (XTC, WAE, NOS) aufzustellen, um die entsprechenden Berechnungen für mehrere Domänen durchzuführen. Durch die Auslagerung der Berechnungen vom Head-End zum End können Geräte Pfade berechnen, ohne dass Transparenz in der gesamten Topologie vorhanden ist. Für dieses Path Computation Element (PCE) wird die Entität verwendet, die die gesamte Transparenz der Domäne besitzt, Berechnungen durchführt und die berechneten LSP verfolgt.
Wenn ein Controller vorübergehend nicht verfügbar ist und im Segment-Routing-Core Multi-Domain-Berechnungen erforderlich sind, können verschiedene Konfigurationen durchgeführt werden, um Tunneln die Einrichtung in interbereichsübergreifenden Szenarien zu ermöglichen.
Pfadtypen
Mit SR-TE können mehrere Pfadtypen definiert werden, die allgemein als Explicit Pfade und dynamische Pfade bezeichnet werden. Für dynamische und explizite Pfade ist dies einfach. Der SR-TE-Algorithmus kann den Pfad anhand dynamischer Kriterien berechnen, häufig anhand der TE- oder IGP-Metrik zu einem Tail-End. Für explizite Pfade können mehrere Typen definiert werden, von denen viele:
- SID nur als Label (nur MPLS)
- SID nur als IPv6-Adresse (nur SRv6)
- IPv4-Knotenadresse mit optionaler SID
- IPv6-Node-Adresse mit optionaler SID
- IPv4-Adresse + Schnittstellenindex mit optionaler SID
- IPv4-lokale und Remote-Adressen mit optionaler SID
- IPv6 + Schnittstellenindex mit optionaler SID
- IPv6-lokale und Remote-Adressen mit optionaler SID
Bei der Definition von SR-TE-Richtlinien für die Kommunikation zwischen verschiedenen Bereichen müssen explizite Pfade zum Tail-End definiert werden, da wir nicht die gesamte Transparenz der Topologie haben. Für bereichsübergreifende SR-TE müssen die Richtlinien wie folgt konfiguriert werden:
- Explicit-Path mit Tail-End-SID-Label
- Expliziter Pfad mit Transit + SID-Label
- Expliziter Pfad mit lokalen IPv4-Adressen + SID-Label
Hinweis: Wenn dynamische Optionen für den Inter-Area-Pfad erforderlich sind, Die Pfadberechnung muss an eine PCE-Einheit delegiert werden.
Topologiediagramm
In den nächsten Fällen wird diese OSPF-Interbereichs-Topologie verwendet. Beispiele basieren auf der Berechnung von SR-TE-Tunneln von XR1 bis XR5, die die Bereichsgrenzen überschreiten.
Hinweis: Beispiele für SR-TE basieren auf OSPF, gelten aber auch für IS-IS.
Erstkonfiguration
XR1 hostname XR1 icmp ipv4 rate-limit unreachable disable interface Loopback0 ipv4 address 1.1.1.1 255.255.255.255 ! interface Loopback1 ipv4 address 1.1.1.11 255.255.255.255 ! interface GigabitEthernet0/0/0/0.12 ipv4 address 12.0.0.1 255.255.255.0 encapsulation dot1q 12 ! router ospf 1 router-id 1.1.1.1 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 12 mpls traffic-eng interface Loopback0 prefix-sid index 1 ! interface Loopback1 prefix-sid index 11 ! interface GigabitEthernet0/0/0/0.12 cost 100 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls traffic-eng interface GigabitEthernet0/0/0/0.12 admin-weight 100 ! ! end
XR2 hostname XR2 logging console debugging explicit-path identifier 4 index 10 next-label 16004 ! interface Loopback0 ipv4 address 2.2.2.2 255.255.255.255 ! interface GigabitEthernet0/0/0/0.12 ipv4 address 12.0.0.2 255.255.255.0 encapsulation dot1q 12 ! interface GigabitEthernet0/0/0/0.23 ipv4 address 23.0.0.2 255.255.255.0 encapsulation dot1q 23 ! interface GigabitEthernet0/0/0/0.26 ipv4 address 26.0.0.2 255.255.255.0 encapsulation dot1q 26 ! router ospf 1 router-id 2.2.2.2 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 2 ! interface GigabitEthernet0/0/0/0.23 cost 100 network point-to-point ! ! area 12 mpls traffic-eng interface GigabitEthernet0/0/0/0.12 cost 100 network point-to-point ! ! area 246 mpls traffic-eng interface GigabitEthernet0/0/0/0.26 cost 200 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.12 admin-weight 100 ! interface GigabitEthernet0/0/0/0.23 admin-weight 100 ! interface GigabitEthernet0/0/0/0.26 admin-weight 1 ! ! end
XR3 hostname XRv3 interface Loopback0 ipv4 address 3.3.3.3 255.255.255.255 ! interface MgmtEth0/0/CPU0/0 shutdown ! interface GigabitEthernet0/0/0/0.23 ipv4 address 23.0.0.3 255.255.255.0 encapsulation dot1q 23 ! interface GigabitEthernet0/0/0/0.34 ipv4 address 34.0.0.3 255.255.255.0 encapsulation dot1q 34 ! router ospf 1 router-id 3.3.3.3 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 3 ! interface GigabitEthernet0/0/0/0.23 cost 100 network point-to-point ! interface GigabitEthernet0/0/0/0.34 cost 100 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.23 admin-weight 100 ! interface GigabitEthernet0/0/0/0.34 admin-weight 100 ! ! end
XR4 hostname XR4 interface Loopback0 ipv4 address 4.4.4.4 255.255.255.255 ! interface GigabitEthernet0/0/0/0.34 ipv4 address 34.0.0.4 255.255.255.0 encapsulation dot1q 34 ! interface GigabitEthernet0/0/0/0.45 ipv4 address 45.0.0.4 255.255.255.0 encapsulation dot1q 45 ! interface GigabitEthernet0/0/0/0.46 ipv4 address 46.0.0.4 255.255.255.0 encapsulation dot1q 46 ! router ospf 1 distribute bgp-ls router-id 4.4.4.4 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 4 ! interface GigabitEthernet0/0/0/0.34 cost 100 network point-to-point ! ! area 45 mpls traffic-eng interface GigabitEthernet0/0/0/0.45 cost 100 network point-to-point ! ! area 246 mpls traffic-eng interface GigabitEthernet0/0/0/0.46 cost 200 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.34 admin-weight 100 ! interface GigabitEthernet0/0/0/0.45 admin-weight 100 ! interface GigabitEthernet0/0/0/0.46 admin-weight 1 ! ! end
XR5 hostname XRv5 interface Loopback0 ipv4 address 5.5.5.5 255.255.255.255 ! interface Loopback1 ipv4 address 5.5.5.55 255.255.255.255 ! interface GigabitEthernet0/0/0/0.45 ipv4 address 45.0.0.5 255.255.255.0 encapsulation dot1q 45 ! router ospf 1 router-id 5.5.5.5 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 45 mpls traffic-eng interface Loopback0 prefix-sid index 5 ! interface Loopback1 prefix-sid index 55 ! interface GigabitEthernet0/0/0/0.45 cost 100 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.45 admin-weight 100 ! ! end
XR6 hostname XR6 icmp ipv4 rate-limit unreachable disable interface Loopback0 ipv4 address 6.6.6.6 255.255.255.255 ! interface GigabitEthernet0/0/0/0.26 ipv4 address 26.0.0.6 255.255.255.0 encapsulation dot1q 26 ! interface GigabitEthernet0/0/0/0.46 ipv4 address 46.0.0.6 255.255.255.0 encapsulation dot1q 46 ! router ospf 1 router-id 6.6.6.6 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 246 mpls traffic-eng interface Loopback0 prefix-sid index 6 ! interface GigabitEthernet0/0/0/0.26 cost 200 network point-to-point ! interface GigabitEthernet0/0/0/0.46 cost 200 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.26 admin-weight 1 ! interface GigabitEthernet0/0/0/0.46 admin-weight 1 ! ! end
Geräte in der OSPF-Domäne haben LSPs zwischen ihnen erstellt. Dies können wir überprüfen, indem wir den LSP zwischen XR1 und XR5 prüfen.
RP/0/0/CPU0:XR1#ping mpls ipv4 5.5.5.5/32 fec-type generic verbose
Sending 5, 100-byte MPLS Echos to 5.5.5.5/32, timeout is 2 seconds, send interval is 0 msec: Codes: '!' - success, 'Q' - request not sent, '.' - timeout, 'L' - labeled output interface, 'B' - unlabeled output interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label, 'P' - no rx intf label prot, 'p' - premature termination of LSP, 'R' - transit router, 'I' - unknown upstream index, 'X' - unknown return code, 'x' - return code 0 Type escape sequence to abort. ! size 100, reply addr 45.0.0.5, return code 3 ! size 100, reply addr 45.0.0.5, return code 3 ! size 100, reply addr 45.0.0.5, return code 3 ! size 100, reply addr 45.0.0.5, return code 3 ! size 100, reply addr 45.0.0.5, return code 3 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/10 ms
SR-TE-Richtlinienkonfigurationen
Fall 1: SR-TE-Tunnel für den Interbereich mit explizitem Pfad und Präfix-SID des Tail-End
Wir erstellen eine SR-TE-Richtlinie von XR1, um einen Pfad zur XR5-Präfix-SID zu berechnen, der 5.5.5.5/32 entspricht. Das Präfix 5.5.5.5/32 wurde mit einem Index von 5 konfiguriert. Dies ist das einzige Label, das wir PCALC zur Berechnung des Pfads zur Verfügung stellen.
Hinweis: Alle Router in der Topologie verfügen über denselben SRGB-Block.
explicit-path name CASE1 index 10 next-label 16005 ! interface tunnel-te15 ipv4 unnumbered Loopback0 autoroute destination 5.5.5.5 destination 5.5.5.5 path-selection metric te segment-routing adjacency unprotected ! path-option 1 explicit name CASE1 segment-routing !
Hinweis: Die Ankündigung der Autoroute funktioniert nicht in interbereichsübergreifenden Fällen.
Überprüfungen
Wenn wir eine SID-Liste als Eingabe für die Berechnung bereitstellen, wird nur die erste Bezeichnung überprüft, und wenn diese Bedingung erfüllt ist, ist der Tunnel aktiv. Wenn wir den Tunnel überprüfen, sehen wir, dass er betriebsbereit ist und das Routing durchgeführt wird.
RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels segment-routing p2p 15
Name: tunnel-te15 Destination: 5.5.5.5 Ifhandle:0x130
Signalled-Name: XR1_t15
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, (Segment-Routing) type explicit CASE1 (Basis for Setup)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Mon Nov 26 02:14:33 2018 (00:14:34 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (interface)
Path Selection:
Tiebreaker: Min-fill (default)
Protection: Unprotected Adjacency
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: disabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Autoroute Destinations: 1
Loadshare: 0 equal loadshares
Auto-bw: disabled
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
History:
Tunnel has been up for: 00:04:43 (since Mon Nov 26 02:24:24 UTC 2018)
Current LSP:
Uptime: 00:04:43 (since Mon Nov 26 02:24:24 UTC 2018)
Prior LSP:
ID: 5 Path Option: 1
Removal Trigger: tunnel shutdown
Segment-Routing Path Info (OSPF 1 area 12)
Segment0[Node]: 5.5.5.5, Label: 16005
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Hinweis: PCALC-Ereignisse können mit dem Befehl debug mpls traffic-eng path lookup überprüft werden.
Wenn wir die globale RIB prüfen, sehen wir, dass das Routing zu 5.5.5.5/32 über die Tunnelschnittstelle 15 eingerichtet wird.
RP/0/0/CPU0:XR1#show route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "te-client", distance 2, metric 401 (connected)
Installed Nov 26 02:24:24.336 for 00:07:03
Routing Descriptor Blocks
directly connected, via tunnel-te15
Route metric is 401
No advertising protos.
Wenn wir das LFIB prüfen, sehen wir, dass tunnel-te15 installiert wurde und weitergeleitet werden kann.
RP/0/0/CPU0:XR1#ping 5.5.5.5 source 1.1.1.1 repeat 100 size 1500 Type escape sequence to abort. Sending 100, 1500-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 9/12/19 ms
RP/0/0/CPU0:XR1#show mpls forwarding tunnels detail
Tunnel Outgoing Outgoing Next Hop Bytes
Name Label Interface Switched
------------- ----------- ------------ --------------- ------------
tt15 (SR) 16005 Gi0/0/0/0.12 12.0.0.2 150400
Updated: Nov 26 02:24:24.357
Version: 200, Priority: 2
Label Stack (Top -> Bottom): { 16005 }
NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
MAC/Encaps: 18/22, MTU: 1500
Packets Switched: 100
Interface Name: tunnel-te15, Interface Handle: 0x00000130, Local Label: 24003
Forwarding Class: 0, Weight: 0
Packets/Bytes Switched: 100/150000
Fall 2: SR-TE-Tunnel zwischen verschiedenen Bereichen mit explizitem Pfad mit lokal installierten IPv4-Adressen + Präfix-SIDs
Bei der Definition von SR-TE-Richtlinien für den Inter-Area-Bereich können Labels und IPv4-Adressen kombiniert werden. Damit der PCALC erfolgreich einen Pfad zum Tail-End berechnen kann, müssen die für die Berechnung bereitgestellten IPv4-Adressen lokal im Bereich sein. Bei Elementen, die sich außerhalb des Bereichs befinden, müssen beide Präfix-Adjacency-SIDs bereitgestellt werden.
explicit-path name CASE2 index 10 next-address strict ipv4 unicast 12.0.0.2 index 20 next-label 16006 index 50 next-label 16005 ! interface tunnel-te15 ipv4 unnumbered Loopback0 autoroute destination 5.5.5.5 destination 5.5.5.5 path-selection metric te segment-routing adjacency unprotected ! path-option 1 explicit name CASE2 segment-routing !
Überprüfungen
Wie beobachtet, haben wir PCALC angedeutet, dass der Pfad über XR6 (16006) und dann über das letzte Präfix SID (16005) zu gehen hat. Beim Überprüfen der Tunnelberechnungsergebnisse sehen wir, wie sie berechnet wurden.
RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels segment-routing p2p 15
Name: tunnel-te15 Destination: 5.5.5.5 Ifhandle:0x130
Signalled-Name: XR1_t15
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, (Segment-Routing) type explicit CASE2 (Basis for Setup)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Mon Nov 26 02:14:33 2018 (00:40:44 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0xffff
Metric Type: TE (interface)
Path Selection:
Tiebreaker: Min-fill (default)
Protection: Unprotected Adjacency
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: disabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Autoroute Destinations: 1
Loadshare: 0 equal loadshares
Auto-bw: disabled
Path Protection: Not Enabled
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
History:
Tunnel has been up for: 00:08:47 (since Mon Nov 26 02:46:30 UTC 2018)
Current LSP:
Uptime: 00:00:10 (since Mon Nov 26 02:55:07 UTC 2018)
Reopt. LSP:
Last Failure:
LSP not signalled, identical to the [CURRENT] LSP
Date/Time: Mon Nov 26 02:52:43 UTC 2018 [00:02:34 ago]
Prior LSP:
ID: 9 Path Option: 1
Removal Trigger: reoptimization completed
Segment-Routing Path Info (OSPF 1 area 12)
Segment0[Link]: 12.0.0.1 - 12.0.0.2, Label: 24001
Segment1[Node]: 6.6.6.6, Label: 16006
Segment2[Node]: 5.5.5.5, Label: 16005
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Wenn wir eine Traceroute verwenden, können wir die nächsten Hops sehen, die wir effektiv über XR6 durchlaufen.
RP/0/0/CPU0:XR1#traceroute 5.5.5.5 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.5 1 12.0.0.2 [MPLS: Labels 16006/16005 Exp 0] 9 msec 0 msec 0 msec 2 26.0.0.6 [MPLS: Label 16005 Exp 0] 0 msec 0 msec 0 msec 3 46.0.0.4 [MPLS: Label 16005 Exp 0] 0 msec 9 msec 0 msec 4 45.0.0.5 9 msec * 9 msec
Fall 3: SR-TE-Inter-Area-Tunnel mit explizitem Pfad und lokal vorhandenen IPv4-Adressen + suboptimales Präfix-SID-Routing
Es kann Situationen geben, in denen wir die Präfix-SIDs definieren, aber suboptimale oder Schleifen von Datenverkehrsmustern bilden. In diesem Fall erstellen wir dieses Szenario.
explicit-path name CASE3 index 10 next-address strict ipv4 unicast 12.0.0.2 index 20 next-label 16006 index 30 next-label 16002 index 40 next-label 16003 index 50 next-label 16005
!
interface tunnel-te15
ipv4 unnumbered Loopback0
autoroute destination 5.5.5.5
destination 5.5.5.5
path-selection
metric te
segment-routing adjacency unprotected
!
path-option 1 explicit name CASE3 segment-routing
Basierend auf der Präfix-SID, können wir sehen, dass der Datenverkehr die Präfix-SIDs von XR6 -> XR2 -> XR3 -> XR5 durchlaufen sollte.
RP/0/0/CPU0:XR1#show mpls traffic-eng tunnels segment-routing p2p 15
Admin: up Oper: up Path: valid Signalling: connected
path option 1, (Segment-Routing) type explicit CASE3 (Basis for Setup)
<<Output omitted>>
Segment-Routing Path Info (OSPF 1 area 12)
Segment0[Link]: 12.0.0.1 - 12.0.0.2, Label: 24001
Segment1[Node]: 6.6.6.6, Label: 16006
Segment2[Node]: 2.2.2.2, Label: 16002
Segment3[Node]: 3.3.3.3, Label: 16003
Segment4[Node]: 5.5.5.5, Label: 16005
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Wenn wir den Pfad zu 5.5.5.5/32 verfolgen, sehen wir, dass zwischen XR2 und XR6 eine Schleife gebildet wurde, obwohl dies suboptimiert ist, können wir trotzdem ohne Probleme zu XR5 5.5.5.5/32 weiterleiten, da der LSP korrekt eingerichtet ist.
RP/0/0/CPU0:XR1#traceroute 5.5.5.5 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.5 1 12.0.0.2 [MPLS: Labels 16006/16002/16003/16005 Exp 0] 19 msec 19 msec 9 msec 2 26.0.0.6 [MPLS: Labels 16002/16003/16005 Exp 0] 9 msec 9 msec 9 msec 3 26.0.0.2 [MPLS: Labels 16003/16005 Exp 0] 9 msec 9 msec 9 msec 4 23.0.0.3 [MPLS: Label 16005 Exp 0] 9 msec 9 msec 9 msec 5 34.0.0.4 [MPLS: Label 16005 Exp 0] 9 msec 9 msec 9 msec 6 45.0.0.5 9 msec * 9 msec
Zusammenfassung
Beim Erstellen von Multi-Domain-Richtlinien ohne PCEs im Segment Routing Traffic Engineering haben wir nicht die vollständige Ansicht der Link-State-Datenbank. Aus diesem Grund müssen wir explizite Pfade festlegen, die spezifische Routing-Anforderungen erfüllen, da die Transparenz fehlt. Interregionale Tunnel sind möglich und werden durch die Definition expliziter Pfade mit IPv4-Adressen, Adjacency-SIDs und/oder Präfix-SIDs im lokalen Bereich mit Präfix-SIDs der Transit-Geräte und/oder Tail-End der SR-TE-Richtlinie erstellt. Andere explizite Pfaddefinitionen schlagen fehl.
Feedback