Unified MPLS-Konfigurationsbeispiel

Einführung

Dieses Dokument beschreibt den Zweck von Unified Multiprotocol Label Switching (MPLS) und enthält ein Konfigurationsbeispiel.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrund

Unified MPLS dient ausschließlich der Skalierung. Zur Skalierung eines MPLS-Netzwerks, in dem in Teilen des Netzwerks verschiedene Arten von Plattformen und Services vorhanden sind, ist es sinnvoll, das Netzwerk in verschiedene Bereiche aufzuteilen. Ein typisches Design führt eine Hierarchie ein, die einen Kern in der Mitte mit Aggregation auf der Seite hat. Zur Skalierung können im Core unterschiedliche Interior Gateway Protocols (IGPs) im Vergleich zur Aggregation vorhanden sein. Zur Skalierung können die IGP-Präfixe nicht von einem IGP auf das andere verteilt werden. Wenn Sie die IGP-Präfixe nicht von einem IGP auf das andere IGP verteilen, sind die End-to-End Label-Switched Paths (LSPs) nicht möglich.

Um die MPLS-Services durchgängig bereitstellen zu können, muss der LSP durchgängig sein. Das Ziel besteht darin, die MPLS-Services (MPLS VPN, MPLS L2VPN) unverändert beizubehalten, jedoch eine höhere Skalierbarkeit zu gewährleisten. Hierzu verschieben Sie einige IGP-Präfixe in das Border Gateway Protocol (BGP) (die Loopback-Präfixe der Provider Edge (PE)-Router), das die Präfixe dann durchgängig verteilt.

Architektur

Abbildung 1 zeigt ein Netzwerk mit drei verschiedenen Bereichen: ein Kern und zwei Aggregationsbereiche nebeneinander. Jeder Bereich führt sein eigenes IGP aus, ohne dass die Verteilung zwischen diesen Bereichen auf den Area Border Router (ABR) erfolgt. Zur Bereitstellung eines End-to-End-MPLS-LSP ist die Verwendung von BGP erforderlich. Das BGP kündigt die Loopbacks der PE-Router mit einem Label über die gesamte Domäne an und stellt einen End-to-End-LSP bereit. BGP wird zwischen den PEs und ABRs mit RFC 3107 bereitgestellt, d. h., das BGP sendet das IPv4-Präfix +-Label (AFI/SAFI 1/4).

Da die Kern- und Aggregationsteile des Netzwerks integriert sind und End-to-End-LSPs bereitgestellt werden, wird die Unified MPLS-Lösung auch als "Nahtloses MPLS" bezeichnet.

Hier werden keine neuen Technologien oder Protokolle verwendet, sondern nur MPLS, Label Distribution Protocol (LDP), IGP und BGP. Da Sie die Loopback-Präfixe der PE-Router nicht von einem Teil des Netzwerks in einen anderen Teil verteilen möchten, müssen Sie die Präfixe im BGP übernehmen. Das interne Border Gateway Protocol (iBGP) wird in einem Netzwerk verwendet, sodass die nächste Hop-Adresse der Präfixe die Loopback-Präfixe der PE-Router sind, die vom IGP in den anderen Teilen des Netzwerks nicht bekannt sind. Das bedeutet, dass die nächste Hop-Adresse nicht für die Rekursion zu einem IGP-Präfix verwendet werden kann. Der Trick besteht darin, die Routen-Reflektoren (RR) für ABR-Router zu erstellen und den nächsten Hop selbst festzulegen, selbst für die reflektierten iBGP-Präfixe. Damit dies funktioniert, ist ein neuer Knopf erforderlich.

Nur die RRs benötigen neuere Software, um diese Architektur zu unterstützen. Da die RRs die BGP-Präfixe mit dem nächsten Hop selbst melden, weisen sie den BGP-Präfixen ein lokales MPLS-Label zu. Das bedeutet, dass die auf diesen End-to-End-LSPs weitergeleiteten Pakete auf der Datenebene im Label-Stack über ein zusätzliches MPLS-Label verfügen. Die RRs befinden sich im Weiterleitungspfad.

