Esempio di configurazione MPLS unificata

Introduzione

Questo documento descrive lo scopo di Unified Multiprotocol Label Switching (MPLS) e fornisce un esempio di configurazione.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Sfondo

Lo scopo di Unified MPLS è proprio quello di scalare. Per scalare una rete MPLS, in cui vi sono diversi tipi di piattaforme e servizi in alcune parti della rete, ha senso suddividere la rete in diverse aree. Un progetto tipico introduce una gerarchia che ha un nucleo al centro con aggregazione laterale. Per garantire la scalabilità, nel core possono esistere diversi IGP (Interior Gateway Protocol) rispetto all'aggregazione. Per scalare, non potete distribuire i prefissi IGP da un IGP all'altro. Se non si distribuiscono i prefissi IGP da un IGP all'altro, non è possibile creare percorsi Label-Switched (LSP) end-to-end.

Per fornire servizi MPLS completi, è necessario che l'LSP sia completo. L'obiettivo è mantenere i servizi MPLS (MPLS VPN, MPLS L2VPN) così come sono, ma introdurre una maggiore scalabilità. A tal fine, spostare alcuni dei prefissi IGP nel Border Gateway Protocol (BGP) (i prefissi di loopback dei router Provider Edge (PE)), che quindi distribuisce i prefissi end-to-end.

Architettura

Nella figura 1 è illustrata una rete con tre aree diverse: un core e due aree di aggregazione laterali. Ogni area esegue il proprio IGP, senza alcuna ridistribuzione tra di loro sul router di confine area (ABR). Per fornire un LSP MPLS end-to-end, è necessario l'uso di BGP. BGP annuncia i loopback dei router PE con un'etichetta nell'intero dominio e fornisce un LSP end-to-end. Il protocollo BGP viene implementato tra PE e ABR con la RFC 3107, quindi BGP invia il prefisso IPv4 + l'etichetta (AFI/SAFI 1/4).

Poiché le parti principali e di aggregazione della rete sono integrate e vengono forniti LSP end-to-end, la soluzione MPLS unificata viene anche definita "MPLS senza interruzioni".

Non vengono utilizzate nuove tecnologie o protocolli, ma solo MPLS, Label Distribution Protocol (LDP), IGP e BGP. Poiché non si desidera distribuire i prefissi di loopback dei router PE da una parte della rete a un'altra, è necessario trasportare i prefissi in BGP. Il protocollo iBGP (Internal Border Gateway Protocol) viene utilizzato in una rete, quindi l'indirizzo hop successivo dei prefissi sono i prefissi di loopback dei router PE, che non sono noti all'IGP nelle altre parti della rete. Ciò significa che l'indirizzo dell'hop successivo non può essere utilizzato per la ricorsione a un prefisso IGP. Il trucco è rendere i router ABR Route Reflectors (RR) e impostare l'hop successivo su se stessi, anche per i prefissi iBGP riflessi. Affinché questa operazione funzioni, è necessaria una nuova manopola.

Per supportare questa architettura, solo gli RR necessitano di un software più recente. Poiché i router annunciano i prefissi BGP con l'hop successivo impostato su se stessi, assegnano un'etichetta MPLS locale ai prefissi BGP. Ciò significa che nel data plane, i pacchetti inoltrati su questi LSP end-to-end hanno un'etichetta MPLS extra nello stack di etichette. I record di risorse sono nel percorso di inoltro.

Nota: Su questa architettura viene fornito qualsiasi servizio MPLS. Ad esempio, MPLS VPN o MPLS L2VPN sono forniti tra i router PE. La differenza nel piano dati per questi pacchetti è che ora hanno tre etichette nello stack, mentre avevano due etichette nello stack quando Unified MPLS non era usato.

Esistono due possibili scenari:

• ABR non imposta l'hop successivo su se stesso per i prefissi annunciati (riflessi da BGP) da ABR nella parte di aggregazione della rete. Per questo motivo, l'ABR deve ridistribuire i prefissi di loopback degli ABR dall'IGP di base all'IGP di aggregazione. In questo caso, la scalabilità è ancora presente. Solo i prefissi di loopback ABR (dal core) devono essere annunciati nella parte di aggregazione, non i prefissi di loopback dai router PE dalle parti di aggregazione remote.
  
  
• L'ABR imposta l'hop successivo su se stesso per i prefissi annunciati (riflessi da BGP) dall'ABR nella parte di aggregazione. Per questo motivo, ABR non deve ridistribuire i prefissi di loopback degli ABR dall'IGP di base all'IGP di aggregazione.

In entrambi gli scenari, l'ABR imposta l'hop successivo su se stesso per i prefissi annunciati (riflessi da BGP) dall'ABR dalla parte di aggregazione della rete nella parte centrale. In caso contrario, l'ABR deve ridistribuire i prefissi di loopback dei PE dall'IGP di aggregazione nell'IGP di base. In questo caso, non vi è scalabilità.

Per impostare l'hop successivo su se stesso per le route iBGP riflesse, è necessario configurare il comando next-hop-self-all del router adiacente.

Configurazione

Questa è la configurazione dei router PE e degli ABR per lo scenario 2.

Nota: La topologia è illustrata nella Figura 2. Il servizio di esempio è xconnect (MPLS L2VPN). Tra i router PE e gli ABR, è presente l'etichetta BGP per IPv4 +.

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

Nota: La ridistribuzione dell'IGP di base (ospf 1) nell'aggregazione IGP (ospf2 o ospf 3) viene eseguita con una route-map. Questa route-map consente ai prefissi di loopback dell'RR di essere ridistribuiti nell'IGP di aggregazione. Il motivo è che il prefisso di loopback della RR viene pubblicizzato solo direttamente nell'IGP di base (ospf 1). Tuttavia, il prefisso di loopback dell'RR deve essere noto anche nell'aggregazione IGP, in modo che BGP sul router PE possa eseguire il peer con il loopback dell'RR.

Verifica

Vedere la Figura 2 per verificare il funzionamento del piano di controllo.

Vedere la Figura 3 per verificare gli annunci delle etichette MPLS.

Vedere la Figura 4 per verificare l'inoltro del pacchetto.

In questo modo i pacchetti vengono inoltrati da PE1 a PE2. Il prefisso di loopback di PE2 è 10.100.1.5/32, quindi il prefisso è interessante.

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

Nota: Hop 5 mostra ?5 * * ?. Infatti il router P2 non ha un percorso per l'indirizzo IP di origine 10.100.1.4 (PE1) del traceroute. Pertanto, il router P2 non può inviare il messaggio di errore ICMP (Internet Control Message Protocol) a PE1. Si tratta di un comportamento normale, in quanto lo scopo di Unified MPLS è non avere i prefissi di loopback di tutti i router PE in una parte di aggregazione da visualizzare negli IGP delle altre parti di aggregazione. Il router P2 non tenta di inoltrare il messaggio di errore ICMP allo stack di etichette originale. Infatti, lo stack di etichette originale ha una sola etichetta. Se lo stack di etichette originale del pacchetto ha due o più etichette, il messaggio di errore ICMP viene inoltrato lungo l'LSP e può tornare all'origine del traceroute. Se lo stack di etichette originale ha una sola etichetta, il router che genera il messaggio di errore ICMP tenta di eseguire una ricerca del percorso e di instradarlo usando la tabella di routing (senza usare lo stack di etichette originale).

P2#show ip route 10.100.1.4
% Subnet not in table

Risoluzione dei problemi

Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.

Informazioni correlate

• Architettura MPLS perfetta
• Documentazione e supporto tecnico – Cisco Systems

Cronologia delle revisioni