Inhalt

Einführung

1. Für die Inter-AS-MPLS-VPN-Optionen B und C ist eine statische Route erforderlich.

2. Beibehaltung der Route Targets auf den ASBRs für Inter-AS Option B

3. IPv4-Unicast-Adressen mit Labels werden nicht von ASBR angekündigt.

4. Für eBGP-eBGP (Back-to-Back eBGP) Vpnv4 ist ein Dummy-iBGP-Nachbarn erforderlich.

5. Option C für die AS-Verbindung - Das BGP-Label wird dem LDP-Label vorgezogen.

6. Inter-AS Option B - Das BGP-Label wird dem LDP-Label vorgezogen.

7. Multihop-BGP-Sitzung über VPN (oder 6PE oder EVPN) Underlay

8. Neuverteilung von BGP in LDP

9. MPLS-Aktivierungsschnittstelle - Befehl

Beispiel 1. IGP, aber kein LDP

Beispiel 2. Konföderation

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

!

Hinweis: Der Befehl kann bestimmten Präfixen Labels zuweisen, wenn eine Routingrichtlinie angegeben wird.

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.

Hinweis: Sie müssen die statischen Routen auch auf ASBR3 konfigurieren.

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:

1. eBGP-Multi-Hop-Sitzung von PE1 (innerhalb einer VRF-Instanz) zu PE2 (innerhalb einer VRF-Instanz)

2. 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.

Hinweis: MPLS-Traceroute funktioniert nur, wenn MPLS-OAM auf jedem Router auf dem Pfad aktiviert 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}