El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Acerca de esta traducción
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma.
Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional.
Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe el proceso para verificar la conectividad de extremo a extremo a través de una red de núcleo VPN de Capa 3 MPLS.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
Conocimiento del ruteo IP básico
Conocimiento de la línea de comandos de Cisco IOS® XE y Cisco IOS® XR
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Router con software Cisco IOS XR
Router con software Cisco IOS XE
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
El propósito de este documento es demostrar los pasos básicos de verificación y solución de problemas para verificar la conectividad y el reenvío entre dos routers CE (Customer Edge) interconectados con BGP (Border Gateway Protocol) por una red de núcleo VPN de Capa 3 MPLS con una mezcla de routers Cisco IOS XE y Cisco IOS XR que actúan como routers PE (Provider Edge) y P (Provider).
Según la información y la topología iniciales, la disponibilidad debe ser satisfactoria entre la dirección de origen 192.168.1.10 representada por Loopback1 en el router CE-EAST y la dirección de destino 172.16.1.10 representada por Loopback1 en el router CE-WEST:
CE-EAST#show run interface loopback1
Building configuration...
Current configuration : 66 bytes
!
interface Loopback1
ip address 192.168.1.10 255.255.255.0
end
CE-WEST#show run interface loopback 1
Building configuration...
Current configuration : 65 bytes
!
interface Loopback1
ip address 172.16.1.10 255.255.255.0
end
El alcance ICMP y un traceroute se utilizaron para comenzar a verificar la conectividad entre estas direcciones de origen y destino, sin embargo, a partir de las siguientes salidas se puede ver que esto no fue exitoso:
CE-EAST#ping 172.16.1.10 source loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.10
.....
Success rate is 0 percent (0/5)
CE-EAST#traceroute 172.16.1.10 source loop1 probe 1 numeric
Type escape sequence to abort.
Tracing the route to 172.16.1.10
VRF info: (vrf in name/id, vrf out name/id)
1 10.11.0.2 2 msec
2 *
3 10.10.0.2 [MPLS: Label 16 Exp 0] 9 msec
4 *
5 *
6 *
7 *
8 *
9 *
10 *
11 *
12 *
13 *
14 *
15 *
16 *
17 *
18 *
19 *
20 *
21 *
22 *
23 *
24 *
25 *
26 *
27 *
28 *
29 *
30 *
CE-EAST#
Nota: Durante la resolución de problemas, el uso de un traceroute cuando se conecta a una red MPLS puede ser menos efectivo ya que algunos proveedores de servicios tienden a configurar el comando no mpls ip propagate-ttl forward en Cisco IOS XE o el comando mpls ip-ttl-propagate disable forwarding en Cisco IOS XR para ocultar todos los LSR (Label Switch Router) en el núcleo (sin embargo, esto con la excepción de los routers PE de ingreso y egreso).
Al revisar el estado del router CE de origen, ya que este router no tiene ningún VRF (reenvío de ruta virtual) y no reconoce MPLS, debe verificar el RIB (base de información de routing), CEF (Cisco Express Forwarding) y BGP. En las siguientes salidas, se puede observar que hay una entrada de ruteo conocida a través de BGP a la subred de destino 172.16.1.0/24 y es accesible a través de la interfaz GigabitEthernet0/0:
CE-EAST#show ip route 172.16.1.10
Routing entry for 172.16.1.0/24
Known via "bgp 65001", distance 20, metric 0 <<<<<
Tag 65500, type external
Last update from 10.11.0.2 3d01h ago
Routing Descriptor Blocks:
* 10.11.0.2, from 10.11.0.2, 3d01h ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 65500
MPLS label: none
CE-EAST#show ip cef 172.16.1.10
172.16.1.0/24
nexthop 10.11.0.2 GigabitEthernet0/0 <<<<<
CE-EAST#
Dado que el router CE-EAST de origen tiene una ruta al destino instalado en la RIB, es el momento de observar el router de borde del proveedor PE4 (PE de ingreso), como se muestra en la topología. En este punto, se configuran los distinguidores de ruta y VRF, así como la importación y exportación de destino de ruta, como se observa en las siguientes salidas:
RP/0/0/CPU0:PE4#show run vrf EAST
Mon Sep 11 20:01:54.454 UTC
vrf EAST
address-family ipv4 unicast
import route-target 65000:1 65001:1 65001:2 ! export route-target 65001:1
!
!
!
RP/0/0/CPU0:PE4#show run router bgp
Mon Sep 11 20:06:48.164 UTC
router bgp 65500
address-family ipv4 unicast
!
address-family vpnv4 unicast
!
neighbor 10.10.10.6
remote-as 65500
update-source Loopback0
address-family vpnv4 unicast
!
!
vrf EAST
rd 65001:1
address-family ipv4 unicast
!
neighbor 10.11.0.1
remote-as 65001
address-family ipv4 unicast
route-policy PASS in
route-policy PASS out
!
!
!
!
RP/0/0/CPU0:PE4#
De la salida anterior se puede ver que el nombre VRF "EAST" se definió con la importación route-target para 65000:1, ahora se puede verificar la tabla de ruteo VRF y esto ayuda a determinar si PE4 tiene una ruta a la dirección IP de destino 172.16.1.10:
RP/0/0/CPU0:PE4#show route vrf EAST 172.16.1.10
Mon Sep 11 19:58:28.128 UTC
Routing entry for 172.16.1.0/24
Known via "bgp 65500", distance 200, metric 0
Tag 65000, type internal
Installed Sep 8 18:28:46.303 for 3d01h
Routing Descriptor Blocks
10.10.10.1, from 10.10.10.6
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
RP/0/0/CPU0:PE4#
Como este PE es un dispositivo Cisco IOS XR, la palabra clave "detail" se puede utilizar al final del comando show route vrf <name> para buscar información adicional como la etiqueta VPNv4 impuesta por MP-BGP (Multiprotocol BGP) y el RD de origen (Route Distinguisher) del prefijo:
RP/0/0/CPU0:PE4#show route vrf EAST 172.16.1.10 detail
Mon Sep 11 20:21:48.492 UTC
Routing entry for 172.16.1.0/24
Known via "bgp 65500", distance 200, metric 0
Tag 65000, type internal
Installed Sep 8 18:28:46.303 for 3d01h
Routing Descriptor Blocks
10.10.10.1, from 10.10.10.6
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
Label: 0x10 (16) <<<<<
Tunnel ID: None
Binding Label: None
Extended communities count: 0
Source RD attributes: 0x0000:65000:1 <<<<<
NHID:0x0(Ref:0)
Route version is 0x5 (5)
No local label
IP Precedence: Not Set
QoS Group ID: Not Set
Flow-tag: Not Set
Fwd-class: Not Set
Route Priority: RIB_PRIORITY_RECURSIVE (12) SVD Type RIB_SVD_TYPE_REMOTE
Download Priority 3, Download Version 36
No advertising protos.
RP/0/0/CPU0:PE4#
Ahora, echemos un vistazo al prefijo BGP VPNv4 que se importó en el VRF, observe que esta es la misma etiqueta 16 de la salida anterior y también tiene la comunidad extendida 65000:1. También es importante notar que 10.10.10.1 es el salto siguiente que PE4 necesita para poder realizar una recursión de ruta hacia él, la siguiente dirección "from 10.10.10.6" es el peer BGP que PE4 usó para aprender este prefijo (en este escenario es el Route Reflector P6):
RP/0/0/CPU0:PE4#show bgp vpnv4 unicast vrf EAST 172.16.1.10
Mon Sep 11 22:42:28.114 UTC
BGP routing table entry for 172.16.1.0/24, Route Distinguisher: 65001:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 48 48
Last Modified: Sep 8 18:28:46.314 for 3d04h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65000
10.10.10.1 (metric 20) from 10.10.10.6 (10.10.10.1) <<<<<
Received Label 16
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 0, version 48
Extended community: RT:65000:1 <<<<<
Originator: 10.10.10.1, Cluster list: 10.10.10.6
Source AFI: VPNv4 Unicast, Source VRF: default, Source Route Distinguisher: 65000:1 <<<<<
Al revisar CEF con la palabra clave exact-route en el nivel VRF, puede hacerse una idea de la interfaz de salida para los paquetes. Este comando también puede dar algunos detalles importantes, ya que muestra las dos etiquetas impuestas al prefijo, 24001 y 16, la razón es que la etiqueta 16 proviene de BGP VPNv4 y la etiqueta 24001 proviene de LDP (Label Distribution Protocol):
RP/0/0/CPU0:PE4#show cef vrf EAST exact-route 192.168.1.10 172.16.1.10
Mon Sep 11 22:48:15.241 UTC
172.16.1.0/24, version 36, internal 0x5000001 0x0 (ptr 0xa12dc74c) [1], 0x0 (0x0), 0x208 (0xa155b1b8)
Updated Sep 8 18:28:46.323
local adjacency 10.0.0.16
Prefix Len 24, traffic index 0, precedence n/a, priority 3
via GigabitEthernet0/0/0/4
via 10.10.10.1/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa15c3f54 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
next hop 10.10.10.1/32 via 24010/0/21
next hop 10.0.0.16/32 Gi0/0/0/4 labels imposed {24001 16} <<<<<
Como paso siguiente, se utiliza el comando show bgp vpnv4 unicast para verificar las rutas VPNv4 que aprende este PE. Esta salida muestra la información antes de importar el prefijo VPNv4 al VRF, recuerde que el RT (Destino de ruta) configurado (para este ejemplo los RT importados son 65000:1, 65001:1, 65001:2) indica qué rutas y a qué VRF se importan:
RP/0/0/CPU0:PE4#show bgp vpnv4 unicast
Fri Sep 15 02:15:15.463 UTC
BGP router identifier 10.10.10.4, local AS number 65500
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 85
BGP NSR Initial initsync version 1 (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: 65000:1*>i172.16.1.0/24 10.10.10.1 0 100 0 65000 i <<<<<
*>i172.16.2.0/24 10.10.10.1 0 100 0 65000 i
Route Distinguisher: 65001:1 (default for vrf EAST)
* i0.0.0.0/0 10.10.10.3 0 100 0 65001 i
*> 10.11.0.1 0 0 65001 i
*>i172.16.1.0/24 10.10.10.1 0 100 0 65000 i
*>i172.16.2.0/24 10.10.10.1 0 100 0 65000 i
*> 192.168.1.0/24 10.11.0.1 0 0 65001 i
*>i192.168.2.0/24 10.10.10.3 0 100 0 65001 i
*> 192.168.3.0/24 10.11.0.1 0 0 65001 i
Route Distinguisher: 65001:2
*>i0.0.0.0/0 10.10.10.3 0 100 0 65001 i
*>i192.168.2.0/24 10.10.10.3 0 100 0 65001 i
Processed 10 prefixes, 11 paths
En este ejemplo, la tabla VPNv4 puede ser pequeña, pero en un entorno de producción en lugar de tener en cuenta todos los prefijos VPNv4, puede restringir la verificación hasta el RD y el prefijo específicos con el siguiente comando:
RP/0/0/CPU0:PE4#show bgp vpnv4 unicast rd 65000:1 172.16.1.10
Mon Sep 11 22:54:04.967 UTC
BGP routing table entry for 172.16.1.0/24, Route Distinguisher: 65000:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 46 46
Last Modified: Sep 8 18:28:46.314 for 3d04h
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65000
10.10.10.1 (metric 20) from 10.10.10.6 (10.10.10.1)
Received Label 16
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf
Received Path ID 0, Local Path ID 0, version 46
Extended community: RT:65000:1
Originator: 10.10.10.1, Cluster list: 10.10.10.6
En este punto, el plano de control MP-BGP tiene el prefijo de destino y las etiquetas LDP y VPNv4 {24001/16} respectivamente, la interfaz de salida para este tráfico parece ser Gi0/0/0/4 y el siguiente salto donde el tráfico debe ser reenviado es 10.10.10.1. Pero, ¿existe otra opción para verificar la interfaz de salida preferida? Es hora de echar un vistazo a la tabla de reenvío MPLS o LFIB (Base de información de reenvío de etiquetas). Con el uso del comando show mpls forwarding, se muestran dos entradas hacia el destino 10.10.10.1 (Loopback0 de PE1), una ruta con una interfaz saliente de Gi0/0/0/4 y una 10.0.0.16 (router P5) de salto siguiente donde la etiqueta saliente impuesta es 24001 y otra ruta a través de Gi0/0/0/3 con un salto siguiente 10.0.0.13 (router P6) y una etiqueta saliente de 23:
A partir de las salidas anteriores, está claro que hay dos opciones de trayecto en las que el tráfico puede equilibrarse con la carga, pero hay un par de maneras que pueden ayudar a determinar cuál es el trayecto preferido. Una forma es con el uso del comando show cef exact-route <IP de origen> <IP de destino> agregando el Loopback0 del PE de origen y el Loopback0 del PE de destino. Como se muestra en el siguiente resultado, la trayectoria preferida es a través de Gi0/0/0/4:
RP/0/0/CPU0:PE4#show cef exact-route 10.10.10.4 10.10.10.1
Mon Sep 11 23:49:44.558 UTC
10.10.10.1/32, version 39, internal 0x1000001 0x0 (ptr 0xa12dbdbc) [1], 0x0 (0xa12c18c0), 0xa28 (0xa185307c)
Updated Sep 8 20:27:26.596
local adjacency 10.0.0.16
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via GigabitEthernet0/0/0/4
via 10.0.0.16/32, GigabitEthernet0/0/0/4, 9 dependencies, weight 0, class 0 [flags 0x0] <<<<<
path-idx 1 NHID 0x0 [0xa16765bc 0x0]
next hop 10.0.0.16/32
local adjacency
local label 24010 labels imposed {24001}
Otra opción es verificar primero la LIB (Base de información de etiquetas) y obtener el enlace LDP del Loopback0 de destino (10.10.10.1 que pertenece al PE de salida) mediante el comando show mpls ldp bindings <prefix/mask>, y una vez que se encuentre la etiqueta de enlace local a partir de esa salida, utilice ese valor de etiqueta en el comando show mpls forwarding exact-route label <label> ipv4 <source IP> <destination IP> detail para encontrar la ruta preferida:
A continuación, es importante verificar el router de salto siguiente que está en el plano de datos; para este ejemplo en particular, el router a verificar es P5 (que tiene la interfaz 10.0.0.16). El primer lugar para comenzar a buscar es la tabla de reenvío MPLS, donde la etiqueta local para el prefijo 10.10.10.1 debe ser 24001:
RP/0/0/CPU0:P5#show mpls forwarding
Thu Sep 14 20:07:16.455 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Pop 10.10.10.6/32 Gi0/0/0/2 10.0.0.11 361906
24001 Pop 10.10.10.1/32 Gi0/0/0/1 10.0.0.0 361002 <<<<<
24002 Pop 10.0.0.4/31 Gi0/0/0/1 10.0.0.0 0
Pop 10.0.0.4/31 Gi0/0/0/2 10.0.0.11 0
24003 Pop 10.10.10.2/32 Gi0/0/0/0 10.0.0.6 360940
24004 Pop 10.0.0.8/31 Gi0/0/0/0 10.0.0.6 0
Pop 10.0.0.8/31 Gi0/0/0/2 10.0.0.11 0
24005 Pop 10.0.0.2/31 Gi0/0/0/0 10.0.0.6 0
Pop 10.0.0.2/31 Gi0/0/0/1 10.0.0.0 0
24006 Pop 10.10.10.4/32 Gi0/0/0/4 10.0.0.17 361230
24007 Pop 10.0.0.12/31 Gi0/0/0/2 10.0.0.11 0
Pop 10.0.0.12/31 Gi0/0/0/4 10.0.0.17 0
24008 Pop 10.10.10.3/32 Gi0/0/0/3 10.0.0.15 361346
24009 Pop 10.0.0.20/31 Gi0/0/0/3 10.0.0.15 0
Pop 10.0.0.20/31 Gi0/0/0/4 10.0.0.17 0
24010 Pop 10.0.0.18/31 Gi0/0/0/2 10.0.0.11 0
Pop 10.0.0.18/31 Gi0/0/0/3 10.0.0.15 0
RP/0/0/CPU0:P5#show mpls forwarding labels 24001
Thu Sep 14 20:07:42.584 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24001 Pop 10.10.10.1/32 Gi0/0/0/1 10.0.0.0 361060
RP/0/0/CPU0:P5#
De la salida anterior se puede ver que la entrada LFIB para el prefijo 10.10.10.1/32 muestra "Pop" como la etiqueta saliente, lo que significa que este router es el Penultimate Hop Popping (PHP). También muestra que el tráfico debe enviarse a través de Gi0/0/0/1 basado en la información de LFIB, y esto también puede verificarse mientras se observa CEF. El siguiente resultado de CEF exact-route muestra la etiqueta implícita nula como la etiqueta impuesta, esto de nuevo, se debe al hecho de que el siguiente salto conectado en Gi0/0/0/1 es el último router en la trayectoria del switch de etiqueta y también es el PE que se enfrenta al sitio de destino (CE-WEST). Esta es también la razón por la que el router P5 está eliminando y no imponiendo otra etiqueta al paquete, gracias a este proceso el router de salida PE1 va a recibir un paquete sin una etiqueta LDP:
RP/0/0/CPU0:P5#show cef exact-route 10.10.10.4 10.10.10.1
Thu Sep 14 20:25:57.269 UTC
10.10.10.1/32, version 192, internal 0x1000001 0x0 (ptr 0xa1246394) [1], 0x0 (0xa122b638), 0xa20 (0xa155b550)
Updated Sep 12 14:15:38.009
local adjacency 10.0.0.0
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via GigabitEthernet0/0/0/1
via 10.0.0.0/32, GigabitEthernet0/0/0/1, 9 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa166e280 0xa166e674]
next hop 10.0.0.0/32
local adjacency
local label 24001 labels imposed {ImplNull} <<<<<
El último punto para verificar la trayectoria del switch de etiquetas es PE1. Al observar la tabla de reenvío MPLS, se puede observar que no hay entrada para el prefijo 10.10.10.1/32 en la LFIB:
PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 No Label 172.16.1.0/24[V] 12938 Gi3 10.10.0.1
17 No Label 172.16.2.0/24[V] 0 Gi3 10.10.0.1
18 Pop Label 10.0.0.6/31 0 Gi1 10.0.0.1
Pop Label 10.0.0.6/31 0 Gi2 10.0.0.3
19 Pop Label 10.0.0.8/31 0 Gi2 10.0.0.3
Pop Label 10.0.0.8/31 0 Gi4 10.0.0.5
20 Pop Label 10.0.0.10/31 0 Gi1 10.0.0.1
Pop Label 10.0.0.10/31 0 Gi4 10.0.0.5
21 Pop Label 10.0.0.12/31 0 Gi4 10.0.0.5
22 Pop Label 10.0.0.14/31 0 Gi1 10.0.0.1
23 Pop Label 10.0.0.16/31 0 Gi1 10.0.0.1
24 Pop Label 10.0.0.18/31 0 Gi4 10.0.0.5
25 24009 10.0.0.20/31 0 Gi1 10.0.0.1
22 10.0.0.20/31 0 Gi4 10.0.0.5
26 Pop Label 10.10.10.2/32 0 Gi2 10.0.0.3
27 24008 10.10.10.3/32 0 Gi1 10.0.0.1
24 10.10.10.3/32 0 Gi4 10.0.0.5
28 24006 10.10.10.4/32 0 Gi1 10.0.0.1
25 10.10.10.4/32 0 Gi4 10.0.0.5
29 Pop Label 10.10.10.5/32 0 Gi1 10.0.0.1
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
30 Pop Label 10.10.10.6/32 0 Gi4 10.0.0.5
31 [T] Pop Label 1/1[TE-Bind] 0 drop
[T] Forwarding through a LSP tunnel.
View additional labelling info with the 'detail' option
Como ya ha descubierto, la razón de este comportamiento es que el prefijo (10.10.10.1/32) pertenece a PE1, y el router también ha asignado una etiqueta nula implícita a este prefijo conectado. Esto se puede verificar con el uso del comando show mpls ldp bindings:
PE1#show run interface loopback 0
Building configuration...
Current configuration : 66 bytes
!
interface Loopback0
ip address 10.10.10.1 255.255.255.255
end
PE1#show mpls ldp bindings 10.10.10.1 32
lib entry: 10.10.10.1/32, rev 24
local binding: label: imp-null
remote binding: lsr: 10.10.10.6:0, label: 23
remote binding: lsr: 10.10.10.5:0, label: 24001
remote binding: lsr: 10.10.10.2:0, label: 24000
Como PE1 es un router Cisco IOS XE, el uso del comando show bgp vpnv4 unicast all o show bgp vpnv4 unicast rd <value> <destination IP> puede ayudar a identificar y confirmar que el prefijo de destino 172.16.1.0/24 se aprende correctamente a través de MP-BGP. El resultado de estos comandos muestra el prefijo después de ser exportado:
PE1#show bgp vpnv4 unicast all
BGP table version is 61, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf WEST)
*>i 0.0.0.0 10.10.10.3 0 100 0 65001 i
*bi 10.10.10.4 0 100 0 65001 i
*> 172.16.1.0/24 10.10.0.1 0 0 65000 i <<<<<
*> 172.16.2.0/24 10.10.0.1 0 0 65000 i
*>i 192.168.1.0 10.10.10.4 0 100 0 65001 i
*>i 192.168.2.0 10.10.10.3 0 100 0 65001 i
*>i 192.168.3.0 10.10.10.4 0 100 0 65001 i
Route Distinguisher: 65001:1
*>i 0.0.0.0 10.10.10.4 0 100 0 65001 i
*>i 192.168.1.0 10.10.10.4 0 100 0 65001 i
*>i 192.168.3.0 10.10.10.4 0 100 0 65001 i
Route Distinguisher: 65001:2
Network Next Hop Metric LocPrf Weight Path
*>i 0.0.0.0 10.10.10.3 0 100 0 65001 i
*>i 192.168.2.0 10.10.10.3 0 100 0 65001 i
PE1#show bgp vpnv4 unicast rd 65000:1 172.16.1.10
BGP routing table entry for 65000:1:172.16.1.0/24, version 2
Paths: (1 available, best #1, table WEST)
Additional-path-install
Advertised to update-groups:
6
Refresh Epoch 2
65000
10.10.0.1 (via vrf WEST) from 10.10.0.1 (172.16.2.10) <<<<<
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65000:1 , recursive-via-connected <<<<<
mpls labels in/out 16/nolabel
rx pathid: 0, tx pathid: 0x0
Updated on Sep 15 2023 18:27:23 UTC
De manera similar, al observar el prefijo BGP VPNv4 en el VRF, que es el prefijo recibido por CE-WEST, con el uso del comando show bgp vpnv4 unicast vrf <name> <prefix>, el resultado muestra la etiqueta MP-BGP 16 que se llevó hasta el PE4 de ingreso, así como la exportación RT configurada 65000:1:
PE1#show bgp vpnv4 unicast vrf WEST 172.16.1.10
BGP routing table entry for 65000:1:172.16.1.0/24, version 2
Paths: (1 available, best #1, table WEST)
Additional-path-install
Advertised to update-groups:
6
Refresh Epoch 2
65000
10.10.0.1 (via vrf WEST) from 10.10.0.1 (172.16.2.10)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65000:1 , recursive-via-connected <<<<<
mpls labels in/out 16/nolabel <<<<<
rx pathid: 0, tx pathid: 0x0
Updated on Sep 15 2023 18:27:23 UTC
PE1#show run vrf WEST
Building configuration...
Current configuration : 478 bytes
vrf definition WEST
rd 65000:1
route-target export 65000:1 <<<<<
route-target import 65000:1
route-target import 65001:1
route-target import 65001:2
!
address-family ipv4
exit-address-family
!
!
interface GigabitEthernet3
vrf forwarding WEST
ip address 10.10.0.2 255.255.255.252
negotiation auto
no mop enabled
no mop sysid
!
router bgp 65500
!
address-family ipv4 vrf WEST
neighbor 10.10.0.1 remote-as 65000
neighbor 10.10.0.1 activate
exit-address-family
!
end
La última información que se debe verificar en este PE son las entradas RIB y CEF en el nivel VRF a la IP de destino, a diferencia de la entrada que se ve en PE4, no hay una etiqueta en el RIB para el prefijo 172.16.1.0/24, la razón es que esta es la ruta que entra desde el CE y esto se aprende a través de eBGP y se inserta en la tabla de ruteo VRF antes de que este prefijo se exporte a VPNv4. Esto se puede verificar con el uso de los comandos show ip route vrf <name> <prefix> y show ip cef vrf <name> <prefix> que se muestran a continuación:
PE1#show ip route vrf WEST 172.16.1.10
Routing Table: WEST
Routing entry for 172.16.1.0/24
Known via "bgp 65500", distance 20, metric 0
Tag 65000, type external
Last update from 10.10.0.1 1w0d ago
Routing Descriptor Blocks:
* 10.10.0.1, from 10.10.0.1, 1w0d ago, recursive-via-conn
opaque_ptr 0x7F8B4E3E1D50
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65000
MPLS label: none
PE1#show ip cef vrf WEST 172.16.1.10
172.16.1.0/24
nexthop 10.10.0.1 GigabitEthernet3
En este punto, se ha confirmado que el prefijo de destino 172.16.1.0/24 fue aprendido correctamente por el origen del CE de tráfico (CE-EAST), se propagó correctamente a través de MP-BGP y también se aprendieron las etiquetas de los loopbacks PE y Ps a través de la trayectoria del switch de etiquetas. Sin embargo, la accesibilidad entre el origen y el destino no es satisfactoria, y todavía hay un último router para verificar CE-WEST. Lo primero que se debe verificar en este router es la tabla de ruteo, recuerde que se espera que el prefijo IP de origen 192.168.1.0/24 aparezca allí:
CE-WEST#show ip route 192.168.1.10% Network not in table CE-WEST#
La "Red no en la tabla" es claramente el problema, la tabla BGP también se puede verificar pero después de buscar el prefijo tampoco está allí:
CE-WEST#show ip bgp
BGP table version is 41, local router ID is 172.16.2.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/24 0.0.0.0 0 32768 i
CE-WEST#
Dando un paso atrás, puede verificar si este router de borde del proveedor (PE1) está anunciando el prefijo al vecino eBGP CE-WEST. Esto se puede hacer con el comando show bgp vpnv4 unicast vrf <name> neighbors <neighbor IP> advertised-routes que se muestra a continuación:
PE1#show bgp vpnv4 unicast vrf WEST neighbors 10.10.0.1 advertised-routes
BGP table version is 61, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65000:1 (default for vrf WEST)
*>i 0.0.0.0 10.10.10.3 0 100 0 65001 i
*>i 192.168.1.0 10.10.10.4 0 100 0 65001 i <<<<<
*>i 192.168.2.0 10.10.10.3 0 100 0 65001 i
*>i 192.168.3.0 10.10.10.4 0 100 0 65001 i
Total number of prefixes 4
Según el paso anterior, se puede confirmar que el router PE1 está anunciando el prefijo correctamente a CE-WEST, por lo tanto, es hora de mirar a los vecinos BGP en el lado CE:
CE-WEST#show ip bgp neighbors
BGP neighbor is 10.10.0.2, remote AS 65500, external link
BGP version 4, remote router ID 10.10.10.1
BGP state = Established, up for 1w4d
Last read 00:00:40, last write 00:00:43, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 3 17
Keepalives: 19021 18997
Route Refresh: 2 0
Total: 19029 19019
Do log neighbor state changes (via global configuration)
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
Session: 10.10.0.2
BGP table version 41, neighbor version 41/0
Output queue size : 0
Index 3, Advertise bit 0
3 update-group member
Inbound path policy configured
Route map for incoming advertisements is FILTER <<<<<
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 2 0
Prefixes Total: 4 23
Implicit Withdraw: 2 13
Explicit Withdraw: 0 10
Used as bestpath: n/a 0
Used as multipath: n/a 0
Used as secondary: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
route-map: 0 4
Bestpath from this peer: 18 n/a
Total: 18 4
Number of NLRIs in the update sent: max 2, min 0
Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 3
Last Sent Refresh Start-of-rib: 4d23h
Last Sent Refresh End-of-rib: 4d23h
Refresh-Out took 0 seconds
Last Received Refresh Start-of-rib: 4d23h
Last Received Refresh End-of-rib: 4d23h
Refresh-In took 0 seconds
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 1 2
Refresh End-of-RIB 1 2
Address tracking is enabled, the RIB does have a route to 10.10.0.2
Route to peer address reachability Up: 1; Down: 0
Last notification 1w5d
Connections established 3; dropped 2
Last reset 1w4d, due to Peer closed the session of session 1
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
Interface associated: GigabitEthernet0/3 (peering address in same link)
Transport(tcp) path-mtu-discovery is enabled
Graceful-Restart is disabled
SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.10.0.1, Local port: 179
Foreign host: 10.10.0.2, Foreign port: 39410
Connection tableid (VRF): 0
Maximum output segment queue size: 50
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x4D15FD56):
Timer Starts Wakeups Next
Retrans 19027 1 0x0
TimeWait 0 0 0x0
AckHold 19012 18693 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 1676751051 snduna: 1677112739 sndnxt: 1677112739
irs: 2109012892 rcvnxt: 2109374776
sndwnd: 16061 scale: 0 maxrcvwnd: 16384
rcvwnd: 15890 scale: 0 delrcvwnd: 494
SRTT: 1000 ms, RTTO: 1003 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 1036662542 ms, Sent idletime: 40725 ms, Receive idletime: 40925 ms
Status Flags: passive open, gen tcbs
Option Flags: nagle, path mtu capable
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 37957 (out of order: 0), with data: 19014, total data bytes: 361883
Sent: 37971 (retransmit: 1, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 19027, total data bytes: 361687
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
TCP Semaphore 0x0F3194AC FREE
La salida anterior revela que hay un route map aplicado para los anuncios entrantes con el nombre "FILTER", después de observar la configuración del route map muestra una cláusula match que señala a una lista de prefijos con una sentencia permit para 192.168.0.0/16, sin embargo esto es incorrecto ya que el prefix-list sólo permite ese prefijo específico y no todos los que se pueden incluir en este rango:
CE-WEST#show route-map FILTER
route-map FILTER, permit, sequence 10
Match clauses:
ip address prefix-lists: FILTER
Set clauses:
Policy routing matches: 0 packets, 0 bytes
CE-WEST#show ip prefix-list FILTER
ip prefix-list FILTER: 1 entries
seq 5 permit 192.168.0.0/16 <<<<<
CE-WEST#show run | i ip prefix-list
ip prefix-list FILTER seq 5 permit 192.168.0.0/16
Con un pequeño cambio en la configuración de la lista de prefijos, la ruta hacia 192.168.1.10 se instala ahora en el RIB:
CE-WEST#show run | i ip prefix-listip prefix-list FILTER seq 5 permit 192.168.0.0/16 le 32 <<<<<
CE-WEST#show ip bgp
BGP table version is 44, local router ID is 172.16.2.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/24 0.0.0.0 0 32768 i
*> 192.168.1.0 10.10.0.2 0 65500 65001 i <<<<<
*> 192.168.2.0 10.10.0.2 0 65500 65001 i
*> 192.168.3.0 10.10.0.2 0 65500 65001 i
CE-WEST#show ip route 192.168.1.10Routing entry for 192.168.1.0/24 <<<<<
Known via "bgp 65000", distance 20, metric 0
Tag 65500, type external
Last update from 10.10.0.2 00:00:37 ago
Routing Descriptor Blocks:
* 10.10.0.2, from 10.10.0.2, 00:00:37 ago
Route metric is 0, traffic share count is 1
AS Hops 2
Route tag 65500
MPLS label: none
Verificación
Ahora, el alcance entre el origen y el destino es exitoso y se puede confirmar que el traceroute pasa por la misma trayectoria de switch de etiqueta que se rastreó a través de la red MPLS:
Ruta de reenvío
CE-EAST#ping 172.16.1.10 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.10
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/7/9 ms <<<<<
CE-EAST#traceroute 172.16.1.10 source loop1 probe 1 numeric
Type escape sequence to abort.
Tracing the route to 172.16.1.10
VRF info: (vrf in name/id, vrf out name/id)
1 10.11.0.2 2 msec
2 10.0.0.16 [MPLS: Labels 24001/16 Exp 0] 9 msec
3 10.10.0.2 [MPLS: Label 16 Exp 0] 8 msec
4 10.10.0.1 9 msec
RP/0/0/CPU0:P5#show ipv4 interface brief
Wed Sep 20 18:23:47.158 UTC
Interface IP-Address Status Protocol Vrf-Name
Loopback0 10.10.10.5 Up Up default
MgmtEth0/0/CPU0/0 unassigned Shutdown Down default
GigabitEthernet0/0/0/0 10.0.0.7 Up Up default
GigabitEthernet0/0/0/1 10.0.0.1 Up Up default <<<<<
GigabitEthernet0/0/0/2 10.0.0.10 Up Up default
GigabitEthernet0/0/0/3 10.0.0.14 Up Up default
GigabitEthernet0/0/0/4 10.0.0.16 Up Up default <<<<<
RP/0/0/CPU0:P5#
Comandos de verificación de Cisco IOS XE
MPLS/LDP
show mpls interfaces
show mpls forwarding-table
show mpls ldp bindings [destination prefix]
show mpls ldp neighbor [neighbor address]
clear mpls ldp neighbor [neighbor address|*]
RIB and CEF show ip vrf [detail]
show run vrf
show ip route [destination prefix]
show ip route vrf
[destination prefix] show ip cef vrf
[destination prefix] show ip cef exact-route
show ip cef vrf
exact-route
BGP/VPNv4 show ip bgp [neighbors]
show bgp vpnv4 unicast all [summary|destination prefix] show bgp vpnv4 unicast all neighbor
advertised-routes show bgp vpnv4 unicast vrf
neighbors
advertised-routes show bgp vpnv4 unicast vrf
show bgp vpnv4 unicast rd
Comandos de verificación de Cisco IOS XR
MPLS/LDP show mpls interfaces
show mpls forwarding
show mpls ldp bindings [destination prefix/mask]
show mpls ldp neighbor [neighbor address]
show mpls forwarding prefix [destination prefix/mask]
show mpls forwarding prefix [destination prefix/mask] detail hardware egress
clear mpls ldp neighbor [neighbor address]
RIB and CEF show vrf [name|all]
show run vrf [name]
show route [destination prefix]
show route vrf
[destination prefix] show cef vrf
[destination prefix] show cef exact-route
show cef vrf
exact-route
BGP/VPNv4 show bgp vpnv4 unicast [summary|destination prefix/mask] show bgp vpnv4 unicast neighbors
advertised-routes show bgp vpnv4 unicast vrf
[prefix] show bgp vrf
neighbors
advertised-routes show bgp vpnv4 unicast rd [value|all] [destination IP]
Diagrama de Topología MPLS
Ruta de reenvío
Comentarios