O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve alguns cenários que têm um comportamento e uma configuração especiais para a combinação de Multiprotocol Label Switching (MPLS) e Border Gateway Protocol (BGP) no Cisco IOS®-XR.
Esta imagem mostra uma configuração da Opção B entre AS.
Imagem 1.
O roteador Provider Edge (PE) PE1 tem uma rota para o prefixo VRF 10.200.1.2/32, mas não está resolvido.
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 não tem uma rota para 10.3.1.4/32. Ele tem uma rota para 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.
Deve haver uma rota estática na rota de borda de sistema autônomo (ASBR) para o próximo salto. Você precisa configurar essa rota estática em cada ASBR e redistribuí-la no Interior Gateway Protocol (IGP).
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
!
!
router ospf 1
redistribute static
A rota está agora resolvida.
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}
O ASBR1 instala um rótulo de saída de POP em direção ao ASBR2 para os prefixos 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
Mesmo com o Next-Hop-Self no ASBR em direção aos vizinhos do iBGP, o encaminhamento de rótulo entre os ASBRs será interrompido, se a rota estática não estiver configurada no ASBR.
Com o Next Hop-Self no ASBR1 em direção ao PE1 e nenhuma rota estática:
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
Observe que a interface de saída está ausente na coluna Interface de saída. A rota estática é necessária nos ASBRs para as Opções B e C entre AS.
Um comando é necessário para garantir que o ASBR armazene/mantenha as rotas vpnv4/6 e depois as anuncie. Sem esse comando, o ASBR não armazena as rotas se não houver nenhum VRF local configurado no ASBR que importe qualquer um dos Route-Targets das rotas, ou se não for um refletor de rota (RR) para a família de endereços vpnv4/6.
router bgp 1
address-family ipv4 unicast
!
address-family vpnv4 unicast
retain route-target all
!
IPv4 rotulado-unicast é necessário em redes Inter-AS Option C ou Seamless MPLS (Unified MPLS). Isso ocorre porque os prefixos de vpnv4/6 são rotulados por padrão, mas esse não é o caso do unicast IPv4 (IPv6). Se esse não for o caso, o caminho comutado por rótulo (LSP) de ponta a ponta será interrompido e o fluxo de tráfego de ponta a ponta falhará.
Veja a imagem 2, ela mostra uma configuração da Opção C entre AS.
Imagem 2.
Os roteadores P1 e P2 também são os refletores de rota em seu sistema autônomo (AS) para vpnv4.
A LU (Labeled Unicast) é usada para transportar os prefixos de loopback de um AS para o outro.
O ASBR1 tem essa família de endereços configurada, mas não há rotas nela:
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
O motivo é que o ASBR deve ter o seguinte comando para que possa alocar um rótulo Multi-Protocol Label Switching (MPLS) para cada rota e depois anunciar as rotas.
RP/0/0/CPU0:ASBR1#show run router bgp
router bgp 1
address-family ipv4 unicast
redistribute ospf 1
allocate-label all
!
Note: O comando pode alocar rótulos para prefixos específicos se uma política de rota for especificada.
O resultado desse 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
Resumindo:
Veja a imagem 3.
Imagem 3.
Há três ASBRs em uma linha. O ASBR3 executa o unicast eBGP vpnv4 para ASBR1 e ASBR2.
Note: Você também deve configurar as rotas estáticas em ASBR3.
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
Há um problema ao anunciar as rotas vpnv4 de ASBR3: O ASBR3 não anuncia as rotas de vpnv4 externas.
A solução é configurar um vizinho iBGP fictício no ASBR3 e ativar o next-hop-self: O vizinho iBGP fictício não precisa estar ativo.
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
!
!
!
O resultado é que a rota vpnv4 agora é anunciada:
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
Consulte esta imagem para ver uma configuração com os dois ASBRs conectados em vários links. Para que isso funcione, a sessão de LU ipv4 do eBGP entre os ASBRs deve ser multi-hop, pois há links paralelos entre eles.
Imagem 4.
Essa é a opção C entre AS. Os roteadores P1 e P2 também são os refletores de rota para vpnv4.
Há IPv4 rotulado unicast entre os roteadores PE e ASBRs. Os ASBRs estão diretamente conectados em vários links.
No ASBR, você vê:
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
Não há necessidade de Protocolo de Distribuição de Rótulo (LDP - Label Distribution Protocol) entre os ASBRs. O BGP cuidará do encaminhamento de MPLS nos links entre os 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
Até agora tudo bem. O problema está no cenário como mostrado nesta imagem.
Imagem 5.
Essa é a opção C entre AS. Os roteadores P1 e P2 também são os refletores de rota para vpnv4.
Há IPv4 rotulado unicast entre os roteadores PE e ASBRs. ASBR1 e ASBR2 não estão diretamente conectados. Eles são conectados multi-hop através de uma rede que executa um IGP e LDP. Na imagem 5, essa rede intermediária é representada pelo roteador ASBR3, que executa um IGP e um LDP com ASBR1 e ASBR2.
Com o eBGP multi-hop nos ASBRs, há um problema. A sessão BGP entre os RR em cada AS nem sequer aparece.
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}
Para obter de P1, o RR no AS 1, para P2, o RR no AS 2, o rótulo de saída é 24007. No ASBR1, esse rótulo é trocado pelo rótulo 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}
O rótulo 24000 é o rótulo recebido em ASBR1 por BGP LU de 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
No entanto, o roteador ASBR entre eles não executa o BGP e, portanto, não pode encaminhar pacotes que recebe com esse rótulo, pois não atribuiu o rótulo 24000. O rótulo que deve ser usado para obter os pacotes para 10.100.1.5 é o rótulo do 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.
Isso se repete no próximo salto 10.100.1.4, o loopback de ASBR2.
O rótulo recebido de ASBR3 por LDP deve ser usado, mas não é.
A pilha de rótulos adicionada é {ImplNull 24000} em vez de {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
O ASBR1 deve impor o rótulo LDP 24002 que recebeu do roteador ASBR3. Para desabilitar o encaminhamento BGP MPLS, você adiciona a palavra-chave mpls ao comando eBGP multi-hop.
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
!
O ASBR1 agora tem a regravação de rótulo correta:
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}
A partir da referência do comando:
O uso da opção mpls no comando ebgp-multihop impede que o BGP ative o MPLS na interface de peering e também impede a alocação de rótulos de regravação Implicit-NULL para endereços do próximo salto aprendidos do peer. Isso é útil em alguns cenários em que os rótulos de encaminhamento de MPLS para os nexthops já foram aprendidos via BGP rotulado unicast ou LDP.
Em outras palavras, no IOS-XR, quando o BGP oferece alocar um rótulo para o LFIB, ele terá precedência sobre o LDP. O cenário da Opção C entre AS com vários saltos entre os roteadores ASBR é esse.
Imagem 6.
Essa é a Opção B entre AS. Entretanto, há vários links paralelos entre os dois ASBRs. Há RFC3107 (trocando rotas IPv4 e rótulos MPLS) entre os ASBRs, em vez de usar um IGP e LDP.
Para ativar a sessão multihop eBGP entre as interfaces de loopback de ASBR1 e ASBR2, a LU do eBGP é necessária entre os dois ASBRs. Há dois links entre os ASBRs, portanto, há duas sessões de LU eBGP necessárias. O comando distribute-label é necessário para a família de endereços 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
!
!
As rotas estáticas da seção 1 ainda são necessárias:
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
10.3.2.4/32 GigabitEthernet0/0/0/2
!
!
A sessão eBGP vpnv4 entre os 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
!
!
Observe que a palavra-chave mpls não é necessária aqui, como na seção 5. Além disso, as sessões de LU do iBGP entre PE e ASBRs não são necessárias se o Next-Hop-Self estiver configurado para as sessões de vpnv4 do iBGP. A etiqueta anunciada pelo ASBR2 para 10.100.1.4/32 é a etiqueta 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 há outro caminho entre os ASBRs e esse caminho usa IGP + LDP ou MPLS TE, a palavra-chave mpls é necessária para o comando multihop eBGP.
Imagem 7.
Uma política de rota de BGP em ASBR1 em direção a P3 é usada para definir o peso muito alto de modo que os prefixos de P3 sejam preferidos aos prefixos de ASBR2 diretamente.
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
O ASBR1 deve agora usar o rótulo 24001 como um rótulo de saída para 10.100.1.4/32. Não:
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}
A solução é a mesma da seção 5: use a palavra-chave mpls para o 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
O ASBR1 agora usa o rótulo 24001 como um rótulo de saída para 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 envia este rótulo extra. Um traceroute no Virtual Routing and Forwarding (VRF) de PE1 para PE2 mostra os rótulos extras enviados.
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
O IGP e o LDP foram usados entre ASBR1 e P3 e ASBR2 e P3. O mesmo problema e a mesma solução existem quando a Engenharia de Tráfego (TE) MPLS é usada entre esses roteadores.
Não há LDP de ASBR1 a P3, mas há TE MPLS.
Sem a palavra-chave mpls no comando eBGP multihop, o mesmo problema está de volta:
Os pacotes encaminhados para 10.100.1.4 não obtêm o rótulo 24000 da LU do BGP.
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}
Enquanto com a palavra-chave mpls, o rótulo 24000 está 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}
Com a palavra-chave mpls, a regravação é semelhante a esta:
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
Sem a palavra-chave mpls, a regravação é assim:
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
Esse rótulo 14012 não é usado para tráfego de VRF para VRF ou PE para PE, mas, se encontrado, pode ser uma indicação de que a entrada Label Forwarding Instance Base (LFIB) está ou estava errada.
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
Alternar a palavra-chave mpls no comando eBGP multihop pode causar a mensagem de syslog para colisão de rótulo de 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]
Esta mensagem é para o rótulo local 24012.
A verificação é feita para garantir que um rótulo ativo de propriedade do BGP não seja atribuído novamente pelo BGP para qualquer outra coisa. Essa verificação é apenas para rótulos por prefixo.
Esta mensagem é um sintoma e não a causa de qualquer problema deste artigo.
Se houver uma sessão de vários saltos eBGP, a rota para o endereço do próximo salto não poderá ser aprendida através de uma rota vpnv4/6 ou 6PE (IPv6 sobre MPLS) ou Ethernet Virtual Private Network (EVPN), a menos que o roteador tenha o Cisco IOS®-XR 6.3.2 ou versão posterior. Consulte esta imagem.
Imagem 8.
Possíveis cenários de falha:
Isto aplica-se:
A sessão de multi-salto do eBGP é configurada na seção VRF sob o roteador BGP no roteador PE.
A sessão eBGP multi-hop do PE1 (dentro do VRF) ao PE2 (dentro do VRF), ou a sessão eBGP multi-hop é do PE1 (dentro do VRF) ao CE2, só é suportada a partir do Cisco IOS®-XR 6.3.2.
O endereço do peer eBGP pode ser alcançado sobre a base que consiste em vnpv4. vpnv6, 6PE ou EVPN.
Nas versões do Cisco IOS® anteriores à 6.3.2, a sessão do eBGP ficará ociosa.
Por exemplo, a sessão de vários saltos do eBGP PE1 para PE2 no VRF um está configurada.
A configuração relevante para a sessão de multi-salto eBGP de PE1 para PE2 em 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
!
!
!
!
A sessão eBGP permanece inativa:
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)
A rota para o endereço do peer eBGP está presente na tabela de roteamento VRF um:
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.
A causa subjacente do problema é que a rota para o endereço de peering é uma rota importada:
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
Isso é suportado após o Cisco IOS®-XR 6.3.2.
Isso é o que o Unified ou o Seamless MPLS é e como ele é configurado com IOS-XR: Unified MPLS com IOS-XR
Com o Unified MPLS regular, há LU BGP entre todos os roteadores PE e ABR, como mostrado na imagem.
Imagem 9.
Imagem 10.
Neste exemplo, há uma área/nível IGP sem LU de BGP. À esquerda, a área de agregação é na verdade o OSPF (Open Shortest Path First) processo 1, que não tem redistribuição com o processo 2 do OSPF no núcleo. Na parte da rede com OSPF 1, não há LU de BGP entre roteadores PE e ABR (Area Border Router, roteador de borda de área).
Imagem 11.
Os prefixos de LU BGP são redistribuídos no IGP OSPF 1 em ABR1, como mostrado na imagem.
Imagem 12.
Você precisa do BGP para alocar o rótulo para os prefixos iBGP LU recebidos. No entanto, esse rótulo não é automaticamente anunciado pelo LDP na associação de rótulo para o prefixo redistribuído. O IOS(-XE) faz isso por padrão.
Observe que o ABR está redistribuindo rotas BGP internas para o IGP na área esquerda. Isso significa que o comando bgp redistribute-internal é necessário no roteador 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
O ABR atribui um rótulo local às rotas LU iBGP recebidas quando a alocação de rótulo local está habilitada.
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
O comando route-policy select-to-Allocation pode ser usado para especificar quais prefixos LU BGP recebidos recebem um rótulo local.
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
!
O prefixo de loopback de PE2 é visto em ABR1 com um rótulo local, mas o LDP não vê esse rótulo local:
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
Isso significa que o LSP de PE1 para PE2 é interrompido:
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
O LSP é interrompido em P2 porque não obteve um rótulo remoto via LDP do ABR1. ABR1 não tem o rótulo atribuído localmente para o prefixo 10.100.1.7/32 no LDP.
Há uma configuração necessária no ABR para redistribuir o BGP no LDP no roteador onde a rota BGP é redistribuída no IGP.
ABR1 não anuncia uma associação de rótulo LDP para o prefixo 10.100.1.7/32 para o roteador P2.
Para que ABR1 anuncie a associação de rótulo LDP para os prefixos iBGP redistribuídos, ABR1 deve ter a seguinte configuração (o número AS deve ser configurado).
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
!
!
!
Você pode fazer com que o LDP filtre os anúncios. Por exemplo, você pode configurar um filtro como este:
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
Você especifica o ID do roteador LDP na lista de acesso.
Com este exemplo, o ABR anuncia somente as associações LDP para as rotas iBGP redistribuídas para o vizinho LDP P2 (e não para P1), já que 10.100.1.2 é o ID do roteador LDP de P2.
O LSP de PE1 para PE2 agora é ininterrupto:
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
Imagem 13.
O rótulo atribuído ao BGP (24006) anunciado pelo LDP na área de agregação esquerda agora é usado para o tráfego de PE1 para PE2.
Observe que somente um rótulo MPLS é usado na área de agregação esquerda. Dois rótulos seriam usados se esse fosse um Unified MPLS regular.
Neste ponto, você não pode filtrar quais das rotas de LU iBGP redistribuídas no LDP, receber um rótulo local e quais não. Assim que a redistribuição de rotas LU do iBGP para o LDP é ativada, todos recebem um rótulo local.
O PE2 também anuncia o prefixo 10.100.1.99/32 na LU do BGP. Esse prefixo não é redistribuído por ABR1 no OSPF 1. No entanto, assim que a redistribuição das rotas LU do iBGP para o LDP foi ativada, o prefixo 10.100.1.99/32 também recebeu um rótulo local.
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
O comando mpls ativate é necessário se houver um IGP cuidando do roteamento interno, mas não há LDP para anunciar as associações de rótulo. Se cada salto executa o BGP, o BGP LU pode ser usado para anunciar prefixos e rótulos. Quando é iBGP através de um link, esse link precisa ser ativado no BGP do roteador com o comando mpls ativados. Consulte esta imagem.
Imagem 14.
R1 e R2 executam um IGP e uma LU iBGP entre eles. R1 e R2 estão diretamente conectados. R2 tem uma sessão de LU de eBGP para R3.
R3 anuncia o prefixo 10.100.100.3/2 para R2 em uma sessão de LU de eBGP. O R2 anuncia esse prefixo a R1 em uma sessão de LU do iBGP.
O objetivo é ter um LSP ininterrupto de R1 para R3. Está aí?
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
Não há rótulo para este prefixo no primeiro salto.
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 *
Então, não há rótulo. Isso não é uma surpresa, pois o MPLS não está ativado na interface para R2:
RP/0/0/CPU0:R1#show mpls interfaces
RP/0/0/CPU0:R1#
O prefixo de LU anunciado por R3 está, no entanto, presente em 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
Você configura o comando mpls ative em R1 para a interface para 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
!
!
!
O MPLS agora está ativado na interface de saída.
RP/0/0/CPU0:R1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No No No Yes
O traceroute agora mostra que o LSP é ininterrupto.
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
Este exemplo ilustra que o comando mpls ativate é necessário em links de confederação de eBGP (inter-AS) quando você usa LU de BGP (RFC 3107) e não está usando LDP.
A rede nesta imagem é uma confederação 65000 com sistemas sub-autônomos 65501, 65502, 65503 e 65504.
Imagem 15.
A ideia é ter um LSP MPLS de R1 para R8 (10.0.0.8/32 é anunciado por R8 em LU BGP) usando LU BGP em ambos os sistemas autônomos.
Há LU de eBGP regular entre R7 e R8. Há um iBGP configurado entre R2 e R4 e entre R5 e R6. Há um eBGP configurado entre R1 e R2, R4 e R5 e entre R6 e R7. Há o próximo salto em cada sessão de eBGP.
A rota estática para o próximo salto do peer eBGP (típico para sessões BGP entre AS) é necessária porque há eBGP entre os sistemas subautônomos dentro da confederação.
Isso será suficiente para fazer a conectividade entre R1 e R8? Isso significa que o objetivo é ter um LSP ininterrupto de R1 para R8.
Verifique isto.
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 * * *
O traceroute não retorna nenhum salto/rótulo e continuaria se não houvesse um limite de TTL fornecido no comando. Os roteadores provavelmente respondem ao traceroute, mas os pacotes podem não voltar ao R1. Faça mpls traceroute, que é uma aposta mais segura.
Note: O traceroute de MPLS só funciona se o OAM de MPLS estiver ativado em cada roteador ao longo do caminho.
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
Você vê que o problema está em R4. A interface de saída está ausente no 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
A entrada no CEF não foi resolvida:
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}
O MPLS não está ativado na interface 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
O problema é resolvido com o comando para ativar o MPLS para BGP no link entre R4 e R5. R4 e R5 têm uma sessão de confederação eBGP neste link. Na realidade, esta é uma sessão iBGP na confederação 65000. Como resultado, o comando para ativar o MPLS é necessário para garantir que o prefixo em R4 seja resolvido para o próximo salto R5. Em outras redes regulares, haveria LDP cuidando disso, mas aqui não há LDP entre R4 e R5 porque é uma sessão eBGP dentro da confederação.
Adicione o comando mpls ativate para a interface ge 0/0/0/1 em 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
O traceroute agora revela um LSP ininterrupto de 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
Agora há uma interface de saída no LFIB para esta entrada:
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
O rótulo de saída está presente em R4 para o prefixo e o CEF mostra o prefixo como resolvido:
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}