Cisco IOS-XR BGP con progetti MPLS
Sommario
Introduzione
Questo documento descrive alcuni scenari con un comportamento e una configurazione speciali per la combinazione di Multiprotocol Label Switching (MPLS) e Border Gateway Protocol (BGP) in Cisco IOS®-XR.
1. È necessaria una route statica per le opzioni VPN tra MPLS e MPLS B e C
In questa immagine viene illustrata l'impostazione dell'opzione B Inter-AS.
Immagine 1.
Il router PE1 di Provider Edge dispone di un percorso per il prefisso VRF 10.200.1.2/32, ma non è stato risolto.
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 non dispone di una route per 10.3.1.4/32. Dispone di una route per 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.
È necessario che sia presente un percorso statico sull'ASBR (Autonomous System Border Route) per l'hop successivo. È necessario configurare questa route statica su ciascuna ASBR e ridistribuirla nel protocollo IGP (Interior Gateway Protocol).
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
!
!
router ospf 1
redistribute static
Il percorso è stato risolto.
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 installa un'etichetta in uscita di POP verso ASBR2 per i prefissi VPNv4/6:
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
Anche con l'hop successivo sul router ASBR verso i router adiacenti iBGP, l'inoltro delle etichette tra le appliance ASBR verrà interrotto, se il percorso statico non è configurato sull'appliance ASBR.
Con l'auto-hop successivo su ASBR1 verso PE1 e senza route statica:
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
Nella colonna Interfaccia in uscita manca l'interfaccia in uscita. La route statica è richiesta sulle appliance ASBR per le opzioni B e C di Inter-AS.
2. Mantenere gli obiettivi dei cicli di lavorazione sugli ASBR per l'opzione B di Inter-AS
È necessario un comando per garantire che l'ASBR archivi/mantenga le route vpnv4/6 e le annunci. Senza questo comando, l'ASBR non memorizza le route se sull'ASBR non è configurato alcun VRF locale che importa una delle Route-Targets delle route o se non è un reflector di route (RR) per la famiglia di indirizzi vpnv4/6.
router bgp 1
address-family ipv4 unicast
!
address-family vpnv4 unicast
retain route-target all
!
3. Gli indirizzi Unicast con etichetta IPv4 non vengono annunciati da ASBR
Il protocollo IPv4 unicast con etichetta è richiesto nelle reti Inter-AS Option C o Seamless MPLS (Unified MPLS). Infatti, a differenza dei prefissi IPv4 (IPv6), i prefissi vpnv4/6 sono etichettati per impostazione predefinita. In caso contrario, il percorso end-to-end Label Switched (LSP) viene interrotto e il flusso del traffico end-to-end non riesce.
Nell'immagine 2 è illustrata l'impostazione dell'opzione C Inter-AS.
Immagine 2.
I router P1 e P2 sono anche i Route Reflector nel loro sistema autonomo (AS) per vpnv4.
L'opzione LU (Labeled Unicast) viene utilizzata per trasportare i prefissi di loopback da un AS all'altro.
ASBR1 ha questa famiglia di indirizzi configurata, ma non contiene route:
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
Il motivo è che l'ASBR deve disporre del comando seguente in modo da poter allocare un'etichetta Multi-Protocol Label Switching (MPLS) per ciascuna route e quindi annunciare le route.
RP/0/0/CPU0:ASBR1#show run router bgp
router bgp 1
address-family ipv4 unicast
redistribute ospf 1
allocate-label all
!
Il risultato di questo comando è:
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
In breve:
- È necessario configurare l'allocazione delle etichette (su tutti i router ASBR e PE)
- È necessario configurare la famiglia di indirizzi ipv4 con etichetta unicast per il sistema adiacente BGP
4. È necessario un router adiacente fittizio iBGP per eBGP-eBGP (back-to-back eBGP) Vpnv4
Guardate l'immagine 3.
Immagine 3.
Ci sono tre ASBR di fila. L'ASBR3 esegue eBGP vpnv4 unicast su ASBR1 e ASBR2.
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
C'è un problema con la pubblicità delle route vpnv4 da ASBR3: ASBR3 non annuncia le route vpnv4 esterne in uscita.
La soluzione consiste nel configurare un router adiacente iBGP fittizio su ASBR3 e abilitare l'opzione next-hop-self: Non è necessario che il vicino iBGP fittizio sia attivo.
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
!
!
!
Di conseguenza, la route vpnv4 viene ora annunciata:
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. Inter-AS Option C - L'etichetta BGP è preferita all'etichetta LDP
Per una configurazione con due ASBR collegate su più collegamenti, fare riferimento a questa immagine. Per far funzionare questo problema, la sessione LU ipv4 di eBGP tra le ASBR deve essere multi-hop perché ci sono collegamenti paralleli tra di esse.
Immagine 4.
Questa è l'opzione C di Inter-AS. I router P1 e P2 sono anche i Route-Reflector per vpnv4.
Tra i router PE e gli ASBR è presente un unicast con etichetta IPv4. Gli ASBR sono collegati direttamente su più collegamenti.
Sull'ASBR è possibile visualizzare:
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
Non è necessario un LDP (Label Distribution Protocol) tra le appliance ASBR. BGP si occuperà dell'inoltro MPLS sui collegamenti tra gli ASBR.
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
Finora tutto bene. Il problema è relativo allo scenario illustrato in questa immagine.
Immagine 5.
Questa è l'opzione C di Inter-AS. I router P1 e P2 sono anche i Route-Reflector per vpnv4.
Tra i router PE e gli ASBR è presente un unicast con etichetta IPv4. ASBR1 e ASBR2 non sono collegati direttamente. Sono connessi in multi-hop, attraverso una rete che esegue un IGP e un LDP. Nell'immagine 5, questa rete intermedia è rappresentata dal router ASBR3, che esegue un IGP e un LDP con ASBR1 e ASBR2.
Con il multi-hop eBGP sugli ASBR, c'è un problema. La sessione BGP tra le RR in ciascun ASA non viene nemmeno visualizzata.
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}
Per passare da P1, RR in AS 1 a P2, RR in AS 2, l'etichetta in uscita è 24007. Su ASBR1, questa etichetta viene sostituita con l'etichetta 24000.
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}
L'etichetta 24000 è l'etichetta ricevuta su ASBR1 da BGP LU da ASBR2.
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
Tuttavia, il router ASBR intermedio non esegue BGP e non può inoltrare i pacchetti ricevuti con questa etichetta, in quanto non ha assegnato l'etichetta 24000. L'etichetta da utilizzare per portare i pacchetti a 10.100.1.5 è l'etichetta di 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.
Questa operazione viene ripetuta all'hop successivo 10.100.1.4, il loopback di ASBR2.
Si consiglia di utilizzare l'etichetta ricevuta da ASBR3 da LDP, ma non lo è.
Lo stack di etichette aggiunto è {ImplNull 24000} anziché {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 deve imporre l'etichetta LDP 24002 ricevuta dal router ASBR3. Per disabilitare l'inoltro MPLS BGP, aggiungere la parola chiave mpls al comando multi-hop eBGP.
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
!
ASBR1 dispone ora della riscrittura etichetta corretta:
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}
Dal riferimento del comando:
L'uso dell'opzione mpls nel comando ebgp-multihop impedisce a BGP di abilitare MPLS sull'interfaccia peer e impedisce inoltre l'allocazione di etichette di riscrittura Implicit-NULL per gli indirizzi dell'hop successivo appresi dal peer. Ciò è utile in alcuni scenari in cui le etichette di inoltro MPLS agli hop successivi sono già state apprese tramite BGP etichettato come unicast o LDP.
In altre parole, in IOS-XR, quando BGP offre di allocare un'etichetta all'LFIB, avrà la precedenza su LDP. Lo scenario dell'opzione Inter-AS C con più hop tra i router ASBR è uno scenario di questo tipo.
6. Opzione B tra appliance ASA - L'etichetta BGP è preferita all'etichetta LDP
Immagine 6.
Questa è l'opzione B di Inter-AS. Tuttavia, sono presenti più collegamenti paralleli tra le due ASBR. Tra gli ASBR è presente la RFC3107 (scambio di route IPv4 ed etichette MPLS), che consente di evitare l'utilizzo di IGP e LDP.
Per visualizzare la sessione multihop eBGP tra le interfacce di loopback di ASBR1 e ASBR2, è necessario disporre di eBGP LU tra le due ASBR. Poiché esistono due collegamenti tra gli ASBR, sono necessarie due sessioni eBGP LU. Il comando allocate-label è richiesto per la famiglia di indirizzi IPv4.
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
!
!
Le route statiche dalla sezione 1 sono ancora necessarie:
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
10.3.2.4/32 GigabitEthernet0/0/0/2
!
!
La sessione eBGP vpnv4 tra le appliance ASBR:
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
!
!
Si noti che la parola chiave mpls non è necessaria in questo caso, come nella sezione 5. Inoltre, le sessioni LU iBGP tra PE e ASBR non sono necessarie se l'opzione next-hop-self è configurata per le sessioni iBGP vpnv4. L'etichetta pubblicizzata da ASBR2 per 10.100.1.4/32 è l'etichetta 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
Quando tra le ASBR è presente un altro percorso che utilizza i protocolli IGP + LDP o MPLS TE, la parola chiave mpls è necessaria per il comando eBGP multihop.
Immagine 7.
Una route policy BGP su ASBR1 verso P3 viene utilizzata per impostare il peso su un valore molto alto, in modo che i prefissi di P3 siano preferiti rispetto a quelli di ASBR2 direttamente.
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 deve ora utilizzare l'etichetta 24001 come etichetta in uscita per 10.100.1.4/32, ma non:
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}
La soluzione è la stessa della sezione 5: usare la parola chiave mpls per il comando eBGP multihop.
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 utilizza ora l'etichetta 24001 come etichetta in uscita per 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 spinge questa etichetta extra. Un traceroute nel VRF (Virtual Routing and Forwarding) da PE1 a PE2 mostra le etichette aggiuntive sottoposte a push.
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 e LDP sono stati utilizzati tra ASBR1 e P3 e ASBR2 e P3. Lo stesso problema e la stessa soluzione si verificano quando tra questi router viene utilizzato MPLS Traffic Engineering (TE).
Non esiste un LDP da ASBR1 a P3, ma esiste MPLS TE.
Senza la parola chiave mpls sul comando eBGP multihop, si torna allo stesso problema:
I pacchetti inoltrati alla versione 10.100.1.4 non ricevono l'etichetta BGP LU 24000 con 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}
mentre con la parola chiave mpls, l'etichetta 24000 è presente:
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}
Con la parola chiave mpls la riscrittura avrà il seguente aspetto:
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
Senza la parola chiave mpls, la riscrittura avrà il seguente aspetto:
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
Questa etichetta 14012 non viene utilizzata per il traffico da VRF a VRF o da PE a PE, ma se rilevata, potrebbe indicare che la voce della base dell'istanza di inoltro etichette (LFIB) è errata o non è corretta.
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
La commutazione della parola chiave mpls sul comando eBGP multihop potrebbe causare una collisione del messaggio syslog per l'etichetta BGP:
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]
Questo messaggio è per l'etichetta locale 24012.
Il controllo viene eseguito per garantire che un'etichetta attiva di proprietà di BGP non venga assegnata di nuovo da BGP per nessun altro motivo. Questo controllo è valido solo per le etichette per prefisso.
Questo messaggio è un sintomo e non la causa di alcun problema in questo articolo.
7. Sessione BGP multihop su VPN (o 6PE o EVPN) Underlay
In caso di sessione multi-hop di eBGP, il percorso per l'indirizzo dell'hop successivo non può essere individuato tramite una route vpnv4/6 o 6PE (IPv6 su MPLS) o Ethernet Virtual Private Network (EVPN), a meno che il router non sia dotato della versione Cisco IOS®-XR 6.3.2 o successive. Fare riferimento a questa immagine.
Immagine 8.
Possibili scenari di errore:
- Sessione multi-hop eBGP da PE1 (all'interno di un VRF) a PE2 (all'interno di un VRF)
- Sessione multi-hop eBGP da PE1 (all'interno di un VRF) a CE2
Ciò vale:
La sessione multi-hop eBGP è configurata nella sezione VRF del router BGP sul router PE.
La sessione multi-hop eBGP da PE1 (all'interno del VRF) a PE2 (all'interno del VRF) o la sessione multi-hop eBGP da PE1 (all'interno del VRF) a CE2, sono supportate solo a partire da Cisco IOS®-XR 6.3.2.
L'indirizzo del peer eBGP è raggiungibile sulla base dell'indirizzo che consiste di vnpv4. vpnv6, 6PE o EVPN.
Nelle versioni Cisco IOS® precedenti alla 6.3.2, la sessione eBGP sarà inattiva.
Ad esempio, la sessione multi-hop eBGP da PE1 a PE2 in VRF 1 è configurata.
Configurazione appropriata per la sessione multi-hop eBGP da PE1 a PE2 in 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
!
!
!
!
La sessione eBGP rimane inattiva:
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)
La route per l'indirizzo peer eBGP è presente nella tabella di routing VRF one:
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.
La causa sottostante del problema è che la route per l'indirizzo peer è una route importata:
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
Questa funzione è supportata dopo Cisco IOS®-XR 6.3.2.
8. Ridistribuzione di BGP in LDP
Questo è il significato di MPLS unificato o senza interruzioni e la sua configurazione con IOS-XR: MPLS unificato con IOS-XR
Con MPLS unificato standard, esiste una LU BGP tra tutti i router PE e ABR, come mostrato nell'immagine.
Immagine 9.
Immagine 10.
Nell'esempio, esiste un'area/livello IGP senza BGP LU. A sinistra, l'area di aggregazione è in realtà il processo OSPF (Open Shortest Path First) 1, che non ha una ridistribuzione con il processo OSPF 2 nel nucleo. Nella parte della rete con OSPF 1, non è presente alcuna LU BGP tra i router PE e i router ABR (Area Border Router).
Immagine 11.
I prefissi BGP LU vengono ridistribuiti nell'IGP OSPF 1 su ABR1 come mostrato nell'immagine.
Immagine 12.
È necessario disporre di BGP per allocare l'etichetta per i prefissi LU iBGP ricevuti. Tuttavia, questa etichetta non viene automaticamente annunciata da LDP nell'associazione etichetta per il prefisso ridistribuito. Per impostazione predefinita, IOS(-XE) esegue questa operazione.
Si noti che ABR sta ridistribuendo le route BGP interne nell'IGP nell'area sinistra. Ciò significa che il comando bgp redistribute-internal è richiesto con il router bgp.
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
Quando è abilitata l'allocazione delle etichette locali, ABR assegna un'etichetta locale alle route LU iBGP ricevute.
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
La selezione per l'allocazione dei criteri di route può essere utilizzata per specificare a quali prefissi LU BGP ricevuti viene assegnata un'etichetta locale.
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
!
Il prefisso di loopback di PE2 è visibile su ABR1 con un'etichetta locale, ma LDP non vede questa etichetta locale:
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
Ciò significa che l'LSP da PE1 a PE2 viene interrotto:
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
L'LSP viene interrotto in corrispondenza di P2 perché non ha ricevuto un'etichetta remota tramite LDP da ABR1. Ad ABR1 non è stata assegnata localmente l'etichetta per il prefisso 10.100.1.7/32 in LDP.
È necessaria una configurazione sull'ABR per ridistribuire BGP in LDP sul router su cui la route BGP viene ridistribuita nell'IGP.
ABR1 non annuncia un binding di etichetta LDP per il prefisso 10.100.1.7/32 al router P2.
Affinché ABR1 possa annunciare il binding dell'etichetta LDP per i prefissi iBGP ridistribuiti, è necessario che ABR1 abbia la seguente configurazione (il numero AS deve essere configurato).
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
!
!
!
È possibile impostare il filtro LDP per gli annunci. È ad esempio possibile configurare un filtro simile al seguente:
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
L'ID del router LDP viene specificato nell'elenco degli accessi.
In questo esempio, ABR annuncia solo i binding LDP per le route iBGP ridistribuite al router adiacente LDP P2 (e non a P1), poiché 10.100.1.2 è l'ID router LDP di P2.
L'LSP da PE1 a PE2 è ora ininterrotto:
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
Immagine 13.
L'etichetta assegnata BGP (24006) annunciata da LDP nell'area di aggregazione sinistra è ora utilizzata per il traffico da PE1 a PE2.
Si noti che nell'area di aggregazione sinistra viene utilizzata una sola etichetta MPLS. Se si tratta di un MPLS unificato standard, vengono utilizzate due etichette.
A questo punto, non è possibile filtrare le route LU iBGP ridistribuite in LDP, che riceveranno un'etichetta locale e quali no. Non appena la ridistribuzione delle route iBGP LU in LDP è abilitata, tutti ottengono un'etichetta locale.
PE2 inoltre annuncia il prefisso 10.100.1.99/32 in BGP LU. Questo prefisso non viene ridistribuito da ABR1 in OSPF 1. Tuttavia, non appena la ridistribuzione delle route LU iBGP in LDP è stata attivata, il prefisso 10.100.1.99/32 ha anche un'etichetta locale.
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. Comando MPLS Activate Interface
Esempio 1. IGP ma non LDP
Il comando mpls activate è necessario se un IGP si occupa del routing interno, ma non è disponibile alcun LDP per annunciare i binding delle etichette. Se ogni hop esegue BGP, è possibile utilizzare BGP LU per annunciare prefissi ed etichette. Quando è iBGP su un collegamento, il collegamento deve essere abilitato sul router BGP con il comando mpls activate. Fare riferimento a questa immagine.
Immagine 14.
R1 e R2 eseguono una LU IGP e iBGP tra loro. R1 e R2 sono collegati direttamente. R2 ha una sessione LU eBGP con R3.
R3 annuncia il prefisso da 10.100.100.3/2 a R2 su una sessione eBGP LU. R2 annuncia questo prefisso a R1 su una sessione LU iBGP.
L'obiettivo è avere un provider di servizi di traduzione ininterrotto da R1 a R3. È lì?
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
Non esiste un'etichetta per questo prefisso al primo hop.
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 *
Quindi, non c'è nessuna etichetta. Non è una sorpresa, perché MPLS non è abilitato sull'interfaccia di R2:
RP/0/0/CPU0:R1#show mpls interfaces
RP/0/0/CPU0:R1#
Il prefisso LU annunciato da R3 è tuttavia presente in R1:
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
È possibile configurare il comando mpls active su R1 per l'interfaccia su 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 è ora abilitato sull'interfaccia in uscita.
RP/0/0/CPU0:R1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No No No Yes
Il comando traceroute ora mostra che l'LSP è ininterrotto.
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
Esempio 2. Confederazione
Nell'esempio viene mostrato che il comando mpls activate è richiesto sui collegamenti di confederazione eBGP (inter-AS) quando si usa BGP LU (RFC 3107) e non si usa LDP.
La rete in questa immagine è una confederazione 6500 con sistemi subautonomi 65501, 65502, 65503 e 65504.
Immagine 15.
L'idea è quella di avere un LSP MPLS da R1 a R8 (10.0.0.8/32 viene pubblicizzato da R8 in BGP LU) utilizzando BGP LU in entrambi i sistemi autonomi.
C'è una LU eBGP regolare tra R7 e R8. C'è una iBGP riconosciuta tra R2 e R4 e tra R5 e R6. C'è una eBGP confermata tra R1 e R2, R4 e R5 e tra R6 e R7. C'è un hop successivo-self in ogni sessione eBGP.
La route statica all'hop successivo del peer eBGP (tipica per le sessioni BGP inter-AS) è necessaria perché esiste eBGP tra i sistemi subautonomi all'interno della confederazione.
Sarà sufficiente per effettuare la connettività tra R1 e R8? Ciò significa che l'obiettivo è avere un LSP ininterrotto da R1 a R8.
Controlla questo.
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 * * *
Il comando traceroute non restituisce hop/etichette e continuerà se non viene specificato alcun limite TTL. I router probabilmente rispondono al traceroute, ma i pacchetti potrebbero non essere in grado di tornare alla versione R1. Eseguire il traceroute mpls, che è la scelta più sicura.
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
Il problema si verifica in R4. L'interfaccia in uscita non è presente in 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
La voce in CEF non è risolta:
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 non è abilitato sull'interfaccia GE0/0/0/1:
RP/0/0/CPU0:R4#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
Il problema viene risolto con il comando di attivazione di MPLS per BGP sul collegamento tra R4 e R5. R4 e R5 hanno una sessione di confederazione eBGP su questo collegamento. In realtà, si tratta di una sessione iBGP all'interno della confederazione 6500. Di conseguenza, il comando per attivare MPLS è necessario per assicurarsi che il prefisso su R4 venga risolto nell'hop successivo R5. In altre reti regolari, questo problema sarebbe risolto da LDP, ma qui non c'è LDP tra R4 e R5 perché si tratta di una sessione eBGP all'interno della confederazione.
Aggiungere il comando mpls activate per l'interfaccia ge 0/0/0/1 su R4:
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
Il traceroute ora rivela un LSP ininterrotto da R1 a R8.
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
Esiste ora un'interfaccia in uscita in LFIB per questa voce:
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
L'etichetta in uscita è presente su R4 per il prefisso e CEF mostra il prefisso come risolto:
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}
Feedback