Comprensión de BGP Dynamic Segment Routing Traffic Engineering
Contenido
Introducción
Este documento describe cómo entender, configurar y verificar la función BGP Dynamic Segment Routing Traffic Engineering (SR-TE) en Cisco IOS® XR.
Prerequisites
No hay requisitos previos para este documento.
Requirements
No hay requisitos específicos para este documento.
Componentes Utilizados
La información de este documento se basa en Cisco IOS XR y 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
SR-TE proporciona las capacidades para dirigir el tráfico a través de un núcleo habilitado para SR sin creación y mantenimiento de estado (sin estado). Una directiva SR-TE se expresa como una lista de segmentos que especifica una ruta de acceso, denominada lista de Id. de segmento (SID). No se requiere señalización ya que el estado está en el paquete y los routers de tránsito procesan la lista de SID como un conjunto de instrucciones.
Con el protocolo de gateway fronterizo dinámico (BGP) SR-TE puede generar políticas de SR-TE automáticas basadas en criterios arbitrarios, como las comunidades señaladas por un router que participa en una red de routing de segmento. Para poder cumplir los SLA (del inglés Service Level Assurance, garantía de nivel de servicio) de las aplicaciones del sitio y las rutas de cálculo basadas en requisitos específicos, puede generar políticas SR-TE automáticas para una subred o servicios IP determinados estableciendo comunidades y activando estas políticas .
Una aplicación común para esta función es en entornos MPLS L3VPN, donde el administrador de red puede activar políticas de túnel SR-TE automáticas para enrutar el tráfico según restricciones específicas (retraso, ancho de banda, etc.). Para las demostraciones de este documento, creamos un servicio L3VPN que conecta XR1 y XR5 y activa túneles automáticos en XR2 (cabecera) basándose en una comunidad determinada establecida en XR4 (cola) en MP-BGP.
Configurar
Diagrama de la red
Configuraciones iniciales
Se han habilitado las configuraciones básicas L3VPN, Segment Routing y SR-TE.
XR1 hostname XR1 logging console debugging interface Loopback0 ipv4 address 10.0.1.1 255.255.255.255 ! interface GigabitEthernet0/0/0/0.12 ipv4 address 192.0.2.1 255.255.255.0 encapsulation dot1q 12 ! route-policy PASS pass end-policy ! router bgp 100 bgp router-id 10.0.1.1 address-family ipv4 unicast network 10.0.1.1/32 ! neighbor 192.0.2.7 remote-as 200 address-family ipv4 unicast route-policy PASS in route-policy PASS out ! ! ! end
XR2
hostname XR2 logging console debugging vrf BLUE address-family ipv4 unicast import route-target 1:1 ! export route-target 1:1 ! ! ! interface Loopback0 ipv4 address 10.0.2.2 255.255.255.255 ! interface GigabitEthernet0/0/0/0.12 vrf BLUE ipv4 address 192.0.2.7 255.255.255.0 encapsulation dot1q 12 ! interface GigabitEthernet0/0/0/0.23 ipv4 address 192.0.2.8 255.255.255.0 encapsulation dot1q 23 ! interface GigabitEthernet0/0/0/0.26 ipv4 address 192.0.2.9 255.255.255.0 encapsulation dot1q 26 ! route-policy PASS pass end-policy ! ! router ospf 1 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 2 ! interface GigabitEthernet0/0/0/0.23 cost 100 network point-to-point ! interface GigabitEthernet0/0/0/0.26 cost 200 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! router bgp 100 bgp router-id 10.0.2.2 address-family vpnv4 unicast ! neighbor 10.0.4.4 remote-as 200 update-source Loopback0 address-family vpnv4 unicast ! ! vrf BLUE rd 1:1 address-family ipv4 unicast ! neighbor 192.0.2.10 remote-as 200 address-family ipv4 unicast route-policy PASS in route-policy PASS out as-override ! ! ! ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.23 admin-weight 100 ! interface GigabitEthernet0/0/0/0.26 admin-weight 1 ! ! end
XR3
hostname XR3 logging console debugging interface Loopback0 ipv4 address 10.0.3.3 255.255.255.255 ! ! interface GigabitEthernet0/0/0/0.23 ipv4 address 192.0.2.11 255.255.255.0 encapsulation dot1q 23 ! interface GigabitEthernet0/0/0/0.34 ipv4 address 192.0.2.12 255.255.255.0 encapsulation dot1q 34 ! router ospf 1 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 3 ! interface GigabitEthernet0/0/0/0.23 cost 100 network point-to-point ! interface GigabitEthernet0/0/0/0.34 cost 100 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.23 admin-weight 100 ! interface GigabitEthernet0/0/0/0.34 admin-weight 100 ! ! end
XR4
hostname XR4 logging console debugging vrf BLUE address-family ipv4 unicast import route-target 1:1 ! export route-target 1:1 ! ! ! interface Loopback0 ipv4 address 10.0.4.4 255.255.255.255 ! interface GigabitEthernet0/0/0/0.34 ipv4 address 192.0.2.13 255.255.255.0 encapsulation dot1q 34 ! interface GigabitEthernet0/0/0/0.45 vrf BLUE ipv4 address 192.0.2.14 255.255.255.0 encapsulation dot1q 45 ! interface GigabitEthernet0/0/0/0.46 ipv4 address 192.0.2.15 255.255.255.0 encapsulation dot1q 46 ! route-policy PASS pass end-policy ! ! router ospf 1 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 4 ! interface GigabitEthernet0/0/0/0.34 cost 100 network point-to-point ! interface GigabitEthernet0/0/0/0.46 cost 200 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! router bgp 100 bgp router-id 10.0.4.4 address-family vpnv4 unicast ! neighbor 10.0.2.2 remote-as 200 update-source Loopback0 address-family vpnv4 unicast ! ! vrf BLUE rd 1:1 bgp unsafe-ebgp-policy address-family ipv4 unicast ! neighbor 192.0.2.16 remote-as 200 address-family ipv4 unicast route-policy PASS in route-policy PASS out as-override ! ! ! ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.34 admin-weight 100 ! interface GigabitEthernet0/0/0/0.46 admin-weight 1 ! ! end
XR5 hostname XR5 logging console debugging interface Loopback0
description REGULAR LSP PATH ipv4 address 10.0.5.5 255.255.255.255 ! interface Loopback1
description DELAY SENSITIVE - LOW LATENCY PATH (1:1) ipv4 address 10.0.5.55 255.255.255.255 ! interface GigabitEthernet0/0/0/0.45 ipv4 address 192.0.2.16 255.255.255.0 encapsulation dot1q 45 ! route-policy PASS pass end-policy ! router bgp 100 bgp router-id 10.0.5.5 bgp unsafe-ebgp-policy address-family ipv4 unicast network 10.0.5.5/32 network 10.0.5.55/32 ! neighbor 192.0.2.14 remote-as 200 address-family ipv4 unicast route-policy PASS in route-policy PASS out ! ! ! mpls oam ! end
XR6
hostname XR6 logging console debugging interface Loopback0 ipv4 address 10.0.6.6 255.255.255.255 ! interface GigabitEthernet0/0/0/0.26 ipv4 address 192.0.2.17 255.255.255.0 encapsulation dot1q 26 ! interface GigabitEthernet0/0/0/0.46 ipv4 address 192.0.2.18 255.255.255.0 encapsulation dot1q 46 ! router ospf 1 segment-routing mpls segment-routing forwarding mpls segment-routing sr-prefer address-family ipv4 area 0 mpls traffic-eng interface Loopback0 prefix-sid index 6 ! interface GigabitEthernet0/0/0/0.26 cost 200 network point-to-point ! interface GigabitEthernet0/0/0/0.46 cost 200 network point-to-point ! ! mpls traffic-eng router-id Loopback0 ! mpls oam ! mpls traffic-eng interface GigabitEthernet0/0/0/0.26 admin-weight 1 ! interface GigabitEthernet0/0/0/0.46 admin-weight 1 ! ! end
XR2 y XR4 (PE) han creado un LSP mediante el routing de segmentos, que se puede verificar mediante el ping MPLS para la FEC de routing de segmentos correspondiente. Para este escenario, hay dos rutas posibles para transportar el tráfico L3VPN de XR1 a XR5:
Trayectoria LSP regular: XR1 > XR2 > XR3 > XR4 > XR5
Trayectoria LSP de baja latencia: XR1 > XR2 >XR6 > XR4 > XR5
Inicialmente, todo el tráfico entre XR1 y XR5 se rutea a través de XR3 a través de la ruta LSP normal debido a un menor coste de IGP, podemos confirmar tanto los LSP como la conectividad según estas verificaciones. El coste de IGP para llegar a XR4 desde XR2 mediante XR3 es de 201 frente a 401 mediante XR6. Aunque la trayectoria a través de XR3 tiene una mejor métrica de trayectoria, los servicios de baja latencia en VRF BLUE se deben rutear a través de la trayectoria a través de XR6.
RP/0/0/CPU0:XR2#ping mpls ipv4 10.0.4.4/32 fec-type generic verbose
Sending 5, 100-byte MPLS Echos to 10.0.4.4/32,
timeout is 2 seconds, send interval is 0 msec:
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.
! size 100, reply addr 192.0.2.13, return code 3
! size 100, reply addr 192.0.2.13, return code 3
! size 100, reply addr 192.0.2.13, return code 3
! size 100, reply addr 192.0.2.13, return code 3
! size 100, reply addr 192.0.2.13, return code 3
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
Si verifica los servicios L3VPN en XR1, puede confirmar la disponibilidad al loopback XR5 10.0.5.5/32 y 10.0.5.55/32 respectivamente a través de la trayectoria LSP regular. Los servicios L3VPN básicos están habilitados en el núcleo SR MPLS.
RP/0/0/CPU0:XR1#ping 10.0.5.5 source 10.0.1.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.5.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/9 ms RP/0/0/CPU0:XR1#ping 10.0.5.55 source 10.0.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.5.55, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/9 ms RP/0/0/CPU0:XR1#traceroute 10.0.5.5 source 10.0.1.1 Type escape sequence to abort. Tracing the route to 10.0.5.5 1 192.0.2.7 9 msec 0 msec 0 msec 2 192.0.2.11 [MPLS: Labels 16004/24002 Exp 0] 0 msec 0 msec 0 msec 3 192.0.2.13 [MPLS: Label 24002 Exp 0] 0 msec 0 msec 0 msec 4 192.0.2.16 0 msec * 0 msec RP/0/0/CPU0:XR1#traceroute 10.0.5.55 source 10.0.1.1 Type escape sequence to abort. Tracing the route to 10.0.5.55 1 192.0.2.7 9 msec 0 msec 0 msec 2 192.0.2.11 [MPLS: Labels 16004/24005 Exp 0] 0 msec 0 msec 0 msec 3 192.0.2.13 [MPLS: Label 24005 Exp 0] 0 msec 0 msec 0 msec 4 192.0.2.16 0 msec * 0 msec
Como se observó, todo el tráfico en VRF BLUE pasa por la trayectoria LSP regular XR1 > XR2 > XR3 > XR4 > XR5.
Configuración de BGP Dynamic SR-TE
Para este ejemplo, configure XR4 (extremo final) para insertar la comunidad 1:1 y enviarla a XR2 para indicar la creación de una política SR-TE para el prefijo 10.0.5.55/32 en VRF BLUE. La selección de la trayectoria de política SR-TE se configurará para tomar la trayectoria de baja latencia en lugar de la LSP regular. Para ello, seleccione la métrica TE más baja (peso de administrador) mediante XR6. La métrica TE total (peso de administración) a través de XR6 es 2, ya que los pesos de administración se han configurado en 1 en las interfaces salientes hacia XR4 (extremo final) a través de XR6, como se observa en el diagrama de topología de referencia y las configuraciones iniciales.
Para crear las políticas dinámicas de SR-TE, necesitamos configurar qué loopback se utilizará como origen y cuál es el rango de túnel dinámico que utilizará la cabecera para generar los túneles. Esta configuración es necesaria en la cabecera de la política de SR-TE XR2. Establezca el rango de túnel en un mínimo de 500 y un máximo de 500, creando eficazmente un solo túnel SR-TE y el loopback de origen en loopback 0 en la cabecera del túnel.
XR2 ipv4 unnumbered mpls traffic-eng Loopback0 mpls traffic-eng auto-tunnel p2p tunnel-id min 500 max 500 ! ! end
En XR4, establezca la comunidad 1:1 y aplíquela en el prefijo VRF BLUE 10.0.5.55/32, esto le permitirá insertar la comunidad en la actualización de BGP.
XR4
route-policy COMMUNITY_1:1
# 1:1 Community
if destination in (10.0.5.55/32) then
set community (1:1)
endif
pass
end-policy
!
router bgp 100
vrf BLUE
!
neighbor 192.0.2.16
address-family ipv4 unicast
route-policy COMMUNITY_1:1 in
!
!
end
Comprobando XR2 (headend) podemos ver que tiene la comunidad 1:1 configurada en las actualizaciones de VPNv4 recibidas desde XR4.
RP/0/0/CPU0:XR2#show bgp vrf BLUE 10.0.5.55/32 detail
BGP routing table entry for 10.0.5.55/32, Route Distinguisher: 1:1 Versions: Process bRIB/RIB SendTblVer Speaker 36 36 Flags: 0x00043001+0x00000200; Last Modified: Nov 23 17:50:59.798 for 00:02:53 Paths: (1 available, best #1) Advertised to CE peers (in unique update groups): 192.0.2.10 Path #1: Received by speaker 0 Flags: 0x4000000085060005, import: 0x9f Advertised to CE peers (in unique update groups): 192.0.2.10 200 10.0.4.4 (metric 201) from 10.0.4.4 (10.0.4.4) Received Label 24005 Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported Received Path ID 0, Local Path ID 0, version 36 Community: 1:1 Extended community: RT:1:1 Source AFI: VPNv4 Unicast, Source VRF: BLUE, Source Route Distinguisher: 1:1
En XR2 (cabecera), cree una política de ruta RPL que coincida con la comunidad 1:1 y establezca el conjunto de atributos correspondiente para la ingeniería de tráfico MPLS. Después de establecer la política, podemos ir a la stanza de configuración MPLS-TE y establecer el conjunto de atributos correspondiente para la política SR-TE e indicar cuáles son los criterios de selección de trayectoria, que son Segment Routing y la métrica TE en este caso, ya que queremos elegir la trayectoria a través del peso administrativo más bajo a través de XR6.
XR2
route-policy DYN_BGP_SR-TE
# Matches community 1:1
if community matches-every (1:1) then
set mpls traffic-eng attributeset DYN_SR-TE_POLICIES
endif
pass
end-policy
!
router bgp 100
!
neighbor 10.0.4.4
address-family vpnv4 unicast
route-policy DYN_BGP_SR-TE in
!
mpls traffic-eng
attribute-set p2p-te DYN_SR-TE_POLICIES
path-selection
metric te
segment-routing adjacency unprotected
!
end
Verificación
Una vez completada, puede observar que la interfaz tunnel-te 500 se ha creado dinámicamente para el rango especificado.
RP/0/0/CPU0:XR2#show mpls traffic-eng tunnels segment-routing tabular
Tunnel LSP Destination Source Tun FRR LSP Path
Name ID Address Address State State Role Prot
----------------- ----- --------------- --------------- ------ ------ ---- -----
^tunnel-te500 2 10.0.4.4 10.0.2.2 up Inact Head Inact
^ = automatically created P2P/P2MP tunnel
BGP RIB indica que la política "DYN_SR-TE_POLICIES" está conectada al prefijo, lo que significa que el tráfico debe enrutarse según la política.
RP/0/0/CPU0:XR2#show bgp vrf BLUE
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 (default for vrf BLUE) *> 10.0.1.1/32 192.0.2.10 0 0 200 i *>i10.0.5.5/32 10.0.4.4 0 100 0 200 i *>i10.0.5.55/32 10.0.4.4 T:DYN_SR-TE_POLICIES 0 100 0 200 i
Si verificamos el BGP RIB para el prefijo 10.0.5.55/32 detalladamente, podemos ver la información del plano de control a la que se hará referencia para generar el túnel SR-TE.
RP/0/0/CPU0:XR2#show bgp vrf BLUE 10.0.5.55/32 detail
BGP routing table entry for 10.0.5.55/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 39 39
Flags: 0x00041001+0x00000200;
Last Modified: Nov 23 17:55:22.798 for 00:04:43
Paths: (1 available, best #1)
Advertised to CE peers (in unique update groups):
192.0.2.10
Path #1: Received by speaker 0
Flags: 0x4000000085060005, import: 0x9f
Advertised to CE peers (in unique update groups):
192.0.2.10
200
10.0.4.4 T:DYN_SR-TE_POLICIES (metric 201) from 10.0.4.4 (10.0.4.4)
Received Label 24005
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 0, version 39
Community: 1:1
Extended community: RT:1:1
TE tunnel attribute-set DYN_SR-TE_POLICIES, up, registered, binding-label 24000, if-handle 0x00000130
Source AFI: VPNv4 Unicast, Source VRF: BLUE, Source Route Distinguisher: 1:1
Podemos ver que la política de túnel está en estado activo y registrada. El SID de enlace asignado es 24000. Este SID de enlace se puede utilizar para verificar qué túnel se utiliza para este prefijo en particular. Como se observó anteriormente, tunnel-te500 se creó e instaló en el LFIB.
RP/0/0/CPU0:XR2#show mpls forwarding labels 24000 detail
Local Outgoing Prefix Outgoing Next Hop Bytes Label Label or ID Interface Switched ------ ----------- ------------------ ------------ --------------- ------------ 24000 Pop No ID tt500 point2point 0 Updated: Nov 23 17:55:23.267 Label Stack (Top -> Bottom): { } MAC/Encaps: 0/0, MTU: 0 Packets Switched: 0
Alternativamente, puede utilizar el if-handle 0x00000130 de la salida de BGP RIB para verificar la política SR-TE asignada para el prefijo 10.0.5.55/32.
RP/0/0/CPU0:XR2#show mpls forwarding tunnels ifh 0x00000130 detail
Tunnel Outgoing Outgoing Next Hop Bytes Name Label Interface Switched ------------- ----------- ------------ --------------- ------------ tt500 (SR) 24003 Gi0/0/0/0.26 192.0.2.17 0 Updated: Nov 23 17:55:23.267 Version: 138, Priority: 2 Label Stack (Top -> Bottom): { 24003 } NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0 MAC/Encaps: 18/22, MTU: 1500 Packets Switched: 0 Interface Name: tunnel-te500, Interface Handle: 0x00000130, Local Label: 24001 Forwarding Class: 0, Weight: 0 Packets/Bytes Switched: 0/0
La política SR-TE en XR2 (cabecera) tendrá estas propiedades desde una perspectiva de plano de control y plano de datos para reenviar el tráfico. También la información de estado del túnel SR-TE se puede ver según la salida, que debe coincidir con las verificaciones anteriores.
RP/0/0/CPU0:XR2#show mpls traffic-eng tunnels segment-routing p2p 500
Name: tunnel-te500 Destination: 10.0.4.4 Ifhandle:0x130 (auto-tunnel for BGP default)
Signalled-Name: auto_XR2_t500
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, (Segment-Routing) type dynamic (Basis for Setup, path weight 2)
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 0 kbps CT0
Creation Time: Fri Nov 23 17:55:23 2018 (00:09:01 ago)
Config Parameters:
Bandwidth: 0 kbps (CT0) Priority: 7 7 Affinity: 0x0/0x0
Metric Type: TE (interface)
Path Selection:
Tiebreaker: Min-fill (default)
Protection: Unprotected Adjacency
Hop-limit: disabled
Cost-limit: disabled
Path-invalidation timeout: 10000 msec (default), Action: Tear (default)
AutoRoute: disabled LockDown: disabled Policy class: not set
Forward class: 0 (default)
Forwarding-Adjacency: disabled
Autoroute Destinations: 0
Loadshare: 0 equal loadshares
Auto-bw: disabled
Path Protection: Not Enabled
Attribute-set: DYN_SR-TE_POLICIES (type p2p-te)
BFD Fast Detection: Disabled
Reoptimization after affinity failure: Enabled
SRLG discovery: Disabled
History:
Tunnel has been up for: 00:09:01 (since Fri Nov 23 17:55:23 UTC 2018)
Current LSP:
Uptime: 00:09:01 (since Fri Nov 23 17:55:23 UTC 2018)
Reopt. LSP:
Last Failure:
LSP not signalled, identical to the [CURRENT] LSP
Date/Time: Fri Nov 23 17:56:53 UTC 2018 [00:07:31 ago]
Segment-Routing Path Info (OSPF 1 area 0)
Segment0[Link]: 192.0.2.9 - 192.0.2.17, Label: 24005
Segment1[Link]: 192.0.2.18 - 192.0.2.15, Label: 24003
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 1 up, 0 down, 0 recovering, 0 recovered heads
Verifique el prefijo directamente en VRF BLUE RIB, podemos confirmar que el SID 24000 de enlace fue asignado al prefijo.
RP/0/0/CPU0:XR2#show route vrf BLUE 10.0.5.55/32 detail
Routing entry for 10.0.5.55/32 Known via "bgp 100", distance 200, metric 0 Tag 200, type internal Installed Nov 23 17:55:23.267 for 00:10:38 Routing Descriptor Blocks 10.0.4.4, from 10.0.4.4 Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000 Route metric is 0 Label: 0x5dc5 (24005) Tunnel ID: None Binding Label: 0x5dc0 (24000) Extended communities count: 0 Source RD attributes: 0x0000:1: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 27 No advertising protos.
FIB para VRF BLUE indica que el reenvío para este prefijo se realiza a través del túnel-te 500 de acuerdo con nuestra política dinámica de BGP SR-TE.
RP/0/0/CPU0:XR2#show cef vrf BLUE 10.0.5.55/32 detail
10.0.5.55/32, version 27, internal 0x1000001 0x0 (ptr 0xa142a574) [1], 0x0 (0x0), 0x208 (0xa159d208) Updated Nov 23 17:55:23.287 Prefix Len 32, traffic index 0, precedence n/a, priority 3 gateway array (0xa129f23c) reference count 1, flags 0x4038, source rib (7), 0 backups [1 type 1 flags 0x48441 (0xa15b780c) ext 0x0 (0x0)] LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0] gateway array update type-time 1 Nov 23 17:55:23.287 LDI Update time Nov 23 17:55:23.287 via local-label 24000, 3 dependencies, recursive [flags 0x6000] path-idx 0 NHID 0x0 [0xa1605bf4 0x0] recursion-via-label next hop VRF - 'default', table - 0xe0000000 next hop via 24000/0/21 next hop tt500 labels imposed {ImplNull 24005} Load distribution: 0 (refcount 1) Hash OK Interface Address 0 Y Unknown 24000/0
En el XR1 podemos verificar la conectividad y confirmar que el tráfico pasa a través del túnel TE 500 a través de una ruta de baja latencia a través del XR6.
RP/0/0/CPU0:XR1#traceroute 10.0.5.55 source 10.0.1.1 Type escape sequence to abort. Tracing the route to 10.0.5.55 1 192.0.2.7 0 msec 0 msec 0 msec 2 192.0.2.17 [MPLS: Labels 24003/24005 Exp 0] 0 msec 0 msec 0 msec 3 192.0.2.15 [MPLS: Label 24005 Exp 0] 0 msec 0 msec 0 msec 4 192.0.2.16 0 msec * 9 msec
Los contadores XR2 aumentan para el túnel te500, que corresponde a nuestra política SR-TE.
RP/0/0/CPU0:XR2#show mpls forwarding tunnels Tunnel Outgoing Outgoing Next Hop Bytes Name Label Interface Switched ------------- ----------- ------------ --------------- ------------ tt500 (SR) 24003 Gi0/0/0/0.26 192.0.2.17 2250
La trayectoria para el prefijo 10.0.5.5/32 aún está atravesando la trayectoria LSP regular a través de XR3, como se ve a continuación.
RP/0/0/CPU0:XR1#traceroute 10.0.5.5 source 10.0.1.1 Type escape sequence to abort. Tracing the route to 10.0.5.5 1 192.0.2.7 0 msec 0 msec 0 msec 2 192.0.2.11 [MPLS: Labels 16004/24002 Exp 0] 0 msec 0 msec 0 msec 3 192.0.2.13 [MPLS: Label 24002 Exp 0] 0 msec 0 msec 0 msec 4 192.0.2.16 0 msec * 0 msec
Troubleshoot
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Summary
BGP Dynamic SR-TE ofrece granularidad y aplicación automática de políticas de ruteo para el propósito de ingeniería de tráfico en el núcleo habilitado para SR. La creación automática de túneles se puede activar según criterios arbitrarios, lo que permite a los administradores de red crear fácilmente patrones de tráfico que cumplan los requisitos de aplicación del sitio.
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
2.0 |
19-Oct-2022 |
Documento alineado con RFC 1918, 5737 y 6761 |
1.0 |
28-Nov-2018 |
Versión inicial |
Comentarios