Unified MPLS-configuratievoorbeeld

Inleiding

Dit document beschrijft het doel van Unified Multiprotocol Label Switching (MPLS) en geeft een configuratievoorbeeld.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Achtergrond

Het doel van Unified MPLS is alles te maken met schalen. Om een MPLS-netwerk te kunnen schalen, waar er verschillende soorten platforms en services zijn in delen van het netwerk, is het verstandig om het netwerk in verschillende gebieden te splitsen. Een typisch ontwerp introduceert een hiërarchie die een kern in het centrum heeft met aggregatie aan de zijkant. Om te kunnen schalen, kunnen er verschillende Interior Gateway Protocols (IGP’s) worden toegepast in de kern tegen de aggregatie. Om te kunnen schalen, kunt u de IGP prefixes van het ene IGP in het andere distribueren. Als u de IGP-prefixes van de ene IGP niet in de andere IGP distribueert, zijn de end-to-end Label-Switched Paths (LSP’s) niet mogelijk.

Om de MPLS services end-to-end te leveren hebt u de LSP nodig om end-to-end te zijn. Het doel is om de MPLS-services (MPLS VPN, MPLS L2VPN) ongewijzigd te laten, maar toch een grotere schaalbaarheid te introduceren. Om dit te doen, verplaats sommige van de IGP prefixes in Border Gateway Protocol (BGP) (de loopback prefixes van de PE (Provider Edge) routers), die dan de prefixes end-to-end distribueert.

Architectuur

Afbeelding 1 toont een netwerk met drie verschillende gebieden: een kern - en twee aggregatiegebieden aan de zijkant. Elk gebied runt zijn eigen IGP, zonder herverdeling tussen hen op de Router van het Gebied (ABR). Gebruik van BGP is nodig om een end-to-end MPLS LSP te kunnen leveren. BGP adverteert de loopbacks van de PE routers met een etiket over het volledige domein, en verstrekt een end-to-end LSP. BGP wordt tussen de PE's en ABR's met RFC 3107 ingezet, wat betekent dat BGP het IPv4 prefix + label (AFI/SAFI 1/4) verstuurt.

Aangezien de kern- en aggregatiedelen van het netwerk geïntegreerd zijn en end-to-end LSP's geleverd worden, wordt de Unified MPLS-oplossing ook aangeduid als "Seamless MPLS".

Nieuwe technologieën of protocollen worden hier niet gebruikt, alleen MPLS, Label Distribution Protocol (LDP), IGP en BGP. Aangezien u de loopback prefixes van de PE routers van één deel van het netwerk in een ander deel niet wilt verdelen, moet u de prefixes in BGP dragen. Het Intern Border Gateway Protocol (iBGP) wordt in één netwerk gebruikt, zodat het volgende hopadres van de prefixes de loopback prefixes van de PE routers is, die door IGP niet bekend is in de andere delen van het netwerk. Dit betekent dat het volgende hopadres niet kan worden gebruikt om terug te keren naar een IGP prefix. De truc is om de ABR routers Route Reflectors (RR) te maken en de volgende hop in zichzelf te stellen, zelfs voor de gereflecteerde iBGP prefixes. Om dit te laten werken is een nieuwe knop nodig.

Alleen de R's hebben nieuwere software nodig om deze architectuur te ondersteunen. Aangezien de RR's de BGP-prefixes adverteren met de volgende hop die op zichzelf is ingesteld, kennen zij een lokaal MPLS-label toe aan de BGP-prefixes. Dit betekent dat in het gegevensvliegtuig de pakketten die op deze end-to-end LSPs worden doorgestuurd een extra MPLS etiket in de etiketstapel hebben. De R's bevinden zich in het verzendingspad.

Opmerking: In deze architectuur wordt elke MPLS-service geleverd. Bijvoorbeeld, MPLS VPN of MPLS L2VPN worden geleverd tussen de PE routers. Het verschil in het gegevensvlak voor deze pakketten is dat ze nu drie etiketten in de etiketstapel hebben, terwijl ze twee etiketten in de labelstapel hadden toen Unified MPLS niet werd gebruikt.

Er zijn twee mogelijke scenario's:

