Cisco IOS-XR BGP mit MPLS-Designs
Inhalt
Einführung
In diesem Dokument werden einige Szenarien beschrieben, die ein besonderes Verhalten und eine spezielle Konfiguration für die Kombination von Multiprotocol Label Switching (MPLS) und Border Gateway Protocol (BGP) in Cisco IOS®-XR aufweisen.
1. Für die Inter-AS-MPLS-VPN-Optionen B und C ist eine statische Route erforderlich.
Dieses Bild zeigt eine Einrichtung für die Option B für die AS-Verbindung.
Bild 1.
Der Provider Edge (PE)-Router PE1 verfügt über eine Route für das VRF-Präfix 10.200.1.2/32, ist jedoch nicht aufgelöst.
RP/0/0/CPU0:PE1#show cef vrf one 10.200.1.2
10.200.1.2/32, version 3, internal 0x5000001 0x0 (ptr 0xa140be74) [1], 0x0 (0x0), 0x208 (0xa14a7118)
Updated Apr 7 14:36:45.628
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.3.1.4/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0d87468 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
unresolved
labels imposed {24004}
PE1 hat keine Route für 10.3.1.4/32. Es hat eine Route für 10.3.1.0/24.
RP/0/0/CPU0:PE1#show route 10.3.1.4
Routing entry for 10.3.1.0/24
Known via "ospf 1", distance 110, metric 3, type intra area
Installed Apr 7 14:07:01.140 for 00:32:48
Routing Descriptor Blocks
10.1.1.2, from 10.100.1.3, via GigabitEthernet0/0/0/0
Route metric is 3
No advertising protos.
Auf der Autonomous System Border Route (ASBR) für den Next-Hop muss eine statische Route vorhanden sein. Sie müssen diese statische Route auf jedem ASBR konfigurieren und im Interior Gateway Protocol (IGP) neu verteilen.
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
!
!
router ospf 1
redistribute static
Die Route ist nun aufgelöst.
RP/0/0/CPU0:PE1#show cef vrf one 10.200.1.2
10.200.1.2/32, version 3, internal 0x5000001 0x0 (ptr 0xa140be74) [1], 0x0 (0x0), 0x208 (0xa14a7118)
Updated Apr 7 14:36:45.628
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.3.1.4/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa150f9f4 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
next hop 10.3.1.4/32 via 24005/0/21
next hop 10.1.1.2/32 Gi0/0/0/0 labels imposed {24003 24004}
ASBR1 installiert ein ausgehendes Label von POP zu ASBR2 für die VPNv4/6-Präfixe:
RP/0/0/CPU0:ASBR1#show mpls forwarding prefix 10.3.1.4/32
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24005 Pop 10.3.1.4/32 Gi0/0/0/1 10.3.1.4 2506
Selbst bei Next-Hop-Self auf dem ASBR zu den iBGP-Nachbarn wird die Label-Weiterleitung zwischen den ASBRs unterbrochen, wenn die statische Route nicht auf dem ASBR konfiguriert ist.
Mit Next-Hop-Self auf ASBR1 zu PE1 und ohne statische Route:
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24006 detail
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24006 24004 2:2:10.200.1.2/32 10.3.1.4 0
Updated: Apr 7 14:49:58.190
Path Flags: 0x6000 [ ]
Label Stack (Top -> Bottom): { }
MAC/Encaps: 0/0, MTU: 0
Packets Switched: 0
Beachten Sie, dass die ausgehende Schnittstelle in der Spalte "Ausgehende Schnittstelle" fehlt. Die statische Route wird für ASBRs für die Inter-AS-Optionen B und C benötigt.
2. Beibehaltung der Route Targets auf den ASBRs für Inter-AS Option B
Es wird ein Befehl benötigt, um sicherzustellen, dass der ASBR die vpnv4/6-Routen speichert/speichert und dann ankündigt. Ohne diesen Befehl speichert der ASBR die Routen nicht, wenn auf dem ASBR kein lokales VRF konfiguriert ist, das eines der Route Targets der Routen importiert, oder wenn es sich nicht um einen Route Reflector (RR) für die Adressfamilie vpnv4/6 handelt.
router bgp 1
address-family ipv4 unicast
!
address-family vpnv4 unicast
retain route-target all
!
3. IPv4-Unicast-Adressen mit Labels werden nicht von ASBR angekündigt.
IPv4-Unicast mit Label wird in Inter-AS-Option C- oder Seamless-MPLS-Netzwerken (Unified MPLS) benötigt. Dies liegt daran, dass vpnv4/6-Präfixe standardmäßig als gekennzeichnet sind, dies ist jedoch bei IPv4 (IPv6)-Unicast nicht der Fall. Ist dies nicht der Fall, wird der Label Switched Path (LSP)-End-to-End-Datenverkehrsfluss unterbrochen und durchgängig unterbrochen.
Schauen Sie sich Bild 2 an. Es wird eine C-Einrichtung für die AS-Verbindung angezeigt.
Bild 2.
Die P1- und P2-Router sind auch die Routen-Reflektoren in ihrem AS (Autonomous System) für VPNv4.
Das Label Unicast (LU) wird verwendet, um die Loopback-Präfixe von einem AS in das andere zu übertragen.
Für ASBR1 ist diese Adressfamilie konfiguriert, in ihr sind jedoch keine Routen vorhanden:
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast
RP/0/0/CPU0:ASBR1#
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast summary
BGP router identifier 10.100.1.3, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 41
BGP main routing table version 41
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 41 41 41 41 41 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.3.1.4 0 2 150 151 41 0 0 00:06:29 0
10.100.1.2 0 1 52 52 41 0 0 00:06:42 0
Der Grund hierfür ist, dass der ASBR über den folgenden Befehl verfügen muss, damit er für jede Route ein Multi-Protocol Label Switching (MPLS)-Label zuweisen und die Routen ankündigen kann.
RP/0/0/CPU0:ASBR1#show run router bgp
router bgp 1
address-family ipv4 unicast
redistribute ospf 1
allocate-label all
!
Das Ergebnis dieses Befehls ist:
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast
BGP router identifier 10.100.1.3, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 52
BGP main routing table version 52
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.2.2 2 32768 ?
*> 10.1.2.0/24 0.0.0.0 0 32768 ?
*> 10.2.1.0/24 10.3.1.4 0 0 2 ?
*> 10.2.2.0/24 10.3.1.4 2 0 2 ?
*> 10.3.1.0/24 0.0.0.0 0 32768 ?
* 10.3.1.4 0 0 2 ?
*> 10.100.1.1/32 10.1.2.2 3 32768 ?
*> 10.100.1.2/32 10.1.2.2 2 32768 ?
*> 10.100.1.3/32 0.0.0.0 0 32768 ?
*> 10.100.1.4/32 10.3.1.4 0 0 2 ?
*> 10.100.1.5/32 10.3.1.4 2 0 2 ?
*> 10.100.1.6/32 10.3.1.4 3 0 2 ?
Processed 11 prefixes, 12 paths
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.6/32
BGP routing table entry for 10.100.1.6/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 48 48
Local Label: 24008
Last Modified: Apr 7 16:20:04.509 for 00:00:49
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
10.100.1.2
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
10.100.1.2
2
10.3.1.4 from 10.3.1.4 (10.100.1.4)
Received Label 24002
Origin incomplete, metric 3, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 48
Origin-AS validity: not-found
Kurz gesagt:
- Label-Zuweisung muss konfiguriert werden (auf allen ASBRs und PE-Routern)
- Die Adressfamilie ipv4 eLabel-Unicast muss für den BGP-Nachbarn konfiguriert werden.
4. Für eBGP-eBGP (Back-to-Back eBGP) Vpnv4 ist ein Dummy-iBGP-Nachbarn erforderlich.
Schauen Sie sich Bild 3 an.
Bild 3.
Es gibt drei ASBRs in Folge. Der ASBR3 führt eBGP vpnv4-Unicast auf ASBR1 und ASBR2 aus.
RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast
BGP router identifier 10.100.1.7, local AS number 3
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 3
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1
*> 10.200.1.1/32 10.4.1.3 0 1 ?
Route Distinguisher: 2:2
*> 10.200.1.2/32 10.4.2.4 0 2 ?
Processed 2 prefixes, 2 paths
RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast rd 1:1 10.200.1.1/32
BGP routing table entry for 10.200.1.1/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 2 2
Last Modified: Apr 7 18:45:21.510 for 00:03:30
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
1
10.4.1.3 from 10.4.1.3 (10.100.1.3)
Received Label 24009
Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf
Received Path ID 0, Local Path ID 1, version 2
Extended community: RT:1:1
Es besteht ein Problem mit der Werbung für die VPNv4-Routen von ASBR3: ASBR3 kündigt keine externen VPNv4-Routen an.
Die Lösung besteht darin, einen Dummy-iBGP-Nachbarn auf ASBR3 zu konfigurieren und Next-Hop-Self zu aktivieren: Der iBGP-Dummy-Nachbarn muss nicht aktiv sein.
router bgp 3
address-family vpnv4 unicast
retain route-target all
!
neighbor 10.4.1.3
remote-as 1 address-family vpnv4 unicast
route-policy PASS in
route-policy PASS out
!
!
neighbor 10.4.2.4
remote-as 2
address-family vpnv4 unicast
route-policy PASS in
route-policy PASS out
!
!
neighbor 10.99.99.99
remote-as 3
description dummy-iBGP neighbor for back-to-back eBGP vpnv4
update-source Loopback0
address-family vpnv4 unicast
next-hop-self
!
!
!
Das Ergebnis ist, dass die vpnv4-Route jetzt angekündigt wird:
RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast rd 1:1 10.200.1.1/32
BGP routing table entry for 10.200.1.1/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 12 12
Local Label: 24002
Last Modified: Apr 7 18:58:04.510 for 00:01:46
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
1
10.4.1.3 from 10.4.1.3 (10.100.1.3)
Received Label 24009
Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf
Received Path ID 0, Local Path ID 1, version 12
Extended community: RT:1:1
5. Option C für die AS-Verbindung - Das BGP-Label wird dem LDP-Label vorgezogen.
In diesem Bild sehen Sie eine Konfiguration mit den beiden ASBRs, die über mehrere Verbindungen verbunden sind. Damit dies funktioniert, muss die eBGP IPv4-LU-Sitzung zwischen den ASBRs Multihop sein, da parallele Verbindungen zwischen ihnen bestehen.
Bild 4.
Dies ist die Option C für die AS-Verbindung. Router P1 und P2 sind auch die Routen-Reflektoren für VPNv4.
Zwischen den PE-Routern und den ASBRs ist IPv4 als Unicast markiert. Die ASBRs sind direkt über mehrere Verbindungen miteinander verbunden.
Im ASBR sehen Sie:
router bgp 1
…
neighbor 10.100.1.4
remote-as 2
ebgp-multihop 2
update-source Loopback0
address-family ipv4 labeled-unicast
route-policy PASS in
route-policy PASS out
Zwischen den ASBRs ist kein Label Distribution Protocol (LDP) erforderlich. Das BGP übernimmt die MPLS-Weiterleitung für die Verbindungen zwischen den ASBRs.
RP/0/0/CPU0:ASBR1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
GigabitEthernet0/0/0/1 No No No Yes
GigabitEthernet0/0/0/2 No No No Yes
GigabitEthernet0/0/0/3 No No No Yes
GigabitEthernet0/0/0/4 No No No Yes
So weit so gut. Das Problem besteht im Szenario, wie in diesem Bild gezeigt.
Bild 5.
Dies ist die Option C für die AS-Verbindung. Router P1 und P2 sind auch die Routen-Reflektoren für VPNv4.
Zwischen den PE-Routern und den ASBRs ist IPv4 als Unicast markiert. ASBR1 und ASBR2 sind nicht direkt verbunden. Sie sind über ein Netzwerk mit IGP und LDP mit Multi-Hop verbunden. In Bild 5 wird dieses zwischengeschaltete Netzwerk durch den Router ASBR3 dargestellt, der ein IGP und LDP mit ASBR1 und ASBR2 ausführt.
Bei eBGP-Multi-Hop auf den ASBRs liegt ein Problem vor. Die BGP-Sitzung zwischen den RRs in jedem AS wird nicht einmal ausgeführt.
RP/0/0/CPU0:P1#show cef 10.100.1.5
10.100.1.5/32, version 263, internal 0x1000001 0x0 (ptr 0xa13bde74) [1], 0x0 (0xa1389560), 0xa28 (0xa14a72a8)
Updated Apr 8 09:38:02.551
local adjacency 10.1.2.3
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.1.2.3/32, GigabitEthernet0/0/0/1, 5 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0e8b2a4 0x0]
next hop 10.1.2.3/32
local adjacency
local label 24004 labels imposed {24007}
Um von P1, dem RR in AS 1, auf P2 und dem RR in AS 2 zu gelangen, ist das ausgehende Label 24007. Auf ASBR1 wird dieses Label durch das Label 24000 ersetzt.
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24007
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24007 24000 10.100.1.5/32 10.100.1.4 1404
RP/0/0/CPU0:ASBR1#show cef 10.100.1.5
10.100.1.5/32, version 155, internal 0x5000001 0x0 (ptr 0xa13be174) [1], 0x0 (0xa138965c), 0xa08 (0xa14a72d0)
Updated Apr 8 10:02:38.101
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.100.1.4/32, 5 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa150f874 0x0]
recursion-via-/32
next hop 10.100.1.4/32 via 24004/0/21
local label 24007
next hop 10.4.1.7/32 Gi0/0/0/4 labels imposed {ImplNull 24000}
Das Label 24000 ist das Label, das von der BGP LU vom ASBR2 auf ASBR1 empfangen wurde.
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.5
BGP routing table entry for 10.100.1.5/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 76 76
Local Label: 24007
Last Modified: Apr 8 09:37:57.509 for 00:04:05
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.1 10.100.1.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.1 10.100.1.2
2
10.100.1.4 from 10.100.1.4 (10.100.1.4)
Received Label 24000
Origin incomplete, metric 2, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 76
Origin-AS validity: not-found
Der ASBR-Router dazwischen führt jedoch kein BGP aus und kann daher Pakete, die er mit diesem Label empfängt, nicht weiterleiten, da er das Label 24000 nicht zugewiesen hat. Das Label, das für die Übertragung der Pakete auf 10.100.1.5 verwendet werden soll, ist das Label von LDP:
RP/0/0/CPU0:ASBR1#show route 10.100.1.5/32
Routing entry for 10.100.1.5/32
Known via "bgp 1", distance 20, metric 2, [ei]-bgp, labeled unicast (3107)
Tag 2, type external
Installed Apr 8 10:02:38.082 for 01:24:37
Routing Descriptor Blocks
10.100.1.4, from 10.100.1.4, BGP external
Route metric is 2
No advertising protos.
Dies wird auf Next-Hop 10.100.1.4, das Loopback von ASBR2, zurückgesetzt.
Das von LDP von ASBR3 empfangene Label sollte verwendet werden, dies jedoch nicht.
Der hinzugefügte Label-Stack ist {ImplNull 24000} anstelle von {24002 24000}.
RP/0/0/CPU0:ASBR1#show mpls ldp bindings 10.100.1.4/32
10.100.1.4/32, rev 146
Local binding: label: 24004
Remote bindings: (2 peers)
Peer Label
----------------- ---------
10.100.1.2:0 24003
10.100.1.7:0 24002
ASBR1 sollte das vom ASBR3-Router empfangene LDP-Label 24002 durchsetzen. Um die BGP MPLS-Weiterleitung zu deaktivieren, fügen Sie das mpls-Schlüsselwort dem eBGP-Multi-Hop-Befehl hinzu.
ASBR1:
router bgp 1
…
neighbor 10.100.1.4
remote-as 2
ebgp-multihop 2 mpls
update-source Loopback0
address-family ipv4 labeled-unicast
route-policy PASS in
route-policy PASS out
!
Der ASBR1 verfügt jetzt über eine korrekte Label-Neufassung:
RP/0/0/CPU0:ASBR1#show cef 10.100.1.5
10.100.1.5/32, version 155, internal 0x5000001 0x0 (ptr 0xa13be174) [1], 0x0 (0xa138965c), 0xa08 (0xa14a72d0)
Updated Apr 8 10:02:38.102
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.100.1.4/32, 5 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa150f874 0x0]
recursion-via-/32
next hop 10.100.1.4/32 via 24004/0/21
local label 24007
next hop 10.4.1.7/32 Gi0/0/0/4 labels imposed {24002 24000}
Über die Befehlsreferenz:
Durch die Verwendung der mpls-Option im Befehl ebgp-multihop wird verhindert, dass BGP MPLS auf der Peering-Schnittstelle aktiviert und die Zuweisung von Implicit-NULL-Rewrite-Labels für Next-Hop-Adressen verhindert wird, die vom Peer abgerufen wurden. Dies ist in einigen Szenarien nützlich, in denen die Labels für die MPLS-Weiterleitung an die Nexthops bereits über BGP als Unicast oder LDP erfasst wurden.
Mit anderen Worten: Wenn BGP in IOS-XR anbietet, dem LFIB ein Label zuzuweisen, hat es Vorrang vor LDP. Das Szenario der Option C für die AS-Verbindung mit mehreren Hops zwischen den ASBR-Routern ist ein solches Szenario.
6. Inter-AS Option B - Das BGP-Label wird dem LDP-Label vorgezogen.
Bild 6.
Dies ist Option B für die AS-Verbindung. Es gibt jedoch mehrere parallele Verbindungen zwischen den beiden ASBRs. Es gibt RFC3107 (Austausch von IPv4-Routen und MPLS-Labels) zwischen den ASBRs, anstatt ein IGP und LDP zu verwenden.
Um die eBGP-Multihop-Sitzung zwischen den Loopback-Schnittstellen von ASBR1 und ASBR2 aufzurufen, wird zwischen den beiden ASBRs eine eBGP-LU benötigt. Da zwischen den ASBRs zwei Verbindungen bestehen, sind zwei eBGP LU-Sitzungen erforderlich. Die Befehlszuweisung als Label wird für die Adressfamilie IPv4 benötigt.
router bgp 65001
address-family ipv4 unicast
network 10.100.1.3/32
allocate-label all
!
neighbor 10.3.1.4
remote-as 65002
address-family ipv4 labeled-unicast
route-policy pass in
route-policy pass out
!
!
neighbor 10.3.2.4
remote-as 65002
address-family ipv4 labeled-unicast
route-policy pass in
route-policy pass out
!
!
Statische Routen aus Abschnitt 1 werden weiterhin benötigt:
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
10.3.2.4/32 GigabitEthernet0/0/0/2
!
!
Die eBGP-v4-Sitzung zwischen den ASBRs:
router bgp 65001
address-family ipv4 unicast
network 10.100.1.3/32
allocate-label all
!
address-family vpnv4 unicast
retain route-target all
!
neighbor 10.100.1.4
remote-as 65002
ebgp-multihop 255
update-source Loopback0
address-family vpnv4 unicast
route-policy pass in
route-policy pass out
!
!
Beachten Sie, dass das mpls-Schlüsselwort hier nicht benötigt wird, wie in Abschnitt 5. Außerdem sind die iBGP-LU-Sitzungen zwischen PE und ASBRs nicht erforderlich, wenn Next-Hop-Self für die iBGP-VPNv4-Sitzungen konfiguriert ist. Das von ASBR2 für 10.100.1.4/32 angegebene Label ist Label 3:
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.4/32
Fri Jun 2 11:50:16.178 UTC
BGP routing table entry for 10.100.1.4/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 8 8
Local Label: 24005
Last Modified: Jun 2 11:48:39.920 for 00:01:36
Paths: (4 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
65002
10.3.1.4 from 10.3.1.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 8
Origin-AS validity: not-found
Path #2: Received by speaker 0
Not advertised to any peer
65002
10.3.2.4 from 10.3.2.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #3: Received by speaker 0
Not advertised to any peer
65003 65002
10.3.3.9 from 10.3.3.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, valid, external, group-best
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #4: Received by speaker 0
Not advertised to any peer
65003 65002
10.3.4.9 from 10.3.4.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Fri Jun 2 11:51:06.994 UTC
10.100.1.4/32, version 254, internal 0x1000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13896ec), 0xa20 (0xa14a70f0)
Updated Jun 2 11:48:39.634
local adjacency 10.3.1.4
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.3.1.4/32, GigabitEthernet0/0/0/1, 5 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0e8b1fc 0xa0e8b34c]
next hop 10.3.1.4/32
local adjacency
local label 24005 labels imposed {ImplNull}
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24005
Fri Jun 2 11:51:20.204 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24005 Pop 10.100.1.4/32 Gi0/0/0/1 10.3.1.4 610
Wenn ein anderer Pfad zwischen den ASBRs vorhanden ist und dieser Pfad IGP + LDP oder MPLS TE verwendet, wird das Schlüsselwort mpls für den eBGP-Multihop-Befehl benötigt.
Bild 7.
Eine BGP-Routing-Richtlinie für ASBR1 zu P3 wird verwendet, um das Gewicht sehr hoch festzulegen, sodass Präfixe von P3 gegenüber Präfixen von ASBR2 direkt bevorzugt werden.
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.4/32
Fri Jun 2 11:57:23.789 UTC
BGP routing table entry for 10.100.1.4/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 9 9
Local Label: 24005
Last Modified: Jun 2 11:51:58.920 for 00:05:24
Paths: (4 available, best #3)
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
Path #1: Received by speaker 0
Not advertised to any peer
65002
10.3.1.4 from 10.3.1.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external, group-best
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #2: Received by speaker 0
Not advertised to any peer
65002
10.3.2.4 from 10.3.2.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #3: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
65003 65002
10.3.3.9 from 10.3.3.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, weight 65535, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 9
Origin-AS validity: not-found
Path #4: Received by speaker 0
Not advertised to any peer
65003 65002
10.3.4.9 from 10.3.4.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
ASBR1 sollte jetzt das Label 24001 als ausgehende Bezeichnung für 10.100.1.4/32 verwenden. Sie
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Fri Jun 2 11:59:46.519 UTC
10.100.1.4/32, version 255, internal 0x1000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13896ec), 0xa20 (0xa14a7140)
Updated Jun 2 11:51:58.741
local adjacency 10.3.3.9
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.3.3.9/32, GigabitEthernet0/0/0/3, 7 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0e8b544 0xa0e8b5ec]
next hop 10.3.3.9/32
local adjacency
local label 24005 labels imposed {ImplNull}
Die Lösung ist die gleiche wie in Abschnitt 5: Verwenden Sie das mpls-Schlüsselwort für den eBGP-Multihop-Befehl.
RP/0/0/CPU0:ASBR1# conf t
Fri Jun 2 13:56:45.618 UTC
RP/0/0/CPU0:ASBR1(config)#router bgp 65001
RP/0/0/CPU0:ASBR1(config-bgp)# neighbor 10.100.1.4
RP/0/0/CPU0:ASBR1(config-bgp-nbr)#ebgp-multihop 255 mpls
RP/0/0/CPU0:ASBR1(config-bgp-nbr)#commit
ASBR1 verwendet jetzt das Label 24001 als ausgehende Bezeichnung für 10.100.1.4/32.
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Fri Jun 2 13:58:13.402 UTC
10.100.1.4/32, version 200, internal 0x5000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13895cc), 0xa08 (0xa14a71b8)
Updated Jun 2 13:56:59.378
Prefix Len 32, traffic index 0, precedence n/a, priority 15
via 10.3.3.9/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa15102f4 0x0]
recursion-via-/32
next hop 10.3.3.9/32 via 24014/0/21
local label 24005
next hop 10.3.3.9/32 Gi0/0/0/3 labels imposed {ImplNull 24001}
ASBR1 überträgt diese zusätzliche Bezeichnung. Eine Traceroute im VRF (Virtual Routing and Forwarding) von PE1 zu PE2 zeigt die zusätzlich übertragenen Label.
RP/0/0/CPU0:PE1#trace vrf one 10.99.1.2
Fri Jun 2 13:49:38.959 UTC
Type escape sequence to abort.
Tracing the route to 10.99.1.2
1 10.1.1.5 [MPLS: Labels 24002/24012 Exp 0] 29 msec 39 msec 39 msec
2 10.1.2.3 [MPLS: Label 24012 Exp 0] 29 msec 29 msec 39 msec
3 10.3.1.4 [MPLS: Label 24007 Exp 0] 39 msec 39 msec 39 msec
4 10.2.1.6 [MPLS: Labels 24001/24005 Exp 0] 39 msec 39 msec 29 msec
5 10.2.2.2 39 msec * 239 msec
IGP und LDP wurden zwischen ASBR1 und P3 sowie zwischen ASBR2 und P3 verwendet. Bei Verwendung von MPLS Traffic Engineering (TE) zwischen diesen Routern treten dasselbe Problem und dieselbe Lösung auf.
Es gibt kein LDP von ASBR1 zu P3, sondern MPLS TE.
Ohne das mpls-Schlüsselwort im eBGP-Multihop-Befehl ist dasselbe Problem wieder aufgetreten:
Pakete, die an 10.100.1.4 weitergeleitet werden, erhalten das BGP LU-Label 24000 nicht per Push.
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Tue Jun 6 10:36:56.528 UTC
10.100.1.4/32, version 50, internal 0x1000001 0x0 (ptr 0xa12cc1fc) [1], 0x0 (0xa12b18c0), 0xa20 (0xa14a7258)
Updated Jun 6 10:36:32.930
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.3.3.9/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa15d58f8 0xa15d5840]
next hop 10.3.3.9/32
local adjacency
local label 24012 labels imposed {ImplNull}
Während das mpls-Schlüsselwort das Label 24000 enthält:
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Tue Jun 6 10:36:03.241 UTC
10.100.1.4/32, version 34, internal 0x5000001 0x0 (ptr 0xa12cc1fc) [1], 0x0 (0xa12b15a8), 0xa08 (0xa14a70f0)
Updated Jun 6 09:39:24.56
Prefix Len 32, traffic index 0, precedence n/a, priority 15
Extensions: context-label:24012
via 10.3.3.9/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa150fecc 0x0]
recursion-via-/32
next hop 10.3.3.9/32 via 24011/0/21
local label 24012
next hop 10.3.3.9/32 tt1 labels imposed {ImplNull 24000}
Mit dem mpls-Schlüsselwort sieht die Umschreibung wie folgt aus:
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24012
Tue Jun 6 10:43:50.559 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24012 24000 10.100.1.4/32 tt1 10.3.3.9 0
Ohne das mpls-Schlüsselwort sieht die Umschreibung wie folgt aus:
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24012
Tue Jun 6 10:45:08.734 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24012 Pop 10.100.1.4/32 tt1 10.3.3.9 0
Dieses Label 14012 wird nicht für Datenverkehr von VRF zu VRF oder von PE zu PE verwendet. Wenn es jedoch auftritt, kann dies darauf hindeuten, dass der LFIB-Eintrag (Label Forwarding Instance Base) falsch ist oder war.
RP/0/0/CPU0:PE1# trace vrf one 10.99.1.2
Type escape sequence to abort.
Tracing the route to 10.99.1.2
1 10.1.1.5 [MPLS: Labels 24001/24015 Exp 0] 129 msec 229 msec 129 msec
2 10.1.2.3 [MPLS: Label 24015 Exp 0] 219 msec 439 msec 349 msec
3 10.3.3.9 [MPLS: Labels 24000/24011 Exp 0] 169 msec 249 msec 139 msec
4 10.3.5.4 [MPLS: Label 24011 Exp 0] 89 msec 129 msec 109 msec
5 10.2.1.6 [MPLS: Labels 24004/24008 Exp 0] 139 msec 99 msec 139 msec
6 10.2.2.2 129 msec * 219 msec
Ein Umschalten der Schlüsselwortmpls auf den eBGP-Multihop-Befehl kann die Syslog-Meldung für die BGP-Label-Kollision verursachen:
bgp[1051]: %ROUTING-BGP-4-LABEL_COLLISION : Label 24012 collision: prev: [T: 3 RD:0:0:0 PFX/NHID:10.100.1.4/32] curr: [T: 13 RD:0:0:0 PFX/NHID:10.100.1.4/32]
Diese Nachricht gilt für das lokale Label 24012.
Bei der Überprüfung wird sichergestellt, dass ein aktives Label, das dem BGP gehört, nicht erneut vom BGP für andere Zwecke zugewiesen wird. Diese Prüfung gilt nur für Labels mit Präfixen.
Diese Nachricht ist ein Symptom und nicht die Ursache für ein Problem in diesem Artikel.
7. Multihop-BGP-Sitzung über VPN (oder 6PE oder EVPN) Underlay
Bei einer eBGP-Multi-Hop-Sitzung kann die Route für die Next-Hop-Adresse nicht über eine VPNv4/6- oder 6PE-Route (IPv6 over MPLS) oder eine Ethernet Virtual Private Network (EVPN)-Route abgerufen werden, es sei denn, der Router verfügt über die Cisco IOS®-XR 6.3.2 oder höher. Weitere Informationen finden Sie in diesem Bild.
Bild 8.
Mögliche Fehlerszenarien:
- eBGP-Multi-Hop-Sitzung von PE1 (innerhalb einer VRF-Instanz) zu PE2 (innerhalb einer VRF-Instanz)
- eBGP-Multi-Hop-Sitzung von PE1 (innerhalb einer VRF-Instanz) zu CE2
Dies gilt:
Die eBGP-Multi-Hop-Sitzung wird im VRF-Abschnitt unter Router BGP auf dem PE-Router konfiguriert.
Die eBGP-Multi-Hop-Sitzung von PE1 (innerhalb der VRF) zu PE2 (innerhalb der VRF-Instanz) oder die eBGP-Multi-Hop-Sitzung von PE1 (innerhalb der VRF-Instanz) zu CE2 wird nur ab Cisco IOS®-XR 6.3.2 unterstützt.
Die eBGP-Peer-Adresse ist über das Underlay erreichbar, das aus entweder vnpv4 besteht. vpnv6, 6PE oder EVPN.
In Cisco IOS®-Versionen vor 6.3.2 ist die eBGP-Sitzung inaktiv.
Beispielsweise wird die eBGP-Multi-Hop-Sitzung PE1 zu PE2 in VRF konfiguriert.
Die relevante Konfiguration für die eBGP-Multi-Hop-Sitzung von PE1 zu PE2 auf PE1:
interface Loopback100
vrf one
ipv4 address 10.2.100.1 255.255.255.255
router bgp 1
address-family vpnv4 unicast
!
neighbor 10.100.1.2
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
!
!
vrf one
rd 1:1
address-family ipv4 unicast
redistribute connected
!
neighbor 10.2.100.2
remote-as 65002
ebgp-multihop 255
local-as 65001
update-source Loopback100
address-family ipv4 unicast
route-policy pass in
route-policy pass out
!
!
!
!
Die eBGP-Sitzung bleibt inaktiv:
RP/0/0/CPU0:PE1#show bgp vrf one neighbors
BGP neighbor is 10.2.100.2, vrf one
Remote AS 65002, local AS 65001, external link
Remote router ID 0.0.0.0
BGP state = Idle (No route to multi-hop neighbor)
Die Route für die eBGP-Peer-Adresse ist in der VRF-One-Routing-Tabelle vorhanden:
RP/0/0/CPU0:PE1# show route vrf one
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
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 - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR
A - access/subscriber, a - Application route, (!) - FRR Backup path
Gateway of last resort is not set
L 10.2.100.1/32 is directly connected, 00:23:25, Loopback100
B 10.2.100.2/32 [200/0] via 10.100.1.2 (nexthop in vrf default), 00:19:28
RP/0/0/CPU0:PE1# show route vrf one 10.2.100.2/32
Routing entry for 10.2.100.2/32
Known via "bgp 1", distance 200, metric 0, type internal
Installed May 29 09:07:53.368 for 00:19:36
Routing Descriptor Blocks
10.100.1.2, from 10.100.1.2
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
Die grundlegende Ursache des Problems ist, dass die Route für die Peering-Adresse eine importierte Route ist:
RP/0/0/CPU0:PE1# show bgp vpnv4 unicast vrf one 10.2.100.2/32
BGP routing table entry for 10.2.100.2/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Last Modified: May 29 09:07:53.524 for 00:21:20
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.2 (metric 2) from 10.100.1.2 (10.100.1.2)
Received Label 16001
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 7
Extended community: RT:1:1
Source VRF: one, Source Route Distinguisher: 1:1
Dies wird nach Cisco IOS®-XR 6.3.2 unterstützt.
8. Neuverteilung von BGP in LDP
Dies ist Unified oder Nahtloses MPLS, und wie wird es mit IOS-XR konfiguriert: Unified MPLS mit IOS-XR
Bei regulärem Unified MPLS ist BGP LU zwischen allen PE- und ABR-Routern vorhanden, wie im Bild gezeigt.
Bild 9.
Bild 10.
In diesem Beispiel gibt es einen IGP-Bereich/eine IGP-Ebene ohne BGP-LU. Auf der linken Seite ist der Aggregationsbereich tatsächlich OSPF-Prozess 1 (Open Shortest Path First), der nicht über eine Neuverteilung mit OSPF-Prozess 2 im Core verfügt. Im Teil des Netzwerks mit OSPF 1 gibt es keine BGP-LU zwischen PE- und Area Border Router (ABR)-Routern.
Bild 11.
Die BGP-LU-Präfixe werden wie im Bild gezeigt auf IGP OSPF 1 auf ABR1 neu verteilt.
Bild 12.
Das Label für die empfangenen iBGP-LU-Präfixe muss vom BGP zugewiesen werden. Dieses Label wird jedoch nicht automatisch von LDP in der Label-Bindung für das neu verteilte Präfix angekündigt. IOS(-XE) übernimmt dies standardmäßig.
Beachten Sie, dass der ABR interne BGP-Routen im linken Bereich über das IGP verteilt. Dies bedeutet, dass der Befehl bgp redistribute-internal unter Router bgp erforderlich ist.
router bgp 1
bgp redistribute-internal
router ospf 1
router-id 10.100.1.3
redistribute bgp 1 metric 10 route-policy select-to-allocate
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
!
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
Der ABR weist den empfangenen iBGP-LU-Routen eine lokale Bezeichnung zu, wenn die lokale Label-Zuweisung aktiviert ist.
router bgp 1
bgp redistribute-internal
ibgp policy out enforce-modifications
address-family ipv4 unicast
redistribute ospf 1 metric 10 route-policy ospf-1-loopbacks-PE
allocate-label route-policy select-to-allocate
Mit der Route-Policy select-to-assigned (Zugewiesene Route-Policy) kann angegeben werden, welche empfangenen BGP-LU-Präfixe einem lokalen Label zugewiesen werden.
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
!
Das Loopback-Präfix von PE2 wird auf ABR1 mit lokalem Label angezeigt, für LDP wird dieses lokale Label jedoch nicht angezeigt:
RP/0/0/CPU0:ABR1#show bgp ipv4 labeled-unicast 10.100.1.7/32
BGP routing table entry for 10.100.1.7/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 6 6
Local Label: 24006
Last Modified: Sep 5 06:55:47.368 for 06:40:23
Paths: (1 available, best #1)
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.2
Local, (Received from a RR-client)
10.100.1.5 (metric 20) from 10.100.1.5 (10.100.1.7)
Received Label 24003
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 1, version 6
Originator: 10.100.1.7, Cluster list: 10.100.1.5
RP/0/0/CPU0:ABR1#show mpls ldp bindings 10.100.1.7/32
10.100.1.7/32, rev 0 (no route)
No local binding
Remote bindings: (1 peers)
Peer Label
----------------- ---------
10.100.1.2:0 18
Dies bedeutet, dass der LSP von PE1 zu PE2 unterbrochen wird:
RP/0/0/CPU0:PE1#traceroute 10.100.1.7 source 10.100.1.1
Type escape sequence to abort.
Tracing the route to 10.100.1.7
1 10.1.1.2 [MPLS: Label 18 Exp 0] 9 msec 0 msec 0 msec
2 10.1.2.3 0 msec 0 msec 0 msec <<< no MPLS labels
3 10.1.3.4 [MPLS: Labels 16/24003 Exp 0] 29 msec 19 msec 29 msec
4 10.1.4.5 [MPLS: Label 24003 Exp 0] 9 msec 9 msec 9 msec
5 * * *
6 10.1.6.7 9 msec * 19 msec
Der LSP wird bei P2 unterbrochen, da er kein Remote-Label über LDP von ABR1 erhalten hat. ABR1 verfügt in LDP nicht über das lokal zugewiesene Label für das Präfix 10.100.1.7/32.
Für den ABR ist eine Konfiguration erforderlich, um BGP in LDP auf dem Router neu zu verteilen, auf dem die BGP-Route auf das IGP verteilt wird.
ABR1 kündigt dem P2-Router keine LDP-Labelbindung für das Präfix 10.100.1.7/32 an.
Damit ABR1 die LDP-Labelbindung für die neu verteilten iBGP-Präfixe ankündigen kann, muss ABR1 die folgende Konfiguration aufweisen (die AS-Nummer muss konfiguriert werden).
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
!
!
!
Sie können die Werbung durch LDP filtern lassen. Sie können z. B. einen Filter wie den folgenden konfigurieren:
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
advertise-to 1
!
ipv4 access-list 1
10 permit ipv4 host 10.100.1.2 any
Sie geben die LDP-Router-ID in der Zugriffsliste an.
In diesem Beispiel kündigt der ABR dem LDP-Nachbarn P2 (und nicht P1) nur LDP-Bindungen für die neu verteilten iBGP-Routen an, da 10.100.1.2 die LDP-Router-ID von P2 ist.
Der LSP von PE1 zu PE2 ist jetzt ununterbrochen:
RP/0/0/CPU0:PE1#traceroute 10.100.1.7 source 10.100.1.1
Type escape sequence to abort.
Tracing the route to 10.100.1.7
1 10.1.1.2 [MPLS: Label 20 Exp 0] 39 msec 49 msec 29 msec
2 10.1.2.3 [MPLS: Label 24006 Exp 0] 29 msec 49 msec 39 msec
3 10.1.3.4 [MPLS: Labels 16/24003 Exp 0] 29 msec 19 msec 29 msec
4 10.1.4.5 [MPLS: Label 24003 Exp 0] 29 msec 19 msec 29 msec
5 * * *
6 10.1.6.7 19 msec * 19 msec
Bild 13.
Das vom LDP im linken Aggregationsbereich angegebene BGP-Label (24006) wird nun für den Datenverkehr von PE1 zu PE2 verwendet.
Beachten Sie, dass im linken Aggregationsbereich nur ein MPLS-Label verwendet wird. Wenn es sich um ein reguläres Unified MPLS handelt, werden zwei Labels verwendet.
Zu diesem Zeitpunkt können Sie nicht filtern, welche der neu verteilten iBGP-Routen des LUs in das LDP aufgenommen werden, sondern eine lokale Bezeichnung erhalten und welche nicht. Sobald die Neuverteilung der iBGP-LU-Routen in das LDP aktiviert ist, erhalten alle ein lokales Label.
PE2 kündigt außerdem das Präfix 10.100.1.99/32 in BGP LU an. Dieses Präfix wird von ABR1 nicht in OSPF 1 umverteilt. Sobald jedoch die Neuverteilung der iBGP LU-Routen in LDP aktiviert war, erhielt das Präfix 10.100.1.99/32 auch ein lokales Label.
RP/0/0/CPU0:ABR1#show mpls ldp bindings 10.100.1.99/32
10.100.1.99/32, rev 24
Local binding: label: 24007
No remote bindings
9. MPLS-Aktivierungsschnittstelle - Befehl
Beispiel 1. IGP, aber kein LDP
Der Befehl mpls enable ist erforderlich, wenn ein IGP die interne Weiterleitung übernimmt, es jedoch kein LDP gibt, das die Label-Bindings ankündigt. Wenn jeder Hop BGP ausführt, kann BGP LU zum Anzeigen von Präfixen und Labels verwendet werden. Wenn es sich um iBGP über eine Verbindung handelt, muss diese Verbindung unter Router-BGP aktiviert werden, wobei der Befehl mpls aktiviert wird. Weitere Informationen finden Sie in diesem Bild.
Bild 14.
R1 und R2 führen eine IGP- und iBGP-LU zwischen ihnen aus. R1 und R2 sind direkt verbunden. R2 hat eine eBGP LU-Sitzung mit R3.
R3 informiert R2 über eine eBGP LU-Sitzung über das Präfix 10.100.100.3/2. R2 informiert R1 über eine iBGP LU-Sitzung über dieses Präfix.
Ziel ist es, einen ununterbrochenen LSP von R1 bis R3 zu erreichen. Ist es da?
RP/0/0/CPU0:R1#trace 10.100.100.3 so 10.100.100.1
Type escape sequence to abort.
Tracing the route to 10.100.100.3
1 100.1.1 !N * !N
Für dieses Präfix gibt es am ersten Hop kein Label.
RP/0/0/CPU0:R1#traceroute mpls ipv4 10.100.100.3/32 ttl 5
Tracing MPLS Label Switched Path to 10.100.100.3/32, timeout is 2 seconds
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.
0 0.0.0.0 MRU 0 [No Label]
Q 1 *
Es gibt also kein Etikett. Dies ist keine Überraschung, da MPLS auf der Schnittstelle zu R2 nicht aktiviert ist:
RP/0/0/CPU0:R1#show mpls interfaces
RP/0/0/CPU0:R1#
Das von R3 angegebene LU-Präfix ist jedoch auf R1 vorhanden:
RP/0/0/CPU0:R1#show bgp ipv4 labeled-unicast 10.100.100.3/32
BGP routing table entry for 10.100.100.3/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Local Label: 24001
Last Modified: Sep 13 14:27:17.510 for 00:11:39
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65001
10.100.1.2 (metric 2) from 10.100.1.2 (10.100.1.2)
Received Label 24002
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 1, version 7
Sie konfigurieren den Befehl mpls active auf R1 für die Schnittstelle zu R2:
router bgp 65000
mpls activate
interface GigabitEthernet0/0/0/0
!
address-family ipv4 unicast
network 10.100.100.1/32
allocate-label all
!
neighbor 10.100.1.2
remote-as 65000
update-source Loopback0
address-family ipv4 labeled-unicast
!
!
!
MPLS ist jetzt auf der ausgehenden Schnittstelle aktiviert.
RP/0/0/CPU0:R1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No No No Yes
Die Traceroute zeigt nun, dass der LSP ununterbrochen funktioniert.
RP/0/0/CPU0:R1#trace 10.100.100.3 so 10.100.100.1
Type escape sequence to abort.
Tracing the route to 10.100.100.3
1 10.1.2.2 [MPLS: Label 24002 Exp 0] 39 msec 9 msec 9 msec
2 10.2.3.3 19 msec * 9 msec
RP/0/0/CPU0:R1#traceroute mpls ipv4 10.100.100.3/32 ttl 5 source 10.100.100.1
Tracing MPLS Label Switched Path to 10.100.100.3/32, timeout is 2 seconds
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 labl,
'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.
0 10.1.2.1 MRU 1500 [Labels: implicit-null/24002 Exp: 0/0]
L 1 10.1.2.2 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0] 0 ms
! 2 10.2.3.3 10 ms
Beispiel 2. Konföderation
Dieses Beispiel veranschaulicht, dass der Befehl mpls enable für eBGP (inter-AS)-Konverbundverbindungen erforderlich ist, wenn Sie BGP LU (RFC 3107) verwenden und LDP nicht verwenden.
Das Netzwerk in diesem Bild ist eine Föderation 65000 mit subautonomen Systemen 65501, 65502, 65503 und 65504.
Bild 15.
Die Idee ist, einen MPLS LSP von R1 bis R8 (10.0.0.8/32 wird von R8 in BGP LU angekündigt) zu haben, indem BGP LU in beiden autonomen Systemen verwendet wird.
Es gibt eine reguläre eBGP LU zwischen R7 und R8. Es wird iBGP zwischen R2 und R4 und zwischen R5 und R6 konfektioniert. Es wird ein eBGP zwischen R1 und R2, R4 und R5 sowie zwischen R6 und R7 konfektioniert. Bei jeder eBGP-Sitzung erfolgt der nächste Hop-Self-Service.
Die statische Route zum nächsten Hop des eBGP-Peers (typisch für Inter-AS-BGP-Sitzungen) wird benötigt, da eBGP zwischen den subautonomen Systemen innerhalb des Bundesstaates existiert.
Reicht dies aus, um Verbindungen zwischen R1 und R8 herzustellen? Dies bedeutet, dass das Ziel darin besteht, einen ununterbrochenen LSP von R1 bis R8 zu erhalten.
Überprüfen Sie dies.
RP/0/0/CPU0:R1#traceroute 10.0.0.8
Type escape sequence to abort.
Tracing the route to 10.0.0.8
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
Die Traceroute gibt keine Hops/Labels zurück und wird fortgesetzt, wenn keine TTL-Obergrenze für den Befehl angegeben wurde. Die Router beantworten wahrscheinlich die Traceroute, aber die Pakete machen sie möglicherweise nicht zurück zu R1. Tun Sie mpls Traceroute, die eine sicherere Wette ist.
RP/0/0/CPU0:R1#trace mpls ipv4 10.0.0.8/32
Tracing MPLS Label Switched Path to 10.0.0.8/32, timeout is 2 seconds
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.
0 10.1.2.1 MRU 1500 [Labels: implicit-null/24015 Exp: 0/0]
L 1 10.1.2.2 MRU 1500 [Labels: 24003/24014 Exp: 0/0] 10 ms
L 2 10.2.3.3 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms
N 3 10.3.4.4 MRU 0 [No Label] 10 ms
Sie sehen, dass das Problem auf R4 liegt. Die ausgehende Schnittstelle fehlt im LFIB:
RP/0/0/CPU0:R4#show mpls forwarding prefix 10.0.0.8/32
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24014 24014 10.0.0.8/32 10.4.5.5 5140
Der Eintrag in CEF ist nicht aufgelöst:
RP/0/0/CPU0:R4#show cef 10.0.0.8/32
10.0.0.8/32, version 109, drop adjacency, internal 0x5000001 0x0 (ptr 0xa14160e4) [1], 0x0 (0xa13f83c8), 0xa08 (0xa16cd370)
Updated Sep 13 12:43:30.252
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.4.5.5/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0f182d8 0x0]
recursion-via-/32
unresolved
local label 24014
labels imposed {24014}
MPLS ist auf der GE0/0/0/1-Schnittstelle nicht aktiviert:
RP/0/0/CPU0:R4#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
Das Problem wird durch den Befehl zur Aktivierung von MPLS für BGP auf der Verbindung zwischen R4 und R5 gelöst. R4 und R5 verfügen über eine eBGP-Konverbundsitzung über diese Verbindung. In Wirklichkeit ist dies eine iBGP-Sitzung innerhalb des Bundes 65000. Daher ist der Befehl zur Aktivierung von MPLS erforderlich, um sicherzustellen, dass das Präfix auf R4 auf den nächsten Hop R5 aufgelöst wird. In anderen regulären Netzwerken würde dies von LDP übernommen, aber hier gibt es kein LDP zwischen R4 und R5, da es sich um eine eBGP-Sitzung innerhalb des Bundes handelt.
Fügen Sie den Befehl mpls enable für die Schnittstelle ge 0/0/0/1 auf R4 hinzu:
router bgp 65502
bgp confederation peers
65501
65503
65504
!
bgp confederation identifier 65000
mpls activate
interface GigabitEthernet0/0/0/1
!
…
RP/0/0/CPU0:R4#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
GigabitEthernet0/0/0/1 No No No Yes
Die Traceroute zeigt nun einen ununterbrochenen LSP von R1 bis R8 an.
RP/0/0/CPU0:R1#trace mpls ipv4 10.0.0.8/32
Tracing MPLS Label Switched Path to 10.0.0.8/32, timeout is 2 seconds
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.
0 10.1.2.1 MRU 1500 [Labels: implicit-null/24015 Exp: 0/0]
L 1 10.1.2.2 MRU 1500 [Labels: 24003/24014 Exp: 0/0] 10 ms
L 2 10.2.3.3 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms
L 3 10.3.4.4 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms
L 4 10.4.5.5 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 20 ms
L 5 10.5.6.6 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 30 ms
L 6 10.6.7.7 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0] 30 ms
! 7 10.7.8.8 30 ms
RP/0/0/CPU0:R1#traceroute 10.0.0.8
Type escape sequence to abort.
Tracing the route to 10.0.0.8
1 10.1.2.2 [MPLS: Label 24015 Exp 0] 69 msec 29 msec 29 msec
2 10.2.3.3 [MPLS: Labels 24003/24014 Exp 0] 49 msec 29 msec 29 msec
3 10.3.4.4 [MPLS: Label 24014 Exp 0] 19 msec 19 msec 19 msec
4 10.4.5.5 [MPLS: Label 24014 Exp 0] 49 msec 19 msec 29 msec
5 10.5.6.6 [MPLS: Label 24014 Exp 0] 19 msec 19 msec 29 msec
6 10.6.7.7 [MPLS: Label 24014 Exp 0] 29 msec 29 msec 29 msec
7 10.7.8.8 29 msec * 29 msec
Für diesen Eintrag gibt es jetzt eine ausgehende Schnittstelle im LFIB:
RP/0/0/CPU0:R4#show mpls forwarding prefix 10.0.0.8/32
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24014 24014 10.0.0.8/32 Gi0/0/0/1 10.4.5.5 2890
Das ausgehende Label ist für das Präfix auf R4 vorhanden, und CEF zeigt das Präfix als aufgelöst an:
RP/0/0/CPU0:R4#show cef 10.0.0.8/32
Updated Sep 13 12:43:30.252
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.4.5.5/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa17420e4 0x0]
recursion-via-/32
next hop 10.4.5.5/32 via 24016/0/21
local label 24014
next hop 10.4.5.5/32 Gi0/0/0/1 labels imposed {ImplNull 24014}
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)