Hinweis: Über diese Architektur wird ein beliebiger MPLS-Service bereitgestellt. Beispielsweise werden zwischen den PE-Routern MPLS-VPN oder MPLS-L2VPN bereitgestellt. Der Unterschied auf der Datenebene für diese Pakete besteht darin, dass sie nun über drei Labels im Label-Stack verfügen, während sie im Label-Stack zwei Labels enthielten, wenn Unified MPLS nicht verwendet wurde.

Es gibt zwei mögliche Szenarien:

• Der ABR legt den nächsten Hop nicht auf sich selbst für die Präfixe fest, die vom ABR für den Aggregationsteil des Netzwerks angekündigt werden (dargestellt durch BGP). Aus diesem Grund muss der ABR die Loopback-Präfixe der ABRs vom Kern-IGP auf das Aggregation IGP verteilen. Ist dies der Fall, ist die Skalierbarkeit noch gegeben. Nur die ABR-Loopback-Präfixe (vom Core) müssen im Aggregationsteil angekündigt werden, nicht die Loopback-Präfixe der PE-Router aus den Remote-Aggregationsteilen.
  
  
• Der ABR legt den nächsten Hop für die vom ABR für den Aggregationsteil angegebenen Präfixe (reflektiert durch BGP) auf sich selbst fest. Aus diesem Grund muss der ABR die Loopback-Präfixe der ABRs vom Kern-IGP nicht auf das Aggregation IGP verteilen.

In beiden Szenarien legt der ABR den nächsten Hop für die Präfixe fest, die vom ABR aus dem Aggregationsteil des Netzwerks in den Core-Teil angekündigt (dargestellt durch BGP) werden. Andernfalls muss der ABR die Loopback-Präfixe der PEs vom Aggregation IGP auf das Core-IGP verteilen. Ist dies der Fall, gibt es keine Skalierbarkeit.

Um den nächsten Hop für reflektierte iBGP-Routen auf sich selbst festzulegen, müssen Sie den Befehl neighbor x.x.x.x next-hop-self all konfigurieren.

Konfigurieren

Dies ist die Konfiguration der PE-Router und ABRs für Szenario 2.

Hinweis: Die Topologie ist in Abbildung 2 dargestellt. Der Beispieldienst ist xconnect (MPLS L2VPN). Zwischen den PE-Routern und den ABRs gibt es das BGP für IPv4 + Label.

PE1

interface Loopback0
 ip address 10.100.1.4 255.255.255.255

!
interface Ethernet1/0
 no ip address
 xconnect 10.100.1.5 100 encapsulation mpls
!
router ospf 2
 network 10.2.0.0 0.0.255.255 area 0
 network 10.100.1.4 0.0.0.0 area 0
!
router bgp 1
 bgp log-neighbor-changes
 network 10.100.1.4 mask 255.255.255.255
 neighbor 10.100.1.1 remote-as 1
 neighbor 10.100.1.1 update-source Loopback0
 neighbor 10.100.1.1 send-label

RR1


interface Loopback0
 ip address 10.100.1.1 255.255.255.255
router ospf 1
 network 10.1.0.0 0.0.255.255 area 0
 network 10.100.1.1 0.0.0.0 area 0
!
router ospf 2
 redistribute ospf 1 subnets match internal route-map ospf1-into-ospf2
 network 10.2.0.0 0.0.255.255 area 0
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.100.1.2 remote-as 1
 neighbor 10.100.1.2 update-source Loopback0
 neighbor 10.100.1.2 next-hop-self all
 neighbor 10.100.1.2  send-label
 neighbor 10.100.1.4 remote-as 1
 neighbor 10.100.1.4 update-source Loopback0
 neighbor 10.100.1.4 route-reflector-client
 neighbor 10.100.1.4 next-hop-self all
 neighbor 10.100.1.4 send-label

ip prefix-list prefix-list-ospf1-into-ospf2 seq 5 permit 10.100.1.1/32

route-map ospf1-into-ospf2 permit 10
 match ip address prefix-list prefix-list-ospf1-into-ospf2


RR2

interface Loopback0
 ip address 10.100.1.2 255.255.255.255

