Comprendre l’ingénierie du trafic de routage de segment dynamique BGP
Contenu
Introduction
Ce document décrit les aspects de la compréhension, de la configuration et de la vérification de la fonctionnalité d'ingénierie de trafic de routage de segment dynamique (SR-TE) du protocole BGP (Border Gateway Protocol) dans Cisco IOS® XR.
Conditions préalables
Il n'y a aucune condition requise pour ce document.
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Les informations de ce document sont basées sur Cisco IOS XR et Cisco IOS XE.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Informations générales
SR-TE fournit les fonctionnalités permettant d'acheminer le trafic via un noyau SR sans création et maintenance d'état (sans état). Une stratégie SR-TE est exprimée sous la forme d'une liste de segments qui spécifie un chemin, appelé liste SID (Segment ID). Aucune signalisation n'est requise car l'état est dans le paquet et la liste SID est traitée comme un ensemble d'instructions par les routeurs de transit.
Avec Dynamic BGP SR-TE, vous pouvez générer des stratégies SR-TE automatiques basées sur des critères arbitraires tels que les communautés signées par un routeur participant à un réseau de routage de segment. Afin de pouvoir satisfaire aux SLA (Service Level Assurance) des applications du client et des chemins de calcul basés sur des exigences spécifiques, vous pouvez générer des stratégies SR-TE automatiques pour un ou plusieurs sous-réseaux IP donnés en définissant des communautés et en déclenchant ces stratégies en conséquence.
Une application courante pour cette fonctionnalité est dans les environnements MPLS L3VPN, où l'administrateur réseau peut déclencher des politiques de tunnel SR-TE automatiques pour acheminer le trafic en fonction de contraintes spécifiques (délai, bande passante, etc.). Pour les démonstrations de ce document, nous allons créer un service L3VPN connectant XR1 et XR5 et déclencher des tunnels automatiques sur XR2 (tête de réseau) en fonction d'une communauté particulière définie sur XR4 (extrémité arrière) sur MP-BGP.
Configuration
Diagramme du réseau
Paramètres de configuration initiaux
Les configurations de base L3VPN, Segment Routing et SR-TE ont été activées.
XR1 hostname XR1 logging console debugging interface Loopback0 ipv4 address 1.1.1.1 255.255.255.255 ! interface GigabitEthernet0/0/0/0.12 ipv4 address 12.0.0.1 255.255.255.0 encapsulation dot1q 12 ! route-policy PASS pass end-policy ! router bgp 100 bgp router-id 1.1.1.1 address-family ipv4 unicast network 1.1.1.1/32 ! neighbor 12.0.0.2 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 2.2.2.2 255.255.255.255 ! interface GigabitEthernet0/0/0/0.12 vrf BLUE ipv4 address 12.0.0.2 255.255.255.0 encapsulation dot1q 12 ! interface GigabitEthernet0/0/0/0.23 ipv4 address 23.0.0.2 255.255.255.0 encapsulation dot1q 23 ! interface GigabitEthernet0/0/0/0.26 ipv4 address 26.0.0.2 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 2.2.2.2 address-family vpnv4 unicast ! neighbor 4.4.4.4 remote-as 200 update-source Loopback0 address-family vpnv4 unicast ! ! vrf BLUE rd 1:1 address-family ipv4 unicast ! neighbor 12.0.0.1 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 3.3.3.3 255.255.255.255 ! ! interface GigabitEthernet0/0/0/0.23 ipv4 address 23.0.0.3 255.255.255.0 encapsulation dot1q 23 ! interface GigabitEthernet0/0/0/0.34 ipv4 address 34.0.0.3 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 4.4.4.4 255.255.255.255 ! interface GigabitEthernet0/0/0/0.34 ipv4 address 34.0.0.4 255.255.255.0 encapsulation dot1q 34 ! interface GigabitEthernet0/0/0/0.45 vrf BLUE ipv4 address 45.0.0.4 255.255.255.0 encapsulation dot1q 45 ! interface GigabitEthernet0/0/0/0.46 ipv4 address 46.0.0.4 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 4.4.4.4 address-family vpnv4 unicast ! neighbor 2.2.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 45.0.0.5 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 5.5.5.5 255.255.255.255 ! interface Loopback1
description DELAY SENSITIVE - LOW LATENCY PATH (1:1) ipv4 address 5.5.5.55 255.255.255.255 ! interface GigabitEthernet0/0/0/0.45 ipv4 address 45.0.0.5 255.255.255.0 encapsulation dot1q 45 ! route-policy PASS pass end-policy ! router bgp 100 bgp router-id 5.5.5.5 bgp unsafe-ebgp-policy address-family ipv4 unicast network 5.5.5.5/32 network 5.5.5.55/32 ! neighbor 45.0.0.4 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 6.6.6.6 255.255.255.255 ! interface GigabitEthernet0/0/0/0.26 ipv4 address 26.0.0.6 255.255.255.0 encapsulation dot1q 26 ! interface GigabitEthernet0/0/0/0.46 ipv4 address 46.0.0.6 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 et XR4 (PE) ont créé un LSP à l'aide du routage de segment, ce qui peut être vérifié à l'aide de la requête ping MPLS pour le FEC de routage de segment correspondant. Pour ce scénario, il existe deux chemins possibles pour transporter le trafic L3VPN de XR1 à XR5 :
Chemin LSP normal : XR1 > XR2 > XR3 > XR4 > XR5
Chemin LSP à faible latence : XR1 > XR2 >XR6 > XR4 > XR5
Initialement, tout le trafic entre XR1 et XR5 est acheminé via XR3 via le chemin LSP normal en raison d'un coût IGP plus faible, nous pouvons confirmer à la fois les LSP et la connectivité comme indiqué ci-dessous les vérifications. Le coût IGP pour atteindre XR4 depuis XR2 via XR3 est de 201 contre 401 via XR6. Même si le chemin via XR3 possède une meilleure métrique de chemin, les services à faible latence sur VRF BLUE doivent être routés via XR6.
RP/0/0/CPU0:XR2#ping mpls ipv4 4.4.4.4/32 fec-type generic verbose
Sending 5, 100-byte MPLS Echos to 4.4.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 34.0.0.4, return code 3
! size 100, reply addr 34.0.0.4, return code 3
! size 100, reply addr 34.0.0.4, return code 3
! size 100, reply addr 34.0.0.4, return code 3
! size 100, reply addr 34.0.0.4, return code 3
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
Si vous vérifiez les services L3VPN sur XR1, vous pouvez confirmer l'accessibilité au bouclage XR5.5.5.5/32 et 5.5.5.55/32 respectivement via le chemin LSP normal. Les services L3VPN de base sont activés dans le coeur MPLS SR.
RP/0/0/CPU0:XR1#ping 5.5.5.5 source 1.1.1.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.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 5.5.5.55 source 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 5.5.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 5.5.5.5 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.5 1 12.0.0.2 9 msec 0 msec 0 msec 2 23.0.0.3 [MPLS: Labels 16004/24002 Exp 0] 0 msec 0 msec 0 msec 3 34.0.0.4 [MPLS: Label 24002 Exp 0] 0 msec 0 msec 0 msec 4 45.0.0.5 0 msec * 0 msec RP/0/0/CPU0:XR1#traceroute 5.5.5.55 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.55 1 12.0.0.2 9 msec 0 msec 0 msec 2 23.0.0.3 [MPLS: Labels 16004/24005 Exp 0] 0 msec 0 msec 0 msec 3 34.0.0.4 [MPLS: Label 24005 Exp 0] 0 msec 0 msec 0 msec 4 45.0.0.5 0 msec * 0 msec
Comme nous l'avons vu, tout le trafic sur VRF BLUE passe par le chemin LSP normal XR1 > XR2 > XR3 > XR4 > XR5.
Configuration de BGP Dynamic SR-TE
Dans cet exemple, nous allons configurer XR4 (extrémité arrière) pour insérer la communauté 1:1 et l'envoyer à XR2 pour signaler la création d'une stratégie SR-TE pour le préfixe 5.5.5.55/32 sur VRF BLUE. La sélection du chemin de stratégie SR-TE sera définie pour prendre le chemin de faible latence au lieu du LSP normal. Pour ce faire, nous sélectionnerons la métrique TE la plus basse (Poids Admin) via XR6. La métrique TE totale (poids admin) via XR6 est de 2, car les poids admin ont été définis sur 1 sur les interfaces sortantes vers XR4 (extrémité arrière) via XR6, comme le montrent le schéma de topologie de référence et les configurations initiales.
Afin de créer les stratégies SR-TE dynamiques, nous devons configurer le bouclage qui sera utilisé comme source et quelle est la plage de tunnels dynamiques que la tête de réseau utilisera pour générer les tunnels, cette configuration est requise à la tête de réseau de la stratégie SR-TE XR2. Nous allons définir la plage du tunnel sur un minimum de 500 et un maximum de 500, créant ainsi un tunnel SR-TE unique et le bouclage source sur le bouclage 0 à la tête de réseau du tunnel.
XR2 ipv4 unnumbered mpls traffic-eng Loopback0 mpls traffic-eng auto-tunnel p2p tunnel-id min 500 max 500 ! ! end
Sur XR4, nous allons définir la communauté 1:1 et l'appliquer sur le préfixe BLEUE VRF 5.5.5.55/32, ce qui lui permettra d'insérer la communauté dans la mise à jour BGP.
XR4
route-policy COMMUNITY_1:1
# 1:1 Community
if destination in (5.5.5.55/32) then
set community (1:1)
endif
pass
end-policy
!
router bgp 100
vrf BLUE
!
neighbor 45.0.0.5
address-family ipv4 unicast
route-policy COMMUNITY_1:1 in
!
!
end
Vérification que XR2 (tête de réseau) est configuré pour la communauté 1:1 sur les mises à jour VPNv4 reçues de XR4.
RP/0/0/CPU0:XR2#show bgp vrf BLUE 5.5.5.55/32 detail
BGP routing table entry for 5.5.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): 12.0.0.1 Path #1: Received by speaker 0 Flags: 0x4000000085060005, import: 0x9f Advertised to CE peers (in unique update groups): 12.0.0.1 200 4.4.4.4 (metric 201) from 4.4.4.4 (4.4.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
Sur XR2 (tête de réseau), nous allons créer une stratégie de route RPL correspondant à la communauté 1:1 et définissant le jeu d'attributs correspondant pour l'ingénierie de trafic MPLS. Une fois la stratégie définie, nous pouvons accéder à la configuration de MPLS-TE et définir le jeu d'attributs correspondant à la stratégie SR-TE et indiquer quels sont les critères de sélection de chemin, qui sont le routage de segment et la métrique TE dans ce cas, car nous voulons choisir le chemin via le poids administratif le plus faible via 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 4.4.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
Vérification
Une fois terminé, vous pouvez observer que l'interface tunnel-te 500 a été créée dynamiquement pour la plage spécifiée.
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 4.4.4.4 2.2.2.2 up Inact Head Inact
^ = automatically created P2P/P2MP tunnel
BGP RIB indique que la stratégie « DYN_SR-TE_POLICIES » est associée au préfixe, ce qui signifie que le trafic doit être acheminé conformément à la stratégie.
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) *> 1.1.1.1/32 12.0.0.1 0 0 200 i *>i5.5.5.5/32 4.4.4.4 0 100 0 200 i *>i5.5.5.55/32 4.4.4.4 T:DYN_SR-TE_POLICIES 0 100 0 200 i
Si nous vérifions le RIB BGP pour le préfixe 5.5.5.55/32 en détail, nous pouvons voir les informations du plan de contrôle qui seront référencées pour générer le tunnel SR-TE.
RP/0/0/CPU0:XR2#show bgp vrf BLUE 5.5.5.55/32 detail
BGP routing table entry for 5.5.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):
12.0.0.1
Path #1: Received by speaker 0
Flags: 0x4000000085060005, import: 0x9f
Advertised to CE peers (in unique update groups):
12.0.0.1
200
4.4.4.4 T:DYN_SR-TE_POLICIES (metric 201) from 4.4.4.4 (4.4.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
Nous pouvons voir que la politique de tunnel est en état actif et enregistrée. Le SID de liaison attribué est 24000, ce SID de liaison peut être utilisé pour vérifier quel tunnel est utilisé pour ce préfixe particulier. Comme indiqué précédemment, tunnel-te500 a été créé et installé dans la 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
Vous pouvez également utiliser la commande if-handle 0x0000130 donnée à partir de la sortie RIB BGP pour vérifier la stratégie SR-TE affectée pour le préfixe 5.5.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 26.0.0.6 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 stratégie SR-TE sur XR2 (tête de réseau) aura les propriétés suivantes du point de vue du plan de contrôle et du plan de données pour transférer le trafic. Les informations d'état du tunnel SR-TE peuvent également être vues comme indiqué ci-dessous, qui doit correspondre aux vérifications précédentes.
RP/0/0/CPU0:XR2#show mpls traffic-eng tunnels segment-routing p2p 500
Name: tunnel-te500 Destination: 4.4.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]: 26.0.0.2 - 26.0.0.6, Label: 24005
Segment1[Link]: 46.0.0.6 - 46.0.0.4, 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
En vérifiant le préfixe directement sur le RIB BLEU VRF, nous pouvons confirmer que le SID de liaison 24000 a été attribué au préfixe.
RP/0/0/CPU0:XR2#show route vrf BLUE 5.5.5.55/32 detail
Routing entry for 5.5.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 4.4.4.4, from 4.4.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 pour VRF BLUE indique que le transfert de ce préfixe est effectué via tunnel-te 500 conformément à notre politique SR-TE dynamique BGP.
RP/0/0/CPU0:XR2#show cef vrf BLUE 5.5.5.55/32 detail
5.5.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
Sur XR1, nous pouvons vérifier la connectivité et confirmer que le trafic passe par le tunnel-te 500 via un chemin à faible latence via XR6.
RP/0/0/CPU0:XR1#traceroute 5.5.5.55 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.55 1 12.0.0.2 0 msec 0 msec 0 msec 2 26.0.0.6 [MPLS: Labels 24003/24005 Exp 0] 0 msec 0 msec 0 msec 3 46.0.0.4 [MPLS: Label 24005 Exp 0] 0 msec 0 msec 0 msec 4 45.0.0.5 0 msec * 9 msec
Les compteurs XR2 augmentent pour le tunnel-te500, ce qui correspond à notre politique 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 26.0.0.6 2250
Le chemin du préfixe 5.5.5.5/32 passe toujours par le chemin LSP normal via XR3 comme indiqué ci-dessous.
RP/0/0/CPU0:XR1#traceroute 5.5.5.5 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 5.5.5.5 1 12.0.0.2 0 msec 0 msec 0 msec 2 23.0.0.3 [MPLS: Labels 16004/24002 Exp 0] 0 msec 0 msec 0 msec 3 34.0.0.4 [MPLS: Label 24002 Exp 0] 0 msec 0 msec 0 msec 4 45.0.0.5 0 msec * 0 msec
Dépannage
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.
Résumé
BGP Dynamic SR-TE offre la granularité et l'application automatique des politiques de routage à des fins d'ingénierie de trafic dans le coeur de réseau SR activé. La création automatique de tunnel peut être déclenchée en fonction de critères arbitraires, ce qui permet aux administrateurs réseau de créer facilement des modèles de trafic répondant aux exigences des applications du client.
Commentaires