• ABR stelt de volgende hop niet zelf in voor de voorfixes die door de ABR worden geadverteerd (gereflecteerd door BGP) in het aggregatiegedeelte van het netwerk. Daarom moet ABR de loopback prefixes van de ABR's van de kern-IGP naar de aggregatie-IGP herverdelen. Als dit gebeurt, is er nog schaalbaarheid. Alleen de ABR loopback prefixes (van de kern) hoeven in het aggregatiegedeelte te worden geadverteerd, niet de loopback prefixes van de PE routers van de externe aggregatiedelen.
  
  
• ABR stelt de volgende hop zelf in voor de voorfixes die door het ABR worden geadverteerd (gereflecteerd door BGP) in het aggregatiegedeelte. Daarom hoeft ABR de loopback-upprefixes van de ABR's van de kern-IGP niet te herverdelen in het aggregatie-IGP.

In beide scenario's stelt ABR de volgende hop zelf in voor de voorfixes die door het ABR worden geadverteerd (weerspiegeld door BGP) van het aggregatiegedeelte van het netwerk naar het kerngedeelte. Als dit niet gebeurt, moet het ABR de loopback prefixes van de PE's van de aggregatie IGP naar de kern IGP herverdelen. Als dit gebeurt, is er geen schaalbaarheid.

Om de volgende hop zelf in te stellen voor de weerspiegelde iBGP routes, moet u de buurx.x.x.x de volgende-hop-zelf opdracht vormen.

Configureren

Dit is de configuratie van de PE routers en ABR's voor scenario 2.

Opmerking: De technologie wordt in afbeelding 2 getoond. De voorbeeldservice is xconnect (MPLS L2VPN). Tussen de PE-routers en de ABR's is er BGP voor 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

Opmerking: Herdistributie van de kern-IGP (ospf 1) in de aggregatie-IGP (ospf2 of ospf 3) wordt uitgevoerd met een routekaart. Deze route-map laat de loopback prefixes van de RR toe om opnieuw te verdelen in de aggregatie IGP. De reden hiervoor is dat het loopback prefix van de RR alleen rechtstreeks wordt geadverteerd in het core IGP (ospf 1). Maar het loopback prefix van de RR moet ook bekend zijn in het aggregatie IGP, zodat BGP op de PE router kan samenvallen met de loopback van de RR.

Verifiëren

Zie figuur 2 om de werking van het bedieningspaneel te controleren.

Zie Afbeelding 3 voor de verificatie van de MPLS-labeladvertenties.

Zie Afbeelding 4 om het pakkettransport te controleren.

Dit is hoe pakketten van PE1 naar PE2 worden verzonden. Het achtervoegsel van PE2 is 10.100.1.5/32, dus dat voorvoegsel van belang is.

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

Opmerking: Hop 5 toont .5 * * *? Dit is omdat router P2 geen route voor het bron IP adres 10.100.1.4 (PE1) van het traceroute heeft. Dus kan router P2 de fout bericht van het Internet Control Message Protocol (ICMP) niet naar PE1 terugsturen. Dit is normaal, omdat het punt van Unified MPLS is om de loopback prefixes van alle PE routers in één aggregatiedeel niet te hebben om in de IGPs van de andere aggregatiedelen te tonen. De router P2 probeert de ICMP-foutmelding niet met de oorspronkelijke labelstack te verzenden. Dit komt doordat de originele labelstack maar één label heeft. Als deze originele labelstapel van het pakket twee of meer etiketten heeft, wordt het ICMP foutbericht langs LSP doorgestuurd en kan terug naar de bron van de traceroute. Als de originele labelstack slechts één label heeft, probeert de router die de ICMP-foutmelding genereert een routeraadpleging en probeert deze te routeren via de routingtabel (zonder het gebruik van de oorspronkelijke labelstack).

P2#show ip route 10.100.1.4
% Subnet not in table

Problemen oplossen

Er is momenteel geen specifieke troubleshooting-informatie beschikbaar voor deze configuratie.

Gerelateerde informatie

• Naadloze MPLS-architectuur
• Technische ondersteuning en documentatie – Cisco Systems

Revisiegeschiedenis