router ospf 1
 network 10.1.0.0 0.0.255.255 area 0
 network 10.100.1.2 0.0.0.0 area 0
!
router ospf 3
 redistribute ospf 1 subnets match internal route-map ospf1-into-ospf3
 network 10.3.0.0 0.0.255.255 area 0
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.100.1.1 remote-as 1
 neighbor 10.100.1.1 update-source Loopback0
 neighbor 10.100.1.1 next-hop-self all
 neighbor 10.100.1.1 send-label
 neighbor 10.100.1.5 remote-as 1
 neighbor 10.100.1.5 update-source Loopback0
 neighbor 10.100.1.5 route-reflector-client
 neighbor 10.100.1.5 next-hop-self all
 neighbor 10.100.1.5 send-label

ip prefix-list prefix-list-ospf1-into-ospf3 seq 5 permit 10.100.1.2/32

route-map ospf1-into-ospf3 permit 10
 match ip address prefix-list prefix-list-ospf1-into-ospf3


PE2

interface Loopback0
 ip address 10.100.1.5 255.255.255.255

interface Ethernet1/0
 no ip address
 xconnect 10.100.1.4 100 encapsulation mpls

router ospf 3
 network 10.3.0.0 0.0.255.255 area 0
 network 10.100.1.5 0.0.0.0 area 0

router bgp 1
 bgp log-neighbor-changes
 network 10.100.1.5 mask 255.255.255.255
 neighbor 10.100.1.2 remote-as 1
 neighbor 10.100.1.2 update-source Loopback0
 neighbor 10.100.1.2 send-label

Hinweis: Die Neuverteilung des Core-IGP (OSPF 1) in das Aggregation-IGP (OSPF2 oder OSPF 3) erfolgt mit einer Routing-Map. Diese Routing-Map ermöglicht den Loopback-Präfixen des RR die Neuverteilung auf das Aggregation IGP. Der Grund dafür ist, dass das Loopback-Präfix des RR nur direkt im Core-IGP angekündigt wird (OSPF 1). Das Loopback-Präfix des RR muss jedoch auch im Aggregation IGP bekannt sein, damit das BGP auf dem PE-Router mit dem Loopback des RRs verbunden werden kann.

Überprüfen

In Abbildung 2 wird der Betrieb der Kontrollebene überprüft.

In Abbildung 3 können Sie die Meldungen für das MPLS-Label überprüfen.

Zur Überprüfung der Paketweiterleitung siehe Abbildung 4.

Auf diese Weise werden Pakete von PE1 an PE2 weitergeleitet. Das Loopback-Präfix für PE2 lautet 10.100.1.5/32, sodass das Präfix von Interesse ist.

PE1#show ip route 10.100.1.5

Routing entry for 10.100.1.5/32
  Known via "bgp 1", distance 200, metric 0, type internal
  Last update from 10.100.1.1 00:11:12 ago
  Routing Descriptor Blocks:
  * 10.100.1.1, from 10.100.1.1, 00:11:12 ago
    Route metric is 0, traffic share count is 1
    AS Hops 0
    MPLS label: 22


PE1#show ip cef 10.100.1.5
10.100.1.5/32
  nexthop 10.2.2.6 Ethernet0/0 label 19 22


PE1#show ip cef 10.100.1.5 detail
10.100.1.5/32, epoch 0, flags rib defined all labels
  1 RR source [no flags]
  recursive via 10.100.1.1 label 22
    nexthop 10.2.2.6 Ethernet0/0 label 19

PE1#show bgp ipv4 unicast labels

   Network          Next Hop      In label/Out label
   10.100.1.4/32    0.0.0.0         imp-null/nolabel
   10.100.1.5/32    10.100.1.1      nolabel/22


P1#show mpls forwarding-table labels 19 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
Label      Label      or Tunnel Id     Switched      interface              
19         Pop Label  10.100.1.1/32    603468        Et1/0      10.2.1.1   
        MAC/Encaps=14/14, MRU=1504, Label Stack{}
        AABBCC000101AABBCC0006018847
        No output feature configured


