0% encontró este documento útil (0 votos)

18 vistas375 páginas

Análisis de BGP y Segment Routing en Nodo21

El documento describe la instalación y configuración de un prefijo BGP en el Nodo21, incluyendo detalles sobre el AS-path, nexthop, y la asignación de etiquetas. Se menciona que el Nodo21 reanuncia el prefijo 1.1.1.3/32 a Nodo31, actualizando el nexthop a su dirección local y propagando el atributo Prefix-SID. Además, se presentan ejemplos de la entrada en la tabla BGP y la configuración de BGP del Nodo21.

Cargado por

kripter

Derechos de autor

Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.

Formatos disponibles

Descarga como PDF, TXT o lee en línea desde Scribd

0% encontró este documento útil (0 votos)

18 vistas375 páginas

Análisis de BGP y Segment Routing en Nodo21

Cargado por

kripter

Derechos de autor

Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.

Formatos disponibles

Descarga como PDF, TXT o lee en línea desde Scribd

43 Camino AS: 3

44 Segmento de ruta AS: 3

45 Tipo de segmento de ruta: AS_SEQUENCE (2)
46 Longitud del segmento de ruta: 1 AS
47 Valor del segmento de ruta: 3
48 MULTI_EXIT_DISC: 0 (7 bytes)
49 Banderas: 0x80 (Opcional, No transitivo, Completo)
50 1... .... = Opcional: Opcional
51 .0.. .... = Transitivo: No transitivo
52 ..0. .... = Parcial: Completo
53 ...0 .... = Longitud: Largo normal
54 Código de tipo: MULTI_EXIT_DISC (4)
55 Longitud: 4 bytes
56 Discriminador de salida múltiple: 0
57 PREFIX-SID (13 bytes)
58 Banderas: 0xc0 (Opcional, Transitivo, Completo)
59 1... .... = Opcional: Opcional
60 .1.. .... = Transitivo: Transitivo
61 ..0. .... = Parcial: Completo
62 ...0 .... = Longitud: Largo normal
63 Código de tipo: PREFIJO-SID (40)
64 Longitud: 10 bytes
65 Etiqueta-índice: 3 (1)
66 Código de tipo: Etiqueta-índice (1)
67 Longitud: 7 bytes
68 Banderas: 0x00
69 Índice de etiquetas: 3

Nodo21 instala el prefijo [Link]/32 en la tabla BGP. La entrada en la tabla BGP se muestra en el Ejemplo 6-.
13. Los diferentes elementos del mensaje de actualización BGP se muestran en esta salida: el AS-pathatributo
{3} en la línea 14, el nexthop BGP [Link] en la línea 15, y el Origen y MED en la línea 17.

El Nodo3 anuncia el valor de etiqueta "3" para este prefijo, que es la etiqueta implícita-nula (Received
Label 3 en la línea 16), y el Nodo3 establece el Prefix-SID Label Index "3" (línea 21), que es el valor que
fue asignado a este prefijo en la configuración route-policy SID() del Nodo3. Como Nodo21 tiene SR BGP
habilitado, asigna una etiqueta local 16003 del SRGB [16000-23999] para este prefijo (16003 = 16000 + 3).
Esta etiqueta local se muestra en la línea 6.
Ejemplo 6-13: Entrada en la tabla BGP del prefijo [Link]/32 en Nodo21

1 RP/0/0/CPU0:xrvr-21#show bgp ipv4 labeled-unicast [Link]/32

2 Entrada en la tabla de enrutamiento BGP para [Link]/32
3 Versiones:
4 Proceso bRIB/RIB SendTblVer
5 Altavoz 3 3
6 Etiqueta local: 16003
7 Última modificación: Aug 10 12:14:05.225 para 1d05h
8 Caminos: (1 disponible, mejor #1)
9 Anunciado a grupos de actualización (con más de un peer):
10 0.2
11 Ruta #1: Recibido por el altavoz 0
12 Anunciado a grupos de actualización (con más de un peer):
13 0.2
14 3
15 [Link] de [Link] ([Link])
16 Etiqueta recibida 3
17 Origen IGP, métrica 0, localpref 100, válido, externo, mejor, grupo-mejor
18 ID de ruta recibida 0, ID de ruta local 0, versión 3
19 Origen-AS validez: no encontrado
20 Prefijo SID Tamaño del atributo: 10
21 Índice de etiquetas: 3

El Nodo21 instala la entrada de reenvío para el prefijo [Link]/32 en su tabla de reenvío. La entrada RIB se
muestra en el Ejemplo 6-14. La etiqueta local para el prefijo [Link]/32 es la etiqueta Prefix-SID 16003 (línea
16). El valor de etiqueta 0x100004 (1048580) en la salida (línea 10) es un valor interno especial que representa
la etiqueta pop o implicit-null. Por defecto Cisco IOS XR etiqueta automáticamente una ruta aprendida de BGP
con el número de AS más reciente en su ruta AS (línea 5); esto no está relacionado con SR BGP.
Ejemplo 6-14: Entrada RIB del prefijo [Link]/32 en Nodo21

El Nodo21 instala la entrada de imposición de etiquetas en la tabla cef (ver Ejemplo 6-15) y la entrada de
intercambio de etiquetas en la tabla de reenvío MPLS (ver Ejemplo 6-16). El Nodo21 no impone etiquetas a
los paquetes entrantes no etiquetados destinados a [Link]/32 ya que el destino Nodo3 es adyacente (última
línea del Ejemplo 6-15). La etiqueta se quita para los paquetes etiquetados que llegan con la etiqueta superior
16003 (última línea en el Ejemplo 6-16).

Ejemplo 6-15: Entrada CEF del prefijo [Link]/32 en Nodo21

RP/0/0/CPU0:xrvr-21#show cef [Link]/32

[Link]/32, versión 1802, interno 0x5000001 0x80 (ptr 0xa1492df4) [1], 0x0
(0xa145dc44), 0xa00 (0xa15832f8)
Actualizado el 30 de mayo a las 17:59:40.005
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 4
via [Link]/32, 3 dependencias, recursivo, bgp-ext [flags 0x6020] path-
idx 0 NHID 0x0 [0xa1492374 0xa15eb9f4]
recursividad-via-/32
siguiente salto [Link]/32 vía [Link]/32
etiqueta local 16003
siguiente salto [Link]/32 Gi0/0/0/0 etiquetas impuestas {ImplNull ImplNull}
Ejemplo 6-16: Entrada en la tabla de reenvío MPLS del prefijo [Link]/32 en Nodo21

RP/0/0/CPU0:xrvr-21#show mpls forwarding prefix [Link]/32

Local Saliente Prefijo Salida Siguiente salto Bytes
Etiqueta Etiqueta o ID Interfaz Conmutado

16003 Pop SR Pfx (idx 3) Gi0/0/0/0 [Link] 5311

En el Ejemplo 6-17 se muestra la configuración BGP del Nodo21. La configuración de las diferentes políticas de
ruta es la misma que en el Nodo3. Nodo21 tiene un número de AS 21. Se configuran dos neighbor-groups: uno
para las BGP a los nodos Tier-1 (neighbor-group TIER1 en líneas 22 a 25) y otro para las sesiones
EBGP a los nodos Tier-3 (neighbor-group TIER3 en las líneas 28 a 31). En este ejemplo, los dos
grupos de vecinos contienen la misma configuración. Nodo21 origina su prefijo loopback0 [Link]/32 con un
índice Prefix-SID 21 a todos sus vecinos EBGP-LU (la declaración de red en la línea 19). El neighbor-group
respectivo se aplica a cada . SRGB [16000-23999] se configura globalmente en las líneas 45 y 46.
Ejemplo 6-17: Configuración BGP del Nodo21

1 interfaz Loopback0
2 dirección ipv4 [Link] [Link]
¡3 !
4 política de ruta SID($SID)
5 set label-index $SID
6 fin de la política
¡7 !
8 route-policy bgp_in
9 pase
10 fin de la política
¡11 !
12 route-policy bgp_out
13 pase
14 fin de la política
¡15 !
16 router bgp 21
17 bgp router-id [Link]
18 address-family ipv4 unicast
19 network [Link]/32 route-policy SID(21)
20 asignar-etiquetar todo
21 ¡!
22 neighbor-group TIER1
23 address-family ipv4 labeled-unicast
24 política de ruta bgp_in en
25 política de ruta bgp_out out out
26 ¡!
27 ¡!
28 grupo-vecino TIER3
29 address-family ipv4 labeled-unicast
30 route-policy bgp_in in
31 route-policy bgp_out out out
32 ¡!
33 ¡!
34 vecino [Link]
35 remoto-as 3
36 use neighbor-group TIER1
37 descripción eBGP peer xrvr-3
38 ¡!
39 vecino [Link]
40 remoto-as 31
41 use neighbor-group TIER3
42 descripción eBGP peer xrvr-31
43 ¡!
¡44 !
45 enrutamiento por segmentos
46 bloque global 16000 23999
¡47 !
Nodo21 re-anuncia el prefijo [Link]/32 a Nodo31. El mensaje de actualización BGP capturado se muestra en
el Ejemplo 6-18. El atributo MP_REACH_NRLI se muestra en las líneas 8 a 25. El atributo
MP_REACH_NRLI se muestra en las líneas 8 a 25. Nodo21 ha actualizado el nexthop BGP a su dirección de
interfaz local [Link] (línea 19) debido al comportamiento por defecto EBGP "nexthop-self". Nodo21
anuncia el prefijo IPv4 Labeled Unicast [Link]/32 con valor de etiqueta 16003 (líneas 22 y 24); esta es la
etiqueta local que Nodo21 asignó para el prefijo [Link]/32. Nodo21 antepuso su número AS 21 al atributo AS-
path (línea 35). El atributo Prefix-SID se propaga sin cambios (líneas 48 a 60).

Ejemplo 6-18: Mensaje de actualización BGP enviado por Nodo21

1 Border Gateway Protocol - Mensaje UPDATE

2 Marcador: ffffffffffffffffffffffffffffffffffffff
3 Longitud: 74
4 Tipo: Mensaje UPDATE (2)
5 Rutas inviables longitud: 0 bytes
6 Longitud total del atributo de ruta: 51 bytes
7 Atributos de la ruta
8 MP_REACH_NLRI (21 bytes)
9 Banderas: 0x90 (Opcional, no transitivo, completo, longitud extendida)
10 1... .... = Opcional: Opcional
11 .0.. .... = Transitivo: No transitivo
12 ..0. .... = Parcial: Completo
13 ...1 .... = Longitud: Longitud extendida
14 Código de tipo: MP_REACH_NLRI (14)
15 Longitud: 17 bytes
16 Familia de direcciones: IPv4 (1)
17 Identificador de la familia de direcciones subsiguiente: Etiquetado Unicast (4)
18 Dirección de red del siguiente salto (4 bytes)
19 Siguiente salto: [Link] (4)
20 Puntos de conexión a la subred: 0
21 Información de accesibilidad de la capa de red (8 bytes)
22 Etiqueta Pila=16003 (abajo) IPv4=[Link]/32
23 MP Reach NLRI Longitud del prefijo: 56
24 Pila de etiquetas MP Reach NLRI: 16003 (abajo)
25 MP Reach NLRI Prefijo IPv4: [Link] ([Link])
26 ORIGEN: IGP (4 bytes)
27 Banderas: 0x40 (Conocido, Transitivo, Completo)
28 0... .... = Opcional: Conocido
29 .1.. .... = Transitivo: Transitivo
30 ..0. .... = Parcial: Completo
31 ...0 .... = Longitud: Largo normal
32 Código de tipo: ORIGEN (1)
33 Longitud: 1 byte
34 Origen: IGP (0)
35 AS_PATH: 21 3 (13 bytes)
36 Banderas: 0x40 (Conocido, Transitivo, Completo)
37 0... .... = Opcional: Conocido
38 .1.. .... = Transitivo: Transitivo
39 ..0. .... = Parcial: Completo
40 ...0 .... = Longitud: Largo normal
41 Código de tipo: AS_PATH (2)
42 Longitud: 10 bytes
43 Ruta AS: 21 3
44 Segmento de ruta AS: 21 3
45 Tipo de segmento de ruta: AS_SEQUENCE (2)
46 Longitud del segmento de ruta: 2 AS
47 Valor del segmento de ruta: 21 3
48 PREFIX-SID (13 bytes)
49 Banderas: 0xc0 (Opcional, Transitivo, Completo)
50 1... .... = Opcional: Opcional
51 .1.. .... = Transitivo: Transitivo
52 ..0. .... = Parcial: Completo
53 ...0 .... = Longitud: Largo normal
54 Código de tipo: PREFIJO-SID (40)
55 Longitud: 10 bytes
56 Etiqueta-índice: 3 (1)
57 Código de tipo: Etiqueta-índice (1)
58 Longitud: 7 bytes
59 Banderas: 0x00
60 Índice de etiquetas: 3

En el Ejemplo 6-19 se muestra la entrada de la tabla BGP para el prefijo [Link]/32 en el Nodo31. La etiqueta
que el Nodo31 recibió del Nodo21 es 16003 (línea 16) y el índice SID en el atributo Prefijo-SID (líneas 20 y
21) es 3. Como el Nodo31 está habilitado para SR BGP, asigna una etiqueta local 16003 desde el SRGB para
el prefijo [Link]/32 (línea 6). El Nodo31 utiliza el índice SID 3 recibido para determinar qué etiqueta local
Prefijo- SID asignar.
Ejemplo 6-19: Entrada en la tabla BGP del prefijo [Link]/32 en Nodo31

1 RP/0/0/CPU0:xrvr-31#show bgp ipv4 labeled-unicast [Link]/32

2 Entrada en la tabla de enrutamiento BGP para [Link]/32
3 Versiones:
4 Proceso bRIB/RIB SendTblVer
5 Altavoz 4 4
6 Etiqueta local: 16003
7 Última modificación: 30 de mayo 17:59:44.268 para 00:04:48
8 Caminos: (1 disponible, mejor #1)
9 Anunciado a grupos de actualización (con más de un par):
10 0.2
11 Ruta nº 1: Recibido por el altavoz 0
12 Anunciado a grupos de actualización (con más de un par):
13 0.2
14 20 3
15 [Link] de [Link] ([Link])
16 Etiqueta recibida 16003
17 Origen IGP, localpref 100, valid, external, best, group-best
18 ID de ruta recibida 0, ID de ruta local 0, versión 4
19 Origen-AS validez: no encontrado
20 Prefijo SID Tamaño del atributo: 10
21 Índice de etiquetas: 3

El Nodo31 instala las entradas de reenvío para el prefijo [Link]/32. La entrada RIB se muestra en el
Ejemplo 6-20. La etiqueta local 16003 se muestra en la línea 16 y la etiqueta saliente 16003 se muestra en la
línea 10. La etiqueta local 16003 se muestra en línea 16 y la etiqueta saliente 16003 se muestra en la línea
10.
Ejemplo 6-20: Entrada RIB del prefijo [Link]/32 en Nodo31

La entrada CEF para el prefijo [Link]/32 se muestra en el Ejemplo 6-21. La pila de etiquetas impuestas consta
de dos entradas (mostradas en la última línea de la salida) porque es una entrada recursiva; el prefijo
[Link]/32 resuelve en el nextopo [Link]. El primer valor de etiqueta en la lista labels imposed
{ImpNull 16003} es la etiqueta para alcanzar el nexthop, que es el Nodo21 conectado directamente, de
ahí la etiqueta ImplNull. La segunda etiqueta es la etiqueta Prefix-SID para el prefijo [Link]/32.
Ejemplo 6-21: Entrada CEF del prefijo [Link]/32 en Nodo31

RP/0/0/CPU0:xrvr-31#show cef [Link]/32

[Link]/32, versión 213, interno 0x5000001 0x80 (ptr 0xa141aaf4) [1], 0x0
(0xa13e5974), 0xa08 (0xa1583230)
Actualizado el 12 de agosto 09:32:04.036
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 4
vía [Link]/32, 5 dependencias, recursivo, bgp-ext [flags 0x6020] path-idx
0 NHID 0x0 [0xa15eb5f4 0x0].
recursividad-via-/32
siguiente salto [Link]/32 vía 24001/0/21
etiqueta local 16003
siguiente salto [Link]/32 GIO/0/0/2 etiquetas impuestas {ImplNull 16003}

La entrada de reenvío MPLS se muestra en el Ejemplo 6-22. Tanto las etiquetas locales como las salientes para el
prefijo
[Link]/32 son 16003.

Ejemplo 6-22: Entrada en la tabla de reenvío MPLS del prefijo [Link]/32 en Nodo31

RP/0/0/CPU0:xrvr-31#show mpls forwarding prefix [Link]/32

Local Saliente Prefijo Saliente Siguiente salto Bytes
Etiqueta Etiqueta o ID Interfaz Conmutado

16003 16003 SR Pfx (idx 3) Gi0/0/0/2 [Link] 208

El prefijo, el Label-index y el valor de la etiqueta son re-anunciados por el Nodo31 y el Nodo11 para llegar
finalmente al Nodo1. Las configuraciones BGP de Nodo11 y Nodo1 son equivalentes a las anteriores. El Nodo1
instala entonces la entrada de reenvío para el prefijo 1.1 1.3/32 que se muestra en el Ejemplo 6-.
23. Nodo1 está habilitado para SR BGP, por lo tanto asigna una etiqueta local 16003 del SRGB para el prefijo
etiqueta local [Link]/32. Esta se instala en la entrada de reenvío MPLS que se muestra en el Ejemplo 6-25. Esta
etiqueta local se instala en la entrada de reenvío MPLS que se muestra en el Ejemplo 6- 25.
Ejemplo 6-23: Entrada CEF del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

[Link]/32, versión 5107, interno 0x1000001 0x80 (ptr 0xa12753f4) [1], 0x0
(0xa123fd40), 0xa08 (0xa13ab0f0)
Actualizado el 30 de mayo 18:52:20.338
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 4
via [Link]/32, 5 dependencias, recursivo, bgp-ext [flags 0x6020] path-
idx 0 NHID 0x0 [0xa1413e74 0x0]
recursividad-via-/32
siguiente salto [Link]/32 vía 24000/0/21
etiqueta local 16003
siguiente salto [Link]/32 GIO/0/0/0 etiquetas impuestas {ImplNull 16003}

Ejemplo 6-24: Entrada en la tabla de reenvío MPLS del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show mpls forwarding prefix [Link]/32

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

16003 16003 SR Pfx (idx 3) Gi0/0/0/0 [Link] 0

Se puede utilizar Traceroute para verificar la ruta a [Link] en Nodo1. La salida de IP traceroute se muestra en
el Ejemplo 6-25. La ruta trazada es Nodo1→Nodo11→Nodo31→Nodo21→Nodo3. La ruta trazada es
Nodo1→Nodo11→Nodo31→Nodo21→Nodo3. Se utiliza la misma etiqueta Prefijo- SID 16003 para todos
los saltos de la ruta, hasta que el penúltimo salto, Nodo21, quita la etiqueta. En el Ejemplo 6-26 se muestra la
salida del traceroute MPLS. La pila de etiquetas saliente para cada salto (implicit-null/16003) es la
pila de etiquetas como se muestra en la entrada CEF del Ejemplo 6-23.

Ejemplo 6-25: IP traceroute desde Nodo1 a Nodo3

RP/0/0/CPU0:xrvr-1#traceroute [Link] source [Link]

Escriba la secuencia de escape para abortar.

Rastreando la ruta a [Link]

1 [Link] [MPLS: Etiqueta 16003 Exp 0] 289 mseg 39 mseg 39 mseg

2 [Link] [MPLS: Etiqueta 16003 Exp 0] 309 mseg 49 mseg 59 mseg
3 [Link] [MPLS: Etiqueta 16003 Exp 0] 199 mseg 49 mseg 69 mseg
4 [Link] 299 mseg 229 mseg 219 mseg
Ejemplo 6-26: Traceroute MPLS desde Nodo1 a Nodo3

RP/0/0/CPU0:xrvr-1#traceroute mpls ipv4 [Link]/32 source [Link] fec-type generic Tracing MPLS

Label Switched Path to [Link]/32, timeout is 2 seconds

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

L' - interfaz de salida etiquetada, 'B' - interfaz de salida no
etiquetada, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC
mismatch, 'M' - malformed request, 'm' - tlvs no soportados, 'N' - no rx
label, 'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - código de retorno desconocido, 'x' - código de

retorno 0 Escriba la secuencia de escape para abortar.

0 [Link] MRU 1500 [Etiquetas: implicit-null/16003 Exp: 0/0]

L 1 [Link] MRU 1500 [Etiquetas: implicit-null/16003 Exp: 0/0] 20 ms
L 2 [Link] MRU 1500 [Labels: implicit-null/16003 Exp: 0/0] 210 ms
L 3 [Link] MRU 1500 [Etiquetas: implícito-nulo/implícito-nulo Exp: 0/0] 200 ms
¡! 4 [Link] 220 ms

6.8.2 Configuración del servicio de superposición L3VPN

Hasta ahora, en esta sección se ha tratado el transporte SR MPLS a través del Data Center Fabric. A
continuación, se despliega un servicio superpuesto L3VPN entre los dos nodos Tier-1 Nodo1 y Nodo3. Los
servidores o máquinas virtuales que se conectan a la interfaz VRF de estos Tier-1 participan en el servicio
L3VPN.

El intercambio BGP de prefijo y etiqueta vpnv4 entre los Tier-1 se realiza a través de un Service Route
Reflector Node41. En este ejemplo, el Service Route Reflector está conectado al nodo 31 de nivel 3.

La configuración del servicio L3VPN del Nodo Tier-13 se muestra en el Ejemplo 6-27. La vrf "SVC" está
configurada en las líneas 1 a 7, especificando el Route-target 1:1000 tanto para importación como para
exportación. La address-family vpnv4 unicast está habilitada bajo la instancia BGP. El grupo de vecinos
ROUTE_REFLECTORS se configura en las líneas 14 a 19, con la configuración de vecinos BGP para el grupo
de vecinos ROUTE_REFLECTORS.
al Route Reflector Node41. El Route Reflector tiene un número de AS 41. Nodo3 se conecta él mediante una
sesión EBGP multisalto establecida entre loopbacks de ambos nodos. El transporte entre los prefijos de
loopback es SR MPLS. El vrf SVC está configurado en BGP con un Distintivo de Ruta seleccionado
automáticamente (líneas 27 a 30).
Ejemplo 6-27: Configuración BGP para servicio L3VPN en Nodo3

1 vrf VPC
2 address-family ipv4 unicast
3 importar ruta-objetivo
4 1:1000
5 ¡!
6 export ruta-objetivo
7 1:1000
8 ¡!
9 ¡!
¡10 !
11 router bgp 3
12 address-family vpnv4 unicast
13 ¡!
14 neighbor-group ROUTE_REFLECTORS
15 ebgp-multihop 255
16 update-source Loopback0
17 address-family vpnv4 unicast
18 route-policy bgp_in in
19 route-policy bgp_out out out
20 ¡!
21 ¡!
22 vecino [Link]
23 remoto-as 41
24 use neighbor-group ROUTE_REFLECTORS
25 descripción servicio RR Nodo41
26 ¡!
27 vrf VPC
28 rd auto
29 address-family ipv4 unicast
30 red [Link]/24
31 ¡!
32 ¡!
¡33 !

La configuración BGP para el servicio SR MPLS en el Nodo RR 41 es equivalente a las configuraciones de los
otros nodos del Data Center Fabric. El ejemplo 6-28 muestra la configuración BGP en el RR Nodo41 para su
función como RR de servicio de superposición L3VPN.
Ejemplo 6-28: Configuración BGP para el servicio L3VPN en el Nodo RR de Servicio41

1 router bgp 41
2 address-family vpnv4 unicast
3 retain route-target all
4 ¡!
5 neighbor-group RR_CLIENTS
6 ebgp-multihop 255
7 update-source Loopback0
8 address-family vpnv4 unicast
9 route-policy bgp_in in
10 route-policy bgp_out out out
11 next-hop-unchanged
12 ¡!
13 ¡!
14 vecino [Link]
15 remoto-as 1
16 use grupo de vecinos RR_CLIENTS
17 ¡!
18 vecino [Link]
19 remoto-as 3
20 use grupo de vecinos RR_CLIENTS
21 ¡!
¡22 !

Por defecto, un nodo no acepta ningún prefijo VPN que no coincida con una política local de importación de
Ruta-destino. Este comportamiento por defecto es por razones de escalabilidad para no malgastar memoria en
entradas BGP que de todas formas no se utilizan. Los Reflectores de Ruta (RRs) (IBGP) tienen este
desactivado por defecto ya que su función es reflejar todos los prefijos VPN incluso si no hay ningún vrf
configurado en el RR. El Nodo41 de este no es un RR real en sentido estricto ya que "Route Reflector" es un
mecanismo de BGP Interno (IBGP).
El Nodo41 por otro lado re-anuncia o refleja las actualizaciones BGP debido a la funcionalidad nativa EBGP.
Dado que el Nodo41 no es un RR real, el filtro RT no está deshabilitado por defecto. Pero la retención de
prefijos VPN en el Nodo41 puede lograrse configurando retain route-target bajo la familia de
direcciones vpnv4 (ver línea 3 en el Ejemplo 6-28). Esta configuración acepta la palabra clave all o una
route-policy; all retiene todos los prefijos mientras que usar una route-policy en la configuración permite
filtrar los prefijos que deben ser retenidos.

La función del es volver a anunciar los prefijos VPN entre sus clientes RR. Un RR no debe modificar el atributo
nexthop de BGP cuando vuelve a anunciar un . Por lo tanto el comportamiento EBGP nexthop-self por defecto
se desactiva configurando next-hop-unchanged bajo el neighbor-group applied
a las sesiones de cliente de Route Reflector (línea 11). De este modo, el Route Reflector mantiene el nexthop
BGP original para el prefijo cuando vuelve a .

En el Ejemplo 6-29 se muestra la entrada BGP del prefijo vrf SVC [Link]/24 en Nodo1. El nexthop BGP
para el prefijo es [Link], que es el router-id del Nodo3 que originó el prefijo (línea 12). La etiqueta 90039
(línea 13) es la etiqueta agregada que el Nodo3 ha asignado y anunciado para la vrf SVC. Por defecto, un PE
asigna y anuncia una etiqueta por vrf para prefijos vrf originados localmente. El PE hace un Pop-and-lookup
en la tabla de reenvío vrf cuando llega un paquete con etiqueta Aggregate.

Ejemplo 6-29: Entrada en la tabla BGP del prefijo [Link]/24 en vrf SVC en Nodo1

1 RP/0/0/CPU0:xrvr-1#show bgp vrf SVC [Link]/24

2 Entrada en la tabla de enrutamiento BGP para [Link]/24, Distintivo de ruta: [Link]:1
3 Versiones:
4 Proceso bRIB/RIB SendTblVer
5 Altavoz 16 16
6 Última modificación: 30 de mayo 18:52:19.880 para 10:45:06
7 Caminos: (1 disponible, mejor #1)
8 No se anuncia a ningún homólogo
9 Ruta nº 1: Recibido por el altavoz 0
10 No se anuncia a ningún homólogo
11 41 3
12 [Link] de [Link] ([Link])
13 Etiqueta recibida 90039
14 Origen IGP, localpref 100, valid, external, best, group-best, import-
candidate, imported
15 ID de ruta recibida 0, ID de ruta local 0, versión 16
16 Comunidad ampliada: RT:1:1000
17 Fuente AFI: VPNv4 Unicast, VRF de origen: por defecto, Distintivo de ruta de origen:
[Link]:1

La salida en el Ejemplo 6-30 muestra la entrada RIB para el prefijo [Link]/24 en la vrf SVC en Nodo1.
Muestra que este prefijo vrf se resuelve en su nexthop BGP [Link] en la tabla de reenvío global (por
defecto) (líneas 8 y 9).
Ejemplo 6-30: Entrada RIB del prefijo [Link]/24 en vrf SVC en Nodo1

1 RP/0/0/CPU0:xrvr-1#show route vrf SVC [Link]/24

2
3 Entrada de enrutamiento para [Link]/24
4 Conocido vía "bgp 1", distancia 20, métrica 0
5 Etiqueta 41, tipo externo
6 Instalado May 30 18:52:20.328 para 10:42:57
7 Bloques descriptores de enrutamiento
8 [Link], de [Link], BGP externo
9 Nexthop en Vrf: "default", Tabla: "default", IPv4 Unicast, Id. de tabla:
0xe0000000
10 La métrica de la ruta es 0
11 Nada de protos publicitarios.

La entrada cef para este prefijo en vrf SVC en Nodo1 (Ejemplo 6-33), muestra la pila de etiquetas que Nodo1
impone a los paquetes destinados a ese prefijo. La pila de etiquetas consiste de tres etiquetas: labels
imposed {ImplNull 16003 90039} (última línea en la salida). Las dos primeras etiquetas son las
etiquetas de Segment Routing BGP-LU utilizadas para alcanzar el nexthop BGP [Link]. Esta pila de dos
etiquetas también se muestra en la salida de show cef [Link]/32 en el Nodo1 en el Ejemplo 6-23.
La primera de estas dos etiquetas es la etiqueta BGP-LU. La primera de estas dos etiquetas es la etiqueta para
alcanzar el nexthop [Link]/32. Como este nexthop está conectado directamente, no se requiere ninguna
etiqueta, de ahí la etiqueta ImplNull. La segunda etiqueta es la Prefix-SID 16003 para el prefijo [Link]/32.
La última etiqueta de la pila de tres etiquetas, la etiqueta en la parte inferior de la pila, la etiqueta VPN 90039
utilizada para este prefijo.

Ejemplo 6-31: Entrada CEF del prefijo [Link]/24 en vrf SVC en Nodo1

RP/0/0/CPU0:xrvr-1#show cef vrf SVC [Link]/24

[Link]/24, versión 5, interno 0x5000001 0x0 (ptr 0xa1273974) [1], 0x0 (0x0), 0x208 (0xa13ab2d0)
Actualizado el 30 de mayo 18:52:20.338
Prefijo Len 24, índice de tráfico 0, precedencia n/a, prioridad 3
via [Link]/32, 3 dependencias, recursivo, bgp-ext [flags 0x6020] path-
idx 0 NHID 0x0 [0xa1413df4 0x0]
recursividad-via-/32
next hop VRF - 'default', tabla - 0xe0000000 next
hop [Link]/32 via 16003/0/21
siguiente salto [Link]/32 GIO/0/0/0 etiquetas impuestas {ImplNull 16003 90039}

En el Ejemplo 6-32 se muestra un traceroute IP en vrf SVC en Nodo1 al destino [Link]. Los paquetes viajan
a través de Nodo11, Nodo31 y Nodo21 para llegar a Nodo3. Los paquetes viajan a través de Nodo11,
Nodo31, y Nodo21 para llegar a Nodo3. Las etiquetas en los paquetes son la etiqueta Prefix-SID 16003 y la
etiqueta VPN 90039. Un pequeño detalle: el último salto en el traceroute no
no muestra la etiqueta VPN ya que el prefijo de destino del traceroute es local al Nodo3. Si la dirección de
destino fuera un CE conectado en la interfaz vrf entonces la etiqueta VPN se como la única etiqueta para el
cuarto salto en el traceroute.

Ejemplo 6-32: IP traceroute en vrf SVC desde Nodo1 a destino en vrf SVC

RP/0/0/CPU0:xrvr-1#traceroute vrf SVC [Link]

Escriba la secuencia de escape para abortar.

Rastreando la ruta a [Link]

1 [Link] [MPLS: Etiquetas 16003/90039 Exp 0] 879 mseg 49 mseg 79 mseg

2 [Link] [MPLS: Etiquetas 16003/90039 Exp 0] 39 mseg 49 mseg 39 mseg
3 [Link] [MPLS: Etiquetas 16003/90039 Exp 0] 49 mseg 39 mseg 39 mseg
4 [Link] 59 mseg 39 mseg 39 mseg

6.8.3 Configuración de ECMP con E-BGP Multipath

Al añadir el otro de los nodos de la topología de la Figura 6-12 (Nodo2, Nodo12, Nodo32, Nodo22, y Nodo4),
múltiples caminos de Igual Coste quedan disponibles en el Tejido del Centro de Datos, también entre Nodo1 y
Nodo3. Por supuesto, todos los ECMP disponibles deben ser utilizados en el Centro de Datos para utilizar toda
la capacidad de red disponible. Por defecto, BGP selecciona una ruta a cada destino como mejor ruta, y sólo
esa ruta se instala en la tabla de reenvío. Para instalar múltiples rutas por destino, BGP multi-path debe estar
habilitado. EBGP multi-path se habilita configurando maximum-paths ebgp <n> bajo address-family,
donde <n> especifica el número máximo de rutas que se instalarán para cada destino. Esta configuración se
muestra en el Ejemplo 6-31.

Ejemplo 6-33: Configuración EBGP multipath

router bgp 1
address-family ipv4 unicast
maximum-paths ebgp 16 !! máximo 16 rutas Equal Cost por prefijo
¡!
¡!

Una configuración adicional puede ser requerida, dependiendo de la asignación del número AS en el Data Center
Fabric. El Nodo1 en la Figura 6-12 recibe dos rutas EBGP-LU para el prefijo loopback del Nodo3
[Link]/32 (ver la salida en el Ejemplo 6-34): una vía Nodo11 (líneas 11 a 21) y otra vía Nodo12 (líneas 22 a
31). Debido a la asignación del número AS en el ejemplo (cada nodo tiene su propio y único número AS, ambas
rutas no tienen la misma ruta AS: {11 31 21 3} para la primera ruta (línea 14) y {12 31
21 3} para la segunda ruta (línea 24). La ruta vía Nodo11 es seleccionada como la mejor ruta ya que todos
los atributos son iguales para ambas rutas (sólo la longitud de la ruta AS cuenta en la evaluación de la mejor
ruta) y la ruta vía Nodo11 tiene la dirección vecina más baja. La segunda ruta no es admitida en la multi-
ruta ya que EBGP multi-ruta requiere que las rutas candidatas tengan un coste igual a la mejor ruta; decir,
que tengan idénticos atributos BGP: mismo Peso, mismo Local-Pref, mismo AS-Path (longitud y contenido
AS-path), mismo Origen, mismo MED, y un nexthop diferente.

Ejemplo 6-34: Entrada en la tabla BGP del prefijo [Link]/32 en Nodo1 con selección EBGP multipath por defecto

1 RP/0/0/CPU0:xrvr-1#show bgp ipv4 labeled-unicast [Link]/32

2 Entrada en la tabla de enrutamiento BGP para [Link]/32
3 Versiones:
4 Proceso bRIB/RIB SendTblVer
5 Altavoz 48 48
6 Etiqueta local: 16003
7 Última modificación: 12 ago 11:52:24.342 para 00:01:55
8 Caminos: (2 disponibles, mejor el nº 1)
9 Anunciado a grupos de actualización (con más de un par):
10 0.2
11 11 Ruta #1: Recibida por el altavoz 0
12 Anunciado a grupos de actualización (con más de un par):
13 0.2
14 11 31 21 3
15 [Link] de [Link] ([Link])
16 Etiqueta recibida 16003
17 Origen IGP, localpref 100, valid, external, best, group-best
18 ID de ruta recibida 0, ID de ruta local 0, versión 48
19 Origen-AS validez: no encontrado
20 Prefijo SID Tamaño del atributo: 10
21 21 Índice de etiquetas: 3
22 22 Ruta #2: Recibida por el altavoz 0
23 No se anuncia a ningún homólogo
24 12 31 21 3
25 [Link] de [Link] ([Link])
26 Etiqueta recibida 16003
27 Origen IGP, localpref 100, valid, external, group-best
28 ID de ruta recibida 0, ID de ruta local 0, versión 0
29 Origen-AS validez: no encontrado
30 Prefijo SID Tamaño del atributo: 10
31 31 Índice de etiquetas: 3

Para admitir la segunda ruta en la ruta múltiple, la regla de selección de rutas múltiples puede relajarse para
permitir también rutas con la misma longitud de ruta AS que la mejor ruta, pero diferente contenido de ruta AS.
Por lo tanto, bgp
bestpath as-path multipath-relax debe estar configurado. Esto se ilustra en el Ejemplo 6-
35. Ahora se acepta la segunda ruta en la ruta múltiple, como se indica en las líneas 23 y 33.

Ejemplo 6-35: Entrada en la tabla BGP del prefijo [Link]/32 en Nodo1 con selección EBGP multipath relajada

1 RP/0/0/CPU0:xrvr-1#configurar
2 RP/0/0/CPU0:xrvr-1(config)#router bgp 1
3 RP/0/0/CPU0:xrvr-1(config-bgp)# bgp bestpath as-path multipath-relax
4 RP/0/0/CPU0:xrvr-1(config-bgp)#commit
5 RP/0/0/CPU0:xrvr-1(config-bgp)#end
6 RP/0/0/CPU0:xrvr-1#
7 RP/0/0/CPU0:xrvr-1#show bgp ipv4 labeled-unicast [Link]/32
8 Entrada en la tabla de enrutamiento BGP para [Link]/32
9 Versiones:
10 Proceso bRIB/RIB SendTblVer
11 Altavoz 54 54
12 Etiqueta local: 16003
13 Última modificación: 12 ago 12:32:22.342 para 00:00:12
14 Caminos: (2 disponibles, mejor el nº 1)
15 Anunciado a grupos de actualización (con más de un peer):
16 0.2
17 Ruta #1: Recibido por el altavoz 0
18 Anunciado a grupos de actualización (con más de un par):
19 0.2
20 11 31 21 3
21 [Link] de [Link] ([Link])
22 Etiqueta recibida 16003
23 Origen IGP, localpref 100, valid, external, best, group-best, multipath
24 ID de ruta recibida 0, ID de ruta local 0, versión 54
25 Origen-AS validez: no encontrado
26 Prefijo SID Tamaño del atributo: 10
27 Índice de etiquetas: 3
28 Ruta #2: Recibido por el altavoz 0
29 No se anuncia a ningún homólogo
30 12 31 21 3
31 [Link] de [Link] ([Link])
32 Etiqueta recibida 16003
33 Origen IGP, localpref 100, válido, externo, multipath
34 ID de ruta recibida 0, ID de ruta local 0, versión 0
35 Origen-AS validez: no encontrado
36 Prefijo SID Tamaño del atributo: 10
37 Índice de etiquetas: 3

Las rutas de igual coste también se añaden a la tabla de reenvío, como se ilustra en el Ejemplo 6-36 y en el
Ejemplo 6-37.
Ejemplo 6-36: Entrada CEF del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

[Link]/32, versión 305, interno 0x1000001 0x80 (ptr 0xa141a6f4) [1], 0x0
(0xa13e5758), 0xa08 (0xa16f0050)
Actualizado el 12 de agosto de 12:32:22.675
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 4
vía [Link]/32, 5 dependencias, recursivo, bgp-ext, bgp-multipath [flags 0x60a0]
path-idx 0 NHID 0x0 [0xa15eb4f4 0x0]
recursion-via-/32
siguiente salto [Link]/32 vía 24000/0/21
etiqueta local 16003
siguiente salto [Link]/32 GIO/0/0/0 etiquetas impuestas {ImplNull 16003}
vía [Link]/32, 5 dependencias, recursivo, bgp-ext, bgp-multipath [flags 0x60a0]
path-idx 1 NHID 0x0 [0xa15ebbf4 0x0]
recursion-via-/32
siguiente salto [Link]/32 vía 24007/0/21
etiqueta local 16003
siguiente salto [Link]/32 Gi0/0/0/1 etiquetas impuestas {ImplNull 16003}

Ejemplo 6-37: Entrada en la tabla de reenvío MPLS del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show mpls forwarding prefix [Link]/32

Local Saliente Prefijo Saliente Salto siguiente Bytes
Etiqu Etiqueta o ID Interfaz Conmutado
eta

16003 16003 SR Pfx (idx 3) Gi0/0/0/0 [Link] 0

16003 SR Pfx (idx 3) GIO/0/0/1 [Link] 0

Se puede utilizar MPLS multi-path traceroute para explorar el número de posibles rutas desde Nodo1 a Nodo3 a
través del tejido del Centro de Datos. El Capítulo 11, "Verificando la conectividad en la red SR MPLS"
describe la funcionalidad del traceroute MPLS multi-path con más detalle. En el Ejemplo 6-38 se muestra la
salida del comando traceroute mpls. Se encuentran ocho caminos diferentes que van desde el Nodo1 al
Nodo3 en esta topología.

Ejemplo 6-38: Traceroute MPLS multipath desde Nodo1 a Nodo3

RP/0/0/CPU0:xrvr-1#traceroute mpls multipath ipv4 [Link]/32 source [Link] fec-type generic

Iniciando LSP Path Discovery para [Link]/32

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

L": interfaz de salida etiquetada, "B": interfaz de salida no etiquetada,
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' - código de retorno desconocido, 'x' - código de

retorno 0 Escriba la secuencia de escape para abortar.

¡LLL!
Ruta 0 encontrada,
output interface GigabitEthernet0/0/0 nexthop [Link] source
[Link] destination [Link]
¡L!
Ruta 1 encontrada,
output interface GigabitEthernet0/0/0 nexthop [Link] source
[Link] destination [Link]
¡LL!
Ruta 2 encontrada,
output interface GigabitEthernet0/0/0 nexthop [Link] source
[Link] destination [Link]
¡L!
Ruta 3 encontrada,
output interface GigabitEthernet0/0/0 nexthop [Link] source
[Link] destination [Link]
¡LLL!
Ruta 4 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]
¡L!
Ruta 5 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]
¡LL!
Ruta 6 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]
¡L!
Ruta 7 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]

Rutas (encontradas/rotas/no exploradas)

(8/0/0) Petición de eco (enviada/fallida)
(22/0)
Eco Respuesta (recibido/timeout) (22/0)
Tiempo total transcurrido 559 ms

Un servidor/VM con dirección IP [Link] está multi-homed a Nodo3 y Nodo4. Tanto Nodo3 como Nodo4
anuncian su accesibilidad al prefijo [Link]/24 en vrf SVC. Ambos nodos usan una Ruta diferente
Distinguidor (RD) para este prefijo, los RDs asignados automáticamente [Link]:1 y [Link]:0 respectivamente.
Debido a que los RDs son diferentes, el Reflector de Ruta Nodo41 ve ambas rutas como rutas diferentes y
refleja ambas rutas a sus clientes RR. El Nodo1 recibe las dos e importa ambas en la tabla BGP del vrf SVC.
En el Ejemplo 6-39 se muestran las entradas BGP para el prefijo [Link]/24 de la vrf SVC. Sólo una de las
rutas se selecciona como mejor ruta y se instala en la tabla de reenvío; ésta es la segunda ruta, vía Nodo4.

Ejemplo 6-39: Entrada en la tabla BGP del prefijo [Link]/24 en vrf SVC en Nodo1 sin multipath

RP/0/0/CPU0:xrvr-1#show bgp vrf SVC [Link]/24

Entrada en la tabla de enrutamiento BGP para [Link]/24, Distintivo de ruta:
[Link]:1 Versiones:
Proceso bRIB/RIB SendTblVer
Altavoz 27 27
Última modificación: 12 ago 10:30:12.342 para 02:26:45
Rutas: (2 disponibles, la mejor #2)
No anunciada a ningún par Ruta
#1: Recibida por el altavoz 0 No
anunciada a ningún par
41 3
[Link] de [Link] ([Link])
Etiqueta recibida 90039
Origen IGP, localpref 100, válido, externo, import-candidate, importado
Received Path ID 0, Local Path ID 0, versión 0
Comunidad ampliada: RT:1:1000
Fuente AFI: VPNv4 Unicast, VRF de origen: por defecto, Distintivo de ruta de origen:
[Link]:1
Ruta #2: Recibida por altavoz 0
No anunciada a ningún par
41 4
[Link] de [Link] ([Link])
Etiqueta recibida 90049
Origen IGP, localpref 100, valid, external, best, group-best, import-candidate, imported
ID de ruta recibida 0, ID de ruta local 0, versión
27 Comunidad extendida: RT:1:1000
Fuente AFI: VPNv4 Unicast, VRF de origen: por defecto, Distintivo de ruta de origen:
[Link]:0

Para habilitar la carga compartida entre las dos rutas, BGP multi-path debe estar habilitado bajo el vrf. Vea la
configuración en el Ejemplo 6-40. maximum-paths ebgp 16 está configurado bajo la vrf SVC
address-family ipv4 unicast. Observe en la salida del Ejemplo 6-39 que las dos rutas tienen un
AS-Path diferente: {41 3} para la primera ruta y {41 4} para la segunda ruta. Debido a esto, el
La ruta no óptima no es elegible como ruta adicional para multipath. Por lo tanto, se debe aplicar la
configuración multipath-relax bajo el vrf (línea 3 del Ejemplo 6-40) para permitir la ruta no óptima ruta
adicional en la ruta múltiple BGP.

Ejemplo 6-40: Configuración de BGP multipath en nodos Tier-1

1 vrf VPC
2 rd auto
3 bgp bestpath as-path multipath-relax
4 address-family ipv4 unicast
5 maximum-paths ebgp 16
6 red [Link]/24
7 ¡!
8 ¡!
¡9 !

El balanceo de carga multi-ruta BGP en superposición de servicio VPN añade otro nivel de reparto de carga a la
red: reparto de carga sobre los dos nodos Tier-1 en la red superpuesta de servicio y reparto de carga sobre el
tejido del Centro de Datos hacia cada nodo Tier-1 en el Tejido del Centro de Datos. El ejemplo 6-41 muestra las
dos rutas hacia el prefijo multi-homed [Link]/24 en la vrf SVC: la primera ruta en las líneas 8 a 10 y la
segunda ruta en las líneas 11 a 13.

Ejemplo 6-41: Entrada en la tabla BGP del prefijo [Link]/24 en vrf SVC en Nodo1 con multipath

1 RP/0/0/CPU0:xrvr-1#show route vrf SVC [Link]/24

2
Entrada de enrutamiento para [Link]/24
3
4 Conocido vía "bgp 1", distancia 20, métrica 0
5 Etiqueta 40, tipo externo
6 Instalado el 12 ago 10:30:12.648 para 02:27:11
7 Bloques descriptores de enrutamiento
8 [Link], desde [Link], BGP externo, BGP multitrayecto
9 Nexthop en Vrf: "default", Tabla: "default", IPv4 Unicast, Id. de tabla:
0xe0000000
10 La métrica de la ruta es 0
11 [Link], desde [Link], BGP externo, BGP multitrayecto
12 Nexthop en Vrf: "default", Tabla: "default", IPv4 Unicast, Id. de tabla:
0xe0000000
13 La métrica de la ruta es 0
14 Nada de protos publicitarios.

6.8.4 Configuración de segmentos de prefijo I-BGP

BGP-LU interno (IBGP-LU) también se puede utilizar en el Centro de Datos. Aunque el núcleo del protocolo
BGP es el mismo para EBGP e IBGP, existen diferencias en el comportamiento del protocolo entre ambos y
el comportamiento deseado de BGP para esta aplicación es el más cercano al comportamiento de EBGP. Por
lo tanto, se aplica a IBGP un comportamiento similar a EBGP. Esto significa:

Utilización de la función Route Reflector para volver a anunciar rutas entre pares

Utilizar Cluster-list para evitar bucles y asignar Cluster-ids similares a los números AS
Utilizar next-hop-self para rutas re-anunciadas.

RECORDATORIO: Funcionalidad del reflector de rutas IBGP

Para evitar bucles dentro de un Sistema Autónomo (AS), existe una regla que especifica que todos los nodos IBGP de red no deben volver a
anunciar ninguna ruta recibida de un vecino IBGP a ningún vecino IBGP. Debido a esta regla, todos los nodos IBGP del AS deben estar
conectados en una malla completa lógica para permitir la propagación de rutas a todos los nodos IBGP del AS. Sin embargo, una malla completa
no es una solución escalable. Una posible forma de eliminar la necesidad de una malla completa es utilizar Route Reflectors.

Un Route Reflector (RR) es un nodo BGP que puede anunciar actualizaciones recibidas de un peer IBGP a otro peer IBGP. Los RR se
especifican en el RFC 4456 del IETF.

Pero hay ciertas reglas bajo las cuales un RR puede reflejar una ruta. Para ello, los peers IBGP de un se dividen en dos grupos: peers clientes y
peers no clientes. Las reglas:

Una recibida de un peer cliente se refleja a sus clientes y no clientes. Una ruta recibida de un

par no cliente sólo se refleja en los pares cliente.

Cuando un RR refleja una ruta que aún no tiene un Originator-id, RR añade ese atributo en la actualización reflejada y lo establece en el BGP
router-id del nodo de origen. El RR también añade su propio Cluster-id al atributo Cluster-list de la ruta reflejada. Un nodo ignora una
actualización recibida con el Originator-id igual a su propio Router-id. Un RR ignora una actualización recibida que contenga su Cluster-id local
en el atributo Cluster-list. Este es el mecanismo de prevención de bucles utilizado cuando se utilizan RRs.

Por defecto, una RR sólo refleja la mejor ruta BGP para un prefijo.

Cuando un RR refleja una rutano debe modificar el atributo de siguiente salto, entre otros. A veces se requiere el comportamiento next-hop-self;
por lo tanto se requiere la modificación del atributo next-hop. Para asegurarse realmente de que las modificaciones de atributos no se realizan
por accidente, se debe configurar ibgp policy out enforce-modifications para permitir la modificación de atributos de rutas
reflejadas.

Las RR pueden ser al mismo tiempo clientes de otras RR, realizando así una configuración jerárquica de RR.
Una jerarquía de Route Reflector puede aplicarse naturalmente a una topología Clos. En una topología Clos de
tres niveles, los nodos de nivel 3 son los RR de nivel superior. Los nodos Tier-2 son clientes de los RRs Tier-3
y son RRs ellos mismos hacia los nodos Tier-1. En otras palabras, los nodos de nivel inferior son clientes RR
de los nodos de nivel superior. Los nodos de nivel superior son pares normales (no clientes RR) de los nodos
de nivel inferior.

El reflejo de ruta se ilustra en la topología de red de la Figura 6-21. Para simplificar la ilustración, se asume que
la ruta se convierte en el mejor camino BGP para el prefijo en cada nodo. Los mensajes de actualización BGP
se muestran en la topología parcial desplegada de la Figura 6-22. El Nodo1 envía un mensaje de actualización
BGP para su prefijo de loopback [Link]/32 al Nodo11. Como Nodo1 es un cliente RR de Nodo11, Nodo11
refleja la ruta a sus clientes RR Nodo1 y Nodo2 y a sus peers no clientes RR Nodo31 y Nodo32. El Nodo11
establece el atributo Originator-id en el mensaje de actualización al router-id del Nodo1
[Link] y añade su propio cluster-id [Link] al Cluster-list. Como el Nodo1 ve su propio router-id BGP en el
atributo Originator-id, ignora la actualización. Ambos nodos Tier-3 Nodo31 y Nodo32 actúan de forma
similar sobre el mensaje de actualización recibido, pero sólo se ilustra el reflejo de ruta del Nodo31. El
Nodo31 refleja la ruta recibida de su cliente RR Nodo11 a sus clientes RR Nodo11, Nodo12, Nodo21 y
Nodo22. El Nodo11 ve su cluster-id local 11 en la Cluster-list, por lo que ignora este mensaje de actualización.
Los otros tres nodos Tier-2 actúan igual, pero sólo se ilustra el reflejo de ruta del Nodo21. El Nodo21 recibe la
ruta de su par cliente no RR Nodo31 y sólo refleja la ruta a sus pares clientes RR Nodo3 y Nodo4.
Figura 6-21: Reflexión de rutas en topología Clos usando IBGP

Figura 6-22: Representación desplegada de una ruta en la topología de la red

Al igual que para EBGP, BGP multipath puede ser habilitado para IBGP para balancear la carga sobre múltiples
rutas de igual coste. Sin embargo, existe una limitación en la selección multipath de IBGP. Recuerde el proceso
de selección de BGP; BGP selecciona el mejor camino, siguiendo las reglas de selección del mejor camino:

1. Peso máximo

2. Mayor preferencia local

3. Longitud de la ruta de AS más corta

4. Tipo de origen más bajo

5. MED más bajo (Discriminador de salida múltiple)

6. Preferir externo a interno

7. Salida más cercana (menor distancia IGP)

8. Router-ID más bajo (Desempate)

9. Longitud más corta de la lista de clústeres (Desempate)

10. Dirección del vecino más bajo (Desempate)

La selección de rutas múltiples IBGP se detiene en la regla 7. La selección bestpath de BGP continúa hasta la
regla 10. Esto significa que todos los caminos que son iguales para las primeras 6 reglas son elegibles para
multipath. Nótese que la regla 9 que prefiere la menor longitud de Cluster-list no se considera para IBGP
multipath. La consecuencia es que un nodo puede considerar caminos menos deseables para multipath. Usando
la topología de ejemplo de la Figura 6-21, los mensajes de actualización BGP que llegan al Nodo12 se ilustran
en la Figura 6-23, junto con la entrada de la tabla para el prefijo [Link]/32 para algunos de los nodos. En la
Figura 6-23 sólo se muestra una parte de la topologí[Link]

Nodo1 anuncia el prefijo [Link]/32 a Nodo11 y Nodo12. Nodo11 refleja este prefijo a Nodo31 y Nodo32. El
Nodo12 hace lo mismo, pero esto no se ilustra. Tanto el Nodo31 como el Nodo32 seleccionan la ruta recibida
del Nodo11 como su mejor ruta. Los dos caminos son iguales hasta la regla 9 de selección del mejor camino
(ver arriba), por lo tanto el mejor camino se selecciona basándose en la dirección vecina más baja, que es la
utilizada por el Nodo11. Tanto el Nodo31 como el Nodo32 anuncian su mejor camino hacia el Nodo12, por lo
que el Nodo12 tiene tres caminos utilizables hacia [Link]/32. De ellos, selecciona el mejor camino hacia el
Nodo12. De ellos, selecciona el mejor camino basado en la lista de grupos más corta (regla 9): el camino
directo a través de Nodo1. Sin embargo, los otros caminos son elegibles para multipath ya que tienen los
mismos atributos hasta la regla 7. Esto hace que el Nodo2 equilibre la carga de tráfico hacia
[Link] /32 a través de tres rutas, las tres rutas BGP para [Link]/32. Esto es altamente indeseable ya
conduce a rutas no óptimas y bucles de paquetes.
Figura 6-23: Problema de rutas múltiples IBGP

Hay varias soluciones posibles para este problema. Una posible solución podría ser utilizar el mismo
identificador de clúster en los nodos Tier-2 del mismo clúster. El último "cluster" de la frase anterior se utiliza
en sentido de un conjunto de dispositivos Tier-1 y Tier-2 conectados directamente junto con sus servidores
conectados. Si el Nodo11 y el Nodo12 utilizan el mismo cluster-id 10, entonces ignoran las rutas que el Nodo31
y el Nodo32 reflejan hacia ellos. El Nodo12 sólo tiene una ruta a [Link]/32: vía Nodo1.

Otra posible solución es incrementar una métrica cada vez que se refleja una ruta. Esta métrica puede ser
cualquier atributo que influya en la selección del mejor camino. En este ejemplo, se utiliza el IGP
Acumulado (AIGP).

IETF RFC 7311 especifica AIGP. El uso del atributo AIGP permite a BGP utilizar la métrica IGP para la
selección de la mejor ruta, lo que facilita la selección de la mejor ruta BGP en una red multi-AS bajo una
administración común. Cuando se utiliza AIGP, se prefiere la ruta con la métrica AIGP más baja antes de
considerar la longitud AS-path de esa ruta, por lo que entre los pasos de Preferencia Local y Longitud AS-path en
las reglas de selección de mejor ruta BGP. A falta de IGP en una red sólo BGP, la métrica AIGP incrementarse
estáticamente en su lugar.
La selección del mejor camino BGP prefiere el camino con la métrica AIGP más baja y sólo los caminos con
la misma métrica AIGP que el mejor camino BGP son elegibles para la selección multitrayecto.

Cuando se incrementa la métrica AIGP al anunciar una ruta, se selecciona un camino similar a la selección del
camino más corto en IGP.

La configuración completa IBGP-LU se analiza en base a la topología de la Figura 6-24.

Figura 6-24: Ejemplo de topología de red SR IBGP

La configuración BGP del Nodo Tier-13 se muestra en el Ejemplo 6-42. La salida comienza con las
políticas de ruta que son usadas. SID($SID) para establecer el índice SID a $SID y
ADDMETRIC($METRIC) para incrementar la métrica AIGP con el valor $METRIC. La sentencia RPL
set aigp-metric+ $METRIC añade $METRIC al valor actual de aigp-metric.

De forma similar a EBGP, las sesiones IBGP se establecen entre direcciones de interfaz, y se requiere una ruta
estática a la dirección de interfaz del vecino para resolver las rutas BGP-LU. A diferencia de EBGP-LU,
MPLS no está habilitado por defecto para las sesiones IBGP-LU entre interfaces conectadas. MPLS es
habilitado manualmente en las interfaces peering agregándolas bajo la configuración mpls activate
(líneas 12 a 14). Al contrario que EBGP, IBGP no requiere aplicar políticas de ruta de entrada y salida, sólo se
aplica una política de ruta de salida para incrementar la métrica AIGP (ver línea 23 donde la métrica AIGP se
incrementa en 10). IBGP multipath está habilitado por maximum-paths ibgp 16 en la línea 17.
Ejemplo 6-42: Configuración IBGP del Nodo3

1 política de ruta SID($SID)

2 set label-index $SID
3 fin de la política
4 ¡!
5 route-policy ADDMETRIC($METRIC)
6 set aigp-metric+ $METRIC
7 pase
8 fin de la política
9 ¡!
10 router bgp 1
11 bgp router-id [Link]
12 mpls activar
13 interfaz GigabitEthernet0/0/0/0
14 interfaz GigabitEthernet0/0/0/1
15 ¡!
16 address-family ipv4 unicast
17 maximum-paths ibgp 16
18 network [Link]/32 route-policy SID(3)
19 asignar-etiquetar todo
20 ¡!
21 neighbor-group TIER2
22 address-family ipv4 labeled-unicast
23 route-policy ADDMETRIC(10) out
24 ¡!
25 ¡!
26 vecino [Link]
27 remoto-as 1
28 use neighbor-group TIER2
29 descripción iBGP peer xrvr-21
30 ¡!
31 vecino [Link]
32 remoto-as 1
33 use neighbor-group TIER2
34 description iBGP peer xrvr-22
35 ¡!
¡36 !
37 enrutamiento por segmentos
38 bloque global 16000 23999
¡39 !

La configuración BGP del Nodo Leaf21 se muestra en el Ejemplo 6-43. Nodo21 tiene dos neighbor-groups
configurados, uno para las sesiones IBGP a los nodos Tier-1 (TIER1 en la línea 15) y otro para las sesiones
IBGP a los nodos Tier-3 (TIER3 en la línea 22). Los vecinos Tier-1 están configurados como clientes RR
(ver línea 17), y next-hop-self está configurado para estas sesiones (ver línea 19). Router Reflectores
no debe modificar atributos BGP como el atributo BGP Nexthop. Es necesario habilitar un comando de
salvaguarda para permitir que se aplique next-hop-self: ibgp policy out enforce-
modificaciones en la línea 9. Los vecinos Tier-3 no están configurados como clientes RR, pero el next-
hop-self está habilitado. Para todos los vecinos, la métrica AIGP de cada ruta se incrementa en 10 cuando se
anuncia.

Ejemplo 6-43: Configuración IBGP del Nodo21

1 router bgp 1
2 bgp router-id [Link]
3 mpls activar
4 interfaz GigabitEthernet0/0/0/0
5 interfaz GigabitEthernet0/0/0/1
6 interfaz GigabitEthernet0/0/0/2
7 interfaz GigabitEthernet0/0/0/3
8 ¡!
9 ibgp policy out enforce-modifications
10 address-family ipv4 unicast
11 maximum-paths ibgp 16
12 network [Link]/32 route-policy SID(21)
13 asignar-etiquetar todo
14 ¡!
15 neighbor-group TIER1
16 address-family ipv4 labeled-unicast
17 ruta-reflector-cliente
18 route-policy ADDMETRIC(10) out
19 next-hop-self
20 ¡!
21 ¡!
22 neighbor-group TIER3
23 address-family ipv4 labeled-unicast
24 route-policy ADDMETRIC(10) out
25 next-hop-self
26 ¡!
27 ¡!
28 vecino [Link]
29 remoto-as 1
30 use neighbor-group TIER1
31 descripción iBGP peer xrvr-3
32 ¡!
33 vecino [Link]
34 remoto-as 1
35 use neighbor-group TIER1
36 description iBGP peer xrvr-4
37 ¡!
38 vecino [Link]
39 remoto-as 1
40 use neighbor-group TIER3
41 descripción iBGP peer xrvr-31
42 ¡!
43 vecino [Link]
44 remoto-as 1
45 use neighbor-group TIER3
46 descripción iBGP peer xrvr-32
47 ¡!
¡48 !

La configuración BGP del Nodo31 se muestra en el Ejemplo 6-44. Nodo31 tiene un neighbor-groups
configurado para los vecinos Tier-2 (TIER2 en la línea 15). Estos vecinos están configurados como clientes de
Route Reflector y la opción next-hop-self está activada.
Ejemplo 6-44: Configuración IBGP del Nodo31

1 router bgp 1
2 bgp router-id [Link]
3 mpls activar
4 interfaz GigabitEthernet0/0/0/0
5 interfaz GigabitEthernet0/0/0/1
6 interfaz GigabitEthernet0/0/0/2
7 interfaz GigabitEthernet0/0/0/3
8 ¡!
9 ibgp policy out enforce-modifications
10 address-family ipv4 unicast
11 maximum-paths ibgp 16
12 network [Link]/32 route-policy SID(31)
13 asignar-etiquetar todo
14 ¡!
15 neighbor-group TIER2
16 address-family ipv4 labeled-unicast
17 ruta-reflector-cliente
18 route-policy ADDMETRIC(10) out
19 next-hop-self
20 ¡!
21 ¡!
22 vecino [Link]
23 remoto-as 1
24 use neighbor-group TIER2
25 descripción iBGP peer xrvr-11
26 ¡!
27 vecino [Link]
28 remoto-as 1
29 use neighbor-group TIER2
30 descripción iBGP peer xrvr-12
31 ¡!
32 vecino [Link]
33 remoto-as 1
34 use neighbor-group TIER2
35 descripción iBGP peer xrvr-21
36 ¡!
37 vecino [Link]
38 remoto-as 1
39 use neighbor-group TIER2
40 description iBGP peer xrvr-22
41 ¡!
¡42 !

Las configuraciones de los otros nodos son similares a las configuraciones anteriores. En el Ejemplo 6-45 se
muestra la entrada BGP para el prefijo [Link]/32 en el Nodo1. Hay dos rutas disponibles, una vía Nodo11
(líneas 10 a 20), y una vía Nodo12 (líneas 21 a 31). BGP ha seleccionado la primera ruta como bestpath ya
que tiene la dirección de vecino más baja, y la otra ruta está seleccionada para BGP multipath. La métrica
AIGP para ambos caminos es 40. El cluster-list del primer camino es [Link], [Link],
[Link] que indica que ha sido reflejado por Nodo21, Nodo31 y Nodo11.

Ejemplo 6-45: Entrada en la tabla BGP del prefijo [Link]/32 en Nodo1

1 RP/0/0/CPU0:xrvr-1#show bgp ipv4 labeled-unicast [Link]/32

2 Entrada en la tabla de enrutamiento BGP para [Link]/32
3 Versiones:
4 Proceso bRIB/RIB SendTblVer
5 Altavoz 123 123
6 Etiqueta local: 16003
7Última modificación: Aug 16 14:43:23.342 para 00:30:22
8 Caminos: (2 disponibles, mejor el nº 1)
9 No se anuncia a ningún homólogo
10 Ruta nº 1: Recibido por el altavoz 0
11 No se anuncia a ningún homólogo
12 Local
13 [Link] de [Link] ([Link])
14 Etiqueta recibida 16003
15 Origen IGP, métrica 0, localpref 100, aigp métrica 40, valid, internal, best, group-
best, multipath
16 ID de ruta recibida 0, ID de ruta local 0, versión 123
17 Originador: [Link], Lista de grupos: [Link], [Link], [Link]
18 Total métrica AIGP 40
19 Prefijo SID Tamaño del atributo: 10
20 Índice de etiquetas: 3
21 Ruta #2: Recibido por el altavoz 0
22 No se anuncia a ningún homólogo
23 Local
24 [Link] de [Link] ([Link])
25 Etiqueta recibida 16003
26 Origen IGP, métrica 0, localpref 100, aigp métrica 40, válido, interno,
multipath
27 ID de ruta recibida 0, ID de ruta local 0, versión 0
28 Originador: [Link], Lista de grupos: [Link], [Link], [Link]
29 Total métrica AIGP 40
30 Prefijo SID Tamaño del atributo: 10
31 Índice de etiquetas: 3

Ambas rutas están instaladas en RIB (ver Ejemplo 6-46) y FIB (ver Ejemplo 6-49) en Nodo1.
Ejemplo 6-46: Entrada RIB del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show route [Link]/32 Entrada de

enrutamiento para [Link]/32

Conocido vía "bgp 1", distancia 200, métrica 40, [ei]-bgp, etiquetado unicast (3107) (métrica
AIGP), etiquetado SR, tipo interno
Instalado 16 ago 14:43:23.802 para 00:36:38
Bloques descriptores de enrutamiento
[Link], desde [Link], BGP multi ruta La
métrica de la ruta es 40
[Link], desde [Link], BGP multi ruta La
métrica de la ruta es 40
Nada de protos publicitarios.

Ejemplo 6-47: Entrada CEF del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

[Link]/32, versión 1270, interno 0x5000001 0x80 (ptr 0xa141b1f4) [1], 0x0
(0xa13e5c44), 0xa08 (0xa1758260)
Actualizado el 16 de agosto a las 14:43:23.822
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 4
vía [Link]/32, 5 dependencias, recursivo, bgp-multipath [flags 0x6080] path-idx
0 NHID 0x0 [0xa15eb6f4 0x0].
recursividad-via-/32
siguiente salto [Link]/32 vía 24000/0/21
etiqueta local 16003
siguiente salto [Link]/32 GIO/0/0/0 etiquetas impuestas {ImplNull 16003}
vía [Link]/32, 5 dependencias, recursivo, bgp-multipath [flags 0x6080] path-idx
1 NHID 0x0 [0xa15eb7f4 0x0].
recursividad-via-/32
siguiente salto [Link]/32 vía 24007/0/21
etiqueta local 16003
siguiente salto [Link]/32 Gi0/0/0/1 etiquetas impuestas {ImplNull 16003}

La configuración del servicio overlay es muy similar a la configuración para el caso EBGP. La configuración
del servicio L3VPN del nodo Tier-1 Nodo3 se muestra en el Ejemplo 6-48. IBGP multi-path también está
habilitado en el servicio superpuesto; ver línea 27. Ambos Nodo3 y Nodo4 anuncian el prefijo vrf SVC
[Link]/24.
Ejemplo 6-48: Configuración BGP para servicio L3VPN en Nodo3

1 vrf VPC
2 address-family ipv4 unicast
3 importar ruta-objetivo
4 1:1000
5 ¡!
6 export ruta-objetivo
7 1:1000
8 ¡!
9 ¡!
¡10 !
11 router bgp 1
12 address-family vpnv4 unicast
13 ¡!
14 neighbor-group ROUTE_REFLECTORS
15 remoto-as 1
16 update-source Loopback0
17 address-family vpnv4 unicast
18 ¡!
19 ¡!
20 vecino [Link]
21 use neighbor-group ROUTE_REFLECTORS
22 descripción servicio RR Nodo41
23 ¡!
24 vrf VPC
25 rd auto
26 address-family ipv4 unicast
27 maximum-paths ibgp 16
28 red [Link]/24
29 ¡!
30 ¡!
¡31 !

El Ejemplo 6-47 muestra la configuración BGP para la superposición de servicios en el Nodo Reflector
Router41. No se muestra la configuración para la conectividad subyacente. El grupo de vecinos RR_CLIENTS
de la línea 5 es para los vecinos de servicio L3VPN, utilizando address-family vpnv4 unicast. Estos
vecinos de servicio L3VPN están configurados como clientes de Route Reflector.
Ejemplo 6-49: Configuración BGP para el servicio L3VPN en el Nodo RR de Servicio41

1 router bgp 1
2 bgp router-id [Link]
3 address-family vpnv4 unicast
4 ¡!
5 neighbor-group RR_CLIENTS
6 remoto-as 1
7 update-source Loopback0
8 address-family vpnv4 unicast
9 ruta-reflector-cliente
10 ¡!
11 ¡!
12 vecino [Link]
13 use grupo de vecinos RR_CLIENTS
14 ¡!
15 vecino [Link]
16 use grupo de vecinos RR_CLIENTS
17 ¡!
18 vecino [Link]
19 use grupo de vecinos RR_CLIENTS
20 ¡!
21 vecino [Link]
22 use grupo de vecinos RR_CLIENTS
23 ¡!
¡24 !

El prefijo vpnv4 BGP [Link]/24 en vrf SRV en Nodo1 se muestra en el Ejemplo 6-50. Tanto Nodo3 como
Nodo4 anuncian este prefijo. Tanto Nodo3 como Nodo4 anuncian este prefijo, por lo tanto Nodo1 tiene dos
rutas hacia ese prefijo: una vía Nodo3 (nexthop [Link]) y otra vía Nodo4 (nexthop [Link]). La etiqueta 90039
(línea 13) la etiqueta agregada para la vrf SVC asignada por el Nodo3 para esta vrf. Nodo4 asignó la etiqueta
90049 (línea 23) para este prefijo.
Ejemplo 6-50: Entrada en la tabla BGP del prefijo multi-homed [Link]/24 en vrf SVC en Nodo1

1 RP/0/0/CPU0:xrvr-1#show bgp vrf SVC [Link]/24

2 Entrada en la tabla de enrutamiento BGP para [Link]/24, Distintivo de ruta: [Link]:0
3 Versiones:
4 Proceso bRIB/RIB SendTblVer
5 Altavoz 6 6
6 Última modificación: Aug 17 12:09:06.342 para 00:00:05
7 Caminos: (2 disponibles, mejor el nº 1)
8 No se anuncia a ningún homólogo
9 Ruta #1: Recibido por el altavoz 0
10 No se anuncia a ningún homólogo
11 Local
12 [Link] (métrica 40) de [Link] ([Link])
13 Etiqueta recibida 90039
14 Origen IGP, métrica 0, localpref 100, válido, interno, best, group-best,
multipath, import-candidate, importado
15 ID de ruta recibida 0, ID de ruta local 0, versión 6
16 Comunidad ampliada: RT:1:1000
17 Originador: [Link], Lista de grupos: [Link]
18 Fuente AFI: VPNv4 Unicast, VRF de origen: por defecto, Distintivo de ruta de origen:
[Link]:0
19 Ruta #2: Recibido por el altavoz 0
20 No se anuncia a ningún homólogo
21 Local
22 [Link] (métrica 40) de [Link] ([Link])
23 Etiqueta recibida 90049
24 Origen IGP, métrica 0, localpref 100, válido, interno, multipath, import-
candidato, importado
25 ID de ruta recibida 0, ID de ruta local 0, versión 0
26 Comunidad ampliada: RT:1:1000
27 Originador: [Link], Lista de grupos: [Link]
28 Fuente AFI: VPNv4 Unicast, VRF de origen: por defecto, Distintivo de ruta de origen:
[Link]:0

El ejemplo 6-50 muestra la entrada vrf SVC RIB para el prefijo [Link]/24. Hay dos rutas disponibles: vía
Nodo3 y vía Nodo4. Hay dos rutas disponibles: vía Nodo3 y vía Nodo4.
Ejemplo 6-51: Entrada RIB del prefijo multi-homed [Link]/24 en vrf SVC en Nodo1

RP/0/0/CPU0:xrvr-1#show route vrf SVC [Link]/24 Entrada

de enrutamiento para [Link]/24

Conocido vía "bgp 1", distancia 200, métrica 0, tipo interno
Instalado el 17 ago 12:09:06.207 para 00:00:51
Bloques descriptores de enrutamiento
[Link] desde [Link], ruta múltiple BGP
Nexthop en Vrf: "default", Tabla: "default", IPv4 Unicast, Id. de tabla: 0xe0000000 La
métrica de la ruta es 0
[Link] desde [Link], ruta múltiple BGP
Nexthop en Vrf: "default", Tabla: "default", IPv4 Unicast, Id. de tabla: 0xe0000000 La
métrica de la ruta es 0
Nada de protos publicitarios.
6.9 Resumen
Los SR BGP Prefix-SIDs pueden utilizarse para varios diseños de despliegue como la conectividad
MPLS de extremo a extremo inter-AS (o inter-dominio), o Centros de Datos basados en BGP.

El mecanismo BGP Labeled-Unicast (RFC 3107) se ha ampliado para la señalización del BGP Prefix-
SID

SR BGP interopera con implementaciones no SR BGP-LU y puede habilitarse sin problemas en una red
existente para la migración a SR.

SR BGP facilita la introducción de MPLS en el centro de datos y proporciona ventajas adicionales.

6.10 Referencias
[draft-ietf-idr-bgp-prefix-sid] Previdi, S., Filsfils, C., Lindem, A., Patel, K., Sreekantiah, A., Ray, S., y H.
Gredler, "Segment Routing Prefix SID extensions for BGP", draft-ietf-idr-bgp-prefix- sid (work in
progress), junio de 2016, [Link]

[draft-ietf-spring-oam-usecaseietf-spring-oam-usecase, septiembre de 2016,

[Link] usecase.] Geib, R., Ed., Filsfils, C., Pignataro, C.,
Ed., y N. Kumar, "A Scalable and Topology-Aware MPLS Dataplane Monitoring System", Work in
Progress, draft-

[draft-ietf-spring-segment-routing-msdc] Filsfils, C., Previdi, S., Mitchell, J., Aries, E., y P. Lapukhov,
"BGP-Prefix Segment in large-scale data centers", draft-ietf-spring-segment-routing- msdc-01 (work in
progress), abril de 2016, [Link] segment-routing-msdc-01.

[draft-ietf-spring-sr-oam-requirementietf-spring-sr-oam-requirement, julio de 2016,

[Link] oam-requirement.] Kumar, N., Pignataro, C., Akiya,
N., Geib, R., Mirsky, G. y S. Litkowski, "OAM Requirements for Segment Routing Network", Work in
Progress, draft-

[FLOWLET] Sinha, S., Kandula, S. y D. Katabi, "Harnessing TCP's Burstiness with Flowlet Switching",
2004.

[RFC2283] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP- 4", RFC
2283, DOI 10.17487/RFC2283, febrero de 1998, [Link] obsoluted by
RFC4760.

[RFC3107] Rekhter, Y. y E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI
10.17487/RFC3107, mayo de 2001, [Link]

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., y S. Hares, Ed., "A Border Gateway Protocol 4 (BGP- 4)", RFC
4271, DOI 10.17487/RFC4271, enero de 2006, [Link]

[RFC4364] Rosen, E. e Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI
10.17487/RFC4364, febrero de 2006, [Link]

[RFC4456] Bates, T., Chen, E., y R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal
BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, abril de 2006,
[Link]

[RFC4760] Bates, T., Chandra, R., Katz, D. e Y. Rekhter, "Multiprotocol Extensions for BGP- 4", RFC 4760,
DOI 10.17487/RFC4760, enero de 2007, [Link]

[RFC7311] Mohapatra, P., Fernando, R., Rosen, E. y J. Uttaro, "The Accumulated IGP Metric Attribute for
BGP", RFC 7311, DOI 10.17487/RFC7311, agosto de 2014, [Link]

[RFC7938] Lapukhov, P., Premji, A., y J. Mitchell, Ed., "Use of BGP for Routing in Large- Scale Data
Centers", RFC 7938, DOI 10.17487/RFC7938, agosto de 2016, [Link]

1 En un tejido no bloqueante siempre hay disponible una ruta a plena velocidad entre dos servidores,
independientemente de qué otras rutas existan en ese momento.
7 ENRUTAMIENTO DE SEGMENTOS EN
REDES MPLS EXISTENTES
Uno de los objetivos del Segment Routing ha sido simplificar los protocolos y mecanismos necesarios para
hacer funcionar el MPLS existente, añadiendo al mismo tiempo nuevas capacidades de protección e ingeniería
de tráfico. El despliegue de MPLS está muy extendido en la actualidad, por lo que la introducción de la
tecnología de enrutamiento por segmentos en las redes existentes debe realizarse de forma sencilla y sin
interrupciones de los servicios. Éste ha sido siempre un requisito fundamental para las personas implicadas en
el desarrollo de la tecnología de Segment Routing desde el principio. En su mayor parte, las funciones básicas
de Enrutamiento por Segmentos habilitarse con una simple actualización de software, ya que el plano de
reenvío MPLS está apalancado, como se ha visto anteriormente en el capítulo 7, "Enrutamiento por Segmentos
en Redes MPLS Existentes".

En este capítulo examinaremos las opciones de despliegue y los mecanismos disponibles para la introducción
del Segment Routing en las redes MPLS existentes. Para empezar, examinamos los modelos de despliegue de
alto nivel. Estos modelos pueden ser mixtos, ya sea sólo durante un periodo de transición o de forma más
permanente.

En el primer enfoque, el encaminamiento por segmentos y otros protocolos MPLS coexisten uno junto al otro
como "barcos en la noche". El Segment Routing puede introducirse sin interrumpir los servicios existentes.
Los nuevos servicios pueden desplegarse utilizando el encaminamiento por segmentos, dejando los servicios
existentes en su transporte actual. Estos existentes ya pueden beneficiarse de la funcionalidad de Enrutamiento
por Segmentos, como la protección de redireccionamiento rápido LFA independiente de la topología (veremos
más detalles respecto en el capítulo 9, "LFA independiente de la topología (TI-LFA)"). Los servicios existentes
entonces migrar gradualmente para utilizar el transporte de Enrutamiento por Segmentos, migrando finalmente
a una red sólo de Enrutamiento por Segmentos. Algunos servicios podrían mantenerse en su transporte actual,
si fuera necesario, forma más permanente. Este planteamiento de migración se principalmente en la
consideración de los servicios y sus transportes, suponiendo que todos los encaminadores ofrezcan flexibilidad
para soportar el transporte de encaminamiento por segmentos existente y el más reciente.

En el segundo enfoque, Segment Routing y LDP funcionan entre . Esta funcionalidad de interfuncionamiento
permite actualizar gradualmente y habilitar el enrutamiento por segmentos en los routers para la mayor de la
red, mientras se dejan los equipos heredados (sin soporte de software de enrutamiento por segmentos) en su
lugar, ejecutando LDP. La mayor parte de la red puede beneficiarse de las capacidades de Segment Routing
mientras que
dando tiempo para la sustitución de los dispositivos heredados en producción. Tenga en cuenta que para
aprovechar algunas de aplicaciones más nuevas y avanzadas del Enrutamiento por Segmentos, como la
Ingeniería de Tráfico (que veremos en la siguiente parte de este libro), puede ser necesario realizar también
actualizaciones de hardware en routers específicos de la red. Este enfoque de migración se basa en
consideración de las plataformas de routers desplegadas en la red, sus posiciones o funciones y sus
capacidades.

Combinando estos dos enfoques son posibles diferentes modelos de despliegue. El enrutamiento por segmentos
ofrece la flexibilidad necesaria para introducirlo en cualquiera de estos modelos diferentes en función de la
combinación de servicios, transportes y consideraciones sobre la plataforma de enrutamiento.

DESTACADO: Despliegue de enrutamiento por segmentos en redes MPLS existentes

Las funciones básicas de Segment Routing habilitarse mediante actualización de software en la mayoría de las plataformas de
enrutamiento; las actualizaciones de hardware pueden ser necesarias sólo en determinadas aplicaciones avanzadas y también en
enrutadores específicos de la red.

El transporte de enrutamiento por segmentos puede introducirse en una red para determinados servicios nuevos o para un subconjunto
de servicios existentes, mientras que otros servicios existentes siguen funcionando utilizando sus mecanismos de transporte actuales;
modelo "barco en la noche".

Las funciones de Enrutamiento por Segmentos pueden habilitarse en una red que tenga equipos heredados no soporten el
Enrutamiento por Segmentos; el interfuncionamiento LDP permite el uso del Enrutamiento por Segmentos para servicios en dichas
redes.

En el resto de este , veremos más de cerca cómo el Enrutamiento por Segmentos coexiste e interactúa con las
tecnologías de transporte MPLS tradicionales.
7.1 Coexistencia de SR y otros protocolos MPLS
7.1.1 Coexistencia del plano de control
En un nodo pueden ejecutarse simultáneamente varios protocolos de distribución de etiquetas MPLS.
Pueden coexistir como naves en la noche y sus mecanismos de plano de control son independientes. La
arquitectura MPLS permite el uso simultáneo de LDP, RSVP-TE, Segment Routing y otros. Esto no es nada
nuevo; la coexistencia del plano de control MPLS existe desde los inicios de MPLS.

En cada nodo existe una función de plano de control MPLS ("Label Manager") que garantiza que las etiquetas
locales utilizadas por diferentes protocolos de distribución de etiquetas no colisionen; garantiza que las
etiquetas locales se asignen y asignen de forma única.

Para los Segmentos Globales de Enrutamiento de Segmentos, como los Segmentos de Prefijo, se reserva un
rango de etiquetas locales: el SRGB. El Gestor de Etiquetas de cada nodo garantiza que las etiquetas de este
rango se utilicen exclusivamente para estos Segmentos Globales SR.

Para los protocolos de distribución de etiquetas MPLS (por ejemplo, LDP, RSVP-TE, BGP, etc.) que utilizan
etiquetas dinámicas aleatorias, o para los Segmentos Locales de Enrutamiento de Segmentos, como los
Segmentos de Adyacencia IGP o los Segmentos de Peer BGP, el Gestor de Etiquetas garantiza que cada etiqueta
local es localmente única, que cada etiqueta local se asigna y se asigna una sola vez.

El Label Manager de cada nodo sólo puede gestionar localmente la asignación de etiquetas. Para los
Segmentos Globales, es responsabilidad del operador asegurarse de que cada Segmento Global obtiene un
índice SID que es único dentro del Dominio de Enrutamiento de Segmentos. Cada índice SID global único se
traduce entonces en una etiqueta local única para ese Segmento Global en cada .

DESTACADO: Coexistencia de protocolos de plano de control MPLS

La arquitectura MPLS siempre ha permitido que múltiples protocolos como LDP, RSVP-TE, BGP y otros funcionen de
forma independiente; lo mismo ocurre con los protocolos de plano de control de enrutamiento por segmentos como ISIS,
OSPF y BGP.

El gestor de etiquetas garantiza que las etiquetas dinámicas señalizadas no colisionen; SRGB garantiza que el espacio de etiquetas de los
segmentos globales SR esté reservado exclusivamente para él.
7.1.2 Coexistencia del plano de datos
En un nodo pueden coexistir varios protocolos de distribución de etiquetas MPLS. La función Label Manager se
encarga de la unicidad de las etiquetas asignadas localmente. Esta asignación única de etiquetas locales
garantiza que puedan coexistir trayectos conmutados por etiquetas instalados por distintos protocolos de plano
de control MPLS. Pueden distinguirse dos casos: (1) el paquete entrante es un paquete etiquetado (MPLS-a-
MPLS o MPLS-a-IP), y
(2) la etiqueta entrante es un paquete no etiquetado (IP-to-MPLS). Aunque las referencias aquí son para IPv4, lo
mismo se aplica también para IPv6.

[Link] MPLS a MPLS, MPLS a IP

En el plano de datos, pueden coexistir varias entradas de reenvío MPLS a MPLS o MPLS a IP, incluso si se
dirigen al mismo prefijo de destino. los valores de las etiquetas locales o entrantes sean localmente únicos, no
habrá conflictos ni interferencias.

Un paquete llega con una etiqueta específica en la parte superior de su pila de etiquetas. Esa etiqueta tiene una
entrada única en la tabla de reenvío MPLS del nodo receptor y el reenvío se realiza basándose en esa entrada
única. El gestor de etiquetas garantiza la unicidad de cada etiqueta local.

No es necesario que las etiquetas salientes de las entradas de reenvío MPLS a MPLS sean únicas, ya que las
etiquetas salientes sólo son significativas para el vecino descendente, el vecino al que se reenvía el paquete, no
para el nodo local.

Múltiples entradas de reenvío MPLS-to-MPLS y MPLS-to-IP pueden coexistir para el mismo destino - por
ejemplo, en caso de que exista un segmento de prefijo así como un LSP LDP hacia el mismo prefijo de
destino. Aunque estén asociadas al mismo prefijo de destino en el plano de control, cada protocolo del plano
de control programa independientemente su entrada como una entrada de conexión cruzada de etiquetas
("label in to label out"), cada una con su etiqueta local única.

La Figura 7-1 ilustra la coexistencia en el plano de datos de entradas de reenvío MPLS instaladas por Segment
Routing y entradas MPLS instaladas por otros protocolos de distribución de etiquetas MPLS. El otro protocolo
MPLS es LDP en este ejemplo, pero puede ser cualquier otro protocolo MPLS como RSVP-TE, o BGP- LU,
etc.
Figura 7-1: Coexistencia de MPLS a MPLS y de MPLS a IP

La topología de la red es una cadena de nodos. La ruta a través de los nodos se seguirá desde el Nodo1 hasta el
Nodo5. La tabla de reenvío MPLS de cada nodo se muestra debajo del nodo, con la etiqueta entrante o local en
la columna de la izquierda, y la etiqueta saliente en la columna de la derecha. La tabla de etiquetas está
ordenada con valores de etiquetas locales incrementales. El rango de etiquetas utilizables en Cisco IOS XR
para estos protocolos es de 16000 a 1 millón. Las etiquetas inferiores a están reservadas en Cisco IOS XR para
entradas de etiquetas estáticas y etiquetas de propósito especial. Todos los nodos de esta topología tienen
activados tanto Segment Routing como LDP.

Nodo1, Nodo2 y Nodo4 han asignado el SRGB por defecto, de 16000 a 23999. Aunque la recomendación es
"usar el mismo SRGB en todos los nodos", el Nodo3 ha asignado un SRGB diferente a efectos ilustrativos. El
SRGB del Nodo3 empieza en 24000 y llega hasta 31999.

El Nodo5 anuncia su prefijo de loopback [Link]/32 con un Prefijo-SID asociado de índice 5. Se solicita el
comportamiento por defecto de PHP para este Prefix-SID. En Nodo1, Nodo2, y Nodo4 este Prefijo-SID tiene un
valor de etiqueta local de 16005 (=16000+ 5). En Nodo3 el valor de la etiqueta local de este prefijo-SID es
24005 (=24000 + 5).
La Figura 7-1 muestra las entradas de reenvío de etiquetas que se utilizan cuando se reenvía un paquete en
el Segmento Prefijo al Nodo5. Cuando un paquete entra en el Nodo1 con una etiqueta superior 16005, será
reenviado usando las entradas de reenvío de etiquetas resaltadas hasta que la etiqueta sea saltada en el
penúltimo salto Nodo4.
A continuación, el Nodo5 procesa el paquete basándose en la cabecera del paquete que queda expuesta
después de que el Nodo4 haya quitado la etiqueta superior.

Todos los nodos también asignan y anuncian una etiqueta LDP para el prefijo loopback del Nodo5, [Link]/32.
La Figura 7-1 muestra las entradas de reenvío de etiquetas que se utilizan cuando se reenvía un paquete en la
Ruta Conmutada por Etiquetas LDP al destino en el Nodo5.

Cuando un paquete entra en el Nodo1, con una etiqueta superior 90002, que es la etiqueta LDP local asignada
por el Nodo1 para el prefijo loopback del Nodo5, es reenviado con las entradas de reenvío de etiqueta
resaltadas hasta que la etiqueta es saltada en el penúltimo salto Nodo4. A continuación, el Nodo5 procesa el
paquete basándose en la cabecera recién expuesta.

Dado que el gestor local de etiquetas de cada nodo gestiona la asignación local de etiquetas, se garantiza que
estas etiquetas locales sean únicas. Dado que sus etiquetas locales o entrantes catalogan las entradas de
reenvío MPLS a MPLS y MPLS a IP, estas entradas de reenvío MPLS pueden coexistir, independientemente
de las aplicaciones MPLS que hayan instalado cada entrada de reenvío. Los paquetes transportados por
entradas de reenvío MPLS instaladas por diferentes protocolos de distribución de etiquetas MPLS son como
barcos en la noche.

El ejemplo mostraba la coexistencia de entradas de reenvío de etiquetas de Segment Routing y LDP, pero la
coexistencia del plano de control y el plano de datos MPLS también se aplica a las etiquetas MPLS distribuidas
por cualquier otro protocolo de distribución de etiquetas MPLS, como RSVP-TE y BGP Labeled Unicast.

[Link] IP a MPLS
Cuando un paquete IP llega al nodo de entrada de una red MPLS, el paquete se clasifica en una Clase de
Equivalencia de Reenvío. A continuación, se impone una etiqueta al paquete, dependiendo de la FEC del
paquete. Por defecto, la clasificación de paquetes en una FEC se basa en la coincidencia del prefijo más largo
de la dirección de destino del paquete. Esta clasificación por defecto de los paquetes y la imposición de
etiquetas a esos paquetes es el tema de esta sección. Es posible una clasificación más granular de los paquetes
o una clasificación basada en otros elementos que no sean la dirección de destino, pero esto queda fuera del
alcance de esta sección y esas reglas de clasificación no se ven realmente afectadas o modificadas por la
introducción del Enrutamiento por Segmentos.
Cuando un paquete IP llega al nodo de entrada de la red MPLS, se realiza una búsqueda del prefijo de mayor
coincidencia para la dirección de destino en la tabla de reenvío, la Forwarding Information Base (FIB).
Esta búsqueda da como resultado una única entrada en la FIB, el prefijo que coincide con el prefijo más largo
de la FIB para la dirección de destino del paquete. Cada entrada FIB tiene una o múltiples rutas de igual
coste que llevan al destino. Si existen varias rutas de igual coste para un prefijo, el tráfico destinado a ese
prefijo se reparte entre las rutas disponibles. Cada una de estas rutas de prefijo tiene una única entrada de
etiqueta saliente que contiene la etiqueta que se impone a los paquetes reenviados por esa ruta.
Normalmente se impondría una única etiqueta por ruta de prefijo.

En un entorno mixto de Enrutamiento por Segmentos y LDP en el que se puede llegar a un destino a través de
un Segmento de Prefijo así como a través de un LSP LDP, sólo se puede programar una entrada de imposición
de etiqueta para ruta de prefijo de destino. Se puede imponer una de Enrutamiento de Segmento o una etiqueta
LDP a los paquetes reenviados en esa ruta de prefijo. Si existen múltiples rutas de igual coste al destino, cada
una de las rutas de prefijo individuales puede tener una entrada de imposición de etiqueta Segment Routing o
LDP, independientemente de las otras rutas de prefijo del mismo prefijo. Primero echaremos un vistazo al
escenario más simple en el que la(s) ruta(s) es(son) de un único protocolo y más adelante en la sección 7.2,
"Segment Routing and LDP Interworking" veremos una mezcla de rutas analicemos el
[Link] y

En la Figura 7-2, que está basada en la Figura 7-1, existen dos rutas etiquetadas desde el Nodo1 al destino
Nodo5. El primer camino es un camino instalado de Enrutamiento de Segmento: el Segmento Prefijo al
Nodo5. El otro camino es un camino instalado LDP: el LSP LDP al Nodo5. Si un paquete no etiquetado con
dirección de destino
[Link] llega al Nodo1, ¿qué etiqueta debe imponerse al paquete para transportarlo a su destino?
Figura 7-2: sin coexistencia IP-to-MPLS: seleccionar etiqueta a imponer

Por defecto, el Nodo1 impone la etiqueta LDP para el FEC [Link]/32, que es 90001 en el ejemplo. Pero el
operador puede configurar el Nodo1 para que prefiera la imposición de la etiqueta Segment Routing en su lugar.
En el ejemplo sería la etiqueta 16005, el Prefijo-SID asociado a [Link]/32.

En caso de que sólo esté disponible una única ruta etiquetada hacia el destino (ya sea Segment Routing o LDP,
pero no ambos), entonces no hay elección, la etiqueta de la única ruta etiquetada disponible se impondrá al
paquete entrante sin etiquetar.

La decisión de preferir LDP en lugar de la imposición de etiquetas de Enrutamiento por Segmentos por
defecto se ha tomado después de pensarlo mucho. La idea es que, como el Enrutamiento por Segmentos es
nuevo en el momento de escribir este , es muy probable que las redes utilicen LDP para su señalización de
transporte. Cuando se habilita el Enrutamiento por Segmentos de forma continua en los nodos de la red, no
queremos necesariamente que se utilice inmediatamente por defecto; todos los servicios siguen funcionando
sin interrupción utilizando LDP. Esto da la oportunidad a los operadores de comprobar y verificar las
operaciones del plano de control de Segment Routing y también las entradas de reenvío sin cambiar realmente
los servicios sobre él. Entonces, en momento adecuado, el operador puede cambiar la preferencia para cambiar
sin problemas los servicios de LDP a Segment Routing. Este cambio puede realizarse de un nodo de entrada o
de borde a vez e incluso para servicios o destinos específicos.
únicamente. Tal vez en un futuro no muy lejano, a medida que el despliegue y uso del enrutamiento por
segmentos se generalice, sería natural cambiar la preferencia por defecto a enrutamiento por segmentos.

En las plataformas Cisco IOS-XR, si un paquete sin etiqueta llega al nodo de entrada de una red MPLS y hay
una etiqueta saliente LDP así como una etiqueta saliente Segment Routing disponible para la dirección de
destino del paquete, se debe seleccionar una de las dos para imponerla al . Por defecto se prefiere la imposición
de la etiqueta LDP, por lo que si una etiqueta saliente LDP está disponible para el FEC ligado al prefijo de
destino, esa etiqueta LDP será impuesta al paquete. El operador puede configurar el nodo de entrada para que
imponer la etiqueta Segment Routing al paquete.

Añadiendo la palabra clave sr-prefer al comando de configuración segment-routing mpls bajo el

IGP, se configura la preferencia del Enrutamiento por Segmentos sobre la imposición de etiquetas LDP. Ver
Ejemplo 7-1 para ISIS y Ejemplo 7-2 para OSPF.

Ejemplo 7-1: Configuración de SR-prefer para ISIS

enrutador isis 1
address-family ipv4|ipv6 unicast
segment-routing mpls sr-prefer

Ejemplo 7-2: Configuración de SR-prefer para OSPF

router ospf 1 segment-

routing mpls
segment-routing mpls sr-prefer

La implementación OSPF también permite el uso de una lista de prefijos para determinar prefijos específicos
que necesitan ser preferidos para rutas de Enrutamiento de Segmento. La lista de prefijos puede especificar con
la configuración sr- prefer. Con esta configuración, la imposición de etiquetas SR sólo se prefiere para los
prefijos permitidos por la lista de prefijos. Esta funcionalidad permite una migración granular de LDP a SR,
añadiendo prefijos de forma incremental a la lista de prefijos. Esto proporciona un control por prefijo del
proceso de migración. En el momento de escribir este libro, la opción de lista de prefijos no estaba disponible
con ISIS.

En la configuración mostrada en el Ejemplo 7-3, la imposición de etiquetas SR es preferida para el prefijo

[Link]/32 y todos los prefijos /32 en el rango de prefijos [Link]/24. La imposición de etiquetas LDP es
preferida para todos los demás prefijos. La imposición de etiquetas LDP se prefiere para todos los demás
prefijos.
Ejemplo 7-3: Preferencia OSPF SR con lista de prefijos

ipv4 prefix-list PREFER_SR

10 permiso [Link]/32
20 permit [Link]/24 eq 32
¡!
router ospf 1
segment-routing sr-prefer prefix-list PREFER_SR

DESTACADO: Coexistencia del plano de datos MPLS

Pueden coexistir múltiples entradas de reenvío MPLS a MPLS y MPLS a IP para el mismo prefijo IP siempre que su etiqueta entrante/local
sea diferente.

El gestor de etiquetas garantiza la unicidad de estas etiquetas entrantes/locales, ya sea controlando directamente la asignación única a
clientes MPLS locales (LDP, RSVP-TE, BGP-VPN, etc.) o indirectamente delegando un rango de etiquetas locales (SRGB) a SR. El
propio SR garantiza que la asignación del prefijo SID dentro SRGB es única.

Para las entradas de reenvío IP a MPLS, preferencia por defecto es LDP sobre Segment Routing; esto cambiarse mediante la configuración
para preferir Segment Routing
Consideraciones al migrar a SR

"Cuando se habilita el Enrutamiento por Segmentos en una red MPLS existente, es importante planificar la hoja de ruta para la migración y
el diseño final incluyendo aspectos como:

El tamaño del SRGB, los límites del dominio SR y el diseño

Las capacidades del enrutador: cuáles son compatibles con el enrutamiento por segmentos y cuáles no; si se requiere alguna
actualización, etc.

Las migraciones de servicios: cuáles se migrarían y cuándo, y cuáles no.

Una vez concluida esta fase, se sugiere la siguiente secuencia para garantizar una transición con una interrupción mínima (si es que se
produce alguna) de los servicios existentes:"

Activar los protocolos de enrutamiento por segmentos en el plano de control, pero no dar preferencia al enrutamiento por segmentos en
el plano de reenvío.

Inicio del aprovisionamiento de SID prefijados y rangos SRMS

Verificar las operaciones del plano de control y las entradas de reenvío de Segment Routing; verificar también mediante operaciones
OAM; comprobar específicamente las entradas de reenvío en los puntos de interfuncionamiento SR/LDP.

Si la red existente dispone de protección, considere la posibilidad de habilitar TI-LFA como siguiente paso o bien hágalo después
de que se haya verificado el reenvío en el siguiente paso

Empezar a dar preferencia a SR sobre LDP en determinados nodos de la red y verificar la transición sin problemas de LDP a SR; a
continuación, lo mismo en toda la red.

En caso de problemas, se puede volver al estado anterior en cualquier momento.

- Ketan Talaulik ar

7.1.3 Aspectos de la aplicación

Para entender cómo las entradas de enrutamiento de segmento y reenvío LDP terminan en la tabla de reenvío, es
mejor mirar un diagrama muy simplificado de las interacciones entre los diferentes componentes involucrados
tomando referencia la implementación de Cisco IOS-XR. El diagrama de la Figura 7-3 ilustra el
comportamiento del Nodo1 en la topología de ejemplo que hemos visto en la sección anterior (Figura 7-1 y
Figura 7-2). El diagrama muestra el Protocolo de Pasarela Interior (IGP) que programa sus rutas en la Base de
Información de Enrutamiento (RIB). La RIB programa las entradas de reenvío en la Forwarding Information
Base (FIB), y reenvía la información de prefijos a los componentes Label Distribution Protocol (LDP) y Label
Switching Database (LSD), que también programan las entradas de reenvío en la FIB.
Figura 7-3: FIB de programación IGP y LDP: comportamiento del Nodo1

IGP aprende sobre un prefijo [Link]/32 y su Prefijo-SID índice 5. En la topología hay un único camino en
Nodo1 hacia ese , sin ECMP. Esto simplifica la ilustración, pero recuerda que el comportamiento descrito se
aplica a cada ruta de prefijo individual. El IGP instala sus rutas en la RIB proporcionando el prefijo, las rutas
del prefijo y las etiquetas prefijo-SID de cada ruta. En el ejemplo, el IGP instala el prefijo
[Link]/32 en la RIB. IGP proporciona la etiqueta local y la etiqueta saliente para el . Dado que todos los nodos
de la red utilizan SRGB [16000-23999], tanto la etiqueta local como la etiqueta saliente para el índice Prefix-
SID 5 tienen el valor 16005 (= 16000 + 5). RIB reenvía esta entrada de prefijo a LDP/LSD, que proporciona
las etiquetas LDP locales y salientes para el FEC vinculado a esta ruta de prefijo de destino y envía la ruta de
prefijo con las etiquetas LDP a FIB. Paralelamente, la RIB también envía directamente a la FIB la ruta del
prefijo y las etiquetas de enrutamiento de segmento proporcionadas por el IGP.
En consecuencia, para la misma ruta de prefijo, la FIB recibe información de dos fuentes: RIB y LSD. Es
importante tener en cuenta que la fuente inicial de ambas entradas de ruta de prefijo recibidas por FIB es la ruta
de prefijo IGP.

De estas dos fuentes, FIB prefiere la ruta proporcionada por LDP/LSD por defecto. El operador puede
configurarlo para que prefiera la ruta de de segmento (es decir, IGP).

Para la ruta de prefijo preferido, la FIB instala tanto una entrada de imposición de etiqueta (para imponer una
etiqueta a los paquetes entrantes no etiquetados con prefijo de destino [Link]/32 en este ejemplo) como una
conexión cruzada de etiqueta, que es una entrada de intercambio de etiqueta o una entrada de disposición de
etiqueta si este nodo es el penúltimo salto y la etiqueta debe ser retirada.

Para la ruta de prefijo no preferido, que es por defecto la ruta de enrutamiento de segmento IGP, sólo se
instala la conexión cruzada de etiqueta. O una entrada de disposición de etiqueta si este nodo es el
penúltimo salto y la etiqueta debe saltar.

La Figura 7-4 se acerca a la FIB e ilustra el caso por defecto en el que se prefiere la imposición de etiquetas
LDP. Tres entradas están programadas en la , todas pertenecientes a la misma entrada de prefijo [Link]/32:

imponer la etiqueta 90001 para paquetes IP que coincidan con el prefijo

[Link]/32 (LDP) intercambiar la entrante 90002 con la etiqueta saliente
90001 (LDP)

intercambiar la etiqueta de entrada 16005 con la etiqueta de salida 16005 (SR)

Figura 7-4: Programación de IGP y LDP FIB: prefiere la imposición de etiquetas LDP

Supongamos ahora que segment-routing mpls sr-prefer está configurado bajo la configuración
IGP de Nodo1. El diagrama de la Figura 7-5 ilustra este caso no predeterminado, donde se prefiere la
imposición de etiquetas Segment Routing. De las dos fuentes que proporcionan la información de reenvío de
ruta de prefijo a FIB, RIB y LSD, FIB ahora prefiere la ruta proporcionada por IGP/RIB.

Para la ruta de prefijo preferido, la FIB instala una entrada de imposición de etiqueta (para imponer una etiqueta
a los paquetes entrantes no etiquetados con prefijo de destino [Link]/32 en este ejemplo) y una conexión
cruzada de etiqueta.

Para la ruta no preferida, que en este es la ruta LDP/LSD, sólo se instala la conexión cruzada de etiquetas.

En el ejemplo de la Figura 7-5, se programan tres entradas en la FIB, todas relativas a la misma entrada de
prefijo [Link]/32:

imponer la etiqueta 16005 para paquetes IP que coincidan con el prefijo

[Link]/32 (SR) intercambiar la entrante 16005 con la etiqueta saliente
16005 (SR)

intercambiar la etiqueta entrante 90002 con la etiqueta saliente 90001 (LDP)

Figura 7-5: IGP y LDP programando FIB, prefiere imposición de etiquetas SR

Tenga en cuenta que las entradas de intercambio de etiquetas tanto para Segment Routing como para LDP
siempre se instalan cuando están disponibles, independientemente de la configuración de preferencia de
imposición. Esto es posible ya que pueden coexistir múltiples entradas de reenvío de intercambio de etiquetas
para el mismo prefijo de destino, no hay necesidad de seleccionar entre ellas.

La programación de la FIB se ilustra utilizando la topología de red de la Figura 7-6. Es la misma topología que
se muestra en la Figura 7-1. Es la misma topología que se muestra en la Figura 7-1. Nodo1 aplica la preferencia
de imposición de etiqueta por defecto: imponer la etiqueta saliente LDP si está disponible.
Figura 7-6: FIB de programación IGP y LDP - ejemplo

El ejemplo 7-4 muestra la salida de show mpls forwarding, mostrando las entradas de la tabla de
reenvío MPLS en Nodo1 para las etiquetas de este ejemplo. Ambas conexiones cruzadas de etiquetas MPLS,
una con etiquetas Segment Routing (in/out 16005) y otra con etiquetas LDP (in 90002, out 90001), están
programadas en la tabla de reenvío MPLS del Nodo1. Ambas entradas tienen la misma interfaz de salida y
nexthop Nodo2. Nótese que ambas entradas de reenvío están programadas independientemente de la
configuración de preferencia de imposición de etiquetas.
Ejemplo 7-4: Programación IGP y LDP FIB - Entradas de reenvío MPLS

RP/0/0/CPU0:xrvr-1#show mpls forwarding labels 16005

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

16005 16005 SR Pfx (idx 5) Gi0/0/0/0 [Link] 0

RP/0/0/CPU0:xrvr-1#show mpls forwarding labels 90002

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

90002 90001 [Link]/32 Gi0/0/0/0 [Link] 0

El Ejemplo 7-5 muestra un extracto de la configuración ISIS en Nodo1. La preferencia de imposición de

etiquetas LDP por defecto se aplica con esta configuración.

Ejemplo 7-5: Programación IGP y LDP Configuración FIB - ISIS

enrutador isis 1
address-family ipv4 unicast
metric-style wide
segment-routing mpls
¡!
¡!

La etiqueta local y saliente LDP para el FEC vinculado al prefijo de destino [Link]/32 se puede encontrar en la
salida show mpls ldp bindings para el prefijo [Link]/32. Ver la salida en el Ejemplo 7-6. Vea la salida
en el Ejemplo 7-6. Este comando muestra la etiqueta LDP vinculante para el prefijo [Link]/32 como es
anunciada por el vecino Node2 (LDP router ID [Link]). Nodo2 asignó la etiqueta local 90001 para el prefijo
[Link]/32.
La etiqueta local LDP asignada por Nodo1 para el prefijo [Link]/32 es 90002, y la etiqueta saliente para este
prefijo es 90001.

Ejemplo 7-6: Programación IGP y LDP FIB - LDP label bindings

RP/0/0/CPU0:xrvr-1#show mpls ldp bindings [Link]/32

[Link]/32, rev 40
Encuadernación local: etiqueta: 90002
Enlaces remotos: (1 peers) Peer
Etiqu
eta

[Link]:0 90001
Estas etiquetas pueden ser encontradas en la salida de show cef para el prefijo [Link]/32 en Nodo1. Vea la
salida en el Ejemplo 7-7. La entrada CEF para el prefijo [Link]/32 muestra la etiqueta local 90002 y la
etiqueta saliente, "labels imposed", es 90001. Estas son de hecho las etiquetas LDP tal y como se encuentran
en la salida del Ejemplo 7-6. De acuerdo con esta entrada CEF, todos los paquetes destinados a [Link]/32 y
todos los paquetes para los cuales el destino se resuelve en [Link]/32, tales como destinos BGP con [Link]
como nexthop BGP, obtienen la etiqueta saliente 90001 impuesta y son transportados sobre el LDP LSP.

Ejemplo 7-7: FIB de programación IGP y LDP - entrada CEF en Nodo1

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

[Link]/32, versión 42, interno 0x1000001 0x1 (ptr 0xa13fa974) [1], 0x0
(0xa13dfe3c), 0xa28 (0xa1541960)
Actualizado el 22 de febrero a las 13:42:56.375
adyacencia local [Link]
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 3
via [Link]/32, GigabitEthernet0/0/0/0, 11 dependencias, peso 0, clase 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0ef31fc 0x0]
next hop [Link]/32
adyacencia local
etiqueta local 90002 etiquetas impuestas {90001}

En el siguiente ejemplo se actualiza la configuración del Nodo1 para que prefiera las etiquetas de Enrutamiento
por Segmentos para su imposición. Por lo tanto el operador añadió la palabra clave sr-prefer a la
configuración de Enrutamiento por Segmentos del Nodo1. Ver el extracto de configuración en el Ejemplo 7-8.

Ejemplo 7-8: FIB de programación IGP y LDP - Configuración SR-prefer en Nodo1

enrutador isis 1
address-family ipv4 unicast
metric-style wide
segment-routing mpls sr-prefer
¡!
¡!

El IGP proporciona el prefijo, las rutas de prefijo y las etiquetas de enrutamiento de segmento a la RIB. RIB
posteriormente reenvía la información a FIB. La salida de show route detail para el prefijo [Link]/32
puede ser usada para mostrar las etiquetas que el IGP proporcionó al RIB. Vea la salida recolectada en el Nodo1
en el Ejemplo 7-
9. La ruta a [Link]/32 tiene una etiqueta local 16005 y una etiqueta saliente 16005 para la ruta del prefijo;
ambas están resaltadas en la salida. La etiqueta 16005 es efectivamente la etiqueta del Prefijo-SID de [Link]/32.
Ejemplo 7-9: Programación IGP y LDP FIB - Entrada RIB en Nodo1

RP/0/0/CPU0:xrvr-1#show route [Link]/32 detail Entrada de

enrutamiento para [Link]/32

Conocido vía "isis 1", distancia 115, métrica 40, etiquetado SR, tipo nivel-2
Instalado Feb 22 13:56:14.630 para 00:00:03
Bloques descriptores de enrutamiento
[Link], desde [Link], vía GigabitEthernet0/0/0/0 La
métrica de la ruta es 40
Etiqueta: 0x3e85 (16005)
ID de túnel: Ninguno
Etiqueta de enlace:
Ninguno
Recuento de comunidades extendidas:
0 Id de ruta:1 Recuento de
referencias de ruta:0
NHID:0x1(Ref:19)
La versión de la ruta es 0x1d0
(464) Etiqueta local: 0x3e85
(16005) Precedencia IP: No
establecida
QoS Group ID: Not Set
Flow-tag: Not Set Fwd-
class: No configurado
Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD RIB_SVD_TYPE_LOCAL
Descarga Prioridad 1, Descarga Versión 4267
Sin publicidad protos.

La salida de show cef para el prefijo [Link]/32 en el Nodo1, como se muestra en el Ejemplo 7-10, muestra
que la etiqueta prefijo-SID 16005 es impuesta a los paquetes destinados a, o que resuelven en, el prefijo
[Link]/32. La FIB prefirió la información de etiqueta SR provista por el IGP para programar la entrada de
reenvío. La FIB prefirió la información de etiqueta SR proporcionada por el IGP para programar la entrada de
reenvío.

Ejemplo 7-10: Programación IGP y LDP FIB - Entrada CEF en Nodo1

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

[Link]/32, versión 4267, interno 0x1000001 0x83 (ptr 0xa13fa974) [1], 0x0
(0xa13dfb00), 0xa28 (0xa15413c0)
Actualizado 18 dic 12:35:36.580
adyacencia local [Link]
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 1
vía [Link]/32, GigabitEthernet0/0/0/0, 13 dependencias, peso 0, clase 0 [banderas 0x0]
path-idx 0 NHID 0x0 [0xa0ef31fc 0x0]
next hop [Link]/32
adyacencia local
etiqueta local 16005 etiquetas impuestas {16005}
Los ejemplos de esta sección utilizan una red ISIS, pero la funcionalidad equivalente existe para OSPF. Los
ejemplos utilizan prefijos IPv4, pero los mismos mecanismos son aplicables a prefijos IPv6 si se utilizan
simultáneamente otros protocolos MPLS (incluyendo LDP para IPv6) y Segment Routing MPLS para IPv6.
7.2 Enrutamiento por segmentos e interfuncionamiento LDP
En el modelo de despliegue de interfuncionamiento, la red necesita interfuncionar partes de la red de
Enrutamiento por Segmentos con partes de la sólo LDP. La funcionalidad de interfuncionamiento se encarga de
la conectividad de Segment Routing a LDP y de LDP a Segment Routing. También se encarga de interconectar
partes de la red con Segment Routing sobre LDP y de interconectar partes de la red con LDP utilizando Segment
Routing.

DESTACADO: interfuncionamiento SR/LDP

El interfuncionamiento SR/LDP es perfecto: no se requiere ninguna configuración específica (aparte del Servidor de Mapeo (ver
capítulo 8, "Servidor de Mapeo de Enrutamiento de Segmentos") para los destinos sólo LDP), no se define ninguna pasarela
específica. El interfuncionamiento se produce automáticamente en cualquier nodo de la frontera entre los dominios SR y LDP.

El interfuncionamiento sin fisuras se consigue sustituyendo una etiqueta saliente desconocida (Unlabelled) de un protocolo por una
etiqueta saliente válida del otro protocolo.

Evitar la noción de una pasarela específica es excelente ya que las pasarelas representan puntos calientes de congestión y riesgos de

disponibilidad. Los nodos SR aprenden los SID de los nodos remotos no SR (LDP) gracias a los anuncios del Servidor de Mapeo.

Como para cualquier nodo SR, el operador asigna un SID del SRGB a cada prefijo loopback de un nodo LDP y no SR. Por ejemplo,
si el Nodo 1 con prefijo [Link]/32 está ejecutando LDP pero no SR, el operador asignaría el índice 1 del SRGB al prefijo [Link]/32.
Este mapeo ([Link]/32, SID índice 1) es entonces configurado en el Servidor(es) de Mapeo.

Aconsejamos al operador que active la funcionalidad de Servidor de Mapeo en dos del Dominio SR (por motivos de redundancia). Los
Servidores de Mapeo anuncian los mapeos (Prefijo a SID) en nombre de los nodos LDP no SR. Todos los demás nodos SR del
dominio son clientes por defecto.

7.2.1 Interfuncionamiento de LDP a SR

La Figura 7-7 muestra una red dividida en dos partes: una parte LDP a la izquierda y una parte SR la derecha.
Los nodos de la parte LDP sólo ejecutan LDP (no SR) y los nodos de la parte SR sólo ejecutan SR (no LDP).
Nodo3, el nodo en la frontera entre las dos partes, ejecuta tanto SR como LDP.
Figura 7-7: Topología de red de interfuncionamiento SR/LDP

¿Cómo puede el Nodo1 sólo LDP alcanzar el Nodo5 sólo enrutamiento de segmento a través de una ruta
conmutada por etiquetas?

Nodo3 está habilitado para LDP, pero su vecino aguas abajo Nodo4 hacia el destino Nodo5, no está habilitado
para LDP y consecuentemente no anuncia ninguna etiqueta LDP. Por lo tanto el Nodo3 no recibe una etiqueta
LDP saliente para el destino Nodo5. Nótese que si el Nodo3 usa el Modo de Control de Distribución de
Etiquetas Independiente LDP, entonces el Nodo3 por defecto asigna una etiqueta local LDP para [Link]/32, ya
que ese prefijo está en su tabla de encaminamiento. Si el Nodo3 usa el Modo de Control de Distribución de
Etiquetas Ordenadas LDP entonces el Nodo3 debe asegurarse de que asigna una LDP local para prefijos
remotos con un SID de Prefijo asociado, y distribuye esa a sus vecinos aguas abajo.

RECORDATORIO: Modo de control de distribución de etiquetas

LDP puede asignar etiquetas locales y distribuir etiquetas en dos modos:

Modo de control de distribución de etiquetas independiente: LDP asigna y distribuye una etiqueta local para cada prefijo IP en la tabla de
enrutamiento del nodo. LDP no espera a que el vecino aguas abajo anuncie primero un enlace de etiqueta para el prefijo.

Modo de control de distribución ordenada de etiquetas: LDP asigna y distribuye etiquetas locales para prefijos IP en la tabla de enrutamiento del
para el que es el nodo de salida (es decir, el último nodo MPLS para ese prefijo) o si ha recibido un enlace de etiqueta para ese prefijo de su
vecino descendente.

Los routers Cisco IOS XR siempre actúan en modo de control de distribución de etiquetas independiente. Por defecto, Cisco IOS XR asigna una
etiqueta local LDP para todos los prefijos de su tabla de enrutamiento, excepto los prefijos BGP.
Normalmente, si el Nodo3 no recibe una etiqueta saliente LDP para [Link]/32, instala una entrada de reenvío
MPLS para [Link]/32 con una etiqueta saliente "Unlabelled". Sin embargo, en lugar de programar una entrada
sin etiqueta en la tabla de reenvío, el Nodo3 conecta automáticamente la Ruta Conmutada por Etiquetas LDP
hacia el Nodo5, al Segmento Prefijo del Nodo5. Cualquier nodo en la frontera LDP a Segmento de
Enrutamiento instala automáticamente tales entradas de reenvío LDP-a-SR.

Para conectar el LSP LDP al prefijo, el Nodo3 instala la siguiente entrada de reenvío MPLS LDP to Segment
Routing:

La etiqueta local o entrante es la etiqueta local asignada por LDP para el FEC del Nodo destino5.

La etiqueta saliente es la etiqueta Prefix-SID asociada al prefijo loopback del Nodo5, 16005 en este ejemplo.

La interfaz saliente es la interfaz hacia el vecino Nodo4, el vecino descendente en el camino más corto hacia
Nodo5.

Esta entrada de reenvío de interfuncionamiento es derivada e instalada automáticamente por cualquier nodo
frontera LDP/SR. No requiere ninguna configuración adicional; no requiere ninguna posición específica en la
red.

La funcionalidad de interfuncionamiento sólo se aplica a los paquetes etiquetados; no se necesita ninguna

funcionalidad de interfuncionamiento para la imposición de etiquetas. Para paquetes IP no etiquetados con
destino Nodo5 que llegan a Nodo3, Nodo3 impone la etiqueta Prefijo-SID 16005.

La Figura 7-8 ilustra la programación de la tabla de reenvío MPLS en una red con interfuncionamiento LDP a
Segment Routing. La figura muestra la ruta desde el Nodo1 al destino Nodo5. Las tablas de reenvío MPLS se
muestran bajo los nodos. El rango de etiquetas disponible es de 16000 a 1 millón. La columna izquierda de las
tablas de reenvío muestra las etiquetas locales o entrantes, la columna derecha muestra las etiquetas salientes.
Figura 7-8: Ilustración del interfuncionamiento SR/LDP

Nodo1 y Nodo2 son nodos LDP heredados; no soportan Enrutamiento por Segmentos. Por lo tanto Nodo1 y
Nodo2 no tienen SRGB. En este ejemplo se asume que su rango dinámico de comienza en 24000.

Nodo4 y Nodo5 son nodos habilitados para Enrutamiento de Segmentos. Estos nodos utilizan el rango de
etiquetas SRGB por defecto, de 16000 a 23999, para los segmentos de prefijo. Nodo4 y Nodo5 no tienen LDP
habilitado.

El nodo en la frontera de los dos dominios, Nodo3, tiene habilitados tanto el Enrutamiento por Segmentos
como el LDP. También utiliza el SRGB por defecto [16000-23999]. El rango dinámico de etiquetas, utilizado
por ejemplo para las etiquetas LDP, comienza en 24000, después del SRGB.

Esta sección examina el interfuncionamiento de LDP a SR, para paquetes que van de la parte de la red sólo LDP
(azul) a la parte de la red sólo SR (verde).

El Nodo5 anuncia su prefijo de loopback [Link]/32 con un Prefijo-SID 16005. Nodo3 y Nodo4 programan la
entrada de reenvío MPLS para el segmento de prefijo al Nodo5, la etiqueta Prefix-SID 16005.
Nodo1, Nodo2 y Nodo3 programan sus entradas de reenvío LDP para el FEC de destino Nodo5. LDP utiliza un
modo de asignación de etiquetas descendente: un nodo ascendente utiliza las etiquetas asignadas y anunciadas
por su vecino descendente. LDP en Nodo3 asigna dinámicamente una etiqueta local 90007 para el FEC
[Link]/32 y anuncia esta etiqueta a todos sus vecinos LDP. LDP en Nodo2 asigna la etiqueta local 90100 -
rango dinámico de etiquetas - para el FEC [Link]/32 y anuncia esta etiqueta a todos sus vecinos LDP.
Finalmente, LDP en Nodo1 asigna una etiqueta local 90008 para el FEC [Link]/32.

Como el Nodo4 no está habilitado para LDP, el Nodo3 no recibió una etiqueta LDP vinculante del Nodo4 para
el prefijo [Link]/32. Por lo tanto, el Nodo3 no tiene una etiqueta LDP saliente para el FEC [Link]/32. Por lo
tanto el Nodo3 no tiene una etiqueta saliente LDP para el prefijo [Link]/32. La etiqueta saliente LDP es
"Unlabelled". Sin embargo, el Nodo3 tiene otro Label Switched Path al Nodo5: el segmento de prefijo del
Nodo5. El Nodo3 conecta automáticamente el Label Switched Path LDP del FEC
[Link]/32 al Segmento de Prefijo de [Link]/32, proporcionando una Ruta Conmutada por Etiquetas sin
interrupciones desde el Nodo1 al Nodo5. No se requiere ninguna configuración para esta funcionalidad.
Cualquier nodo en la frontera LDP/SR cumple automáticamente este papel de interworking.

[Link] Aspectos de la aplicación del PDL al RE

Para entender cómo las entradas de Segment Routing y LDP terminan en la tabla de reenvío, se utiliza un
diagrama muy simplificado de las interacciones entre los diferentes componentes involucrados. Este diagrama
está basado en la implementación de Cisco IOS-XR. Es el mismo utilizado en la sección 7.1.3, "Aspectos de
Implementación".
Figura 7-9: interfuncionamiento SR/LDP - FIB de programación IGP y LDP

Primero un rápido recordatorio del mecanismo de programación del plano de reenvío tal y como se describe en
la sección 7.1.3, "Aspectos de Implementación". Cuando IGP instala sus rutas en RIB, proporciona el prefijo y
las rutas con
las etiquetas de Segment Routing a RIB. RIB envía la información de ruta de prefijo a LDP/LSD y a FIB.
LDP/LSD proporciona las etiquetas LDP y envía la información de la ruta del prefijo a FIB. FIB recibe ambas
fuentes de información para la ruta del prefijo, de RIB y de LSD, y por defecto prefiere la información
proporcionada por LDP/LSD. El operador puede configurar el nodo para que FIB la información proporcionada
por IGP/RIB. Para la ruta de prefijo recibida de la fuente preferida, el nodo instala tanto entradas de imposición
de etiqueta como de intercambio de etiqueta. Para la ruta de prefijo recibida de la otra fuente no preferida, el
nodo sólo instala la entrada de intercambio de etiquetas.

Este es el flujo general descrito anteriormente. Pero, ¿qué ocurre con este flujo si el vecino aguas abajo hacia
el prefijo de destino [Link]/32 no es capaz de LDP? En ese , LDP no es capaz de proporcionar una etiqueta
saliente para el FEC ligado al prefijo [Link]/32. ¿O qué pasa si el vecino no tiene capacidad de Segment
Routing? En ese caso, no hay etiqueta saliente para el segmento de prefijo.

En dos casos anteriores, FIB realiza una operación de "reemplazo" utilizando las dos fuentes de información de
ruta, RIB y LDP/LSD. FIB reemplaza cualquier entrada no etiquetada en la información de ruta con la etiqueta
válida proporcionada por la otra fuente de información de ruta. La operación de "reemplazo" también se
denomina "fusión", pero es un término equivocado. Las etiquetas no se fusionan, sino que se sustituyen, como
se muestra más adelante.

Cuando FIB recibe la información de ruta de prefijo de las dos fuentes, RIB y LSD, reemplaza las etiquetas
salientes "Unlabelled"([)1] presentes en la entrada de ruta de prefijo de una fuente, con el valor de etiqueta
saliente válido de la ruta de prefijo correspondiente de la otra fuente. Si FIB recibe una entrada de ruta de
prefijo de la fuente LDP/LSD con una etiqueta saliente "Unlabelled", como se ilustra en la Figura 7-10,
entonces FIB reemplaza esa etiqueta con valor de etiqueta saliente válido de la misma ruta de prefijo de la
fuente IGP/RIB. Y viceversa.
Figura 7-10: Operación "reemplazar" FIB - LDP a SR

Esto se traduce en el comportamiento de que si no hay ninguna etiqueta saliente LDP disponible, se utiliza en su
lugar la etiqueta saliente proporcionada por el Enrutamiento de Segmentos IGP/RIB. Esto ocurrirá si el vecino
aguas abajo destino no está habilitado para LDP o si ese vecino aguas abajo no envía una etiqueta LDP
vinculante para el FEC vinculado al destino. Del mismo modo, si el vecino de destino no tiene habilitado el
enrutamiento por segmentos, se utilizará la etiqueta saliente LDP para la FEC vinculada al destino.

[Link] Ilustración del PDL al SR

La Figura 7-11 repite la topología de la Figura 7-8, con una parte de la red sólo LDP en el izquierdo (azul) y
una parte de la red sólo Segment Routing en el lado derecho (verde). Considere la ruta que va de izquierda a
derecha, la ruta desde LDP-only a Segment Routing-only. Se examina la programación de la tabla de reenvío en
Nodo3, el nodo en la frontera entre las dos partes de la red.
Figura 7-11: Ilustración de interfuncionamiento de LDP a SR

Nodo4, el vecino aguas abajo de Nodo3 hacia Nodo5, no está habilitado para LDP, lo que implica que Nodo3
no tiene etiqueta LDP saliente para el FEC ligado a destino Nodo5. FIB en Nodo3 automáticamente reemplaza
la etiqueta saliente "Unlabelled" de la entrada de ruta de prefijo proporcionada por LSD, por la etiqueta saliente
válida de la entrada de ruta de prefijo recibida de RIB. Con esta operación de reemplazo de la etiqueta saliente,
la ruta de conmutación de etiquetas LDP se une automáticamente a la ruta del segmento de prefijo.

Este comportamiento se comprueba ahora examinando la salida de los comandos show del router.

ISIS en Nodo3 tiene habilitado segment-routing mpls sin la palabra clave sr-prefer. Esto significa que
utiliza la preferencia de imposición de etiquetas por defecto: prefer label imposition LDP. Vea el extracto de
configuración del Nodo3 en el Ejemplo 7-11
Ejemplo 7-11: Extracto de la configuración ISIS del Nodo3

enrutador isis 1
address-family ipv4 unicast
metric-style wide
segment-routing mpls
¡!
¡!

La salida en Nodo3 de show route detail para el prefijo [Link]/32 muestra la entrada RIB del prefijo.
Vea la salida en el Ejemplo 7-12. Esta entrada de prefijo RIB es instalada por la instancia ISIS 1 (línea 4). El
prefijo tiene una etiqueta local 16005 (línea 16), que es la etiqueta prefijo-SID 16005. Sólo hay una ruta que
conduce a este prefijo de destino, a través de la interfaz GigabitEthernet0/0/0/0 y el siguiente salto [Link]
(línea 7). La etiqueta saliente para esta ruta es de nuevo la etiqueta prefijo-SID 16005 (línea 9). Tanto las
etiquetas locales como las salientes son etiquetas de Segment Routing, proporcionadas por el IGP, que es ISIS
en este ejemplo.

Ejemplo 7-12: Mostrar salida de ruta en Nodo3

1 RP/0/0/CPU0:xrvr-3#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocida vía "isis 1", distancia 115, métrica 40, etiquetado SR, tipo nivel-2
5 Instalado Feb 22 20:23:47.068 para 00:00:10
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/0
8 La métrica de ruta es 40
9 Etiqueta: 0x3e85 (16005)
10 ID del túnel: Ninguno
11 Etiqueta de encuadernación: Ninguna
12 Recuento de comunidades extendidas: 0
13 Id de ruta:1 Recuento de rutas:0
14 NHID:0x2(Ref:15)
15 La versión de la ruta es 0x224 (548)
16 Etiqueta local: 0x3e85 (16005)
17 Precedencia IP: No configurada
18 QoS Group ID: No configurado
19 Etiqueta de flujo: No fijado
20 Clase Fwd: No fijado
21 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
22 Descargar prioridad 1, Descargar versión 5032
23 Nada de protos publicitarios.
La salida en Nodo3 de show mpls ldp bindings para el FEC [Link]/32 muestra la etiqueta LDP local
asignada 90007. Vea la salida en el Ejemplo 7-13. Nodo4 es el vecino upstream para Nodo3 hacia el destino
[Link]/32 y Nodo3 debería usar la etiqueta LDP recibida de Nodo4 para FEC [Link]/32. Como LDP no está
habilitado en el Nodo4, el Nodo3 no recibe ninguna etiqueta vinculante para FEC
[Link]/32 desde Nodo4. La salida sólo muestra una etiqueta remota para [Link]/32 desde el vecino aguas abajo
[Link] (Nodo2). A falta de una etiqueta LDP vinculante desde Nodo4, Nodo3 no tiene etiqueta LDP saliente
para programar para FEC [Link]/32.

Ejemplo 7-13: Mostrar salida de mpls ldp bindings en Nodo3

RP/0/0/CPU0:xrvr-3#show mpls ldp bindings [Link]/32

[Link]/32, rev 37
Enlace local: etiqueta: 90007
Enlaces remotos: (1 pares)
Peer Etiqueta

[Link]:0 90100

La salida de "show mpls ldp forwarding" para el prefijo [Link]/32 en el Ejemplo 7-14 muestra
efectivamente una etiqueta saliente "Unlabelled".

Ejemplo 7-14: Mostrar salida de mpls ldp forwarding en Nodo3

RP/0/0/CPU0:xrvr-3#show mpls ldp forwarding [Link]/32 Códigos:

= -GR label recovering, (!)= LFA FRR pure backup path
{} = Pila de etiquetas con salida multilínea para una ruta de enrutamiento
G= GR, S = Stale, R = LFA remoto Copia de
seguridad FRR

Prefijo Etiquet Etiqueta(s) Interfaz de Próximo salto Bande

a In fuera salida ras G
S R

[Link]/32 90007 Sin etiqueta Gi0/0/0/0 [Link]

En el Nodo3 se utiliza la preferencia de imposición de etiqueta por defecto, que es preferir la imposición de la
etiqueta LDP si está disponible. En la salida de show cef para el prefijo [Link]/32 en el Ejemplo 7-15, se
muestra una ruta a través de la interfaz saliente Gi0/0/0 y el siguiente salto [Link] (línea 7). La etiqueta local
es la etiqueta local 90007 asignada para LDP FEC [Link]/32. La etiqueta saliente es la etiqueta Prefix-SID
16005. Esta etiqueta saliente es el resultado de la operación "replace". La etiqueta LDP saliente "sin etiqueta
para FEC [Link]/32 ha sido sustituida por la etiqueta de salida de Segment Routing válida para [Link]/32:
Prefix-SID label 16005.

Ejemplo 7-15: Mostrar salida cef en Nodo3

1RP/0/0/CPU0:xrvr-3#show cef [Link]/32

2 [Link]/32, versión 76, interno 0x1000001 0x5 (ptr 0xa13fa774) [1], 0x0
(0xa13dfc8c), 0xa28 (0xa1541898)
3 Actualizado 18 dic 12:35:42.562
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 15
6 via [Link]/32, GigabitEthernet0/0/0/0, 11 dependencias, peso 0, clase 0 [flags
0x0]
7 path-idx 0 NHID 0x0 [0xa10b13a0 0x0]
8 siguiente salto [Link]/32
9 adyacencia local
10 etiqueta local 90007 etiquetas impuestas {16005}

La salida de show cef flags para el prefijo [Link]/32 en el Ejemplo 7-16 muestra que la bandera
LDP/SR merge requested está activada (línea 5), lo que que la operación de fusión o reemplazo está
solicitada para ese prefijo. La bandera LDP/SR merge active también está , lo que significa que la
operación de fusión o reemplazo ocurrió.

Ejemplo 7-16: Mostrar salida de banderas cef en Nodo3

1RP/0/0/CPU0:xrvr-3#show cef [Link]/32 flags

[Link]/32, versión 76, interno 0x1000001 0x5 (ptr 0xa13fa774) [1], 0x0
(0xa13dfc8c), 0xa28 (0xa1541898)
3 banderas de hoja: propietario bloqueado, insertado
4
5 hoja flags2: LDP/SR merge requested,LDP/SR merge active,
6 hoja ext flags: PriChange,illegal-0x00000020,illegal-0x00000200,illegal-
0x00000800,
7 Actualizado 18 dic 12:35:42.562
8 adyacencia local [Link]
9 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 15
10 via [Link]/32, GigabitEthernet0/0/0/0, 11 dependencias, peso 0, clase 0 [flags
0x0]
11 path-idx 0 NHID 0x0 [0xa10b13a0 0x0]
12 siguiente salto [Link]/32
13 adyacencia local
14 etiqueta local 90007 etiquetas impuestas {16005}
Un detalle interesante: la salida show cef detail muestra la fuente de la entrada cef. El ejemplo 7-17
muestra la línea en la salida que contiene la fuente. En este caso la fuente es LSD (source lsd). (5) es el
identificador interno de "LSD".

Ejemplo 7-17: Mostrar detalle de cef en Nodo3

RP/0/0/CPU0:xrvr-3#show cef [Link]/32 detail| incl "source"

gateway array (0xa14102b8) reference count 3, flags 0x68, source lsd (5), 2 backups

La salida de show mpls forwarding for label 16005 en el Ejemplo 7-18 muestra la entrada de la tabla
de reenvío MPLS para la etiqueta prefijo-SID asociada con el prefijo de destino [Link]/32. La etiqueta local o
entrante prefijo-SID 16005 se intercambia con la etiqueta saliente 16005 y se reenvía en la interfaz saliente
Gi0/0/0. La etiqueta local o entrante prefijo-SID 16005 se intercambia con la etiqueta saliente 16005 y se
reenvía en la interfaz saliente Gi0/0/0, siguiente salto [Link]. No se ha realizado ninguna operación de
reemplazo para esta entrada. No se ha realizado ninguna operación de reemplazo para esta entrada ya que la
etiqueta Prefix-SID 16005 saliente estaba disponible en el Nodo3.

Ejemplo 7-18: show mpls forwarding output on Node3, SR entry

RP/0/0/CPU0:xrvr-3#show mpls forwarding labels 16005

Local Saliente Prefijo Saliente Salto siguiente Bytes
Etiqu Etiqueta o ID Interfaz Conmutado
eta

16005 16005 SR Pfx (idx 5) Gi0/0/0/0 [Link] 0

La salida de show mpls forwarding para el prefijo [Link]/32, muestra la etiqueta LDP 90007 como
etiqueta local y la etiqueta Prefix-SID 16005 como etiqueta saliente. Esta etiqueta saliente es el resultado de la
operación de reemplazo (o fusión) de etiqueta. Nodo3 reemplaza la etiqueta saliente LDP original "Unlabelled"
por la etiqueta Prefix-SID 16005. En la entrada de reenvío resultante, la etiqueta LDP local 90007 se
intercambia con la etiqueta Prefix-SID saliente 16005 y se reenvía en la interfaz saliente Gi0/0/0 con el
siguiente salto [Link].

Ejemplo 7-19: show mpls forwarding output on Node3, entrada LDP

RP/0/0/CPU0:xrvr-3#show mpls forwarding prefix [Link]/32

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

90007 16005 [Link]/32 Gi0/0/0/0 [Link] 0

Ejecutando un traceroute desde Nodo1 a Nodo5 muestra el LSP LDP siendo mapeado al Segmento Prefijo. Ver
la salida en el Ejemplo 7-20. Las etiquetas LDP dinámicas se utilizan hasta el Nodo3 y allí la etiqueta se
intercambia con la etiqueta Prefix-SID 16005. Recuerde que un traceroute clásico muestra la pila de etiquetas
del paquete tal y como lo recibe el nodo que al mensaje de sondeo.

Ejemplo 7-20: traceroute en Nodo1 a Nodo5

RP/0/0/CPU0:xrvr-1#traceroute [Link]

Escriba la secuencia de escape para

abortar.
Rastreando la ruta a [Link]

1 [Link] [MPLS: Etiqueta 90100 Exp 0] 19 mseg 9 mseg 9 mseg

2 [Link] [MPLS: Etiqueta 90007 Exp 0] 0 mseg 0 mseg 9 mseg
3 [Link] [MPLS: Etiqueta 16005 Exp 0] 9 mseg 0 mseg 0 mseg
4 [Link] 0 mseg 0 mseg 9 mseg

En la misma topología, el Nodo3 está ahora configurado para preferir la imposición de etiquetas de Segment
Routing añadiendo la palabra clave sr-prefer a la configuración MPLS de segment-routing del Nodo3. Vea
el extracto de configuración resultante en el Ejemplo 7-21.

Ejemplo 7-21: Configuración de SR-prefer

enrutador isis 1
address-family ipv4 unicast
metric-style wide
segment-routing mpls sr-prefer
¡!
¡!

Ahora que el Nodo3 está configurado para preferir la imposición de etiquetas de enrutamiento de Segmento,
la salida de show cef flags en el Nodo3 para el prefijo [Link]/32 se muestra en el Ejemplo 7-22.
Ejemplo 7-22: Mostrar salida de banderas cef en Nodo3, no merge

1RP/0/0/CPU0:xrvr-3#show cef [Link]/32 flags

[Link]/32, versión 5077, interno 0x1000001 0x83 (ptr 0xa13fa774) [1], 0x0
(0xa13dfe84), 0xa28 (0xa1541780)
3 banderas de hoja: propietario bloqueado, insertado
4
5 banderas de hoja2: LDP/SR merge requested,RIB pref over LSD,SR Prefix,
6 hoja ext flags: PriChange,illegal-0x00000020,illegal-0x00000200,illegal-
0x00000800,
7 Actualizado 18 dic 12:35:42.562
8 adyacencia local [Link]
9 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 1
10 vía [Link]/32, GigabitEthernet0/0/0/0, 9 dependencias, peso 0, clase 0 [flags
0x0]
11 path-idx 0 NHID 0x0 [0xa10b13a0 0x0]
12 siguiente salto [Link]/32
13 adyacencia local
14 etiqueta local 16005 etiquetas impuestas {16005}

La bandera LDP/SR merge requested está activada en la entrada FIB (línea 5), por lo FIB intentará
reemplazar o fusionar las etiquetas salientes "Unlabelled". Pero la bandera LDP/SR merge active no
está activada; las banderas no activadas no se muestran en la salida. La operación de reemplazo no tiene lugar
aquí porque no es necesario. Con la configuración sr-prefer, la FIB prefiere la imposición de etiquetas de
Segment Routing y ya había disponible una de salida de Segment Routing válida. Por lo tanto, no era
necesaria una operación de reemplazo.

También se establece otra bandera en la entrada cef: RIB pref over LSD. Esta bandera indica que se
prefiere la imposición de etiquetas de Enrutamiento por Segmentos ("RIB") sobre la imposición de etiquetas
LDP ("LSD"), que es de hecho lo que se pretendía con la configuración sr-prefer.

La salida de show cef detail en Nodo3 en el Ejemplo 7-23 muestra la fuente de la entrada cef. Sólo se
muestra la línea en la salida que contiene la fuente. En este caso, con sr-prefer configurado, la fuente es
RIB ("source rib").

Ejemplo 7-23: Mostrar detalle de cef en Nodo3, fuente RIB

RP/0/0/CPU0:xrvr-3#show cef [Link]/32 detail| i "source"

gateway array (0xa141061c) reference count 3, flags 0x68, source rib (7), 1 backups
La configuración de la preferencia de imposición de etiquetas en el Nodo3 no tiene efecto sobre la ruta de
conmutación de etiquetas desde el Nodo1 al Nodo5. Un traceroute de Nodo1 a Nodo5 mostraría, por ejemplo,
los mismos valores de etiqueta, independientemente de la preferencia de imposición de etiqueta en Nodo3.

7.2.2 Interfuncionamiento SR a LDP

La Figura 7-12 muestra la representación en espejo de la topología de la Figura 7-7. Es la misma topología, sólo
que el orden de los nodos está invertido. Es la misma , sólo que el orden de los nodos está invertido. La
topología consiste en una parte sólo de Segment Routing, en lado izquierdo, y una parte sólo de LDP en el
derecho. Nodo3, el nodo en la frontera entre las dos partes, ejecuta tanto Segment Routing como LDP. Se
examina la ruta desde Segment Routing a LDP, de izquierda a derecha. Los de Enrutamiento por Segmentos
asignaron SRGB [16000-23999].

Figura 7-12: Topología de red de interfuncionamiento SR/LDP

El Nodo5 es un nodo de Enrutamiento por Segmentos; está situado dentro del área verde de Enrutamiento por
Segmentos. Si el Nodo5 quiere utilizar el Enrutamiento por Segmentos para transportar paquetes al Nodo1 de
destino, debe tener una etiqueta Prefijo-SID hacia el Nodo1 de destino. Dado que el Nodo1 no es un nodo de
Enrutamiento por Segmentos, no puede anunciar un Prefijo-SID para su prefijo de loopback [Link]/32. Aquí
entra en el Servidor de Mapeo del capítulo 8. Un Servidor de Mapeo es una entidad (componente, aplicación
o nodo de red) que es capaz de anunciar un Prefijo-SID asociado con un prefijo (un mapeo prefijo-a-SID) en
nombre de otros nodos. La funcionalidad del Servidor de Mapeo está integrada en los nodos Cisco IOS XR.
Un Servidor de Mapeo puede anunciar mapeos prefijo-a-SID en IGP en nombre de otros nodos, incluyendo
nodos que no tienen habilitado el Enrutamiento por Segmentos. Dado que IGP inunda estas asignaciones en la
red, todos nodos de la red reciben estos anuncios del Servidor de Asignación. Los nodos de la red habilitados
para Enrutamiento por Segmentos utilizan las asignaciones de prefijo a SID para programar entradas de reenvío
de Enrutamiento por Segmentos en su tabla de reenvío. Un nodo utiliza la asignación de prefijo a SID
anunciada por el servidor de asignación para un prefijo si no ningún Prefijo-SID "nativo" disponible para ese
prefijo. "Nativo" significa que el nodo que origina el prefijo también origina el Prefijo-SID asociado.

En el ejemplo, el Nodo5 necesita un Prefijo-SID para el prefijo loopback del Nodo1, [Link]/32. Como el
Nodo1 no soporta Enrutamiento por Segmentos, no anuncia un Prefijo-SID para su prefijo loopback. Como
Nodo1 no soporta Segment Routing, no anuncia un Prefijo-SID para su prefijo loopback. Un Servidor de
Mapeo anuncia un Prefijo-SID índice 1 asociado con el prefijo [Link]/32 en nombre de Nodo1. Dado que no
hay un prefijo-SID "nativo" disponible para [Link]/32los nodos de Segment Routing instalan la etiqueta
derivada del índice Prefix-SID anunciado por el Servidor de Mapeo. El valor de la etiqueta para el índice
Prefix-SID 1 y SRGB [16000-23999] es 16001 (=16000 + 1).

Nodo4 y Nodo5, los nodos de Segment Routing en la topología, instalan la siguiente entrada de reenvío MPLS de
Segment Routing para el prefijo loopback de Nodo1:

La etiqueta local o entrante es la etiqueta Prefix-SID asociada al prefijo loopback del Nodo1, 16001 en el
ejemplo. Esta información procede del Servidor de Mapeo.

La etiqueta saliente es la etiqueta Prefix-SID asociada al prefijo loopback del Nodo1, 16001 en el ejemplo.
Esta información procede del Servidor de Mapeo.

La interfaz saliente es la interfaz hacia el vecino aguas abajo en el camino más corto hacia Nodo1. Esta
información proviene de los anuncios regulares IGP link-state.

Nodo4 y Nodo5, instala también la siguiente entrada de imposición de etiquetas Segment Routing para el
prefijo loopback de Nodo1:

Prefijo Loopback del Nodo1, [Link]/32 en el ejemplo.

La etiqueta saliente es la etiqueta Prefix-SID asociada al prefijo loopback del Nodo1, 16001 en el ejemplo.
Esta información procede del Servidor de Mapeo.

La interfaz saliente es la interfaz hacia el vecino descendente en el camino más corto hacia Nodo1.
Un Servidor de Mapeo anuncia, por ejemplo, un Prefijo-SID índice 1 para [Link]/32, en nombre del Nodo1.
Esto permite el uso de etiquetas de Enrutamiento por Segmentos para transportar tráfico hacia este destino
dentro del dominio de Enrutamiento por Segmentos.

El siguiente problema a resolver es el interfuncionamiento de Segment Routing a LDP.

Nodo3, el nodo en la frontera entre las dos áreas, ejecuta tanto Segment Routing como LDP. El Nodo3 tiene
habilitado el Enrutamiento por Segmentos, pero su vecino aguas abajo, el Nodo2, hacia el destino Nodo1, no
tiene habilitado el Enrutamiento por Segmentos. Por lo tanto, Nodo3 no puede programar una etiqueta saliente
de Enrutamiento por Segmentos para el destino Nodo1, ya que Nodo2 no podría interpretar correctamente la
etiqueta de Enrutamiento por Segmentos en los paquetes que recibiría. En lugar de programar una entrada
"Unlabelled" en la tabla de reenvío para el destino Nodo1, el Nodo3 conecta automáticamente el Segmento
Prefijo del Nodo1 a la Ruta Conmutada por LDP hacia el Nodo1. Cualquier nodo en la frontera Segmento de
Enrutamiento a LDP instala automáticamente tales entradas de reenvío SR-a-LDP. No es necesaria ninguna
configuración.

Para conectar el segmento de prefijo al LSP LDP, el Nodo3 instala la siguiente entrada de enrutamiento de
segmento a reenvío LDP:

La etiqueta local o entrante es la etiqueta Prefix-SID local asociada con el prefijo loopback de Nodo1,
16001 en este ejemplo. Esta información proviene del Servidor de Mapeo.

La etiqueta de salida es la etiqueta de salida LDP para el FEC vinculado al destino Nodo1, tal y como se
recibe del vecino nodo2.

La interfaz saliente es la interfaz hacia el vecino Nodo2, el vecino descendente en el camino más corto hacia
Nodo1.

La Figura 7-13 ilustra la programación de la tabla de reenvío MPLS en una red con Segment Routing
interworking a LDP. Es la misma topología que en la Figura 7-8, pero el orden de los nodos está invertido en la
presentación. La figura muestra la ruta desde el Nodo5, a la izquierda, al destino Nodo1, a la derecha. La
ilustración muestra las tablas de reenvío MPLS bajo los nodos. El rango de etiquetas disponible es de 16000 a 1
millón. La columna izquierda de tablas de reenvío muestra las locales o entrantes, la columna derecha muestra
las etiquetas salientes.
Figura 7-13: Ilustración del interfuncionamiento SR a LDP

Nodo4 y Nodo5 son nodos habilitados para Segment Routing. Estos nodos están usando el rango de etiquetas
SRGB por defecto, de 16000 a 23999. Nodo4 y Nodo5 no tienen LDP habilitado.

Nodo1 y Nodo2 son nodos LDP heredados; no soportan Enrutamiento por Segmentos. Por lo tanto Nodo1 y
Nodo2 no tienen SRGB. En este ejemplo se asume que su rango dinámico de comienza en 24000.

El nodo en la frontera de los dos dominios, Nodo3, tiene tanto LDP como Segment Routing habilitados.
También utiliza el SRGB por defecto [16000-23999]. El rango dinámico de etiquetas, utilizado por ejemplo
para las etiquetas LDP, comienza en 24000, después del SRGB.

Como su prefijo loopback está localmente conectado, Nodo1 anuncia la etiqueta LDP implícita-nula para el
FEC ligado a su prefijo loopback [Link]/32. Nodo2 asigna una etiqueta local 90090 - del rango de etiquetas
dinámicas - para el FEC ligado al prefijo [Link]/32 y anuncia esta etiqueta a sus vecinos LDP. Nodo2 asigna
una etiqueta local 90090 - del rango de etiquetas dinámicas - para la FEC ligada al prefijo [Link]/32, y
anuncia esta etiqueta a sus vecinos LDP. Nodo2 instala la entrada de reenvío LDP: entrante: 90090, etiqueta
saliente: pop, interfaz saliente: Nodo1, el siguiente salto en el camino más corto a [Link]/32.
Nodo3 asigna una etiqueta local 90002 - del rango de etiquetas dinámicas - para el LDP FEC ligado al prefijo
[Link]/32. Nodo3 instala la entrada de reenvío LDP: etiqueta entrante: 90002, etiqueta saliente: 90090, interfaz
saliente: Nodo2, siguiente salto en la ruta más corta a [Link]/32.

Un Servidor de Mapeo anuncia un índice prefijo-SID 1, asociado al prefijo [Link]/32. Todos los nodos
habilitados para Enrutamiento por Segmentos utilizan el índice prefijo-SID anunciado por el Servidor de
Asignación para programar las entradas de etiquetas de Enrutamiento por Segmentos a [Link]/32. Como todos
los nodos de Enrutamiento por Segmentos de la topología utilizan el SRGB predeterminado [16000-23999],
instalan las entradas de reenvío Prefijo-SID utilizando la etiqueta 16001 (= 16000 + 1).

Dado que el Nodo2 no tiene habilitado el Enrutamiento por Segmentos, el Nodo3 no tiene etiqueta Prefijo-SID
saliente para [Link]/32.

Sin embargo, el Nodo3 tiene otra ruta de conmutación de etiquetas hacia [Link]/32: la ruta de conmutación de
etiquetas LDP para la FEC vinculada a [Link]/32. El Nodo3 ha recibido la etiqueta saliente para esa FEC del
Nodo2: etiqueta 90090. Nodo3 ha recibido la etiqueta saliente para ese FEC desde Nodo2: etiqueta 90090.

El Nodo3 conecta automáticamente el segmento de prefijo de [Link]/32 a la ruta de conmutación de etiquetas

LDP para el FEC [Link]/32. De esta forma se proporciona una ruta de conmutación de etiquetas continua desde
el Nodo5 hasta el Nodo1. De esta forma, se proporciona un Label Switched Path sin interrupciones desde el
Nodo5 hasta el Nodo1.

[Link] SR a los aspectos de aplicación del PDL

Refiriéndonos a la topología de la Figura 7-13, los nodos en la parte de la red que sólo permite el
Enrutamiento por Segmentos necesitan un Prefijo-SID para el prefijo de destino con el fin de transportar
tráfico a ese destino usando el Segmento de Prefijo. Dado que el Nodo1 de destino no tiene habilitado el
Enrutamiento por Segmentos, no puede anunciar un Prefijo-SID por sí mismo. Se utiliza un Servidor de
Mapeo para anunciar un prefijo-SID índice 1 para el prefijo
[Link]/32 en nombre del Nodo1. El IGP en cada nodo de Segment Routing utiliza los mapeos prefijo-a-SID
anunciados por el Servidor de Mapeo para instalar las entradas de reenvío SR para los nodos sólo-LDP.
Todo esto se hace en el plano de control; por ejemplo la etiqueta Prefijo-SID 16001 se instala en la FIB de la
misma manera que un Prefijo-SID "nativo", vía IGP/RIB.

El mecanismo "replace" para instalar entradas de reenvío de interfuncionamiento SR a LDP es el mismo que
para las entradas de LDP a SR. Consulte la sección [Link].

La Figura 7-14 ilustra el comportamiento del Nodo3 en la topología de la Figura 7-13. Nodo2 es el vecino
aguas abajo de Nodo3 hacia el destino [Link]/32. Dado que el Nodo2 no es Segment Routing
activado, el IGP del Nodo3 no tiene una etiqueta Prefix-SID saliente para [Link]/32. Por lo tanto, el IGP
proporciona una etiqueta saliente "Sin etiquetar" para el prefijo [Link]/32 a la RIB. Por lo tanto IGP
proporciona una etiqueta saliente "Sin Etiquetar" para el prefijo [Link]/32 a RIB. Nodo2 asigna y anuncia una
etiqueta local LDP para el prefijo [Link]/32: etiqueta 90090. El LSD proporciona esta etiqueta 90090 como
etiqueta saliente para el FEC [Link]/32 a la FIB.

Figura 7-14: Operación FIB "replace" - SR a LDP

FIB reemplaza automáticamente la etiqueta saliente "Unlabelled" que recibió de RIB por la etiqueta saliente
válida 90090 que recibió de LDP/LSD. Tras esta operación de sustitución, el segmento de prefijo a
[Link]/32 está cosida a la ruta conmutada por etiquetas LDP de FEC [Link]/32.

[Link] Ilustración de SR a LDP

Nodo3, Nodo4, y Nodo5 instalan las entradas de reenvío de Segment Routing a los nodos LDP-only según lo
anunciado por el Servidor de Mapeo. El Servidor de Mapeo anuncia que el Prefijo-SID índice 1 está mapeado al
prefijo [Link]/32. Vea la salida en el Ejemplo 7-24. Vea la salida en el Ejemplo 7-24. La columna "Rango"
indica el número de prefijos que están en esta entrada de mapeo prefijo-a-SID; uno en este ejemplo. Ver la
sección Servidor de Mapeo para más detalles.
Ejemplo 7-24: Mapeo de prefijo a SID anunciado por el servidor de mapeo

RP/0/0/CPU0:iosxrv-5#show isis segment-routing prefix-sid-map active

IS-IS 1 activo política

Prefijo Índice SID Gama Bander
as
[Link]/32 1 1

Número de entradas de mapeo: 1

ISIS en Nodo5 instala el prefijo [Link]/32 en RIB, con las etiquetas derivadas del índice Prefix-SID anunciado
por el Servidor de Mapeo. El cálculo para derivar la etiqueta Prefix-SID es el mismo que para un Prefix-SID
"normal": añadir el índice Prefix-SID a la Base SRGB. En este ejemplo, la etiqueta Prefix-SID es 16001 (=
16000 + 1). Véase el resultado en el Ejemplo 7-25. La ruta se marca como recibida del Servidor de Mapeo
"SR(SRMS)" (línea 4). La ruta tiene 16001 como etiquetas local y saliente (líneas 9 y 16). No se ilustra aquí,
pero el Nodo4 instala la entrada equivalente en su tabla de enrutamiento.

Ejemplo 7-25: Mostrar salida de ruta en Nodo5 para el mapeo prefijo-a-SID anunciado por SRMS

1 RP/0/0/CPU0:iosxrv-5#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocido vía "isis 1", distancia 115, métrica 40, etiquetado SR(SRMS), tipo nivel-2
5 Instalado Feb 23 11:16:58.647 para 00:21:50
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/1
8 La métrica de ruta es 40
9 Etiqueta: 0x3e81 (16001)
10 ID del túnel: Ninguno
11 Etiqueta de encuadernación: Ninguna
12 Recuento de comunidades extendidas: 0
13 Id de ruta:1 Recuento de rutas:0
14 NHID:0x4(Ref:9)
15 La versión de la ruta es 0x245 (581)
16 Etiqueta local: 0x3e81 (16001)
17 Precedencia IP: No configurada
18 QoS Group ID: No configurado
19 Etiqueta de flujo: No fijado
20 Clase Fwd: No fijado
21 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
22 Descargar prioridad 1, Descargar versión 4622
23 Nada de protos publicitarios.
Así, los nodos SR-only pueden ahora reenviar tráfico SR hacia los nodos LDP-only.

El Nodo3, en la frontera entre las partes de red SR-only y LDP-only instala entradas de reenvío SR a LDP
para los prefijos LDP-only. El ejemplo 7-26 muestra la salida de show route detail en el Nodo3 para
el prefijo [Link]/32, el prefijo loopback del Nodo1. Esta salida muestra las etiquetas locales y salientes para
cada prefijo. Esta salida muestra las etiquetas locales y salientes para cada ruta de prefijo. En este ejemplo,
sólo hay una ruta al prefijo [Link]/32: vía Gi0/0/0/1 (línea 7). La etiqueta local es 16001 (línea 16), que es la
etiqueta Prefix-SID para [Link]/32. El IGP no pudo proporcionar una etiqueta saliente para la ruta del prefijo.
El IGP no pudo proporcionar una etiqueta saliente para el prefijo [Link]/32 ya que el vecino aguas abajo,
Nodo2, no tiene habilitado el Enrutamiento por Segmentos. La etiqueta saliente "Unlabelled" está representada
por Label: None en esta salida (línea 9).

Ejemplo 7-26: Mostrar detalle de ruta en Nodo3

1 RP/0/0/CPU0:xrvr-3#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocido vía "isis 1", distancia 115, métrica 20, etiquetado SR(SRMS), tipo nivel-2
5 Instalado Feb 23 11:11:32.319 para 00:35:55
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/1
8 La métrica de ruta es 20
9 Etiqueta: Ninguna
10 ID del túnel: Ninguno
11 Etiqueta de encuadernación: Ninguna
12 Recuento de comunidades extendidas: 0
13 Id de ruta:1 Recuento de rutas:0
14 NHID:0x3(Ref:4)
15 La versión de la ruta es 0x25d (605)
16 Etiqueta local: 0x3e81 (16001)
17 Precedencia IP: No configurada
18 QoS Group ID: No configurado
19 Etiqueta de flujo: No fijado
20 Clase Fwd: No fijado
21 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
22 Descarga Prioridad 1, Descarga Versión 5600
23 Nada de protos publicitarios.

La salida de show mpls ldp bindings para FEC [Link]/32 en el Ejemplo 7-27 muestra la etiqueta
local LDP 90002 que el Nodo3 asignó para FEC [Link]/32, y la etiqueta saliente para ese FEC, etiqueta
90090, recibida del vecino aguas abajo [Link] (Nodo2).
Ejemplo 7-27: Mostrar salida de mpls ldp bindings en Nodo3

RP/0/0/CPU0:xrvr-3#show mpls ldp bindings [Link]/32

[Link]/32, rev 40
Enlace local: etiqueta: 90002
Enlaces remotos: (1 pares)
Peer Etiqueta

[Link]:0 90090

Al principio, la preferencia de imposición de etiqueta en Nodo3 es la predeterminada, que es preferir la

imposición de la etiqueta LDP para paquetes entrantes sin etiqueta.

La salida de show cef flags para el prefijo [Link]/32 en el Ejemplo 7-28 muestra que la bandera
LDP/SR merge requested está activada (línea 5) pero la bandera LDP/SR merge active no está
activada (las banderas no activadas no se muestran en la salida). Esto significa que la operación de fusión o
reemplazo fue solicitada pero en realidad no ocurrió. No hubo necesidad de reemplazar la etiqueta saliente ya
que LDP proporcionó una etiqueta saliente válida a FIB. El campo de etiquetas impuestas en la salida
muestra que la etiqueta de salida LDP 90090 está impuesta, como se esperaba.

Ejemplo 7-28: Mostrar salida de banderas cef en Nodo3

1RP/0/0/CPU0:xrvr-3#show cef [Link]/32 flags

2 [Link]/32, versión 371, interno 0x1000001 0x1 (ptr 0xa13fa4f4) [1], 0x0
(0xa13dfd1c), 0xa28 (0xa15410f0)
3 banderas de hoja: propietario bloqueado, insertado
4
5 hoja flags2: LDP/SR merge requested,
6 hoja ext flags: PriChange,illegal-0x00000020,illegal-0x00000200,illegal-
0x00000800,
7 Actualizado el 23 de febrero a las 12:09:41.629
8 adyacencia local [Link]
9 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 3
10 via [Link]/32, GigabitEthernet0/0/0/1, 9 dependencias, peso 0, clase 0 [flags
0x0]
11 path-idx 0 NHID 0x0 [0xa10b17e4 0x0]
12 siguiente salto [Link]/32
13 adyacencia local
14 etiqueta local 90002 etiquetas impuestas {90090}

El Ejemplo 7-30 muestra la salida de show mpls forwarding para el prefijo [Link]/32. La salida
muestra que la etiqueta local LDP entrante 90002 se intercambia con la etiqueta LDP saliente 90090 y
reenviado en la interfaz Gi0/0/0/1, siguiente salto Nodo2. Nada especial aquí, ya que una etiqueta LDP
saliente estaba fácilmente disponible para el destino [Link]/32.

Ejemplo 7-29: Mostrar salida mpls forwarding en Nodo3, entrada LDP

RP/0/0/CPU0:xrvr-3#show mpls forwarding prefix [Link]/32

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

90002 90090 [Link]/32 GIO/0/0/1 [Link] 0

Ahora el Nodo3 está configurado para preferir la imposición de etiquetas Segment Routing (configurando
sr- prefer). La salida de show cef flags ahora se ve como se muestra en el Ejemplo 7-30. La bandera
LDP/SR merge requested está activada en la entrada FIB (línea 5), y la bandera LDP/SR merge
active está activada, lo que significa que la operación de reemplazo de etiqueta está solicitada y la etiqueta
ha sido reemplazada. La etiqueta local es la etiqueta Prefix-SID 16001 y la etiqueta impuesta es la
etiqueta LDP saliente 90090 para FEC [Link]/32. Esta etiqueta saliente es el resultado de la operación de
reemplazo de etiqueta en la FIB que reemplazó la etiqueta saliente "Unlabelled" de Segment Routing por la
etiqueta saliente LDP válida.

Se establece otra bandera en la entrada FIB: RIB pref over LSD. Este indicador se activa cuando la FIB
debe preferir la imposición de etiquetas de Segment Routing ("RIB") sobre el LDP para imposición de etiquetas
("LSD"). Este es el caso si sr-prefer está configurado.
Ejemplo 7-30: Mostrar salida de banderas cef en Nodo3 con sr-prefer

1RP/0/0/CPU0:xrvr-3#show cef [Link]/32 flags

[Link]/32, versión 5600, interno 0x1000001 0x87 (ptr 0xa13fa4f4) [1], 0x0
(0xa13dfef0), 0xa28 (0xa1541870)
3 banderas de hoja: propietario bloqueado, insertado
4
5 leaf flags2: LDP/SR merge requested,RIB pref over LSD,LDP/SR merge active,SR Prefix,
6 hoja ext flags: PriChange,illegal-0x00000020,illegal-0x00000200,illegal-
0x00000800,
7 Actualizado 18 dic 12:35:42.563
8 adyacencia local [Link]
9 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 15
10 via [Link]/32, GigabitEthernet0/0/0/1, 9 dependencias, peso 0, clase 0 [flags
0x0]
11 path-idx 0 NHID 0x0 [0xa10b17e4 0x0]
12 siguiente salto [Link]/32
13 adyacencia local
14 etiqueta local 16001 etiquetas impuestas {90090}

La entrada de reenvío MPLS para la etiqueta entrante 16001, la etiqueta Prefix-SID de [Link]/32, se muestra en
el Ejemplo 7-31. Como resultado de la operación de reemplazo, la etiqueta saliente para esta entrada es la
etiqueta saliente LDP para FEC [Link]/32.

Ejemplo 7-31: Mostrar salida mpls forwarding en Nodo3, entrada SR

RP/0/0/CPU0:xrvr-3#show mpls forwarding labels 16001

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

16001 90090 SR Pfx (idx 1) GIO/0/0/1 [Link] 0

Tenga en cuenta que las entradas de intercambio de etiquetas, las conexiones cruzadas de etiquetas tanto para
Segment Routing como para etiquetas locales LDP siempre se instalan, independientemente de la configuración
sr-prefer.

Un traceroute desde el Nodo5 al Nodo1 en el Ejemplo 7-32 muestra el cambio del Segmento Prefijo al LSP
LDP en el Nodo3. Inicialmente el paquete tiene la etiqueta 16001, que es la etiqueta Prefix-SID para [Link]/32.
Después del Nodo3 el paquete tiene una etiqueta LDP. Luego en el Nodo3 el paquete tiene una etiqueta LDP.
Ejemplo 7-32: Traceroute de Nodo5 a Nodo1

RP/0/0/CPU0:iosxrv-5#traceroute [Link]

Escriba la secuencia de escape para abortar.

Rastreando la ruta a [Link]

1 [Link] [MPLS: Etiqueta 16001 Exp 0] 29 mseg 9 mseg 9 mseg

2 [Link] [MPLS: Etiqueta 16001 Exp 0] 9 mseg 9 mseg 9 mseg
3 [Link] [MPLS: Etiqueta 90090 Exp 0] 9 mseg 9 mseg 9 mseg
4 [Link] 9 mseg 9 mseg 9 mseg

7.2.3 SR sobre LDP, LDP sobre SR

Para interconectar dos partes de la red de Enrutamiento por Segmentos a través de una parte de la sólo LDP, se
utiliza el interfuncionamiento SR/LDP en ambos nodos frontera que conectan las partes de la red, como se
ilustra en la Figura 7-15 (a). El segmento de prefijo se conecta a la ruta de conmutación de etiquetas LDP en la
frontera SR-a-LDP. Y en el límite LDP-to-SR, el Label Switched Path LDP está conectado al Prefix Segment.
Figura 7-15: SR sobre LDP y LDP sobre SR

¿Es necesario un Servidor de Mapeo para interconectar dos partes de la red de Enrutamiento por Segmentos
a través de una parte de la red sólo LDP?

Si no se requiere transporte de Enrutamiento por Segmentos desde fuentes en la parte de Enrutamiento por
Segmentos de la red a destinos que están localizados en la parte de la red sólo LDP, entonces un Servidor de
Mapeo no es estrictamente necesario. El nodo origen de Enrutamiento por Segmentos conoce el prefijo-SID del
nodo destino. El nodo destino tiene habilitado el Enrutamiento por Segmentos y anuncia de forma nativa un
Prefijo-SID para su prefijo loopback. Véase la Figura 7-16.
Figura 7-16: SR sobre LDP

Si se requiere transporte Segment Routing desde fuentes en la parte Segment Routing de la red a destinos que
están localizados en la parte LDP-only de la red, entonces se necesita un Servidor de Mapeo. Este es el
interworking normal de SR a LDP que requiere un Servidor de Mapeo.

Para interconectar dos partes de la red sólo LDP a través de una parte de la sólo Segment Routing, el Label
Switched Path LDP se conecta al Prefix Segment en el límite LDP-to-SR. En el límite SR a LDP, el segmento
de prefijo está conectado al Label Switched Path LDP. Ver Figura 7-15 (b).

¿Es necesario un Servidor de Mapeo para interconectar dos partes de la red sólo LDP a través de una parte de
la red de Enrutamiento por Segmentos? La respuesta es: Sí, siempre. Dentro de la parte de red de
Enrutamiento por Segmentos, las etiquetas prefijo-SID son necesarias para transportar los paquetes
etiquetados. Si un origen en la parte de la red sólo LDP necesita transportar paquetes a un destino en la parte
de la red sólo LDP a través de la red de Enrutamiento por Segmentos, entonces se necesita un Servidor de
Mapeo. Los nodos de la red de Enrutamiento por Segmentos necesitan una etiqueta Prefix-SID para el prefijo
de destino, que es originado por un nodo sólo LDP. Este sólo LDP no puede anunciar un Prefijo-SID para su
prefijo loopback. Un Servidor de Mapeo anuncia un Prefijo-SID para ese prefijo loopback en nombre del
nodo LDP-only. Ver ilustración en la Figura 7-17.
Figura 7-17: LDP sobre SR

Si un origen en la parte de la red que sólo utiliza LDP necesita transportar paquetes a un destino en
parte de la red que utiliza Segment Routing, entonces no es estrictamente necesario un Servidor de
Mapeo. Esta es la funcionalidad normal de interfuncionamiento entre LDP y SR.

La funcionalidad de interfuncionamiento SR/LDP también se aplica en la ruta de backup Topology

Independent-LFA, véase el capítulo 9.

La implementación del interfuncionamiento SR/LDP intenta mantener los paquetes en el mismo tipo de
transporte, ya sea Segment Routing o LDP, siempre que sea posible. Sólo si es necesario, la funcionalidad de
interfuncionamiento SR/LDP se utiliza para interconectar segmentos de prefijo con rutas de conmutación de
etiquetas LDP.

En la Figura 7-18, un paquete que es transportado en un LSP LDP llega al Nodo1. El paquete atraviesa una isla
de sólo enrutamiento de segmento, representada por el Nodo3. LDP no está habilitado en Nodo3.

La funcionalidad de interfuncionamiento SR/LDP en Nodo2 conecta el LSP LDP al Segmento Prefijo hacia el
destino. A partir de ahí, el paquete permanece en el Segmento Prefijo mientras haya conectividad continua de
Enrutamiento de Segmento. El transporte sólo vuelve a un LSP LDP si es necesario, si se atraviesa un nodo sólo
LDP. Lo mismo ocurre en el caso inverso. Un paquete permanece en un LSP LDP mientras haya LDP
continua.
Figura 7-18: Interfuncionamiento SR/LDP sólo si es necesario

DESTACADO: Consideraciones sobre el despliegue

Se recomienda incluir los siguientes prefijos pertenecientes a nodos no aptos para Enrutamiento Segmentado (es decir, LDP) en
las asignaciones Prefijo-SID del Servidor de Asignación:

todos los prefijos loopback en estos nodos que se utilizan para terminar servicios

todos los prefijos loopback asociados al "router-id" en los nodos que terminan los servicios (es decir, los routers de entrada o salida
de la red de transporte)

otros prefijos a los que podría destinarse tráfico/servicios, pero que no están realmente asociados a Prefix-SIDs (por ejemplo,
destinos detrás de un router de borde o prefijos redistribuidos) pero para los necesitamos características como la protección TI-
LFA en el dominio de Segment Routing.

7.2.4 Resumen del interfuncionamiento SR/LDP

La Figura 7-19 resume la funcionalidad de interfuncionamiento SR/LDP. La ilustración está dividida en tres
columnas. El nodo en la parte superior de cada columna indica la localización del nodo en la red. Cada está en
la frontera entre una parte de la red LDP+ Segment Routing en el lado izquierdo y las diferentes combinaciones
posibles de Segment Routing y/o LDP en el lado derecho. Los paquetes debajo de cada nodo muestran cómo el
nodo fronterizo maneja los paquetes que llegan (1) sin etiqueta, (2) con una etiqueta de transporte LDP y (3)
con una etiqueta de transporte Segment Routing. Dependiendo de cuál
está disponible en el lado derecho del nodo frontera, se distinguen tres modelos: naves-en-la-noche", "sólo-a-
LDP" y "sólo-a-SR".

Figura 7-19: Resumen de interfuncionamiento SR/LDP

El primer es el de "barcos en la noche", que se muestra en la primera columna. Este proporciona tanto
enrutamiento por segmentos como conectividad LDP a ambos lados del nodo frontera. El segundo modelo es
el modelo "to-LDP-only", mostrado en la columna central, que tiene una parte de la red sólo LDP en el lado
derecho del nodo frontera. El tercer es el "to-SR-only", mostrado en la columna de la derecha, que tiene una
parte de la red sólo de Segment Routing a la derecha del nodo frontera.

Cuando llega un paquete IP sin etiqueta desde la izquierda (primera fila, denominada "IP"), el nodo frontera
impone la etiqueta de salida para el prefijo de destino. Para el modelo "barcos en la noche", la etiqueta
impuesta depende de la configuración de preferencias de imposición de etiquetas del nodo, ya que están
disponibles tanto las etiquetas de transporte Segment Routing como LDP. Para los demás modelos, sólo se
dispone de una etiqueta saliente, que se impone al paquete saliente.

Cuando un paquete con una etiqueta de transporte LDP llega al nodo (segunda fila, llamada "LDP"), la etiqueta
será intercambiada con una etiqueta de salida LDP para los modelos "ship-in-the-night" y to-LDP-only". La
etiqueta LDP se intercambia con una etiqueta Segment Routing para el modelo "to-SR-only".
Cuando un paquete con una etiqueta de transporte de Enrutamiento de Segmentos llega al nodo (tercera fila,
denominada "SR"), la etiqueta se intercambiará con una etiqueta de salida de Enrutamiento de Segmentos para
los modelos "ship-in-the-night" y "to-SR-only". La etiqueta Segment Routing se intercambia con una etiqueta
LDP para el modelo "to-LDP-only".

"El interfuncionamiento y los mecanismos de transición de Segment Routing han sido factores clave para su implantación en las redes
MPLS existentes. Existe flexibilidad para utilizar distintos modelos (ships-in-the-night e interworking) para diferentes servicios, así
como para actualizar gradualmente las plataformas de enrutamiento más antiguas de la red."

- Ketan Talaulik ar
7.3 Resumen
Por defecto un Nodo impone una etiqueta LDP a los paquetes entrantes no etiquetados, se puede configurar
la preferencia de imposición de Enrutamiento por Segmentos.

Un nodo instala entradas de reenvío MPLS a MPLS tanto LDP como SR (intercambio de etiquetas) si están
disponibles, independientemente de la configuración de preferencias SR/LDP.

La funcionalidad del plano de datos de interfuncionamiento SR/LDP se consigue sustituyendo una etiqueta
saliente desconocida (Unlabelled) por una etiqueta saliente válida del otro protocolo.

Un Servidor de Mapeo anuncia Prefix-SIDs en nombre de nodos sólo LDP. Esto permite enviar tráfico de
Segment Routing a nodos sólo LDP.

Un nodo en la frontera de una parte LDP de la red a una parte sólo SR de red une automáticamente LSPs
LDP a segmentos de prefijo.

Un nodo en la frontera de una parte SR de la red a una parte sólo LDP de la red une automáticamente
Segmentos de Prefijo a LSPs LDP.
7.4 Referencias
[draft-ietf-spring-segment-routing-ldp-interop] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B. y S.
Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment- routing-ldp-interop
(work in progress), julio de 2016, [Link] spring-segment-routing-ldp-
interop.

[draft-ietf-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski,
S., Horneffer, M., Shakir, R., Tantsura, J. y E. Crabbe, "Segment Routing with MPLS data plane", draft-
ietf-spring-segment-routing-mpls (work in progress), septiembre de 2016,
[Link]

1 Estilo británico "Unlabelled" con doble "l", como se utiliza en la salida show del router
8 SERVIDOR DE MAPEO DE ENRUTAMIENTO
DE SEGMENTOS
8.1 Función del servidor de mapas
Un Servidor de Mapeo de Enrutamiento de Segmentos, o simplemente "Servidor de Mapeo", es una entidad
capaz de anunciar mapeos de prefijo a índice Prefijo-SID en IGP. Un Servidor de Mapeo puede ser una función
en un nodo de red, una aplicación independiente o una plataforma dedicada.

La funcionalidad de Servidor de Mapeo se define para la funcionalidad de interfuncionamiento

SR/LDP. El término "Segment Routing Mapping Server" se abrevia a veces como "SRMS".

Un nodo no habilitado para Enrutamiento por Segmentos no puede anunciar un Prefijo-SID asociado con su ,
simplemente porque el nodo no está habilitado para Enrutamiento por Segmentos. Si se necesita un Prefijo-
SID para ese prefijo, el anuncio del Prefijo-SID para ese prefijo debe ser realizado por otra entidad en la , en
nombre del nodo propietario del prefijo. La función de Servidor de Mapeo proporciona ese anunciando listas
de prefijos con sus índices Prefijo-SID asociados en el IGP, los llamados "mapeos de índice prefijo a Prefijo-
SID", o, algo más corto, "mapeos prefijo a SID".

La funcionalidad del Servidor de Mapeo es necesaria en la red para permitir el interfuncionamiento entre nodos
habilitados para Segment Routing y nodos no habilitados para Segment Routing, como los nodos sólo LDP. Por
lo tanto, la función de Servidor de Mapeo es un componente clave de esta funcionalidad de
interfuncionamiento SR/LDP. El capítulo 7 de interfuncionamiento SR/LDP, "Segment Routing in Existing
MPLS Networks" explica cómo encaja un Servidor de Mapeo en la arquitectura de interfuncionamiento
SR/LDP. Este capítulo cubre la funcionalidad del Servidor de Mapeo en sí.
SRMS para anunciar los SID del nodo habilitado para SR

"El concepto SRMS se ha inventado para la solución de interfuncionamiento SR/LDP. Permite a los nodos SR descubrir los SID de
nodos sólo LDP (o prefijos de nodos no SR).

Personalmente, no me plantearía ampliar el SRMS para distribuir los SID de los nodos habilitados para SR. Los nodos habilitados para
SR son capaces de hacerlo y, en mi opinión, deberían .

Un principio clave del diseño de SR es la simplicidad, por lo que siempre buscamos automatizar los comportamientos y simplificar el
funcionamiento.

Uno puede preguntarse si configurar todos los mapeos Prefijo-a-SID en algunos nodos centrales y distribuirlos a través del IGP
podría proporcionar alguna simplificación adicional. No estoy convencido de ello.

No veo la ganancia de configuración: de hecho, el mapeo prefijo-a-SID necesita ser configurado dos veces o más con la opción SRMS
comparado con la configuración clásica en el propio nodo SR. Esto es aún más obvio teniendo en cuenta que el Prefijo-
Se espera que el mapeo to-SID nunca cambie y por lo tanto sólo necesita ser configurado una vez por nodo SR.

El SID de un prefijo es la angular sobre la que se construye toda solución. Esta piedra angular debe ser lo más estable y fiable posible
y, por tanto, no debe depender de ningún otro nodo que no sea el que anuncia el prefijo al que está vinculado el SID.

A medida que las redes evolucionan en la era SDNla automatización y la programabilidad se convierten en elementos clave para su
aprovisionamiento y gestión. Herramientas como Cisco Network Services Orchestrator (NSO) [1] facilitan una gestión centralizada y
racionalizada de los servicios de red.
modelo de aprovisionamiento que también facilita y reduce errores en tareas como asignación de direcciones IP (y, como extensión, sus
SID de prefijo para SR)."

- Clarence Filsfils & Ketan Talaulik ar

8.2 Posición del servidor cartográfico en la red
Un Servidor de Mapeo es un componente funcional de la red. Su objetivo es anunciar las correspondencias
prefijo-SID. La función del Servidor de Asignación puede realizarse como un módulo o componente de un
dispositivo existente (NMS, enrutador, conmutador) o como una entidad dedicada (o servicio virtualizado) en
la red. Puede haber, y probablemente habrá, múltiples entidades de Servidor de Mapeo en la red. Este libro
sólo cubre el Servidor de Mapeo como componente de un enrutador (físico o virtual).

La posición del servidor de mapeo en la red es comparable a la de un reflector de rutas BGP.

De forma similar a un reflector de rutas BGP, el Servidor de Mapeo es una funcionalidad del plano de control.
Un nodo que ejecute la funcionalidad de Servidor de Mapeo no necesita estar en la ruta de datos, pero puede
estarlo. La posición exacta del Servidor de Mapeo en la red no influye en su función, ya que los anuncios de
mapeo se distribuyen utilizando el mecanismo regular de anuncios IGP. Dado que utiliza el IGP para distribuir
sus mapeos, un Servidor de Mapeo necesita tener una adyacencia IGP a la red. Los nodos que no soportan o no
entienden los anuncios IGP del Servidor de Mapeo seguirán reenviando estos anuncios utilizando el mecanismo
de inundación IGP regular veremos esto más de cerca en esta sección.

No es necesario que un Servidor de Asignación sea un nodo de la red dedicado a la función de Servidor de
Asignación, pero puede serlo. Cualquier nodo que admita la función de servidor de asignación, como cualquier
router Cisco IOS XR, puede gestionar la función de servidor de asignación cuando esté configurado para ello.

El papel del servidor de mapeo en la red es crucial, por lo que se necesita capacidad de recuperación y
redundancia.
Posicionamiento de la función SRMS en la red

"Hay ciertos aspectos prácticos para situar la función SRMS en la red, que también podrían de pauta para su posicionamiento.

Esta función está integrada en todos los routers con software Cisco IOS-XR para evitar la necesidad de una plataforma adicional o
especial y ofrecer flexibilidad en el posicionamiento.

Esta función se considera parte del plano de control distribuido del enrutamiento por segmentos, ya que implica la inundación a través
de IGP. Lo más lógico es incrustarla en routers redundantes de la red.

A efectos de redundancia, debe colocarse en al menos dos routers que sean a su vez redundantes (es decir, menos propensos a fallar
o quedar aislados juntos) y preferiblemente plataformas con buenas características de Alta Disponibilidad (HA). Dos suelen ser
suficientes en la mayoría de las redes.

Colocar esta función en un gran número de dispositivos podría ser contraproducente, ya que habría que garantizar la coherencia de
las asignaciones en todos ellos y la posibilidad de errores aumenta especialmente al modificar las asignaciones en un gran número
de routers de coordinada en una red de producción en funcionamiento.

Al colocar esta función en dispositivos como un router OSPF ABR, se garantizará que las asignaciones se propaguen desde una única
fuente a las múltiples áreas afectadas. Estos routers de frontera son también generalmente pasarelas redundantes entre partes de la red
a través de las cuales fluyen muchos servicios. Tenga en cuenta que incluso si se configuran en otros dispositivos, el ABR tendría que
gestionar su propagación a través de las áreas. Tenga en cuenta que esto no se aplica a la implementación ISIS de Cisco IOS XR en
momento de escribir este libro, consulte la sección 8.10.1."

- Ketan Talaulik ar

DESTACADO: Servidor de asignación de rutas por segmentos

Segment Routing Mapping Server es la función en la que las asignaciones Prefix-SID para prefijos pertenecientes a nodos no habilitados
para SR se aprovisionan de forma centralizada y se distribuyen a través de IGP por toda la red.

Normalmente habilitado en dos (o raramente más) routers redundantes en la red.

8.3 Función del cliente de cartografía
Como su nombre indica, un Cliente de Mapeo es un cliente de un Servidor de Mapeo. La función de Cliente de
Mapeo es una función en el IGP para recibir, analizar y procesar los mapeos de prefijo a Prefijo-SID anunciados
por los Servidores de Mapeo. Los nodos que necesitan instalar las entradas de reenvío del Segmento de Prefijo
derivadas de los mapeos de prefijo a SID, utilizan la funcionalidad de Cliente de Mapeo.

Un nodo que es un Servidor de Mapeo puede ser al mismo tiempo un Cliente de Mapeo. Por ejemplo, un
Servidor de Cartografía que se encuentre en la ruta de datos. Dado que no es necesario que la función de
Servidor de Asignación se ejecute en un nodo dedicado, es posible implementar la función de Servidor de
Asignación en un nodo de la red que se encuentre en la ruta de datos. Dado que se encuentra en la ruta de
datos, dicho nodo también utilizaría los mapeos de prefijo a SID para instalar las entradas de reenvío derivadas
de estos mapeos; por lo tanto, necesitaría ser un Cliente de Mapeo. Si un Cliente de Mapeo es también un
Servidor de Mapeo, entonces el Cliente de Mapeo considera los mapeos anunciados por el Servidor de Mapeo
local de la misma manera que considera los mapeos de un Servidor de Mapeo remoto. El cliente de asignación
actúa como si todos los servidores de asignación estuvieran ubicados remotamente.

Un Cliente de Mapeo recibe mapeos prefijo-a-SID de todos los Servidores de Mapeo en la red. Las
asignaciones de prefijo a SID que recibe pueden ser inválidas o conflictivas, debido a errores de software,
errores humanos, durante la reconfiguración, etc. Por lo tanto, el Cliente de Mapeo utiliza un conjunto de
reglas para seleccionar un conjunto válido de mapeos de todos los mapeos prefijo-a-SID recibidos. Las reglas
de selección deben dar como resultado un conjunto coherente de asignaciones de prefijo a SID en toda la red:
cada cliente de asignación de la red debe obtener el mismo conjunto de asignaciones válidas. Esto es necesario
para obtener entradas de reenvío consistentes basadas en estos mapeos prefijo-a-SID para evitar bucles de
reenvío y agujeros negros.
Este conjunto consistente y válido de mapeos prefijo-a-SID se denomina Política de Mapeo Activa.

Se deriva una Política de Asignación Activa por instancia IGP en un nodo. La instancia IGP utiliza esta Política
de Asignación Activa para derivar un Prefijo-SID para algunos o todos los prefijos que no tienen un Prefijo-SID
asociado.

Las entradas de asignación de prefijo a SID que se recibieron pero no llegaron a la política de asignación
activa, posiblemente debido a solapamientos o conflictos con otras entradas de asignación de prefijo a SID, se
insertan en la política de asignación de reserva.
Si uno o más Servidores de Mapeo están desplegados en la red, entonces todos los nodos habilitados para
Enrutamiento por Segmentos deben usar los mapeos prefijo-a-SID anunciados por estos Servidores de Mapeo.
Si no todos los nodos habilitados para el enrutamiento por segmentos lo hacen, las entradas de reenvío pueden
no ser coherentes entre los nodos que utilizan las asignaciones y los nodos que no las utilizan. Esto puede
provocar agujeros negros de tráfico o bucles de reenvío. Por lo tanto, una regla de diseño de sentido común es:
"Si se despliega un Servidor de Mapeo en la red, todos los nodos de Enrutamiento de Segmentos en la red
deben ser Clientes de Mapeo". Por esta razón práctica, los IGPs en implementaciones Cisco IOS-XR operarán
por defecto como Clientes de Mapeo y aceptarán mapeos provenientes de Servidores de Mapeo - esto puede ser
cambiado vía configuración explícita.

DESTACADO: Cliente de asignación de rutas por segmentos

El Cliente de Mapeo de Enrutamiento por Segmentos es la función en nodos IGP habilitados para Enrutamiento por Segmentos
que acepta y utiliza los mapeos Prefijo-SID anunciados por el Servidor o Servidores de Mapeo de Enrutamiento por Segmentos
para asignar SIDs a prefijos para los no tiene anuncios "nativos" IGP Prefijo-SID.

Normalmente habilitado por defecto en todos los routers IGP con capacidad de Enrutamiento por Segmentos.
8.4 Arquitectura del servidor de mapas
La Figura 8-1 muestra un diagrama simplificado de arquitectura del Servidor de Mapeo Cisco IOS XR que
puede servir como una buena referencia para entender el concepto. A la izquierda se ve el componente
Mapping Manager, a la derecha el componente IGP. El Gestor de Mapeo valida la configuración del mapeo
local prefijo-a-SID y proporciona una Política de Mapeo Local válida al . Los diferentes componentes de la
arquitectura se examinan recorriendo su funcionalidad.

Figura 8-1: Arquitectura del servidor de mapeo

La funcionalidad del gestor de asignaciones comienza configurando las asignaciones de prefijo a SID en el
servidor de asignaciones. Las asignaciones de prefijo a SID se configuran en la configuración global de
enrutamiento por segmentos de Cisco IOS XR.

El verificador de políticas locales comprueba la coherencia y corrección de la configuración y, a

continuación, inserta las correspondencias prefijo-SID válidas y coherentes en una base de datos de políticas
de correspondencias locales.

El componente IGP almacena en caché la Política de Mapeo Local y esta caché de Política Local es utilizada
por la funcionalidad del Servidor de Mapeo IGP para generar las actualizaciones IGP para distribuir los
mapeos prefijo-a-SID a través de la red. La caché de la Política Local se actualiza cuando se actualiza la
configuración del Servidor de Mapeo. Las diferentes instancias IGP que se ejecutan en un nodo se conectan al
Gestor de Mapeo central para recuperar la base de datos global de la Política de Mapeo Local.
La función de cliente de asignación también utiliza la política de asignación local si el cliente de asignación es
al mismo tiempo un servidor de asignación. Otros clientes de asignación, los que no se ejecutan en un servidor de
asignación, sólo obtienen asignaciones de prefijo a SID recibidas de servidores de asignación remotos.

Tanto las asignaciones de prefijo a SID en la Política Local como las asignaciones recibidas de los Servidores
de Asignación remotos se introducen en el Calculador de Políticas. El calculador de políticas valida las
asignaciones SID y obtiene un conjunto válido y no solapado (véase la sección 8.6, "Resolución de conflictos
entre rangos de asignación") de asignaciones de prefijo a SID que es coherente en todos los clientes de
asignación de de prefijo a la red. Este conjunto de asignaciones de prefijo a SID se inserta en la base de datos de
la política de asignación activa.

La instancia IGP utiliza esta base de datos de Política de Asignación Activa para derivar un Prefijo-SID para
algunos o todos los prefijos que no tienen un Prefijo-SID asociado. Tenga en cuenta que cada instancia IGP que
se ejecuta en el deriva su propia Política de Asignación Activa, probablemente diferente. Mientras que la
Política de Mapeo Local es global en el nodo, compartida por todas las instancias IGP.
8.5 Configuración de la política local del servidor de asignación
Una Política de Mapeo Local se configura estáticamente en un nodo actúa como Servidor de Mapeo. Esta
Política de Mapeo Local consiste en mapeos estáticos de prefijos a índices prefijo-SID, los mapeos prefijo-a-
SID. La Política Local de Mapeo puede contener mapeos prefijo-a-SID tanto IPv4 como IPv6. Los mapeos
prefijo-a-SID IPv6 sólo pueden ser anunciados por ISIS en la implementación Cisco IOS-XR en el momento de
escribir este libro.

Las asignaciones de prefijo a SID no necesitan configurarse por prefijo individual, sino que pueden
configurarse como rangos de prefijos asignados a rangos de índices prefijo-SID. Cada prefijo en el rango
entonces se mapea estáticamente al índice prefijo-SID en el mismo offset en el rango.

La configuración de mapeo para un rango de prefijos consiste en el prefijo, su longitud de prefijo, el primer
índice Prefijo-SID a utilizar para este rango de prefijos, y el tamaño del rango de prefijos. Nótese bien que
la configuración requiere índices SID, no valores de etiqueta. Véase el Ejemplo 8-1.

Ejemplo 8-1: Configuración de la política local del servidor de asignación

1 enrutamiento por segmentos

2 mapping-server
3 prefix-sid-map
4 address-family ipv4
5 !! <prefix>/<mask> <first-SID-index> range <range>
6 [Link]/32 1 rango 10
7 ¡!
8 address-family ipv6
9 2001::1:1:1:1/128 4001 alcance 10
10 ¡!
11 ¡!
12 ¡!
¡13 !

Cada prefijo del rango utiliza la misma longitud de prefijo configurada. Los prefijos suelen ser prefijos de host,
/32 o /128, cuando consideramos los escenarios de interfuncionamiento SR/LDP, pero se permiten otras
longitudes de prefijo.

Cada línea en esta configuración resulta en un mapeo prefijo-a-SID separado anunciado por IGP.

Para ISIS, es posible indicar en los anuncios del Servidor de Mapeo que se sabe que un prefijo está conectado o
adjunto al nodo que lo anuncia con la bandera A (Attached) establecida. Véase Control IGP
plano capítulo 5, "Segment Routing IGP Control Plane". Esta funcionalidad se puede utilizar si el Servidor de
Mapeo anuncia Prefijo-SIDs en nombre de nodos IGP que no están habilitados para Segment Routing ni LDP.
La bandera "Attached" puede establecer en la configuración de la Política de Mapeo Local.

Utilice el comando show segment-routing mapping-server prefix-sid-map ipv4|ipv6

[detail] para verificar la Política de Mapeo Local. Se puede examinar una entrada individual de asignación
de prefijo a SID añadiendo el prefijo al comando anterior.

El 8-2 Ejemplo Ejemplo 8-1y el Ejemplo 8-3 muestran la salida de la Política de Mapeo Local para la
configuración del .

Ejemplo 8-2: Política de asignación local IPv4

1 RP/0/0/CPU0:xrvr-4#show segment-routing mapping-server prefix-sid-map ipv4

2 Prefijo SID Índice Gama Indicadores
3 [Link]/32 1 10
4
5 Número de entradas de asignación: 1
6
7 RP/0/0/CPU0:xrvr-4#show segment-routing mapping-server prefix-sid-map ipv4 detail
8 Prefijo
9 [Link]/32
10 Índice SID: 1
11 Alcance: 10
12 Último prefijo: [Link]/32
13 Último índice 10
SID:
14 Banderas:
15

16 Número de entradas de asignación: 1

Ejemplo 8-3: Política de asignación local IPv6

1 RP/0/0/CPU0:xrvr-4#show segment-routing mapping-server prefix-sid-map ipv6

2 Prefijo SID Índice Gama Indicadores
3 2001::1:1:1:1/128 4001 10
4
5 Número de entradas de asignación: 1
6
7 RP/0/0/CPU0:xrvr-4#show segment-routing mapping-server prefix-sid-map ipv6 detail
8 Prefijo
9 2001::1:1:1:1/128
10 Índice SID: 4001
11 Alcance: 10
12 Último prefijo: 2001::1:1:1:a/128
13 Último índice 4010
SID:
14 Banderas:
15

16 Número de entradas de asignación: 1

8.6 Rangos cartográficos Resolución de conflictos
Terminología:

Entrada de asignación: asignación de prefijo a SID para un prefijo individual

Rango de mapeo: mapeo de prefijo a SID para un rango de prefijos, según lo configurado en la Política Local.
Un rango de mapeo puede expresarse como una tupla (P/L, S, N), con P/L: primer prefijo y longitud en el
rango; S: primer índice SID en el rango; y N: tamaño del rango.

Un Servidor de Asignación anuncia uno o más rangos de asignación y pueden existir múltiples Servidores de
Asignación en la red, cada uno anunciando sus propios rangos de asignación. Un cliente de asignación
considera todos los ámbitos de asignación que recibe de todos los servidores de asignación para obtener la
política activa. La Política Activa consiste en rangos de mapeo que no se solapan. Esta política activa debe ser
la misma en todos los clientes de asignación de la red para lograr un reenvío coherente en toda la red para los
Prefix-SID de las entradas de asignación.

Tenga en cuenta que el Cliente de asignación considera los rangos de asignación en su proceso de selección, no
las entradas de asignación individuales.

Los ámbitos de asignación pueden solaparse o entrar en conflicto. Los rangos de mapeo superpuestos contienen
al menos una entrada de mapeo con un prefijo o índice SID común. Los ámbitos de asignación en conflicto
contienen al menos una entrada que entra en conflicto con otra entrada. El conflicto puede ser un conflicto de
prefijo y/o un conflicto de índice SID. Si se asignan diferentes índices SID al mismo prefijo, existe un
"conflicto de prefijo". Si el mismo índice SID está asignado a varios prefijos, existe un "conflicto de índice
SID".

Tenga en cuenta que los rangos en conflicto también se solapan, ya que los rangos en conflicto contienen
prefijos comunes y/o índices SID comunes, de lo contrario no podrían entrar en conflicto. Pero los rangos
solapados no siempre son conflictivos. La Política Activa consiste en rangos de mapeo no solapados, por lo tanto
no conflictivos.

La configuración del servidor de asignación en Cisco IOS-XR sólo acepta rangos de asignación no solapados
para la política de asignación local. Por lo tanto, un de asignación de Cisco IOS XR sólo anuncia intervalos
de asignación válidos que no se solapen. Sin embargo, es posible que dos servidores de asignación
diferentes anuncien asignaciones que entren en conflicto o se solapen.
Tenga en cuenta que, en el momento de escribir este arranque, se están llevando a cabo debates en el IETF
para llegar a un consenso sobre la gestión de estos escenarios de conflicto de forma determinista en todas las
implementaciones (consulte el borrador-ietf-spring-conflict-resolution). Basándose en la estandarización de los
mecanismos de resolución de conflictos, la implementación en Cisco IOS XR también puede actualizarse en el
futuro para gestionar los conflictos por parte de la función Mapping Client - no se esperan cambios en la
comprobación de conflictos para garantizar la coherencia durante la configuración por parte de la función
Mapping Server.

8.6.1 Ejemplos de superposición y conflicto de ámbitos cartográficos

Los ejemplos de esta sección utilizan IPv4; existen reglas equivalentes para rangos de mapeo IPv6. Un
ejemplo de conjunto no conflictivo, pero solapado, de rangos de mapeo prefijo-a-SID: ([Link]/32, 100, 10) y
([Link]/32, 105, 5). Los rangos de asignación se expresan como una tupla (P/L, S, N), con P/L: primer prefijo
y longitud en el rango; S: primer índice SID en el rango; y N: tamaño del rango. Las entradas individuales de
mapeo de prefijo a SID se muestran en la Tabla 8-1. Las entradas de mapeo del primer rango se muestran en
columnas de la izquierda, las entradas de mapeo del segundo rango en las columnas de la derecha.

Tabla 8-1: Asignaciones de prefijo a SID no conflictivas y solapadas

Entrada de asignación del intervalo ([Link]/32, 100, 10) Entrada de asignación del intervalo ([Link]/32, 105, 5)

prefijo Índice SID prefijo Índice SID

[Link]/32 100

[Link]/32 101

[Link]/32 102

[Link]/32 103

[Link]/32 104

[Link]/32 105 [Link]/32 105

[Link]/32 106 [Link]/32 106

[Link]/32 107 [Link]/32 107

[Link]/32 108 [Link]/32 108

[Link]/32 109 [Link]/32 109

No hay conflicto, los prefijos de ambos rangos se asignan al mismo índice prefijo-SID, pero algunas de las
entradas de los rangos son comunes. En tal , el cliente de asignación sólo selecciona uno de los rangos. La
verificación de la configuración en IOS XR garantiza que no se puedan configurar tales entradas superpuestas
en la política local. Véase el ejemplo 8-4.

Ejemplo 8-4: Error de configuración al solapar las asignaciones de prefijo a SID

1 RP/0/0/CPU0:xrvr-1#configurar
2 RP/0/0/CPU0:xrvr-1(config)#enrutamiento por segmentos
3 RP/0/0/CPU0:xrvr-1(config-sr)# mapping-server
4 RP/0/0/CPU0:xrvr-1(config-sr-ms)# prefix-sid-map
5 RP/0/0/CPU0:xrvr-1(config-sr-ms-map)# address-family ipv4
6 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)# [Link]/32 100 rango 10
7 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)# [Link]/32 105 rango 5
8 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)#commit
9
10 % Failed to commit one or more configuration items during a pseudo-atomic operation.
Todos los cambios realizados han sido revertidos. Por favor, ejecute 'show configuration
failed [inheritance]' desde esta sesión para ver los errores.
11 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)#show configuration failed
12 ¡¡!! ERRORES SEMÁNTICOS: Esta configuración fue rechazada por
13 el sistema debido a errores semánticos. El individuo
14 !! los errores con cada comando de configuración fallido pueden ser
15 ...que encontrarás a continuación.
16
17
18 enrutamiento de segmentos
19 mapping-server
20 prefix-sid-map
21 address-family ipv4
22 [Link]/32 105 alcance 5
23 !!% Argumento inválido: Solapamiento IP
24 [Link]/32 .. [Link]/32
25 El elemento solapado es [Link]/32 100 10
26 ¡!
27 ¡!
28 ¡!
¡29 !
30 fin

Si se asignan diferentes índices SID al mismo prefijo, se produce un "conflicto de prefijo". Los conflictos de
prefijo sólo pueden ocurrir entre rangos de mapeo de la misma familia de direcciones y la misma longitud de
prefijo. Considera el siguiente conjunto de rangos de mapeo prefijo-a-SID: ([Link]/32, 100, 10) y ([Link]/32,
10, 5). Cada entrada individual de mapeo prefijo-a-SID se muestra en la Tabla 8-2. Las entradas de mapeo de
del primer rango se muestran en las columnas de la izquierda, las entradas de asignación del segundo
rango en las columnas de la derecha.

Tabla 8-2: Asignaciones de prefijo a SID en conflicto: conflicto de prefijo

Entrada de asignación del intervalo ([Link]/32, 100, 10) Entrada de asignación de rango ([Link]/32, 10, 5)

prefijo Índice SID prefijo Índice SID

[Link]/32 100

[Link]/32 101

[Link]/32 102

[Link]/32 103

[Link]/32 104

[Link]/32 105 (!) [Link]/32 10 (!)

[Link]/32 106 (!) [Link]/32 11 (!)

[Link]/32 107 (!) [Link]/32 12 (!)

[Link]/32 108 (!) [Link]/32 13 (!)

[Link]/32 109 (!) [Link]/32 14 (!)

Los prefijos 1.1.1.n/32, con n=6...10 se asignan a dos índices SID diferentes: 105...109 y 10...
14. El cliente de mapeo podría extraer lógicamente las entradas de los rangos de mapeo prefijo-a-SID que no
tienen conflicto, es decir ([Link]/32, 100, 5) en este ejemplo, pero esto llevaría a una complejidad de
implementación adicional en el cliente y no se considera. La verificación de la configuración en IOS XR
garantiza que no se puedan configurar tales rangos conflictivos (y solapados).
Ejemplo 8-5: Error de configuración conflicto de prefijos

1 RP/0/0/CPU0:xrvr-1#configurar
2 RP/0/0/CPU0:xrvr-1(config)#enrutamiento por segmentos
3 RP/0/0/CPU0:xrvr-1(config-sr)# mapping-server
4 RP/0/0/CPU0:xrvr-1(config-sr-ms)# prefix-sid-map
5 RP/0/0/CPU0:xrvr-1(config-sr-ms-map)# address-family ipv4
6 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)# [Link]/32 100 rango 10
7 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)# [Link]/32 10 rango 5
8 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)#commit
9
10 % Failed to commit one or more configuration items during a pseudo-atomic operation.
Todos los cambios realizados han sido revertidos. Por favor, ejecute 'show configuration
failed [inheritance]' desde esta sesión para ver los errores.
11 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)#show configuration failed
12 ¡¡!! ERRORES SEMÁNTICOS: Esta configuración fue rechazada por
13 el sistema debido a errores semánticos. El individuo
14 !! los errores con cada comando de configuración fallido pueden ser
15 ...que encontrarás a continuación.
16
17
18 enrutamiento de segmentos
19 mapping-server
20 prefix-sid-map
21 address-family ipv4
22 [Link]/32 10 gama 5
23 !!% Argumento inválido: Solapamiento IP
24 [Link]/32 .. [Link]/32
25 El elemento solapado es [Link]/32 100 10
26 ¡!
27 ¡!
28 ¡!
¡29 !
30 fin

Si se asigna el mismo índice SID a varios prefijos, existe un "conflicto de índice SID". Los conflictos SID
pueden ocurrir entre entradas de mapeo de cualquier familia de direcciones y longitud de prefijo. Considera el
siguiente conjunto de rangos de mapeo prefijo-a-SID: ([Link]/32, 100, 10) y ([Link]/32, 100, 5). Cada entrada
individual de mapeo prefijo-a-SID se muestra en la Tabla 8-3. Las entradas de mapeo del primer rango se
muestran en las columnas de la izquierda, las entradas de mapeo del segundo rango en las columnas de la
derecha.

Tabla 8-3: Asignaciones de prefijo a SID en conflicto: Conflicto de índice SID

Entrada de asignación del intervalo ([Link]/32, 100, 10) Entrada de asignación del intervalo ([Link]/32, 105, 5)

prefijo Índice SID prefijo Índice SID

[Link]/32 100 (!)

[Link]/32 101 (!)

[Link]/32 102 (!)

[Link]/32 103 (!)

[Link]/32 104 (!)

[Link]/32 105

[Link]/32 106

[Link]/32 107

[Link]/32 108

[Link]/32 109

[Link]/32 100 (!)

[Link]/32 101 (!)

[Link]/32 102 (!)

[Link]/32 103 (!)

[Link]/32 104 (!)

Los mismos índices SID: 100...104 han sido asignados a los prefijos 1.1.1.n/32 y 1.1.1.m/32, con n=1...5 y
m=11...15. También aquí el cliente de mapeo podría extraer lógicamente la parte del rango en los rangos de
mapeo prefijo-a-SID que no tiene conflicto, decir ([Link]/32, 105, 5) en este ejemplo, pero esto no se considera
debido a la complejidad adicional. La verificación de la configuración en IOS XR garantiza que no puedan
configurar tales rangos conflictivos (y solapados).
Ejemplo 8-6: Error de configuración - Conflicto de índice SID

1 RP/0/0/CPU0:xrvr-1#configurar
2 RP/0/0/CPU0:xrvr-1(config)#enrutamiento por segmentos
3 RP/0/0/CPU0:xrvr-1(config-sr)# mapping-server
4 RP/0/0/CPU0:xrvr-1(config-sr-ms)# prefix-sid-map
5 RP/0/0/CPU0:xrvr-1(config-sr-ms-map)# address-family ipv4
6 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)# [Link]/32 100 rango 10
7 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)# [Link]/32 100 rango 5
8 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)#commit
9
10 % Failed to commit one or more configuration items during a pseudo-atomic operation.
Todos los cambios realizados han sido revertidos. Por favor, ejecute 'show configuration
failed [inheritance]' desde esta sesión para ver los errores.
11 RP/0/0/CPU0:xrvr-1(config-sr-ms-map-af)#show configuration failed
12 ¡¡!! ERRORES SEMÁNTICOS: Esta configuración fue rechazada por
13 el sistema debido a errores semánticos. El individuo
14 !! los errores con cada comando de configuración fallido pueden ser
15 ...que encontrarás a continuación.
16
17
18 enrutamiento de segmentos
19 mapping-server
20 prefix-sid-map
21 address-family ipv4
22 [Link]/32 100 alcance 5
23 !!% Argumento inválido: SID overlap:
24 100 .. 104
25 El elemento solapado es [Link]/32 100 10
26 ¡!
27 ¡!
28 ¡!
¡29 !
30 fin

8.6.2 Selección de ámbitos de asignación de diferentes servidores de

asignación
Para propósitos de redundancia, deben existir múltiples Servidores de Mapeo en la red. Se espera que todos
estos Servidores de Mapeo anuncien los mismos mapeos prefijo-a-SID, pero esto puede no ser siempre el caso.
Diferentes Servidores de Mapeo pueden anunciar diferentes o incluso conflictivos mapeos prefijo-a-SID.
Además, las asignaciones de prefijo a SID anunciadas por el servidor de asignación también pueden entrar en
conflicto con otros anuncios de prefijo a SID. Si un cliente de mapeo recibe entradas de mapeo conflictivas, no
puede saber cuáles son correctas y incorrectas. El borrador del IETF draft-ietf-spring-conflict-resolution
describe diferentes estrategias para hacer frente a estos conflictos. Una primera estrategia podría ser ignorar
todas las conflictivas.
Otra estrategia podría ser seleccionar y utilizar una de las entradas conflictivas aplicando un conjunto de reglas.
Este último enfoque es el seleccionado en la implementación de Cisco IOS XR. Para garantizar entradas de
reenvío coherentes, las reglas que se utilicen deben ser tales que den como resultado el mismo conjunto de
asignación (Política de asignación local) en cada Cliente de asignación de red.

Si un Cliente de asignación recibe dos o más de asignación superpuestos, selecciona uno de rangos
superpuestos basándose en las siguientes reglas de preferencia. Estas reglas se aplican secuencialmente al
conjunto de intervalos de asignación hasta que una regla da como resultado un único intervalo; este intervalo se
selecciona entonces como intervalo de asignación preferido.

1. Se prefiere el router-id más grande (OSPF) o el system-id (ISIS)

2. Se prefiere el id de área más pequeño (OSPF) o el nivel (ISIS)

3. El rango IPv4 es preferible al rango IPv6

4. Se prefiere el prefijo de menor longitud

5. Se prefiere la dirección IP más pequeña

6. Se prefiere el índice SID más pequeño

7. Se prefiere la gama más pequeña

8. Se prefiere la primera gama recibida

El Cliente de Asignación inserta el rango de asignación preferido en la Política Activa, y los otros rangos de
asignación no seleccionados, en la Política de Respaldo.

Las reglas 3 a 8 sólo se utilizan si un Servidor de Mapeo individual anuncia rangos de mapeo solapados o
cuando un ABR propaga rangos de mapeo solapados. Lo primero normalmente no se observaría para un
Servidor de Mapeo Cisco IOS XR ya que sólo se aceptan rangos de mapeo no conflictivos y no solapados
cuando se configura la Política de Mapeo Local. [2]

Las reglas de preferencia implementadas actualmente garantizan una política de asignación activa coherente
para todos los clientes de asignación de una misma área. Sin embargo, no garantizan Políticas Activas
coherentes en todos los Clientes de Asignación de red si los anuncios de asignación se propagan entre áreas o
niveles. Cuando el nodo ABR o L1L2 propaga los mapeos prefijo-a-SID, (re)origina los mapeos
con su propio router-id o system-id. Esto afecta a la selección del mapeo prefijo-a-SID ya que el identificador
de enrutador o identificador de sistema se utiliza en la primera regla de preferencia. Dado que el system-id o
router-id del anuncio de mapeo propagado ha cambiado, un mapeo prefijo-a-SID que es preferido en un área,
puede no ser preferido en otra área o al .

IETF draft-ietf-spring-conflict-resolution especifica reglas que aseguran una selección consistente de

mapeos prefijo- a-SID en todos los Mapping Clients y como se mencionó anteriormente no todas sus reglas
están implementadas en Cisco IOS XR pendiente de consenso al momento de escribir este .

El siguiente ejemplo ilustra la selección de mapeos Prefijo-a-SID. La Figura 8-2 muestra una topología con
dos Servidores de Mapeo, Nodo2 y Nodo3, y un Cliente de Mapeo, Nodo1. Los Servidores de Mapeo
anuncian un rango de mapeo común y tres rangos de mapeo que se superponen y/o entran en conflicto con los
rangos de mapeo del otro Servidor de Mapeo. Los ámbitos de en conflicto son equivalentes a los ámbitos
utilizados en la sección 8.6.1, Ámbitos de asignación solapados y en conflicto - ejemplos". Consulte dicha
sección para obtener más informació[Link]ón solapados y

Figura 8-2: topología de red con dos servidores de mapeo

La Tabla 8-4 muestra los rangos de mapeo anunciados uno al lado del otro. Las asignaciones de prefijo a SID se
escriben como tuplas (P/L, S, N). Con P/L: primer prefijo; S: primer índice SID; N: tamaño del rango.

Tabla 8-4: Asignación de servidores de prefijo a SID

Anunciada por el Nodo 2 (ruta r- id Anunciada por el Nodo 3 (ruta r-id Comentario ([Link]/32, 100, 10)
[Link]) [Link])

ninguno Sin solapamientos ([Link]/32, 200, 10) ([Link]/32, 200, 10)

Idéntico ([Link]/32, 300, 10) ([Link]/32, 305, Solapamiento, no

5) contradictorio

([Link]/32, 400, 10) ([Link]/32, 410, 5) Conflicto de prefijos ([Link]/32, 500, 10)

Para los rangos de mapeo solapados (filas 2 a 5 en la Tabla 8-4), el Cliente de Mapeo prefiere los rangos
anunciados por el Servidor de Mapeo con el router-id o system-id más alto, Nodo3 en este ejemplo. El Cliente
de Mapeo también seleccionó el no solapado (fila 1 en la Tabla 8-4), que sólo es anunciado por Nodo2. Los
rangos de mapeo preferidos están resaltados en la Tabla 8-4. Las configuraciones de la Política de Mapeo Local
en el Nodo2 y Nodo3 se muestran en el Ejemplo 8-7 y Ejemplo 8-8.

Ejemplo 8-7: Configuración de mapeo local Nodo2

1 enrutamiento por segmentos

2 mapping-server
3 prefix-sid-map
4 address-family ipv4
5 [Link]/32 100 alcance 10
6 [Link]/32 200 alcance 10
7 [Link]/32 Alcance 300 10
8 [Link]/32 Alcance 400 10
9 [Link]/32 Gama 500 10
10 ¡!
11 ¡!
12 ¡!
¡13 !

Ejemplo 8-8: Configuración de mapeo local Nodo3

1 enrutamiento por segmentos

2 mapping-server
3 prefix-sid-map
4 address-family ipv4
5 [Link]/32 200 gama 10
6 [Link]/32 305 gama 5
7 [Link]/32 410 gama 5
8 [Link]/32 500 alcance 5
9 ¡!
10 ¡!
11 ¡!
12 ¡!
La Política de Asignación Local es independiente del IGP. La Política Activa y la Política de Respaldo sin
embargo, son derivadas por IGP. Estas Políticas de Mapeo pueden ser verificadas en el IGP usando el
comando show isis|ospf segment-routing prefix-sid-map active-policy|backup-
policy. Vea la salida para OSPF en el Nodo Cliente de Mapeo1 en el Ejemplo 8-9 y la salida detallada en el
Ejemplo 8-10.

Ejemplo 8-9: Política de asignación activa

1 RP/0/0/CPU0:xrvr-1#show ospf segment-routing prefix-sid-map active-policy

2
3 Política activa SRMS para ID de proceso 1
4
5 Prefijo SID Índice Gama Indicadores
6 [Link]/32 200 10
7 [Link]/32 305 5
8 [Link]/32 410 5
9 [Link]/32 500 5
10 [Link]/32 100 10
11
12 Número de entradas de mapeo: 5

Ejemplo 8-10: Política detallada de asignación activa

1 RP/0/0/CPU0:xrvr-1#show ospf segment-routing prefix-sid-map active-policy detail

2
3 Política activa SRMS para ID de proceso 1
4
5 Prefijo
6 [Link]/32
7 Fuente: Remoto
8 ID de router: [Link]
9 Identificación de 1
la zona:
10 Índice SID: 200
11 Alcance: 10
12 Último prefijo: [Link]/32
13 Último índice 209
SID:
14 Banderas:
15 [Link]/32
16 Fuente: Remoto
17 ID de router: [Link]
18 Identificación de 1
la zona:
19 Índice SID: 305
20 Alcance: 5
21 Último prefijo: [Link]/32
22 Último índice 309
SID:
23 Banderas:
24 [Link]/32
25 Fuente: Remoto
26 ID de router: [Link]
27 Identificación de 1
la zona:
28 Índice SID: 410
29 Alcance: 5
30 Último prefijo: [Link]/32
31 Último índice 414
SID:
32 Banderas:
33 [Link]/32
34 Fuente: Remoto
35 ID de router: [Link]
36 Identificación de 1
la zona:
37 Índice SID: 500
38 Alcance: 5
39 Último prefijo: [Link]/32
40 Último índice 504
SID:
41 Banderas:
42 [Link]/32
43 Fuente: Remoto
44 ID de router: [Link]
45 Identificación de 1
la zona:
46 Índice SID: 100
47 Alcance: 10
48 Último prefijo: [Link]/32
49 Último índice 109
SID:
50 Banderas:
51

52 Número de entradas de mapeo: 5

De los rangos de mapeo solapados, el Cliente de Mapeo en Nodo1 prefirió los anunciados por el nodo con el
router-id más alto, Nodo3. El Nodo2 anuncia el último rango de mapeo mostrado en la Política de Mapeo
Activa, ya que Nodo3 no anuncia un rango de mapeo que se solape con éste.

Los rangos de asignación superpuestos no preferidos se añaden a la política de asignación de copias de

seguridad. Ver Ejemplo 8-11. En este ejemplo, la Política de Mapeo de Respaldo contiene los rangos de mapeo
que el Nodo2 anuncia.
Ejemplo 8-11: Política de asignación de copias de seguridad

1 RP/0/0/CPU0:xrvr-1#show ospf segment-routing prefix-sid-map backup-policy

2
3 Política de copia de seguridad SRMS para ID de proceso 1
4
5 Prefijo SID Índice Gama Indicadores
6 [Link]/32 200 10
7 [Link]/32 300 10
8 [Link]/32 400 10
9 [Link]/32 500 10
10
11 Número de entradas de mapeo: 4

8.6.3 Conflicto de rango de asignación con Prefijo-SID "nativo

Como recordatorio, los IGPs reciben asignaciones de Prefijo-SID vía configuración local en el router así como
vía Anuncio IGP de Prefijo-SIDs como se describe en el capítulo 5, "Plano de Control IGP de Enrutamiento por
Segmentos". Estas asignaciones también proporcionan el mapeo de un prefijo a su SID, pero la diferencia es
que provienen de nodos donde probablemente han sido configuradas explícitamente. En aras de la
simplicidadlas describimos como mapeo Prefijo-SID "nativo" y podrían ser consideradas más autoritarias en
comparación con las asignaciones SID que provienen de una fuente como el Servidor de Mapeo. Este es un
punto de vista y no tomarse como un consenso.

Ahora es posible que el IGP obtenga un mapeo Prefijo-SID de la Política de Mapeo Activa de la función
Cliente de Mapeo para un prefijo para el cual también obtiene una asignación Prefijo-SID "nativa". Si el valor
SID es el mismo no hay problema, pero si son diferentes entonces tenemos un escenario de conflicto. En el
momento de escribir este libro, las implementaciones IGP de Cisco IOS-XR prefieren el Prefijo-SID "nativo"
sobre el mapeo recibido vía SRMS - es decir, la implementación intenta encontrar un mapeo SID para un
prefijo en la política de mapeo activa sólo cuando no ha recibido uno "nativo". Como se ha mencionado
anteriormente, este comportamiento también objeto de la resolución draft-ietf-spring-conflict-resolution que
no ha alcanzado un consenso en momento de escribir este libro.
DESTACADO: Modificación de las asignaciones SRMS

Una vez que los Servidores de Mapeo se despliegan con cierta configuración de rangos de mapeo y se utilizan activamente en un
despliegue, se debe tener especial cuidado al realizar cualquier cambio de configuración en él.

Volver a insistir en el concepto de gamas conflictivas y/o solapadas y en las repercusiones cuando se producen conflictos.

Lo mejor es aprovisionar las asignaciones en varios servidores de asignación de forma simultánea y sin errores con el uso de herramientas
de aprovisionamiento centralizadas como Cisco Network Service Orchestrator.

Cuando cambian las configuraciones de los rangos de mapeo de forma que haya conflictos, es posible que algunos routers pierdan sus
segmentos de prefijo y en este caso el reenvío pase a IP nativo o LDP.

La pérdida de tráfico y el impacto en el servicio podría ocurrir si diferentes implementaciones de routers interpretan y realizan la
resolución de conflictos de manera diferente, ya que esto podría conducir a un estado de reenvío inconsistente a través de los routers;
supervise cómo evoluciona el consenso en el IETF para draft-ietf-spring-conflict-resolution.
8.7 Configuración IGP para SRMS
8.7.1 Servidor de mapas
Para actuar como un Servidor de Mapeo, el anuncio de los mapeos prefijo-a-SID configurados localmente (la
Política de Mapeo Local) debe estar habilitada en el IGP. Configure segment-routing prefix-
sid-map advertise-local bajo el IGP para habilitar la publicidad. Ver Ejemplo 8-12 para ISIS y
Ejemplo 8-13 para OSPF.

Ejemplo 8-12: Configuración del Servidor de Mapeo ISIS

1 enrutador isis 1
2 address-family ipv4 unicast
3 segment-routing prefix-sid-map advertise-local
4 ¡!
5 address-family ipv6 unicast
6 segment-routing prefix-sid-map advertise-local
¡7 !

Ejemplo 8-13: Configuración del Servidor de Mapeo OSPF

1 router ospf 1
2 segment-routing prefix-sid-map advertise-local
¡3 !

Sólo se puede configurar una Política de Mapeo Local en un nodo determinado. Si múltiples instancias IGP en
un nodo tienen la funcionalidad de Servidor de Mapeo habilitada, todas ellas usan y anuncian la misma
Política de Mapeo Local.

Si la función de Servidor de Mapeo está habilitada en una instancia IS-IS L1L2, entonces la Política de Mapeo
Local se anuncia en todos los niveles. Si la función de servidor de asignación está habilitada en un ABR OSPF,
la política de asignación local se anuncia en todas las áreas habilitadas para el enrutamiento por segmentos de
esa instancia OSPF. El comando segment-routing prefix-sid-map advertise-local para
OSPF tiene alcance de instancia: se aplica a todas las áreas de una instancia. Los anuncios del Servidor de
Mapeo no necesitan ser habilitados/deshabilitados por área ya que los anuncios son en cualquier inundados por
IGPs a través de las áreas/niveles Sin embargo, si los prefijos reales no están disponibles en el área (por
ejemplo debido a filtrado o resumen) entonces sólo los anuncios de mapeo Prefijo-SID no tendrían efecto.
El Ejemplo 8-14 muestra un ejemplo de un Servidor de Mapeo configurado para anunciar un conjunto de
mapeos prefijo-a-SID IPv4 e IPv6 en ISIS.

Ejemplo 8-14: Configuración de Política de Mapeo Local y Servidor de Mapeo ISIS

1 enrutamiento por segmentos

2 mapping-server
3 prefix-sid-map
4 address-family ipv4
5 [Link]/32 10 rango 40
6 [Link]/24 100 alcance 60
7 ¡!
8 address-family ipv6
9 2001::1:1:1:0/128 2010 rango 40
10 2001::2:1:1:0/112 2100 alcance 60
¡11 !
12 enrutador isis 1
13 address-family ipv4 unicast
14 segment-routing prefix-sid-map advertise-local

En este ejemplo se configuran dos rangos de mapeo de prefijo a SID IPv4. El primero es un rango de 40
asignaciones para un rango de prefijos que comienza en [Link]/32, con el rango de índice Prefijo-SID que
comienza en el índice
10. Como resultado de esta configuración, el prefijo [Link]/32 se asigna al Prefijo-SID índice 10, [Link]/32 se
asigna al Prefijo-SID índice 11, y así sucesivamente hasta el prefijo [Link]/32 que se asigna al Prefijo-SID
índice 49. Todos los prefijos tienen la misma longitud de prefijo. Véase la Tabla 8-5.

Tabla 8-5: Asignaciones de prefijo IPv4 a índice Prefijo-SID

Prefijo Índice prefijo-SID

[Link]/32 10

[Link]/32 11

... ...

[Link]/32 49

Normalmente, los índices Prefijo-SID se asocian a prefijos de host, pero asociarse a prefijos de otras longitudes.
Para ilustrar el uso de una longitud de prefijo distinta de la longitud del prefijo de host, el segundo rango de
asignación del ejemplo muestra un rango de asignación de prefijo a SID con un prefijo de longitud
24. Todos los prefijos del intervalo tendrán la misma longitud de prefijo 24 y los prefijos del intervalo son
se incrementan en función de la longitud del prefijo. En el ejemplo de un prefijo /24, se incrementa el tercer
dígito del prefijo.

Como resultado de esta configuración, el prefijo [Link]/24 se asigna al Prefijo-SID índice 100, [Link]/24
se asigna al Prefijo-SID índice 101, y así sucesivamente hasta el prefijo [Link]/24 que se asigna al Prefijo-
SID índice 159. Todos los prefijos tienen la misma longitud de prefijo 24. Véase la Tabla 8-6.

Tabla 8-6: Asignaciones de prefijo IPv4 a índice Prefijo-SID, prefijos no-host

Prefijo Índice prefijo-SID

[Link]/24 100

[Link]/24 101

... ...

[Link]/24 159

8.7.2 Cliente de cartografía

Una configuración típica de Cliente de Mapeo no tiene ninguna Política de Mapeo Local configurada. Y no está
configurado para anunciar mapeos prefijo-a-SID locales en el IGP.

El Cliente de Mapeo recibe, analiza y procesa los anuncios del Servidor de Mapeo recibidos por el IGP. La
funcionalidad de Cliente de Mapeo está habilitada por defecto en todos los nodos de Enrutamiento por
Segmentos. Si es necesario, la funcionalidad del Cliente de Mapeo puede ser deshabilitada configurando
segment-routing prefix-sid-map receive disable bajo el IGP. Ver Ejemplo 8-15 y
Ejemplo 8-16.

Ejemplo 8-15: desactivar la función Mapping Client en ISIS

1 enrutador isis 1
2 address-family ipv4 unicast
3 segment-routing prefix-sid-map receive disable
4 ¡!
5 address-family ipv6 unicast
6 segment-routing prefix-sid-map receive disable
7 ¡!
¡8 !
Ejemplo 8-16: desactivar la función Mapping Client en OSPF

1 router ospf 1
2 segment-routing prefix-sid-map receive disable
¡3 !

8.7.3 Servidor de mapas y cliente de mapas

Como se ha visto anteriormente, es posible que el mismo nodo albergue tanto la función de Servidor de
Mapeo como la de Cliente. La Tabla 8-7 describe el comportamiento del Servidor de Mapeo y del Cliente de
Mapeo resultante de las diferentes opciones de configuración del prefijo-sid-map bajo la
configuración IGP. La primera columna indica las opciones de configuración. La columna del medio,
"Advertise Local Policy?", indica si los mapeos prefijo-a-SID de la Política de Mapeo Local son anunciados
con la configuración de la primera columna. La tercera , "Compute Active Policy", indica qué asignaciones se
utilizan al derivar la política de asignación activa. Los "Mapeos locales" son los mapeos prefijo-a-SID de la
Política de Mapeo Local, y los "Mapeos remotos" son los mapeos prefijo-a-SID recibidos de los Servidores de
Mapeo remotos.

Tabla 8-7: Opciones de configuración del Servidor de Mapeo y del Cliente de Mapeo

Opción de ¿Publicitar la política Política activa de cálculo

configuración local?

recibir (por defecto) No Ignorar asignaciones

locales Utilizar
asignaciones remotas

publicidad-local + desactivar Sí Utilizar asignaciones

recepción locales Ignorar asignaciones
remotas

publicidad-local + reciba Sí Utilizar asignaciones

locales Utilizar
asignaciones remotas

De la Tabla 8-7:

Si sólo está configurada la recepción segment-routing prefix-sid-map (este es el valor

por defecto y no se muestra en la configuración), entonces la Política de Mapeo Local, si está configurada,
no se anuncia en el IGP. Con esta configuración la política de mapeo configurada localmente es ignorada
y sólo los mapeos prefijo-a-SID recibidos de Servidores de Mapeo remotos son usados para calcular la
Política Activa. Esta es una configuración típica de Cliente de Mapeo.

Si segment-routing prefix-sid-map advertise-local y segment-

routing prefix-sid-map receive , entonces la Política de Mapeo Local es anunciada por el
IGP. Con esta configuración los mapeos prefijo-a-SID recibidos de Servidores de Mapeo remotos son
ignorados y sólo los mapeos prefijo-a-SID en la Política de Mapeo Local son usados para calcular la
Política Activa. Prácticamente esta es una combinación que nunca debería usarse.

Si ambos segment-routing prefix-sid-map receive y segment-routing

prefix-sid-map advertise-local son configurados, entonces la Política de Mapeo Local es
anunciada en IGP y ambos mapeos prefijo-a-SID locales y remotos son usados para computar la
Política Activa. Esta es una configuración típica de Servidor de Mapeo.
8.8 Asignación de anuncios de servidor en IS-IS
El servidor de mapeo IS-IS anuncia mapeos de prefijo a SID utilizando TLVs de SID/Label Binding, que son
TLVs de nivel superior en el LSP ISIS. El sub-TLV Prefijo-SID se incluye como un sub-TLV de este TLV
SID/Label Binding. Cada intervalo de asignación de prefijo a SID (una línea en la configuración de asignación
local) se codifica en un TLV de SID/Label Binding independiente.

El borrador de extensiones ISIS SR del IETF[ 3] describe tres aplicaciones del TLV SID/Label Binding:

Anunciar un enlace SID/Etiqueta a un FEC junto con al menos un único anclaje "estilo nexthop".
Anunciar los enlaces SID/Etiqueta y sus rutas primaria y de reserva asociadas.

Anunciar prefijos a las correspondencias SID/Etiqueta para la funcionalidad "Servidor de correspondencias".

En este sólo se trata la aplicación Mapping Server. Los detalles de las demás aplicaciones pueden encontrarse
en el borrador del IETF.

La Figura 8-3 muestra el formato del TLV SID/Label Binding.

Figura 8-3: Formato TLV ISIS SID/Label Binding

El TLV SID/Label Binding contiene los siguientes campos:

Banderas:
F (Address-Family): si no está configurado, el prefijo FEC es un prefijo IPv4; si está configurado, el
prefijo FEC es un prefijo IPv6.

M (Mirror Context): se establece si el SID/ruta corresponde a un contexto reflejado. Ver ietf-

spring- segment-routing para más detalles - IOS XR: siempre unset.

S (Scope): si no está activado, este TLV no debe propagarse entre niveles; si está activado, este TLV
puede propagarse por todo el dominio. El uso de este indicador es equivalente al indicador S del TLV de
capacidad de enrutador - IOS XR: siempre desactivado.

D (Down): set si este TLV se propaga de Nivel-2 a Nivel-1, unset en caso contrario. Si se estableceno se
propaga del Nivel-1 al Nivel-2. Se utiliza para evitar la inundación innecesaria de este . El uso de esta
bandera es equivalente a la bandera D en el Router Capability TLV - IOS XR: siempre unset

A (Attached): se establece si se sabe que los prefijos del TLV están adjuntos a sus originadores. El
indicador A debe estar desactivado si este TLV se filtra a otro nivel/área. - IOS XR por defecto:
unset

Campo Peso: El valor representa el peso de la ruta a efectos de equilibrio de carga - IOS XR: siempre 0

Rango: número de entradas de asignación de prefijo a SID en el rango de

asignación Longitud del prefijo y prefijo FEC: el primer prefijo en rango de
asignación
sub-TLV: El sub-TLV Prefijo-SID que indica el primer índice Prefijo-SID del rango de mapeo prefijo-a-SID.

El sub-TLV Prefijo-SID fue cubierto anteriormente en este libro, en el capítulo 5 del plano de control SR IGP.
En esa sección el Prefix-SID sub-TLV fue usado para anunciar un Prefix-SID "nativo", un Prefix-SID adjunto
a un IP Reachability TLV. La aplicación Mapping Server utiliza el mismo sub-TLV, pero hay una diferencia en la
interpretación de las banderas en ese sub-TLV. El formato del sub-TLV Prefix-SID se repite aquí en la Figura
8-4, con el campo Flags adaptado a su uso aquí. El sub-TLV Prefix-SID utilizado en el TLV SID/Label
Binding sólo puede utilizar el indicador N.
Figura 8-4: Campo de banderas del sub-TLV Prefijo-SID

Los indicadores del sub-TLV de prefijo-SID que se utilizan cuando se incluyen en el TLV de enlace SID/etiqueta:

N (Node-SID): establecido si el Prefix-SID es un Node-SID, es decir, identifica el nodo - siempre sin

establecer en Cisco IOS XR

Los demás indicadores de este sub-TLV no se utilizan para la aplicación del servidor de mapas y se ignoran en
la recepción.

El campo Algoritmo del sub-TLV Prefijo-SID se establece en 0 (SPF) en Cisco IOS XR.

Los anuncios del Servidor de Mapeo pueden verificar en la base de datos link-state IS-IS. El Ejemplo 8-17
muestra la salida de show isis database verbose para un LSP ISIS anunciado por un Servidor de
Mapeo. El Servidor de Mapeo tiene la Política de Mapeo Local configurada como en el Ejemplo 8-14. Cada
entrada de la Política de Mapeo Local configurada tiene una entrada de la Política de Mapeo Local. Cada
entrada configurada de Política de Mapeo Local se anuncia como un TLV separado en el LSP ISIS del Servidor
de Mapeo.
Ejemplo 8-17: Anuncios del Servidor de Mapeo ISIS

1 RP/0/CPU0:xrvr-5#show isis database verbose xrvr-5

2
3 IS-IS 1 (Nivel-2) Base de datos de estado de enlace
4 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
5 xrvr-5.00-00 * 0x000000d9 0x9c55 1100 0/0/0
6 Dirección de área: 49.0002
7 NLPID: 0xcc
8 NLPID: 0x8e
9 MT: Estándar (IPv4 Unicast)
10 MT: IPv6 Unicast 0/0/0
11 Nombre de host: xrvr-5
12 Dirección IP: [Link]
13 Dirección IPv6: 2001::1:1:1:5
14 Router Cap: [Link], D:0, S:0
15 Enrutamiento de segmentos: I:1 V:1, SRGB Base: 16000 Rango: 8000
16 <...>
17 Enlace SID: [Link]/32 F:0 M:0 S:0 D:0 A:0 Peso:0 Alcance:40
18 SID: Inicio:10, Algoritmo:0, R:0 N:0 P:0 E:0 V:0 L:0
19 Enlace SID: [Link]/24 F:0 M:0 S:0 D:0 A:0 Peso:0 Alcance:60
20 SID: Inicio:100, Algoritmo:0, R:0 N:0 P:0 E:0 V:0 L:0
21 Enlace SID: 2001::1:1:1:0/128 F:1 M:0 S:0 D:0 A:0 Peso:0 Alcance:40
22 SID: Inicio:2010, Algoritmo:0, R:0 N:0 P:0 E:0 V:0 L:0
23 Enlace SID: 2001::2:1:1:0/112 F:1 M:0 S:0 D:0 A:0 Peso:0 Alcance:60
24 SID: Inicio:2100, Algoritmo:0, R:0 N:0 P:0 E:0 V:0 L:0
25
26 Recuento total de LSP de nivel 2 1 Recuento de LSP locales de nivel 2 1
8.9 Asignación de anuncios de servidor en OSPF
Un servidor de mapeo OSPF anuncia mapeos de prefijo a SID utilizando LSA opacos de prefijo extendido
(tipo opaco 7), el mismo tipo de LSA que para los anuncios "nativos" de prefijo a SID. Las asignaciones de
prefijo a SID se codifican en un TLV de rango de prefijo extendido de OSPFv2, un nuevo TLV de nivel
superior del LSA de prefijo extendido. El LSA de prefijo extendido de OSPFv2 también puede llevar el TLV de
prefijo extendido. Pero al contrario que el TLV de Prefijo Extendido, que está asociado a un único prefijo, el
TLV de Rango de Prefijo Extendido es para especificar atributos para un rango y por tanto se señalizan por
separado. En Cisco IOS XR cada entrada configurada de Política de Mapeo Local se anuncia en un LSA
separado que contiene un único TLV de Rango de Prefijos Extendido para simplificar la señalización de
cambios en los rangos de mapeo.

La Figura 8-5 muestra el formato del TLV Extended Prefix Range.

Figura 8-5: TLV de rango de prefijo extendido OSPFv2

El TLV OSPFv2 Extended Prefix Range contiene los siguientes campos:

Longitud del prefijo: longitud del prefijo

AF (Familia de direcciones): 0 - IPv4 unicast

Tamaño del rango: número de entradas de mapeo prefijo-a-SID en el rango de
mapeo Flags:
IA (Inter-Area): se establece si el anuncio se propaga entre áreas. Este indicador se utiliza para evitar el
bucle de anuncios del servidor de asignación entre áreas. Un ABR no propaga un anuncio del servidor
de asignación que se haya recibido de una zona no troncal y que tenga el indicador IA activado.

Prefijo de dirección: el primer prefijo del rango de prefijos

sub-TLVs: pueden incluir diferentes sub-TLVs, como el sub-TLV Prefix-SID

El sub-TLV Prefix SID ya se ha descrito en el capítulo 5, "Segment Routing IGP Control Plane" y su formato se
repite en la Figura 8-6. Si este sub-TLV se incluye en un anuncio de Servidor de Mapeo, el tratamiento de
algunos de los campos es diferente comparado con su uso en el TLV de Prefijo Extendido para anunciar un
Prefijo-SID "nativo".

Figura 8-6: Formato OSPFv2 Prefix-SID sub-TLV

El sub-TLV OSPFv2 Prefix-SID contiene los siguientes campos:

Banderas:

NP (no-PHP): se ignora si la bandera M está activada, decir, para el anuncio del

Servidor de Mapas M (Servidor de Mapas): activada ya que se anuncia desde un

Servidor de Mapas.
E (Explicit-Null): se ignora si el indicador M está activado, es decir, para el anuncio del servidor de
asignación.

V (Valor): establecido si el prefijo-SID lleva un valor absoluto, no establecido si el prefijo-SID lleva un

índice - Cisco IOS XR: siempre no establecido

L (Local/Global): activado si el prefijo-SID tiene local, desactivado si el prefijo-SID tiene importancia

global - Cisco IOS XR: siempre desactivado

MT-ID (Multi-Topology ID (como se define en IETF RFC 4915)) - IOS XR: siempre topología por defecto
(0)

Algoritmo: el algoritmo al que está asociado el Prefijo-SID. - IOS XR: establecido en 0

SID/Index/Label: si V-flag y L-flag están desactivados: el índice Prefix-SID. Cuando este sub-TLV Prefix-
SID se anuncia en un TLV de gama de prefijos ampliada (es decir, un anuncio de servidor de asignación),
el valor Prefix-SID se interpreta como un valor de índice SID inicial.

Utilice el comando show ospf database opaque-area para verificar los anuncios de mapeo
prefijo-a-SID para OSPF, como en el Ejemplo 8-18. Recuerde que estos anuncios de Servidor de Mapeo se
llevan en LSAs Opacos de Prefijo Extendido (Opaque-type 7). Los LSA opacos utilizados para los anuncios
del servidor de asignación tienen alcance de área (LSA de tipo 10) en Cisco IOS XR. El servidor de
asignación anuncia cada intervalo de política de asignación local configurado en un LSA independiente.
Ejemplo 8-18: Anuncios del Servidor de Mapeo OSPFv2

1 RP/0/0/CPU0:xrvr-5#show ospf database opaque-area [Link] self-originate

2
3
4 Enrutador OSPF con ID ([Link]) (ID de proceso 1)
5
6 Tipo-10 Área de enlace opaco Estados de enlace (Área 0)
7

8 LS edad: 51
9 Opciones: (Sin capacidad TOS, DC)
10 Tipo LS: Enlace de área opaca
11 ID de estado de enlace: [Link]
12 Tipo opaco: 7
13 Opaco ID: 3
14 Router de publicidad: [Link]
15 Número de secuencia LS: 80000001
16 Suma de comprobación: 0xa790
17 Longitud: 48
18
19 Rango de prefijo extendido TLV: Longitud: 24
20 AF : 0
21 Prefijo : [Link]/32
22 : 40
23 Banderas : 0x0 ¡¡!! IA:0
24
25 SID sub-TLV: Longitud: 8
26 Banderas : 0x60 ¡¡!! (NA); NP:1; M:1; E:0; V:0; L:0
27 MTID : 0
28 Algo : 0
29 Índice SID : 10
30

Nota: El indicador NP (PHP-off) está activado en este ejemplo. Esto se basa en una versión anterior (-05)
del borrador IETF draft-ietf-ospf-segment-routing-extensions. La versión actual del borrador del IETF (-08)
especifica que las banderas NP y E- deben ser ignoradas para los anuncios del Servidor de Mapeo, es decir,
si la bandera M está activada.
8.10 Servidor de mapas en red multiárea/nivel
8.10.1 Anuncios de ISIS Inter-Level SRMS
En el momento de escribir este libro, ISIS en Cisco IOS XR no propaga los anuncios del Servidor de Mapeo
entre niveles. Esto significa que para redes IS-IS multinivel, actualmente se requiere un Servidor de Mapeo
por área/nivel IS-IS.

8.10.2 Anuncios SRMS entre áreas OSPF

La asignación de prefijo a SID del servidor de asignación se anuncia en un LSA de prefijo extendido OSPFv2
con un TLV de rango de prefijo extendido OSPFv2. Se genera un LSA de Prefijo Extendido para cada rango de
mapeo prefijo-a-SID local. Estos LSA opacos de prefijo extendido para anuncios de servidor de asignación
tienen alcance de inundación de área (LSA de tipo 10) en Cisco IOS XR, lo que significa que un ABR debe
propagar los TLV de rango de prefijo extendido entre áreas para lograr una distribución en toda la red.

Si el servidor de asignación es un enrutador de frontera de área (ABR), el LSA de prefijo extendido con TLV de
intervalo de prefijo extendido se anuncia en cada área conectada en la que esté activado el enrutamiento por
segmentos.

Cuando un Area Border Router recibe un Extended Prefix Range TLV en un anuncio de Mapping Server,
entonces lo propaga a todas las áreas conectadas excepto de la que se recibió el anuncio de Mapping Server.
Para prevenir la inundación redundante de TLV de Rango de Prefijo Extendido entre áreas, se usa la siguiente
lógica:

ABR establece IA-flag (Inter-Area) en el TLV Extended Prefix Range cuando propaga un anuncio de mapeo
prefijo-a-SID a otra área. Una asignación de prefijo a SID en un TLV de rango de prefijo extendido con el
indicador IA activado se denomina "asignación entre áreas".

ABR nunca propaga un TLV de rango de prefijo extendido que se haya recibido de un área no troncal y
que tenga el indicador IA-flag (Inter-Area) activado

Si otro nodo alcanzable anuncia un TLV de rango de prefijo extendido como un mapeo intra-área (IA-
flag=0) en un área, entonces ABR no origina ese mismo TLV de rango de prefijo extendido como un
anuncio de mapeo inter-área (IA-flag=1) en esa área.

Nótese que la propagación de anuncios de mapeo Prefijo-a-SID es independiente de la selección de un mapeo

Prefijo-a-SID preferido de un conjunto de mapeos superpuestos. OSPF propaga todos los
pero evita la inundación redundante del mismo rango de asignación (el mismo TLV de rango de prefijo
extendido).

La Figura 8-7 y la Figura 8-8 ilustran la propagación de anuncios de mapeo y el mecanismo de prevención de
inundación redundante. La topología de red consiste en tres áreas, con dos ABRs entre el área troncal (0) y
cada una de las otras dos áreas (1 y 2). El Nodo 5 es un Servidor de mapeo y anuncia un rango de mapeo
prefijo a SID en el Área 1: (N5, M1, IA=0), donde N5 es el nodo anunciante, M1 es el rango de mapeo
prefijo a SID, e IA=0 es la bandera inter-área. Los ABRs Nodo1 y Nodo2 propagan el rango de mapeo al
Área 0 y establecen la bandera IA en el rango de mapeo propagado. En el Área hay dos instancias del
anuncio de rango de mapeo M1: (N1, M1, IA=1) del Nodo1, y (N2, M1, IA=1) del Nodo2. Los ABRs Nodo3
y Nodo4 no ven un anuncio intra-área del rango de mapeo M1 en el Área 2, por lo tanto ambos propagan el
anuncio del rango de mapeo M1 al Área 2: (N3, M1, IA=1) desde Nodo3, y (N4, M1, IA=1) desde Nodo4.
Se evita la inundación redundante. Por ejemplo, el Nodo ABR 4 no propaga el rango de mapeo (N3, M1,
IA=1) al Área 2 ya que un anuncio de mapeo entre áreas (IA-flag=1) nunca se propaga desde un área no
backbone.

Figura 8-7: Propagación de anuncios del Servidor de Mapeo

Ahora se añade el Servidor de Mapeo Nodo6 en el Área 2, ver Figura 8-8. Tanto Nodo5 como Nodo6
anuncian el mismo rango de mapeo M2. Los ABRs Nodo1 y Nodo2 propagan el anuncio del rango de mapeo
M2 al Área 0. Sin embargo, los ABRs Nodo3 y Nodo4 no propagan el anuncio del rango de mapeo M2 al
Área 2 porque el Nodo6 ya anuncia el rango de mapeo M2 en el Área 2 como anuncio intra-área (IA=0). Del
mismo modo, los ABRs Nodo1 y Nodo2 no propagan el anuncio interárea
rangos de mapeo anunciados por Nodo3 y Nodo4 en el Área 0, en el Área 1 debido al anuncio de mapeo intra-
área del Nodo5 en el Área 1.

Figura 8-8: Propagación de anuncios del Servidor de Mapeo

Veamos más de cerca cómo ocurre la propagación de los anuncios del Servidor de Mapeo en OSPF. Para esta
ilustración, con configuraciones de router y comandos show, se usa la misma topología que en la sección
OSPF inter-área (ver capítulo 5). La topología se repite aquí en la Figura 8-9. Es una cadena de 7 nodos. Es
una cadena de 7 nodos. Nodo1, Nodo2, y Nodo3 están en el área 1. Nodo3, Nodo4 y Nodo5 están en el área 0.
Los nodos 5, 6 y 7 están en el área 2.

Figura 8-9: topología de la red entre zonas

Nodo1 está configurado como Servidor de Mapeo con la configuración de la Política de Mapeo Local mostrada
en el Ejemplo 8-19.
Ejemplo 8-19: Configuración de la Política Local del Servidor de Mapeo

1 enrutamiento por segmentos

2 mapping-server
3 prefix-sid-map
4 address-family ipv4
5 [Link]/32 10 rango 40
6 [Link]/24 100 alcance 60
7 ¡!
8 ¡!
9 ¡!
¡10 !
11 router ospf 1
12 segment-routing prefix-sid-map advertise-local
¡13 !

Nodo1 anuncia los mapeos prefijo-a-SID en dos LSAs de Prefijo Extendido, uno por rango de mapeo prefijo-
a-SID. Ver Ejemplo 8-20 y Ejemplo 8-21. El indicador IA del TLV de rango de prefijo extendido no está
activado. El NP-flag (PHP-off) y el M-flag (Mapping Server) del Prefix-SID sub-TLV están ambos
establecidos. IETF draft-ietf-ospf-segment-routing-extensions-08 especifica ignorar el NP-flag si el M-flag
está activado.
Ejemplo 8-20: Rango de prefijos extendido en el Área 1, [Link]/24

1 RP/0/0/CPU0:xrvr-1#show ospf 0 1 database opaque-area [Link]/24 self-originate

2
3
4 Enrutador OSPF con ID ([Link]) (ID de proceso 1)
5
6 Tipo-10 Área de enlace opaco Estados de enlace (Área 1)
7

8 Edad LS: 872

9 Opciones: (Sin capacidad TOS, DC)
10 Tipo LS: Enlace de área opaca
11 ID de estado de enlace: [Link]
12 Tipo opaco: 7
13 Opaco ID: 2
14 Router de publicidad: [Link]
15 Número de secuencia LS: 80000001
16 Suma de comprobación: 0xffd5
17 Longitud: 48
18
19 Rango de prefijo extendido TLV: Longitud: 24
20 AF : 0
21 Prefijo : [Link]/24
22 : 60
23 Banderas : 0x0 ¡¡!! IA:0
24
25 SID sub-TLV: Longitud: 8
26 Banderas : 0x60 ¡¡!! (NA); NP:1; M:1; E:0; V:0; L:0
27 MTID : 0
28 Algo : 0
29 Índice SID : 100
30
Ejemplo 8-21: Rango de prefijos extendido en el Área 1, [Link]/32

1 RP/0/0/CPU0:xrvr-1#show ospf 0 1 database opaque-area [Link]/32 self-originate

2
3
4 Enrutador OSPF con ID ([Link]) (ID de proceso 1)
5
6 Tipo-10 Área de enlace opaco Estados de enlace (Área 1)
7

8 Edad LS: 881

9 Opciones: (Sin capacidad TOS, DC)
10 Tipo LS: Enlace de área opaca
11 ID de estado de enlace: [Link]
12 Tipo opaco: 7
13 Opaco ID: 3
14 Router de publicidad: [Link]
15 Número de secuencia LS: 80000001
16 Suma de comprobación: 0xbf7c
17 Longitud: 48
18
19 Rango de prefijo extendido TLV: Longitud: 24
20 AF : 0
21 Prefijo : [Link]/32
22 : 40
23 Banderas : 0x0 ¡¡!! IA:0
24
25 SID sub-TLV: Longitud: 8
26 Banderas : 0x60 ¡¡!! (NA); NP:1; M:1; E:0; V:0; L:0
27 MTID : 0
28 Algo : 0
29 Índice SID : 10
30

El Ejemplo 8-22 muestra la Política de Mapeo Activa en Nodo1. Como en este sólo hay un Servidor de Mapeo,
la Política de Mapeo Activa coincide con la Política de Mapeo Local.
Ejemplo 8-22: Política de Asignación Activa en Nodo1

1 RP/0/0/CPU0:xrvr-1#show ospf segment-routing prefix-sid-map active-policy

2
3 Política activa SRMS para ID de proceso 1
4
5 Prefijo SID Índice Rango Indicadores
6 [Link]/24 100 60
7 [Link]/32 10 40
8
9 Número de entradas cartográficas: 2
10
11 RP/0/0/CPU0:xrvr-1#show ospf segment-routing prefix-sid-map active-policy detail
12
13 Política activa SRMS para ID de proceso 1
14
15 Prefijo
16 [Link]/24
17 Fuente: Local
18 ID de router: [Link]
19 Identificación de No fijado
la zona:
20 Índice SID: 100
21 Alcance: 60
22 Último prefijo: [Link]/24
23 Último índice 159
SID:
24 Banderas:
25 [Link]/32
26 Fuente: Local
27 ID de router: [Link]
28 Identificación de No fijado
la zona:
29 Índice SID: 10
30 Alcance: 40
31 Último prefijo: [Link]/32
32 Último índice 49
SID:
33 Banderas:
34

35 Número de entradas cartográficas: 2

ABR Nodo3 propaga ambos rangos de mapeo prefijo-a-SID desde el Área 1 al Área 0. Sólo uno se muestra en
el Ejemplo 8-23, el otro rango de mapeo es equivalente. El IA-flag del TLV Extended Prefix Range está
activado ya que este TLV ha sido propagado entre áreas; es un mapeo inter-área en el Área 0. Los indicadores
NP (PHP-off) y M (Mapping Server) del sub-TLV Prefix-SID están ambos activados.
Ejemplo 8-23: Alcance de prefijo extendido Área 0, [Link]/32

1 RP/0/0/CPU0:xrvr-3#show ospf 1 0 database opaque-area [Link]/32 self-originate

2
3
4 Enrutador OSPF con ID ([Link]) (ID de proceso 1)
5
6 Tipo-10 Área de enlace opaco Estados de enlace (Área 0)
7

8 Edad LS: 1068

9 Opciones: (Sin capacidad TOS, DC)
10 Tipo LS: Enlace de área opaca
11 ID de estado de enlace: [Link]
12 Tipo opaco: 7
13 Opaco ID: 6
14 Router de publicidad: [Link]
15 Número de secuencia LS: 80000001
16 Suma de comprobación: 0x2394
17 Longitud: 48
18
19 Rango de prefijo extendido TLV: Longitud: 24
20 AF : 0
21 Prefijo : [Link]/32
22 : 40
23 Banderas : 0x80 ¡¡!! IA:1
24
25 SID sub-TLV: Longitud: 8
26 Banderas : 0x60 ¡¡!! (NA); NP:1; M:1; E:0; V:0; L:0
27 MTID : 0
28 Algo : 0
29 Índice SID : 10
30

El Ejemplo 8-24 muestra la Política de Mapeo Activa en el Nodo4. Note que el router-id de cada rango de
mapeo es ahora el router-id del ABR Nodo3 ([Link]). Es el router-id del nodo anunciante.
Ejemplo 8-24: Política de Asignación Activa en Nodo4

1 RP/0/0/CPU0:xrvr-4#show ospf segment-routing prefix-sid-map active-policy

2
3 Política activa SRMS para ID de proceso 1
4
5 Prefijo SID Índice Rango Indicadores
6 [Link]/24 100 60
7 [Link]/32 10 40
8
9 Número de entradas cartográficas: 2
10
11 RP/0/0/CPU0:xrvr-4#show ospf segment-routing prefix-sid-map active-policy deta$
12
13 Política activa SRMS para ID de proceso 1
14
15 Prefijo
16 [Link]/24
17 Fuente: Remoto
18 ID de router: [Link]
19 Identificación de 0
la zona:
20 Índice SID: 100
21 Alcance: 60
22 Último prefijo: [Link]/24
23 Último índice 159
SID:
24 Banderas:
25 [Link]/32
26 Fuente: Remoto
27 ID de router: [Link]
28 Identificación de 0
la zona:
29 Índice SID: 10
30 Alcance: 40
31 Último prefijo: [Link]/32
32 Último índice 49
SID:
33 Banderas:
34

35 Número de entradas cartográficas: 2

A continuación, el Nodo 5 propaga las asignaciones de prefijo a SID al Área 2. Véase el Ejemplo 8-25. El
indicador IA del TLV de rango de prefijo extendido está activado, ya que este TLV se ha propagado entre
áreas; se trata de una asignación entre áreas. Los indicadores NP (PHP-off) y M (Mapping Server) del sub-TLV
Prefijo-SID están ambos activados.
Ejemplo 8-25: Alcance de prefijo extendido Área 2, [Link]/32

1 RP/0/0/CPU0:xrvr-5#show ospf 1 2 database opaque-area [Link]/32 self-originate

2
3
4 Enrutador OSPF con ID ([Link]) (ID de proceso 1)
5
6 Tipo-10 Área de enlace opaco Estados de enlace (Área 2)
7

8 Edad LS: 1254

9 Opciones: (Sin capacidad TOS, DC)
10 Tipo LS: Enlace de área opaca
11 ID de estado de enlace: [Link]
12 Tipo opaco: 7
13 Opaco ID: 9
14 Router de publicidad: [Link]
15 Número de secuencia LS: 80000001
16 Suma de comprobación: 0xf8b9
17 Longitud: 48
18
19 Rango de prefijo extendido TLV: Longitud: 24
20 AF : 0
21 Prefijo : [Link]/32
22 : 40
23 Banderas : 0x80 ¡¡!! IA:1
24
25 SID sub-TLV: Longitud: 8
26 Banderas : 0x60 ¡¡!! (NA); NP:1; M:1; E:0; V:0; L:0
27 MTID : 0
28 Algo : 0
29 Índice SID : 10
30

El Ejemplo 8-26 muestra la Política de Mapeo Activa en el Nodo7. Aquí el router-id de cada rango de mapeo
es el router-id del ABR Nodo5 ([Link]).
Ejemplo 8-26: Política de Asignación Activa en Nodo7

1 RP/0/0/CPU0:xrvr-7#show ospf segment-routing prefix-sid-map active-policy

2
3 Política activa SRMS para ID de proceso 1
4
5 Prefijo SID Índice Rango Indicadores
6 [Link]/24 100 60
7 [Link]/32 10 40
8
9 Número de entradas cartográficas: 2
10
11 RP/0/0/CPU0:xrvr-7#show ospf segment-routing prefix-sid-map active-policy deta$
12
13 Política activa SRMS para ID de proceso 1
14
15 Prefijo
16 [Link]/24
17 Fuente: Remoto
18 ID de router: [Link]
19 Identificación de 2
la zona:
20 Índice SID: 100
21 Alcance: 60
22 Último prefijo: [Link]/24
23 Último índice 159
SID:
24 Banderas:
25 [Link]/32
26 Fuente: Remoto
27 ID de router: [Link]
28 Identificación de 2
la zona:
29 Índice SID: 10
30 Alcance: 40
31 Último prefijo: [Link]/32
32 Último índice 49
SID:
33 Banderas:
34

35 Número de entradas cartográficas: 2

8.11 Resumen
La política de asignación local contiene las asignaciones de prefijo a SID configuradas localmente en un
servidor de asignación.

La política de asignación local contiene un conjunto de asignaciones de prefijo a SID válidas y no solapadas.

Un cliente de asignación aplica reglas de selección a todas las asignaciones de prefijo a SID recibidas
para obtener un conjunto válido, no superpuesto y no conflictivo de asignaciones de prefijo a SID.

Cada nodo SR es por defecto un Cliente de Mapeo.

OSPF propaga anuncios del Servidor de Mapeo entre áreas.

8.12 Referencias
[ draft-ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski,
S., Decraene, B. y J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf- isis-segment-routing-
extensions (trabajo en curso), junio de 2016, [Link]
routing-extensions.

[draft-ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R.,
Henderickx, W. y J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf- ospf-segment-routing-
extensions (trabajo en curso), julio de 2016, [Link]
routing-extensions.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L. y P. Pillay-Esnault, "Multi-Topology (MT) Routing
in OSPF", RFC 4915, DOI 10.17487/RFC4915, junio de 2007,
[Link]

[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., y U. Chunduri, "IS-IS Prefix Attributes for
Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, marzo de 2016,
[Link]

1 Cisco Network Services Orchestrator (NSO), habilitado por Tail-f, [Link]

2 Si, debido a una reconfiguración, un rango de mapeo se mueve de un LSP a otro, entonces es posible que un
router receptor reciba dos LSPs que contengan rangos de mapeo conflictivos desde el mismo router
anunciante. Por supuesto, esto ocurrirá durante un breve periodo de hasta que el router anunciante anuncie una
nueva versión del segundo LSP sin la entrada conflictiva.

3 [draft-ietf-isis-segment-routing-extensions]
9 LFA INDEPENDIENTE DE LA TOPOLOGÍA (TI-
LFA)
9.1 Introducción
El desvío rápido es un mecanismo para reducir el tiempo de restablecimiento del tráfico cuando se produce un
fallo en la red. En la mayoría de los casos, el fallo considerado es un enlace, pero también podría ser un nodo o
un grupo de enlaces de riesgo compartido (SRLG - véase el recuadro recordatorio más adelante en esta
sección).

El nodo que proporciona protección se denomina punto de reparación local (PLR). El PLR está directamente
conectado al enlace. Precalcula la ruta de reparación de desvío rápido (FRR) antes del fallo e instala la
solución en el plano de datos. Al detectar el fallo de su enlace, el PLR habilita la solución FRR precalculada y
activa la convergencia IGP.

Se espera que una solución FRR restablezca el tráfico en un plazo de 50 ms tras producirse el fallo, con
tiempo de detección del enlace que suele estimarse en 10 mseg. Este es el caso de los enlaces SONET/SDH o
de los enlaces supervisados por detección bidireccional de fallos (BFD) (intervalo BFD 3 mseg, 3 no-show
consecutivos indican el fallo). Si el tiempo de detección del enlace se ajusta para que sea más largo (por
ejemplo, para amortiguar las caídas del enlace), el tiempo para restablecer el tráfico aumentará en
consecuencia.

La activación de la solución FRR precalculada depender del prefijo o ser independiente del prefijo. Una
verdadera solución FRR requiere una solución independiente del prefijo - decir, el número de prefijos, cuyas
rutas primarias se ven afectadas por el fallo y que necesitan que se activen sus rutas de respaldo, no tiene
ningún impacto en el tiempo de activación de la solución FRR precalculada. Una solución independiente del
prefijo suele requerir un plano de datos FIB jerárquico. La activación de la solución FRR precalculada,
suponiendo una implementación independiente del prefijo, suele tardar ~20 mseg.

RECORDATORIO: FIB aplanada y jerárquica

Tradicionalmente, la estructura de la Forwarding Information Base (FIB) era plana. Al programar las entradas de la base de información de
enrutamiento (RIB) en la FIB, cada entrada se resolvía completamente y se añadía a la entrada un puntero a la adyacencia saliente. La adyacencia
contiene la interfaz saliente y la información de reescritura de capa 2. También se aplanaron las entradas FIB de las entradas BGP. La FIB se vería
como la que se muestra en la Figura 9-1. B1, B2, y Bn son prefijos BGP. I1, I2 y I3 son prefijos IGP. En la ilustración cada entrada de prefijo
enlaza directamente con la adyacencia Adj1.
Prefijos BG@

Prefijos IG
Figura 9-1: Estructura aplanada de la FIB

Para activar IPFRR con dicha estructura, sería necesario recorrer cada entrada para activar la ruta de reparación. Esta solución dependería del
prefijo; la protección para cada prefijo se activaría secuencialmente.

Una FIB jerárquica no aplana la FIB, sino que utiliza punteros para las dependencias entre elementos de la FIB. Se introducen varios niveles de
indirección en la estructura. Véase la ilustración de este tipo de FIB en la Figura 9-2. Cada entrada de prefijo BGP tiene un puntero a un
elemento llamado lista de rutas BGP. Esta lista de rutas BGP contiene uno o más nexthops para los prefijos BGP. Si se utiliza BGP Multipath,
lista de rutas BGP contiene más de un nexthop y el tráfico se reparte entre todos nexthops de lista de rutas BGP. Las listas de rutas BGP se
comparten entre prefijos; los prefijos BGP con el(los) mismo(s) nextopo(s) apuntan a la misma de rutas BGP. Una entrada de la lista de rutas
BGP apunta a una entrada de prefijo IGP. Esta entrada de prefijo IGP apunta a una lista de rutas IGP. Esta lista de rutas IGP contiene uno o más
nexthops. Si se puede llegar al destino a través de varias rutas de igual coste, la lista de rutas IGP contiene una entrada para cada ruta. Cada
entrada de la lista de rutas IGP apunta a la adyacencia correspondiente. La entrada de la lista de rutas que se utiliza para reenviar un paquete se
selecciona al reenviar el paquete.

Aparte del ECMP, una lista de rutas IGP contiene información de la ruta de backup. En caso de fallo, se activa la ruta de backup. Esto se ilustra
en la Figura 9-2. Cuando Adj1 falla, se activan las entradas de backup en las listas IGP Path. En la ilustración, los prefijos I1 e I2 usarían el
camino de respaldo vía Adj2, y el prefijo I3 iría vía Adj3.

Figura 9-2: Estructura jerárquica de la FIB

La convergencia del IGP depende principalmente del número de prefijos en el IGP. Una implementación
moderna de IGP debería converger 1000 prefijos dentro de unos pocos cientos de mseg después de la ocurrencia
de la falla. El gráfico de la Figura 9-3 ilustra este comportamiento. Después de un , cada nodo comienza su
proceso de convergencia. Después de calcular el nuevo Árbol del Camino Más Corto (SPT), un nodo actualiza
el
entradas de reenvío (prefijos) secuencialmente [1]. El eje Y muestra el tiempo de pérdida de conectividad de un
prefijo. Este es el periodo de tiempo entre la ocurrencia del fallo y el momento en que la conectividad para el
prefijo fue restaurada. Para el gráfico etiquetado "IGP", es el momento en que se actualizó la entrada del
prefijo en la tabla de reenvío. El eje X indica la posición de cada prefijo en el orden en que se actualizan. Por
ejemplo, el primer prefijo se actualiza 100 ms después del fallo. El último prefijo (el prefijo 5000 en este
ejemplo) se actualiza 1100 ms después del fallo. El prefijo número 1000 se actualiza 300 ms después del fallo.
El objetivo de la solución FRR es reparar la pérdida de tráfico hasta que el IGP haya convergido y las rutas
"post-convergencia" estén instaladas en el plano de datos. IPFRR restaura la conectividad para todos los
prefijos al mismo , el tiempo en que IPFRR fue activado. En la Figura 9-3 esto ocurre 20 ms después del fallo,
ver gráfico etiquetado "IPFRR". Nótese que tanto IGP como IPFRR ocurren en paralelo: mientras IPFRR está
activo, IGP computa y actualiza las nuevas entradas de reenvío.

Figura 9-3: Tiempo de actualización del prefijo en función de la posición del prefijo

Existen dos tipos de soluciones FRR: basadas en instalaciones y basadas en prefijos.

Una solución FRR basada en la instalación calcula una única ruta de reserva desde el PLR, alrededor de la
instalación (por ejemplo, el enlace) y de vuelta al siguiente salto del PLR sobre la instalación protegida. En
caso de pérdida del enlace, todo tráfico afectado se redirige a través de esta única ruta de reserva y dirige al
otro lado del enlace, desde donde el tráfico se divide en un conjunto de flujos, cada uno de los cuales viaja a su
propio destino. Véase la ilustración de la Figura 9-4. La ruta de backup de la instalación (etiquetada "Facility
backup") dirige el tráfico al otro extremo del enlace protegido entre Nodo2 y Nodo3, desde donde el tráfico
fluye a los destinos. Los flujos de tráfico hacia los destinos Nodo6 y Nodo9 comparten la misma ruta de
backup de la instalación.

RSVP-TE FRR y SONET/SDH son ejemplos de solución FRR basada en instalaciones.

Figura 9-4: Ilustración de la copia de seguridad de la instalación

El principal mérito de estas soluciones es que históricamente fueron las primeras en aplicarse.

Tienen inconvenientes importantes cuando se aplican a redes IP: dirigen todo el tráfico por la misma ruta de
reserva (no utilizan ECMP) y hasta el otro lado del enlace protegido (no son óptimas).

IPFRR es una solución FRR basada en prefijos; el PLR calcula previamente una ruta de backup individual por
destino/prefijo.
Esto es significativamente mejor para las redes IP por las siguientes razones:

ECMP: cada ruta de backup puede ser diferente y, por lo tanto, al activarse la solución FRR, el tráfico
afectado se divide en flujos y cada flujo se dirige a lo largo de sus rutas de backup óptimas. El tráfico
afectado no se concentra en la misma ruta de reserva.

Optimalidad: en las redes IP, la ruta de reserva óptima suele evitar el otro lado del enlace averiado. Una
solución FRR basada en instalaciones es en gran medida subóptima cuando se aplica a redes IP: fuerza el
tráfico hasta el otro lado del enlace fallido sin ninguna razón. De hecho, una solución FRR basada en
instalaciones hace esto porque fue diseñada para un paradigma de circuito y, por lo tanto, el tráfico
protegido tuvo que ser redirigido al otro lado del enlace para volver al estado de circuito. En las redes IP,
los paquetes IP tienen toda la información de encaminamiento que necesitan: es decir, la dirección de
destino.

El tráfico MPLS/LDP también se beneficia de IPFRR al aprovechar las rutas de backup calculadas por IPFRR.

"Stefano Previdi y yo iniciamos la investigación del IPFRR en la cafetería de Cisco de Bruselas en 2001. Eran los primeros días de
MPLS. Yo me centraba en el aspecto FRR/TE/QoS y Stefano en VPN. Estaba muy claro que RSVP-TE FRR se resentía de su
naturaleza de circuito y no era óptimo para IP. Queríamos encontrar una solución basada en IP que fuera óptima para IP (desde el
punto de vista de ECMP, capacidad y enrutamiento). Llamamos al proyecto IPFRR para subrayar la centralidad de IP en la solución".

- Clarence Filsfils

El Nodo2 en la Figura 9-5 tiene protección habilitada para el enlace entre el Nodo2 y el Nodo3; este enlace es
el componente protegido. La ruta primaria desde el Nodo2 a los destinos Nodo6 y Nodo9 atraviesa el
componente protegido, como indican las flechas etiquetadas como "Pre-convergencia". El Nodo2 calcula una
ruta de reparación para cada uno de estos destinos, como indican las flechas "IPFRR". En caso de fallo del
componente protegido, el Nodo2 desvía el tráfico hacia estos destinos a través de sus rutas de reparación.
Mientras el tráfico llega a su destino a través de las rutas de reparación, el IGP converge e instala nuevas
entradas de reenvío. El tráfico ya no se reenvía a través de la ruta de reparación, sino a través de las nuevas
rutas, como indican las flechas etiquetadas como "Post-convergencia".
Figura 9-5: Ilustración de la protección local

La redirección rápida proporciona protección local para el tráfico que atraviesa el componente protegido. Es
local porque el nodo que está directamente aguas arriba del componente averiado activa el mecanismo. Es el
primer nodo en detectar el fallo del conectado localmente, eliminando así cualquier retraso en propagar la
condición de fallo a través de la red. Los demás nodos de la red no tienen por qué conocer la activación de la
protección y no hacen nada.
DESTACAR

Una solución FRR oculta la pérdida de conectividad que comienza cuando falla un enlace, nodo o SRLG y dura hasta que el IGP
instala las rutas post-convergencia de los destinos afectados (los destinos que inicialmente se enrutaron a través del enlace, nodo o
SRLG fallido).

Una solución FRR es calculada por un nodo directamente conectado al enlace, nodo o SRLG cuyo fallo debe protegerse. Se denomina
punto de reparación local (PLR).

El PLR calcula previamente la ruta de reparación FRR antes de que se produzca el fallo.

Buscamos una ruta de reparación FRR por destino: la ruta de reserva (reparación) se calcula y optimiza por destino.

Buscamos una solución FRR independiente del prefijo: el tiempo para activar la ruta de reparación FRR precalculada no depende del número
de entradas de destino que necesitan que se active su ruta de reparación.

Una solución FRR sólo depende de la inteligencia del PLR. Los demás nodos de la red no tienen que hacer nada.

Buscamos una solución FRR de 50 mseg. Suponemos que el tiempo para detectar el fallo local es inferior a 10 mseg. La naturaleza
independiente del destino de la implementación de FRR y el cálculo previo de las rutas de copia de seguridad/reparación garantizan
que la activación sea < 40 mseg.

Buscamos una solución FRR optimizada para IP, no para circuitos.

La familia de soluciones IPFRR se denomina así para subrayar su naturaleza "IP" y su optimización para redes IP. El

tráfico MPLS/LDP se beneficia de un IPFRR.

La investigación del IPFRR produjo en primer lugar el bucle alterno sin bucle (LFA). A continuación, la
cobertura del LFA se amplió con el LFA remoto (RLFA). Por último, gracias a SR, la investigación se
completó con la entrega de LFA independientes de la topología (TI-LFA), una solución IPFRR completa y
óptima.

Un mecanismo de ruta rápida debe precalcular la ruta de reparación a proteger para un fallo concreto. Este
fallo puede ser un fallo de enlace, un fallo de nodo o un fallo de grupo de enlaces de riesgo compartido
(SRLG). El tipo de fallo proteger se configura normalmente como parte de la configuración del fast-
reroute.

La Figura 9-6 ilustra los tipos de protección de enlace, nodo y SRLG. El Nodo5 en la topología aplica los
diferentes modelos de protección para proteger el tráfico hacia el destino Nodo3.
Figura 9-6: Protección de enlaces, nodos y SRLG

La protección de enlace significa que la ruta de reparación evita el enlace saliente a lo largo de la ruta primaria
hacia el destino. Véase la Figura 9-6 (a).

La protección de nodo significa que la ruta de reparación evita el nodo de primer salto a lo largo de la ruta
primaria hacia el destino. La protección de nodos implica la protección de enlaces. Véase la Figura 9-6 (b).

La protección SRLG significa que la ruta de reparación evita todos los enlaces que comparten un SRLG con la
ruta primaria al destino. La implementación de Cisco IOS XR protege contra fallos de las interfaces locales que
pertenecen al mismo SRLG que la ruta primaria, la denominada protección SRLG local. La protección SRLG
implica protección de enlace. Véase la Figura 9-6 (c).
RECORDATORIO: Grupo de Enlace de Riesgo Compartido (SRLG)

Un grupo de enlaces de riesgo compartido (SRLG) es un grupo de enlaces de red que comparten un recurso (físico) común (como un cable,
conducto, nodo o subestructura). Un fallo de ese recurso provocará el fallo de todos los enlaces grupo. Por ejemplo, dos fibras en el mismo
conducto o varias longitudes de onda que comparten la misma fibra estarían en el mismo SRLG. Un enlace puede pertenecer a varios SRLG.

Un número identifica cada SRLG, ese número se adjunta a cada enlace que es miembro de ese SRLG. IETF RFC 4202 establece: "Un SRLG
es identificado por un número de 32 bits que es único dentro de un dominio IGP. La Información SRLG es una lista desordenada de SRLG's a
los que pertenece el enlace".

Los identificadores SRLG se anuncian en IGP. El número SRLG se anuncia en un TLV SRLG en ISIS (IETF RFC 4205). Se anuncia en un
SRLG sub-TLV del Link TLV en el OSPF TE Opaque LSA (IETF RFC 4203).

La protección de nodos y SRLG puede combinarse e implicar también la protección de enlaces. Véase la Figura

9-6 (d). La implementación de Cisco IOS XR es compatible:

Protección de enlace, nodo o SRLG local con ALF.

Protección de enlace con ALF remoto.

Protección de enlace, nodo o SRLG local con TI-LFA.

9.2 Alternativa sin bucle
La forma más sencilla de encontrar una ruta de reparación para un destino D es que el PLR encuentre un vecino
directamente conectado cuya ruta más corta a D no atraviese el componente protegido. Este vecino se denomina
alternativo sin bucle (ALB).

En caso de fallo del componente protegido, el PLR redirige el tráfico destinado a D a través del ALF
precalculado. El vecino LFA recibe este tráfico y naturalmente (es decir, sin saber del fallo) lo reenvía al
destino a lo largo de su camino más corto. Esto es importante porque restaurar el tráfico en un tiempo tan corto
(50 ms) que no podemos esperar que el vecino LFA haya completado su convergencia IGP. Hay que asegurarse
que el vecino LFA que elijamos reenviará el tráfico hacia el destino usando tanto su antiguo como su nuevo
estado de reenvío después del evento de fallo.

El vecino del ALF seleccionado por el PLR se denomina "punto de liberación" para el destino D: un paquete
liberado en el ALF llega naturalmente al destino D sin cruzar el componente protegido ni volver al PLR.

Un PLR puede no tener ningún ALF para un destino en particular, si la topología no lo permite. En este caso,
no se instalará ninguna protección para este destino y el tráfico se interrumpirá hasta la convergencia IGP.

La alternativa sin bucle "clásica" se especifica en el RFC 5286 del IETF. El prefijo "clásico" se añade para
distinguirlo de otros tipos de ALF en este libro. Recomendamos leer IETF RFC 6571 ("LFA Applicability in
Service Provider (SP) Networks") para conocer casos de uso y directrices de diseño para LFA.

De la inspección de la topología en la Figura 9-5, se puede ver que el Nodo2 usa el Nodo4 como un ALF para el
Nodo destino6. El camino más corto de Nodo4 a Nodo6 pasa por Nodo5 y no atraviesa el componente
protegido, el enlace entre Nodo2 y Nodo3. De forma similar, Nodo2 usa Nodo7 como ALF destino Nodo9.
Nótese que Nodo2 calcula rutas de backup por destino: Nodo4 para destino Nodo6 y Nodo7 para destino
Nodo9.

Obsérvese la optimización de tener una ruta de reserva por destino. Una solución basada en circuitos como
RSVP- TE FRR habría utilizado una única ruta de backup (por ejemplo, 2-7-8-3) y habría dirigido todo el
tráfico reparado al otro extremo del enlace fallido (Nodo3). Esto es en gran medida subóptimo desde un punto
de vista de capacidad y ECMP, pero también desde un punto de vista de enrutamiento y latencia: el tráfico
reparado al Nodo6
seguramente no debe pasar por Nodo7 y Nodo8. El tráfico reparado hacia el Nodo 9 no debería volver a través
del Nodo 3.

La formalización de la idea del ALF es sencilla (Ecuación 9-1)

Ecuación 9-1: LFA Condición básica sin bucle

Dist(N, D)< Dist(N, PLR)+ Dist(PLR, D)

Dist(A, B) es la distancia más corta de A a B N es

un vecino del PLR

D es el destino considerado

La ecuación simplemente formaliza que, para un , su vecino N es un ALF para el destino D si y sólo si el
camino más corto de N a D no vuelve a través del PLR. En otras palabras: si el PLR envía un paquete con
destino D a N N no lo devolverá al PLR si se cumple la condición. Se trata del criterio sin bucle.

Ahora evalúe la condición de la Ecuación 9-1 en la topología de red de la Figura 9-5 con PLR=Nodo2 y
D=Nodo6. Al evaluar primero N=Nodo7, la condición se convierte en:
Dist(N, D)< Dist(N, PLR)+ Dist(PLR, D)
→ Dist(Nodo7, Nodo6)< Dist(Nodo7, Nodo2)+ Dist(Nodo2, Nodo6)
→ 30< 10+ 20
→ Falso→ Nodo7 no es un ALF para el destino Nodo9.

El camino más corto del Nodo7 al Nodo6 atraviesa efectivamente el enlace del Nodo2 al Nodo3.

Al evaluar N=Nodo4, la condición pasa a ser:

Dist(N, D)< Dist(N, PLR)+ Dist(PLR, D)
→ Dist(Nodo4, Nodo6)< Dist(Nodo4, Nodo2)+ Dist(Nodo2, Nodo6)
→ 20< 10+ 20
→ Verdadero→ Nodo4 es un ALF para el Nodo de destino6.
El AGL clásico es sencillo y muy a menudo posible. IETF RFC 6571 analiza muchos conjuntos de datos reales
y muestra que el ALF es posible para el 89% de los destinos en una red troncal típica. IETF RFC 6571 también
proporciona directrices de diseño para garantizar una cobertura del 100%.

Por cobertura se entiende el porcentaje de pares (PLR P, destino D) en los que el PLR P tiene un ALF para el
destino D.

El ALF clásico es un mecanismo de protección sencillo, pero tiene limitaciones y desventajas:

No proporciona protección en todos los casos, su cobertura depende de la topología

No siempre proporciona la ruta de copia de seguridad más óptima.

No siempre existe un ALF adecuado (clásico); depende de la topología de la red, las métricas y el componente
que se quiera proteger. Aunque el ALF clásico proporciona protección para la mayoría de los prefijos de destino
en la mayoría de las redes, no puede proporcionar protección para todos los destinos en todas las topologías. Es
"dependiente de la topología". También se dice que el LFA clásico no proporciona una cobertura de protección
del 100%.

En el ejemplo de topología de red de la Figura 9-7, el Nodo2 quiere proteger el tráfico que va a los destinos
Nodo8 y Nodo5 contra el fallo del enlace con el Nodo3. De la inspección de la topología de la red se puede ver
que el Nodo6 es un ALF para el destino Nodo8 en el Nodo2. Usando la Ecuación 9-1, se puede verificar
matemáticamente que el Nodo6 es un ALF para el destino Nodo8 ya que cumple la condición básica de libre de
bucles:
Dist(N, D)< Dist(N, PLR)+ Dist(PLR, D), con D=Nodo8, PLR=Nodo2, y N=Nodo6
→ Dist(Nodo6, Nodo8) (=10)< Dist(Nodo6, Nodo2) (=10)+ Dist(Nodo2, Nodo8) (=20)
→ 10< 10+ 20
→ Verdadero→ Nodo6 es un ALF para el Nodo de destino8.
Figura 9-7: El ALF clásico depende de la topología

Sin embargo, el Nodo2 no tiene un ALF clásico para el destino Nodo5. El Nodo2 sólo tiene un vecino
alternativo Nodo6. Sin embargo, el camino más corto de Nodo6 a Nodo5 es un ECMP con uno de los caminos
cruzando el enlace entre Nodo2 y Nodo3. El otro camino de igual coste desde el Nodo6 al Nodo5 pasa por el
Nodo7. Matemáticamente, el Nodo6 no cumple la condición básica sin bucles del ALF: Dist(Nodo6, Nodo5)
(=30) no es menor que Dist(Nodo6, Nodo2) (=10) + Dist(Nodo2, Nodo5)
(=20). Por lo tanto Nodo6 no es un ALF para el destino Nodo5. Nótese que existe una ruta de backup desde
Nodo2 a Nodo5: Nodo2→Nodo6→Nodo7→Nodo3→Nodo5. Esta es también la ruta que seguirá el tráfico
una vez completada la convergencia, la ruta post-convergencia. Dado que no está libre de bucles (el Nodo6 no
es un ALF como se ha concluido anteriormente) esta ruta de backup no se puede utilizar con la funcionalidad
clásica de ALF. La mitad tráfico entraría en bucle entre el Nodo6 y el Nodo2.

La otra desventaja del ALF clásico: no siempre proporciona la ruta de reparación más óptima. Si se encuentra
un ALF clásico, proporciona protección, pero posiblemente no a través de la ruta de reparación más deseada.

En el ejemplo de topología de red de la Figura 9-8, el Nodo2 quiere proteger el tráfico que va a los destinos
Nodo8 y Nodo5 contra el fallo del enlace con el Nodo3. De la inspección de la topología de red se puede
deducir que el Nodo4 es un ALF para el destino Nodo5 ya que el camino más corto desde el Nodo4 al Nodo5
no atraviesa el enlace protegido. El Nodo 4 también cumple matemáticamente la condición de no tener bucles:
Dist(N,D)< Dist(N, PLR)+ Dist(PLR, D), con PLR=Nodo2, D=Nodo5, y N=Nodo4
→ D(Nodo4, Nodo5) (=110)< D(Nodo4, Nodo2) (=100)+ D(Nodo2, Nodo8) (=20)
→ 110< 100+ 20
→ Verdadero→ Nodo4 es un ALF para el Nodo de destino5.

El otro vecino de Nodo2, Nodo6, no es un ALF para el destino Nodo5. Esto se concluyó en el ejemplo anterior
para la topología de red de la Figura 9-7, y también es cierto para la topología de la Figura
9-8.
Figura 9-8: El AGL clásico puede proporcionar una vía de reparación subóptima

Nótese que el único ALF disponible para el Nodo de destino5, Nodo4, es un nodo Provider Edge. El operador
ha configurado métricas altas en los enlaces que conectan el Nodo4 con el núcleo. El operador claramente no
quiere que el Nodo4 sea utilizado para tráfico de tránsito, lo cual es una regla de planificación común. Los
enlaces de métrica alta suelen tener baja capacidad, lo que puede llevar a congestión y pérdida de paquetes si
se usan como ruta de reparación. Aún así Classic LFA selecciona Nodo4 como LFA ya que en este caso es el
único LFA disponible.
El RFC 7916 del IETF describe otros casos en los que el mecanismo clásico del ALF no elige la ruta de
reparación deseada. A veces el resultado deseado puede conseguirse con intervención operativa. Puede ser
posible ajustar manualmente los llamados desempates para conseguir la ruta de reparación deseada. Los
desempates son los criterios que se usan para seleccionar un de entre varios posibles, ver IETF RFC 5286. Sin
embargo, esta configuración caso por caso no siempre es posible y, en cualquier caso, aumenta la complejidad
operativa de solución LFA clásica.

Al analizar las rutas de reparación más deseadas en una red, resulta que la mejor ruta de reparación es
siempre la ruta posterior a la convergencia, la ruta que seguirá el tráfico después de que el IGP haya
convergido. Esta es exactamente la ruta de reparación que el AGL independiente de la topología proporciona
automáticamente.

Volviendo al ejemplo de la Figura 9-8. Observe que existe una ruta de copia de seguridad óptima desde el
Nodo2 al Nodo5: Nodo2→Nodo6→Nodo7→Nodo3→Nodo5. Esta ruta no cruza ningún nodo o enlace no
deseado. También es la ruta que seguirá el tráfico una vez completada la convergencia, la ruta post-
convergencia.

DESTACAR

El ALF clásico es sencillo y suele estar disponible.

El RFC 6571 del IETF analiza muchos conjuntos de datos reales y demuestra que el ALF es posible para el 89% de los destinos de una
red troncal típica.

El RFC 6571 del IETF proporciona directrices de diseño para garantizar una cobertura del 100%.

TI-LFA mejora el LFA clásico en dos aspectos: garantiza una cobertura del 100% en cualquier topología y asegura la optimalidad
de la ruta de respaldo.
9.3 LFA remoto
La sección anterior destacó que no siempre se puede un ALF. No siempre hay un vecino conectado
directamente que pueda dirigir los paquetes a su destino sin atravesar el componente protegido.

IETF RFC 7490 especifica una extensión de LFA, llamada Remote LFA (RLFA). RLFA amplía la cobertura de
protección de LFA clásico utilizando "LFAs virtuales". Estos LFAs virtuales son nodos remotos que pueden
funcionar como un punto de liberación LFA.

En caso de avería de un componente, el nodo de protección (punto de reparación local o PLR) puede dirigir el
tráfico hacia dicho ALF remoto, donde se libera el tráfico. A partir de ahí, el tráfico se dirige a su destino
siguiendo el camino más corto habitual, sin volver atrás ni atravesar el componente protegido. La RLFA se
utiliza normalmente si no se dispone de una LFA conectada directamente.

En una solución RLFA, el PLR dirige el tráfico al nodo RLFA a través de un . En las redes MPLS, el túnel suele
ser un LDP LSP.

El punto de liberación RLFA cumple la condición sin bucle LFA de la Ecuación 9-1.

El PLR calcula la lista de posibles nodos RLFA para un destino D basándose en las dos condiciones siguientes,
denominadas respectivamente P y Q:

P: el camino más corto desde el PLR al candidato RLFA no debe atravesar el componente protegido C (por
ejemplo, un enlace, un nodo o un SRLG local). Esto se aplica a todos los caminos ECMP a lo largo del
camino más corto.

P: el camino más corto desde el candidato RLFA hasta el destino D no debe atravesar el componente
protegido C.

El conjunto de nodos que satisfacen el primer criterio se denomina espacio P(PLR, C) de un nodo PLR con
respecto a un componente C. El espacio (PLR, C) es el conjunto de nodos cuyo camino más corto desde el PLR
hasta ellos no atraviesa el componente C. Los nodos del espacio P(PLR, C) son accesibles desde el PLR
independientemente del estado del componente C protegido. Se puede llegar a los nodos del espacio (S, C)
desde el PLR independientemente del estado del componente protegido C. Un PLR puede calcular su espacio P
para un componente local C que proteger, calculando su árbol de rutas más cortas (normal) y podando todos los
nodos.
que se alcanzan a través del componente C. En el RFC 7490 del IETF se describe un posible algoritmo para
calcular el espacio P.

El PLR tiene el control total del primer salto de la ruta de reparación. Puede utilizar cualquiera de sus nodos
adyacentes primer salto de la ruta de reparación, independientemente del camino más corto. Por consiguiente,
si un vecino del nodo protector puede llegar a un destino sin atravesar el componente protegido, entonces el
nodo protector también puede llegar a ese destino sin atravesar el componente protegido. Por lo tanto, puede
llegar a todos los nodos de todos los espacios P de sus vecinos. La unión de los espacios P de los vecinos del
PLR se denomina espacio P ampliado. Usar el espacio P extendido puede ampliar la elección de posibles
nodos RLFA. Pext(PLR, C) es el espacio P ampliado de un PLR con respecto a un componente C.

El conjunto de nodos que satisfacen el segundo criterio se denomina espacio Q(D, C) de un destino D con
respecto al componente C. El nodo N está en el espacio Q(D, C) si el camino más corto de N a D evita C. Los
nodos en el espacio Q pueden llegar al destino, independientemente del estado del componente protegido.
Nótese que un ALF clásico conectado directamente que protege el destino D contra el fallo del componente C
es un nodo del espacio Q(D, C). Un ALF puede alcanzar el destino D sin atravesar el componente C, que es
exactamente la propiedad de los nodos en el espacio Q.

Para la protección de enlaces, en la práctica se utiliza el espacio Q del nodo situado en el extremo remoto del
enlace protegido. Este espacio Q se utiliza como sustituto del espacio Q de cada destino al que se llega a través
de ese salto siguiente. Esta aproximación reduce en gran medida la complejidad del cálculo de posibles RLFA,
a expensas de rutas de reparación potencialmente subóptimas. Para obtener el SPT inverso, calcule el SPT
normal, pero utilice la métrica de enlace en la dirección desde el siguiente salto hacia la raíz del árbol en lugar de
la métrica de enlace en la dirección de alejamiento de la raíz. Para obtener el SPT inverso, calcule el SPT
normal, pero utilice la métrica de enlace en la dirección desde el siguiente salto hacia la raíz del árbol en lugar de
la métrica de enlace en la dirección de alejamiento de la raíz. En el RFC 7490 del IETF se describe un posible
algoritmo para calcular el espacio Q.

Un ALF Remoto es un nodo que satisface las condiciones P y Q. Por lo tanto, un ALF se conoce comúnmente
como "nodo PQ". Se encuentra en la intersección de los espacios P y Q.

Si falla el componente protegido C, el PLR puede dirigir los paquetes protegidos a la RLFA sin cruzar C
(propiedad de los nodos del espacio P), y desde los puntos de liberación de la RLFA, los paquetes pueden llegar
a su destino sin cruzar C (propiedad de los nodos del espacio Q).
Si hay varios candidatos RLFA, se recomienda seleccionar el más cercano del PLR, ya que así se maximizan las
posibilidades de equilibrar la carga para el tráfico que viaja desde el RLFA a su destino.

En la topología de red de la Figura 9-9 el Nodo2 quiere proteger el destino Nodo5 contra el fallo del enlace al
Nodo3. La ruta primaria al Nodo5 cruza el enlace protegido. Nodo2 no tiene un ALF para proteger el destino
Nodo5, ya que el único vecino alternativo, Nodo6, devuelve en bucle (parte de) el tráfico al Nodo2. Por lo tanto
el Nodo2 busca un posible RLFA.

Nodo2 calcula el espacio P(Nodo2, enlace2-3): {Nodo1, Nodo2, Nodo6}. Si se observa la topología, se puede
ver que el camino más corto desde Nodo2 a estos destinos no atraviesa el enlace protegido. El espacio P
extendido en este ejemplo es la unión del espacio P del Nodo2 y el espacio P del Nodo6: P(Nodo2, enlace2-
3)∪ P(Nodo6, enlace2-3) = {Nodo1, Nodo2, Nodo6, Nodo7, Nodo8}. De hecho, si el Nodo2 dirige paquetes
con destino al Nodo7 hacia el Nodo6, entonces el Nodo6 reenvía estos paquetes a través del camino más corto
hacia el Nodo7 sin atravesar el enlace protegido. Lo mismo ocurre con el Nodo8.

A continuación, el Nodo2 calcula el espacio Q(Nodo5, enlace2-3): {Nodo3, Nodo5, Nodo7, Nodo8}. De
hecho, cualquiera de estos nodos puede llegar al nodo 5 por el camino más corto sin atravesar el enlace
protegido.

La intersección del espacio P extendido y el espacio Q es: {Nodo7, Nodo8}. El Nodo7 es el más cercano al
Nodo2, por lo que el Nodo2 selecciona el Nodo7 como RLFA (Nodo PQ). Si falla el enlace con el Nodo3, el
Nodo2 dirige el tráfico al Nodo5 a través del Nodo7. El tráfico puede llegar al Nodo7 (propiedad del espacio P)
y desde el Nodo7 puede llegar al Nodo5 (propiedad del espacio Q).
Figura 9-9: Ejemplo de RLFA

Para dirigir el tráfico protegido a través de la RLFA a su destino, el nodo de protección necesita encapsular o
tunelizar los paquetes a la RLFA. Normalmente, la solución RLFA utiliza LDP como transporte de túnel. En
ese caso, el nodo de protección introduce la etiqueta saliente LDP vinculada a la FEC del nodo RLFA en los
paquetes de la ruta de reparación. Entonces la cosa se complica. Si el tráfico protegido se transporta usando
etiquetas LDP entonces el nodo protector tiene que saber qué etiqueta ha asignado la RLFA para el destino
protegido. La RLFA reenvía paquetes con esa al destino. Las etiquetas LDP se señalizan salto a salto, sólo los
vecinos LDP directos conocen las etiquetas LDP locales. Por lo tanto, para que el nodo de protección conozca
las etiquetas LDP locales de la RLFA, una sesión LDP (dirigida) debe ser
establecida entre estos dos nodos. Esta sesión LDP (específica) es necesaria entre cada par PLR/RLFA.

En la topología de red de la Figura 9-9, el Nodo2 tiene que establecer una sesión LDP destino con el Nodo7
RLFA. El Nodo2 aprende qué etiqueta LDP local ha asignado el Nodo7 para el destino Nodo5: LDP(Nodo7,
D:Nodo5). Nodo2 aprende la etiqueta LDP que debe utilizar para alcanzar Nodo7 desde su vecino aguas abajo
Nodo6: LDP(Nodo6, D:Nodo7). Cuando falla el enlace con el Nodo3, el Nodo2 dirige el tráfico LDP con
destino al Nodo5 a través del Nodo7. El Nodo2 intercambia la etiqueta superior de paquetes entrantes con
LDP(Nodo7, D:Nodo5). Esta etiqueta llevará los paquetes desde el Nodo7 a su destino Nodo5. Además, el
Nodo2 también empuja una etiqueta para dirigir los paquetes al Nodo7.

Los ALF remotos amplían la cobertura de protección en comparación con los ALF conectados directamente; sin
embargo, los ALF remotos no proporcionan una cobertura completa garantizada. La cobertura sigue
dependiendo de la topología. Y la RLFA seleccionada puede no proporcionar la ruta de copia de seguridad
óptima. Y tiene un coste: La RLFA requiere sesiones LDP específicas entre los PLRs y las RLFAs.

DESTACAR

El RLFA amplía el LFA clásico.

La cobertura combinada alcanza el 99% en conjuntos de datos reales analizados en IETF RFC 7490.

RLFA amplía la cobertura de la solución LFA clásica. IETF RFC 7490 analiza conjuntos de datos reales y
demuestra que LFA+RLFA tienen una cobertura combinada del 99% de las redes troncales analizadas.

El RLFA no mejora la falta de optimalidad en algunos casos y no ofrece la garantía de cobertura del 100%.
"El despliegue del ALF podría una victoria rápida en una red IP que no exija una protección de tráfico garantizada: es muy sencillo de
desplegar (normalmente un comando CLI), es muy fácil de entender y tiene un impacto de escalado insignificante a la vez que
proporciona una cobertura casi buena en las topologías habituales. Implementar RLFA remoto añade un nivel adicional, aunque
también es simple de desplegar (un comando CLI), puede ser más difícil de operar ya que el candidato RLFA necesitaría aceptar
sesiones TLDP de un PLR (característica adicional requerida en cualquier parte de la red). Con la RLFA es difícil predecir (sin una
herramienta de simulación) qué nodo sería el mejor candidato RLFA para un destino concreto desde un PLR concreto. Dependiendo
del diseño y del tamaño de la red, un candidato RLFA concreto puede ser utilizado por muchos PLRs, lo que lleva a una configuración
masiva de sesiones TLDP que puede añadir consideraciones de escalado.

LFA y RLFA pueden no utilizar una ruta de reparación óptima ya que las reglas de desempate base definidas en RFC 5286 y RFC
7490 son realmente simples. Utilizar una ruta no óptima puede causar algunos problemas en la red, como la congestión transitoria de
enlaces: ¡imagínese si un enlace central de gran ancho de banda está protegido a través de una ruta que utiliza enlaces de acceso de
bajo ancho de banda! El RFC 7916 describe estas consideraciones e introduce un marco político en el que un operador puede dirigir
mejor la elección de los candidatos LFA/RLFA.

Aunque la aplicación de esta política ayuda a resolver redirección rápida del tráfico, añade un nivel adicional de complejidad operativa.

Mi recomendación sería considerar el despliegue de LFA y RLFA cuando no se exija una protección garantizada y cuando la
optimización de la ruta de reparación no sea una preocupación."

- Stéphane Litkowski
9.4 ALF independiente de la topología
En las secciones anteriores ha quedado claro que el ALF clásico tiene grandes ventajas, pero también tiene
limitaciones y desventajas. El ALF clásico no puede proteger todos los destinos en todas las redesdepende de
la topología. Una desventaja del ALF es que aunque existan uno o más ALF, no siempre se proporciona el
más óptimo y necesario realizar ajustes manuales. Esto aumenta la complejidad operativa.

El LFA remoto amplía la cobertura al 95-99% de los destinos, pero tampoco proporciona siempre la ruta de
reparación más deseada. Además, añade más complejidad operativa al requerir una sesión LDP dirigida a los
RLFA para proteger el tráfico LDP.

El LFA independiente de la topología (TI-LFA) ofrece una solución para estas limitaciones manteniendo la
simplicidad de la solución IPFRR. Dado que TI-LFA utiliza Segment Routing para la ruta de reparación, SR debe
estar desplegado en la red. Nótese que incluso un despliegue parcial de SR puede proporcionar ya protección
TI-LFA. Esto se tratará más adelante en esta sección.

El uso del AGL independiente de la topología como mecanismo de protección tiene las siguientes ventajas:

TI-LFA proporciona protección de enlace, nodo y SRLG por debajo de 50 mseg con una cobertura del 100%.

TI-LFA es fácil de manejar y comprender. La funcionalidad está contenida dentro del IGP y no se
requieren protocolos o señalización adicionales.

La ruta de reparación es calculada automáticamente por el IGP, no se requiere ningún ajuste específico.

Al utilizar la ruta posterior a la convergencia como ruta de reserva, se evita la congestión transitoria y el
enrutamiento subóptimo en la ruta de reserva.

TI-LFA desplegarse de forma incremental; es una funcionalidad local.

TI-LFA también protege el tráfico LDP e IP del tráfico de Segment Routing.

La ruta de reparación más óptima y natural a seguir cuando se produce un fallo es la ruta que el tráfico seguirá
finalmente después de que el IGP haya convergido: la ruta post-convergencia. Esta ruta es preferible porque:

es óptimo para la planificación de la capacidad. Durante la fase de planificación de la capacidad de la red,

la capacidad de un enlace se aprovisiona teniendo en cuenta que dicho enlace se utilizará cuando fallen
otros enlaces. Por consiguiente, una ruta de reserva que también sea una ruta de postconvergencia es en
gran medida
determinista y no perturba las capacidades previstas.

es fácil de manejar. No es necesario realizar ajustes caso por caso para seleccionar el mejor entre varios
candidatos. Así se reduce la sobrecarga de aprovisionamiento al eliminar la necesidad de ajustar la
selección del ALF.

hay menos transiciones de tráfico. Como el trayecto de reparación es igual al trayecto posterior a la
convergencia, el tráfico cambia de trayecto una sola vez.

DESTACAR

La ruta de reparación más óptima y natural a seguir cuando se produce un fallo es la ruta que el tráfico seguirá finalmente después de
que el IGP haya convergido: la ruta de postconvergencia.

Antes de SR, no podía utilizar la ruta posterior a la convergencia, ya que en muchos casos no está libre de
bucles. El tráfico volvería al nodo de protección. El tráfico debe dirigirse explícitamente a lo largo de la ruta
posterior a la convergencia para garantizar la ausencia de bucles en la ruta.

Gracias a las capacidades de direccionamiento del tráfico de enrutamiento de origen de SR, siempre es posible
utilizar la posconvergencia como ruta de reparación. Basta con codificarla como una lista de segmentos para
que esté libre de bucles. Esto no crea ningún estado adicional en los nodos a lo largo de la ruta de reparación, ya
que la ruta de reparación no se señaliza, sino que se codifica en el origen en la cabecera del paquete. Por lo tanto,
al igual que LFA/RLFA, TI-LFA también es un mecanismo local en el PLR.

Con TI-LFA, el camino de reparación para proteger un destino D contra el fallo de un componente C es el
camino posterior a la convergencia cuando falla C: decir, es el camino más corto al destino D con el
componente C eliminado de la topología.

Con TI-LFA, el PLR codifica la ruta posterior a la convergencia como una lista de segmentos (es decir, una pila
de etiquetas). Al activarse la solución FRR, la pila de etiquetas adecuada se introduce en el tráfico reparado.

Recordemos que el cálculo de las listas de segmentos (es decir, la pila de etiquetas) se realiza por destino. Esto
garantiza la optimalidad de la solución: cada destino se repara a lo largo de su propia ruta de postconvergencia.
La 9-10 Figura Figura 9-8 repite la topología de red de la para ilustrar la selección óptima y automática de la
ruta de reparación TI-LFA. En esta red, Nodo2 protege el tráfico al destino Nodo5. Figura 9-10 indica que
LFA clásico dirige el tráfico a Nodo4 LFA después de un fallo del enlace protegido. Como se indicó antes en
la sección de LFA clásico, este camino no es óptimo ya que atraviesa el Nodo de Borde Nodo4 que está
conectado a través de enlaces de menor capacidad. Si el enlace protegido fallase, entonces el camino más corto
desde el Nodo2 al Nodo5 pasaría por el camino post-convergencia
Nodo2→Nodo6→Nodo7→Nodo3→Nodo5. Antes del fallo, TI-LFA calcula esta ruta de post-convergencia y
obtiene la Lista de Segmentos necesaria para dirigir los paquetes a lo largo de la ruta de post-convergencia sin
bucles de vuelta. En este sencillo ejemplo, TI-LFA codificará un único segmento en la cabecera de los
paquetes de la ruta de reparación: el segmento de prefijo del Nodo7. Como se muestra en la sección RLFA, el
Nodo7 es el nodo PQ para el Nodo5 de destino. El tráfico dirigido a través del nodo PQ Nodo7 efectivamente
lleva el tráfico al Nodo destino5. Y a partir de la inspección de la topología de la red, el tráfico seguirá la ruta
post-convergencia.
Figura 9-10: TI-LFA utiliza la ruta de postconvergencia
DESTACADO: Ventajas de TI-LFA
Protección de enlaces, nodos y SRLG en menos de

50 ms cobertura del 100% sea cual sea la

topología.

Fácil de manejar y entender

Calculado automáticamente por el IGP, no se requiere ningún otro protocolo

No se crea ningún estado fuera del estado de protección en el PLR; mecanismo

local Óptimo: la ruta de copia de seguridad sigue la ruta posterior a la

convergencia.

Despliegue gradual

Además del tráfico de Segment Routing, también se aplica al tráfico IP y LDP

"TI-LFA aporta una enorme ventaja sobre otras técnicas IPFRR. Mientras que LFA y RLFA no pueden garantizar la protección
(aunque proporcionen una buena cobertura), con TI-LFA operador sabe que siempre tendrá protección del tráfico, sea cual sea el
diseño implemente. Antes de TI-LFA, para una red IP o LDP que requiriera el 100% de la protección del tráfico, un operador tenía que
implementar RSVP-TE fast-reroute en cada enlace, lo que añadía mucha complejidad (LDP sobre RSVP tunneling para gestionar) y
seguía sin proporcionar una ruta de reparación óptima (era una solución FRR basada en instalaciones): el tráfico a menudo se desviaba
en muchos enlaces.

TI-LFA ofrece ahora una solución sencilla y natural para una IP o LDP. Además, incluso para redes en las que la protección del
tráfico garantizado no es una preocupación, TI-LFA es una solución rápida de desplegar (de nuevo un comando CLI y nada más de lo
que ocuparse) tan pronto como su red ejecute enrutamiento por segmentos. De nuevo, desplegar enrutamiento por segmentos en su red
no significa migrar todo su tráfico primario a LSPs de enrutamiento por segmentos. Puedes fácilmente desplegar enrutamiento por
segmentos, y sólo usarlo para reparar rutas construidas por TI-LFA, así que tu tráfico primario es todavía puro IP o LDP, usará rutas
de enrutamiento por segmentos sólo cuando FRR sea activado, y revertirá a IP o LDP cuando IGP converja.

La optimización del tráfico de TI-LFA supone una enorme mejora en comparación con cualquier otra técnica de FRR. Sólo RSVP-TE
detour FRR proporcionaba este enfoque en pasado, pero nunca se implementó porque requiere una malla completa de túneles TE de
extremo a extremo con una ruta FRR dedicada para cada túnel, que no es escalable. TI-LFA no tiene este problema de escalabilidad,
ya que no hay que mantener ningún estado en los nodos intermedios. La optimización del tráfico es fundamental, especialmente
cuando el ancho de banda es escaso y caro: un operador no puede desperdiciarlo. Además, tener una política de planificación de la
capacidad doble (una para la ruta FRR y otra para la ruta postconvergencia) aumentaría la complejidad de la planificación y podría
incrementar los costes de la red; esto no tiene sentido. Por tanto, alinear el trayecto FRR con el trayecto postconvergencia elimina la
necesidad de políticas específicas de direccionamiento del tráfico para FRR y simplifica de nuevo la red y su funcionamiento".

- Stéphane Litkowski

9.4.1 Cálculo TI-LFA

Esta sección ofrece una visión general de los pasos que se siguen en el cálculo de la ruta de reparación TI-LFA.

"Dedicamos muchas investigaciones a garantizar que el cálculo de las trayectorias posteriores a la convergencia y su codificación en
listas SID fueran escalables.

El cálculo debe realizarse por destino cada vez que cambia la topología. Debe escalarse a grandes redes de PE que experimenten
cambios frecuentes.

El resultado de esa investigación se ha implementado en la aplicación de Cisco. No es necesario detallar el algoritmo implementado,
ya que se trata de un comportamiento por salto."

- Clarence Filsfils

El PLR calcula la ruta primaria cada destino. Detecta cuál es el enlace saliente a lo largo de la ruta primaria. A
continuación, calcula un camino más corto con este enlace eliminado de la topología. Este es el camino post-
convergencia. A continuación, codifica el camino posterior a la convergencia como una lista de . Esta lista de
segmentos (es decir, una pila de etiquetas en MPLS SR) es la ruta de reserva precalculada para el destino
considerado.

El PLR repite este proceso para todos los destinos de la tabla IGP.

Es sencillo aplicar este proceso a la protección de enlaces, nodos o SRLG. La única modificación se produce en
el paso de poda (es decir, qué componente se elimina de la topología para calcular la ruta de posconvergencia).

Una vez calculada la ruta primaria a un destino, el PLR busca la política TI-LFA seleccionada por el operador
para el enlace saliente a lo largo de la ruta primaria.

Si la política indica SRLG, el PLR elimina las interfaces locales que comparten un SRLG con la ruta primaria.
Si la política indica Nodo, el PLR elimina el nodo de primer salto a lo largo de la ruta primaria. Si no, el PLR
elimina el enlace saliente a lo largo de la ruta primaria.

DESTACAR

TI-LFA ofrece protección de enlaces, nodos y SRLG

9.4.2 Análisis del tamaño de la lista de segmentos

"Es intuitivo que TI-LFA requiera pocos segmentos para codificar la ruta posterior a la

convergencia. En primer lugar, LFA y RLFA suelen estar disponibles (99%) y requieren cero o un

segmento.

En segundo lugar, se aplica la misma intuición que para la SRTE. En nuestra vida cotidiana, no planificamos nuestros viajes giro a
giro, sino que los planificamos como un número muy pequeño de saltos en el camino más corto. Aplicando esta intuición a una red
real: uno o dos caminos más cortos intermedios, uno o dos segmentos en terminología SR, bastarían para dirigir el tráfico. Véase el
capítulo 1, "Introducción"".

- Clarence Filsfils

La protección de enlaces TI-LFA en redes con métricas simétricas (donde para cada enlace A-B en la red, la
métrica de A→B es igual a la métrica de B→A) requiere como máximo dos segmentos adicionales en la ruta de
reparación. Esto está garantizado y demostrado (véase, por ejemplo, la referencia [FRANCOIS]).

En estas redes, los espacios P y Q se solapan o son adyacentes para proteger los enlaces. Aunque el límite
teórico es de dos segmentos adicionales, en la realidad rara vez se necesita más de uno.

Las redes no siempre utilizan métricas IGP simétricas. Esta asimetría de métricas puede ser intencionada o debida
a un error de configuración. Puede que se desee protección de nodo o SRLG. En estos casos, no existe un límite
teórico sobre el número de segmentos a imponer en la ruta de backup. Pero en realidad las cosas son mucho más
sencillas.

Un gran proveedor de servicios de ha presentado los resultados de la simulación TI-LFA para su red
[MPLSWC14], mostrando que la protección de enlaces en su red no requiere la mayor parte del tiempo ningún
segmento adicional y que el peor de los casos, muy raro, es de 2 segmentos en la ruta de backup.

Para la protección de nodos, se protege el 99,72% de los destinos utilizando hasta 2 ; con hasta 3 segmentos se
protege el 99,96% de los destinos; utilizando hasta 4 segmentos se consigue una cobertura del 100% para la
protección de nodos.

El análisis de otras topologías de red reales muestra resultados similares.

DESTACAR

El análisis de conjuntos de datos teóricos y reales muestra que TI-LFA requiere listas de

segmentos poco profundas. La mayoría de las rutas de copia de seguridad posteriores a la

convergencia se expresan en 0 o 1 segmento.

El 99,72% de las rutas de backup analizadas en la topología de red real requieren ≤ 2 segmentos.

El 99,96% de las rutas de copia de seguridad analizadas en la topología de red real requieren ≤ 3

segmentos. Ninguna ruta de copia de seguridad requirió más de 4 segmentos

9.4.3 Infraestructura TE para caminos de reparación

Un trayecto de reparación con protección de enlace en una red con métrica simétrica requiere como máximo
dos . También en otras circunstancias (por ejemplo, si se requiere protección de nodo o SRLG, o la red tiene
métricas asimétricas) el número de segmentos necesarios para el trayecto de reparación está limitado en
realidad, véase la sección 9.4.2, "Análisis del tamaño de la lista de segmentos". Sin embargo, a veces se
necesitan más segmentos (etiquetas en la implementación MPLS SR) en la ruta de reparación. El número de
segmentos que puede imponer un router depende de la capacidad de su plataforma hardware. La imposición de
múltiples segmentos a un paquete en un encaminador no es nueva en el plano de datos MPLS tradicional, pero
con el encaminamiento por segmentos y especialmente con algunos de casos de uso en ingeniería de tráfico, el
número de etiquetas a imponer podría ser grande dependiendo de la posición en la red.

Para acomodar la imposición de más del límite soportado por la plataforma para la ruta de reparación, los IGP
en Cisco IOS XR utilizan la infraestructura de ingeniería de tráfico (TE). El IGP proporciona la interfaz
saliente, el siguiente salto y la pila de etiquetas de la ruta de reparación calculada al TE y solicita al TE que
instancie una política SRTE[ 2] con esa información. No se ninguna otra funcionalidad del TE, como la
validación de la ruta.
Con este mecanismo, la cantidad de etiquetas en la ruta de reparación se incrementa hasta un número muy
superior al soportado por la infraestructura TE.

En el momento de escribir este libro, el número máximo de etiquetas que se podían imponer directamente eran
3 y utilizando la infraestructura TE eran 10 para plataformas como las series ASR9000 y NCS6000 mientras
que podían ser menores para algunas otras plataformas o modelos específicos de tarjetas de línea. Estos
números son unos cuantos órdenes superiores a lo que se suele necesitar para la mayoría de las implantaciones
de TI-LFA y este mecanismo es
completamente abstraído por la aplicación para no añadir ninguna complejidad o sobrecarga a la provisión o
gestión por parte del operador.

Para utilizar esta funcionalidad, debe instalarse la PIE MPLS[ 3] en el nodo de protección en el que está
habilitada la TI-LFA, ya que la funcionalidad de infraestructura TE está contenida en dicha PIE. No se
requiere ninguna configuración TE para habilitar esta funcionalidad. Dado que en la mayoría de los casos se
puede proporcionar cobertura total con hasta tres etiquetas en el trayecto de reparación, esta funcionalidad
puede no ser necesaria en una red determinada.

IGP no crea una Política SRTE diferente para proteger cada destino individual, sino que comparte la misma
Política SRTE como ruta de reparación para múltiples destinos que comparten la ruta de reparación.

Una limitación del uso de una política SRTE instanciada automáticamente para la ruta de reparación es que
todos los nodos de reparación t (es decir, saltos explícitos) requeridos deben ser aptos para SR, y el nodo vecino
nexthop en la ruta de reparación debe ser apto para SR. La funcionalidad de interfuncionamiento SR/LDP aún
puede aplicarse en la ruta de reparación si los nodos intermedios (nodos que no son nodos de punto final de
segmento) en la ruta de reparación son sólo LDP.

La salida del Ejemplo 9-1 muestra una ruta de reparación de protección de nodo calculada por TI-LFA de
ISIS. Aquí sólo se discute la implicación de la Política SRTE. La Sección [Link] discute los detalles de esta
ruta de reparación (topología, tipo de protección, etc.). La ruta de reparación contiene cuatro segmentos; se
deben imponer cuatro etiquetas a los paquetes dirigidos por esta ruta de reparación. Para pilas de superiores a
tres, el IGP utiliza la infraestructura TE para crear una política SRTE. En este ejemplo, la política SRTE está
representada por tunnel-te32783, como se muestra en la línea 6 de la salida. El número de esta interfaz tunnel-
te se selecciona dinámicamente de un conjunto predeterminado que comienza en 32768. El operador puede
especificar otro conjunto de números como se ilustra en el Ejemplo 9-2.

Aunque no se requiere ninguna configuración TE para utilizar esta funcionalidad, en el momento de escribir
este , todavía era necesario configurar la dirección IP por defecto de la interfaz tunnel-te utilizando la
configuración ipv4 unnumbered mpls traffic-eng Loopback0.
Ejemplo 9-1: Nodo TI-LFA ISIS que protege la ruta de reparación

1 RP/0/0/CPU0:xrvr-1#show isis fast-reroute [Link]/32 detail

2
L2 [Link]/32 [20/115] prioridad media
3
4 vía [Link], GigabitEthernet0/0/0/1, xrvr-2, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (nodo), vía [Link], GigabitEthernet0/0/0 xrvr-5, SRGB
Base: 16000, Peso: 0
6 Túnel de respaldo: tunnel-te32783
7 Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
8 Nodo Q: xrvr-3.00 [[Link]], Etiqueta: 30403
9 Nodo P: xrvr-8.00 [[Link]], Etiqueta: 16008
10 Nodo P: xrvr-10.00 [[Link]], Etiqueta: 16010
11 Etiqueta prefijo: 16006
12 P: No, TM: 110, LC: No, NP: No, D: No, SRLG: No
13 src xrvr-6.00-00, [Link], prefijo-SID índice 6, R:0 N:1 P:0 E:0 V:0 L:0

Ejemplo 9-2: Grupo de números de interfaz de política SRTE

mpls traffic-eng
auto-tunnel p2p
tunnel-id min 10000 max 19999

Los detalles de la Política SRTE en el nodo de protección se muestran en el Ejemplo 9-3. La mayoría de los
elementos de la salida no tienen importancia para el uso de la Política SRTE instanciada automáticamente de la
ruta de reparación TI- LFA. La política SRTE es literalmente Segment-Routing, lo que significa que
el IGP dicta cómo TE construye la política (literalmente= "palabra por palabra"). La ruta de la Política SRTE
contiene un siguiente salto ([Link]) y un número de etiquetas {16004, 30403, 16008, 16010}, ver líneas 37 a
42.
Ejemplo 9-3: Política SRTE instanciada por IGP para ruta de reparación TI-LFA

1 RP/0/0/CPU0:xrvr-1#show mpls traffic-eng tunnels 32783

2
3
4 Nombre: tunnel-te32783 Destino: [Link] Ifhandle:0x1480 (auto-túnel para ISIS 1)
5 Signalled-Name: auto_xrvr-1_t32783
6 Estado:
7 Admin: arriba Oper: up Ruta: válida Señalización: conectado
8
9 ruta opción 10, (literal Segment-Routing) tipo explícito (_te32783) (Base para Setup)
10 G-PID: 0x0800 (derivado de las propiedades de la interfaz de salida)
11 Ancho de banda solicitado: 0 kbps CT0
12 Hora de creación: Fri Jul 1 07:18:59 2016 (hace 05:05:19)
13 Parámetros de configuración:
14 Ancho de banda: 0 kbps (CT0) Prioridad: 7 7 Afinidad: 0x0/0x0
15 Tipo métrico: TE (global)
16 Selección del camino:
17 Desempate: Min-relleno (por defecto)
18 Protección: cualquiera (por defecto)
19 Límite de saltos: desactivado
20 Límite de costes: desactivado
21 Tiempo de espera de validación de ruta: 10000 mseg (por defecto), Acción: Tear (por
defecto)
22 AutoRoute: desactivado LockDown: desactivado Clase de política: no establecida
23 Clase de reenvío: 0 (por defecto)
24 Reenvío-Adyacencia: desactivado
25 Destinos Autoroute: 0
26 Carga compartida: 0 loadshares iguales
27 Auto-bw: desactivado
28 Protección de ruta: No activada
29 Detección rápida BFD: Desactivado
30 Reoptimización tras fallo de afinidad: Activado
31 Descubrimiento del SRLG: Desactivado
32 Historia:
33 Túnel ha estado arriba para: 03:33:43 (desde vie jul 01 08:50:35 UTC 2016)
34 LSP actual:
35 Tiempo de actividad: 03:33:43 (desde vie jul 01 08:50:35 UTC 2016)
36
37 Segment-Routing Path Info (no se utiliza la información IGP)
38 Segmento0[Primer salto]: [Link], Etiqueta: -
39 Segmento1[ - ]: Etiqueta: 16004
40 Segmento2[ - ]: Etiqueta: 30403
41 Segmento3[ - ]: Etiqueta: 16008
42 Segmento4[ - ]: Etiqueta: 16010
43 Mostró 1 (de 4) caras, 0 (de 0) puntos medios, 0 (de 0) colas
44 Se muestra 1 arriba, 0 abajo, 0 recuperando, 0 cabezas recuperadas
IGP comparte las mismas Políticas SRTE para proteger múltiples destinos; aquellos que requieren la misma ruta
de reparación. Esto se ilustra en el Ejemplo 9-4. ISIS utiliza tunnel-te32784 para la ruta de reparación del
destino [Link]/32, [Link]/32, ..., como se muestra en la línea 9 de la salida.

Ejemplo 9-4: Política SRTE compartida para proteger varios destinos

1 RP/0/0/CPU0:xrvr-1#show isis fast-reroute tunnel

2
3 túneles de reserva IS-IS 1 SRTE
4
5 tunnel-te32784, estado up
6 Interfaz de salida: GigabitEthernet0/0/0/0
7 Siguiente salto: [Link]
8 Pila de etiquetas: 16004, 24002, 16008
9 Prefijo: [Link]/32 [Link]/32 [Link]/24 [Link]/24 [Link]/24
10
11 tunnel-te32783, estado up
12 Interfaz de salida: GigabitEthernet0/0/0/0
13 Siguiente salto: [Link]
14 Pila de etiquetas: 16004, 24002, 16008, 16010
15 Prefijo: [Link]/32 [Link]/24
9.5 Opciones de protección TI-LFA
En esta sección, veremos las diferentes opciones de protección que están disponibles para TI-LFA, cómo se
configuran tanto para ISIS como para OSPF. También veremos ejemplos de cada una usando la topología de
red de la Figura 9-11, que se usa para ilustrar TI-LFA tanto para ISIS como para OSPF.

Figura 9-11: Topología de la red TI-LFA

Todos los enlaces tienen una métrica IGP 10, excepto el enlace entre Nodo3 y Nodo4 que tiene una métrica IGP
40. Todos los nodos tienen asignado el SRGB por defecto [16000-23999]. Cada NodoX tiene un prefijo
loopback
1.1.1.X/32 y una etiqueta Prefix-SID asociada 16000+ X. El Nodo2 tiene dos enlaces que comparten un SRLG
"1111": enlace con el Nodo6 y enlace con el Nodo9. Estos enlaces están marcados con un cuadrado en la
ilustración.
DESTACAR

Todas las opciones de protección TI-LFA garantizan una ruta de reparación a lo largo de la ruta posterior a la convergencia en cualquier
topología

La opción de protección de enlace por defecto funciona en muchos diseños de red y es la preferida; incluso puede proporcionar
protección de nodo de facto en muchos casos

La protección SRLG puede habilitarse en redes en las que se han proporcionado SRLG; tenga en cuenta que en implementación de
Cisco IOS XR en el momento de escribir este libro sólo se tienen en cuenta SRLG para enlaces locales.

Puede ser útil activar la protección de nodos en determinados casos, pero podría no proporcionar la ruta posterior a la convergencia si
el fallo fuera sólo de enlace.

9.5.1 Protección de enlaces

La protección de enlaces es la más básica de las opciones disponibles para TI-LFA y todo lo que necesita es
estar activada para todos los enlaces que necesiten protección.

[Link] Configuración ISIS

El Ejemplo 9-5 muestra una configuración ISIS muy simple para habilitar la Protección de Enlace TI-LFA.
fast- reroute per-prefix y fast-reroute per-prefix ti-lfa están habilitadas bajo
la familia de direcciones de cada interfaz ISIS. TI-LFA está soportado tanto para familias de direcciones IPv4
como IPv6.

Ejemplo 9-5: Protección de enlace ISIS TI-LFA

enrutador isis 1
address-family ipv4 unicast
segment-routing mpls
¡!
address-family ipv4 unicast
segment-routing mpls
¡!
interfaz GigabitEthernet0/0/0/0
punto a punto
address-family ipv4 unicast
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
¡!
address-family ipv6 unicast
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
Para añadir automáticamente la configuración TI-LFA a todas las interfaces ISIS, se puede utilizar la
funcionalidad de grupo de configuración; véase el Ejemplo 9-6. La funcionalidad de grupo de configuración es
una herramienta genérica de simplificación de la configuración, que no es específica de TI-LFA o Segment
Routing.

Ejemplo 9-6: Protección de enlace ISIS TI-LFA - usando grupo de configuración

grupo GROUP_ISIS
enrutador isis '.*'
interface 'GigabitEthernet.*'
address-family ipv4 unicast
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
address-family ipv6 unicast
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
end-group
¡!
enrutador isis 1
aplicar-grupo GROUP_ISIS
address-family ipv4 unicast
segment-routing mpls
¡!
address-family ipv4 unicast
segment-routing mpls
¡!
interfaz GigabitEthernet0/0/0/0
punto a punto
address-family ipv4 unicast

[Link] Configuración de OSPF

El Ejemplo 9-7 muestra un ejemplo de configuración TI-LFA para OSPF. La configuración TI-LFA para tiene
alcance de interfaz. Es aplicable por interfaz pero puede ser configurada por instancia, por área y por interfaz.
Las reglas regulares de herencia de configuración OSPF son aplicadas en la configuración: si TI-LFA es
configurado por instancia o por área, entonces todas las interfaces en la instancia o área heredan la
configuración TI- LFA.

Ejemplo 9-7: Configuración OSPF TI-LFA

router ospf 1 segment-

routing mpls
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
El ejemplo 9-8 ilustra cómo se puede desactivar fast-reroute y/o TI-LFA por área o por interfaz.

Ejemplo 9-8: Configuración TI-LFA de OSPF - desactivación

router ospf 1 segment-

routing mpls
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable area
0
interfaz GigabitEthernet0/0/0/0 red
punto a punto
fast-reroute disable
¡!
¡!
área 1
fast-reroute per-prefix ti-lfa disable interface
GigabitEthernet0/0/0/1
red punto a punto
¡!
¡!
¡!

[Link] Ejemplos de protección de enlaces

Aquí se analiza un único ejemplo de protección de enlaces TI-LFA: un enlace de doble segmento que protege la
ruta de reparación.

Consulte la topología de la red en la Figura 9-12.

Figura 9-12: Protección de enlace de doble segmento TI-LFA

Para el Nodo1, la ruta primaria hacia el destino Nodo6 atraviesa el enlace entre el Nodo1 y el Nodo2. El
cálculo TI-LFA para el Nodo de destino 6 es el siguiente:

Elimina de la topología el enlace del camino primario al Nodo6 (enlace Nodo1-Nodo2) y calcula el Árbol
del Camino Más Corto (SPT) en la topología resultante. Esto nos da la ruta post-convergencia desde el
Nodo1 al Nodo6: {Nodo5, Nodo4, Nodo3, Nodo2, Nodo6}. Este camino está etiquetado como "Camino
post-convergencia" en la ilustración.

Nodo4 está en el espacio P (Nodo1 puede enviar un paquete destinado a Nodo4 sin riesgo de que ese
paquete fluya de vuelta a través del enlace protegido Nodo1-Nodo2). El Nodo4 no está en el espacio Q; un
paquete destinado al Nodo6 que se dirige al Nodo4 se devuelve en bucle y se envía a través del enlace
protegido. El espacio P y el espacio Q se indican en la ilustración.

Nodo3 está en el espacio Q (Nodo3 puede enviar un paquete a Nodo2 sin riesgo de que este paquete
fluya de vuelta a través del enlace protegido Nodo1-Nodo2).

Los espacios P y Q no se cruzan; no hay ningún nodo que esté tanto en el espacio P como en el espacio Q.
Pero el nodo 4 (nodo P) y el nodo 3 (nodo Q) son adyacentes y están situados en la trayectoria de
postconvergencia.
El PLR Nodo1 empuja la lista de segmentos {Prefix-SID(Nodo4), Adjacency-SID(R4-R3)} en los paquetes
reparados hacia el destino Nodo6 y los reenvía por la interfaz al Nodo5. Si el camino más corto desde el
Nodo4 al Nodo3 es a través del enlace directo entre estos nodos, entonces el Prefijo-SID del Nodo4 puede
ser usado para dirigir el tráfico desde el Nodo3 al Nodo4. De lo contrario, se utiliza el Adjacency-SID del
enlace Nodo4-Nodo3. En este ejemplo se ilustra este último caso: el camino más corto desde el Nodo4 al
Nodo3 consiste en dos caminos de igual coste (a través del Nodo5 y directamente al Nodo3). También en
este caso se utiliza el Adjacency-SID para dirigir el tráfico al Nodo3.

El comportamiento anterior se aplica por prefijo. La ruta de post-convergencia se calcula para cada prefijo de
destino, y la ruta de reparación TI-LFA para cada destino se adapta sobre la ruta de post-convergencia a ese
destino. Nótese que la descripción anterior es una descripción conceptual de los cálculos y no del algoritmo
real. El algoritmo TI-LFA real es propietario (comportamiento local no entra en el ámbito de la estandarización
del IETF) y se escala extremadamente bien.

La Figura 9-13 ilustra la pila de etiquetas en los paquetes dirigidos en la ruta de reparación TI-LFA después
del fallo del enlace entre Nodo1 y Nodo2. Nodo6 anuncia un prefijo loopback [Link]/32 con una etiqueta
Prefix-SID 16006.

Figura 9-13: Ruta de reparación de doble segmento, pila de etiquetas

Un paquete con la etiqueta superior 16006 llega al Nodo1. 16006 es un Prefijo-SID del Nodo6. El Nodo1
cambia la etiqueta superior por misma etiqueta Prefix-SID 16006. Entonces Nodo1 pone dos etiquetas
adicionales en la pila de etiquetas: la primera etiqueta es la etiqueta Prefix-SID 16004 asociada con el prefijo
loopback del Nodo P4. La segunda etiqueta es la etiqueta Adjacency-SID asociada con la adyacencia de
Nodo4 a Nodo3. Se trata de una etiqueta asignada localmente por el Nodo4, por ejemplo 30403 como la
utilizada en la ilustración.
A continuación, el Nodo1 dirige el paquete por la interfaz hacia el Nodo4.

Si un paquete IP sin etiqueta con destino [Link] llega al Nodo1, entonces el Nodo1 impone la etiqueta Prefijo-
SID de [Link]/32, 16006. Esto es equivalente a la imposición de la etiqueta Prefix-SID en el camino primario
cuando el camino de reparación no está activo. Entonces Nodo1 pone las mismas dos etiquetas adicionales en la
pila de etiquetas como se describe arriba: la Prefix-SID 16004 asociada con el prefijo loopback del Nodo P4, y
la Adjacency-SID 30403 asociada con la adyacencia de Nodo4 a Nodo3.

El Nodo3 está en el espacio Q del Nodo6 de destino. Así, cuando el paquete de la ruta de reparación al Nodo3,
éste lo reenvía por su ruta regular más corta hacia el Nodo6 de destino.

El Ejemplo 9-9 muestra la ruta de reparación de protección de enlace calculada por ISIS en la salida de
show isis fast-reroute detail. Esta ruta de reparación TI-LFA utiliza Nodo4 como nodo P y
Nodo3 como nodo Q. El tráfico en la ruta de reparación se dirige en la interfaz saliente Gi0/0/0/0 hacia el
Nodo5, nexthop
[Link] (línea 6). ISIS ha compuesto la pila de etiquetas [16004, 30403, 16006] para la ruta de reparación.
La etiqueta inferior 16006 es la Prefix-SID asociada al prefijo [Link]/32 (línea 8). Esta etiqueta no es una
etiqueta impuesta adicional, sino la etiqueta de salida Prefix-SID regular para el destino. La siguiente
etiqueta en la pila, en el medio, la etiqueta Adjacency-SID 30403 para la adyacencia de Nodo4 a Nodo3
(línea 7). La etiqueta superior 16004 es la Prefix-SID para el nodo P, Nodo4, asociada con el prefijo
[Link]/32 (línea 6).
Ejemplo 9-9: Ruta de reparación de doble segmento ISIS

1 RP/0/0/CPU0:xrvr-1#show isis fast-reroute [Link]/32 detail

2
3L2 [Link]/32 [20/115] prioridad media
4 vía [Link], GigabitEthernet0/0/0/1, xrvr-2, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (enlace), vía [Link], GigabitEthernet0/0/0 xrvr-5,
SRGB Base: 16000, Peso: 0
6 Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
7 Nodo Q: xrvr-3.00 [[Link]], Etiqueta: 30403
8 Etiqueta prefijo: 16006
9 P: No, TM: 80, LC: No, NP: No, D: No, SRLG: No
10 src xrvr-6.00-00, [Link], prefijo-SID índice 6, R:0 N:1 P:0 E:0 V:0 L:0

El Adjacency-SID para dirigir el tráfico protegido del Nodo4 al Nodo3 es el Adjacency- SID desprotegido. La
salida recogida en el Nodo-P Nodo4 en el Ejemplo 9-10 muestra la Adjacency- SID desprotegida al Nodo-Q
Nodo3 con la etiqueta 30403. Esta Adjacency-SID es usada en la ruta de reparación TI-LFA.

Ejemplo 9-10: Adyacencia ISIS-SID de nodo P a nodo Q

RP/0/0/CPU0:xrvr-4#show isis adjacency systemid xrvr-3 detail IS-IS

1 Adyacencias de nivel 2:
Id. del sistema Interfaz SNPA Estado Hold Cambiado NSF IPv4 IPv6
BFD BFD
xrvr-3 GIO/0/0/1 PtoP Arri 28 1w0d Sí Ninguno
ba
Zona Dirección: 49.0001
Dirección IPv4 del vecino: [Link]*
SID de adyacencia: 310403 (protegido)
Pila de etiquetas de [16003]
reserva:
Tamaño de la pila de 1
respaldo:
Interfaz de respaldo: Gi0/0/0/0
Backup nexthop: [Link]
Dirección del nodo de [Link]
respaldo:
SID de adyacencia no FRR: 30403
Topología: IPv4 Unicast

Recuento total de adyacencias: 1

El ejemplo 9-11 muestra la ruta de reparación calculada por OSPF en la salida de show ospf routes
backup-path. La ruta de reparación TI-LFA es una ruta vía Nodo P Nodo4, con etiqueta 16004 (línea 10), y
Nodo Q Nodo3 con etiqueta 30403 (línea 11). El tráfico en ruta de backup se dirige en la interfaz saliente
Gi0/0/0/0 hacia Nodo5, nexthop [Link] (línea 12).
Ejemplo 9-11: Ruta de reparación de doble segmento OSPF

1 RP/0/0/CPU0:xrvr-1#show ospf route [Link]/32 backup-path detail

2
3 Entrada de ruta OSPF para [Link]/32
4 Tipo de ruta: Intra-area
5 Última actualización: 30 Jun 19:58:13.752
6 Métrica: 21
7 SPF prioridad: 4, SPF versión: 37
8 Versión RIB: 0, Fuente: Desconocido
9 [Link], desde [Link], vía GigabitEthernet0/0/0/1, path-id 1
10 Ruta de copia de seguridad: TI-LFA, Lista de reparación: Nodo P: [Link]
Etiqueta: 16004
11 Nodo Q: [Link] Etiqueta: 30403
12 [Link], desde [Link], vía GigabitEthernet0/0/0/0, mapa de bits protegido
0000000000000001
13 Atributos: Métrica: 81, SRLG Disjuntos

La salida en el Nodo-P Nodo4 en el Ejemplo 9-12 muestra el Adjacency-SID desprotegido al Nodo-Q con la
etiqueta 30403 (línea 23). Esta Adjacency-SID se utiliza en la ruta de reparación TI-LFA.

Ejemplo 9-12: Adyacencia OSPF-SID del nodo P al nodo Q

1 RP/0/0/CPU0:xrvr-4#show ospf neighbor det [Link]

2
3 * Indica la interfaz MADJ
4 # Indica vecino esperando sesión BFD up
5
6 Vecinos para OSPF 1
7
8 Vecino [Link], dirección de interfaz [Link]
9 En el área 0 a través de la interfaz GigabitEthernet0/0/0/1
10 La prioridad del vecino es 1, el estado es LLENO, 6 cambios de estado
11 DR es [Link] BDR es [Link]
12 Opciones es 0x52
13 Opciones LLS es 0x1 (LR)
14 Tiempo muerto en 00:00:33
15 El vecino está listo para 1w0d
16 Número de retransmisiones DBD durante el último intercambio 0
17 Índice 2/2, longitud de cola de retransmisión 0, número de retransmisiones 10
18 Primero 0(0)/0(0) Siguiente 0(0)/0(0)
19 La longitud del último escaneo de retransmisión es 0, el máximo es 2
20 El tiempo de escaneo de la última retransmisión es 0 mseg, el máximo es 0 mseg
21 LS Ack list: NSR-sync pending 0, high water mark 0
22 Etiqueta SID de adyacencia: 310403, Protegido
23 Etiqueta SID de adyacencia no protegida: 30403
Para verificar el comportamiento de reenvío para paquetes entrantes no etiquetados, se examina la tabla cef.
La salida de show cef para el prefijo [Link]/32 en el Ejemplo 9-13 muestra una ruta primaria vía Nodo2,
nexthop [Link], con un path-idx 1 (líneas 11-14). La etiqueta 16006 se impone en el camino
primario; ésta es la etiqueta Prefix-SID del Nodo6 de destino. El camino primario está marcado como
protegido por el camino con path-idx 0, indicado por bkup-idx 0.

La ruta de reparación (líneas 6-10 en la salida) tiene path-idx 0 y pasa por el Nodo5, nexthop [Link],
usando el nodo-P [Link] y el nodo-Q [Link]. La pila de etiquetas impuesta contiene tres etiquetas {16004,
30403, 16006}. La etiqueta inferior, a derecha, es la etiqueta Prefijo-SID 16006 asociada con el prefijo de
destino [Link]/32. Esta es la etiqueta Prefijo-SID normal. Esta es la Prefix-SID normal que también se impone
a los paquetes destinados a [Link] en la ruta primaria cuando la ruta de reparación no está . La siguiente
etiqueta en la pila, en el medio, la etiqueta Adjacency-SID 30403 para la adyacencia de Nodo4 a Nodo3. La
etiqueta superior 16004 a la izquierda, es la etiqueta Prefix-SID para el nodo P Nodo4, asociada con el prefijo
[Link]/32.

Ejemplo 9-13: Ruta de reparación de doble segmento TI-LFA en CEF

1 RP/0/0/CPU0:xrvr-1#show cef [Link]/32

2 [Link]/32, versión 1214, interno 0x1000001 0x81 (ptr 0xa1434d74) [1], 0x0 (0xa13ffb00), 0xa28
(0xa171c470)
3 Actualizado 30 Jun 21:42:14.375
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 1
6 via [Link]/32, GigabitEthernet0/0/0/0, 11 dependencias, peso 0, clase 0, backup
(remoto) [flags 0x8300]
7 path-idx 0 NHID 0x0 [0xa110d250 0x0]
8 siguiente salto [Link]/32, nodo P [Link], nodo Q [Link]
9 adyacencia local
10 etiqueta local 16006 etiquetas impuestas {16004 30403 16006}
11 via [Link]/32, GigabitEthernet0/0/0/1, 11 dependencias, peso 0, clase 0, protegido
[flags 0x400]
12 path-idx 1 bkup-idx 0 NHID 0x0 [0xa0e834e0 0x0]
13 siguiente salto [Link]/32
14 etiqueta local 16006 etiquetas impuestas {16006}

Para verificar el comportamiento de reenvío de los paquetes con etiqueta SR entrantes, se examina la tabla de
reenvío MPLS. Consulte la salida de show mpls forwarding detail para Prefix-SID label 16006 en
el Ejemplo 9-14.
La entrada de reenvío MPLS en la parte superior de la salida (líneas 5-12) muestra la ruta primaria vía Nodo2,
nexthop [Link]. La etiqueta local o entrante 16006 se intercambia con la misma etiqueta saliente 16006. La
ruta primaria está marcada como protegida por la ruta con índice 0, como indica Backup path idx: 0 en
la línea 10.

En la ruta de reparación, se muestra la misma pila de etiquetas que en la entrada cef: {16004, 30403, 16006}
(línea 18). Observe que la pila de etiquetas completa sólo se muestra en la salida detallada. La salida normal,
no detallada, sólo muestra la etiqueta superior, 16004 en este ejemplo (como en la línea 14). La ruta de
reparación va a través de la interfaz saliente Gi0/0/0/0, nexthop Nodo5.

Ejemplo 9-14: Reenvío MPLS con protección de doble segmento TI-LFA

1 RP/0/0/CPU0:xrvr-1#show mpls forwarding labels 16006 detail

2 Local Saliente Prefijo Saliente Salto siguiente Bytes
3 Etiqueta Etiqueta o ID Interfaz Conmutado
4
5 16006 16006 SR Pfx (idx 6) Gi0/0/0/1 [Link] 0
6 Actualizado: 30 Jun 21:42:12.444
7 Banderas de ruta: 0x400 [ BKUP-IDX:0 (0xa0e834e0) ]
8 Versión: 1214, Prioridad: 1
9 Pila de etiquetas (Arriba -> Abajo): { 16006 }
10 NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Peso: 0
11 MAC/Encaps: 14/18, MTU: 1500
12 Paquetes conmutados: 0
13
14 16004 SR Pfx (idx 6) Gi0/0/0/0 [Link] 0
(!)
15 Actualizado: 30 Jun 21:42:12.444
16 Banderas de ruta: 0x8300 [ IDX:0 BKUP, NoFwd ]
17 Versión: 1214, Prioridad: 1
18 Pila de etiquetas (Arriba -> Abajo): { 16004 30403 16006 }
19 NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Peso: 0
20 MAC/Encaps: 14/26, MTU: 1500
21 Paquetes conmutados: 0
22 (!): FRR pura copia de seguridad
23
24 Matriz de tráfico Paquetes/Bytes conmutados: 0/0

9.5.2 Protección de nodos y SRLG

TI-LFA también protege contra fallos de nodos y SRLG locales. Dado que TI-LFA instala una única ruta de
reparación por destino, el operador especifica un orden de preferencia para indicar qué componente debe
protegerse: enlace, nodo o SRLG. Si no se configura ninguna preferencia, sólo se tiene en cuenta la protección
del enlace.
Se calcula y se instala la ruta de reparación del modo de protección preferido. Esta ruta de reparación
programada se activa en caso de fallo, independientemente de si se trata de un fallo de enlace, nodo o SRLG.
Por ejemplo, si TI-LFA instala una ruta de reparación de protección de nodo, esa ruta de reparación se utilizará
en caso de fallo del enlace, aunque el nodo siga funcionando.

La configuración del orden de preferencia se realiza mediante una configuración de desempate. Aunque la
sintaxis de la configuración es la misma que la del ALF clásico, la semántica es ligeramente diferente. En el
ALF clásico las reglas de desempate se usan para seleccionar un ALF entre varios ALF candidatos. Las reglas
de desempate usadas en TI-LFA no seleccionan entre múltiples candidatos LFA, pero especifican un orden de
preferencia de modo de protección (enlace, nodo, SRLG). Para empezar, el candidato debe ser una ruta de
postconvergencia, ya que ésta es la propiedad fundamental del TI-LFA. Si el cálculo de la ruta de reparación
de un modo de protección de mayor preferencia no produce una ruta de reparación, se intenta el cálculo de la
ruta del siguiente modo de protección de menor preferencia. TI-LFA intenta combinar todos los modos de
protección configurados. Si se configuran tanto la protección SRLG como la protección de nodo, TI-LFA
intenta proporcionar una protección SRLG combinada de nodo+ .
La protección de nodos y SRLG también proporciona implícitamente protección de enlaces.

Por ejemplo, si el orden de preferencia configurado con los criterios de desempate es: (1) protección local
SRLG,
(2) protección de nodos, (3) protección de enlaces, entonces TI-LFA prefiere una ruta de reparación de
protección de nodos SRLG+ . Si no se encuentra una ruta de reparación de protección de nodos SRLG+ , TI-
LFA prefiere una ruta de reparación de protección de SRLG. Si no está disponible, TI-LFA prefiere una ruta
de reparación que proteja el nodo. Si tampoco está disponible, TI-LFA utiliza una ruta de reparación de
protección de enlace. Con , siempre que haya una ruta alternativa, el algoritmo siempre encuentra una ruta de
reparación protege los enlaces.

[Link] Configuración ISIS

ISIS permite la configuración de reglas de desempate por familia de direcciones bajo la instancia ISIS y bajo la
interfaz ISIS. Cualquier configuración de desempate bajo una interfaz ISIS anula completamente la
configuración de desempate bajo la instancia ISIS para esa familia de direcciones. La configuración de
desempate de la familia de direcciones de la instancia se ignora por completo, es decir, no hay fusión entre las
reglas de desempate de la interfaz y de la instancia. Esto contrasta con OSPF donde los tiebreakers configurados
a diferentes niveles se fusionan; ver sección [Link], "Configuración de OSPF".

Las reglas de desempate pueden configurarse por nivel ISIS.

TI-LFA puede utilizar los tres tipos de desempate (node-protecting, srlg-disjoint, y default)
mostrados en el Ejemplo 9-15. Los otros desempates (LFA clásico) no son soportados por TI-LFA en ISIS.
Los dos primeros tipos (node-protecting y srlg-disjoint) se utilizan para indicar la preferencia
por la protección de nodos y la protección SRLG. El tercero (default) es algo especial. Se utiliza para
indicar que se debe utilizar la protección por defecto, que es la protección de enlace. Se puede utilizar para
volver a la protección por defecto para una determinada interfaz ISIS cuando se configura alguna preferencia
de protección de nodo y/o SRLG en la instancia ISIS. Los siguientes ejemplos lo aclararán mejor.

Ejemplo 9-15: Reglas de desempate del TI-LFA de ISIS

fast-reroute per-prefix tiebreaker node-protecting index <index> {level <level>} fast-

reroute per-prefix tiebreaker srlg-disjoint index <index> {level <level>} fast-reroute
per-prefix tiebreaker default {level <level>}

El índice indica la preferencia de la regla. Un índice más alto significa un criterio de desempate más preferido.

El desempate por defecto es mutuamente excluyente con los desempates de nodo-protección y

srlg- disjoint; no pueden configurarse juntos en el mismo nivel ISIS.

Los siguientes ejemplos ilustran algunas configuraciones posibles.

En el Ejemplo 9-16, las reglas de desempate TI-LFA se configuran bajo la familia de direcciones de la
instancia ISIS (líneas 3 a 4). No se configura ningún desempate en la interfaz ISIS, por lo que la interfaz
hereda los desempates configurados en la instancia. Con esta configuración, TI-LFA proporciona una ruta de
reparación de protección SRLG de nodo+ para los destinos alcanzables a través de la interfaz Gi0/0/0/0 si está
disponible. Esta ruta de reparación también protegería los enlaces. Si no disponible, se seleccionaría una ruta
de reparación de protección de nodos, ya que la regla de desempate de protección de nodos tiene mayor
preferencia (índice más alto). Si no se dispone de tal ruta de reparación, TI-LFA selecciona una ruta de
reparación disjunta SRLG. Si no está disponible, el TI-LFA selecciona una ruta de reparación que proteja los
enlaces. Obsérvese que la regla implícita de desempate de protección de enlaces está siempre en el nivel de
preferencia más bajo (no configurable).
Ejemplo 9-16: Nodo ISIS TI-LFA y protección SRLG

1 enrutador isis 1
2 address-family ipv4 unicast
3 fast-reroute per-prefix tiebreaker node-protecting index 200
4 fast-reroute per-prefix tiebreaker srlg-disjoint index 100
5 ¡!
6 interfaz GigabitEthernet0/0/0/0
7 address-family ipv4 unicast
8 fast-reroute per-prefix
9 !!! no hay desempate
10 fast-reroute per-prefix ti-lfa

En el Ejemplo 9-17 se configura una regla de desempate en la instancia ISIS (línea 3) y otra en la interfaz ISIS
(línea 8). La configuración del criterio de prioridad de la interfaz anula completamente la configuración del
criterio de prioridad de la instancia. Como se ha indicado anteriormente, las diferentes reglas de desempate no
se fusionan. Con esta configuración, TI-LFA selecciona una ruta de reparación SRLG-disjoint para los
destinos alcanzables a través de la interfaz primaria Gi0/0/0/0. Si no ninguna ruta de reparación disponible,
TI-LFA selecciona una ruta de reparación de protección de enlaces.

Ejemplo 9-17: Configuración de ISIS TI-LFA a nivel de instancia e interfaz

1 enrutador isis 1
2 address-family ipv4 unicast
3 fast-reroute per-prefix tiebreaker node-protecting index 100
4 ¡!
5 interfaz GigabitEthernet0/0/0/0
6 address-family ipv4 unicast
7 fast-reroute per-prefix
8 fast-reroute per-prefix tiebreaker srlg-disjoint index 200
9 fast-reroute per-prefix ti-lfa

El ejemplo 9-18 muestra un ejemplo en el que los desempates se configuran en la instancia ISIS (líneas 3 y 4) y
el desempate predeterminado se configura en la interfaz ISIS (línea 10). Con esta configuración, TI-LFA
calcula una ruta de reparación de protección de enlace para los destinos alcanzables a través de la interfaz
primaria Gi0/0/0/0, ya que la configuración de desempate de la interfaz anula completamente los desempates de
la instancia ISIS.
Ejemplo 9-18: Configuración ISIS TI-LFA - volver a los valores por defecto en la interfaz

1 enrutador isis 1
2 address-family ipv4 unicast
3 fast-reroute per-prefix tiebreaker node-protecting index 100
4 fast-reroute per-prefix tiebreaker srlg-disjoint index 200
5 ¡!
6 interfaz GigabitEthernet0/0/0/0
7 address-family ipv4 unicast
8 fast-reroute per-prefix
9 fast-reroute per-prefix ti-lfa
10 fast-reroute per-prefix tiebreaker por defecto

[Link] Configuración de OSPF

OSPF permite la configuración de reglas de desempate bajo la instancia OSPF y bajo la interfaz OSPF. A
diferencia de ISIS, OSPF fusiona las reglas de desempate configuradas en la instancia OSPF con las reglas de
desempate configuradas en una interfaz OSPF.

Cada criterio de desempate puede desactivarse o activarse con un índice específico. El índice indica la
preferencia de la regla. Un índice más alto significa un desempate más preferido.

Algunos de desempates existentes en OSPF son también aplicables a la protección TI-LFA. Ver Tabla 9-1. La
primera columna en esta tabla especifica el tipo de desempate en el comando de configuración. La segunda
columna contiene una descripción del desempate. La tercera columna indica si el desempate es aplicable para
TI-LFA, y la cuarta columna indica el índice de preferencia por defecto, o "Desactivado" si el desempate está
desactivado por defecto. Si el criterio de desempate configurado es aplicable a TI-LFA y tiene un índice de
preferencia superior al de los criterios de desempate de nodos o SRLG, se considera en primer lugar. Los
criterios de desempate que no se aplican a TI-LFA se ignoran, independientemente de su preferencia. Tenga
en cuenta que el criterio de desempate preferido para TI-LFA es "post-convergencia". Este desempate no es
configurable e indica la preferencia de la ruta de reparación siga la ruta post-convergencia.

Tabla 9-1: Desempate de rutas rápidas OSPF

Tiebreaker Descripción TI-LFA? Por defecto

índice

descendente El camino de reparación pasa por el vecino cuya métrica hacia destino es inferior a la métrica del No (sólo Discapacita
nodo protector (PLR) hacia el mismo destino. para dos

prefijo
per
LFA
direct
o)

lc- La ruta de reparación utiliza una interfaz que está en una tarjeta de línea (LC) diferente. Sí Discapacit
ados
disjuntos

métrica La ruta de reparación utiliza la métrica más baja. Para LFA directo, la métrica representa una distancia Sí 20
de copia al prefijo protegido sobre ruta de reparación calculada. Para RLFA la métrica representa la métrica al
de nodo PQ. Para TI-LFA la métrica representa la métrica al prefijo sobre la ruta de reparación post-
segurida convergencia.
d más
baja

nodo- La ruta de reparación evita el nodo que se está utilizando como siguiente salto para la ruta primaria. Para Sí Discapacit
protector ados
TI-LFApermite calcular rutas de reparación candidatas excluyendo el nodo homólogo.

ruta La ruta de reparación es igual a una de las rutas ECMP. No (sólo 10

primaria para
prefijo
per
directo
ALF)

ruta La ruta de reparación no es una ruta ECMP. No (sólo Discapacit

secundaria ados
para
prefijo
per
directo
ALF)

srlg- La ruta de reparación evita los enlaces locales que comparten el mismo SRLG con el enlace primario. Sí Discapacit
disjoint ados
Para TI-LFA, permite rutas de reparación candidatas excluyendo todos los enlaces locales que
comparten SRLG con el enlace primario.

Los desempates OSPF LFA pueden ser verificados usando el comando show ospf interface. Ver
Ejemplo 9-19. No se configuraron desempates para este ejemplo. La lista de tiebreakers (líneas 21 a 29)
contiene dos tiebreakers no configurables: No Tunnel (Implicit) y Post Convergence Path.
El indica que OSPF siempre da mayor preferencia a una ruta de reparación de interfaz no túnel sobre una ruta
de respaldo de interfaz túnel (esto no está relacionado con la instanciación de una Política SRTE para la ruta
de reparación como se describe en la sección 9.4.3, "Infraestructura TE para rutas de reparación"). Esto último
indica la mayor preferencia por una ruta de reparación adaptada sobre automática la ruta de posconvergencia.
Estos dos criterios de desempate tienen una preferencia superior a 255 y, por lo tanto, siempre se prefieren a
los criterios de desempate configurables que tienen como máximo una preferencia de 255.
Ejemplo 9-19: Verificar los desempates OSPF IPFRR

1 RP/0/0/CPU0:xrvr-1#show ospf interface gigabitEthernet 0/0/0/0

2
3 GigabitEthernet0/0/0/0 está activa, protocolo de línea activo
4 Dirección de Internet [Link]/24, Área 0
5 ID de proceso 1, ID de enrutador [Link], Tipo de red POINT_TO_POINT, Coste: 1
6 El retardo de transmisión es de 1 segundo, Estado POINT_TO_POINT, MTU 1500, MaxPktSz 1500
7 Intervalos de tiempo configurados, Hola 10, Muerto 40, Espera 40, Retransmisión 5
8 Hola en 00:00:05:029
9 Índice 1/1, longitud de cola de inundación 0
10 Siguiente 0(0)/0(0)
11 La última longitud de escaneo de inundación es 1, la máxima es 1
12 El último tiempo de escaneo de inundación es 0 mseg, el máximo es 0 mseg
13 LS Ack List: longitud actual 0, marca de pleamar 4
14 El recuento de vecinos es 1, el recuento de vecinos adyacentes es 1
15 Adyacente con vecino [Link]
16 Suprimir hola para 0 vecino(s)
17 Interfaz multizona El recuento es 0
18 Tipo de ruta rápida Por prefijo
19 Desempate por prefijo IPFRR:
20 Nombre Índice
21 Sin túnel (implícito) 257
22 Métrica más baja 20
23 Ruta principal 10
24 Trayectoria posterior a la convergencia 256
25 Aguas abajo 0
26 Tarjeta de línea Disjunta 0
27 Protección de nodos 0
28 Ruta secundaria 0
29 SRLG Disjuntos 0
30 LFA independiente de la topología activado

Los siguientes ejemplos ilustran algunas configuraciones posibles.

En el Ejemplo 9-20, las reglas de desempate TI-LFA están configuradas bajo la instancia OSPF (líneas 6 y 7).
No se configura ningún desempate bajo la interfaz OSPF. La interfaz hereda los desempates configurados bajo
la . Con esta configuración, TI-LFA prefiere una ruta de reparación de protección del nodo+ SRLG para
destinos alcanzables a través de la interfaz Gi0/0/0/0 si está disponible. Si no disponible dicha ruta de
reparación, se seleccionaría una ruta de reparación de menor preferencia. Las reglas de desempate resultantes
para la interfaz Gi0/0/0/0 se muestran en el Ejemplo 9-21. Las líneas 5 y 6 indican que los desempates de
protección de nodo y SRLG disjoint están habilitados con sus índices de preferencia configurados.
Ejemplo 9-20: Nodo TI-LFA de instancia OSPF y protección SRLG

1 RP/0/0/CPU0:xrvr-12#show running-config router ospf

2 router ospf 1
3 segment-routing mpls
4 fast-reroute per-prefix
5 fast-reroute per-prefix ti-lfa enable
6 fast-reroute per-prefix tiebreaker node-protecting index 200
7 fast-reroute per-prefix tiebreaker srlg-disjoint index 100
8 área 0
9 interfaz GigabitEthernet0/0/0/0
10 red punto a punto
11 ¡!
12 ¡!
¡13 !

Ejemplo 9-21: Nodo TI-LFA de instancia OSPF y protección SRLG - verificación

RP/0/0/CPU0:xrvr-12#show ospf interface Gi0/0/0 | begin tiebreakers IPFRR per-

prefix tiebreakers:
Nombre Índice
Sin túnel (implícito) 257
Protección de nodos 200
SRLG Disjuntos 100
Métrica más baja 20
Ruta principal 10
Trayectoria posterior a la convergencia 256
Aguas abajo 0
Tarjeta de línea Disjunta 0
Ruta secundaria 0
LFA independiente de la topología activado

En el Ejemplo 9-22 se configura una regla de desempate bajo la instancia OSPF (línea 6) y una bajo la interfaz
OSPF (línea 10). Las reglas de desempate se fusionan, como se ve en las líneas 5 y 6 del Ejemplo 9-23. Con
esta configuración TI-LFA selecciona una ruta de reparación de protección SRLG de nodo+ para los destinos
alcanzables a través de la interfaz primaria Gi0/0/0/0. Si no ninguna ruta de reparación disponible, TI-LFA
selecciona, en orden de preferencia, una ruta de reparación de protección SRLG, una ruta de reparación de
protección de nodo o una ruta de reparación de protección de enlace.
Ejemplo 9-22: Protección de nodo TI-LFA de instancia OSPF y protección SRLG de interfaz

1 RP/0/0/CPU0:xrvr-12#show running-config router ospf

2 router ospf 1
3 segment-routing mpls
4 fast-reroute per-prefix
5 fast-reroute per-prefix ti-lfa enable
6 fast-reroute per-prefix tiebreaker node-protecting index 100
7 área 0
8 interfaz GigabitEthernet0/0/0/0
9 red punto a punto
10 fast-reroute per-prefix tiebreaker srlg-disjoint index 200
11 ¡!
12 ¡!
¡13 !

Ejemplo 9-23: Protección de nodo TI-LFA de instancia OSPF y protección SRLG de interfaz - verificación

RP/0/0/CPU0:xrvr-12#show ospf interface Gi0/0/0 | begin tiebreakers IPFRR per-

prefix tiebreakers:
Nombre Índice
Sin túnel (implícito) 257
SRLG Disjuntos 200
Protección de nodos 100
Métrica más baja 20
Ruta principal 10
Trayectoria posterior a la convergencia 256
Aguas abajo 0
Tarjeta de línea Disjunta 0
Ruta secundaria 0
LFA independiente de la topología activado

El ejemplo 9-24 muestra un ejemplo de configuración donde los tiebreakers están configurados bajo la instancia
OSPF (líneas 6 y 7) y deshabilitados bajo la interfaz OSPF (líneas 11 y 12). Con esta configuración TI-LFA
calcula una ruta de reparación de protección de enlace para destinos alcanzables a través de la interfaz primaria
Gi0/0/0/0 de acuerdo con las reglas de desempate resultantes para la interfaz. Las reglas de desempate
resultantes para la interfaz se muestran en el Ejemplo 9-25.
Ejemplo 9-24: Instancia OSPF TI-LFA protección deshabilitada para la interfaz

1 RP/0/0/CPU0:xrvr-12#show running-config router ospf

2 router ospf 1
3 segment-routing mpls
4 fast-reroute per-prefix
5 fast-reroute per-prefix ti-lfa enable
6 fast-reroute per-prefix tiebreaker node-protecting index 100
7 fast-reroute per-prefix tiebreaker srlg-disjoint index 200
8 área 0
9 interfaz GigabitEthernet0/0/0/0
10 red punto a punto
11 fast-reroute per-prefix tiebreaker node-protecting disable
12 fast-reroute per-prefix tiebreaker srlg-disjoint disable
13 ¡!
14 ¡!
¡15 !

Ejemplo 9-25: Instancia OSPF TI-LFA protección desactivada para interfaz - verificación

RP/0/0/CPU0:xrvr-12#show ospf interface Gi0/0/0 | begin tiebreakers IPFRR per-

prefix tiebreakers:
Nombre Índice
Sin túnel (implícito) 257
Métrica más baja 20
Ruta principal 10
Trayectoria posterior a la convergencia 256
SRLG Disjuntos 0
Protección de nodos 0
Aguas abajo 0
Tarjeta de línea Disjunta 0
Ruta secundaria 0
LFA independiente de la topología activado

[Link] Ejemplo de protección de nodos

La protección de nodos TI-LFA se ilustra utilizando la topología de red de la Figura 9-14. Nodo1 está
configurado para proteger el tráfico al destino Nodo6 contra fallos de nodo.
Figura 9-14: Protección del nodo TI-LFA

La ruta primaria en el Nodo1 hacia el destino Nodo6 atraviesa el Nodo2. El cálculo TI-LFA para el nodo de
destino 6 es el siguiente:

Elimina el nodo de siguiente salto en el enlace primario al Nodo6 (Nodo2) de la topología y calcula el SPT
en la topología resultante. Esto nos da la ruta post-convergencia desde el Nodo1 al Nodo6:
{Nodo5, Nodo4, Nodo3, Nodo7, Nodo8, Nodo9, Nodo10, Nodo6}. Esta ruta se denomina "Ruta de
postconvergencia" en la ilustración.

Nodo10 está en el espacio Q (Nodo10 puede enviar un paquete a Nodo6 sin riesgo de que este paquete
fluya de vuelta a través del protegido Nodo2).

Los espacios P y Q no se cruzan y no son adyacentes; no hay ningún nodo que esté tanto en el espacio P
como en el espacio Q ni hay ningún par de nodos P y Q adyacentes. TI-LFA calcula una ruta sin bucles a lo
largo de la ruta posterior a la convergencia para salvar la distancia entre el espacio P y el espacio Q. En este
ejemplo
la ruta consta de un segmento de adyacencia y dos segmentos de prefijo. El segmento de adyacencia lleva
los paquetes del Nodo4 al Nodo3. A continuación, los segmentos de prefijo dirigen los paquetes por un
camino sin bucles hasta el Nodo10 a través del Nodo8. Los caminos más cortos desde el Nodo3 al Nodo8
y desde el Nodo8 al Nodo10 no atraviesan el Nodo2 y siguen el camino posterior a la convergencia.

El PLR Nodo1 empuja la lista de segmentos {Prefix-SID(Nodo4), Adjacency-SID(R4-R3), Prefix-

SID(Nodo8), Prefix-SID(Nodo10)} en los paquetes reparados al destino Nodo6 y los reenvía por
interfaz al Nodo5.

El comportamiento anterior se aplica por prefijo. La ruta de post-convergencia se calcula para cada prefijo de
destino, y la ruta de reparación TI-LFA para cada destino se adapta sobre la ruta de post-convergencia a ese
destino. Nótese que la descripción anterior es una descripción conceptual de los cálculos y no del algoritmo
real. El algoritmo TI-LFA real es propietario (comportamiento local que no está en el ámbito de la
estandarización del IETF) y se escala extremadamente bien.

El Ejemplo 9-26 muestra la ruta de reparación TI-LFA calculada por ISIS en Nodo1 para la topología de la
Figura 9-14. La salida muestra que es una ruta de reparación de protección de nodo (línea 5). La salida muestra
que es una ruta de reparación de protección de nodo (línea 5). Los segmentos de la ruta de reparación son
como se ilustra en la Figura 9-14. Note que los segmentos de prefijo en la lista están etiquetados como nodo
P (líneas 7, 9-10) y el segmento de adyacencia está etiquetado como nodo Q (línea 8). Un nodo P puede ser
alcanzado desde el nodo anterior sin atravesar el nodo protegido, mientras que un nodo Q puede alcanzar el
siguiente nodo de la ruta sin atravesar el nodo protegido. La lista de segmentos de la ruta de reparación
contiene más de tres segmentos, por lo que ISIS instala dinámicamente una política SRTE, tunnel-te32783 en
este ejemplo (línea 6). Esta implicación de la infraestructura TE se trata con más detalle en la sección 9.4.3,
"Infraestructura TE para rutas de reparación".
Ejemplo 9-26: Nodo ISIS TI-LFA que protege la ruta de reparación

1 RP/0/0/CPU0:xrvr-1#show isis fast-reroute [Link]/32 detail

2
3L2 [Link]/32 [20/115] prioridad media
4 vía [Link], GigabitEthernet0/0/0/1, xrvr-2, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (nodo), vía [Link], GigabitEthernet0/0/0 xrvr-5, SRGB
Base: 16000, Peso: 0
6 Túnel de respaldo: tunnel-te32783
7 Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
8 Nodo Q: xrvr-3.00 [[Link]], Etiqueta: 30403
9 Nodo P: xrvr-8.00 [[Link]], Etiqueta: 16008
10 Nodo P: xrvr-10.00 [[Link]], Etiqueta: 16010
11 Etiqueta prefijo: 16006
12 P: No, TM: 110, LC: No, NP: No, D: No, SRLG: No
13 src xrvr-6.00-00, [Link], prefijo-SID índice 6, R:0 N:1 P:0 E:0 V:0 L:0

La ruta de reparación TI-LFA computada por OSPF en Nodo1 para la misma topología se muestra en el
Ejemplo 9-27. La ruta es de protección de nodo (ver línea 16) y usa la lista de segmentos ilustrada en la
Figura 9-14. La ruta está protegida por nodos (ver línea 16) y usa la lista de segmentos como se ilustra en la
Figura 9-14. Los nodos en la ruta de reparación están etiquetados con nodo P y nodo Q (líneas 10-13). Los
nodos en la ruta de reparación están etiquetados con nodo P y nodo Q (líneas 10-13), igual que para
ISIS. OSPF instala una política SRTE ya que la ruta de reparación requiere la imposición de más de tres
etiquetas, tunnel-te32781 en este ejemplo (línea 14).

Ejemplo 9-27: Nodo OSPF TI-LFA que protege la ruta de reparación

1 RP/0/0/CPU0:xrvr-1#show ospf routes [Link]/32 backup-path detail

2
3 Entrada de ruta OSPF para [Link]/32
4 Tipo de ruta: Intra-area
5 Última actualización: 30 Jun 19:58:13.752
6 Métrica: 21
7 Prioridad SPF: 4, Versión SPF: 44
8 Versión RIB: 0, Fuente: Desconocido
9 [Link], desde [Link], vía GigabitEthernet0/0/0/1, path-id 1
10 *Ruta de copia de seguridad: TI-LFA, Lista de reparación: *
11 P Nodo: [Link] Etiqueta: 16004
12 Q Nodo: [Link] Etiqueta: 30403
13 P Nodo: [Link] Etiqueta: 16008
14 P Nodo: [Link] Etiqueta: 16010
15 Túnel de reserva: tunnel-te32781
16 [Link], desde [Link], vía GigabitEthernet0/0/0/0, mapa de bits protegido
0000000000000001
17 Atributos: Métrica: 111, Nodo Proteger, SRLG Disjuntos

La entrada cef para el prefijo loopback [Link]/32 del Nodo6 en el Nodo1 se muestra en el Ejemplo 9-28. En el
ruta de reparación (backup), Nodo1 impone la etiqueta Prefix-SID 16006 (línea 14) y se dirige a tunnel-te32781
(línea 10).

Ejemplo 9-28: Nodo TI-LFA protegiendo ruta de reparación en CEF

1 RP/0/0/CPU0:xrvr-1#show cef [Link]/32

2 [Link]/32, versión 1295, interno 0x1000001 0x81 (ptr 0xa1434d74) [1], 0x0
(0xa13ffb00), 0xa28 (0xa171c12c)
3 Actualizado Jul 1 08:50:35.947
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 1
6 via [Link]/32, GigabitEthernet0/0/0/1, 6 dependencias, peso 0, clase 0, protegido
[flags 0x400]
7 path-idx 0 bkup-idx 1 NHID 0x0 [0xa0e84360 0x0]
8 siguiente salto [Link]/32
9 etiqueta local 16006 etiquetas impuestas {16006}
10 via [Link]/32, tunnel-te32781, 6 dependencias, peso 0, clase 0, backup [flags
0x300]
11 path-idx 1 NHID 0x0 [0xa110d934 0x0]
12 siguiente salto [Link]/32
13 adyacencia local
14 etiqueta local 16006 etiquetas impuestas {16006}

La entrada de reenvío MPLS para la etiqueta Prefijo-SID 16006 en el Nodo1 se muestra en el Ejemplo 9-29. La
ruta de respaldo se muestra en las líneas 14 a 19. La etiqueta saliente es 16006 y la interfaz saliente es tunnel-
te32781 (línea 14).
Ejemplo 9-29: Nodo TI-LFA protegiendo ruta de reparación en MPLS

1 RP/0/0/CPU0:xrvr-1#show mpls forwarding labels 16006 detail

2 Local Saliente Prefijo Saliente Salto siguiente Bytes
3 Etiqueta Etiqueta o ID Interfaz Conmutado
4
5 16006 16006 SR Pfx (idx 6) Gi0/0/0/1 [Link] 0
6 Actualizado: Jul 1 08:50:35.627
7 Banderas de ruta: 0x400 [ BKUP-IDX:1 (0xa0e84360) ]
8 Versión: 1295, Prioridad: 1
9 Pila de etiquetas (Arriba -> Abajo): { 16006 }
10 NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 1, Peso: 0
11 MAC/Encaps: 14/18, MTU: 1500
12 Paquetes conmutados: 0
13
14 16006 SR Pfx (idx 6) tt32781 punto2punto 0
(!)
15 Actualizado: Jul 1 08:50:35.627
16 Banderas de ruta: 0x300 [ IDX:1 BKUP, NoFwd ]
17 Pila de etiquetas (Arriba -> Abajo): { }
18 MAC/Encaps: 0/0, MTU: 0
19 Paquetes conmutados: 0
20 Matriz de tráfico Paquetes/Bytes conmutados: 0/0

La entrada de reenvío de la Política SRTE para tunnel-te32781 en Nodo1 se muestra en el Ejemplo 9-30. La
interfaz saliente y el siguiente salto están en la salida de la línea 5. La interfaz saliente y el siguiente salto están
en la salida de la línea 5. La pila de etiquetas impuesta está listada en la línea 8. La pila de etiquetas impuesta
aparece en la línea 8.

Ejemplo 9-30: Entrada de reenvío automático de política SRTE

1 RP/0/0/CPU0:xrvr-1#show mpls for tunnels 32781 detail

2 Túnel Salida Saliente Siguiente salto Bytes
3 Nombre Etiqueta Interfaz Conmutado
4
5 tt32781 (SR) 16004 Gi0/0/0/0 [Link] 0
6 Actualizado: Jul 1 08:50:35.607
7 Versión: 561, Prioridad: 2
8 Pila de etiquetas (Arriba -> Abajo): { 16004 30403 16008 16010 }
9 NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Peso: 0
10 MAC/Encaps: 14/30, MTU: 1500
11 Paquetes conmutados: 0
12
13 Nombre de interfaz: tunnel-te32781, Interface Handle: 0x00001280, Etiqueta local: 24004
14 Clase de reenvío: 0, Peso: 0
15 Paquetes/Bytes conmutados: 0/0
[Link] Ejemplo de protección SRLG
La protección TI-LFA SRLG se ilustra utilizando la topología de red de la Figura 9-15. El nodo2 es el nodo de
protección (PLR) en este ejemplo. El Nodo2 es el nodo protector (PLR) en este ejemplo. Las interfaces del
Nodo2 al Nodo6 y al Nodo9 comparten el mismo SRLG 1111. Este SRLG es indicado en la ilustración por un
cuadrado en el enlace. Nodo2 está configurado para proteger el tráfico al destino Nodo6 contra fallos SRLG.
La implementación de Cisco IOS XR en momento de escribir este libro considera los fallos SRLG locales: no
se consideran los fallos de enlaces remotos que son miembros del mismo SRLG.

Figura 9-15: Protección SRLG local TI-LFA

La ruta primaria en Nodo2 hacia el destino Nodo6 es a través del enlace directo entre estos dos nodos. El
cálculo TI-LFA en el Nodo2 para el Nodo de destino 6 es el siguiente:

Elimina de la topología los enlaces locales que comparten un mismo SRLG con el enlace primario al Nodo6
y calcula el SPT en la topología resultante. El enlace al Nodo9 tiene el mismo SRLG que el enlace de la
ruta primaria (enlace al Nodo6). Esto nos da la ruta post-convergencia del Nodo2 al Nodo6: {Nodo3,
Nodo7, Nodo8, Nodo9, Nodo10, Nodo6}. Este camino está etiquetado como "Camino postconvergencia"
en la ilustración.
El Nodo8 está en el espacio P extendido (el Nodo2 puede enviar un paquete destinado al Nodo8 en la
interfaz saliente al Nodo3 sin ningún riesgo de que ese paquete fluya de vuelta a través de un enlace con
un SRLG protegido). El Nodo8 no está en el espacio Q; un paquete destinado al Nodo6 que se dirija al
Nodo8 puede atravesar un enlace del SRLG protegido: enlace Nodo9-Nodo2. El espacio P (ampliado) y el
espacio Q se indican en la ilustración.

Nodo10 está en el espacio Q (Nodo10 puede enviar un paquete a Nodo6 sin ningún riesgo de que este
paquete atraviese un enlace con un SRLG protegido).

Los espacios P y Q no se cruzan y no son adyacentes. TI-LFA calcula una ruta sin bucles a lo largo de la ruta
posterior a la convergencia para salvar la distancia entre el espacio P y el espacio Q. En este ejemplo, la
ruta consiste en un segmento de prefijo y un segmento de prefijo. En este ejemplo, la ruta consta de un
segmento de prefijo. El segmento de prefijo dirige los paquetes por un camino sin bucles desde el Nodo8 al
Nodo10. El camino más corto desde el Nodo8 al Nodo10 no atraviesa ningún enlace del SRLG protegido y
se realiza a lo largo del camino post-convergencia.

El PLR Nodo2 empuja la lista de segmentos {Prefix-SID(Nodo8), Prefix-SID(Nodo10)} en los paquetes

reparados al destino Nodo6 y los reenvía por interfaz al Nodo3.

El Ejemplo 9-31 muestra la ruta de reparación TI-LFA calculada por ISIS para el destino [Link]/32 en el
Nodo2 para la topología de la Figura 9-15. La salida muestra que es una ruta de reparación de protección SRLG
(línea 5). La salida muestra que es una ruta de reparación de protección SRLG (línea 5). Los segmentos de la
ruta de reparación son como se ilustra en la Figura 9-15. La ruta de reparación contiene dos segmentos de
prefijo: al Nodo8 (16008) y al Nodo10 (16010). El Nodo2 también intercambia o impone la etiqueta Prefijo-
SID del Nodo6 de destino (16006). ISIS no instancia una Política SRTE ya que el tamaño de la pila de etiquetas
es inferior a cuatro (esta plataforma soporta hasta 3 etiquetas).
Ejemplo 9-31: ISIS TI-LFA local SRLG que protege la ruta de reparación

1 RP/0/0/CPU0:xrvr-2#show isis fast-reroute [Link]/32 detail

2
3L2 [Link]/32 [10/115] prioridad media
4 vía [Link], GigabitEthernet0/0/0/2, xrvr-6, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (srlg), vía [Link], GigabitEthernet0/0/0 xrvr-3, SRGB
Base: 16000, Peso: 0
6 Nodo P: xrvr-8.00 [[Link]], Etiqueta: 16008
7 Nodo P: xrvr-10.00 [[Link]], Etiqueta: 16010
8 Etiqueta prefijo: 16006
9 P: No, TM: 60, LC: No, NP: No, D: No, SRLG: No
10 src xrvr-6.00-00, [Link], prefijo-SID índice 6, R:0 N:1 P:0 E:0 V:0 L:0

La ruta de reparación TI-LFA computada por OSPF en Nodo2 para la misma topología se muestra en el
Ejemplo 9-32. La ruta es de protección SRLG (SRLG Disjoint) (ver línea 14) y usa la lista de segmentos
como se ilustra en la Figura 9-15. Los nodos en la ruta de reparación son todos etiquetados como nodo P (líneas
11-12). Los nodos en la ruta de reparación están todos etiquetados como nodo P (líneas 11-12), igual que
para ISIS.

Ejemplo 9-32: OSPF TI-LFA local SRLG protegiendo ruta de reparación

1 RP/0/0/CPU0:xrvr-2#show ospf routes [Link]/32 backup-path

2
3 Tabla de topología para ospf 1 con ID [Link]
4
5 Códigos: O - Intra área, O IA - Inter área
6 O E1 - Tipo externo 1, O E2 - Tipo externo 2
7 O N1 - NSSA externo tipo 1, O N2 - NSSA externo tipo 2
8
9 O [Link]/32, métrico 11
10 [Link], desde [Link], vía GigabitEthernet0/0/0/2, path-id 1
11 Ruta de copia de seguridad: TI-LFA,
12 Lista de reparación: Nodo P: [Link] Etiqueta: 16008
13 Nodo P: [Link] Etiqueta: 16010
14 [Link], desde [Link], vía GigabitEthernet0/0/0/0, mapa de bits protegido
0000000000000001
15 Atributos: Métrica: 61, SRLG Disjuntos

En el Ejemplo 9-33 se muestra la entrada cef para el prefijo loopback [Link]/32 del Nodo6 en el Nodo2. En la
ruta primaria el Nodo2 no impone ninguna etiqueta (ImplNull en la línea 15) ya que el Nodo6 de destino
está conectado directamente (Penultimate Hop Popping, PHP). En la ruta de reparación (backup) Nodo2
impone o intercambia la etiqueta Prefix-SID 16006, e impone las etiquetas 16008 y 16010 (línea 10). El
Nodo2 entonces dirige los paquetes en la ruta de reparación al Nodo3 (vía [Link], Gi0/0/0/0) (línea 6).
Ejemplo 9-33: TI-LFA SRLG protegiendo ruta de reparación en CEF

1 RP/0/0/CPU0:xrvr-2#show cef [Link]/32

2 [Link]/32, versión 1759, interno 0x1000001 0x81 (ptr 0xa14564f4) [1], 0x0
(0xa143b92c), 0xa28 (0xa1750184)
3 Actualizado Jul 4 10:44:56.242
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 1
6 via [Link]/32, GigabitEthernet0/0/0/0, 26 dependencias, peso 0, clase 0, backup
(remoto) [flags 0x8300]
7 path-idx 0 NHID 0x0 [0xa10f3bd4 0x0]
8 siguiente salto [Link]/32, nodo P [Link], nodo Q [Link]
9 adyacencia local
10 etiqueta local 16006 etiquetas impuestas {16008 16010 16006}
11 via [Link]/32, GigabitEthernet0/0/0/2, 26 dependencias, peso 0, clase 0, protegido
[flags 0x400]
12 path-idx 1 bkup-idx 0 NHID 0x0 [0xa0e699dc 0xa0e695c8]
13 siguiente salto [Link]/32
14 etiqueta local 16006 etiquetas impuestas {ImplNull}

En el Ejemplo 9-34 se muestra la entrada de reenvío MPLS para la etiqueta Prefijo-SID 16006 en el Nodo2. La
ruta de reparación se muestra en las líneas 14 a 21. La pila de etiquetas salientes es {16008 16010 16006 }
(ordenada Arriba → Abajo) y la interfaz saliente es Gi0/0/0 vía [Link].
Ejemplo 9-34: Nodo TI-LFA protegiendo ruta de reparación en MPLS

1 RP/0/0/CPU0:xrvr-2#show mpls forwarding labels 16006 detail

2 Local Saliente Prefijo Saliente Salto Bytes
siguiente
3 Etiqueta o ID Interfaz Conmutado
4
5 16006 Pop SR Pfx (idx 6) Gi0/0/0/2 [Link] 0
6 Actualizado: Jul 4 10:32:35.622
7 Banderas de ruta: 0x400 [ BKUP-IDX:0 (0xa0e699dc) ]
8 Versión: 1759, Prioridad: 1
9 Pila de etiquetas (Arriba -> Abajo): { Imp-Null }
10 NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Peso: 0
11 MAC/Encaps: 14/14, MTU: 1500
12 Paquetes conmutados: 0
13
14 16008 SR Pfx (idx 6) Gi0/0/0/0 [Link] 0
(!)
15 Actualizado: Jul 4 10:32:35.622
16 Banderas de ruta: 0x8300 [ IDX:0 BKUP, NoFwd ]
17 Versión: 1759, Prioridad: 1
18 Pila de etiquetas (Arriba -> Abajo): { 16008 16010 16006 }
19 NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Peso: 0
20 MAC/Encaps: 14/26, MTU: 1500
21 Paquetes conmutados: 0
22 (!): FRR pura copia de seguridad
23

24 Matriz de tráfico Paquetes/Bytes conmutados: 0/0

9.5.3 Protección de hecho de los nodos

TI-LFA ofrece una protección de nodos garantizada en cualquier topología. Sin embargo, una protección de
nodo garantizada puede no ser siempre la mejor opción. Dado que los fallos de enlace se producen con más
frecuencia que los fallos de nodo, puede que no sea una buena idea utilizar la ruta de reparación de protección
de nodo para cada fallo. Recuerde que el nodo protector no distingue entre tipos de fallos; sólo se instala una
ruta de reparación para cada destino y ésa es la que se utiliza para cualquier fallo. Si se instala una ruta de
reparación protectora del nodo y sólo falla el enlace mientras el nodo sigue funcionando, se seguirá utilizando
la ruta de reparación protectora del nodo. En tal casola ruta de reparación no siempre sigue la ruta real
posterior a la convergencia, ya que el fallo real difiere del fallo previsto en cálculo de la ruta de reparación.
Esto es cierto a menos que la ruta de reparación de protección de enlace también proteja contra fallos de nodo.
Por ejemplo, en la Figura 9-16, la ruta de reparación de protección de enlace en el PLR Nodo1 para el destino
Nodo3 también protege contra el fallo del Nodo2, ya la ruta de reparación no atraviesa el Nodo2.
Figura 9-16: La ruta de reparación que protege el enlace también protege el nodo

Las simulaciones indican que las rutas de reparación no garantizadas que protegen los nodos proporcionan de
hecho protección de nodos en muchos . Esto significa que la protección simultánea de enlaces de distintos
nodos puede proporcionar protección ante el fallo de un nodo. Un ejemplo puede aclarar más las cosas. Todos
los nodos de la topología de la Figura 9-17 tienen activada la protección de enlace. La métrica de enlace IGP
por defecto es 30. La ilustración muestra varios enlace individuales en diferentes nodos y la ruta de reparación
que el nodo afectado proporciona hacia el destino Nodo3. El fallo del enlace Nodo1-Nodo2 en la Figura 9-17
(a) activa la protección de enlace en Nodo1. El fallo de enlace Nodo4-Nodo2 en la Figura 9-17 (b) activa la
protección de enlace en el Nodo4. Y el fallo de enlace Nodo5-Nodo2 en la Figura 9-17 (c) activa la protección
de enlace en el Nodo5. Los caminos de reparación individuales de protección de enlace en (a) y (b) no son de
protección de nodo ya que todos atraviesan el Nodo2. Dado que por fallo del Nodo2, todos los enlaces del
Nodo2 fallan juntos, cada fallo de enlace activa la protección de enlace en el nodo afectado y el resultado es una
protección de nodo de facto, como se ve en la Figura 9-17 (d). La ruta de reparación del Nodo1 para el tráfico
destinado al Nodo3 va hacia el Nodo4. Cuando el tráfico llega al Nodo4, el Nodo4 dirige el tráfico al Nodo5 ya
que la ruta de reparación del Nodo4 para el destino Nodo3 va hacia el Nodo5. Cuando el tráfico destinado al
Nodo3 llega al Nodo5, el Nodo5 dirige el tráfico al Nodo3 ya que la ruta de reparación del Nodo5 para el
destino Nodo3 va al Nodo3.

El mismo razonamiento puede aplicarse a la protección de los SRLG.

Figura 9-17: Protección de nodo de facto

La protección de facto depende de la topología. Se requiere un estudio topológico o una simulación IPFRR para
averiguar si la protección de facto es aplicable. La protección de facto se beneficia de la ruta de reparación
óptima para los fallos de enlace más frecuentes, al tiempo que proporciona protección para los fallos de nodo o
SRLG menos frecuentes.

"La protección de todos los tipos de servicios de red en cualquier topología a través de TI-LFA ha sido uno de los primeros y
principales casos de uso que ha impulsado el despliegue de SR entre los operadores. El factor clave ha sido la sencillez operativa y su
naturaleza automatizada: en muchos casos basta con un único comando para activar la función en las interfaces deseadas. El otro
aspecto más útil ha sido la previsibilidad de la ruta de backup (a través de la ruta de postconvergencia), que ha permitido realizar una
planificación de la capacidad con simulaciones de fallos utilizando herramientas como Cisco WAE. La calidad de la experiencia
también ha mejorado, ya que no hay que conmutar el tráfico de un lado a otro, de la ruta original a la ruta de reparación y luego a la
ruta de postconvergencia. La ruta de respaldo que es posterior a la convergencia, que viene determinada por las métricas IGP
utilizadas, permite evitar la congestión en la mayoría de los fallos con una planificación adecuada de la capacidad."

- Ketan Talaulik ar
9.6 Direccionamiento de los nodos P y PQ
Para utilizar un nodo remoto como salto intermedio (nodo P o nodo PQ) en la ruta de reparación TI-LFA, el
nodo de protección debe obtener un Prefijo-SID para ese nodo de la base de datos de estado de enlace. Del
mismo modo, si se utiliza LFA Remoto, el nodo de protección necesita averiguar la dirección IP del nodo PQ
para establecer la sesión LDP objetivo. Lógicamente, el nodo de protección podría elegir cualquier prefijo de
nodo alcanzable (prefijo con el indicador N activado) originado por el nodo P y utilizar el Prefijo-SID de ese
prefijo.
En su lugar, la implementación de Cisco IOS-XR utiliza direcciones predeterminadas, como se explica en esta
sección. Dado que se trata de una elección de comportamiento local en el nodo PLR, es específica de la
implementación.

DESTACAR

Se recomienda encarecidamente configurar explícitamente el "router-id" en cada nodo IGP como una de las direcciones loopback del
host que también son anunciadas por el IGP y provisionadas con Prefix-SID; esto se convierte en el Node-SID por defecto y preferido
para TI-LFA y elimina ambigüedades y asegura rutas de reparación consistentes.

9.6.1 Direccionamiento de los nodos P y PQ en ISIS

ISIS selecciona el primer prefijo de host que encuentra del siguiente conjunto, en orden de preferencia:

1. ISIS router-id (TLV 134) Esta dirección se configura como ISIS router-id o TE router-id

2. Dirección de interfaz IP ISIS (TLV 132) que anuncia las direcciones IP de una o más interfaces de este
nodo. Cisco IOS XR anuncia un único TLV de dirección de interfaz por familia de direcciones. Otros
vendedores pueden anunciar múltiples de estos. La dirección en este TLV es seleccionada
automáticamente por el anunciante como la dirección de la interfaz loopback de menor número
anunciada en ISIS, normalmente Loopback0, o la dirección de interfaz no loopback numéricamente más
baja anunciada en ISIS si no se anuncian interfaces loopback.

3. El prefijo de host numéricamente más alto anunciado por ese nodo; se trata realmente de una opción
alternativa, ya que el nodo protector no siempre puede saber si este prefijo es local nodo anunciante.

Si el prefijo seleccionado de esta lista no tiene un Prefijo-SID, entonces ISIS no considera otra dirección de la
lista anterior, pero se asume que el nodo no tiene un Prefijo-SID alcanzable. Por lo tantoes importante
asegurarse de que se configura un Prefijo-SID para la dirección preferida de la lista anterior.
lista. Si el TE Router-id está configurado, entonces el prefijo TE Router-id debe tener un Prefijo-SID asociado.
Si no hay configurado ningún TE Router-id, entonces el prefijo de la interfaz loopback numerada más baja
debe tener un Prefijo-SID asociado. Si se configuran múltiples loopbacks en el nodo la interfaz loopback
numerada más baja no tiene un Prefix-SID configurado, entonces el prefijo loopback que tiene un Prefix-SID
asociado debe configurarse como TE Router-id.

Como ejemplo, un nodo tiene la configuración que se muestra en el Ejemplo 9-35. Note que no ha
configurado router-id y que Loopback0 no tiene Prefix-SID configurado. Basado en esta configuración y el
orden de preferencia anterior, un nodo remoto seleccionaría [Link] para alcanzar este nodo ya que esta es la
dirección en el TLV de dirección de interfaz IP (dirección IP nombrada en la salida). Ver línea 12 del
anuncio ISIS en el Ejemplo 9-36. Sin embargo, como el prefijo [Link]/32 no tiene un Prefijo-SID asociado, el
nodo protector asume que este nodo no tiene un Prefijo-SID.
Ejemplo 9-35: TLV de dirección de interfaz IP ISIS - configuración

interfaz Loopback0
dirección ipv4 [Link] [Link]
dirección ipv6 2001::1:1:1:1/128
¡!
interfaz Loopback1
dirección ipv4 [Link] [Link]
dirección ipv6 2001::1:0:0:1/128
¡!
enrutador isis 1
is-type sólo nivel 2
net 49.0001.0000.0000.0001.00
address-family ipv4 unicast
metric-style wide
segment-routing mpls
¡!
address-family ipv6 unicast
metric-style wide
segment-routing mpls
¡!
interfaz Loopback0
pasiva
address-family ipv4 unicast
¡!
address-family ipv6 unicast
¡!
¡!
interfaz Loopback1
pasiva
address-family ipv4 unicast
prefix-sid absolute 16001
¡!
address-family ipv6 unicast
prefix-sid absolute 20001
¡!
¡!
Ejemplo 9-36: Anuncio de TLV de dirección de interfaz IP ISIS

1 RP/0/CPU0:xrvr-1#show isis database verbose xrvr-1

2
3 IS-IS 1 (Nivel-2) Base de datos de estado de enlace
4 LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
5 xrvr-1.00-00 * 0x00000003 0x01a2 1144 0/0/0
6 Dirección de área: 49.0001
7 NLPID: 0xcc
8 NLPID: 0x8e
9 MT: Estándar (IPv4 Unicast)
10 MT: IPv6 Unicast 0/0/0
11 Nombre de host: xrvr-1
12 Dirección IP: [Link]
13 Dirección IPv6: 2001::1:1:1:1
14 Router Cap: [Link], D:0, S:0
15 Enrutamiento de segmentos: I:1 V:1, SRGB Base: 16000 Rango: 8000
16 Métrica: 0 Extensión IP 1.0 0.1/32
17 Índice Prefijo-SID: 101, Algoritmo:0, R:0 N:1 P:0 E:0 V:0 L:0
18 Métrica: 0 Extensión IP 1.1 1.1/32
19 Métrica: 0 MT (IPv6 Unicast) IPv6 2001::1:0:0:1/128
20 Índice Prefijo-SID: 4101, Algoritmo:0, R:0 N:1 P:0 E:0 V:0 L:0
21 Métrica: 0 MT (IPv6 Unicast) IPv6 2001::1:1:1:1/128
22
23 Recuento total de LSP de nivel 2: 1 Recuento de LSP locales de nivel 2 1

Para , el operador puede configurar un router-id. Configurar un router-id TE también requiere habilitar la
infraestructura TE y anunciar los atributos de enlace TE. Otra opción es configurar el router-id como ISIS
router-id. Ambas opciones de configuración resultan en la publicidad de TLV 134, pero la última no requiere
la publicidad de los atributos de enlace TE. La configuración se muestra en el Ejemplo 9-37 y el anuncio ISIS
resultante en el Ejemplo 9-38. Con esta configuración el nodo protector selecciona el prefijo [Link]/32 que
tiene un Prefijo-SID asociado.
Ejemplo 9-37: ISIS router-id - configuración

Ejemplo 9-38: Anuncio ISIS router-id

RP/0/0/CPU0:xrvr-1#show isis database verbose xrvr-1

IS-IS 1 (Nivel-2) Base de datos de estado de enlace

LSPID LSP Seq Num LSP Checksum Tiempo de ATT/P/OL
espera LSP
xrvr-1.00-00 * 0x00000009 0x54fe 1195 0/0/0
Dirección de área: 49.0001
NLPID: 0xcc
NLPID: 0x8e
MT: Estándar (IPv4 Unicast)
MT: IPv6 Unicast 0/0/0

Nombre de host: xrvr-1

Dirección IP: [Link]
Dirección IPv6: 2001::1:1:1:1
ID de router: [Link]
ID de enrutador IPv6: 2001::1:0:0:1
Router Cap: [Link], D:0, S:0
Enrutamiento de segmentos: I:1 V:1, Base SRGB: Alcance: 8000
16000
Métrica: 0 Extensión IP [Link]/32
Índice Prefijo-SID: 101, Algoritmo:0, R:0 N:1 P:0 E:0 V:0 L:0
Métrica: 0 Extensión IP [Link]/32
Métrica: 0 MT (IPv6 Unicast) IPv6 2001::1:0:0:1/128 Índice
Prefijo-SID: 4101, Algoritmo:0, R:0 N:1 P:0 E:0 V:0 L:0
Métrica: 0 MT (IPv6 Unicast) IPv6 2001::1:1:1:1/128

Recuento total de LSP de nivel 2: 1 Recuento local de LSP de

nivel 2 1

9.6.2 Direccionamiento de nodos P y PQ en OSPF

Para alcanzar un nodo P TI-LFA (o nodo PQ) desde el nodo protector, OSPF prefiere el router-id OSPF del
nodo P si es un prefijo alcanzable. De lo contrario, OSPF selecciona la dirección de host alcanzable
numéricamente más alta con la bandera N activada que es anunciada por el nodo P. Si el prefijo seleccionado
no tiene prefijo, OSPF selecciona la dirección de host alcanzable numéricamente más alta con la bandera N
activada. Si el prefijo seleccionado no tiene Prefijo-SID entonces el nodo protector asume que el nodo P no
anuncia un Prefijo-SID..
9.7 Protección de segmentos de adyacencia
TI-LFA protege tanto los segmentos de prefijo como los segmentos de adyacencia. Para proteger un segmento de
adyacencia,
TI-LFA dirige los paquetes por una ruta de reparación hasta el nodo situado en el extremo remoto del enlace, el
nodo adyacente.
[ 4] A partir de ahí los paquetes reanudan su camino normal. La siguiente lógica se utiliza para proteger un
segmento de adyacencia:

1. Si el enlace del Segmento de Adyacencia está en el camino más corto hacia el vecino de la adyacencia,
entonces el camino de reparación para proteger el Segmento de Adyacencia es igual al camino de
reparación del Nodo-SID del vecino.

2. Si el enlace del Segmento de Adyacencia no está en el camino más corto hacia el vecino de la
adyacencia, entonces el camino de reparación para proteger el Segmento de Adyacencia es igual al
camino primario hacia el Nodo-SID del vecino.

Cualquier desempate que esté configurado para influir en la ruta de reparación del Node-SID del vecino
también influye en la ruta de reparación del Adjacency-SID, ya que se utiliza la misma ruta de reparación. Si
la ruta de reparación del Node-SID vecino requiere una Política SRTE (ya que el número de etiquetas es
mayor que soporte nativo de la plataforma), entonces también la ruta de reparación del Adjacency-SID utiliza
esa Política SRTE.

Sólo se instala una ruta de reparación para el Adjacency-SID elegible para protección. Consulte el capítulo 5 del
plano de control IGP para obtener más información sobre los Adjacency-SID protegibles y no protegibles.

El IGP instala directamente la entrada de reenvío MPLS del Segmento de Adyacencia en el LSD sin involucrar
a la FIB. Esto incluye la ruta de reparación del Segmento de Adyacencia. Esto afecta a la posibilidad de la
funcionalidad de interfuncionamiento SR/LDP en la ruta de reparación del Segmento de Adyacencia. FIB se
encarga de la funcionalidad de interfuncionamiento SR/LDP, como se discute en el capítulo 7, "Enrutamiento de
Segmentos en Redes MPLS Existentes". Dado que FIB no está involucrado en la programación de la ruta de
reparación del segmento de adyacencia, esta ruta de reparación no puede beneficiarse de la funcionalidad de
interfuncionamiento SR/LDP. La Sección 9.8.3 discute esto con más detalle.

La Figura 9-18 ilustra la protección del Segmento de Adyacencia. Todos los enlaces en la topología tienen una
métrica 10, el enlace entre Nodo2 y Nodo4 que tiene una métrica 30. Basado en estas métricas, la ruta
primaria desde Nodo2 a Nodo1 es a través del enlace directo entre estos dos nodos. Basado en estas la ruta
primaria desde el Nodo2 al Nodo1 es a través del enlace directo entre estos dos nodos. Por lo tanto,
basándonos en la explicación anterior, la ruta de reparación del Segmento de Adyacencia Nodo2-Nodo1 sigue
la misma
como la ruta de reparación del Prefijo-SID del vecino: a través del Nodo PQ Nodo4. En el caso de que el enlace
primario entre Nodo2 y Nodo1 falle, entonces el PLR Nodo2 intercambia la etiqueta superior (la etiqueta
Adjacency-SID) con la etiqueta Prefix-SID del nodo en el extremo remoto del enlace y coloca la pila de
etiquetas de la ruta de reparación en la parte superior. En ejemplo, la etiqueta entrante Adjacency-SID 30201 se
intercambia con la etiqueta Prefix-SID 16001 (Prefix-SID del Nodo1) y la etiqueta Prefix-SID del Nodo PQ4 se
coloca en el paquete y se dirige a través de la interfaz al Nodo3.

Figura 9-18: Protección de segmentos de adyacencia

La salida ISIS en Nodo2 para este ejemplo se muestra en el Ejemplo 9-39 y Ejemplo 9-40. El Ejemplo 9-39
muestra la ruta de reparación en el Nodo2 para el prefijo loopback del Nodo1, [Link]/32. La ruta de
reparación va a través del Nodo PQ4 usando la etiqueta Prefix-SID 16004. La ruta de reparación pasa por el
Nodo PQ4, usando la etiqueta Prefix-SID 16004. El Ejemplo 9-40 muestra la ruta de reparación en el Nodo2
para el Segmento de Adyacencia de la adyacencia al Nodo1. Este enlace está en el camino más corto de
Nodo2 a Nodo1, por lo tanto el camino de reparación de este Segmento de Adyacencia es igual al camino de
reparación de [Link]/32. La pila de etiquetas de la ruta de reparación (línea 10) y la interfaz saliente (líneas
12-13) son las mismas que para la ruta de reparación del destino [Link]/32.
Ejemplo 9-39: Protección ISIS Adjacency-SID - protección Prefix-SID del nodo remoto

1 RP/0/0/CPU0:xrvr-2#show isis fast-reroute [Link]/32

2
3 L2 [Link]/32 [10/115]
4 vía [Link], GigabitEthernet0/0/0, xrvr-1, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (enlace), vía [Link], GigabitEthernet0/0/0/1 xrvr-3,
SRGB Base: 16000, Peso: 0
6 Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
7 Etiqueta prefijo: 16001

Ejemplo 9-40: Protección ISIS Adjacency-SID

RP/0/0/CPU0:xrvr-2#show isis adjacency Gi0/0/0/2 detail IS-IS

1 Adyacencias de nivel 2:
Sistema Id Interfaz SNPA Retención Cambiado NSF IPv4 IPv6
estatal BFD BFD
xrvr-1 Gi0/0/0/0 *PtoP* Arri 23 00:49:56 Sí Ninguno Ningu
Zona Dirección: 49.0001 ba no

Recuento total de adyacencias: 1

La salida OSPF para este ejemplo se muestra en el Ejemplo 9-41, Ejemplo 9-42, y Ejemplo 9-43. El Ejemplo 9-
41 muestra la ruta de reparación OSPF TI-LFA para el prefijo loopback del Nodo1, [Link]/32. La ruta de
reparación va a través del Nodo PQ4. La ruta de reparación pasa por el nodo PQ Nodo4. La línea 22 del
Ejemplo 9-42 muestra que el Adjacency-SID de la adyacencia al Nodo1 está protegido. La línea 18 del Ejemplo
9-43 muestra la pila de etiquetas de la ruta de reparación para la etiqueta Adjacency-SID.
Ejemplo 9-41: OSPF Adjacency-SID protection - remote node's Prefix-SID protection

RP/0/0/CPU0:xrvr-2#show ospf routes [Link]/32 backup-path Tabla

de topología para ospf 1 con ID [Link]

Códigos: O - Intra área, O IA - Inter área

O E1 - Tipo externo 1, O E2 - Tipo externo 2
O N1 - NSSA externo tipo 1, O N2 - NSSA externo tipo 2

O [Link]/32, métrica 2
[Link], desde [Link], vía GigabitEthernet0/0/0/0, path-id 1
Ruta de copia de seguridad: TI-LFA, Lista de reparación: Nodo P: [Link]
Etiqueta:
16004 [Link], desde [Link], vía GigabitEthernet0/0/0/1, mapa de bits
protegido
0000000000000001
Atributos: Métrica: 40, SRLG Disjuntos

Ejemplo 9-42: OSPF Adjacency-SID protection - Salida de vecino OSPF

RP/0/0/CPU0:xrvr-2#show ospf neighbor detail [Link]

* Indica la interfaz MADJ

# Indica Vecino en espera de sesión BFD up Vecinos

para OSPF 1

Vecino [Link], dirección de interfaz [Link]

En el área 0 a través de la interfaz GigabitEthernet0/0/0/0
La prioridad del vecino es 1, el estado es FULL, 6 cambios
de estado DR es [Link] BDR es [Link]
Opciones es 0x52
LLS Options is 0x1 (LR) Dead
timer due in 00:00:37
Neighbor is up for 00:14:07
Número de retransmisiones de DBD durante el último intercambio 0
Índice 3/3, longitud de la cola de retransmisión 0, número de retransmisiones 1
Primera 0(0)/0(0) Siguiente 0(0)/0(0)
La longitud del último escaneo de retransmisión es 1, el máximo es 1
El tiempo de escaneo de la última retransmisión es 0 mseg, el
máximo es 0 mseg LS Ack list: NSR-sync pending 0, high water mark
0 Adjacency SID Label: 30201, Protected
Etiqueta SID de adyacencia no protegida: 310201

Recuento total de vecinos: 1

Ejemplo 9-43: Adyacencia OSPF-Protección SID - Reenvío MPLS

RP/0/0/CPU0:xrvr-2#show mpls forwarding labels 30201 detail

Etique Etiqueta de Prefijo Interfaz de Próximo salto Bytes
ta salida o ID salida conmutados
local

30201 Pop SR Adj (idx 0) Gi0/0/0/0 [Link] 0

Actualizado: 30 Jun 16:21:26.553
Banderas de ruta: 0x400 [ BKUP-IDX:1 (0xa0e69ac4) ]
Versión: 201, Prioridad: 1
Pila de etiquetas (Arriba -> Abajo): { Imp-Null }
NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 1, Weight: 1
MAC/Encaps: 14/14, MTU: 1500
Paquetes conmutados: 0

16004 SR Adj (idx 0) Gi0/0/0/1 [Link] 0 (!)

Actualizado: 30 Jun 16:21:26.553
Banderas de ruta: 0x100 [ BKUP, NoFwd ]
Versión: 201, Prioridad: 1
Pila de etiquetas (Arriba -> Abajo): { 16004 16001 }
NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Peso: 4 MAC/Encaps:
14/22, MTU: 1500
Paquetes conmutados: 0
(!): FRR respaldo puro
9.8 TI-LFA para IP y LDP Tra fic
La protección TI-LFA no se limita al tráfico SR, sino que también puede ser aprovechada por el tráfico LDP y
el tráfico IP no etiquetado (IPv4 e IPv6). En estado estacionario, un operador puede mantener el tráfico IP no
etiquetado como tráfico no etiquetado y mantener el tráfico que se transporta a través de LDP LSP como tráfico
transportado por LDP, pero en caso de fallos, pueden beneficiarse de las mejoras que el enrutamiento por
segmentos y TI-LFA aportan a la protección. El transporte SR sólo se utiliza en la ruta de reparación en caso de
fallo. El tráfico es transportado de nuevo por su transporte original una vez que el IGP converge.

Para proteger el tráfico transportado por LDP, el prefijo de destino de este tráfico debe tener un Prefijo-SID. Si
el nodo que origina el prefijo de destino no puede anunciar un Prefijo-SID para ese prefijo (es por ejemplo un
nodo sólo LDP), entonces un Servidor de Mapeo debe anunciar un Prefijo-SID para este prefijo. TI-LFA utiliza
entonces este Prefix-SID (derivado de SRMS) para la ruta de reparación de este prefijo. Por esta razón, se
requiere que todos los nodos SR en la ruta desde el punto de liberación TI-LFA hasta el nodo de destino
soporten la funcionalidad Mapping Client. Esta funcionalidad es necesaria para reenviar el tráfico utilizando el
Prefijo-SID anunciado por el Servidor de Mapeo.

Para proteger el tráfico IP no etiquetado, no requiere Prefix-SID para el prefijo de destino del tráfico no
etiquetado. Antes del fallo, el tráfico se mantiene sin etiquetar. En caso de fallo, se impone a los paquetes la
pila de etiquetas para la ruta de reparación y los paquetes se liberan como paquetes IP no etiquetados en punto
de liberación al final de la ruta de reparación. Cuando el IGP converge tras el fallo, el tráfico se transporta de
nuevo sin etiqueta. Algo fuera de la discusión: si el tráfico necesita permanecer sin etiquetar entonces también
la imposición de etiquetas LDP debe ser prevenida. Si LDP está habilitado entonces por defecto Cisco IOS XR
impone etiquetas LDP a los paquetes entrantes no etiquetados. Filtrar la asignación de etiquetas LDP o el
anuncio de etiquetas puede evitar esto.

Para proteger el tráfico IP no etiquetado en un nodo SR de la plataforma Cisco IOS XR, debe habilitar
Segment Routing en la configuración global del nodo protector, como se muestra en el Ejemplo 9-44. Al
aplicar esta configuración, se asignan etiquetas locales para los destinos no etiquetados (no SR) que están
protegidos por TI-LFA. Estas etiquetas locales son necesarias para el mecanismo de reenvío en dos etapas que
se utiliza en la mayoría de las plataformas Cisco IOS XR. Sin una etiqueta local no se puede imponer ninguna
etiqueta saliente a los paquetes protegidos.
Ejemplo 9-44: Activar enrutamiento por segmentos en la configuración global

enrutamiento por segmentos

¡!

RECORDATORIO: Reenvío en dos etapas

Para obtener un mejor escalado y rendimiento, la mayoría de las plataformas Cisco IOS XR utilizan una arquitectura de plano de datos de reenvío en
dos etapas.

En la primera , la tarjeta de línea de entrada realiza una búsqueda FIB de la dirección de destino de un paquete entrante. La búsqueda FIB
devuelve información suficiente para entregar el paquete a la tarjeta de línea de salida. A continuación, la tarjeta de línea de entrada envía el
paquete a través del tejido a la tarjeta de línea de salida.

En la segunda , la tarjeta de línea de salida realiza una búsqueda FIB en la dirección de destino del paquete. La búsqueda FIB devuelve la adyacencia
completa y la información de reescritura de Capa 2. La tarjeta de línea de salida envía entonces el paquete a la interfaz de salida. A continuación, la
tarjeta de línea de salida envía el paquete a la interfaz de salida.

Para que este reenvío en dos etapas funcione para paquetes etiquetados, se necesita una etiqueta local para asociar la entrada de reenvío de tarjeta
de línea de entrada a la entrada de reenvío de tarjeta de línea de salida. La tarjeta de línea de entrada impone la etiqueta local en el paquete de
entrada y envía el paquete a la tarjeta de línea de salida, que a continuación intercambia la etiqueta local con la etiqueta de salida correcta y envía
los paquetes.

Si LDP está habilitado en el nodo protector, entonces LDP asignaría una etiqueta local para los prefijos de
destino del tráfico IP no etiquetado.

La protección TI-LFA utiliza la funcionalidad de interfuncionamiento SR/LDP para las rutas de reparación
siempre que sea posible. Aunque se recomienda encarecidamente habilitar SR en todos los nodos que atraviesa la
ruta de reparación TI-LFA, no todos los nodos de la ruta de reparación TI-LFA deben tener capacidad de
enrutamiento de segmento. Esto se explica con más detalle en la sección 9.8.3, "TI-LFA and SR/LDP
Interworking".

9.8.1 Protección de la propiedad intelectual no etiquetada

La topología de red de la Figura 9-19 es la misma que la de la Figura 9-12. Todos los nodos de la topología
están habilitados para SR, excepto los nodos origen y destino (Nodo11 y Nodo6) que no son nodos MPLS.
LDP no está habilitado en ningún nodo. El prefijo loopback [Link]/32 del Nodo6 no tiene un Prefix-SID
asociado.
Figura 9-19: Protección de enlace TI-LFA de tráfico IP no etiquetado

Para proteger el tráfico al Nodo de destino 6 en el Nodo PLR 1, TI-LFA calculó una ruta de reparación de
doble segmento a través del Nodo P4 y el Nodo Q3. Esta ruta de reparación también protege el tráfico IP. En
caso de que falle el enlace Nodo1-Nodo2, el Nodo1 del PLR impone los segmentos de la ruta de reparación a
los paquetes protegidos y los dirige hacia el Nodo4. Los paquetes en la ruta de reparación se liberan en el
punto de liberación Nodo3. Desde el Nodo3 el tráfico continúa como tráfico IP no etiquetado hacia su destino.

El Ejemplo 9-45 muestra la entrada RIB en Nodo1 para el prefijo de destino [Link]/32 de Nodo6.

La ruta primaria para este prefijo se muestra en las líneas 17 a 26 de la salida. IGP ha instalado la entrada RIB
para este prefijo. Como el prefijo no tiene un Prefijo-SID asociado, el IGP no proporcionó una etiqueta local
para ese prefijo a la RIB. Por lo tanto la entrada RIB muestra No local label en la línea 28 de la salida.
Como el prefijo no tiene un Prefijo-SID asociado, tampoco la ruta primaria tiene etiqueta saliente (línea 19).

La ruta de reparación de este prefijo se muestra en las líneas 7 a 15 de la salida. La pila de etiquetas salientes
consta de dos etiquetas (línea 10), de arriba a abajo (de izquierda a derecha): Prefijo-SID del Nodo-P Nodo4
(16004), y Adyacencia-SID del enlace Nodo4-Nodo3 (30403).
Ejemplo 9-45: Entrada RIB de prefijo IP no etiquetado

1 RP/0/0/CPU0:xrvr-1#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocido vía "ospf 1", distancia 110, métrica 21, tipo intra área
5 Instalado Jul 5 13:18:38.580 para 00:01:48
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/0, Backup (remoto)
8 El ALF remoto es [Link], [Link]
9 La métrica de la ruta es 0
10 Etiquetas: 0x3e84 0x76c3 (16004 30403)
11 ID del túnel: Ninguno
12 Etiqueta de encuadernación: Ninguna
13 Recuento de comunidades extendidas: 0
14 Id de ruta:65 Recuento de referencia de ruta:1
15 NHID:0x2(Ref:48)
16 Área OSPF:
17 [Link], desde [Link], vía GigabitEthernet0/0/0/1, Protegido
18 La métrica de ruta es 21
19 Etiqueta: Ninguna
20 ID del túnel: Ninguno
21 Etiqueta de encuadernación: Ninguna
22 Recuento de comunidades extendidas: 0
23 Id de ruta:1 Recuento de rutas:0
24 NHID:0x4(Ref:44)
25 Ruta de copia de seguridad id:65
26 Área OSPF: 0
27 La versión de la ruta es 0x7 (7)
28 Sin etiqueta local
29 Precedencia IP: No configurada
30 QoS Group ID: No configurado
31 Etiqueta de flujo: No fijado
32 Clase Fwd: No fijado
33 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
34 Descargar prioridad 1, Descargar versión 3013
35 Nada de protos publicitarios.

El ejemplo 9-46 muestra la entrada CEF para el prefijo [Link]/32. La ruta primaria del prefijo se muestra en las
líneas 11 a 14 de la salida. La ruta primaria del prefijo se muestra en las líneas 11 a 14 de la salida. Se ha
asignado una etiqueta local 90106 para este prefijo, como se muestra en la línea
14. No se impone ninguna etiqueta a los paquetes reenviados en la ruta primaria; la salida muestra etiquetas
impuestas {Ninguna} en la línea 14. La ruta de reparación se muestra en las líneas 6 a 10. La pila de
etiquetas impuestas es
{16004, 30403} (línea 10). Se trata de la misma pila de etiquetas que la de la salida RIB.
Ejemplo 9-46: Entrada CEF de prefijo IP no etiquetado

1RP/0/0/CPU0:xrvr-1#show cef [Link]/32

2 [Link]/32, versión 1155, interno 0x1000001 0x5 (ptr 0xa1435274) [1], 0x0
(0xa1400784), 0xa28 (0xa171c7b4)
3 Actualizado en mayo 4 09:08:31.589
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 15
6 via [Link]/32, GigabitEthernet0/0/0/0, 11 dependencias, peso 0, clase 0, backup
[flags 0x300]
7 path-idx 0 NHID 0x0 [0xa110d250 0x0]
8 siguiente salto [Link]/32, nodo P [Link], nodo Q [Link]
9 adyacencia local
10 etiqueta local 90106 etiquetas impuestas {16004 30403}
11 via [Link]/32, GigabitEthernet0/0/0/1, 11 dependencias, peso 0, clase 0, protegido
[flags 0x400]
12 path-idx 1 bkup-idx 0 NHID 0x0 [0xa0e843d4 0x0]
13 siguiente salto [Link]/32
14 etiqueta local 90106 etiquetas impuestas {Ninguna}

La protección del tráfico IP no etiquetado también se aplica en el caso de que se instancie una política SRTE
para soportar una pila de etiquetas mayor en la ruta de reparación. La Figura 9-20 repite la Figura 9-14 donde
la protección de nodo está activada en el PLR Nodo1. Se necesitan cuatro etiquetas en la ruta de reparación,
por lo que instanciará una política SRTE en esta plataforma.
Figura 9-20: Protección de nodo TI-LFA de tráfico IP no etiquetado

La entrada RIB del prefijo [Link]/32 en Nodo1 se muestra en el Ejemplo 9-47. La ruta de reparación se muestra
en las líneas 17 a 25 de la salida. La ruta de reparación se muestra en las líneas 17 a 25 de la salida. La etiqueta
saliente 0x100004 (1048580) en la línea 19 es un valor interno usado para representar "pop". Esto significa que
no se impone ninguna etiqueta adicional al paquete antes de que se dirija a la política SRTE. Por lo tanto, el
paquete continúa su viaje desde el punto de liberación hasta su destino como un paquete sin etiqueta.
Ejemplo 9-47: Entrada RIB de un prefijo IP no etiquetado utilizando la política SRTE

1 RP/0/0/CPU0:xrvr-1#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocido vía "ospf 1", distancia 110, métrica 21, tipo intra área
5 Instalado Jul 6 14:39:56.727 para 00:09:06
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/1, Protegido
8 La métrica de la ruta es 21
9 Etiqueta: Ninguna
10 ID del túnel: Ninguno
11 Etiqueta de encuadernación: Ninguna
12 Recuento de comunidades extendidas: 0
13 Id de ruta:1 Recuento de rutas:0
14 NHID:0x4(Ref:42)
15 Ruta de copia de seguridad id:66
16 Área OSPF: 0
17 conectado directamente, a través de tunnel-te32800, Backup
18 La métrica de la ruta es 0
19 Etiqueta: 0x100004 (1048580)
20 ID del túnel: Ninguno
21 Etiqueta de encuadernación: Ninguna
22 Recuento de comunidades extendidas: 0
23 Id de ruta:66 Recuento de referencia de ruta:1
24 NHID:0x20(Ref:2)
25 Área OSPF:
26 La versión de la ruta es 0xc1 (193)
27 Sin etiqueta local
28 Precedencia IP: No configurada
29 QoS Group ID: No configurado
30 Etiqueta de flujo: No fijado
31 Clase Fwd: No fijado
32 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
33 Prioridad de descarga 1, Versión de descarga 3294
34 Nada de protos publicitarios.

En el Ejemplo 9-48 se muestra la entrada CEF para el prefijo [Link]/32 en Nodo1. No se impone ninguna
etiqueta en la ruta primaria (labels imposed {None} en la línea 9). El tráfico en la reparación se dirige
a la política SRTE tunnel-te32800 (línea 10) sin imponer una etiqueta adicional sobre la pila de etiquetas de la
ruta de reparación (etiquetas impuestas {ImplNull} en la línea 14).
Ejemplo 9-48: Entrada CEF de prefijo IP no etiquetado mediante política SRTE

1RP/0/0/CPU0:xrvr-1#show cef [Link]/32

2 [Link]/32, versión 1511, interno 0x1000001 0x5 (ptr 0xa1434d74) [1], 0x0
(0xa13ff680), 0xa20 (0xa171c208)
3 Actualizado en mayo 4 09:08:31.589
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 15
6 via [Link]/32, GigabitEthernet0/0/0/1, 5 dependencias, peso 0, clase 0, protegido
[flags 0x400]
7 path-idx 0 bkup-idx 1 NHID 0x0 [0xa0e83e64 0x0]
8 siguiente salto [Link]/32
9 etiqueta local 90106 etiquetas impuestas {Ninguna}
10 via [Link]/32, tunnel-te32800, 5 dependencias, peso 0, clase 0, backup [flags
0x300]
11 path-idx 1 NHID 0x0 [0xa110d9dc 0xa110d934]
12 siguiente salto [Link]/32
13 adyacencia local
14 etiqueta local 90106 etiquetas impuestas {ImplNull}

9.8.2 Proteger el tráfico del PDL

La topología de red de la Figura 9-21 es la misma que la de la Figura 9-12. La diferencia es que todos los nodos
de esta topología tienen SR y LDP habilitados. La diferencia es que todos los nodos en esta topología tienen
tanto SR como LDP habilitados. el Nodo11 y el Nodo6, que son nodos sólo LDP. PLR El Nodo1 calcula una
ruta de reparación de protección de enlace para el destino Nodo6. Se requiere un Prefijo-SID para el Nodo6 con
el fin de transportar los paquetes protegidos como paquetes etiquetados desde el punto de liberación de la ruta
de reparación Nodo3 al destino Nodo6. Dado que el Nodo6 es un nodo no-SR, un Servidor de Mapeo debe
anunciar ese Prefijo-SID para el Nodo6.
Figura 9-21: TI-LFA protegiendo el tráfico LDP

La Política de Mapeo Activa mostrada en el Ejemplo 9-49 indica que el PLR Nodo1 ha aprendido el mapeo
prefijo-a-SID para el prefijo loopback [Link]/32 del Nodo6. El prefijo-SID para el prefijo [Link]/32 tiene un
índice SID 6. Como todos los nodos usan el SRGB por defecto [16000-23999], la etiqueta Prefijo-SID es
16006 (= 16000 + 6).

Ejemplo 9-49: Política de Asignación Activa ISIS en Nodo1

RP/0/0/CPU0:xrvr-1#show isis segment-routing prefix-sid-map active-policy

IS-IS 1 activo política
Prefijo Índice SID Gama Bander
as
[Link]/32 6 1

Número de entradas de mapeo: 1

ISIS en Nodo1 ha calculado una ruta de reparación TI-LFA para el prefijo de destino [Link]/32. La ruta de
reparación pasa por Nodo P4 y Nodo Q3 como se muestra en el Ejemplo 9-50. La ruta de reparación pasa
por el Nodo-P Nodo4 y el Nodo-Q Nodo3, como se muestra en el Ejemplo 9-50. La etiqueta 30403 (línea 7)
para ir del nodo P al nodo Q es la etiqueta Adjacency-SID de la adyacencia del Nodo4 al Nodo3. La etiqueta
Prefix-SID 16006 (línea 8) es la anunciada por el Servidor de Mapeo para el prefijo [Link]/32.
Ejemplo 9-50: Enlace ISIS que protege la ruta de reparación

1 RP/0/0/CPU0:xrvr-1#show isis fast-reroute [Link]/32

2
3 L2 [Link]/32 [20/115]
4 vía [Link], GigabitEthernet0/0/0/1, xrvr-2, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (enlace), vía [Link], GigabitEthernet0/0/0 xrvr-5,
SRGB Base: 16000, Peso: 0
6 Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
7 Nodo Q: xrvr-3.00 [[Link]], Etiqueta: 30403
8 Etiqueta prefijo: 16006

ISIS instala la entrada de prefijo en RIB, como se muestra en el Ejemplo 9-51. La ruta primaria se muestra en
las líneas 16 a 24 y la ruta de reparación en las líneas 7 a 15. La etiqueta local para este prefijo es la etiqueta
Prefix-SID 16006 (línea 26). En la ruta primaria, la etiqueta saliente es 16006 (línea 18) y en la ruta de
reparación, la pila de etiquetas salientes es {16004, 30403, 16006}. Nótese que todas las etiquetas en esta
entrada RIB son todas etiquetas de Segment Routing porque en este , todos los nodos están habilitados para
SR y anuncian sus SIDs, excepto Nodo11 y Nodo6. Un Servidor de Mapeo (SRMS) anuncia un Prefijo-SID
16006 para el prefijo [Link]/32 (Nodo6). Esto también se indica en la entrada RIB marcando la entrada como
etiquetada SR(SRMS) (línea 4).
Ejemplo 9-51: Entrada ISIS RIB

1 RP/0/0/CPU0:xrvr-1#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocido vía "isis 1", distancia 115, métrica 20, etiquetado SR(SRMS), tipo nivel-2
5 Instalado Jul 8 15:54:15.394 para 00:02:14
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/0, Backup (remoto)
8 El ALF remoto es [Link], [Link]
9 La métrica de la ruta es 0
10 Etiquetas: 0x3e84 0x76c3 0x3e86 (16004 30403 16006)
11 ID del túnel: Ninguno
12 Etiqueta de encuadernación: Ninguna
13 Recuento de comunidades extendidas: 0
14 Id de ruta:65 Recuento de referencia de ruta:1
15 NHID:0x2(Ref:24)
16 [Link], desde [Link], vía GigabitEthernet0/0/0/1, Protegido
17 La métrica de ruta es 20
18 Etiqueta: 0x3e86 (16006)
19 ID del túnel: Ninguno
20 Etiqueta de encuadernación: Ninguna
21 Recuento de comunidades extendidas: 0
22 Id de ruta:1 Recuento de rutas:0
23 NHID:0x4(Ref:20)
24 Ruta de copia de seguridad id:65
25 La versión de la ruta es 0xcd (205)
26 Etiqueta local: 0x3e86 (16006)
27 Precedencia IP: No configurada
28 QoS Group ID: No configurado
29 Etiqueta de flujo: No fijado
30 Clase Fwd: No fijado
31 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
32 Descargar prioridad 1, Descargar versión 3451
33 Nada de protos publicitarios.

Si se utiliza OSPF en esta topología, el Nodo1 recibió el anuncio del Servidor de Mapeo para el prefijo
[Link]/32 vía OSPF. Ver Ejemplo 9-52. OSPF calculó la misma ruta de reparación TI-LFA que ISIS, como se
muestra en el Ejemplo 9-53.
Ejemplo 9-52: Política de Mapeo Activo OSPF en Nodo1

RP/0/0/CPU0:xrvr-1#show ospf segment-routing prefix-sid-map active-policy Política

activa SRMS para ID de proceso 1

Prefijo Índice SID Gama Bander

as
[Link]/32 6 1

Número de entradas de mapeo: 1

Ejemplo 9-53: enlace OSPF que protege la ruta de reparación

RP/0/0/CPU0:xrvr-1#show ospf route [Link]/32 backup-path detail

Entrada de ruta OSPF para [Link]/32

Tipo de ruta: Intra-area
Última actualización: Jul 8 15:04:41.398
Métrica: 21
SPF prioridad: 4, SPF versión: 117 RIB
versión: 0, Fuente: Desconocido
[Link], desde [Link], vía GigabitEthernet0/0/0/1, path-id 1
Ruta de copia de seguridad: TI-LFA, Lista de reparación:
Nodo P: [Link] Etiqueta: 16004
Nodo Q: [Link] Etiqueta: 30403
[Link], desde [Link], vía GigabitEthernet0/0/0/0, mapa de bits protegido
0000000000000001
Atributos: Métrica: 81, SRLG Disjuntos

Las entradas RIB y CEF basadas en la información OSPF son equivalentes a las que se ven con ISIS en la red.

Todos los nodos de esta red también tienen habilitado LDP. El PLR Nodo1 tiene una sesión LDP con sus tres
vecinos Nodo2, Nodo5 y Nodo11. El Nodo1 asigna una etiqueta LDP local 90106 para el prefijo loopback
[Link]/32 del Nodo6 y aprende las etiquetas LDP para este prefijo de sus vecinos LDP (Nodo2, Nodo5 y
Nodo11). Todas estas etiquetas LDP se muestran en el Ejemplo 9-54.
Ejemplo 9-54: LDP label bindings en PLR

RP/0/0/CPU0:xrvr-1#show mpls ldp bindings [Link]/32

[Link]/32, rev 959
Enlace local: etiqueta: 90106
Enlaces remotos: (3 pares)
Peer Etiqueta

[Link]:0 90206
[Link]:0 90506
[Link]:0 91106

Nodo1 también instala la entrada de reenvío LDP para el prefijo [Link]/32; ver Ejemplo 9-55. La etiqueta
local LDP 90106 para [Link]/32 se muestra en la línea 11 en la segunda columna de la salida, etiquetada
Label In. La ruta primaria al prefijo [Link]/32 se muestra en la última línea de la salida. La etiqueta LDP
saliente para esta ruta primaria es 90206, que es la etiqueta que el vecino Node2 ha asignado para el prefijo
[Link]/32. La interfaz saliente y el siguiente salto son los mismos. La interfaz saliente y el siguiente salto de la
ruta primaria son hacia Nodo2.

La ruta de reparación para el prefijo [Link]/32 se muestra en las líneas 11 a 13 de la salida. La etiqueta
superior 90504 de la pila de etiquetas salientes (línea 11) es la etiqueta LDP saliente al Nodo P4. Esta etiqueta
LDP saliente es anunciada por el vecino LDP aguas abajo Nodo5 para el prefijo [Link]/32 de Nodo4. Vea las
etiquetas LDP para el prefijo [Link]/32 en el Nodo1 como se muestra en el Ejemplo 9-56. La etiqueta LDP
90504 que el Nodo5 anunció para el prefijo [Link]/32 se muestra en la línea 8 de esta salida. Las últimas dos
etiquetas en la pila de tres etiquetas son Unlabelled (líneas 12-13). Estas son las entradas de etiquetas
para dirigir los paquetes en la ruta de reparación desde el Nodo P4 al Nodo Q3 y desde allí al Nodo destino6.
LDP no tiene valores de etiqueta para estas entradas. CEF utiliza la funcionalidad de interfuncionamiento
SR/LDP para reemplazar estas entradas sin etiqueta con valores de etiqueta válidos.
Ejemplo 9-55: Entrada de reenvío LDP

1 RP/0/0/CPU0:xrvr-1#show mpls ldp forwarding [Link]/32

2
3 Códigos:
4 = -GR label recovering, (!)= LFA FRR pure backup path
5 {} = Pila de etiquetas con salida multilínea para una ruta de enrutamiento
6 G= GR, S = Stale, R = LFA remoto Copia de
seguridad FRR
7

8 Prefijo Etiquet Etiqueta(s) Saliente Próximo salto Bander

a as
9 En En Interfaz G S R
10
11 [Link]/32 90106 { 90504 Gi0/0/0/0 [Link] (!) R
12 Sin etiqueta ([Link])
13 Sin etiquetar ([Link])
}
14 90206 GIO/0/0/1 [Link]

Ejemplo 9-56: Enlace de etiquetas LDP para prefijo de nodo P

RP/0/0/CPU0:xrvr-1#show mpls ldp bindings [Link]/32

[Link]/32, rev 285
Enlace local: etiqueta: 90104
Enlaces remotos: (3 pares)
Peer Etiqueta

[Link]:0 90204
[Link]:0 90504

La entrada de reenvío MPLS resultante para el prefijo [Link]/32 en el Nodo1 se muestra en el Ejemplo 9-57.
La etiqueta local LDP para el prefijo [Link]/32 en el Nodo1 es 90106. La etiqueta local LDP para el prefijo
[Link]/32 en Nodo1 es 90106. La ruta primaria a [Link]/32 se muestra en las líneas 5 a 12 de la salida y la
ruta de reparación TI-LFA en las líneas 14 a 21. La pila de etiquetas de la ruta de reparación (en las líneas 14 a
21) se muestra en el Ejemplo 9-57. La pila de etiquetas de la ruta de reparación (en la línea 18) contiene tres
etiquetas: {90504 30403 16006}. La etiqueta superior 90504 es la etiqueta LDP saliente al nodo P Nodo4
como es anunciada por el vecino LDP aguas abajo Nodo5; ver las etiquetas LDP para el prefijo [Link]/32 en
Nodo1 mostradas en el Ejemplo 9-56. La segunda y tercera etiqueta, 30403 16006 es la etiqueta LDP saliente
para el nodo P Nodo4. La segunda y tercera etiquetas, 30403 y 16006, son el resultado de la operación de
reemplazo de interfuncionamiento SR/LDP en CEF. En esta operación, CEF ha reemplazado las entradas de
etiquetas LDP sin etiquetar que se muestran en las líneas 12 y 13 del 9-55Ejemplo Ejemplo 9-51, con las dos
últimas etiquetas de la pila de etiquetas IGP que se muestran en la línea 10 del : 30403 y 16006. El resultado
de la operación de reemplazo es la reparación de la pila de etiquetas para el tráfico LDP destinado a [Link]/32
como se muestra en la línea 18 del Ejemplo 9-57.
Ejemplo 9-57: Etiqueta LDP de entrada de reenvío MPLS

1 RP/0/0/CPU0:xrvr-1#show mpls forwarding prefix [Link]/32 detail

2 Local Saliente Prefijo Saliente Salto siguiente Bytes
3 Etiqueta Etiqueta o ID Interfaz Conmutado
4
5 90106 90206 [Link]/32 Gi0/0/0/1 [Link] 0
6 Actualizado: Jul 11 15:53:18.961
7 Banderas de ruta: 0x400 [ BKUP-IDX:0 (0xa0e8380c) ]
8 Versión: 303, Prioridad: 15
9 Pila de etiquetas (Arriba -> Abajo): { 90206 }
10 NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Peso: 0
11 MAC/Encaps: 14/18, MTU: 1500
12 Paquetes conmutados: 0
13
14 90504 [Link]/32 Gi0/0/0/0 [Link] 0
(!)
15 Actualizado: Jul 11 15:53:18.961
16 Banderas de ruta: 0x300 [ IDX:0 BKUP, NoFwd ]
17 Versión: 303, Prioridad: 15
18 Pila de etiquetas (Arriba -> Abajo): { 90504 30403 16006 }
19 NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Peso: 0
20 MAC/Encaps: 14/26, MTU: 1500
21 Paquetes conmutados: 0
22 (!): FRR pura copia de seguridad
23

La Figura 9-22 ilustra la pila de etiquetas de paquetes en la ruta de reparación. La ruta completa desde el
Nodo11 al Nodo6, con la ruta de reparación TI-LFA activada, se representa desplegada en esta ilustración. Un
paquete etiquetado LDP al Nodo6 llega al PLR Nodo1 mientras la protección está activa. La etiqueta 90106 en
este paquete es la etiqueta LDP que Nodo1 asignó para [Link]/32. Nodo1 intercambia la etiqueta LDP entrante
90106 con etiqueta saliente Prefix-SID 16006. Además el Nodo1 impone dos etiquetas adicionales: la
Adjacency-SID 30403 para dirigir el paquete del Nodo4 al Nodo3, y la etiqueta LDP 90504 para llevar el
paquete al Nodo4. La etiqueta LDP 90504 es la etiqueta LDP anunciada por el Nodo5 para el prefijo 1.1
1.4/32.
Figura 9-22: Pila de etiquetas de paquetes en ruta de reparación

La pila de etiquetas de ruta de reparación que el Nodo1 impone a los paquetes IP no etiquetados entrantes
depende de la preferencia imposición de etiquetas del Nodo1. Esta preferencia de imposición de etiquetas
indica qué etiqueta impone un nodo a los paquetes entrantes no etiquetados: la etiqueta saliente LDP o la
etiqueta saliente SR. Por defecto se prefiere la imposición de una etiqueta saliente LDP. Este es el primer caso
que se trata aquí.

La entrada CEF es la entrada de reenvío utilizada para los paquetes IP entrantes no etiquetados. La entrada CEF
para el prefijo [Link]/32 en Nodo1 se muestra en el Ejemplo 9-58. La preferencia de imposición de etiquetas
por defecto se aplica en , también para la ruta de reparación. Por lo tanto la entrada CEF para [Link]/32 en
Nodo1 muestra la pila de etiquetas para la ruta de reparación con una etiqueta de salida LDP 90504 como
etiqueta superior (línea 10). Esta es la misma pila de etiquetas para la ruta de reparación que para la entrada de
reenvío LDP MPLS. Compare la pila de etiquetas en línea 10 del Ejemplo 9-58 con la que se muestra en la línea
18 del Ejemplo 9-57. Son iguales. Son iguales.
Ejemplo 9-58: Entrada de imposición de etiquetas

1RP/0/0/CPU0:xrvr-1#show cef [Link]/32

2 [Link]/32, versión 1626, interno 0x1000001 0x5 (ptr 0xa1434d74) [1], 0x0
(0xa14000e8), 0xa28 (0xa171c730)
3 Actualizado en mayo 4 09:08:31.589
4 adyacencia local [Link]
5 Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 15
6 via [Link]/32, GigabitEthernet0/0/0/0, 13 dependencias, peso 0, clase 0, backup
[flags 0x300]
7 path-idx 0 NHID 0x0 [0xa110d2a4 0x0]
8 siguiente salto [Link]/32, nodo P [Link], nodo Q [Link]
9 adyacencia local
10 etiqueta local 90106 etiquetas impuestas {90504 30403 16006}
11 via [Link]/32, GigabitEthernet0/0/0/1, 13 dependencias, peso 0, clase 0, protegido
[flags 0x400]
12 path-idx 1 bkup-idx 0 NHID 0x0 [0xa0e83c94 0x0]
13 siguiente salto [Link]/32
14 etiqueta local 90106 etiquetas impuestas {90206}

La ruta de reparación puede verificarse con MPLS traceroute. La pila de etiquetas de la ruta de reparación
puede especificar en la línea de comandos cuando se utiliza la palabra clave nil-fec en el comando. En el
Ejemplo 9-59 se muestra salida de MPLS traceroute recogida en el Nodo1. Observe que la etiqueta explícita-
nula en la parte inferior de la pila de etiquetas está presente debido a la funcionalidad nil-fec.
Ejemplo 9-59: Traceroute de la pila de etiquetas de ruta de reparación

RP/0/0/CPU0:xrvr-1#traceroute mpls nil-fec labels 90504,30403,16006 output interface Gi0/0/0/0

nexthop [Link]

Trazado de MPLS Label Switched Path con Nil FEC con etiquetas [90504,30403,16006], el tiempo
de espera es de 2 segundos.

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

retorno 0 Escriba la secuencia de escape para abortar.

0 [Link] MRU 1500 [Etiquetas: 90504/30403/16006/explicit-null Exp: 0/0/0/0]

L 1 [Link] MRU 1500 [Etiquetas: implícito-nulo/30403/16006/explícito-nulo Exp: 0/0/0/0]
0 ms
L 2 [Link] MRU 1500 [Etiquetas: implícito-nulo/16006/explícito-nulo Exp: 0/0/0] 10 ms
L 3 [Link] MRU 1500 [Etiquetas: 16006/explicit-null Exp: 0/0] 0 ms
L 4 [Link] MRU 1500 [Etiquetas: implícito-nulo/explícito-nulo Exp: 0/0] 20 ms
¡! 5 [Link] 10 ms

Con la preferencia de imposición de etiquetas por defecto, la pila de etiquetas de ruta de reparación impuesta a
los paquetes no etiquetados entrantes es la misma que la utilizada para el tráfico etiquetado LDP. Cuando el
PLR Nodo1 está para preferir la imposición de etiquetas SR entonces la pila de etiquetas de ruta de reparación
para los paquetes no etiquetados es la misma que se utiliza para el tráfico etiquetado SR entrante. En el
Ejemplo 9-60, el operador configura la preferencia de imposición de etiqueta SR en el Nodo1 y luego verifica
la entrada CEF del prefijo [Link]/32. Comparando la entrada CEF con el prefijo [Link]/32, el operador
verifica si la entrada CEF es correcta. Comparando la entrada CEF con la salida del Ejemplo 9-51, la etiqueta
local ha cambiado a la etiqueta Prefix-SID 16006 y las etiquetas impuestas han cambiado tanto para la ruta
primaria como para la ruta de reparación. Ambas contienen sólo etiquetas SR.

Nótese que la configuración de preferencia de imposición de etiquetas no afecta a la pila de etiquetas de ruta
de reparación para paquetes etiquetados. La entrada de reenvío MPLS para los paquetes etiquetados LDP
destinados a [Link]/32 permanece sin cambios comparado con el Ejemplo 9-57.
Ejemplo 9-60: Reparar entrada de imposición de etiqueta de ruta con sr-prefer configurado

RP/0/0/CPU0:xrvr-1#conf RP/0/CPU0:xrvr-
1(config)#router isis 1
RP/0/CPU0:xrvr-1(config-isis)# address-family ipv4 unicast
RP/0/0/CPU0:xrvr-1(config-isis-af)# segment-routing mpls sr-prefer
RP/0/CPU0:xrvr-1(config-isis-af)#commit
RP/0/0/CPU0:xrvr-1(config-isis-af)#end
RP/0/0/CPU0:xrvr-1#
RP/0/0/CPU0:xrvr-1#show cef [Link]/32
[Link]/32, versión 544, interno 0x1000001 0x83 (ptr 0xa14343f4) [1], 0x0
(0xa13ffb24), 0xa28 (0xa1784394)
Actualizado el 15 de mayo 06:42:59.644
adyacencia local [Link]
Prefijo Len 32, índice de tráfico 0, precedencia n/a, prioridad 1
via [Link]/32, GigabitEthernet0/0/0/0, 17 dependencias, peso 0, clase 0, backup
(remoto) [flags 0x8300]
path-idx 0 NHID 0x0 [0xa110d250 0x0]
siguiente salto [Link]/32, nodo P [Link], nodo Q [Link]
adyacencia local
etiqueta local 16006 etiquetas impuestas {16004 30403 16006}
via [Link]/32, GigabitEthernet0/0/0/1, 17 dependencias, peso 0, clase 0, protegido [flags
0x400]
path-idx 1 bkup-idx 0 NHID 0x0 [0xa0e8380c 0x0]
siguiente salto [Link]/32
etiqueta local 16006 etiquetas impuestas {16006}

9.8.3 Interfuncionamiento TI-LFA y SR/LDP

En la sección anterior se analizó cómo TI-LFA protege el tráfico IP y LDP. suponía que todos los nodos de la
ruta de reparación TI-LFA tenían SR activado. Este requisito puede relajarse un poco. Mientras los nodos clave
de la ruta de reparación tengan SR activado, la funcionalidad de interfuncionamiento SR/LDP se encargará de la
ruta etiquetada de extremo a extremo.

La Figura 9-23 muestra la misma topología de red que la Figura 9-21, pero ahora el Nodo2, Nodo5 y Nodo6 no
tienen SR habilitado. En este son nodos sólo LDP. Los otros nodos de la red tienen tanto SR como LDP
habilitados. Un Servidor de Mapeo anuncia un Prefijo-SID 16006 para el prefijo [Link]/32.
Como la topología no ha cambiado, el PLR Nodo1 utiliza el mismo enlace protegiendo la ruta de reparación
para el destino Nodo6, a través del Nodo P Nodo4 y el Nodo Q Nodo3.
Figura 9-23: Interfuncionamiento SR/LDP en la ruta de reparación TI-LFA

En este ejemplo el PLR Nodo1 debe aplicar la funcionalidad de interworking SR/LDP en la ruta de reparación
ya que el vecino aguas abajo en la ruta de reparación, Nodo5, no tiene SR habilitado. Además, Nodo3 aplicar
SR/LDP interworking ya que su vecino aguas abajo Nodo2 hacia Nodo6 no tiene SR habilitado.

El ejemplo 9-61 muestra la entrada RIB para el prefijo [Link]/32 en el PLR Nodo1. Nótese que la entrada RIB
está marcada como etiquetada SR(SRMS)(línea 4), es decir, usando un Prefijo-SID anunciado por un
Servidor de Mapeo (SRMS). No hay etiqueta SR saliente para el camino primario (Label: None en la
línea 18) ya que el vecino aguas abajo Nodo2 en el camino primario no ha habilitado SR. Además, la etiqueta
superior de la ruta de reparación no está etiquetada. Las etiquetas de la ruta de reparación (línea 10) están
ordenadas arriba→abajo; el valor de etiqueta 0x100001 (1048577) en la línea 10 es un valor interno que
representa no etiquetado. La etiqueta superior no está etiquetada en esta entrada RIB porque el vecino aguas
abajo Nodo5 en la ruta de reparación no ha habilitado SR.
Ejemplo 9-61: interfuncionamiento SR/LDP en ruta de reparación - entrada RIB

1 RP/0/0/CPU0:xrvr-1#show route [Link]/32 detail

2
3 Entrada de enrutamiento para [Link]/32
4 Conocido vía "isis 1", distancia 115, métrica 20, etiquetado SR(SRMS), tipo nivel-2
5 Instalado Jul 12 13:52:17.309 para 00:06:13
6 Bloques descriptores de enrutamiento
7 [Link], desde [Link], vía GigabitEthernet0/0/0/0, Backup (remoto)
8 El ALF remoto es [Link], [Link]
9 La métrica de la ruta es 0
10 Etiquetas: 0x100001 0x76c3 0x3e86 (1048577 30403 16006)
11 ID del túnel: Ninguno
12 Etiqueta de encuadernación: Ninguna
13 Recuento de comunidades extendidas: 0
14 Id de ruta:65 Recuento de referencia de ruta:1
15 NHID:0x2(Ref:24)
16 [Link], desde [Link], vía GigabitEthernet0/0/0/1, Protegido
17 La métrica de ruta es 20
18 Etiqueta: Ninguna
19 ID del túnel: Ninguno
20 Etiqueta de encuadernación: Ninguna
21 Recuento de comunidades extendidas: 0
22 Id de ruta:1 Recuento de rutas:0
23 NHID:0x3(Ref:20)
24 Ruta de copia de seguridad id:65
25 La versión de la ruta es 0x31 (49)
26 Etiqueta local: 0x3e86 (16006)
27 Precedencia IP: No configurada
28 QoS Group ID: No configurado
29 Etiqueta de flujo: No fijado
30 Clase Fwd: No fijado
31 Prioridad de ruta: RIB_PRIORITY_NON_RECURSIVE_MEDIUM (7) Tipo de SVD
RIB_SVD_TYPE_LOCAL
32 Descargar prioridad 1, Descargar versión 770
33 Nada de protos publicitarios.

Las etiquetas LDP para el destino [Link]/32 en el Nodo1 son las mismas que se muestran en el Ejemplo 9-55.
La salida se repite en el Ejemplo 9-62. La salida se repite en el Ejemplo 9-62.
Ejemplo 9-62: Entrada de reenvío LDP

RP/0/0/CPU0:xrvr-1#show mpls ldp forwarding [Link]/32 Códigos:

= -GR label recovering, (!)= LFA FRR pure backup path
{} = Pila de etiquetas con salida multilínea para una ruta de enrutamiento
G= GR, S = Stale, R = LFA remoto Copia de
seguridad FRR

Prefijo Etiquet Etiqueta(s) Interfaz de Próximo salto Bande

a In fuera salida ras G
S R

[Link]/32 90106 { 90504 Gi0/0/0/0 [Link] (!) R

Sin etiqueta ([Link])
Sin etiqueta } ([Link])
90206 GIO/0/0/1 [Link]

La funcionalidad de interfuncionamiento SR/LDP en CEF combina las etiquetas SR y las etiquetas LDP para
llegar a la entrada de reenvío MPLS SR para la etiqueta Prefix-SID 16006 en Nodo1 como se muestra en el
Ejemplo 9-63. La etiqueta de salida de la ruta primaria 90206 en la línea 9 es la etiqueta LDP anunciada por
Nodo2 para el prefijo [Link]/. La etiqueta de salida 90206 de la ruta primaria en la línea 9 es la etiqueta LDP
anunciada por Nodo2 para el prefijo [Link]/32. La etiqueta de salida 90504 para la ruta de reparación en la
línea 18 es la etiqueta LDP anunciada por Nodo5 para [Link]/32. Estas etiquetas LDP en la entrada de reenvío
MPLS Prefix-SID son el resultado de la operación de reemplazo de interfuncionamiento SR/LDP. CEF ha
reemplazado las entradas sin etiqueta que estaban presentes en la entrada RIB en el Ejemplo 9-61, por sus
etiquetas LDP equivalentes.
Ejemplo 9-63: Interfuncionamiento SR/LDP en ruta de reparación - Entrada MPLS SR

1 RP/0/0/CPU0:xrvr-1#show mpls forwarding labels 16006 detail

2 Local Saliente Prefijo Saliente Salto siguiente Bytes
3 Etiqueta Etiqueta o ID Interfaz Conmutado
4
5 16006 24021 SR Pfx (idx 6) Gi0/0/0/1 [Link] 0
6 Actualizado: Jul 12 13:52:17.259
7 Banderas de ruta: 0x400 [ BKUP-IDX:0 (0xa0e8380c) ]
8 Versión: 770, Prioridad: 15
9 Pila de etiquetas (Arriba -> Abajo): { 90206 }
10 NHID: 0x0, Encap-ID: N/A, Path idx: 1, Backup path idx: 0, Peso: 0
11 MAC/Encaps: 14/18, MTU: 1500
12 Paquetes conmutados: 0
13
14 24008 SR Pfx (idx 6) Gi0/0/0/0 [Link] 0
(!)
15 Actualizado: Jul 12 13:52:17.259
16 Banderas de ruta: 0x8300 [ IDX:0 BKUP, NoFwd ]
17 Versión: 770, Prioridad: 15
18 Pila de etiquetas (Arriba -> Abajo): { 90504 30403 16006 }
19 NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Peso: 0
20 MAC/Encaps: 14/26, MTU: 1500
21 Paquetes conmutados: 0
22 (!): FRR pura copia de seguridad
23
24 Matriz de tráfico Paquetes/Bytes conmutados: 0/0

También el Nodo3 aplica la funcionalidad de interfuncionamiento SR/LDP para el Prefijo-SID 16006, como
se ilustra en la Figura 9-24. Esta ilustración muestra la representación desplegada de la ruta desde el Nodo11
al Nodo6 cuando la ruta de reparación está . Para tráfico entrante etiquetado SR y tráfico etiquetado LDP, la
etiqueta superior entrante es intercambiada con la etiqueta Prefix-SID 16006 destino. A continuación, se
impone la misma pila de etiquetas de ruta de reparación para ambos tipos de : {90504, 30403}. Etiqueta 90504
es la etiqueta LDP anunciada por Nodo5 para el prefijo [Link]/32. La etiqueta 30403 es la etiqueta
Adjacency-SID del Nodo4 para el enlace con el Nodo3. Nodo5 es el nodo de penúltimo salto para [Link]/32 y
despliega la etiqueta LDP. Cuando el paquete llega al Nodo4 con la etiqueta superior 30403, el Nodo4
despliega la etiqueta y reenvía el paquete al Nodo3. Como el Nodo2, el vecino aguas abajo del Nodo3, no
tiene SR activado, el Nodo3 intercambia la Prefix-SID 16006 con etiqueta LDP 90206 que el Nodo2 anunció
para el prefijo [Link]/32. Esto es el interfuncionamiento SR/LDP. Esta es la funcionalidad de
interfuncionamiento SR/LDP en el Nodo3.
Figura 9-24: Pila de etiquetas de paquetes en ruta de reparación

Los paquetes IP sin etiqueta destinados a [Link] que llegan al Nodo1 tendrán la misma pila de etiquetas de la
ruta de reparación impuesta por el Nodo1 como se muestra en la Figura 9-24. Como [Link]/32 tiene asociado
un Prefijo-SID 16006 anunciado por un Servidor de Mapeo, el Nodo1 puede usar la etiqueta 16006 en la pila de
etiquetas de la ruta de reparación para llegar a [Link]/32. La pila de etiquetas de reparación no depende de la
pila de etiquetas de la ruta de reparación. La pila de etiquetas de reparación no depende de la configuración de
la preferencia de imposición de etiquetas. La preferencia de imposición sólo influiría en la etiqueta superior de
la pila de etiquetas de la ruta de reparación. Ya que sólo la etiqueta saliente LDP está disponible para alcanzar el
Nodo-P Nodo4, no hay otra opción que usar esa etiqueta en la pila de etiquetas de reparación.
9.9 Equilibrio de carga TI-LFA en RepairPath
Aunque se programa una única ruta de reparación para cada prefijo de destino individual, TI-LFA utiliza el
ECMP disponible en la red para el tráfico reparado. El tráfico protegido utiliza todos los ECMP disponibles
para los segmentos de prefijo utilizados en la ruta de reparación, gracias al conocimiento de ECMP de los
Prefix-SID. Por ejemplo, desde el PLR hacia el nodo P o PQ y desde el punto de liberación de la ruta de
reparación hasta el destino.

Si son posibles varias rutas de reparación equivalentes, TI-LFA equilibra estadísticamente la carga entre ellas.
Esto significa que, para cada destino, TI-LFA selecciona una de las rutas de reparación disponibles basándose
en una función hash. Si, por ejemplo, hay disponibles varios nodos P o PQ equivalentes, TI-LFA equilibra
estadísticamente la carga de los prefijos de destino protegidos entre estas rutas de reparación diferentes.
Equivalente para el caso de nodos P y Q disjuntos; si hay múltiples nodos Q de igual coste desde un nodo P,
entonces de nuevo el PLR selecciona un par (P, Q) para cada prefijo de destino, basándose en una función hash.

La Figura 9-25 ilustra el equilibrio de carga del tráfico en la ruta de respaldo TI-LFA. La topología es basada
en la topología en Figura 9-11, pero dos cambios son aplicados. Primero, se han añadido dos nodos: Nodo13
(entre Nodo1 y Nodo4) y Nodo15 (entre Nodo4 y Nodo2). En segundo lugar, las métricas de enlace para los
enlaces Nodo4-Nodo3 y Nodo4-Nodo13 son 30. Esto difiere de la métrica 40 de los enlaces Nodo1 y Nodo2.
Esto difiere de la métrica 40 usada en la Figura 9-11 para el enlace entre Nodo4 y Nodo3. Usar una métrica 30
en estos enlaces no cambia los espacios P y Q calculados por el PLR Nodo1 Pero con la métrica 30, el camino
más corto desde Nodo4 a Nodo3 es a través del enlace directo entre ellos. Por tanto, el Nodo4 puede llegar al
Nodo3 (y al Nodo13) utilizando su Prefijo-SID. Si el camino más corto entre el Nodo P y el Nodo Q no es a
través del enlace directo entre ellos, entonces se debe utilizar el SID de Adyacencia.

Todos los nodos tienen habilitado SR. Las métricas de enlace IGP en esta topología son 10 excepto para los
enlaces entre Nodo4 y Nodo3 y entre Nodo4 y Nodo13 que tienen una métrica 30. El Nodo1 tiene habilitada la
protección de enlace TI-LFA y protege el tráfico a los destinos Nodo6 y Nodo9, entre otros, frente a un fallo del
enlace con el Nodo2.
Figura 9-25: Equilibrio de carga TI-LFA en la ruta de reparación

El Nodo1 calcula la ruta de reparación TI-LFA para el destino Nodo6 y descubre que existen dos rutas de
reparación igualmente buenas: una a través del par (P, Q) (Nodo4, Nodo3) y otra a través del par (P, Q)
(Nodo4, Nodo13). El PLR instala una única ruta de reparación por destino. Esta ruta de reparación también
incluye la interfaz saliente (OIF) y el siguiente salto (NH). Así, el PLR Nodo1 tiene cuatro rutas de reparación
entre las que elegir:

next-hop Nodo5, (P, Q)-par (Nodo4, Nodo3) next-

hop Nodo5, (P, Q)-par (Nodo4, Nodo13) next-hop
Nodo15, (P, Q)-par (Nodo4, Nodo3)

siguiente salto Nodo15, (P, Q)-par (Nodo4, Nodo13)

El Nodo 2 del PLR intenta distribuir el tráfico protegido por todas las rutas de reparación disponibles.
Selecciona la ruta de reparación basándose en un cálculo hash (calculado sobre el prefijo de destino) para
equilibrar estadísticamente la carga de los destinos protegidos entre las rutas de reparación disponibles. Como
ejemplo, el Nodo2 elige la ruta de reparación a través del Nodo15 y el par (P, Q) (Nodo4, Nodo13) para
proteger el destino Nodo6 y para proteger el destino Nodo9 selecciona la ruta de reparación a través del Nodo5
y el par (P, Q) (Nodo4, Nodo3). Véase la salida ISIS en el Ejemplo 9-64. Note que la entrada para el nodo Q
Nodo13 está etiquetada como nodo P (línea 7).
Esto indica que el nodo anterior (Nodo4) puede llegar al Nodo13 a través de la ruta de postconvergencia
utilizando
su Prefijo-SID. Esto contrasta con el papel real del Nodo13: Nodo Q. La ruta de reparación para el destino
Nodo9 ([Link]/32) pasa por Nodo5, Nodo4, y Nodo3, como se muestra en el Ejemplo 9-65.

Ejemplo 9-64: Ruta de reparación ISIS TI-LFA para destino Nodo6

1 RP/0/0/CPU0:xrvr-1#show isis fast-reroute [Link]/32

2
3 L2 [Link]/32 [20/115]
4 vía [Link], GigabitEthernet0/0/0/3, xrvr-2, SRGB Base: 16000, Peso: 0
5 Ruta de respaldo: TI-LFA (enlace), vía [Link], GigabitEthernet0/0/0/2 xrvr-
15, SRGB Base: 16000, Peso: 0
6 Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
7 Nodo P: xrvr-13.00 [[Link]], Etiqueta: 16013
8 Etiqueta prefijo: 16006

Ejemplo 9-65: Ruta de reparación ISIS TI-LFA para destino Nodo9

RP/0/0/CPU0:xrvr-1#show isis fast-reroute [Link]/32 L2

[Link]/32 [20/115]
vía [Link], GigabitEthernet0/0/0/3, xrvr-2, SRGB Base: 16000, Peso: 0 Ruta de
respaldo: TI-LFA (enlace), vía [Link], GigabitEthernet0/0/0/1 xrvr-5,
Base SRGB: 16000, Peso: 0
Nodo P: xrvr-4.00 [[Link]], Etiqueta: 16004
Nodo P: xrvr-3.00 [[Link]], Etiqueta: 16003
Etiqueta prefijo: 16009

En la misma topología, OSPF selecciona la ruta de reparación vía Nodo5, Nodo4, y Nodo3 para el destino
Nodo6 ([Link]/32). Vea la salida en el Ejemplo 9-66. La interfaz saliente y el siguiente salto se muestran en la
línea 13. La ruta de reparación para el destino Nodo9 ([Link]/32) pasa por Nodo15, Nodo4 y Nodo13, como se
muestra en el Ejemplo 9-67.
Ejemplo 9-66: Ruta de reparación OSPF TI-LFA para destino Nodo6

1 RP/0/0/CPU0:xrvr-1#show ospf routes [Link]/32 backup-path

2
3 Tabla de topología para ospf 1 con ID [Link]
4
5 Códigos: O - Intra área, O IA - Inter área
6 O E1 - Tipo externo 1, O E2 - Tipo externo 2
7 O N1 - NSSA externo tipo 1, O N2 - NSSA externo tipo 2
8
9 O [Link]/32, métrica 21
10 [Link], desde [Link], vía GigabitEthernet0/0/0/3, path-id 1
11 Ruta de copia de seguridad: TI-LFA, Lista de reparación:
12 Nodo P: [Link] Etiqueta: 16004
13 Nodo P: [Link] Etiqueta: 16003
14 [Link], desde [Link], vía GigabitEthernet0/0/0/1, mapa de bits protegido
0000000000000001
15 Atributos: Métrica: 71, SRLG Disjuntos

Ejemplo 9-67: Ruta de reparación OSPF TI-LFA para destino Nodo9

RP/0/0/CPU0:xrvr-1#show ospf routes [Link]/32 backup-path Tabla de

topología para ospf 1 con ID [Link]

Códigos: O - Intra área, O IA - Inter área

O E1 - Tipo externo 1, O E2 - Tipo externo 2
O N1 - NSSA externo tipo 1, O N2 - NSSA externo tipo 2

O [Link]/32, métrica 21
[Link], desde [Link], vía GigabitEthernet0/0/0/3, path-id 1 Ruta de
respaldo: TI-LFA, Lista de reparación:
Nodo P: [Link] Etiqueta: 16004
Nodo P: [Link] Etiqueta: 16013
[Link], desde [Link], vía GigabitEthernet0/0/0/2, mapa de bits protegido
0000000000000001
Atributos: Métrica: 71, SRLG Disjuntos

En otro ejemplo ilustrado en la Figura 9-26, el Nodo20 se añade a la topología entre el Nodo1 y los nodos
Nodo5 y Nodo15. En este , destaca la naturaleza natural de balanceo de carga de los Segmentos Prefijo. El PLR
Nodo1 protege el tráfico hacia los destinos Nodo6, Nodo9 y Nodo10, entre otros, frente al fallo del enlace con
Nodo2. El Nodo1 tiene dos rutas de reparación igualmente buenas entre las que elegir:

siguiente salto Nodo20, (P, Q)-par (Nodo4, Nodo3)

siguiente salto Nodo20, (P, Q)-par (Nodo4,

Nodo13)
El Nodo PLR1 equilibra estadísticamente la carga del tráfico protegido en las dos rutas de reparación
disponibles, seleccionando una de las rutas de reparación por prefijo de destino. El tráfico en la ruta de
reparación seleccionada se equilibra en las dos rutas de igual coste desde el Nodo1 al Nodo P4 (vía Nodo5 y
vía Nodo15) utilizando el conocimiento ECMP del segmento de prefijo hacia el Nodo4. El tráfico también se
equilibra en los trayectos de igual coste desde el Nodo Q (Nodo3 o Nodo13) Nodo destino 10 (vía Nodo6 y vía
Nodo9) utilizando el conocimiento ECMP del Segmento Prefijo hacia el Nodo10. El balanceo de carga sobre
caminos de igual coste de un segmento de prefijo se realiza utilizando la funcionalidad hashing del plano de
datos.

Figura 9-26: Equilibrio de carga TI-LFA en la ruta de reparación

9.10 Evitar microbucle
En esta sección analizaremos los microbucles que se producen en las redes IP/MPLS generalmente después de
un evento de convergencia. Entenderemos qué son los microbucles y cómo se producen y, a continuación,
veremos cómo el enrutamiento por segmentos ayuda a evitar los microbucles.

9.10.1 Una visión general de los microbucles

Cuando la topología de una red IGP cambia (por ejemplo, un enlace o nodo se cae), el IGP de estado de enlace
distribuye primero la información del cambio de topología a los demás nodos de la red; el anuncio del nuevo
estado de enlace se inunda en la red. A continuación, cada nodo de la red ejecuta de forma independiente el
mismo algoritmo de cálculo de rutas y actualiza sus tablas de reenvío con la nueva información. En este periodo
de tiempo, las tablas de reenvío de los nodos de la red no son coherentes. Algunos nodos siguen reenviando
tráfico basándose en la topología antigua, mientras que otros ya han actualizado sus tablas de reenvío de
acuerdo con la nueva topología. Finalmente, cuando todos los nodos han terminado de actualizar sus tablas de
reenvío, se dice que la red ha convergido; las entradas de reenvío de todos los nodos son coherentes y reflejan la
nueva topología.

El periodo de tiempo entre el cambio de topología y la actualización de la tabla de reenvío de un nodo varía
para cada nodo por diversas razones.

La propagación de los cambios de topología a través de la red introduce retrasos. El tiempo que tarda en
llegar a un nodo una notificación de cambio de topología depende de la distancia del cambio de topología
a ese nodo.

No se garantiza que el orden en que cada nodo actualiza los prefijos en la tabla de reenvío sea el mismo.

Las velocidades de actualización del plano de control y del plano de datos varían. Depende de la CPU, el
ASIC, la arquitectura de la plataforma, etc.

Este estado incoherente de las tablas de reenvío de los nodos de la red tras un cambio de topología puede dar
lugar a bucles de tráfico entre nodos. La duración de los bucles está limitada por el tiempo de convergencia del
nodo más lento.[ 5] Estos bucles de reenvío transitorios se denominan microbucles, ya que suelen tener una
duración inferior al segundo.
Los microbucles son un fenómeno natural en las redes IP/MPLS que utilizan encaminamiento salto a salto.
Pueden producirse con cualquier cambio de topología, bueno o malo, fallo o restablecimiento. Pueden
producirse cerca cambio de topología o lejos de él.

El siguiente ejemplo ilustra la aparición de microbucles. La topología de red de la Figura 9-27 tiene una
métrica de enlace por defecto 10. El tráfico fluye desde el Nodo6 al Nodo4, a través del camino más corto
como se indica en la ilustración. Otro flujo de tráfico desde el Nodo3 al destino Nodo4 también se indica en el
dibujo. Ahora falla el enlace entre el Nodo1 y el Nodo2. En este primer ejemplo, se asume que no hay
protección fast-reroute habilitada en el Nodo2. Después del del enlace, el IGP en el Nodo2 converge a la
nueva topología y actualiza la entrada de reenvío al Nodo4 después de 200 ms. En ese momento el Nodo2
empieza a reenviar la ruta. En ese momento el Nodo2 comienza a reenviar el flujo de tráfico destinado al
Nodo4 a través del Nodo3. IGP en Nodo3 es algo más lento y actualiza la entrada de reenvío a Nodo4 después
de 300 ms. El Nodo3 ahora reenvía el tráfico al Nodo4 directamente al Nodo4. Desde el momento en que el
Nodo2 utiliza la nueva ruta de reenvío (después de 200 ms) hasta el momento en que el Nodo3 instala la nueva
entrada de reenvío (después de 300 ms), el tráfico está en bucle entre el Nodo2 y el Nodo3.

Figura 9-27: Microbucle local a PLR

La línea de tiempo de los eventos como se ilustra en la Figura 9-28:

0 ms: el enlace entre Nodo1 y Nodo2 se cae 200 ms:

Nodo2 actualiza la entrada de reenvío a Nodo6

300 ms: Nodo3 actualiza la entrada de reenvío al Nodo6

Durante el periodo de tiempo de 0 ms a 200 ms, el Nodo2 interrumpe el tráfico. Durante el periodo de tiempo
de 200 ms a 300 ms (duración 100 ms), el tráfico pasa en bucle entre el Nodo2 y el Nodo3. En el tiempo 300 ms
se restablece el flujo de tráfico. Suponiendo que todos los paquetes microbucle se pierden o llegan demasiado
tarde, la pérdida de conectividad del flujo hacia el Nodo6 tras el fallo del enlace dura de 0 ms a 300 ms. El
microbucle se produce durante 1/3 de este periodo de tiempo (100 ms).

Figura 9-28: Línea de tiempo del microbucle

Los microbucles siempre han existido en las redes IP, pero en el pasado no eran motivo de gran preocupación.
Eran demasiado cortos en comparación con el tiempo total de convergencia de la red; la pérdida total de tráfico
durante la convergencia de la red enmascaraba cualquier pérdida de tráfico debida a un bucle de enrutamiento.
Pero después de introducir FRR, el restablecimiento del tráfico tras un fallo suele producirse en menos de 30
ms y la expectativa es no ver más 50 ms de pérdida de tráfico cuando FRR está activado. La pérdida de tráfico
debida a los microbucles es ahora notable. El problema se ilustra utilizando IPFRR, pero es independiente del
mecanismo FRR que se utilice. En particulartambién se aplica al FRR TE que protege túneles de un solo salto.

Los microbucles provocan la pérdida de paquetes porque el TTL de los paquetes en el bucle acaba
disminuyendo a cero o porque el enlace se satura. Supongamos un microbucle en un enlace con retardo
unidireccional de 5
mseg. Si el 20% del ancho de banda del enlace se utilizó antes del evento, entonces el enlace se saturará debido
al microbucle después de menos de 20 ms, y los paquetes se perderán debido a esta saturación durante el tiempo
restante del microbucle. La congestión se produce en ambas direcciones del enlace. Esta congestión del enlace
causada por los microbucles puede afectar a otro tráfico que de otro modo no se vería afectado por el cambio de
topología; la congestión afecta a todo el tráfico que atraviesa este enlace. El microbucle ilustrado en la Figura 9-
27, por ejemplo, afecta al tráfico entre el Nodo6 y el Nodo7; tráfico que de otro modo no se vería afectado por
el fallo.

Volviendo al ejemplo de la Figura 9-27, ahora con la protección de enlace TI-LFA activada en el Nodo2.
Nodo2 pre-instala la ruta de reparación TI-LFA (sin bucles) para el destino Nodo4 en la tabla de reenvío. En
este ejemplo, el Nodo2 utiliza el par (P, Q) (Nodo3, Nodo4) para la ruta de reparación al Nodo4. Con esta
configuración, la secuencia de eventos como se ilustra en la Figura 9-29, es la siguiente:

0 ms: el enlace entre Nodo1 y Nodo2 se cae 25 ms: Se

activa la protección TI-LFA del Nodo2
200 ms: Nodo2 actualiza la entrada de reenvío al Nodo6 y elimina la ruta de reparación TI-LFA
300 ms: Nodo3 actualiza la entrada de reenvío al Nodo6

Durante el periodo de tiempo de 0 ms a 25 ms, el Nodo2 deja caer el tráfico. Durante el periodo de tiempo de
25 ms a 200 ms, el tráfico llega a su destino a través de la ruta de reparación TI-LFA; durante este periodo de
tiempo no hay pérdida de conectividad. Durante el periodo de tiempo de 200 ms a 300 ms (duración 100 ms),
el tráfico hace un bucle entre el Nodo2 y el Nodo3. A los 300 ms se restablece el flujo de tráfico.

Hay dos periodos distintos de pérdida de paquetes en este ejemplo: uno justo después del fallo (0 ms - 25 ms) y
otro después de que el Nodo2 converja (200 ms - 300 ms). La pérdida total de conectividad para el flujo hacia el
Nodo6 tras el fallo dura 125 ms (25 ms+ 100 ms). El microbucle se produce durante 4/5 de este periodo de
tiempo.
Figura 9-29: Línea de tiempo de microbucle con FRR

9.10.2 Mecanismos existentes para evitar los microbucles

Desde la introducción de LFA, existe un sencillo mecanismo de evitación de microbucle en Cisco IOS XR.
Mediante este mecanismo, el nodo protector (PLR) retrasa la actualización de su tabla de reenvío para permitir
que todos los demás nodos de la red converjan a la nueva topología. El PLR calcula las nuevas rutas, pero
retrasa la instalación de su tabla de reenvío. Tras este retraso, el PLR actualiza su tabla de reenvío y, dado que
el resto de red ya se encuentra en un estado coherente, se evita el microbucle. La funcionalidad de evitación de
microbucle local se describe en IETF draft-ietf-rtgwg-uloop-delay. Si esta funcionalidad de evasión de
microbucle local está habilitada en el Nodo2 de la Figura 9-27, la secuencia de eventos es la ilustrada en la
Figura 9-30Figura 9-30 . En la se muestra la secuencia de eventos:

0 ms: el enlace entre Nodo1 y Nodo2 se cae 25 ms: Se

activa la protección TI-LFA del Nodo2

300 ms: Nodo3 actualiza la entrada de reenvío al Nodo6

5025 ms: Nodo2 actualiza la entrada de reenvío al Nodo6 y elimina la ruta de reparación TI-LFA

Durante el periodo de tiempo de 0 ms a 25 ms, el Nodo2 deja caer el tráfico. A , el Nodo2 dirige el tráfico por la
ruta de reparación (sin bucles) hasta que el Nodo2 actualiza su tabla de reenvío transcurridos 5 segundos. Dado
que el Nodo3 ya ha actualizado su tabla de reenvío, no se produce ningún bucle.
Figura 9-30: Línea de tiempo de microbucle con FRR y evitación de microbucle local

Sin embargo, este esquema de evitación de microbucle local tiene limitaciones: no funciona para todos los
microbucles y sólo funciona para eventos de caída de enlace. Como ejemplo, este mecanismo no funciona para
un fallo diferente en la topología; ver Figura 9-31. Antes del fallo del enlace entre el Nodo5 y el Nodo4, el
tráfico entre el Nodo origen5 y el Nodo destino6 es el indicado por la línea etiquetada como Pre-convergence
path en la ilustración. También se indica el camino más corto desde el Nodo3 hasta el destino. A continuación,
el enlace Nodo5-Nodo3 falla y la línea denominada Trayectoria posterior a la convergencia indica la
trayectoria después de la convergencia.
Figura 9-31: Microbucle remoto desde PLR

Dependiendo del orden de convergencia de los nodos, son posibles tres microbucles, como se indica en
ilustración. En el peor de los , la secuencia de eventos es la siguiente (véase la Figura 9-32):

0 ms: el enlace entre Nodo4 y Nodo5 se cae 25 ms: Se

activa la protección TI-LFA del Nodo5
200 ms: Nodo1 actualiza su tabla de reenvío
250 ms: Nodo2 actualiza su tabla de reenvío 300
ms: Nodo3 actualiza su tabla de reenvío

5025 ms: Nodo5 actualiza su tabla de reenvío (evitación de microbucle local)

La pérdida de tráfico se produce durante los primeros 25 ms, hasta que el Nodo5 activa la protección TI-LFA.
Dado que el Nodo5 dirige el tráfico por la ruta de reparación sin bucle, no se producen pérdidas de tráfico
hasta que el Nodo1 actualiza su tabla de reenvío. A los 200 ms se inicia un microbucle entre Nodo1 y Nodo2.
Ese se resuelve cuando el Nodo2 actualiza su tabla de reenvío en el tiempo 250 ms. Pero al mismo tiempo se
produce un nuevo
se inicia un microbucle entre Nodo2 y Nodo3. Este microbucle dura hasta que el Nodo3 actualiza su tabla de
reenvío en un tiempo de 300 ms. Algún tiempo después, en torno a los 5 s, el Nodo5 actualiza su tabla de
reenvío. La evitación local de microbucle sólo puede evitar que se produzca uno de los posibles microbucles: el
microbucle entre Nodo1 y Nodo5. En este ejemplo, el flujo de tráfico experimenta pérdidas de conectividad
durante 125 ms, de los cuales 100 ms se deben a microbucles.

Figura 9-32: Línea de tiempo de microbucle remoto con FRR

Hasta ahora, en esta sección sólo se han tratado los microbucles que se producen tras un fallo de enlace. Como
se mencionó antes, los microbucles también pueden ocurrir después de restablecer un enlace. En un ejemplo
usando la misma topología, el enlace entre Nodo4 y Nodo5 es restaurado; ver Figura 9-33. Los posibles
microbucles que afectan al tráfico que va del Nodo6 al Nodo4 se indican en el dibujo. Una posible secuencia de
eventos es la siguiente (ver Figura 9-34:

0 ms: Se restablece el enlace entre Nodo4 y Nodo5 200

ms: Nodo2 actualiza su tabla de reenvío
250 ms: Nodo1 actualiza su tabla de reenvío
300 ms: Nodo5 actualiza su tabla de reenvío

En esta secuencia de eventos, se produce un microbucle entre el Nodo2 y el Nodo1 en el periodo de tiempo
comprendido entre 200 ms y 250 ms. Nodo2 dirige los paquetes al destino hacia Nodo1, pero éste sigue
enviando los paquetes siguiendo la topología antigua. Después de que el Nodo1 actualice su tabla de reenvío, se
produce un microbucle entre el Nodo1 y el Nodo5 durante el periodo de tiempo de 250 ms a 300 ms. Después
de que el Nodo5 actualice su tabla de reenvío, el microbucle se resuelve. En este ejemplo, el tráfico
experimentó una pérdida de paquetes de 100 ms debido a los microbucles; mientras que para el restablecimiento
del enlace no se desea ni se espera ninguna pérdida.
Figura 9-33: Microbucle para restauración de enlaces

Figura 9-34: Línea de tiempo de microbucle de restauración de enlace

Los microbucles han sido objeto de debate e investigación durante varios años. Se han propuesto múltiples
soluciones para evitar los microbucles, pero ninguna ofrecía una solución completa que fuera sencilla de aplicar
y manejar. El RFC 5715 del IETF describe una serie de soluciones propuestas para el problema. La solución
local
La solución para evitar microbucles descrita en IETF draft-ietf-rtgwg-uloop-delay ofrece una solución parcial
para los casos de caída de enlaces.

9.10.3 Evitación de microbucle con enrutamiento de segmentos

La dirección explícita del tráfico enrutado en origen del Enrutamiento por Segmentos proporciona una
solución sencilla y completa para el problema de los microbucles. Cuando se produce un cambio de topología
en la red y un nodo convergente calcula que es posible que se produzcan microbucles en la ruta posterior a la
convergencia, dicho nodo utiliza SR para evitar que se produzcan estos microbucles. El nodo dirige
temporalmente el tráfico en el trayecto posterior a la convergencia utilizando una lista de segmentos explícita a
un punto de liberación libre de bucles (como en el caso de TI- LFA). Cuando ya no hay riesgo de microbucle,
el nodo pasa al reenvío normal sin la lista de segmentos explícita. Los paquetes siguen su camino más corto en
la nueva topología sin riesgo de microbucle.

El proceso de convergencia para evitar microbucles consta de dos fases. Tras un cambio de topología, el nodo N
analiza el cambio de topología y descubre que es posible que se produzcan microbucles en la ruta posterior a la
convergencia hacia el destino D. Por lo tanto, el nodo N aplica el siguiente proceso de convergencia en dos
fases para el destino D:

Etapa 1: El nodo N calcula un trayecto SR sin bucles que se adapta a lo largo del trayecto de
postconvergencia. Durante un periodo de , el nodo N dirige el tráfico a D utilizando esa ruta de
postconvergencia explícita sin bucles. El periodo de es al menos el peor tiempo de convergencia de un nodo,
en toda la red.

Fase 2: Una vez transcurrido el temporizador de la Etapa 1, N instala la ruta de reenvío

postconvergencia normal para el destino D. Por lo tanto, el nodo N ya no impone ningún segmento adicional
para garantizar la ausencia de bucles en la ruta.

Como ejemplo, la funcionalidad de evasión de microbucle SR está habilitada en la misma topología que se usó
anteriormente en esta ; ver Figura 9-35. Antes del fallo del enlace, el tráfico desde el Nodo6 al Nodo4 sigue la
ruta etiquetada como Pre-convergence path en la ilustración. Cuando el enlace entre Nodo4 y Nodo5 falla,
Nodo5 (y Nodo4) activa la protección TI-LFA e inunda la notificación de cambio de topología (IGP link-state
advertisement) en la red. Gracias a la protección TI-LFA FRR, la pérdida de tráfico tras fallo se limita a menos
de 50 ms.
Todos los nodos calculan el nuevo Árbol del Camino Más Corto (SPT). El Nodo 6 calcula la ruta post-
convergencia hacia el Nodo 4 (etiquetada como ruta post-convergencia en la ilustración) y descubre que es
posible que se produzca un microbucle en esa ruta post-convergencia entre el Nodo 2 y el Nodo 3, como se
indica en la ilustración. Por lo tanto, el Nodo6 calcula una Lista de Segmentos para dirigir el tráfico hacia el
Nodo4 sin bucles. El algoritmo para determinar la posibilidad de microbucles y para calcular una ruta explícita
sin bucles para evitarlos está patentado y es una función local del Nodo 6, por lo que no se hace público. El
Nodo 6 impone temporalmente la Lista de Segmentos {Prefix-SID(Nodo3), Adj-SID(L3-4)} a los paquetes
destinados al Nodo 4. Esta es la primera etapa de la convergencia. Esta es la primera etapa del proceso de
convergencia. A partir de ese momento, los paquetes ya atraviesan la ruta de postconvergencia, que es la ruta
más deseada, ya que es la ruta que seguirá el tráfico una vez que la red haya convergido completamente. El
Prefijo-SID(Nodo3) en la Lista de Segmentos lleva los paquetes al Nodo3 de libre de bucles ya que el camino
desde el Nodo6 al Nodo3 no se ve afectado por el cambio de topología. El Adjacency-SID en la Lista de
Segmentos dirige entonces el tráfico desde el Nodo3 al Nodo4 y desde allí el tráfico va a su destino sin verse
afectado por un microbucle.

Los demás nodos de la red también aplican el proceso de evitación de microbucle. Por ejemplo, el Nodo2
impone la Lista de Segmentos {Adj-SID(L3-4)} y envía los paquetes por la interfaz de salida al Nodo3. El
Nodo11 impone la Lista de Segmentos {Prefix-SID(Nodo3), Adj-SID(L3-4)}. La ruta desde el Nodo11 al
Nodo3 está libre de bucles ya que no se ve afectada por el cambio de topología.

En la segunda fase del proceso de convergencia, los nodos cambian a sus rutas de reenvío habituales. Ya no
imponen ningún segmento adicional a los paquetes, puesto que en ese momento la red está libre de posibles
microbucles. No es necesario que esta segunda etapa se produzca de forma sincrónica en todos los nodos.
Por ejemplo, cuando el Nodo2 cambia a la ruta de reenvío normal, el Nodo6 puede seguir utilizando su ruta
de postconvergencia explícita durante algún tiempo. O viceversa. Las rutas no se afectan .
Figura 9-35: Evitación de microbucle SR

La funcionalidad para evitar microbucles de Enrutamiento por Segmentos evita que se produzcan microbucles
para eventos de enlace único. Estos eventos incluyen fallos y restablecimiento de enlaces, así como cambios en
la métrica del enlace.

La evitación de microbucle SR es un comportamiento local. Cada nodo calcula y aplica individualmente las
rutas SR sin bucle necesarias. No se requiere señalización para estas rutas SR enrutadas en origen en los otros
nodos de la red. La funcionalidad básica de reenvío SR (Prefix-SID, Adj-SID) es necesaria para los nodos en la
ruta post-convergencia.

La evitación de microbucle se aplica al tráfico etiquetado SR y LDP, así como al tráfico IP no etiquetado.

No es necesario realizar una actualización completa de la red para beneficiarse de esta funcionalidad. La
evitación de microbucle SR se puede desplegar de forma incremental, con beneficios incrementales. El tráfico
que pasa a través de nodos que tienen esta funcionalidad activada se beneficia de ella. Los nodos que no tengan
activada esta funcionalidad seguirán causando los microbucles que causaban antes de que se introdujera la
funcionalidad, a menos que la red local
comportamiento de otro nodo que soporta la funcionalidad de evitación de microbucle evita que se produzcan
estos bucles.

La implementación IOS XR de la funcionalidad de evitación de microbucle SR instancian Políticas SRTE para las
rutas de postconvergencia temporalmente explícitas. Esta funcionalidad es equivalente a la funcionalidad TI-
LFA descrita en la sección 9.4.3.

En el momento de escribir este , la funcionalidad de evasión de microbucle aún no se había lanzado para Cisco
IOS XR. Proporcionaremos una actualización y más detalles sobre este tema en una futura revisión de este
libro.

"El despliegue del ALF podría considerarse como una victoria rápida en una red IP que no exija una protección de tráfico garantizada:
es muy sencillo de desplegar (normalmente un comando CLI), es muy fácil de entender y tiene un impacto de escalado insignificante a
la vez que proporciona una cobertura casi buena en las topologías habituales. Implementar RLFA remoto añade un nivel adicional;
aunque también es sencillo de desplegar (un comando CLI), puede ser más difícil de operar, ya que el candidato RLFA necesitaría
aceptar sesiones TLDP de un PLR (característica adicional requerida en cualquier parte de la red). Con RLFA es difícil predecir cuál
sería el mejor RLFA para un destino concreto desde un PLR concreto sin utilizar una herramienta de simulación. Dependiendo del
diseño y del tamaño de la red, un candidato RLFA concreto puede ser utilizado por muchos PLRs, lo que lleva a una configuración
masiva de sesiones TLDP que puede añadir consideraciones de escalado.

Las expectativas de los clientes en cuanto a calidad de la experiencia crecen con naturaleza crítica de sus aplicaciones. Como el
transporte MPLS es la base de la mayoría de los servicios de los operadores, debe ser eficiente y robusto, también porque en una red
pueden ocurrir cosas malas y la red debe adaptarse dinámicamente sin interrumpir las aplicaciones de los clientes. En este ámbito, los
microbucles siempre han sido un problema para las redes IP/MPLS, ya que interrumpen las rutas rápidas o crean microcongestiones.
Durante muchos años me he interesado por la prevención de los microbucles, investigando, evaluando y aplicando múltiples
soluciones.

Pero todas esas soluciones pasadas eran sólo parciales o demasiado complejas para ser desplegadas en una red real: el trabajo sobre la
solución del retardo local fue una primera victoria rápida que sin duda ayudó, pero que no considerarse como una solución definitiva,
ya que no resuelve los microbucles remotos. Soluciones como la FIB ordenada introducían demasiada complejidad: intentar ordenar el
cálculo de los nodos en una red en la que, por diseño, los nodos son independientes entre sí, no era el camino correcto.

Ahora, gracias a los bloques de construcción Segment Routing, tenemos la tecnología para construir fácilmente rutas libres de bucles
en la red de una manera sencilla. Tuve la oportunidad de jugar y evaluar en profundidad un primer código que ejecutaba SR
microloop avoidance, y puedo confirmar que funciona y proporciona de nuevo una solución muy sencilla para evitar microloops para
eventos buenos y malos: un único comando CLI en tus routers y evitarás los microloops."

- Stéphane Litkowski
9.11 Resumen
TI-LFA proporciona protección de enlace, nodo y SRLG por debajo de 50 mseg con una cobertura del 100%.

TI-LFA es fácil de manejar y comprender. La funcionalidad está contenida dentro del IGP y no se
requieren protocolos o señalización adicionales.

La ruta de reparación es calculada automáticamente por el IGP, no se requiere ningún ajuste específico.

Al utilizar la ruta posterior a la convergencia como ruta de reserva, se evita la congestión transitoria y el
enrutamiento subóptimo en la ruta de reserva.

TI-LFA puede desplegarse de forma incremental; es una funcionalidad local y también protege el tráfico
LDP e IP.

La prevención de microbucles SR evita que se produzcan microbucles tras un cambio de topología (subida,
bajada o cambio de métrica del enlace). El tráfico se dirige temporalmente por la ruta posterior a la
convergencia, que queda libre de bucles gracias a las funciones de dirección de tráfico de SR.
9.12 Referencias
[draft-francois-rtgwg-segment-routing-uloop] Francois, P., Filsfils, C., Bashandy, A., y Litkowski, S.,
"Loop avoidance using Segment Routing",draft-francois-rtgwg-segment-routing-uloop (trabajo en curso),
junio de 2016, [Link] segment-routing-uloop.

[draft-francois-spring-segment-routing-ti-lfa] Filsfils, C., Bashandy, A., Decraene, B., and Francois, P.,
"Topology Independent Fast Reroute using Segment Routing", draft-francois-spring- segment-routing-ti-lfa,
(trabajo en curso), abril de 2015, [Link] francois-spring-segment-routing-ti-
lfa.

[ FRANCOIS] Pierre François, "Improving the Convergence of IP Routing Protocols", tesis doctoral,
Université Catholique de Louvain, octubre de 2007, [Link] francois-
phd-thesis_0.pdf.

[ietf-rtgwg-uloop-delay] Litkowski, S., Decraene, B., Filsfils, C. y Francois, P., "Microloop prevention by
introducing a local convergence delay", draft-ietf-rtgwg-uloop-delay (work in progress), junio de 2016,
[Link]

[ MPLSWC14] Bruno Decraene, Stéphane Litkowski, Orange, "Topology independent LFA - Orange
use-case and applicability", MPLS SDN World Congress, París, marzo de 2014,
[Link]

[MPLSWC15] Stéphane Litkowski, Orange, "SPRING interoperability testing report", MPLS SDN
World Congress, París, marzo de 2015, [Link] sdn-2015-
spring-interoperability-testing.

[MPLSWC16] Stéphane Litkowski, Orange, "Avoiding microloops using segment routing", MPLS SDN
World Congress, París, marzo de 2016, [Link] sdn-2016-
microloop-avoidance-with-segment-routing-63809004.

[RFC4202] Kompella, K., Ed., e Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-
Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, octubre de 2005,
[Link]

[RFC4203] Kompella, K., Ed., e Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-
Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, octubre de 2005,
[Link]
[RFC5286] Atlas, A., Ed., y A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates",
RFC 5286, DOI 10.17487/RFC5286, septiembre de 2008, [Link]

[RFC5307] Kompella, K., Ed., e Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-
Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, octubre de 2008,
[Link]

[RFC5715] Shand, M. y S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, DOI
10.17487/RFC5715, enero de 2010, [Link]

[RFC6571] Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., y M.
Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571,
DOI 10.17487/RFC6571, junio de 2012,
[Link]

[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M. y N. So, "Remote Loop-Free Alternate (LFA)
Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, abril de 2015,
[Link]

[RFC7916] Litkowski, S., Ed., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., y P. Sarkar, "Operational
Management of Loop-Free Alternates", RFC 7916, DOI 10.17487/RFC7916, julio de 2016,
[Link]

1 El orden de actualización de los prefijos es aleatorio. Pero los prefijos clasificarse en clases de prioridad,
actualizándose antes los prefijos de una clase de prioridad más alta que los de una clase de prioridad más baja.
Por defecto, los prefijos de host tienen mayor prioridad que los prefijos que no son de host.

2 Una Política de Ingeniería de Tráfico SR (SRTE) (a veces llamada Política de Encapsulación SRTE) es la
construcción de reenvío que impone uno o más segmentos a los paquetes que se dirigen a ella. Aunque tiene
propiedades diferentes, a menudo se ve como la contrapartida SR de un túnel RSVP-TE.

3 Package Installation Envelopes (PIE) es un paquete de software que se instala sobre el paquete de software
Cisco IOS XR base y se utiliza para habilitar ciertas funcionalidades que no se incluyen en el paquete de
software base.
4 El TI-LFA IETF draft-francois-rtgwg-segment-routing-ti-lfa propone otro método para el caso de que un
prefijo-SID siga al Adj-SID en la pila de etiquetas: pop Adj-SID y forward al Prefijo-SID que estaba debajo.
Esto no está implementado en la implementación de Cisco IOS-XR en el momento de escribir este libro..

5 Este es el peor de los casos. La duración de un microbucle es, de hecho, el tiempo delta entre las
actualizaciones de la entrada de reenvío de los nodos que participan en el microbucle.
10 INTERCONEXIÓN A GRAN ESCALA CON
ENRUTAMIENTO POR SEGMENTOS
El espacio de etiquetas MPLS "sólo" contiene alrededor de 1 millón de etiquetas (220). A diferencia de IP, no
existe el concepto resumen de etiquetas ni de etiqueta por defecto. Cada nodo necesita su propia etiqueta
específica para el reenvío. En redes a gran escala con millones de puntos finales, esto significaría millones de
entradas en las tablas de reenvío. Esto no es deseable para los conmutadores de centros de datos de bajo coste o
los nodos de acceso Metro Ethernet de los proveedores de servicios. El enrutamiento por segmentos MPLS
puede escalar la red para soportar cientos de miles de nodos y decenas de millones de puntos finales
subyacentes físicos, al tiempo que sólo requiere unas pocas decenas de miles de entradas en tablas de reenvío.

DESTACADO: Un SRGB más grande es posible y a menudo la mejor opción

En esta secciónutilizamos el SRGB predeterminado como ilustración "extrema". Demostramos que incluso con un SRGB muy
pequeño de 8000 etiquetas globales, podemos escalar a una red de cientos de miles de nodos y decenas de millones de puntos finales
subyacentes físicos.

Obviamente, si un despliegue específico se compone de 20k nodos, uno puede simplemente utilizar un SRGB de 20k etiquetas
globales (probablemente 32k para el crecimiento futuro) y utilizar un diseño clásico en el que cada nodo recibe su propio prefijo SID
globalmente único.

Conceptualmente, al SRGB se le puede asignar un tamaño mucho mayor (por ejemplo, 256k entradas).

El diseño jerárquico a hiperescala presentado en esta sección debe aprovecharse cuando el número de nodos supere el tamaño del espacio
de etiquetas MPLS o cuando sea necesario minimizar las capacidades FIB de los nodos de la red.

Algunos aspectos de este nuevo modelo de diseño también son objeto del borrador del IETF "filsfils-spring-large-scale-interconnect".

Con transiciones como Internet de las Cosas (IoT) y el aumento de los dispositivos móviles, el número de dispositivos que se conectan
a la red se dispara. Como consecuencia, las redes también necesitan escalarse para gestionar este crecimiento. Este modelo de diseño
habilitado por el enrutamiento por segmentos permite escalar la red manteniendo la sencillez de las operaciones.
10.1 Consideraciones sobre la aplicabilidad
En la mayoría de las redes, resulta beneficiosa la simplicidad que proporcionan los diseños clásicos y el uso de
un SRGB homogéneo en todo el dominio. Los conceptos tradicionales de diseño IGP de áreas/niveles ayudan
con aspectos de escalabilidad y estabilidad. Nótese que SRGB puede crecer para acomodarse y asegurar que
cada router en estas redes pueda obtener sus propios Node-SIDs y también para diferentes endpoints de
servicio.

Sin embargo, hay ciertas redes a gran escala que se dividen en múltiples dominios al gran número de routers y
puntos finales de servicio que deben gestionarse. La arquitectura MPLS sin fisuras (véase draft-ietf-mpls-
seamless-mpls) es uno de esos diseños de referencia que se utilizan para grandes redes de agregación. Otro
aspecto a tener en cuenta es la escalabilidad de las plataformas de encaminamiento implicadas, especialmente
nodos de acceso/agregación en una red de agregación o los conmutadores de la parte superior del bastidor y de
hoja en el centro de datos. Estas plataformas, al ser dispositivos de menor coste en comparación con las
plataformas de enrutamiento de núcleo y de borde, tienen una escala FIB inferior. Por lo tanto, es necesario
garantizar la conectividad IP/MPLS de extremo a extremo desde cualquier punto final de servicio y, al mismo
tiempo, no disparar el número de entradas de reenvío necesarias, especialmente en nodos de hoja o de acceso.
El modelo de diseño descrito en este capítulo aplicarse más adecuadamente a la interconexión de Centros de
Datos a escala masiva o a grandes redes de agregación de Proveedores de Servicios.
10.2 Diseño de referencia
La topología de red del diseño de referencia se ilustra en la Figura 10-1. La red está estructurada en dominios
hoja (Leaf1, Leaf2, ...) interconectados por un dominio Core central. En la ilustración sólo se muestran dos
dominios hoja. Cada dominio ejecuta Segment Routing con su propio protocolo de enrutamiento independiente
(por ejemplo: IS-IS, OSPF, BGP). Cada dominio hoja Leafk se conecta al dominio Core con dos o más nodos
denominados Xka y Xkb. Cada nodo X ejecuta dos protocolos de enrutamiento SR independientes: uno en
dominio hoja y otro en dominio núcleo.

Se asume un SRGB común de [16000-23999] en todos los dominios. Es posible elegir cualquier otro SRGB
común. Suponemos además que el subrango [16000-17999] del SRGB se utiliza únicamente para
proporcionar segmentos de prefijo en el dominio central, mientras que el subrango [18000-23999] se reutiliza
para proporcionar segmentos de prefijo en cualquier dominio de hoja. Cualquier otra opción para dividir el
SRGB en subrangos es posible. Nótese que estos subrangos sólo existen administrativamente; todos los nodos
siguen asignando el SRGB completo.

Figura 10-1: Diseño de referencia de interconexión a gran escala

El mismo subrango SRGB [18000-23999] se reutiliza para proporcionar segmentos de prefijo en cualquier
dominio de hoja. Por ejemplo, el operador asignó el mismo Prefijo-SID 18001 a los nodos A y C de los
dominios de hoja Leaf1 y Leaf2 respectivamente. El subrango SRGB [16000-17999] no se reutiliza, sino que
se dedica a asignar Prefijo-SID para nodos de dominio Core. Por ejemplo, el operador asignó el Prefijo-SID
16001 al nodo X1a en el dominio Core. Este Prefijo-SID es único en todos los dominios.

El operador asigna dos Prefix-SID del subrango SRGB del dominio Core a cada nodo X: uno que identifica de
forma única al nodo (Node-SID) mientras que el otro es compartido por ellos (es decir, Anycast-SID) e
identifica el par de nodos X que interconectan el dominio leaf Leafk con el dominio core. El nodo X1a de la
Figura 10-1 tiene el Prefix-SID 16001 y el Anycast-SID 16901, mientras que el nodo X1b tiene el Prefix-SID
16003 y el Anycast-SID 16901. El Anycast-SID proporciona equilibrio de carga y redundancia simple de
nodos. Al enviar tráfico a un Anycast-SID, el tráfico será gestionado por el nodo más cercano que anuncie este
Anycast-SID, o se equilibrará la carga entre varios nodos si están a la misma distancia del origen. Si uno de los
nodos X falla, el otro toma el relevo sin problemas gracias a la propiedad del Anycast-SID. Los Anycast-SIDs
también son importantes para las Políticas de Ingeniería de Tráfico de Enrutamiento por Segmentos que se
despliegan en este modelo, pero esto es algo que cubriremos en la siguiente parte del libro.

Todos los prefijos (y sus Prefix-SIDs) de los nodos X se redistribuyen desde el dominio core a dominios leaf, y
ningún otro prefijo se redistribuye desde el dominio core a los dominios leaf. Ningún prefijo se redistribuye de
un dominio hoja al dominio principal. Por lo tanto, la tabla de reenvío de un nodo interno dentro del dominio
core no contiene ninguna entrada para segmentos en el rango [18000-23999] (el sub-rango SRGB de los
dominios leaf). Esto se ilustra en la Figura 10-2.
Figura 10-2: Redistribución entre dominios

Un nodo de un dominio de hoja sólo tiene entradas de reenvío para todos los segmentos del dominio de hoja
local y para los segmentos de prefijo hacia todos los nodos X de la red. Por ejemplo, el nodo A del dominio de
hoja L1 tiene una entrada de reenvío para Anycast-SID 16902, que conduce al par X2a y X2b y, por ejemplo,
también para Prefix-SID 16005, que conduce al nodo X2a.

10.2.1 Nodos de interconexión

Con este diseño, cualquier nodo hoja puede interconectarse con cualquier otro nodo hoja. Y cualquier punto
final puede conectarse a cualquier punto final. Para empezar, supongamos que un nodo hoja puede obtener el
SID de la propia hoja remota y los saltos intermedios en la ruta para llegar a la hoja remota con sus SID a través
de algún mecanismo "fuera de banda".

La Figura 10-3 ilustra la interconexión de nodos.

Figura 10-3: Interconexión de nodos

El nodo A utiliza la lista de segmentos {18002} para llegar al nodo B por el camino más corto. El SID 18002 es
el Prefijo-SID del nodo B. Este es un ejemplo de conectividad intradominio; ambos nodos están situados en el
mismo dominio hoja.

Para proporcionar conectividad entre dominios, la lista de segmentos contiene un código postal de dominio, que
identifica un dominio, y un nombre de calle. El código postal de dominio es el segmento Anycast de los nodos
fronterizos dominio de destino. El nombre de la calle es el segmento de prefijo del nodo de destino en ese
dominio.
El nodo A puede llegar al nodo C por el camino más corto a través de cualquier nodo intermedio X utilizando la
lista de segmentos
{16902, 18001}. El SID 16902 es el Anycast-SID de los nodos X que interconectan el dominio Leaf 2 con el
dominio Core (nodos X2a y X2b), y el SID 18001 es el Prefix-SID del nodo C en el dominio Leaf2.

Para que el nodo A llegue al nodo C por el camino más corto a través de un nodo específico, por ejemplo a
través del nodo X2a, el nodo A puede utilizar la Lista de Segmentos {16002, 18001}. El SID 16002 es el
Prefijo-SID del nodo X2a. Este es un ejemplo de conectividad entre dominios; ambos nodos están situados en
un dominio de hoja diferente.

Este libro no pretende cubrir cómo un nodo fuente deriva y programa la Lista de Segmentos para alcanzar un
nodo remoto o punto final. La configuración estática o un controlador centralizado son candidatos obvios.
Esto se maneja utilizando los conceptos de TE de Enrutamiento de Segmentos que es un tema que se tratará en
el próximo libro.

10.2.2 Interconexión de puntos finales

La Figura 10-6 muestra puntos finales conectados a los nodos A y C. Estos puntos finales pueden ser, por
ejemplo, un Dispositivo de Interfaz de Red (NID) o una Máquina Virtual (VM). El nodo hoja asigna un SID de
Adyacencia para cada endpoint conectado. Los Segmentos de Adyacencia son localmente significativos para el
nodo; por lo tanto, cada nodo hoja puede asignar los mismos SID de Adyacencia. Siguiendo con la comparación
con el servicio postal, el segmento de adyacencia es el número de casa. Un punto final puede estar conectado a
más de un nodo hoja (multi-homed).

Figura 10-4: Interconexión de puntos finales

Para alcanzar un punto final conectado a un nodo hoja, el segmento local del nodo hoja para ese punto final
debe añadirse a la Lista de Segmentos. Por ejemplo, para alcanzar el punto final C1, conectado al nodo C, desde
el punto final A1, conectado al nodo A, se puede utilizar la Lista de Segmentos {16004, 18001, 30001}. Los
dos primeros segmentos dirigen los paquetes al nodo hoja C a través del nodo X2b, luego el SID local 30001
del nodo C dirige los paquetes al punto final C1. Al igual que en el ejemplo anterior, si no hubiera necesidad de
pasar específicamente por X2b, se podría haber utilizado el SID Anycast del par (X2a, X2b) como primer
segmento de la ruta.

El descubrimiento de los puntos finales del servicio a través de algún mecanismo "fuera de banda" está de
nuevo fuera del alcance de este libro y se tratará en un próximo libro.
10.3 Opciones de diseño
10.3.1 Dimensionamiento de los dominios hoja y núcleo
El operador puede elegir no redistribuir ninguna ruta entre los dominios, ni siquiera las rutas para los X. Esta
opción de diseño disminuye la cantidad de entradas de reenvío que se requieren en los nodos de los dominios
hoja. En ese caso se debe añadir un segmento más a la Lista de Segmentos que exprese la ruta de extremo a
extremo. Por ejemplo, la ruta del nodo A al nodo C a través de cualquier nodo X intermedio utiliza la Lista de
Segmentos {16901, 16902, 18001}. El SID 16901 es el Anycast-SID de los nodos X que interconectan el
dominio Leaf1 con el dominio Core (nodos X1a y X1b). Este SID lleva los paquetes al nodo X1a o X1b. SID
16902 es el Anycast-SID de los nodos X2a y X2b, y lleva los paquetes a uno de estos nodos. SID 18001 es el
Prefix-SID del nodo de destino C.

Seguimos suponiendo que existe un mecanismo "fuera de banda" que proporciona a la hoja la información de
conectividad, de forma similar a los casos anteriores.

Figura 10-5: Conectividad sin redistribución

10.3.2 Subdominios
Para aumentar aún más la escala, se puede introducir en el diseño de referencia un tercer nivel de jerarquía
denominado "Subhoja". Estos dominios subhoja están conectados a los dominios hoja.
Figura 10-6: Dominios de las subhojas

En la Figura 10-6, los dominios subhoja SubLeaf11 y SubLeaf21 se han añadido a la topología de red. Los
dominios sub-hoja están conectados a los dominios hoja a través de dos (o más) nodos Y. El subespacio SRGB
[18000-23999] que se asignó inicialmente a los dominios hoja se divide en dos subespacios: [18000-19999]
para la asignación de SIDs en los dominios hoja y [20000-23999] para la asignación de SIDs en el dominio
subhoja. A cada nodo Y se le asigna un Anycast-SID y un Prefix-SID del subespacio SRGB de la hoja. Por
ejemplo, el Prefix-SID 18001 y el Anycast-SID 18901 se asignan a Y21a. Cada nodo dentro de un dominio de
subhoja recibe un Prefijo-SID único del subrango SRGB de ese (por ejemplo, G recibe 20001).

El nodo E puede llegar al nodo G por el camino más corto a través de cualquier nodo intermedio X y cualquier
nodo intermedio Y utilizando la Lista de Segmentos {16902, 18901, 20001}. SID 16902 es el Anycast-SID de
los nodos X2a y X2b). El SID 18901 es el Anycast-SID de los nodos Y21a e Y21b, y el SID 20001 es el
Prefix-SID del nodo E.

10.3.3 Ingeniería de tráfico

Hasta ahora sólo se había hablado del transporte por el camino más corto. Sin embargo, SR ofrece la
posibilidad de dirigir paquetes por cualquier camino de extremo a extremo a través de la red. Esto permite
dirigir el tráfico de servicio por una ruta que satisfaga los requisitos del servicio, sin crear ningún estado
adicional en los nodos distintos del nodo de origen.
SR puede utilizarse para diseñar flujos de tráfico dentro de cada dominio de hoja o núcleo. Véase la topología
de la Figura 10-7. Por ejemplo, un flujo desde el nodo A en el dominio Leaf1 al nodo X1a dentro del mismo
dominio Leaf1 podría ser dirigido a través del nodo P utilizando la política SRTE {18009, 16001}. Del mismo
modo, un flujo desde el nodo X1a al nodo X2a dentro del dominio core podría ser dirigido a través del nodo Z
con la Política SRTE {16009, 16002}.

Del mismo modo, un flujo dirigirse entre dominios. Por ejemplo, un flujo del nodo A en el dominio Hoja1 al
nodo D en el dominio Hoja2 podría dirigirse a través de la ruta A→ B→ X1a→ X2b→ R→ D utilizando la
política SRTE {18002, 16001, 16004, 18009, 18002}.

Figura 10-7: Ilustración de ingeniería de tráfico

La ingeniería de tráfico SR no entra en el ámbito de este primer libro y se tratará en la siguiente parte.

DESTACAR

Conectividad MPLS de extremo a extremo en redes a gran escala El diseño de interconexión a gran escala con SR proporciona
conectividad MPLS de extremo a extremo de forma sencilla y escalable. El beneficio real es la capacidad de hacer Ingeniería de
Tráfico interdominio con SR (que se tratará en la siguiente parte de este libro) también de una manera simple y escalable similar
con controladores.
10.4 Ejemplo de escala
En esta sección se analizan las propiedades de escalado de una red de ejemplo que sigue el diseño de
referencia descrito anteriormente. La red consta de un único dominio central y 100 dominios hoja. El rango
SRGB predeterminado [16000-23999] se divide en dos subrangos: [16000-17999] para el dominio central y
[18000-23999] para los dominios hoja.

Los números de escala se ilustran en la Figura 10-8. Cada dominio de hoja contiene 6000 nodos. Asumiendo
que se asigna un Prefijo-SID para cada nodo, entonces cada dominio hoja contiene 6000 Prefijos-SID. Este es el
máximo para el subrango SRGB que se reservó para los dominios hoja. Si se desean dominios hoja mayores el
SRGB puede ampliarse para acomodarlos.

Cada nodo de un dominio de hoja tiene 500 endpoints conectados a él, por lo que se programan 500 Adj-
SID en cada nodo de hoja; uno por endpoint conectado. En total hay 3 millones (= 6000 * 500) de puntos
finales por dominio de hoja. Con 100 dominios hoja esto hace un total de 300 millones de endpoints.

Figura 10-8: Ejemplo a gran escala de interconexión

Cada nodo X se conecta a un solo dominio de hoja, y cada dominio de hoja se conecta al dominio central a
través de dos nodos X. Se asigna un Anycast-SID a cada par de nodos X. Aparte de los nodos X, el dominio
central contiene 100 nodos internos para interconectar los nodos X. Supongamos que se asigna un Prefix-SID a
cada uno de estos internos del dominio central. El dominio central tiene entonces 2 * 100 Prefix-SIDs y 100
Anycast-SIDs para los nodos X, y 100 Prefix-SIDs para los nodos centrales internos.

Todos los Prefijo-SID del nodo X se redistribuyen en cada dominio

hoja. A escala de toda la red:

6000 (nodos por dominio de hoja) * 100 (número de dominios de hoja) = 600000 nodos

6000 (nodos por dominio de hoja) * 100 (número de dominios de hoja) * 500 (puntos finales por nodo de
hoja) = 300 millones de puntos finales

Escala SID por nodo:

Nodo hoja: 6000 (nodo hoja Prefix-SIDs)+ 200 (nodo X Prefix-SIDs)+ 100 (nodo X Anycast- SIDs) + 500
(endpoint Adj-SIDs) = 6800 SIDs

Nodo X 6000 (nodo hoja Prefix-SIDs)+ 200 (nodo X Prefix-SIDs)+ 100 (nodo X Anycast-SIDs)
+ 100 (nodo central interno Prefijo-SIDs)= 6400 SIDs

Nodo central interno: 200 (X node Prefix-SIDs)+ 100 (X node Anycast-SIDs)+ 100 (internal core node
Prefix-SIDs) = 400 SIDs

El cálculo anterior no incluye los Adj-SID de los enlaces de interconexión. Estos son locales a cada nodo y su
número suele ser < 100.

Dependiendo de las capacidades de la tabla de reenvío de los nodos hoja, dominios hoja pueden dividirse en
múltiples sub-dominios hoja más pequeños. Por ejemplo, todos los dominios hoja se reducen para contener
1000 por dominio. Para mantener el número total de puntos finales (300 millones), el número de dominios hoja
se incrementa a 600. Cada nodo X se conecta sólo a un dominio hoja, y cada dominio hoja se conecta al núcleo
a través de dos nodos X. Por tanto, el número de nodos X es de 1200. Se asignan tres Prefix-SID por par de
nodos X: un Prefix-SID para cada nodo individual y un Anycast-SID para el par. La escala de SID por nodo es
entonces:
Nodo hoja: 1000 (nodo hoja Prefix-SIDs)+ 1200 (nodo X Prefix-SIDs)+ 600 (nodo X Anycast- SIDs) + 500
(endpoint Adj-SIDs) = 3300 SIDs

Nodo X 1000 (Prefix-SIDs del nodo hoja)+ 1200 (Prefix-SIDs del nodo X)+ 600 (Anycast- SIDs del nodo
X) + 100 (Prefix-SIDs del nodo interno) = 2900 SIDs

Nodo central interno: 1200 (nodo X Prefix-SIDs)+ 600 (nodo X Anycast-SIDs)+ 100 (nodo interno
Prefix-SIDs) = 1900 SIDs
10.5 Modelos de implantación
Este modelo de diseño puede desplegarse en un greenfield, utilizando Segment Routing end-to-end. También
puede desplegarse en un proyecto "brownfield" interoperando con una red MPLS sin costuras existente [draft-
ietf-mpls-seamless-mpls] (MPLS sin costuras también se denomina "MPLS unificado"), véase la Figura 10-9.

Figura 10-9: Despliegue Brownfield, interfuncionamiento con MPLS sin fisuras

Otro enfoque ampliamente debatido consiste en habilitar SR en los dominios IGP en un diseño de red MPLS
sin fisuras existente. El mejor esfuerzo o los servicios existentes siguen funcionando basándose en la
conectividad de extremo a extremo proporcionada a través de BGP-LU en el diseño jerárquico (MPLS sin
fisuras). Los nuevos servicios que aprovechan las capacidades SRTE (que se tratarán en el próximo libro) se
despliegan utilizando Listas de Segmentos extremo a extremo, tal y como se describe en este capítulo. Los
servicios de mejor esfuerzo también pueden migrarse posteriormente para utilizar Listas de Segmentos de
"mejor esfuerzo" de extremo a extremo similares. También son posibles otras combinaciones de diseño, pero
quedan fuera del alcance de este libro.
10.6 Beneficios
Este modelo de diseño aporta una serie de ventajas al despliegue de redes a gran escala. Proporciona una forma
sencilla de escalar la red MPLS utilizando el SR existente, sin necesidad de realizar cambios en el protocolo
para soportarlo. Los nodos de la red sólo necesitan ejecutar un único protocolo, un IGP. Como cada trayecto de
extremo a extremo se expresa como una lista de segmentos, utilizan todos los ECMP disponibles en el trayecto
hacia el destino para cada uno de segmentos de prefijo de la lista. El uso de segmentos Anycast para los nodos
X (nodos frontera) permite a ECMP cruzar los límites del dominio. El LFA independiente de la topología, que
está disponible una vez habilitado el enrutamiento por segmentos, proporciona una protección inferior a 50 ms
mediante la reparación local de cualquier fallo de enlace/nodo/SRLG para todos los servicios, de forma
sencilla, automatizada, escalable y distribuida No existe complejidad operativa para implementar diferentes
mecanismos de protección para diferentes servicios a la escala masiva requerida a través de los dominios.
Además de todo esto, existe la capacidad de ofrecer capacidades de Ingeniería de Tráfico de extremo a extremo
para habilitar servicios más nuevos mediante la imposición de una Lista de Segmentos en el paquete por parte
de la fuente, sin necesidad de añadir ningún estado por servicio/flujo en ninguna parte de la .

"La práctica de dividir las redes en dominios IGP separados es cada vez más frecuente a medida que se escalan y convergen para
gestionar múltiples servicios. Las razones de estas redes multidominio son generalmente aspectos de escalabilidad, su función (por
ejemplo, núcleo, agregación regional, etc.), sus servicios (por ejemplo, servicio de Internet, servicio VPN, etc.) o razones
administrativas o una mezcla de éstas. La solución de diseño de interconexión a gran escala con SR permite esta transición y el de la
red. Y lo que es más importante, permite las soluciones de ingeniería de tráfico multidominio de extremo a extremo que hasta no
estaban disponibles en un modelo sencillo y escalable."

- Ketan Talaulik ar
10.7 Resumen
Utilice el enrutamiento por segmentos para ampliar la red de modo que admita cientos de miles de nodos de
red y decenas de millones de puntos finales subyacentes.

El modelo de interconexión a gran escala proporciona un diseño de red flexible y fácil de manejar, por
ejemplo, tamaño flexible del dominio de hoja, dominios de subhoja, ...

La solución proporciona interoperabilidad con los diseños de red existentes, por ejemplo, LDP/RSVP-TE,
diseño MPLS sin fisuras.

El diseño aprovecha al máximo el SR distribuido en cada dominio y proporciona reenvío optimizado y Alta
Disponibilidad: aprovecha ECMP, protección TI-LFA y proporciona capacidades TE de extremo a extremo.
10.8 Referencias
[draft-filsfils-spring-large-scale-interconnect] Filsfils, C., Cai, D., Previdi, S., Henderickx, W., Shakir, R.,
Cooper, D., Ferguson, F., Lin, S., Laberge, T., Decraene, B., Jalil, L., y J. Tantsura, "Interconnecting
Millions Of Endpoints With Segment Routing", draft-filsfils-spring-large-scale- interconnect (trabajo en
curso), septiembre de 2016, [Link] spring-large-scale-interconnect.

[ draft-ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., y D.

Steinberg, "Seamless MPLS Architecture", draft-ietf-mpls-seamless-mpls (work in progress), octubre de
2015, [Link]
11 VERIFICACIÓN DE LA CONECTIVIDAD EN
LA RED SR MPLS
Un operador tiene múltiples opciones para verificar la accesibilidad a un destino: a menudo se intenta primero
un ping para verificar la conectividad básica, seguido de un traceroute al destino para aislar el punto fallo si el
ping falla. Traceroute también se utiliza por sí mismo para comprobar si la ruta real que se sigue a través del
destino en la red es la esperada por el diseño; por tanto, es más que una simple herramienta de análisis de
fallos.

Este libro se referirá a menudo a estas populares herramientas como "IP ping" e "IP traceroute" para de sus
homólogas MPLS. IP ping e IP traceroute utilizan el Protocolo de Mensajes de Control de Internet (ICMP) para
sus paquetes de sondeo y/o retorno. A pesar del nombre que , IP ping e IP traceroute también pueden utilizarse
en redes MPLS. ICMP se ha ampliado para mejorar el soporte de IP traceroute en redes MPLS, pero
básicamente son las mismas herramientas.

Sin embargo, existen algunas deficiencias de IP ping e IP traceroute cuando se utilizan para la verificación en
redes MPLS, por lo que se introducen herramientas específicas MPLS que se basan en el paradigma de ping y
traceroute: MPLS ping y MPLS traceroute, también llamadas LSP ping y LSP traceroute. Se trata de nuevas
herramientas que sólo tienen en común su nombre con sus homólogas IP. Estas herramientas MPLS no
utilizan ICMP para sus paquetes de sondeo y retorno, sino su propio protocolo.

En este capítulo se analizan con más detalle todas estas herramientas, así como su aplicación y uso en las redes
de enrutamiento por segmentos.
11.1 Herramientas de PI existentes
Dos herramientas de red clásicas -ping y traceroute- son la base de casi todos los procesos de solución de
problemas de red. Ping verifica la conectividad a un destino y con traceroute se puede encontrar el punto en el
que se interrumpe la ruta de la red.

Los comandos IP ping y traceroute son conscientes de VRF en Cisco IOS XR. Se pueden utilizar dentro de
un VRF en el nodo PE L3VPN para solucionar problemas y verificar la accesibilidad a los nodos CE y otros
dispositivos de la VPN.

11.1.1 Ping IP
IP Ping es una herramienta ampliamente utilizada. Ping utiliza paquetes ICMP Echo Request y Reply para
verificar la conectividad a un destino. También mide un retraso grueso de ida y vuelta al destino y puede medir
la pérdida de paquetes gruesos.

El emisor envía un paquete ICMP Echo Request, que contiene un Identificador y un Número de Secuencia.
Estos dos campos se utilizan para hacer coincidir la respuesta con la solicitud. Para medir el tiempo de ida y
vuelta, se recoge una marca de tiempo al transmitir la petición de eco. Normalmente, esta marca de tiempo se
incluye en la carga útil para reducir el estado que debe guardarse. El TTL IP del paquete se establece
normalmente en 255. La dirección de origen es una dirección local alcanzable, normalmente la dirección de la
interfaz saliente.

El objetivo responde con un paquete ICMP Echo Reply, devolviendo los datos recibidos en el mensaje Echo
Request. Estos datos incluyen los campos Identificador y Número de secuencia, así como la carga útil, que
normalmente contiene la marca de tiempo de transmisión.

El nodo de origen recibe el ICMP Echo Reply, recoge la marca de tiempo actual y utiliza la marca de tiempo de
transmisión, normalmente incrustada en la carga útil del paquete ICMP Echo Reply, para calcular el tiempo de
ida y vuelta del . El resultado se muestra al usuario.

11.1.2 Rastreo de IP
Cuando se utiliza el comando traceroute, se envían sondas a la dirección de destino especificada por el usuario.
Normalmente, sondas son paquetes UDP con un número de puerto UDP de destino que comienza en 33434[ 1].
Las sondas se envían sucesivamente con valores de campo IP TTL crecientes. El primer paquete de sonda tiene
IP TTL establecido en 1, el siguiente paquete de sonda tiene IP TTL establecido en 2, y así sucesivamente. El
número de puerto de destino UDP es
normalmente se incrementa por cada sonda que se envía. Otras implementaciones sólo incrementan el puerto
UDP cuando incrementan el valor TTL. Los nodos de la red pueden incluir el puerto UDP de destino en el cálculo
hash de equilibrio de carga (hash L4 o 7-tuple). Así, cada vez que se utiliza un puerto UDP diferente para un
paquete de sonda, éste puede seguir otra ruta a través de la red. Esto será visible en la salida de traceroute.

Dado que el primer paquete de sondeo tiene un TTL IP de 1, el TTL del paquete expira en el nodo nexthop. Ese
nodo genera un mensaje de Protocolo de Mensajes de Control de Internet (ICMP) de tipo "Tiempo excedido"
(ICMP tipo 11, código 0) y lo envía a la dirección de origen del paquete de sonda. Este mensaje ICMP también
incluye la cabecera y parte de la carga útil del paquete sonda. La dirección de origen de este mensaje ICMP es
la dirección IP de la interfaz en la que recibió el paquete sonda. [2]

El programa traceroute puede correlacionar el mensaje ICMP recibido con el paquete sonda basándose en el
puerto UDP del paquete sonda, ya que el mensaje ICMP también incluye la cabecera original del paquete sonda.

La salida del comando traceroute muestra el valor TTL del paquete sonda, la dirección de origen del mensaje
ICMP devuelto y el retardo de ida y vuelta. La dirección de origen del mensaje ICMP es la interfaz de entrada
del paquete sonda en el nodo que generó este paquete ICMP. Por defecto, se envían tres sondas para cada valor
TTL con el fin de obtener más estadísticas de retardo para cada salto de la ruta y compensar la posible pérdida
de paquetes.

A continuación, el programa traceroute envía un paquete sonda con el TTL de IP establecido en 2. El nodo
nexthop reenvía este paquete como de costumbre, disminuye el TTL como para cualquier paquete. El TTL
del paquete de sondeo expira en el segundo nodo de la ruta hacia el destino. Este nodo envía un mensaje
ICMP "Time Exceeded" y la salida de traceroute muestra la información del segundo salto.

Este proceso se repite hasta que se alcanza el destino especificado en el comando traceroute sin que expire el
TTL. El nodo de destino (con suerte) no está esperando ningún paquete en el puerto de destino UDP del paquete
sonda, no hay ninguna aplicación usando ese puerto UDP. La razón para usar los puertos de destino UDP
empezando por 33434, es para hacer improbable que una aplicación esté usando ese puerto UDP. La Autoridad
de Asignación de Números de Internet (IANA) ha asignado el puerto UDP 33434 a traceroute, y ha dejado los
puertos 33435-33655 sin asignar. Como el nodo de destino no está escuchando el puerto UDP, genera un
mensaje ICMP "Port Unreachable" (ICMP tipo 3, código 3) y lo envía a
la dirección de origen del paquete sonda. La salida del comando traceroute muestra entonces la información del
último salto. Aquí se detiene el comando traceroute.

Figura 11-1: Ejemplo de traceroute IP en red IP

11.1.3 IP Ping, Traceroute y ECMP

Los multitrayectos de igual coste están omnipresentes en las redes IP. En presencia de ECMP, la red equilibra la
carga de tráfico en los diferentes caminos para llegar al destino. Un fallo en uno de estos
provoca una pérdida parcial de paquetes y puede pasar desapercibida para un mecanismo de verificación de
rutas que no tenga en cuenta el ECMP.

IP ping y traceroute no son inherentemente conscientes de ECMP; la ruta que los paquetes de sonda utilizan
para llegar a su destino depende totalmente del mecanismo hashing de equilibrio de carga de los nodos de
tránsito. El operador podría modificar los campos de la cabecera IP de los paquetes de sondeo para intentar
dirigirlos por la ruta deseada. El operador podría, por ejemplo, especificar una dirección de origen diferente en
el comando ping o traceroute. Sin embargo, este método es, cuando menos, engorroso.

IP ping y traceroute no soportan el descubrimiento de rutas por diseño. No proporcionan una metodología
exhaustiva y determinista para descubrir todos los ECMP hacia un destino en la red. Tampoco proporcionan
una forma sencilla de ejercitar una ruta específica de los ECMP disponibles, ya que están restringidos al uso
de direcciones IP de origen y destino alcanzables para los paquetes de sondeo.

11.1.4 Ping IP en entorno MPLS

La herramienta de ping IP no conoce la red MPLS. Envía sus paquetes de sondeo como paquetes ICMP y deja
que la capa de enrutamiento decida cómo se reenvían estos paquetes. Si utiliza IP ping en una red MPLS, la
capa de enrutamiento impone las mismas etiquetas a los paquetes ICMP generados que a otros paquetes IP que
van al mismo destino. También los paquetes ICMP Echo Reply pueden seguir la ruta de retorno MPLS si la capa
de enrutamiento así lo decide. Así pues, la funcionalidad básica del ping IP funciona en una red MPLS. La
mayor desventaja del ping IP en un entorno MPLS es que no puede detectar fallos LSP que no afecten a la
conectividad IP. Ping devuelve éxito siempre y cuando haya alcanzabilidad IP, incluso si el Label Switched
Path está roto. Supongamos, por ejemplo, que la ruta de conmutación de etiquetas entre dos PEs está rota.
Mientras resuelve el problema, el operador intenta un ping entre dos PEs. Este ping sigue teniendo éxito ya que
la red continúa reenviando paquetes ICMP utilizando el reenvío IP normal, como paquetes sin etiquetar. Parece
como si la conectividad de extremo a extremo se mantuviera, mientras que la ruta conmutada por etiquetas está
realmente rota. Esta situación provoca la caída del tráfico de servicio, independientemente del resultado
positivo del ping.

11.1.5 Traceroute IP en entorno MPLS

IP traceroute también se puede utilizar en un entorno MPLS. Pero al igual que para IP ping, hay limitaciones
con el uso del comando IP traceroute en dicho . La herramienta IP traceroute no conoce la red MPLS. Envía
sus paquetes de sondeo como paquetes IP y deja que la capa de enrutamiento decida sobre
cómo se reenvían estos paquetes. Si reciben una cabecera MPLS, el valor TTL de IP se copia en el
campo TTL de MPLS. El campo MPLS TTL de la etiqueta superior se decrementa cuando el paquete
viaja a través de la red.

Si el TTL de la etiqueta superior del paquete de sonda encapsulado MPLS expira en un nodo, el nodo genera un
ICMP "Time Exceeded". Como se describe en el capítulo 3, "Segment Routing MPLS Data Plane", el nodo
añade la pila completa de MPLS del paquete sonda recibido en el mensaje ICMP, utilizando las extensiones
ICMP (IETF RFC 4950). A continuación, el nodo impone la pila de etiquetas del paquete de sonda recibido en
el mensaje ICMP generado, tal como se especifica en IETF RFC 3032. Por lo tanto, el mensaje ICMP se
reenvía en sentido descendente en el LSP original del paquete de sonda. Si el Label Switched Path (LSP) al
destino está intacto, entonces el mensaje ICMP alcanza el final del LSP. En ese punto se expone la cabecera IP
del paquete ICMP y desde ahí este paquete ICMP se reenvía a su dirección de destino utilizando el reenvío
normal. El destino de este mensaje ICMP es el nodo que ejecuta el comando traceroute.

El programa traceroute recibe el mensaje ICMP y muestra la información al , incluyendo la pila de MPLS que
estaba incrustada en el mensaje ICMP. Esa pila de etiquetas la pila de etiquetas recibida por el nodo donde
expiró el TTL.

El programa traceroute también presenta un retardo para cada salto. Para calcular esto, el nodo recoge una
marca de tiempo de transmisión cuando se envía el paquete de sondeo y recoge una marca de tiempo de
recepción cuando recibe el mensaje ICMP de retorno. Muchas implementaciones codifican la marca de tiempo
de transmisión en la carga útil del paquete de sondeo para evitar tener que mantener el estado de cada paquete
de sondeo. La diferencia entre las dos marcas de tiempo se presenta al usuario en la salida. Esto significa que
sólo se mide el retardo de ida y vuelta; los nodos a lo largo de la ruta no participan en la medición del retardo.
Por lo tanto, traceroute muestra los saltos a lo largo de la ruta, pero el retardo mostrado para cada salto es el
retardo de ida y vuelta.

La Figura 11-1 y el Ejemplo 11-1 ilustran el uso de IP traceroute en una red MPLS. La topología de red consiste
en una cadena de cuatro nodos, con SR habilitado en todos los nodos. El Nodo 4 anuncia su prefijo de bucle de
retorno [Link]/32 con un Prefijo-SID 16004. Se ejecuta un traceroute en Nodo1 para el destino [Link]. Se
envía una única sonda para cada TT. Se envía una única sonda para cada valor TTL (opción sonda 1 en el
comando). La primera sonda se envía con IP TTL 1, este TTL se copia en el campo TTL de la etiqueta impuesta
16004. El paquete de sonda llega al Nodo2 con la etiqueta 16004 y TTL 1. El Nodo2 disminuye el TTL, que
ahora es cero. Por lo tanto, Nodo2 genera un mensaje ICMP Time-to-live Exceeded hacia el origen
dirección [Link] paquete recibido. La dirección de origen paquete ICMP es la dirección IP de la interfaz en
la que se recibió el paquete de sonda. Nodo2 impone la etiqueta 16004 del paquete de sonda recibido en el
paquete ICMP y lo envía al nexthop para la etiqueta 16004. Este paquete se reenvía como un paquete normal.
Finalmente llega al Nodo4 sin etiqueta y el Nodo4 reenvía el paquete basándose en la dirección IP de destino.
Finalmente llega a Nodo1, donde el proceso traceroute produce la salida para el . Traceroute muestra el TTL
del paquete sonda originado, la dirección de origen del mensaje ICMP y la pila de etiquetas incluida en el
mensaje ICMP.

Ejemplo 11-1: IP traceroute en red MPLS - salida traceroute

RP/0/0/CPU0:xrvr-1#traceroute [Link] probe 1

Escriba la secuencia de escape para abortar.

Rastreando la ruta a [Link]

1 [Link] [MPLS: Etiqueta 16004 Exp 0] 0 mseg

2 [Link] [MPLS: Etiqueta 16004 Exp 0] 0 mseg
3 [Link] 0 mseg
Figura 11-2: IP traceroute en red MPLS
El uso de IP traceroute tiene limitaciones cuando se utiliza en un entorno MPLS. Tiene el mismo problema que
la utilidad IP ping. Si el LSP MPLS está roto, pero el reenvío IP sigue funcionando (por ejemplo, la etiqueta
saliente "Sin etiquetar"), entonces el nodo próximo al fallo intenta reenviar el paquete de sondeo utilizando el
reenvío IP normal si tiene una sola etiqueta. El nodo elimina la única etiqueta y reenvía el paquete como un
paquete IP al destino. El paquete sonda puede entonces llegar al destino y la respuesta volverá al origen. Dado
que se ha recibido un paquete de retorno, el LSP MPLS roto puede pasar desapercibido. La rotura del LSP
MPLS aún puede ser descubierta observando la información de la pila de etiquetas MPLS en el mensaje ICMP
de retorno. Si Nodo3 no tiene SR (ni LDP) habilitado, entonces el LSP a Nodo4 está roto. Ejecutando un
traceroute desde Nodo1 a [Link] se obtiene la salida de la Figura 11-2. El ping a
[Link] tiene éxito, así como el . Observa la falta de información de etiqueta para el segundo salto en traceroute
(línea 13). Dado que el Nodo3 no está habilitado para SR, el Nodo2 reenvió el paquete de sondeo al Nodo3
como un paquete IP sin etiqueta.

Ejemplo 11-2: Traceroute sobre LSP defectuoso

1 RP/0/0/CPU0:xrvr-1#ping [Link]
2 Escriba la secuencia de escape para abortar.
3 Enviando 5 ICMP Echos de 100 bytes a [Link], el tiempo de espera es de 2 segundos:
4 ¡¡¡¡¡!!!!!
5 La tasa de éxito es del 100% (5/5), ida y vuelta min/avg/max= 1/4/9 ms
6
7 RP/0/0/CPU0:xrvr-1#traceroute [Link] sonda 1
8
9 Escriba la secuencia de escape para abortar.
10 Rastreando la ruta a [Link]
11
12 1 [Link] [MPLS: Etiqueta 16004 Exp 0] 9 mseg
13 2 [Link] 0 mseg
14 3 [Link] 9 mseg

Otro problema aparece cuando se utiliza IP traceroute para intentar localizar el punto en el que el LSP está .
Dado que los mensajes ICMP generados viajan primero hasta el final del LSP original antes de volver
originador, cualquier fallo en ese LSP puede impedir el retorno de los mensajes ICMP. La localización del
punto de ruptura del LSP no es posible ya que ninguno de paquetes sonda obtiene respuesta. Este problema
aparecerá si el paquete sonda tiene más de una etiqueta (por ejemplo cuando se utiliza traceroute dentro de un
VRF) o si los nodos core no conocen la dirección IP de destino del paquete sonda (por ejemplo cuando se
utiliza traceroute entre PEs en un core sin BGP).
A veces se utiliza la herramienta traceroute para verificar grosso modo los retardos de los paquetes entre los
saltos de la . Ahora bien, si cada mensaje ICMP devuelto viaja primero hasta el final del LSP, entonces el
retardo calculado para cada salto a lo largo de este LSP es de hecho el retardo de ida y vuelta hasta el nodo de
cola del LSP. No se proporciona información el retardo entre los saltos del LSP. Por defecto Cisco IOS XR
utiliza este mecanismo de túnel ICMP (IETF RFC 3032); un nodo que genera un mensaje ICMP como
respuesta a un paquete etiquetado primero dirige el mensaje ICMP a la cola del LSP. Este es el caso incluso si
el tiene alcanzabilidad al nodo que originó la sonda y podría haber devuelto el mensaje ICMP directamente al
nodo de origen. Este comportamiento por defecto se puede cambiar con la configuración `mpls ipv4 ttl-
expiration-pop <n>`. Esta configuración especifica que el mecanismo de túnel ICMP sólo debe aplicarse para
mensajes ICMP en respuesta a paquetes con más de n etiquetas. Para paquetes con n etiquetas o menos, el
mensaje ICMP debe enviarse directamente al origen del paquete de sondeo. Esto mitiga algunos de los
inconvenientes de IP traceroute en un entorno MPLS.

DESTACADO: IP ping y traceroute

Proporcionan funciones básicas de comprobación de la conectividad, aislamiento de errores y verificación de rutas, y son ampliamente
compatibles y utilizadas en todas las redes.

No admiten el descubrimiento de rutas ECMP ni garantizan que todas las rutas ECMP se verifiquen; esto depende de la implementación de
estas herramientas y de cómo los routers realicen el equilibrio de carga.

Trabajar con rutas de reenvío IP y MPLS, por lo tanto, también para el enrutamiento de segmentos.

En el despliegue de enrutamiento por segmentos, traceroute muestra las etiquetas utilizadas para los segmentos en la ruta hacia
destino; el mismo segmento global con SRGB homogéneo y también ayuda a verificar las conexiones cruzadas de etiquetas en los
puntos de interfuncionamiento SR/LDP.

Puede utilizarse para medir la pérdida de paquetes y el tiempo de ida y vuelta.

11.2 Herramientas MPLS existentes
IP ping e IP traceroute se utilizan a menudo para diagnosticar la causa de un problema de accesibilidad en la
red. Estas herramientas se pueden utilizar en un entorno MPLS, pero el rastreo de fallos puede ser difícil si hay
inconsistencias entre las tablas de reenvío IP y MPLS, inconsistencias entre el plano de control MPLS y la tabla
de reenvío, o blackholing de tráfico MPLS. Muchos de estos problemas MPLS son difíciles o imposibles de
diagnosticar con herramientas IP.

El RFC 4379 del IETF especifica herramientas MPLS diseñadas específicamente para diagnosticar problemas
de transporte MPLS. Siguiendo el modelo de las clásicas herramientas ping y traceroute, el conjunto de
herramientas MPLS proporciona una funcionalidad ping para verificar la conectividad y una funcionalidad
traceroute para verificar la ruta salto a salto y localizar un fallo.

MPLS Ping y Traceroute superan varias limitaciones de las herramientas IP Ping y Traceroute:

Las herramientas MPLS verifican la ruta de datos MPLS asegurándose de que los paquetes de sonda no
se enrutan por IP. La carga útil de paquetes de sonda contiene información relevante para la
verificación.

Las herramientas MPLS realizan comprobaciones de coherencia MPLS por diseño:

Consultar el plano de control para construir un paquete de sondeo en el nodo de origen y verificar el
reenvío y el plano de control en la salida.

El paquete sonda atraviesa la ruta de datos MPLS y el nodo que procesa la sonda verifica si el reenvío
es coherente.

Las herramientas MPLS son extensibles por diseño utilizando el

mecanismo TLV. El conjunto de herramientas soporta el
descubrimiento de rutas por diseño.

Los paquetes sonda contienen marcas de tiempo para permitir la medición de retrasos gruesos de paquetes
unidireccionales.

11.2.1 MPLS ping

Al contrario que sus homólogas IP, las herramientas MPLS no utilizan ICMP, sino que se basan en paquetes UDP
IPv4 o IPv6. La base de las herramientas MPLS Ping y Traceroute (también llamadas "LSP Ping" y "LSP
Traceroute") son los paquetes MPLS Echo Request y MPLS Echo Reply.
Para validar un Label Switched Path, el paquete MPLS Echo Request debe ser enviado dentro de la banda de
este LSP, deben seguir la misma ruta que otros paquetes transportados por el LSP. Por lo tanto, aplica la misma
pila de etiquetas a los paquetes MPLS Echo Request que a los demás paquetes transportados por este LSP. Los
paquetes MPLS Echo Request validan principalmente el plano de datos MPLS, pero también pueden utilizarse
para inconsistencias entre el plano de datos y el plano de control. Por lo tanto, los paquetes MPLS Echo llevan
información adicional.

Los paquetes MPLS Echo Reply pueden ser gestionados de diferentes maneras, pero comúnmente son devueltos
al originador del paquete MPLS Echo Request como un paquete IP, siguiendo el reenvío regular en la red. El
paquete MPLS Echo Reply puede tomar un camino MPLS o IP para volver al nodo de origen. En este , el LSP
sólo se valida en una dirección, el LSP de retorno no se valida. Pero la respuesta de eco MPLS puede ser
descartada en la de retorno, lo que puede dar lugar a un falso negativo.

Un paquete MPLS Echo Request es un paquete UDP (con puerto de destino UDP 3503) que se envía a un nodo
destino utilizando la pila de etiquetas del LSP que se está validando. El uso de la pila de etiquetas es
significativo, ya que reenvía el paquete dentro de la banda del LSP.

Se toman precauciones para garantizar que el paquete no pueda desviarse de la ruta prevista sin ser detectado:

1. La dirección IP de destino de un paquete MPLS Echo Request se selecciona del rango IPv4 [Link]/8 o
del rango IPv6 equivalente mapeado a IPv4 ::ffff:127.0.0/104 para IPv6. Este intervalo de direcciones es
el denominado intervalo de direcciones loopback de host. Los paquetes destinados a cualquier destino en
[Link]/8 nunca deben aparecer en ninguna red. Utilizar dicha dirección como dirección IP de destino
obliga a que el paquete sea consumido por el nodo que lo recibe. En el caso del MPLS Echo Request, ese
es el nodo final del LSP u otro nodo si por alguna razón la pila de etiquetas fuera erróneamente eliminada
del paquete. Dado que la dirección IP de destino no se utiliza realmente para el reenvío, también puede
variarse para ejercer diferentes caminos en un ECMP. Como se explica en el capítulo 3, "Segment
Routing MPLS Data Plane", los paquetes se equilibran en carga basándose en un cálculo hash, y la
dirección IP de destino es un elemento de ese cálculo hash.

2. El campo TTL IP del paquete se establece en 1. Tenga en cuenta que esto no se aplica al campo TTL de
MPLS.

3. La opción Alerta de router se establece en la cabecera IP.

El paquete MPLS Echo Request lleva información adicional sobre el LSP para permitir al nodo destino, el
extremo de cola del LSP, verificar si es el objetivo de la sonda. Por lo tanto, el nodo origen incluye la
información de Clase de Equivalencia de Reenvío (FEC) del LSP en el paquete MPLS Echo Request
generado. El nodo final del LSP verifica si es realmente el nodo final (también llamado "egress") para la FEC
especificada en el paquete de sondeo. Si es asídevuelve "success" en el mensaje MPLS Echo Reply, en caso
contrario devuelve un código de error.

Un paquete MPLS Echo Reply es enviado en respuesta a un paquete MPLS Echo Request por el nodo que lo
procesa. Para originar o responder a los paquetes MPLS Echo en Cisco IOS XR, mpls oam debe estar
configurado. Cada nodo que recibe un paquete MPLS Echo Request sin cabecera MPLS procesa el paquete, si
mpls oam está . Este nodo puede ser el nodo de destino o un nodo intermedio si el LSP se rompe y la
cabecera IP se expone prematuramente. También un nodo que recibe un paquete MPLS Echo Request con un
MPLS TTL= 1 procesa el paquete.

El Ejemplo 11-3 muestra la salida de consola de un ping MPLS en Nodo1 a [Link]/32. A diferencia del ping
IP, se especifica un prefijo [Link]/32 en lugar de una dirección. En el paquete MPLS Echo Request incluye
una FEC genérica. Más detalles de los tipos de FEC se discuten después de este ejemplo. La topología de red
utilizada en este ejemplo se muestra en la Figura 11-3.
Ejemplo 11-3: Ejemplo de salida de MPLS ping

RP/0/0/CPU0:xrvr-1#ping mpls ipv4 [Link]/32 fec generic Envío de

5 ecos MPLS de 100 bytes a [Link]/32,

el tiempo de espera es de 2 segundos, el intervalo de envío es de 0 mseg:

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

retorno 0 Escriba la secuencia de escape para abortar.

¡¡¡¡¡!!!!!
La tasa de éxito es del 100% (5/5), ida y vuelta min/avg/max= 10/12/20 ms

image::0087_SR_book_SR_MPLS_OAM_v5p_files/[Link][caption='Figura 11-3: ', title='Ejemplo de

Ping MPLS']

El Ejemplo 11-4 muestra la captura de un paquete MPLS Echo Request. El paquete es capturado en el enlace
entre Nodo1 y Nodo2. Observe la etiqueta MPLS 16004 en la línea 1. Esta es la etiqueta Prefix-SID para
[Link].2. Esta es la etiqueta Prefix-SID para [Link]/32, el prefijo loopback del Nodo4. El IP TTL (ttl 1) y
la opción IP Router Alter (opciones (RA)) se muestran en la línea 2. El paquete es un paquete UDP con
dirección de destino IP
[Link] y puerto UDP 3503, como se muestra en la línea 3. El FEC de destino se muestra en las líneas 14 a
17; es el prefijo [Link]/32. Los otros elementos de la carga útil se discuten más adelante en esta sección.
Ejemplo 11-4: Ejemplo de paquete MPLS Echo Request

1 17:37:18.286050 MPLS (etiqueta 16004, exp 0, [S], ttl 255)

2 IP (tos 0x0, ttl 1, id 78, offset 0, flags [DF], proto UDP (17), length
96, opciones (RA))
3 [Link].3503> [Link].3503: [udp suma ok]
4 LSP-PINGv1, msg-type: MPLS Echo Request (1), length: 64
5 Banderas globales: 0x0000
6 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
7 Código de retorno: Ningún código de retorno o código de retorno contenido en
el TLV de código de error (0).
8 Subcódigo de retorno: (0)
9 Remitente Handle: 0x0000619f, Secuencia: 5
10 Sender Timestamp: 17:36:52.371585 Receptor Timestamp: no timestamp
11 Código privado del vendedor TLV (64512), longitud: 12
12 Id. de proveedor ciscoSystems (9)
13 Valor: 0001000400000004
14 Pila FEC de destino TLV (1), longitud: 12
15 Prefijo IPv4 genérico subTLV (14), longitud: 5
16 Prefijo IPv4: [Link] ([Link])
17 Longitud del prefijo: 32

El Ejemplo 11-5 muestra un paquete MPLS Echo Reply capturado que fue enviado en respuesta al Echo
Request anterior. Este paquete es capturado en el enlace entre Nodo1 y Nodo2. Este paquete MPLS Echo
Reply es un paquete IP con dirección de destino [Link], la dirección IP de origen del paquete Echo Request.
Los otros elementos de la carga útil se discuten más adelante en esta sección.

Ejemplo 11-5: Ejemplo de paquete MPLS Echo Reply

17:37:18.294067 IP (tos 0xc0, ttl 253, id 62, offset 0, flags [none], proto UDP (17),
longitud 76)
[Link].3503> [Link].3503: [udp sum ok]
LSP-PINGv1, msg-type: MPLS Echo Reply (2), length: 48 Global
Flags: 0x0000
reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
Código de retorno: El enrutador de respuesta es una salida para el FEC en la
profundidad de pila 1 (3) Subcódigo de retorno: (1)
Remitente Handle: 0x0000619f, Secuencia: 5
Sender Timestamp: 17:36:52.371585 Sello de tiempo del receptor: 17:36:53.263483
Código privado del vendedor TLV (64512), longitud: 12
Id. de proveedor ciscoSystems
(9) Valor: 0001000400000004

11.2.2 Paquete MPLS Echo Request/Reply

En la Figura 11-4 se muestra el formato de la carga útil de un paquete MPLS Echo Request y MPLS Echo
Reply, tal y como se especifica en IETF RFC 4379.

Figura 11-4. Formato de la carga útil del mensaje MPLS Echo Request/Reply Formato de la carga útil del mensaje MPLS Echo Request/Reply

Número de versión: 1
Banderas globales:
V-flag (Validate FEC stack): set si el emisor solicita la validación de la pila FEC; unset si el emisor deja
la elección de validar FEC al receptor.

T-flag (responder sólo si el TTL ha expirado): si está activado, sólo se enviará una Echo Reply cuando
el TTL del paquete haya expirado - IETF RFC 6425

R-flag (validar ruta inversa): si está activada, el respondedor debe devolver FEC de ruta inversa.
información - IETF RFC 6426

Tipo de mensaje: Echo Request o Echo Reply (y otros que no se describen en este libro)

Reply mode: describe cómo debe devolverse la Echo Reply; en Cisco IOS XR la Reply se devuelve como un
paquete UDP IPv4/IPv6 por defecto para la mayoría de los tipos de LSP.

Código de retorno y subcódigo de retorno: identifica el resultado del procesamiento de la solicitud de eco.

Identificador del remitente: Identificador que permite correlacionar la MPLS Echo Reply con la MPLS Echo
Request original.

Número de secuencia: se utiliza para detectar respuestas perdidas

Timestamp sent: hora del día en que se envió la MPLS Echo Request

Timestamp received: hora del día en que se recibió la MPLS Echo Request.

TLVs: se pueden incluir diferentes TLVs, véase el registro IANA.[ 3] En este libro sólo se trata un subconjunto
de los TLVs.

Uno de los tipos de TLV que pueden incluirse son los TLV específicos del proveedor. Estos TLVs privados de
proveedor tienen un valor de tipo entre 31744-32767 o 64512-65535. Los TLVs con valores de tipo superiores
a 32767 son opcionales y un nodo debe ignorarlos si no los entiende. El TLV de extensión de Cisco se añadió
para garantizar la interoperabilidad entre implementaciones de diferentes versiones del borrador del IETF que
finalmente dio lugar al RFC 4379 del IETF. Los paquetes MPLS Echo de los ejemplos incluyen un TLV de
extensión Cisco con un sub-TLV de revisión que contiene la última revisión, representada por un número de
revisión interno 4. Véase por ejemplo el Ejemplo 11-4, líneas 11 a 13.

Dado que un MPLS Echo Request se utiliza para probar un LSP en particular, debe incluir un Target FEC Stack
TLV; este TLV especifica la(s) FEC(s) del LSP previsto. Este TLV es necesario para que el nodo de destino
pueda verificar si es realmente el nodo final del LSP para el FEC especificado. Por ejemplo, si un nodo quiere
verificar si el Prefijo-SID 16004 para el prefijo [Link]/32 realmente llega al nodo que anunció este Prefijo-SID,
ese nodo puede enviar una Petición de Eco MPLS con una etiqueta 16004 e incluir un TLV de Pila FEC con
una sola FEC, a saber, el prefijo [Link]/32. Este TLV especifica la FEC(s) del LSP previsto.

Cuando un nodo recibe un MPLS Echo Request, valida si tanto el plano de control como el plano de datos
están sincronizados y ambos están de acuerdo con lo especificado en el Target FEC Stack TLV del paquete
recibido antes de generar un paquete MPLS Echo Reply.
En el Ejemplo 11-4 se muestra un ejemplo de paquete MPLS Echo Request. En este ejemplo el Target FEC Stack
TLV contiene un IPv4 Prefix sub-TLV genérico, mostrado en las líneas 14 a 17 de la salida.

Cada tipo de FEC tiene su propio FEC Type sub-TLV. Hay sub-TLVs de Tipo FEC para prefijos LDP, LSPs
RSVP-TE, prefijos BGP-LU, prefijos VPN, etc. Cada sub-TLV de tipo de FEC contiene los campos
necesarios para especificar un FEC de ese tipo.

En el momento de escribir este libro, hay dos sub-TLVs de tipo FEC disponibles en Cisco IOS XR para
verificar rutas MPLS SR: "Generic IP Prefix" y "NIL-FEC". Los nuevos tipos y procedimientos FEC de
enrutamiento por segmentos se especifican en IETF [draft-ietf-mpls-spring-lsp-ping].

El tipo Prefijo Genérico FEC se utiliza generalmente si el protocolo que anuncia la etiqueta es desconocido o
puede variar a lo largo de la ruta. El sub-TLV Generic Prefix FEC Type contiene el prefijo IPv4 o IPv6 y su
longitud de prefijo.

El tipo NIL-FEC FEC se utiliza generalmente si se añaden etiquetas del rango reservado, como la etiqueta
Router Alert o la etiqueta Explicit-null, a la pila de etiquetas. El sub-TLV NIL-FEC FEC Type contiene el valor
de la etiqueta. Cuando se utiliza este tipo Nil-FEC, Cisco IOS XR añade un único sub-TLV de tipo FEC en el
paquete MPLS Echo Request: el valor "0" de la etiqueta IPv4 Explicit-Null.[ 4]

La implementación de Cisco IOS XR permite realizar las operaciones de ping y traceroute MPLS para prefijos
FEC IPv4/IPv6 sin especificar el tipo de FEC. implementación determinará automáticamente el tipo de FEC a
utilizar basándose en el protocolo de control MPLS que señaliza el .
Sin embargo, este enfoque no funciona para los prefijos de Enrutamiento por Segmentos en el momento de
escribir este libro. Se ampliará una funcionalidad similar para los prefijos de Enrutamiento por Segmentos una
vez que se publique la implementación de las nuevas extensiones de Enrutamiento por Segmentos.

El Ejemplo 11-6 muestra un ejemplo de un ping MPLS utilizando NIL-FEC. LSP Ping no puede determinar la
pila de etiquetas, interfaz saliente, y nexthop cuando se usa NIL-FEC, por lo tanto el usuario necesita
especificar esa información en el comando traceroute. La topología de red para este ejemplo se muestra en la
Figura 11-3.
Ejemplo 11-6: salida de consola de MPLS ping con Nil-FEC

1 RP/0/0/CPU0:xrvr-1#ping mpls nil-fec labels 16004 output interface Gi0/0/0/1 nexthop

[Link]
2
3 Envío de 5 Eco MPLS de 100 bytes con FEC nulo con etiquetas [16004],
4 el tiempo de espera es de 2 segundos, el intervalo de envío es de 0 mseg:
5
6 Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,
7 L": interfaz de salida etiquetada, "B": interfaz de salida no etiquetada,
8 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
9 'M' - solicitud malformada, 'm' - tlvs no soportados, 'N' - sin etiqueta
rx,
10 'P' - no rx intf label prot, 'p' - terminación prematura del LSP,
11 'R' - enrutador de tránsito, "I" - índice ascendente desconocido,
12 'X' - código de retorno desconocido, 'x' - código de retorno 0
13
14 Escriba la secuencia de escape para abortar.
15
16 ¡¡¡¡¡!!!!!
17 La tasa de éxito es del 100% (5/5), ida y vuelta min/avg/max= 1/8/10 ms

El Ejemplo 11-7 muestra un paquete MPLS Echo Request con un NIL-FEC Target FEC Stack. Este paquete
es capturado en la interfaz entre Nodo1 y Nodo2 para el ping MPLS del Ejemplo 11-6. La pila de etiquetas
del paquete contiene dos etiquetas: 16004 y 0, ver líneas 1 y 2. El Target FEC TLV con NIL-FEC sub-TLV se
muestra en las líneas 15 a 17. La etiqueta en el sub-TLV NIL-FEC es la etiqueta IPv4 Explicit-null (0).
Ejemplo 11-7: Paquete MPLS Echo Request con Nil-FEC

13:46:47.892495 MPLS (etiqueta 16004, exp 0, ttl 255)

(label 0 (IPv4 explícito NULL), exp 0, [S], ttl 255)
IP (tos 0x0, ttl 1, id 106, offset 0, flags [DF], proto UDP (17), length 92, options (RA))
[Link].3503> [Link].3503:
LSP-PINGv1, msg-type: MPLS Echo Request (1), length: 60
Global Flags: 0x0000
reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
Código de retorno: Ningún código de retorno o código de retorno contenido en el TLV de
código de error.
(0)
Subcódigo de retorno: (0)
Remitente Handle: 0x000061a7, Secuencia: 1
Sender Timestamp: 13:46:21.177759 Sello de tiempo del receptor: sin sello
de tiempo Código privado del vendedor TLV (64512), longitud: 12
Id. de proveedor ciscoSystems
(9) Valor: 0001000400000004
Target FEC Stack TLV (1), longitud: 8
Nil FEC subTLV (16), longitud: 4
Etiqueta: 0 (IPv4 Explicit-Null)

El paquete MPLS Echo Reply devuelto por el Nodo 4 se muestra en el Ejemplo 11-8. Este paquete es
equivalente al paquete MPLS Echo Reply del Ejemplo 11-5. Este paquete es al paquete MPLS Echo Reply del
Ejemplo 11-5.

Ejemplo 11-8: Paquete MPLS Echo Reply para Nil-FEC

13:46:47.899147 IP (tos 0xc0, ttl 253, id 5, offset 0, flags [none], proto UDP (17),
longitud 76)
[Link].3503> [Link].3503:
LSP-PINGv1, msg-type: MPLS Echo Reply (2), length: 48 Global
Flags: 0x0000
reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
Código de retorno: El enrutador de respuesta es una salida para el FEC en la
profundidad de pila 1 (3) Subcódigo de retorno: (1)
Remitente Handle: 0x000061a7, Secuencia: 1
Sender Timestamp: 13:46:21.177759 Sello de tiempo del receptor: 13:46:22.203351
Código privado del proveedor TLV (64512), longitud: 12
Id. de proveedor ciscoSystems
(9) Valor: 0001000400000004

El Target FEC Stack TLV puede contener más de un sub-TLV, uno por cada FEC de la pila de etiquetas que se está
comprobando. El primer sub-TLV corresponde a la parte superior de la pila de etiquetas.

11.2.3 Traceroute MPLS

MPLS Traceroute utiliza básicamente los mismos paquetes y procedimientos que MPLS Ping. MPLS
Traceroute verifica el plano de datos y el plano de control en cada salto del LSP para aislar fallos. Traceroute
envía paquetes MPLS Echo Request subsiguientes con TTL incrementales, comenzando con TTL de 1. Esto
es equivalente a IP traceroute. El nodo de tránsito donde expira el TTL procesa la solicitud de eco MPLS en
software y verifica si tiene un LSP para el FEC de destino y si es el nodo de tránsito previsto para el LSP. A
continuación, el nodo de tránsito envía una MPLS Echo Reply que contiene el resultado de la verificación y,
si ésta se ha realizado correctamente, la pila de etiquetas salientes del LSP, la dirección del nodo nexthop y la
dirección de interfaz del nexthop. El originador procesa esta MPLS Echo Reply para construir el paquete
MPLS Echo Request subsiguiente con TTL+ 1. Este procedimiento se repite hasta que el destino responde
que es la cola del LSP.

Se utiliza un TLV de mapeo descendente (DSMAP) para transportar la información saliente (o descendente) del
LSP: pila de etiquetas salientes, nodo nexthop y direcciones de interfaz.

Este TLV puede incluirse en los paquetes Echo Request y Echo Reply. En el paquete Echo Request,
proporciona la información para que el nodo de tránsito verifique si es el nodo de tránsito previsto para el y
verifique si el paquete se recibe en la interfaz prevista del nodo ascendente (por ejemplo, cuando varias
interfaces de igual coste se conectan al mismo vecino ascendente). En el paquete Echo Reply, devuelve la
información que el originador proporcionará al siguiente nodo del LSP. Esta es otra mejora fundamental sobre
IP traceroute que permite el descubrimiento y verificación de rutas como veremos más adelante en este
capítulo.

El RFC 6424 del IETF deja obsoleto el TLV DSMAP y lo sustituye por el TLV Downstream Detailed Mapping
(DDMAP), pero el TLV DSMAP se sigue utilizando habitualmente, por ejemplo en Cisco IOS XR.

El formato DSMAP TLV está especificado en IETF RFC 4379 y se muestra en la Figura 11-5.
Figura 11-5: Formato TLV de asignación descendente

MTU: tamaño máximo de la trama MPLS (incluida la pila de etiquetas) que puede enviarse por la interfaz
saliente al vecino descendente, básicamente la MTU IP de la interfaz descendente.

Tipo de dirección: IPv4 o IPv6, numerada o no numerada DS

Flags:
I-flag (Interface and Label Stack Object Request): si está activado, el nodo que responde debe responder
con un objeto de pila de interfaz y etiqueta.

N-flag (Non-IP packet): el flujo de paquetes que se está diagnosticando es un flujo de paquetes no IP,
pero los paquetes MPLS Echo son paquetes IP. Por lo tanto, el nodo receptor debe tratar este paquete
MPLS Echo como un paquete no IP para diagnosticar correctamente el comportamiento de un flujo no
IP.

Dirección IP de bajada y dirección de interfaz de bajada: en la Echo Reply, especifica el ID del router del
vecino de bajada y la dirección IP de la interfaz o el índice de la interfaz, dependiendo del
interfaz numerada o no numerada. En la petición de eco, contiene la información que proporcionó el nodo
ascendente.

Tipo de multitrayecto: indica si todos los paquetes se reenviarán a esta interfaz de salida o sólo un
subconjunto de todos los paquetes. Por ejemplo, si la interfaz de salida es una de conjunto de interfaces
de un ECMP, entonces no todos los paquetes se reenviarán a esta interfaz, sino se repartirán entre todas
las interfaces posibles. En tal caso, el Tipo de Multitrayecto indica cómo se identifican los paquetes que
se reenviarán a esta interfaz (direcciones IP, rangos de direcciones IP, direcciones IP con máscara de bits
o etiquetas con máscara de bits). La información de identificación real se proporciona en el campo
Información de Multipath.

Límite de profundidad: sólo aplicable a una pila de etiquetas, especifica el número máximo de etiquetas
consideradas en el hash. Debe ser cero si no se especifica o ilimitado.

Longitud de multitrayectolongitud del campo de información de multitrayecto

Información Multipath: Valores de dirección o etiqueta codificados según el tipo de multitrayecto.

Etiqueta(s) descendente(s): la(s) etiqueta(s) en la pila de etiquetas tal y como aparecerían el paquete se
reenviara a través de esta interfaz. El formato es el de una etiqueta MPLS menos el campo TTL.

Protocolo: especifica el protocolo que ha instalado la entrada de reenvío. 0 para desconocido.

La presencia de un TLV DSMAP en la Solicitud de Eco MPLS, indica al nodo de respuesta que debe incluir
los objetos de mapeo descendente en su Respuesta de Eco MPLS, excepto si el nodo de respuesta es el nodo de
cola de LSP para el FEC especificado, en cuyo caso no debe incluir un TLV DSMAP en su respuesta.

El uso del TLV DSMAP se explica con un ejemplo. La topología de red para este es la misma cadena simple
de cuatro nodos que se utilizó antes, véase por ejemplo la Figura 11-2. Nodo1 en la topología lanza un
traceroute MPLS para [Link]/32. La salida del traceroute se muestra en el Ejemplo 11-9. La variante
verbose muestra un poco más de información. El carácter en la primera columna es el código de resultado,
como se explica en la parte superior de la salida del comando. La segunda columna es el TTL MPLS del
paquete. La tercera columna es la dirección IP del nodo que envía el MPLS Echo Reply. La salida verbose
también muestra otra dirección IP: la dirección IP del vecino aguas abajo. La MTU MPLS de la interfaz
saliente se indica en la siguiente columna (aunque en la salida pone MRU), seguida de la pila de etiquetas que
se encontraría en el paquete saliente. Si el nodo es el
penúltimo salto y se solicita PHP, entonces la etiqueta saliente hacia el vecino descendente se indica como
implícita-nula. Exp: indica el valor de los EXP o TC para cada etiqueta de la pila. Finalmente se
muestra la latencia y el valor numérico del código de retorno si se especificó la palabra clave verbose para
el comando. La dirección del vecino aguas abajo (cuarta columna de la salida), la MTU y las etiquetas se
recuperan de la TLV DSMAP en el paquete MPLS Echo Reply.

Ejemplo 11-9: Ejemplo de salida de consola de un traceroute MPLS

RP/0/0/CPU0:xrvr-1#traceroute mpls ipv4 [Link]/32 fec generic verbose Tracing

MPLS Label Switched Path to [Link]/32, timeout is 5 seconds Códigos: '!' -

éxito, 'Q' - petición no enviada, '.' - timeout,

retorno 0 Escriba la secuencia de escape para abortar.

0 [Link] [Link] MRU 1500 [Etiquetas: 16004 Exp: 0]

L 1 [Link] [Link] MRU 1500 [Etiquetas: 16004 Exp: 0] 40 ms, ret code 8
L 2 [Link] [Link] MRU 1500 [Etiquetas: implicit-null Exp: 0] 30 ms, ret code 8
¡! 3 [Link] 1 ms, ret code 3

Cuando se ejecuta un traceroute, este TLV DSMAP se incluye en el paquete MPLS Echo Request para que el
nodo intermedio en el LSP pueda validar si es el nodo deseado. Cualquier nodo que responda a esta MPLS
Echo Request, excepto el nodo final, añade uno o más de estos TLVs a la MPLS Echo Reply. Si el DSMAP
TLV en el MPLS Echo Request tiene el Multipath Type puesto a cero, entonces el nodo que responde sólo
incluye un DSMAP TLV en el Echo Reply, el mapeado descendente que sería usado por el paquete Echo
Request. El nodo de origen establece Multipath Type= 0 para un traceroute normal. Si el campo Multipath
Type en el TLV se establece en algún otro valor, entonces el que responde incluye todos los mapeos aguas
abajo en el Echo Reply. Se añade entonces un TLV de mapeo descendente para cada ruta saliente del FEC. El
nodo de origen establece Multipath Type a un valor distinto de cero para un traceroute multipath, también
llamado "treetrace".

La salida del comando mpls traceroute muestra algunos de los campos del TLV de mapeo descendente
que se recibieron de los nodos de respuesta: MTU y pila de etiquetas. La opción verbose
muestra aún más información de ese TLV: dirección IP del vecino aguas abajo.

El Ejemplo 11-10 muestra una captura de paquete del MPLS Echo Request originado por el Nodo1 para
salida del comando tracroute en el Ejemplo 11-9. El paquete es capturado en el enlace entre el Nodo1 y el
Nodo2 en la topología de la Figura 11-3. El paquete es capturado en el enlace entre Nodo1 y Nodo2 en la
topología de la Figura 11-3. Una diferencia entre este paquete y un paquete MPLS Echo Request usado para
MPLS ping es el MPLS TTL en la línea 1, que hace un nodo específico en la ruta procese el paquete: el nodo
donde expira el TTL. Otra diferencia con el paquete utilizado para MPLS ping es que el nodo de origen
añade un TLV DSMAP a la Solicitud de Eco MPLS; ver líneas 17 a 24. La presencia de este TLV hará que el
nodo de respuesta incluya un TLV DSMAP en su paquete Echo Reply. El nodo origen indica el nodo de
tránsito previsto (el primer nodo del camino en este caso ya que TTL=1) en el TLV DSMAP. En ese TLV
indica que el nodo donde expirará el TTL tiene:

Interfaz de entrada con una dirección IPv4 y una MTU 1500 (línea 18)
Dirección IP [Link] (línea 19)

Interfaz de entrada Dirección IP [Link] (línea 20)

La pila de etiquetas del paquete entrante es una sola etiqueta 16004 (línea 24)
Ejemplo 11-10: Paquete MPLS Echo Request, TTL 1

1 17:03:31.474163 MPLS (etiqueta 16004, exp 0, [S], ttl 1)

2 IP (tos 0x0, ttl 1, id 169, offset 0, flags [DF], proto UDP (17), length
120, opciones (RA))
3 [Link].3503> [Link].3503:
4 LSP-PINGv1, msg-type: MPLS Echo Request (1), length: 88
5 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
6 Código de retorno: Ningún código de retorno o código de retorno contenido en
el TLV de código de error (0).
7 Subcódigo de retorno: (0)
8 Remitente Handle: 0x000061b2, Secuencia: 1
9 Sender Timestamp: 17:03:04.311512 Timestamp Receptor: no timestamp
10 Código privado del vendedor TLV (64512), longitud: 12
11 Id. de proveedor ciscoSystems (9)
12 Valor: 0001000400000004
13 Pila FEC de destino TLV (1), longitud: 12
14 Prefijo IPv4 genérico subTLV (14), longitud: 5
15 Prefijo IPv4: [Link] ([Link])
16 Longitud del prefijo: 32
17 TLV de asignación descendente (2), longitud: 20
18 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
19 IP descendente: [Link]
20 Interfaz descendente IP: [Link]
21 Tipo de ruta múltiple: sin ruta múltiple (0)
22 Límite de profundidad: 0
23 Longitud multitrayecto: 0
24 Elemento de etiqueta descendente, Etiqueta: 16004, Exp: 0, EOS: 1,
Protocol: 0 (Desconocido)

Nodo2 verifica si tiene un LSP para el FEC de destino, y si es el nodo de tránsito previsto. Nodo2 verifica los
elementos del Downstream Mapping TLV y si estos elementos coinciden con su información local responde
con el código de retorno aplicable. En este caso Nodo2 responde con el código de retorno 8 (línea 5); esto
significa que conmuta los paquetes en el LSP basándose en la enésima etiqueta de la pila de etiquetas, con n
especificado en el subcódigo de retorno, 1 en este caso (línea 6). Nodo2 también incluye un TLV de mapeo
descendente en el paquete Echo Reply donde proporciona la información descendente para el LSP. Dado que
Nodo1 no especificó un tipo de multitrayecto (Multipath Type: no multipath (0) en la línea 16)
en la petición, Nodo2 sólo incluye un único TLV DSMAP en la . El comportamiento de MPLS traceroute
cuando hay ECMP en el camino se discute en la sección 11.2.4, "Path Discovery using MPLS Traceroute".
Nodo2 indica que el nodo aguas abajo del LSP tiene dirección IP
[Link] (línea 14); la interfaz del nodo de bajada tiene una dirección IP [Link] (línea 15) y el
La interfaz saliente tiene una MTU 1500 (línea 13). La pila de etiquetas salientes consta de una única etiqueta
16004 (línea 19).

Ejemplo 11-11: Paquete MPLS Echo Reply, TTL 1

1 17:03:33.426948 IP (tos 0xc0, ttl 255, id 24, offset 0, flags [none], proto UDP
(17), longitud 100)
2 [Link].3503> [Link].3503:
3 LSP-PINGv1, msg-type: MPLS Echo Reply (2), length: 72
4 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
5 Código de retorno: Etiqueta cambiada a profundidad de pila 1 (8)
6 Subcódigo de devolución: (1)
7 Remitente Handle: 0x000061b2, Secuencia: 1
8 Sender Timestamp: 17:03:04.311512 Hora de recepción: 17:03:04.327131
9 Código privado del vendedor TLV (64512), longitud: 12
10 Id. de proveedor ciscoSystems (9)
11 Valor: 0001000400000004
12 TLV de asignación descendente (2), longitud: 20
13 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
14 IP descendente: [Link]
15 Interfaz descendente IP: [Link]
16 Tipo de ruta múltiple: sin ruta múltiple (0)
17 Límite de profundidad: 0
18 Longitud multitrayecto: 0
19 Elemento de etiqueta descendente, Etiqueta: 16004, Exp: 0, EOS: 1,
Protocol: 0 (Desconocido)

El Nodo1 recibe la información de mapeo descendente del Nodo2 e incluye esa información en el siguiente
paquete MPLS Echo Request, dirigido al siguiente nodo del LSP, que es el Nodo3. Ver Ejemplo 11-12. Nodo1
establece TTL=2 en ese paquete (línea 1), utilizando la misma etiqueta 16004.
Ejemplo 11-12: Paquete MPLS Echo Request, TTL 2

1 17:03:33.440386 MPLS (etiqueta 16004, exp 0, [S], ttl 2)

2 IP (tos 0x0, ttl 1, id 170, offset 0, flags [DF], proto UDP (17), length
120, opciones (RA))
3 [Link].3503> [Link].3503:
4 LSP-PINGv1, msg-type: MPLS Echo Request (1), length: 88
5 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
6 Código de retorno: Ningún código de retorno o código de retorno contenido en
el TLV de código de error (0).
7 Subcódigo de retorno: (0)
8 Remitente Handle: 0x000061b2, Secuencia: 2
9 Sender Timestamp: 17:03:06.294275 Hora de recepción: sin hora de recepción
10 Código privado del vendedor TLV (64512), longitud: 12
11 Id. de proveedor ciscoSystems (9)
12 Valor: 0001000400000004
13 Pila FEC de destino TLV (1), longitud: 12
14 Prefijo IPv4 genérico subTLV (14), longitud: 5
15 Prefijo IPv4: [Link] ([Link])
16 Longitud del prefijo: 32
17 TLV de asignación descendente (2), longitud: 20
18 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
19 IP descendente: [Link]
20 Interfaz descendente IP: [Link]
21 Tipo de ruta múltiple: sin ruta múltiple (0)
22 Límite de profundidad: 0
23 Longitud multitrayecto: 0
24 Elemento de etiqueta descendente, Etiqueta: 16004, Exp: 0, EOS: 1,
Protocol: 0 (Desconocido)

El TTL del paquete Echo Request expira en el Nodo3. El Nodo3 verifica la FEC y si es el nodo de destino, y
responde con una MPLS Echo Reply. Ver Ejemplo 11-13. Nodo3 especifica la información de bajada en el
TLV DSMAP. Dado que el Nodo3 es el penúltimo salto para este LSP (Prefijo-SID del Nodo4), la pila de
etiquetas salientes es Implicit-Null (línea 19). El Nodo3 quita la etiqueta antes de reenviar el paquete al
Nodo4.
Ejemplo 11-13: Paquete MPLS Echo Reply, TTL 2

1 17:03:35.346122 IP (tos 0xc0, ttl 254, id 32, offset 0, flags [none], proto UDP
(17), longitud 100)
2 [Link].3503> [Link].3503:
3 LSP-PINGv1, msg-type: MPLS Echo Reply (2), length: 72
4 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
5 Código de retorno: Etiqueta cambiada a profundidad de pila 1 (8)
6 Subcódigo de devolución: (1)
7 Remitente Handle: 0x000061b2, Secuencia: 2
8 Sender Timestamp: 17:03:06.294275 Hora de recepción: 17:03:06.405017
9 Código privado del vendedor TLV (64512), longitud: 12
10 Id. de proveedor ciscoSystems (9)
11 Valor: 0001000400000004
12 TLV de asignación descendente (2), longitud: 20
13 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
14 IP descendente: [Link]
15 Interfaz IP descendente: [Link]
16 Tipo de ruta múltiple: sin ruta múltiple (0)
17 Límite de profundidad: 0
18 Longitud multitrayecto: 0
19 Elemento de etiqueta descendente, Etiqueta: 3 (Implícita-Nula), Exp: 0, EOS: 1,
Protocolo: 0 (Desconocido)

El Nodo1 recibe la información de mapeo descendente del Nodo3 e incluye esa información en el siguiente
paquete MPLS Echo Request, dirigido al siguiente nodo del LSP, que es el Nodo4. Ver Ejemplo 11-14. Nodo1
establece TTL=3 en ese paquete (línea 1).
Ejemplo 11-14: Paquete MPLS Echo Request, TTL 3

1 17:03:35.352786 MPLS (etiqueta 16004, exp 0, [S], ttl 3)

2 IP (tos 0x0, ttl 1, id 171, offset 0, flags [DF], proto UDP (17), length
120, opciones (RA))
3 [Link].3503> [Link].3503:
4 LSP-PINGv1, msg-type: MPLS Echo Request (1), length: 88
5 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
6 Código de retorno: Ningún código de retorno o código de retorno contenido en
el TLV de código de error (0).
7 Subcódigo de retorno: (0)
8 Remitente Handle: 0x000061b2, Secuencia: 3
9 Sender Timestamp: 17:03:08.259859 Hora de recepción: sin hora de recepción
10 Código privado del vendedor TLV (64512), longitud: 12
11 Id. de proveedor ciscoSystems (9)
12 Valor: 0001000400000004
13 Pila FEC de destino TLV (1), longitud: 12
14 Prefijo IPv4 genérico subTLV (14), longitud: 5
15 Prefijo IPv4: [Link] ([Link])
16 Longitud del prefijo: 32
17 TLV de asignación descendente (2), longitud: 20
18 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
19 IP descendente: [Link]
20 Interfaz descendente IP: [Link]
21 Tipo de ruta múltiple: sin ruta múltiple (0)
22 Límite de profundidad: 0
23 Longitud multitrayecto: 0
24 Elemento de etiqueta descendente, Etiqueta: 3 (Implícita-Nula), Exp: 0, EOS: 1,
Protocolo: 0 (Desconocido)

Nodo4 verifica la FEC y la información de mapeo descendente. A continuación, el Nodo4 confirma con el
código de retorno 3 que es el extremo de cola del LSP (línea 5). Es un nodo de salida de la FEC [Link]/32 a
una profundidad de pila indicada en el subcódigo de retorno, 1 en este caso.
Ejemplo 11-15: Paquete MPLS Echo Reply, TTL 3

1 17:03:35.363333 IP (tos 0xc0, ttl 253, id 27, offset 0, flags [none], proto UDP
(17), longitud 76)
2 [Link].3503> [Link].3503:
3 LSP-PINGv1, msg-type: MPLS Echo Reply (2), length: 48
4 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
5 Código de retorno: El router de respuesta es una salida para el FEC en la
profundidad de pila 1 (3)
6 Subcódigo de devolución: (1)
7 Remitente Handle: 0x000061b2, Secuencia: 3
8 Sender Timestamp: 17:03:08.259859 Hora de recepción: 17:03:08.272629
9 Código privado del vendedor TLV (64512), longitud: 12
10 Id. de proveedor ciscoSystems (9)
11 Valor: 0001000400000004

DESTACADO: MPLS ping y traceroute

Proporcionar comprobaciones de conectividad mejoradas, aislamiento de errores y capacidades de verificación de rutas específicas
para LSP MPLS, incluido el enrutamiento por segmentos.

La verificación incluye comprobaciones de coherencia y verificación del plano de control y del plano

de datos Incluye mecanismos de descubrimiento de rutas que permiten la verificación de rutas

ECMP en la

Los LSP de enrutamiento de segmentos pueden verificarse utilizando FEC genérico y FEC nulo mientras se estandarizan las nuevas
extensiones del protocolo ping LSP.

11.2.4 Descubrimiento de rutas mediante MPLS Traceroute

La capacidad de descubrir y rastrear todos los posibles caminos que un paquete puede atravesar para llegar a su
destino final es una característica importante necesaria para solucionar fallos de LSP. Los ECMP del nodo de
tránsito no son visibles para el remitente original de un paquete, por lo que es importante poder descubrir y
validar todos los caminos posibles a través de la red desde cualquier nodo de origen.

MPLS traceroute está diseñado para descubrir todos los ECMP en la ruta hacia el destino. Un nodo equilibra la
carga del tráfico en todas las rutas de igual coste disponibles basándose en los campos de cabecera del paquete:
pila de etiquetas, direcciones IP de origen y destino, puertos de capa 4, etc. MPLS traceroute puede enviar los
paquetes MPLS Echo Request con cualquier dirección IP de destino del rango de direcciones [Link]/8. Por lo
tanto,
el nodo de origen de los paquetes MPLS Echo Request puede enviar los paquetes por los diferentes caminos
de igual coste variando la dirección IP de destino de los paquetes.

Para descubrir los trayectos, el nodo de origen envía un mapa de bits en el sub-TLV Multipath Info del TLV
DSMAP. Junto con una dirección base, este mapa de bits indica qué direcciones IP de destino están hash en
la ruta identificada por la información de mapeo descendente.

Cada bit de la máscara de bits representa una dirección que se hash en la ruta. La dirección es la dirección
base más la posición del bit en la máscara, empezando por cero. Por ejemplo, la dirección base
[Link] y la máscara de bits 10001001011001001010100100010101 indican que las siguientes direcciones
rango [Link]-[Link] están agrupadas en esta ruta: [Link], [Link], [Link],
[Link], [Link], [Link], [Link], [Link], [Link], [Link], [Link],
[Link], y [Link].

El nodo de origen inicia el proceso de descubrimiento enviando un mapa de bits en Multipath Info sub-TLV
en el DSMAP TLV. El mapa de bits inicial (0xFFFFFFFF) contiene todas las direcciones. El nodo de tránsito
consulta la tabla de reenvío de cada dirección del mapa de bits para identificar la ruta de salida (el mapeo
descendente). Para cada dirección, establece el bit correspondiente en el mapa de bits de la TLV DSMAP
correspondiente en el paquete MPLS Echo Reply y devuelve el paquete al nodo origen. El nodo origen utiliza
esta información para interrogar a cada router sucesivo a lo largo de la ruta, ramificando el mapa de bits en más
subconjuntos. El proceso se repite hasta alcanzar destino de cada ruta.

El proceso de descubrimiento multitrayecto se ilustra utilizando la topología de la Figura 11-6. Antes de ver el
descubrimiento real del multipath, la recuperación de la información DSMAP para FEC [Link]/32 del Nodo2 se
ilustra usando MPLS ping.
Figura 11-6: Topología de ejemplo de descubrimiento de rutas múltiples

La usuaria ejecuta un ping MPLS (ver Ejemplo 11-16) y especifica que quiere ver la información DSMAP
(dsmap) para FEC [Link]/32 en el primer nodo (ttl 1) en el LSP que va vía Nodo2 (output nexthop
[Link]). El TTL del paquete expira en el Nodo2 y el Nodo2 envía una MPLS Echo Reply que contiene los
TLVs DSMAP de todos sus caminos hacia [Link]/32: vía Nodo3 y vía Nodo5. La información DSMAP del
primer camino se muestra en las líneas 17 a 23 y la información DSMAP del segundo camino se muestra en las
líneas 24 a 31. La salida del comando MPLS ping muestra las direcciones IP de destino que calculó a partir del
mapa de bits del DSMAP.
Ejemplo 11-16: Recuperación DSMAP usando MPLS ping

1 RP/0/0/CPU0:xrvr-1#ping mpls ipv4 [Link]/32 fec generic dsmap ttl 1 output nexthop
[Link] repeat 1
2
3 Envío de 1 eco MPLS de 100 bytes a [Link]/32,
4 el tiempo de espera es de 2 segundos, el intervalo de envío es de 0 mseg:
5
6 Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,
7 L": interfaz de salida etiquetada, "B": interfaz de salida no etiquetada,
8 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
9 'M' - solicitud malformada, 'm' - tlvs no soportados, 'N' - sin etiqueta
rx,
10 'P' - no rx intf label prot, 'p' - terminación prematura del LSP,
11 'R' - enrutador de tránsito, "I" - índice ascendente desconocido,
12 'X' - código de retorno desconocido, 'x' - código de retorno 0
13
14 Escriba la secuencia de escape para abortar.
15
16 L Eco Respuesta recibida de [Link]
17 DSMAP 0, DS Dirección Router [Link], DS Dirección Intf [Link]
18 Profundidad Límite 0, MRU [Etiquetas: Exp: 0]
1500 16004
19 Direcciones multitrayecto:
20 [Link] [Link] [Link]
[Link]
21 [Link] [Link] [Link]
[Link]
22 [Link] [Link] [Link]
[Link]
23 [Link]
24 DSMAP 1, DS Dirección Router [Link], DS Dirección Intf [Link]
25 Profundidad Límite 0, MRU [Etiquetas: Exp: 0]
1500 16004
26 Direcciones multitrayecto:
27 [Link] [Link] [Link]
[Link]
28 [Link] [Link] [Link]
[Link]
29 [Link] [Link] [Link]
[Link]
30 [Link] [Link] [Link]
[Link]
31 [Link] [Link] [Link]
32
33 El porcentaje de éxito es del 0% (0/1)

En el Ejemplo 11-17 se muestra la captura del paquete MPLS Echo Request. Específico a este paquete es el
Downstream Mapping TLV en las líneas 17 a 26. Dado que el Nodo1 no incluye una pila de etiquetas
en el TLV DSMAP y establece la dirección del nodo descendente en [Link] y el índice de interfaz en 0. El
mapa de bits de información de rutas múltiples incluye todas las direcciones.

Ejemplo 11-17: Paquete MPLS Echo Request capturado solicitando DSMAP

1 14:21:26.780585 MPLS (etiqueta 16004, exp 0, [S], ttl 1)

2 IP (tos 0x0, ttl 1, id 41, offset 0, flags [DF], proto UDP (17), length
124, opciones (RA))
3 [Link].3503> [Link].3503:
4 LSP-PINGv1, msg-type: MPLS Echo Request (1), longitud: 92
5 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6 (2)
6 Código de retorno: Ningún código de retorno o código de retorno contenido en
el TLV de código de error (0).
7 Subcódigo de retorno: (0)
8 Remitente Handle: 0x00004f76, Secuencia: 1
9 Sender Timestamp: 14:21:07.148877 Timestamp Receptor: no timestamp
10 Código privado del vendedor TLV (64512), longitud: 12
11 Id. de proveedor ciscoSystems (9)
12 Valor: 0001000400000004
13 Pila FEC de destino TLV (1), longitud: 12
14 Prefijo IPv4 genérico subTLV (14), longitud: 5
15 Prefijo IPv4: [Link] ([Link])
16 Longitud del prefijo: 32
17 TLV de asignación descendente (2), longitud: 24
18 MTU: 0, Tipo de dirección: IPv4 no numerada (2)
19 IP descendente: [Link]
20 Índice de interfaz ascendente: 0x00000000
21 Tipo Multipath: Conjunto de direcciones IPv4 con máscara de bits (8)
22 Límite de profundidad: 0
23 Longitud multitrayecto: 8
24 Información multitrayecto
25 Dirección IP: [Link] ([Link])
26 Máscara: ffffffff

Nodo2 responde con todos los caminos posibles incluidos como TLVs DSMAP en el paquete MPLS Echo
Reply. Este paquete se muestra en el Ejemplo 11-18. El primer TLV DSMAP se muestra en las líneas 12 a 22 y
el segundo en las líneas 24 a 34.
Ejemplo 11-18: Captura del paquete MPLS Echo Reply multipath DSMAP

1 14:21:26.782376 IP (tos 0xc0, ttl 255, id 19, offset 0, flags [none], proto UDP
(17), longitud 140)
2 [Link].3503> [Link].3503:
3 LSP-PINGv1, msg-type: MPLS Echo Reply (2), length: 112
4 reply-mode: Respuesta mediante un paquete UDP IPv4/IPv6
(2)
5 Código de retorno: Etiqueta cambiada a profundidad de pila
1 (8)
6 Subcódigo de devolución: (1)
7 Remitente Handle: 0x00004f76, Secuencia: 1
8 Sender Timestamp: 14:21:07.148877 Hora de recepción: 14:21:05.127492
9 Código privado del vendedor TLV (64512), longitud: 12
10 Id. de proveedor ciscoSystems (9)
11 Valor: 0001000400000004
12 TLV de asignación descendente (2), longitud: 28
13 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
14 IP descendente: [Link]
15 Interfaz descendente IP: [Link]
16 Tipo Multipath: Conjunto de direcciones IPv4 con máscara
de bits (8)
17 Límite de profundidad: 0
18 Longitud multitrayecto: 8
19 Información multitrayecto
20 Dirección IP: [Link] ([Link])
21 Máscara: 8964a915
22 Elemento de etiqueta descendente, Etiqueta: 16004, Exp: 0, EOS: 1,
Protocol: 0 (Desconocido)
23
24 TLV de asignación descendente (2), longitud: 28
25 MTU: 1500, Tipo de dirección: IPv4 numerada (1)
26 IP de bajada: [Link]
27 IP de la interfaz de bajada: [Link]
28 Tipo Multipath: Conjunto de direcciones IPv4 con máscara de bits (8)
29 Límite de profundidad: 0
30 Longitud multitrayecto: 8
31 Información multitrayecto
32 Dirección IP: [Link] ([Link])
33 Máscara: 769b56ea
34 Elemento de etiqueta descendente, Etiqueta: 16004, Exp: 0, EOS: 1,
Protocol: 0 (Desconocido)

En el ejemplo de descubrimiento multipath, el usuario inicia un traceroute multipath en Nodo1 para el FEC ligado
al prefijo loopback [Link]/32 de Nodo4.

El propio Nodo1 tiene dos rutas de igual coste hacia [Link]/32: vía Nodo2 y vía Nodo6. Traceroute explora
primero el camino a [Link]/32 vía Nodo6, usando la dirección IP de destino [Link].
Nodo1 envía un MPLS Echo Request con dirección de destino [Link] y TTL=1 a Nodo6. El TTL expira en
el Nodo6 y el Nodo6 devuelve una Echo Reply que contiene un único DSMAP TLV, para la ruta vía Nodo5. El
mapa de bits de la dirección en ese DSMAP TLV contiene todas las direcciones puesto que hay solamente una
sola trayectoria. Ver Figura 11-7.

Figura 11-7: Ilustración de traceroute multitrayecto - paso 1

Figura 11-8: Ilustración de traceroute multitrayecto - paso 2

Figura 11-9: Ilustración de traceroute multitrayecto - paso 3

Figura 11-10: Ilustración de traceroute multitrayecto - paso 4

Figura 11-11: Ilustración de traceroute multitrayecto - paso 5

Nodo1→Nodo6→Nodo5→Nodo4: [Link] vía Gi0/0/0/0

Nodo1→Nodo2→Nodo3→Nodo4(enlace1): [Link] via Gi0/0/0/1

Nodo1→Nodo2→Nodo3→Nodo4(link2): [Link] via Gi0/0/0/1
Nodo1→Nodo2→Nodo5→Nodo4: [Link] via Gi0/0/0/1

Ejemplo 11-19: Ejemplo de salida de consola MPLS multipath traceroute

RP/0/0/CPU0:xrvr-1#traceroute mpls multipath ipv4 [Link]/32 fec generic Starting

LSP Path Discovery for [Link]/32

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

retorno 0 Escriba la secuencia de escape para abortar.

¡LL!
Ruta 0 encontrada,
output interface GigabitEthernet0/0/0 nexthop [Link] source
[Link] destination [Link]
¡LL!
Ruta 1 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]
¡!
Ruta 2 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]
¡L!
Ruta 3 encontrada,
output interface GigabitEthernet0/0/0/1 nexthop [Link] source
[Link] destination [Link]

Rutas (encontradas/rotas/no exploradas)

(4/0/0) Petición de eco (enviada/fallida)
(9/0)
Eco Respuesta (recibido/timeout) (9/0)
Tiempo total transcurrido 89 ms

El usuario puede ejercitar cualquiera de las rutas desde Nodo1 a [Link]/32 utilizando las direcciones de
destino y la información de nexthop proporcionada por el traceroute multipath. Por ejemplo, para enviar
un
[Link]/32 a través de la ruta Nodo1→Nodo2→Nodo5→Nodo4 el usuario puede especificar la dirección de
destino [Link] y la interfaz de salida GIO/0/0/1 y/o el nexthop [Link] (Nodo2). Esto se ilustra en el
Ejemplo 11-20. Recuerde que en la convención de direccionamiento IP, el último dígito de una dirección IP de
interfaz es el número del nodo.

Ejemplo 11-20: Traceroute MPLS a lo largo de una ruta específica

RP/0/0/CPU0:xrvr-1#traceroute mpls ipv4 [Link]/32 fec generic destination [Link] output

nexthop [Link]

Rastreo de MPLS Label Switched Path a [Link]/32, el tiempo de espera es de 2 segundos.

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

retorno 0 Escriba la secuencia de escape para abortar.

0 [Link] MRU 1500 [Etiquetas: 16004 Exp: 0]

L 1 [Link] MRU 1500 [Etiquetas: 16004 Exp: 0] 10 ms
L 2 [Link] MRU 1500 [Etiquetas: implicit-null Exp: 0] 10 ms
¡! 3 [Link] 10 ms

11.2.5 Ping y Traceroute MPLS utilizando Nil-FEC

Dado que MPLS Ping y Traceroute interactúan con su correspondiente plano de control para la verificación de
la ruta de un LSP, el soporte de una nueva tecnología como Segment Routing puede requerir cambios o
adiciones a estas interacciones o a las propias herramientas.

Los operadores necesitan una herramienta básica de verificación del plano de datos antes de que hayan
estandarizado y desarrollado los cambios anteriores en las herramientas. Esto es necesario ya que IP ping y
traceroute no son suficientes en una red MPLS ya que pueden no detectar fallos MPLS, como hemos visto al
principio de este capítulo.

En el RFC 4379 del IETF se define una FEC denominada "Nil-FEC". El uso de esta FEC especifica que no se
asocia ninguna FEC explícita (plano de control) a la etiqueta del paquete. Por lo tanto, se puede utilizar la
infraestructura de ping y traceroute existente con un Nil-FEC en el TLV de la pila FAC de destino.
Nil-FEC ping and traceroute proporciona un mecanismo básico para verificar el plano de datos especificando
una pila de etiquetas en la línea de comandos para llegar al destino. El paquete MPLS Echo Request se
conmuta por etiquetas al destino utilizando únicamente etiquetas MPLS. Utilizando Nil-FEC, no hay
interacción con el plano de control, por lo que no se requieren cambios de software. Es compatible con
tecnologías nuevas y emergentes (incluido el enrutamiento por segmentos), ya que la ruta sólo se especifica
como una pila de etiquetas.
11.3 MPLS OAM para enrutamiento por segmentos
Las extensiones de Segment Routing para el protocolo LSP ping están en desarrollo y se están especificando en el
IETF como parte de draft-ietf-mpls-spring-lsp-ping. En el momento de escribir este libro, el trabajo de
especificación aún estaba en curso y la implementación aún no se había publicado en las plataformas Cisco IOS
XR. Cubriremos esto con más detalle a medida que las especificaciones e implementaciones maduren, quizás en
una futura revisión de este libro.

Mientras tanto, los trayectos MPLS SR pueden verificarse mediante las herramientas MPLS OAM existentes
utilizando Nil- FEC o FEC genérico, como se ha descrito anteriormente en este capítulo.
11.4 Resumen
Las conocidas herramientas IP ping y traceroute pueden utilizarse en una red MPLS, pero no son suficientes
para diagnosticar todos los problemas específicos de MPLS.

IP ping y traceroute se basan en la funcionalidad ICMP. ICMP se ha ampliado para proporcionar más
información relacionada con MPLS para IP traceroute.

MPLS ping y traceroute están específicamente diseñados para diagnosticar problemas de transporte MPLS y
la coherencia entre el plano de control y el plano de datos.

Las herramientas MPLS utilizan mensajes MPLS Echo Request y Reply transportados en paquetes UDP en
un formato TLV extensible que permite mejorar las capacidades de descubrimiento y verificación de rutas.

Aunque se están desarrollando extensiones específicas SR MPLS para las herramientas MPLS, Generic
FEC y Nil-FEC pueden utilizarse para diagnosticar fallos en una red SR MPLS.
11.5 Referencias
[ draft-ietf-mpls-spring-lsp-ping], Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, S., Gredler, H. y
M. Chen, "Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using MPLS Dataplane",
draft-ietf-mpls-spring-lsp-ping (work in progress), mayo de 2016, [Link]
mpls-spring-lsp-ping.

[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792,
septiembre de 1981, [Link]

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. y A. Conta, "MPLS
Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, enero de 2001,
[Link]

[RFC4379] Kompella, K. y G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures", RFC 4379, DOI 10.17487/RFC4379, febrero de 2006, [Link]

[RFC4950] Bonica, R., Gan, D., Tappan, D. y C. Pignataro, "ICMP Extensions for
Multiprotocol Label Switching", RFC 4950, DOI 10.17487/RFC4950, agosto de 2007,
[Link]

1 UDP se utiliza por razones históricas. Los vendedores de routers habían implementado inicialmente una
interpretación estricta del RFC 792 que dice: "(...) no se envían mensajes ICMP sobre mensajes ICMP". Debido
a esto, Van Jacobson escribió una versión funcional de traceroute que utilizaba paquetes sonda UDP en lugar de
ICMP. Más tarde, RFC 1122 sección 3.2.2 indicó que los mensajes ICMP no deben ser enviados en respuesta a
mensajes de error ICMP. Véase también
[Link]

2 Esto contrasta con el IETF RFC 1812 que especifica: "(...) la dirección IP de origen en un mensaje ICMP
originado por el router DEBE ser una de las direcciones IP asociadas a la interfaz física sobre la que se
transmite el mensaje ICMP."

3 [Link]

4 Dado que se ha añadido IPv4 Explicit-Null, Nil-FEC no puede utilizarse para verificar rutas MPLS con
señalización IPv6.
12 SEGMENTO ENRUTAMIENTO IPV6 FECHA
PLANO
El enrutamiento por segmentos se aplica tanto a los planos de datos IPv6 como MPLS. La diferencia entre
ambos no está en la arquitectura, sino en la implementación de esa arquitectura.

Cuando se utiliza el plano de datos MPLS para transportar paquetes IPv6, la Lista de Segmentos o Lista SID se
impone en la cabecera del paquete en forma de pila de etiquetas MPLS. Cada etiqueta representa un segmento
y la etiqueta superior representa el Segmento Activo. Cuando un segmento ha finalizado, la etiqueta que lo
representa se retira de la pila de etiquetas. Enrutamiento de segmentos El plano de datos MPLS utiliza la
arquitectura MPLS existente.

Cuando se utiliza el plano de datos IPv6 de Enrutamiento por Segmentos para transportar paquetes IPv6
(comúnmente denominado SRv6), la Lista de Segmentos se impone en la cabecera del paquete en una
Cabecera de Enrutamiento por Segmentos (SRH). Esta cabecera es un nuevo tipo de cabecera de
enrutamiento, un tipo de cabecera de extensión descrita en la especificación IPv6 IETF RFC 2460. Un puntero
en la SRH apunta al Segmento Activo en la lista de segmentos codificados en la cabecera. Cuando un
segmento ha finalizado, no se elimina de la lista, sino que el puntero se actualiza para apuntar al siguiente
segmento de la lista.

Para habilitar SRv6 en una red, sólo los nodos que tienen que procesar la cabecera del paquete deben tener
soporte de plano de datos SRv6. Todos los demás nodos de la red pueden ser nodos IPv6 normales. SRv6 no
requiere una actualización de la red, ya que los nodos SRv6 y no SRv6 son totalmente interoperables y pueden
coexistir en la red. Esto hace posible un despliegue gradual de SRv6 en la red.

En este capítuloofrecemos una visión general de SRv6 y de sus fundamentales. A medida que avancemos en el
resto del libro, que se centra en el plano de datos MPLS, se hará evidente para el lector perspicaz que todos esos
conceptos, mecanismos y habilidades también se aplican a SRv6 - la arquitectura de Enrutamiento por
Segmentos es común para ambos planos de datos. Los detalles de implementación y los modelos de despliegue se
aplazarían. Se tratarán más detalles sobre estos aspectos de SRv6 en una futura parte de este libro.
12.1 "Segmento" en IPv6
La noción de "segmento" no es nueva en IPv6. El término "segmento" se utiliza en la sección Routing Header
de la especificación del protocolo IPv6 IETF RFC 2460, donde se utiliza para indicar el tramo (o span) de una
ruta enrutada de origen entre dos saltos de esa ruta.

En el enrutamiento por segmentos, un segmento puede ser cualquier instrucción: topológica, de servicio, etc.

La Figura 12-1 muestra los diferentes tipos de nodos en una ruta IPv6 de Enrutamiento por Segmentos: Nodo11
es el Nodo Origen; Nodo2, Nodo6 y Nodo12 son Nodos de Punto Final de Segmento; Nodo12 es también nodo
destino; Nodo1, Nodo4 y Nodo7 son Nodos de Tránsito.
Figura 12-1: Ruta SRv6
DESTACAR
Con SRv6, los segmentos verdaderamente locales se utilizarán raramente.

Por ejemplo, un SRv6 Adj-SID es global a su dominio SR. El dominio SR enruta los paquetes con el SID hasta el nodo que lo origina
y este nodo aplica la instrucción (función) asociada localmente al Adj-SID: decir, activa el siguiente SID y reenvía el paquete a lo
largo de la adyacencia/interfaz asociada.

Por tanto, un SRv6 Adj-SID puede verse como un Prefix-SID cuya función es "reenviar en esta adyacencia".

En SRv6, utilizaremos muchas formas diferentes de funciones (instrucciones) asociadas a un Prefijo-SID: por ejemplo, buscar el
siguiente SID activo en un VRF específico, duplicar el paquete y enviar cada copia por dos rutas disjuntas relacionadas con el SID,
etc.

Nodo fuente

Un Nodo Origen puede ser cualquier nodo que origine un paquete IPv6 con una Cabecera de Enrutamiento de
Segmento:

Un nodo que origina un paquete IPv6 con SRH

Un nodo de entrada (en muchos casos generales un router) de un Dominio SRv6 que inserta un SRH en la
cabecera IPv6 o impone una cabecera IPv6 externa con SRH en el paquete.

Segmento Punto final Nodo

Un Nodo de Punto Final de Segmento es el nodo que termina un segmento. La Dirección de Destino de un
paquete IPv6 con SRH corresponde a una dirección del Nodo de Punto Final de Segmento. El Nodo de Punto
Final de Segmento examina y actualiza el SRH y aplica la instrucción asociada con el Segmento Activo, el
segmento de Dirección de Destino del paquete.

Nodo de tránsito

Un Nodo de Tránsito es un nodo (más concretamente un router) en la ruta del paquete, y que no es un Nodo
Final de Segmento. La Dirección de Destino del paquete no corresponde a una dirección de un Nodo de
Tránsito.

La especificación IPv6 (IETF RFC 2460) especifica que un nodo no puede procesar la Cabecera de
Enrutamiento si ese nodo no se corresponde con la Dirección de Destino del . Un Nodo de Tránsito reenvía el
paquete IPv6 basándose en su Dirección de Destino IPv6 sin mirar el SRH ni tocarlo.
Por lo tanto, un Nodo de Tránsito no necesita soportar SRv6 para reenviar el paquete.
12.2 Identificadores de segmento en SRv6
Los segmentos en SRv6 se identifican mediante direcciones IPv6 de 128 bits. Desde el punto de vista de la
señalización, esto es mucho más sencillo en comparación con el plano de datos MPLS: no es necesario
anunciar nada más que prefijos IPv6. El prefijo es el identificador de segmento (SID). Una dirección IPv6
puede representar algo más que un router. Puede representar una interfaz, un dispositivo, un servicio, una
aplicación, etc. O puede representar un conjunto de cualquiera de ellos.

Las direcciones IPv6 se pueden resumir, eso también se aplica a las direcciones IPv6 utilizadas como SID. La
integración no es posible para los SID MPLS.
12.3 Recordatorio de cabeceras IPv6
IPv6 utiliza dos tipos distintos de cabeceras: la cabecera (principal) IPv6 y las cabeceras de extensión IPv6.
La cabecera principal de IPv6 es equivalente a la cabecera básica de IPv4. Al comparar la cabecera IPv6 con
la cabecera IPv4, se han modificado algunos campos y se han eliminado otros.

Uno de los campos eliminados es el de opciones de IPv4. El campo de opciones que existía en la cabecera IPv4
se utilizaba para transmitir información adicional sobre el paquete, o sobre la forma en que éste debía
procesarse. La opción de alerta de enrutador IP (IETF RFC 2113) es probablemente la opción más conocida y
utilizada, alerta a los enrutadores de tránsito para que examinen el contenido del IPv4. En IPv6 la funcionalidad
de las opciones se elimina de la cabecera principal y se implementa a través de un conjunto de cabeceras
adicionales denominadas Cabeceras de Extensión (IETF RFC 2460). Por lo tanto, la cabecera principal de IPv6
tiene un tamaño fijo (40 bytes), mientras que cabeceras de extensión personalizadas se añaden según sea
necesario.

El campo Tipo de protocolo de la cabecera IPv4 que se utiliza para indicar qué cabecera de protocolo de capa
superior viene después de la cabecera IPv4, ha pasado a llamarse campo Siguiente cabecera en la cabecera IPv6.

Encabezado de extensión IPv6

El uso de Cabeceras de Extensión permite extender IPv6 para soportar futuras necesidades y capacidades.
Un paquete IPv6 puede llevar cero, una o más cabeceras de extensión de longitud variable. En un paquete
IPv6 típico no hay cabeceras de extensión. Si el paquete requiere un manejo especial por parte los routers
intermedios en su ruta o del nodo de destino, entonces se añaden una o más Cabeceras de Extensión en la
cabecera del paquete.

Las cabeceras de extensión se encuentran entre la cabecera principal de IPv6 y la cabecera de la capa superior
de un paquete. Existe un pequeño número de tipos de cabecera de extensión, cada uno identificado por un
valor de tipo distinto. Si una cabecera de extensión está presente en la cabecera, el campo Next Header de la
cabecera IPv6 contiene el tipo de la cabecera de extensión, por ejemplo, el tipo 43 para la cabecera de
enrutamiento. El campo Next Header de la cabecera de extensión indica el tipo de la siguiente cabecera de
extensión si hay más cabeceras de extensión en el paquete. El campo Next Header de la última cabecera de
extensión indica el protocolo de capa superior (como TCP, UDP o ICMPv6) que contiene el .

La Figura 12-2 ilustra la cabecera IPv6 con cero o más cabeceras de extensión. Forman una cadena de
cabeceras. Cada cabecera indica en su campo Next Header el tipo de cabecera que sigue, hasta que la
última cabecera de la cadena identifica el protocolo de capa superior.
Figura 12-2: Encadenamiento de cabeceras IPv6
12.4 Cabecera de enrutamiento
Uno de los tipos de cabecera de extensión IPv6 es la cabecera de enrutamiento; su número de tipo es 43. La
cabecera de enrutamiento es utilizada por una fuente IPv6 para listar uno o más nodos intermedios para que el
paquete viaje en su camino hacia el destino final. El nodo de origen puede utilizar la cabecera de enrutamiento
para enrutar el paquete a través de la red. Se han definido diferentes variantes de cabeceras de enrutamiento:
Source Route (IETF RFC 5095 obsoleto), Mobility support (IETF RFC 6275), Routing Protocol for Low-Power
and Lossy Networks (RPL) (IETF RFC 6554).

La cabecera de enrutamiento tiene el formato (IETF RFC 2460) que se muestra en la Figura 12-3.

Figura 12-3: Formato de cabecera de enrutamiento IPv6

Cabecera siguiente: Identifica el tipo de cabecera que sigue inmediatamente a la cabecera de Enrutamiento.
Utiliza los mismos valores que el campo Protocolo IPv4.

Hdr Ext Len: Longitud la cabecera de enrutamiento.

Tipo de enrutamiento: identificador de un tipo concreto de cabecera de enrutamiento.

Segmentos restantes: Número de segmentos de ruta restantes, es decir, el número de nodos intermedios
enumerados explícitamente que quedan por visitar antes de llegar al destino final.

datos específicos del tipo: determinados por el campo Routing Type.

En general, las Cabeceras de Extensión no son examinadas o procesadas por los nodos intermedios a lo largo
camino del paquete hacia su destino. Los nodos intermedios reenvían el paquete basándose en la Dirección de
Destino de la Cabecera IPv6 principal. La excepción es la Cabecera de Opciones Hop-by-hop que transmite
información opcional que debe ser examinada por cada nodo a lo largo de la ruta del paquete. En el
nodo de destino, se examina y procesa la siguiente cabecera, tal y como se indica en el campo Next Header de
la cabecera IPv6. La siguiente cabecera puede ser una cabecera de extensión o una cabecera de protocolo de
capa superior.

Si un nodo recibe un paquete y la Dirección de Destino del paquete corresponde a una dirección del nodo,
entonces el paquete examina la Cabecera de Extensión, si está presente. Si el Encabezado de Extensión es un
Encabezado de Enrutamiento con un Tipo de Enrutamiento que el nodo no reconoce, entonces el
comportamiento del nodo depende valor campo Segmentos Izquierdos:

Si el valor del campo Segments Left es cero, el nodo ignora la cabecera de enrutamiento y procesa la
siguiente cabecera del paquete.

Si el valor del campo Segments Left no es cero, el nodo descarta el paquete y envía un mensaje ICMP
"Parameter Problem" a la Dirección de Origen del paquete.

IETF RFC 2460 define la variante de Routing Header con Routing Type 0, también conocido como "RH0".
Este tipo de cabecera de enrutamiento define el modelo clásico de enrutamiento de origen para IPv6. La
cabecera de enrutamiento de tipo 0 ha quedado obsoleta por la RFC 5095 del IETF, motivada por problemas de
seguridad. Para más detalles sobre las amenazas a la seguridad, véase IETF RFC 5095 y RFC 4942. Estos
problemas de seguridad se han abordado en la especificación SRH.
12.5 Cabecera de enrutamiento de segmento
El Segment Routing Header (SRH) es un nuevo tipo del Routing Header existente, con un Routing Type 4
propuesto.

El formato SRH es muy similar al de la cabecera de enrutamiento de tipo 0. Los problemas de seguridad que
llevaron a la depreciación del encabezado de enrutamiento de tipo de enrutamiento se abordan para el
encabezado de enrutamiento de segmento a través del TLV HMAC que se puede agregar en el encabezado.

La cabecera de enrutamiento de segmento hereda las propiedades de la cabecera de enrutamiento: sólo debe
aparecer una vez en los paquetes; y si el campo Segments Left tiene un valor de 0 entonces la SRH se ignora
(no se descarta) y el paquete se procesa basándose en la siguiente cabecera del paquete.

La Figura 12-4 muestra el formato de la cabecera de enrutamiento de segmento (SRH).

Figura 12-4: Formato de cabecera de enrutamiento de segmento

Cabecera siguiente: Identifica el tipo de cabecera que sigue a la SRH.

Hdr Ext Len: la longitud de la cabecera SRH.

Tipo de enrutamiento: valor propuesto para el tipo de SRH: 4.

Segmentos Izquierda: índice del Segmento Activo actual en la Lista de Segmentos del SRH. Este índice es
se decrementa por cada segmento completado.

Primer : índice del primer segmento de la ruta en la Lista de segmentos del SRH. Dado que los elementos
de la Lista de Segmentos se colocan en orden inverso, éste es el último elemento de la Lista de
Segmentos. Esto ayuda a acceder a los TLV que siguen a la lista de SID.

Banderas:

Bandera C (Limpieza): Si se establece, entonces el SRH debe ser eliminado del paquete antes de
reenviar el paquete en el último ; esto es similar equivalente a MPLS PHP.

P-flag (Protegido): Se establece cuando un Nodo Terminal de Segmento ha redirigido el paquete a través
del mecanismo FRR.

Bandera O (OAM): Si está activado, este paquete es un paquete de operaciones y gestión (OAM).

Bandera A (Alerta): Si se establece, entonces hay objetos importantes de tipo valor de longitud (TLV)

presentes en el SRH. Indicador H (HMAC): Si está activado, el TLV HMAC está presente y se

codifica como el último TLV del SRH.

SRH.

No utilizado: para uso futuro.

Reservado: para uso futuro.
Lista de segmentos[x]: Lista de entradas de 128 bits, que representa cada segmento de la ruta. La lista de
segmentos se codifica en el orden inverso del recorrido: el último segmento ocupa la primera posición (lista
de segmentos[0]) de la lista y el primer segmento ocupa la última posición (lista de segmentos[n-1]).

Objetos opcionales Tipo/Longitud/Valor, véase más adelante.

DESTACAR

El SID activo se encuentra en el campo de dirección de destino (DA) de la cabecera IPv6.

Cuando un nodo recibe un paquete con la dirección de destino igual a un SID local, decimos que el nodo actúa como punto final de
segmento o punto final de SID.

Un punto final SID realiza la instrucción/función asociada al SID: por ejemplo, función nula para un Prefix-SID, reenvío en una interfaz
específica para un Adj-SID (global).

Un punto final SID en el SRH el siguiente SID a activar. Utiliza el campo Segmentos a la izquierda como desplazamiento en la lista
de SID.

Activar un SID significa copiar ese SID en la dirección de destino y reenviar el paquete según esta dirección de destino actualizada.

Si el SID es el último SID (Segmentos Izquierdos = 0), entonces el punto final SID procesa la carga útil de acuerdo con el campo Next
Header en el SRH.

Los TLVs opcionales en el SRH contienen información que puede ser utilizada por el Nodo de Punto Final de
Segmento, el nodo que corresponde a la Dirección de Destino IPv6 del . El uso principal de estos TLVs es
proporcionar información al destino final del paquete sobre la ruta del paquete. La capa de enrutamiento no
utiliza la información en los TLVs, pero puede ser utilizada para otros propósitos, como OAM.

Nodo de entrada TLV

El TLV de nodo de entrada es opcional y contiene un campo de 128 bits con la identidad del nodo por el que el
paquete ha entrado en el dominio de enrutamiento de segmento.

Nodo de salida TLV

El TLV de nodo de salida es opcional y contiene un campo de 128 bits con la identidad del nodo en el que se
espera que el paquete salga del dominio de enrutamiento de segmento.

Contenedor opaco TLV

El contenedor opaco TLV es opcional y contiene 128 bits de datos. Estos datos no son relevantes para la capa
de enrutamiento, pero pueden utilizarse para transmitir otra información al nodo de destino del paquete.

TLV de relleno

El TLV Padding es opcional y se utiliza para alinear el SRH en un límite de 8 octetos.

HMAC TLV

HMAC TLV es opcional y contiene la información HMAC. El formato del TLV HMAC se muestra en la Figura
12-5.

Figura 12-5: Formato TLV de HMAC

12.6 Procedimientos de SSR
Un paquete con un SSR atraviesa varios nodos de la red. Esta sección explica cómo procesan el los diferentes
nodos de la ruta. La topología de red de la Figura 12-6 ilustra el camino de un paquete con SRH. Un paquete es
dirigido desde el Nodo Origen Nodo11 a través de los Nodos Terminales de Segmento Nodo1 y Nodo6 hacia el
Nodo Destino12. El Nodo12 es también el Nodo Final de Segmento del último segmento.

Figura 12-6: Procedimientos SSR - topología de red

12.6.1 Nodo fuente
Un Nodo Origen puede ser cualquier nodo que origine un paquete IPv6 con una Cabecera de Enrutamiento de
Segmento:

Un host que origina un paquete IPv6 con SRH

Un nodo de entrada (en muchos casos un router) de un Dominio SRv6 que inserta un SRH o empuja un
nuevo Encabezado IPv6 externo con SRH.

La lista de segmentos especifica la ruta del paquete. Esta ruta puede ser configurada localmente, calculada
localmente o proporcionada por un controlador externo. La Lista de Segmentos es {S[0], S[1], ..., S[n-1]},
S[x-1] el segmento xth de la lista. El Nodo Origen inserta la Lista de Segmentos en el SRH de la cabecera del
paquete.

Cuando el Nodo Origen origina el paquete, crea el SRH para el paquete de la siguiente manera y lo inserta en la
cabecera:

"Lista de segmentos": n segmentos codificados en el orden inverso de la ruta (último segmento en primera ,
primer segmento en última posición): (0:S[n-1], 1:S[n-2], ..., n-1:S[0]), donde "x:" indica el índice en el
SRH.

Campo "Segmentos a la izquierda":

se establece en n-1 Campo "Primer
segmento": se establece en n-1
El DA del paquete se establece como el primer segmento de la
ruta DA = S["Segmentos Izquierda"]

HMAC TLV y/u otros TLV pueden añadirse al SRH

El Nodo Origen envía el paquete a la Dirección de Destino IPv6 del paquete.

El Nodo11 de la Figura 12-6 es el Nodo Origen de un paquete con Lista de Segmentos {SID(1), SID(6),
SID(12)}. El campo Lista de Segmentos en el SRH se codifica como L=(0:SID(12), 1:SID(6), 2:SID(1)); L se
representa en el orden en que se encuentra en el SRH. El campo Segmentos Izquierdos y el campo Primer
Segmento se establecen en 2. La Dirección de Destino se establece en L[2]=SID(1); este es el Segmento Activo.
El paquete con SRH se representa en la Figura 12-7 entre Nodo11 y Nodo1.
Figura 12-7: Procedimientos SRH - Cabecera de paquete

12.6.2 Segmento Punto final Nodo

Un Nodo de Punto Final de Segmento es un nodo cuya dirección es la Dirección de Destino de un paquete
IPv6 con SRH. El Nodo de Punto Final de Segmento realiza las operaciones mostradas en la Figura 12-8
cuando recibe un paquete con SRH.
Figura 12-8: Operaciones de nodo de punto final de segmento

El Segmento Activo es el segmento de la Lista de Segmentos al que apunta el campo Segmentos Izquierdos. El
Segmento Activo también se establece como la Dirección de Destino del paquete. En cada Nodo Final de
Segmento la Dirección de Destino se actualiza con el siguiente Segmento Activo encontrado en la Lista de
Segmentos. Esto cumple con las reglas IETF RFC 2460 para la cabecera de enrutamiento.

El Nodo1 en la Figura 12-6 es el Nodo del Punto Final del Segmento del primer segmento. Nodo1 encuentra
Segmentos Izquierda
= 2 en el paquete. Disminuye el campo Segmentos Izquierdos a 1 y actualiza la Dirección de Destino IPv6 al
siguiente segmento de la lista: 2001::6. Esto es L[Segmentos Izquierda]= L[1]= 2001::6. Nodo1 envía el
paquete a la Dirección de Destino 2001::6. El Nodo1 equilibra la carga de paquetes en los dos caminos hacia el
Nodo6.

Cuando el paquete llega al Nodo6, éste aplica los mismos procedimientos. Disminuye el campo Segmentos
Izquierdos a 0 y actualiza la Dirección de Destino IPv6 a L[Segmentos Izquierdos]= L[0]= 2001::12, y
envía el paquete a 2001::12.

El Nodo12 es el destino final del paquete. El paquete llega al Nodo12 con el campo Segments Left 0, por lo
que Nodo12 procesa el protocolo de capa superior del paquete.

12.6.3 Nodo de tránsito

Un Nodo de Tránsito es un nodo en la ruta del paquete, pero que no es el punto final de un segmento. El RFC
2460 del IETF especifica que un nodo no puede procesar la cabecera de encaminamiento si dicho nodo no se
corresponde con la dirección de destino del . La especificación IPv6 indica que dicho Nodo de Tránsito debe
reenviar el paquete a su Dirección de Destino IPv6 sin tocar el SRH. Un Nodo de Tránsito no necesita soportar
SRv6 para transportar el paquete.

Nodo2, Nodo4 y Nodo7 en la Figura 12-6 son Nodos de Tránsito. No examinan el SRH y no actualizan la
Dirección de Destino en la Cabecera IPv6. Simplemente reenvían el paquete basándose en su Dirección de
Destino IPv6.
12.7 Inserción de SRH frente a inserción de cabecera IPv6
SRv6 permite múltiples modos de :

Inserción de SRH en el origen del paquete

Inserción de SRH en el nodo de entrada/enrutador del dominio de enrutamiento de segmento

Introducir una nueva cabecera IPv6 externa con SRH en el nodo de entrada del dominio de enrutamiento de
segmento.

Estos modos de funcionamiento se ilustran con la topología de red de la Figura 12-9. El origen del paquete IPv6
es NodoA, su destino es NodoB. El paquete sigue la ruta a través del Nodo2.

Figura 12-9: Inserción de SRH frente a empuje de cabecera IPv6 - topología de red

12.7.1 Inserción de SSR en origen

El nodo origen con capacidad SRv6 origina el paquete IPv6 con un SRH. El SRH permanece en el y se utiliza a
lo largo de la ruta del paquete. Finalmente, el paquete se entrega a su destino con el en la cabecera. Véase la
Figura 12-10.
Figura 12-10: Inserción de SRH en origen del paquete

Opcionalmente, el SRH puede ser eliminado del paquete antes de entregarlo a su destino. Esto se puede
conseguir activando la bandera C (Clear) en el SRH. Véase la Figura 12-11. El Nodo12 recibe el paquete con
Segmentos Izquierdos 1 y el C-flag activado. El Nodo12 aplica las operaciones de la Figura 12-8. El Nodo12
primero disminuye el campo Segmentos Izquierdos, que ahora se convierte en 0. Luego el Nodo12 actualiza la
Dirección de Destino a L[Segmentos Izquierdos]= L[0]= 2001::B. Dado que Segments Left== 0 y C-flag está
activado, el Nodo12 elimina el SRH de la cabecera y reenvía el paquete a su NodoB de destino.
Figura 12-11: Inserción de SRH en el origen del paquete, bandera C activada

12.7.2 Inserción SRH a la entrada

El nodo origen sin capacidad SRv6 origina un paquete IPv6 sin SRH. Cuando el llega al nodo de entrada del
dominio de enrutamiento de segmento, el nodo de entrada inserta un SRH en el paquete. El SRH se elimina
del paquete antes de entregarlo a su destino; esto se consigue activando la bandera C (Clear) en el SRH. Véase
la Figura 12-12. El Nodo12 recibe el paquete con Segmentos Izquierdos 1 y la bandera C activada. El Nodo12
aplica las operaciones de la Figura 12-8. El Nodo12 primero disminuye el campo Segmentos Izquierdos, que
ahora se convierte en 0. Luego el Nodo12 actualiza la Dirección de Destino a L[Segmentos Izquierdos]=
L[0]= 2001::B. Dado que Segments Left== 0 y C-flag está activado, el Nodo12 elimina el SRH de la cabecera
y reenvía el paquete a su NodoB de destino.
Figura 12-12: Inserción de SRH en el nodo de entrada del dominio SR

12.7.3 Inserción de cabecera Encap a la entrada

Un nodo origen sin capacidad SRv6 origina un paquete IPv6 sin SRH. Cuando el paquete llega al nodo de
entrada (normalmente un router) del Dominio de Enrutamiento por Segmentos, éste introduce una nueva
Cabecera IPv6 externa con SRH en el paquete. La cabecera IPv6 externa completa con SRH se elimina en el
nodo de salida (normalmente un ) del dominio de enrutamiento de segmento. Véase la Figura 12-13. Nodo12
es el nodo correspondiente a la Dirección de Destino en la cabecera IPv6 externa. Por lo tanto, el Nodo12
procesa la siguiente cabecera, que es una cabecera IPv6. El Nodo12 despoja la cabecera exterior del paquete y
reenvía el paquete IPv6 expuesto a su NodoB de destino.
Figura 12-13: Empujar cabecera IPv6 externa con SRH en el nodo de entrada del dominio SR
12.8 Resumen
SRv6 es la implementación de la arquitectura de enrutamiento por segmentos utilizando el plano
de datos IPv6 Más sencillo porque no hay señalización ni reenvío MPLS, mejor escala con
integración
El enrutamiento por segmentos para el plano de datos IPv6 (SRv6) especifica un encabezado de
enrutamiento por segmentos (SRH) que se adhiere a la especificación del encabezado de enrutamiento del
estándar IPv6.

Un ID de segmento SRv6 es una dirección IPv6 y la lista de segmentos está codificada en el SRH

El SRH puede ser añadido por el nodo que origina los paquetes o por el nodo de entrada de una red.

SRv6 funciona con nodos IPv6 estándar; sólo los hosts y routers específicos que operan en el SRH
necesitan soportar SRv6.

Funciones como la protección TI-LFA, la ingeniería de tráfico, etc. también se extienden a SRv6.
12.9 Referencias
[draft-ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, J., Kosugi,
T., Vyncke, E. y D. Lebrun, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- segment-routing-
header (trabajo en curso), septiembre de 2016,
[Link]

[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, febrero de 1997,
[Link]

[RFC2460] Deering, S. y R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI
10.17487/RFC2460, diciembre de 1998, [Link]

[RFC4942] Davies, E., Krishnan, S. y P. Savola, "IPv6 Transition/Co-existence Security Considerations",

RFC 4942, DOI 10.17487/RFC4942, septiembre de 2007, [Link]

[RFC5095] Abley, J., Savola, P. y G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6",
RFC 5095, DOI 10.17487/RFC5095, diciembre de 2007,
[Link]
RESUMEN
El propósito de esta primera parte del libro sobre Enrutamiento por Segmentos ha sido proporcionar una
descripción objetiva de su bloque fundamental junto con algunos aspectos subjetivos y el contexto que hay
detrás de su desarrollo. Creemos que el Segment Routing influirá de forma significativa en la evolución de las
redes en los próximos años, de forma muy similar a como lo hizo MPLS en el pasado. El consenso existente en
el sector de las redes y la rápida aceptación de esta tecnología son quizá el mejor testimonio de ello.

El enrutamiento por segmentos evoluciona constantemente con la participación de una gran comunidad de
operadores de redes, ingenieros de redes y desarrolladores de plataformas de redes. Nos gustaría animar al
lector a mantenerse al día de todos estos avances tecnológicos a través de los distintos grupos de trabajo del
IETF implicados en este proceso, así como de otros foros y recursos en Internet. También nos gustaría señalar la
página web [Link] actualizada por una comunidad de desarrolladores de tecnologías de
RS.

En resumen, de este podrían extraerse los siguientes puntos clave:

La arquitectura de enrutamiento por segmentos busca el equilibrio adecuado entre la inteligencia

distribuida (plano de control en routers) y la optimización y programación centralizadas (a través
de controladores) para convertirse en la base de las redes definidas por software.

El enrutamiento por segmentos reduce el estado de la red a segmentos (por ejemplo, segmentos de
prefijo), mientras que la ruta a través de la red se transporta en el paquete en forma de lista de segmentos.
Esto permite escalar la red para manejar un gran número de flujos específicos de aplicaciones y sus rutas a
través de la red sin necesidad de manejar su estado individual, que ahora está en el .

La tecnología Segment Routing se desarrolla utilizando extensiones de los protocolos de red existentes
(por ejemplo, OSPF, ISIS, BGP, etc.) y no introduce ningún protocolo nuevo. De hecho, simplifica las
operaciones de red MPLS al eliminar protocolos como LDP y RSVP-TE en muchos diseños de red.

El enrutamiento por segmentos funciona tanto para IPv4 como para IPv6 en el plano de datos MPLS, así
como en el plano de datos IPv6 nativo (denominado SRv6).

El enrutamiento por segmentos aprovecha el plano de datos MPLS existente y se interconecta con los
protocolos de plano de control MPLS existentes, lo que permite el despliegue en redes IP/MPLS existentes
con un mínimo de
(si es que hay alguna) interrupción del servicio. Los servicios se pueden migrar sin problemas del transporte
existente a SR y la funcionalidad básica es principalmente una actualización de software para la mayoría de
los routers.

TI-LFA, habilitado por Segment Routing, proporciona rutas de backup automatizadas sobre la ruta de
posconvergencia en cualquier topología para permitir una protección inferior a 50 ms para todos los
servicios de la red. Es fácil de aprovisionar y también protege el tráfico IP y LDP.

El enrutamiento por segmentos aborda los problemas de enrutamiento IP del primer día, como los microbucle.

El enrutamiento por segmentos es aplicable a todo tipo de redes, desde el núcleo/acceso/agregación de

proveedores de servicios, centros de datos, peering de Internet y redes empresariales.

El enrutamiento por segmentos permite funciones de ingeniería de tráfico de extremo a extremo para
aplicaciones y servicios, incluso en redes multidominio de escala masiva.

Este libro es la primera parte de una serie. La siguiente parte de la serie detallará la solución de Ingeniería de
Tráfico, la interacción SDN/controlador con la infraestructura SR, SR en el host y SRv6.

También nos gustaría animar a los lectores a conectarse a través de nuestro blog [Link]
[Link], donde podrán enviar sus opiniones y comentarios, así como acceder a recursos adicionales
y actualizados relacionados con este libro, como ejemplos de configuración. Mientras Segment Routing
evoluciona, este blog sería nuestro intento de mantener vivo el contenido entre versiones y notificar a los
lectores de sus revisiones.

También puede ponerse en contacto con los autores del libro a través del correo electrónicosegment-routing-
book@[Link] para enviar erratas, comentarios o sugerencias.

También podría gustarte

Configuración y Análisis de BGPv4
Aún no hay calificaciones
Configuración y Análisis de BGPv4
17 páginas
Introducción al Protocolo BGP
Aún no hay calificaciones
Introducción al Protocolo BGP
27 páginas
Config BGP 00
Aún no hay calificaciones
Config BGP 00
19 páginas
Evolución y Estructura de IPv6 en Internet
Aún no hay calificaciones
Evolución y Estructura de IPv6 en Internet
30 páginas
Ejercicio de DNS y Enrutamiento BGP
Aún no hay calificaciones
Ejercicio de DNS y Enrutamiento BGP
6 páginas
Configuración de BGPv4 en GNS3
Aún no hay calificaciones
Configuración de BGPv4 en GNS3
13 páginas
Guía Completa sobre BGP y su Configuración
Aún no hay calificaciones
Guía Completa sobre BGP y su Configuración
116 páginas
Protocolo BGP: Enrutamiento en Internet
Aún no hay calificaciones
Protocolo BGP: Enrutamiento en Internet
12 páginas
Comparativa: ELAN vs VLAN
Aún no hay calificaciones
Comparativa: ELAN vs VLAN
26 páginas
Protocolo de Enrutamiento RIP y OSPF
Aún no hay calificaciones
Protocolo de Enrutamiento RIP y OSPF
46 páginas
Introducción a BGP: Atributos y Configuración
Aún no hay calificaciones
Introducción a BGP: Atributos y Configuración
2 páginas
Introducción al Protocolo BGP
Aún no hay calificaciones
Introducción al Protocolo BGP
4 páginas
Funcionamiento de AS-Override en BGP
Aún no hay calificaciones
Funcionamiento de AS-Override en BGP
6 páginas
Configuración de VPLS sobre MPLS
Aún no hay calificaciones
Configuración de VPLS sobre MPLS
38 páginas
Configuración y Atributos de BGP en Cisco
Aún no hay calificaciones
Configuración y Atributos de BGP en Cisco
93 páginas
Mensajes y Atributos del Protocolo BGP
Aún no hay calificaciones
Mensajes y Atributos del Protocolo BGP
29 páginas
Protocolo OSPF y BGP en Redes
Aún no hay calificaciones
Protocolo OSPF y BGP en Redes
121 páginas
07 Border Gateway Protocol (BGP)
Aún no hay calificaciones
07 Border Gateway Protocol (BGP)
270 páginas
Fundamentos de BGP y RPKI
Aún no hay calificaciones
Fundamentos de BGP y RPKI
10 páginas
Protocolo BGP en Redes de Comunicación
Aún no hay calificaciones
Protocolo BGP en Redes de Comunicación
8 páginas
Fundamentos del Protocolo BGP
Aún no hay calificaciones
Fundamentos del Protocolo BGP
20 páginas
VPNs MPLS: Práctica de Laboratorio 2023
Aún no hay calificaciones
VPNs MPLS: Práctica de Laboratorio 2023
34 páginas
Chuleta
Aún no hay calificaciones
Chuleta
2 páginas
Atributos BGP: Clasificación y Funciones
Aún no hay calificaciones
Atributos BGP: Clasificación y Funciones
7 páginas
Introducción al Protocolo BGP
Aún no hay calificaciones
Introducción al Protocolo BGP
694 páginas
Fundamentos y Configuración de BGP
Aún no hay calificaciones
Fundamentos y Configuración de BGP
8 páginas
Fundamentos y Ventajas de MPLS
Aún no hay calificaciones
Fundamentos y Ventajas de MPLS
72 páginas
Guía Completa sobre BGP y sus Funciones
Aún no hay calificaciones
Guía Completa sobre BGP y sus Funciones
13 páginas
Atributos Esenciales de BGP
Aún no hay calificaciones
Atributos Esenciales de BGP
12 páginas
Chuleta
Aún no hay calificaciones
Chuleta
2 páginas
Guía BGP para Routers Nokia SR
Aún no hay calificaciones
Guía BGP para Routers Nokia SR
37 páginas
Protocolo BGP y Selección de Rutas
Aún no hay calificaciones
Protocolo BGP y Selección de Rutas
21 páginas
Monitoreo de BGP con Protocolo BMP
Aún no hay calificaciones
Monitoreo de BGP con Protocolo BMP
13 páginas
2.4. BGP
Aún no hay calificaciones
2.4. BGP
20 páginas
Seguridad y BGP en RouterOS v7
Aún no hay calificaciones
Seguridad y BGP en RouterOS v7
49 páginas
BGP y Preferencia de Rutas en RouterOS
Aún no hay calificaciones
BGP y Preferencia de Rutas en RouterOS
57 páginas
Introducción a MPLS L2 VPN y VPLS
Aún no hay calificaciones
Introducción a MPLS L2 VPN y VPLS
70 páginas
BGP con Dos Interfaces en MikroTik
Aún no hay calificaciones
BGP con Dos Interfaces en MikroTik
3 páginas
Introducción a BGP-4: Peering y Configuración
Aún no hay calificaciones
Introducción a BGP-4: Peering y Configuración
14 páginas
12 Mpls Inter As
Aún no hay calificaciones
12 Mpls Inter As
36 páginas
RBA - Clase 5 BGP
Aún no hay calificaciones
RBA - Clase 5 BGP
12 páginas
Notas Clave sobre CCNP ROUTE y Protocolos
Aún no hay calificaciones
Notas Clave sobre CCNP ROUTE y Protocolos
7 páginas
Configuración de Redes MPLS-VPN
Aún no hay calificaciones
Configuración de Redes MPLS-VPN
21 páginas
08 Seguridad en BGP
Aún no hay calificaciones
08 Seguridad en BGP
50 páginas
Análisis de BGP en GNS3 y Wireshark
Aún no hay calificaciones
Análisis de BGP en GNS3 y Wireshark
7 páginas
Ruteo Estático: Conceptos y Configuración
Aún no hay calificaciones
Ruteo Estático: Conceptos y Configuración
8 páginas
Enrutamiento de Segmentos: Guía Completa
Aún no hay calificaciones
Enrutamiento de Segmentos: Guía Completa
428 páginas
Introducción a VPLS: Conectividad Segura
Aún no hay calificaciones
Introducción a VPLS: Conectividad Segura
5 páginas
Curso de BGP: Dual Homed y Multihomed
Aún no hay calificaciones
Curso de BGP: Dual Homed y Multihomed
51 páginas
Introducción a MPLS y su Configuración
Aún no hay calificaciones
Introducción a MPLS y su Configuración
11 páginas
Comparativa EIGRP y BGP en Redes
Aún no hay calificaciones
Comparativa EIGRP y BGP en Redes
24 páginas
Protocolo de Enrutamiento EIGRP y OSPF
Aún no hay calificaciones
Protocolo de Enrutamiento EIGRP y OSPF
41 páginas
Estados del Protocolo BGP
Aún no hay calificaciones
Estados del Protocolo BGP
6 páginas
Guía de Conmutación de Etiquetas MPLS
Aún no hay calificaciones
Guía de Conmutación de Etiquetas MPLS
5 páginas
Redistribución OSPF y BGP Configurada
Aún no hay calificaciones
Redistribución OSPF y BGP Configurada
11 páginas
Configuración de Bridge VLAN en MikroTik
Aún no hay calificaciones
Configuración de Bridge VLAN en MikroTik
21 páginas
Configuración de VPWS en ZXR10 M6000-S
Aún no hay calificaciones
Configuración de VPWS en ZXR10 M6000-S
15 páginas
Protocolo y Configuración de Redes IP
Aún no hay calificaciones
Protocolo y Configuración de Redes IP
363 páginas
Comparativa entre IPv4 e IPv6 en Redes
Aún no hay calificaciones
Comparativa entre IPv4 e IPv6 en Redes
7 páginas
Guía de Seguridad en Redes 5G
Aún no hay calificaciones
Guía de Seguridad en Redes 5G
246 páginas
Guía de Estudio para Álgebra Lineal
100% (1)
Guía de Estudio para Álgebra Lineal
49 páginas
65 PDF
Aún no hay calificaciones
65 PDF
62 páginas
Introducción Al Cálculo Vectorial
100% (12)
Introducción Al Cálculo Vectorial
342 páginas
Propiedades de Triángulos en Cálculo Diferencial
Aún no hay calificaciones
Propiedades de Triángulos en Cálculo Diferencial
6 páginas
Gestión Comercial Transporte por Carretera
Aún no hay calificaciones
Gestión Comercial Transporte por Carretera
48 páginas
Propiedades de Conexión WiFi y Ethernet
Aún no hay calificaciones
Propiedades de Conexión WiFi y Ethernet
4 páginas
Impacto del e-commerce chino en Colombia
Aún no hay calificaciones
Impacto del e-commerce chino en Colombia
53 páginas
Tecnología y crecimiento económico en Colombia
Aún no hay calificaciones
Tecnología y crecimiento económico en Colombia
3 páginas
Función y conceptos del protocolo IP
Aún no hay calificaciones
Función y conceptos del protocolo IP
3 páginas
Métodos de Investigación Cualitativa Online
Aún no hay calificaciones
Métodos de Investigación Cualitativa Online
1 página
Herramientas de red según su uso
0% (1)
Herramientas de red según su uso
2 páginas
Configuración de DHCP en NIC de Windows
Aún no hay calificaciones
Configuración de DHCP en NIC de Windows
5 páginas
Problemas de Internet en Fuerte Tiuna
Aún no hay calificaciones
Problemas de Internet en Fuerte Tiuna
16 páginas
Tránsito de La Capacidad y Calidad de Manual de Servicio
Aún no hay calificaciones
Tránsito de La Capacidad y Calidad de Manual de Servicio
39 páginas
Taller sobre la fórmula VLSM
Aún no hay calificaciones
Taller sobre la fórmula VLSM
16 páginas
Medios Electrónicos e Impresos: Comparativa
Aún no hay calificaciones
Medios Electrónicos e Impresos: Comparativa
5 páginas
Syllabus Mampostería Estructural Posgrado
Aún no hay calificaciones
Syllabus Mampostería Estructural Posgrado
1 página
Características de la noticia periodística
Aún no hay calificaciones
Características de la noticia periodística
6 páginas
Generar Código QR desde Google Drive
Aún no hay calificaciones
Generar Código QR desde Google Drive
6 páginas
Uso del comando netstat en Windows
Aún no hay calificaciones
Uso del comando netstat en Windows
18 páginas
Misterios Ocultos Internet Web Profunda
Aún no hay calificaciones
Misterios Ocultos Internet Web Profunda
3 páginas
Participación y Transcasting en Medios
Aún no hay calificaciones
Participación y Transcasting en Medios
519 páginas
Educación Inclusiva en Colombia y Perú
Aún no hay calificaciones
Educación Inclusiva en Colombia y Perú
84 páginas
Planes y Servicios de 360NET en Aragua
Aún no hay calificaciones
Planes y Servicios de 360NET en Aragua
10 páginas
Factura Electrónica Puerto Barranquilla
Aún no hay calificaciones
Factura Electrónica Puerto Barranquilla
3 páginas
Presupuesto para Rediseño Web de Servomaq
Aún no hay calificaciones
Presupuesto para Rediseño Web de Servomaq
11 páginas
Transmisor IP EX20 para Alarmas
Aún no hay calificaciones
Transmisor IP EX20 para Alarmas
1 página
Trabajo Colaborativo Virtual en Textos Argumentativos
Aún no hay calificaciones
Trabajo Colaborativo Virtual en Textos Argumentativos
154 páginas
Listas IPTV Actualizadas de Canales
Aún no hay calificaciones
Listas IPTV Actualizadas de Canales
9 páginas
Diferencias y funciones en HTML5
Aún no hay calificaciones
Diferencias y funciones en HTML5
3 páginas
Spam PDF
Aún no hay calificaciones
Spam PDF
59 páginas
Itil
Aún no hay calificaciones
Itil
1 página
Internet en la educación: ventajas y desafíos
Aún no hay calificaciones
Internet en la educación: ventajas y desafíos
2 páginas
Sociedad de la Información y Educación
Aún no hay calificaciones
Sociedad de la Información y Educación
4 páginas

Análisis de BGP y Segment Routing en Nodo21

Cargado por

Análisis de BGP y Segment Routing en Nodo21

Cargado por

43 Camino AS: 3

44 Segmento de ruta AS: 3

1 RP/0/0/CPU0:xrvr-21#show bgp ipv4 labeled-unicast [Link]/32

1 RP/0/0/CPU0:xrvr-21#show route [Link]/32 detail

Ejemplo 6-15: Entrada CEF del prefijo [Link]/32 en Nodo21

RP/0/0/CPU0:xrvr-21#show cef [Link]/32

RP/0/0/CPU0:xrvr-21#show mpls forwarding prefix [Link]/32

16003 Pop SR Pfx (idx 3) Gi0/0/0/0 [Link] 5311

Ejemplo 6-18: Mensaje de actualización BGP enviado por Nodo21

1 Border Gateway Protocol - Mensaje UPDATE

1 RP/0/0/CPU0:xrvr-31#show bgp ipv4 labeled-unicast [Link]/32

1 RP/0/0/CPU0:xrvr-31#show route [Link]/32 detail

RP/0/0/CPU0:xrvr-31#show cef [Link]/32

RP/0/0/CPU0:xrvr-31#show mpls forwarding prefix [Link]/32

16003 16003 SR Pfx (idx 3) Gi0/0/0/2 [Link] 208

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

RP/0/0/CPU0:xrvr-1#show mpls forwarding prefix [Link]/32

16003 16003 SR Pfx (idx 3) Gi0/0/0/0 [Link] 0

Ejemplo 6-25: IP traceroute desde Nodo1 a Nodo3

RP/0/0/CPU0:xrvr-1#traceroute [Link] source [Link]

Escriba la secuencia de escape para abortar.

1 [Link] [MPLS: Etiqueta 16003 Exp 0] 289 mseg 39 mseg 39 mseg

Label Switched Path to [Link]/32, timeout is 2 seconds

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

retorno 0 Escriba la secuencia de escape para abortar.

0 [Link] MRU 1500 [Etiquetas: implicit-null/16003 Exp: 0/0]

6.8.2 Configuración del servicio de superposición L3VPN

1 RP/0/0/CPU0:xrvr-1#show bgp vrf SVC [Link]/24

1 RP/0/0/CPU0:xrvr-1#show route vrf SVC [Link]/24

RP/0/0/CPU0:xrvr-1#show cef vrf SVC [Link]/24

RP/0/0/CPU0:xrvr-1#traceroute vrf SVC [Link]

Escriba la secuencia de escape para abortar.

1 [Link] [MPLS: Etiquetas 16003/90039 Exp 0] 879 mseg 49 mseg 79 mseg

6.8.3 Configuración de ECMP con E-BGP Multipath

Ejemplo 6-33: Configuración EBGP multipath

1 RP/0/0/CPU0:xrvr-1#show bgp ipv4 labeled-unicast [Link]/32

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

RP/0/0/CPU0:xrvr-1#show mpls forwarding prefix [Link]/32

16003 16003 SR Pfx (idx 3) Gi0/0/0/0 [Link] 0

Ejemplo 6-38: Traceroute MPLS multipath desde Nodo1 a Nodo3

RP/0/0/CPU0:xrvr-1#traceroute mpls multipath ipv4 [Link]/32 source [Link] fec-type generic

Iniciando LSP Path Discovery para [Link]/32

Códigos: '!' - éxito, 'Q' - solicitud no enviada, '.' - tiempo de espera,

retorno 0 Escriba la secuencia de escape para abortar.

Rutas (encontradas/rotas/no exploradas)

RP/0/0/CPU0:xrvr-1#show bgp vrf SVC [Link]/24

Ejemplo 6-40: Configuración de BGP multipath en nodos Tier-1

1 RP/0/0/CPU0:xrvr-1#show route vrf SVC [Link]/24

6.8.4 Configuración de segmentos de prefijo I-BGP

RECORDATORIO: Funcionalidad del reflector de rutas IBGP

par no cliente sólo se refleja en los pares cliente.

Figura 6-22: Representación desplegada de una ruta en la topología de la red

2. Mayor preferencia local

3. Longitud de la ruta de AS más corta

5. MED más bajo (Discriminador de salida múltiple)

6. Preferir externo a interno

7. Salida más cercana (menor distancia IGP)

8. Router-ID más bajo (Desempate)

9. Longitud más corta de la lista de clústeres (Desempate)

10. Dirección del vecino más bajo (Desempate)

La configuración completa IBGP-LU se analiza en base a la topología de la Figura 6-24.

Figura 6-24: Ejemplo de topología de red SR IBGP

1 política de ruta SID($SID)

Ejemplo 6-43: Configuración IBGP del Nodo21

Ejemplo 6-45: Entrada en la tabla BGP del prefijo [Link]/32 en Nodo1

1 RP/0/0/CPU0:xrvr-1#show bgp ipv4 labeled-unicast [Link]/32

RP/0/0/CPU0:xrvr-1#show route [Link]/32 Entrada de

enrutamiento para [Link]/32

Ejemplo 6-47: Entrada CEF del prefijo [Link]/32 en Nodo1

RP/0/0/CPU0:xrvr-1#show cef [Link]/32

1 RP/0/0/CPU0:xrvr-1#show bgp vrf SVC [Link]/24

RP/0/0/CPU0:xrvr-1#show route vrf SVC [Link]/24 Entrada

de enrutamiento para [Link]/24

SR BGP facilita la introducción de MPLS en el centro de datos y proporciona ventajas adicionales.

[draft-ietf-spring-oam-usecaseietf-spring-oam-usecase, septiembre de 2016,

[draft-ietf-spring-sr-oam-requirementietf-spring-sr-oam-requirement, julio de 2016,