RR1#show mpls forwarding-table labels 22 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
Label      Label      or Tunnel Id     Switched      interface             
22         21         10.100.1.5/32    575278        Et0/0      10.1.1.3   
        MAC/Encaps=14/22, MRU=1496, Label Stack{17 21}
        AABBCC000300AABBCC0001008847 0001100000015000
        No output feature configured


RR1#show bgp ipv4 unicast labels
   Network          Next Hop      In label/Out label
   10.100.1.4/32    10.100.1.4      19/imp-null
   10.100.1.5/32    10.100.1.2      22/21


P3#show mpls forwarding-table labels 17 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
Label      Label      or Tunnel Id     Switched      interface             
17         Pop Label  10.100.1.2/32    664306        Et1/0      10.1.2.2   
        MAC/Encaps=14/14, MRU=1504, Label Stack{}
        AABBCC000201AABBCC0003018847
        No output feature configured


RR2#show mpls forwarding-table labels 21 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
Label      Label      or Tunnel Id     Switched      interface             
21         17         10.100.1.5/32    615958        Et0/0      10.3.1.7   
        MAC/Encaps=14/18, MRU=1500, Label Stack{17}
        AABBCC000700AABBCC0002008847 00011000
        No output feature configured


RR2#show bgp ipv4 unicast labels
   Network          Next Hop      In label/Out label
   10.100.1.4/32    10.100.1.1      22/19
   10.100.1.5/32    10.100.1.5      21/imp-null


P2#show mpls forwarding-table labels 17 detail
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop   
Label      Label      or Tunnel Id     Switched      interface             
17         Pop Label  10.100.1.5/32    639957        Et1/0      10.3.2.5   
        MAC/Encaps=14/14, MRU=1504, Label Stack{}
        AABBCC000500AABBCC0007018847
        No output feature configured


PE1#trace
Protocol [ip]:
Target IP address: 10.100.1.5
Source address: 10.100.1.4
DSCP Value [0]:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.100.1.5
VRF info: (vrf in name/id, vrf out name/id)
  1 10.2.2.6 [MPLS: Labels 19/22 Exp 0] 3 msec 3 msec 3 msec
  2 10.2.1.1 [MPLS: Label 22 Exp 0] 3 msec 3 msec 3 msec
  3 10.1.1.3 [MPLS: Labels 17/21 Exp 0] 3 msec 3 msec 2 msec
  4 10.1.2.2 [MPLS: Label 21 Exp 0] 2 msec 3 msec 2 msec
  5  *  *  *
  6 10.3.2.5 4 msec *  4 msec

Hinweis: Hop 5 zeigt 5 Euro * * * ? Der Grund hierfür ist, dass Router P2 über keine Route für die Quell-IP-Adresse 10.100.1.4 (PE1) der Traceroute verfügt. Daher kann Router P2 die ICMP-Fehlermeldung (Internet Control Message Protocol) nicht an PE1 zurücksenden. Dies ist normal, da der Punkt von Unified MPLS darin besteht, dass die Loopback-Präfixe aller PE-Router in einem Aggregationsteil nicht in den IGPs der anderen Aggregationsteile angezeigt werden. Der Router P2 versucht nicht, die ICMP-Fehlermeldung mit dem ursprünglichen Label-Stack weiterzuleiten. Der Grund hierfür ist, dass der ursprüngliche Label-Stack nur über ein Label verfügt. Wenn dieser ursprüngliche Label-Stack des Pakets zwei oder mehr Labels enthält, wird die ICMP-Fehlermeldung entlang des LSP weitergeleitet und kann an die Quelle der Traceroute zurückgeleitet werden. Wenn der ursprüngliche Label-Stack nur über ein Label verfügt, versucht der Router, der die ICMP-Fehlermeldung generiert, eine Routensuche durchzuführen und versucht, diese mithilfe der Routing-Tabelle (ohne Verwendung des ursprünglichen Label-Stacks) weiterzuleiten.

P2#show ip route 10.100.1.4
% Subnet not in table

Fehlerbehebung

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Zugehörige Informationen

• Nahtlose MPLS-Architektur
• Technischer Support und Dokumentation - Cisco Systems

Revisionsverlauf