Contenido

Introducción

Antecedentes

Diagrama de la red

Teoría

Implementación de IOS-XR

Configurar

Ejemplo de configuración

MPLS Traffic-Engineering en Router Raíz

Troubleshoot

Conclusión

Introducción

Este documento describe cómo puede influenciarse el ruteo cuando hay uno o más Reflectores de Ruta (RR) en la red para evitar una malla completa entre los routers iBGP.

Antecedentes

El paso 8 en el algoritmo de selección de la mejor trayectoria de BGP es preferir la trayectoria con la métrica de IGP más baja al salto siguiente de BGP. Por lo tanto, si todos los pasos anteriores al paso 8 son iguales, entonces el paso 8 puede ser el factor decisivo en cuál es el mejor trayecto en el RR. El costo IGP del RR al router iBGP de anuncio se determina luego por la ubicación del RR. De forma predeterminada, el RR sólo anuncia la mejor trayectoria a sus clientes. Según dónde se ubique el RR, el costo IGP para el router de anuncio puede ser menor o mayor. Si todos los costos IGP de las trayectorias son iguales, es probable que termine hasta el desempate del router de anuncio con el ID de router BGP más bajo.

Diagrama de la red

Los routers PE1, PE2 y PE3 anuncian el prefijo 172.16.2.0/24. Si todos los costos IGP de los links son iguales, entonces el RR verá la trayectoria de PE1, PE2 y PE3 con un costo IGP de 2. Al final, el RR elige el trayecto de PE1 como el mejor porque tiene el ID de router BGP más bajo. Este es el paso 11 en el algoritmo de selección de la mejor trayectoria de BGP. El resultado es que todos los routers PE, incluido PE4, elegirán PE1 como el router PE de salida para el prefijo 172.16.2.0/24. Desde el punto de vista de PE4, la trayectoria IGP más corta a cualquier router PE de salida es la trayectoria a PE3, con un costo IGP de 1. El costo IGP para cualquier otro router PE es 2. Para muchas redes, el hecho de transportar el tráfico a través de la red de tránsito de la manera más corta posible es importante. Esto se conoce como ruteo de papa caliente.

Hay otra razón posible para que RR haya elegido la mejor trayectoria de PE1. Si en la imagen, el costo del protocolo de gateway interior (IGP) del enlace P2-PE3 es 10 y todos los demás links todavía tienen un costo IGP de 1, entonces el RR no elegiría la ruta de PE3 como la mejor, incluso si PE3 tuviera el ID de router BGP más bajo.

Si el administrador de esta red desea tener un ruteo de papa caliente, entonces debe haber un mecanismo para que cuando haya RR en la red, el router de ingreso pueda aprender la trayectoria al router de salida más cercano en la red iBGP. La función BGP Add Path puede lograr esto. Sin embargo, con esa función, los RR y los routers de borde deben tener código más reciente que entienda la función. Con la función BGP Optimal Route Reflection, esto no es un requisito. Esta función permitirá que el RR envíe la mejor trayectoria al router de borde BGP de ingreso, en base a lo que el RR piensa que es la mejor trayectoria desde la perspectiva de ese router BGP de ingreso.

Otra solución que permitiría el ruteo de papa caliente cuando se implementan RR, es la ubicación en línea de RR. Estos RR no son RR dedicados, que sólo ejecutan BGP y el IGP. Estos RR en línea se encuentran en la trayectoria de reenvío y se colocan en la red para que tengan su propio conjunto de clientes RR, de modo que puedan reflejar la mejor trayectoria a cada cliente RR, que también es la mejor trayectoria desde la perspectiva de ese cliente RR.

Como se muestra en esta imagen, los RR se colocan en la red para que sean un pequeño conjunto de clientes RR cercanos a los que puedan servir. Debido al diseño de la red, los clientes RR reciben las mejores trayectorias que son las mejores trayectorias desde su punto de vista, desde los RR para que pueda haber ruteo de papa caliente en la red.

Teoría

La Reflexión de Ruta Óptima BGP se describe en el borrador IETF draft-ietf-idr-bgp-óptimo-route-revision.

La solución BGP Optimal Route Reflection permite al RR enviar una mejor trayectoria específica a un router de borde BGP específico. El RR puede elegir enviar una mejor trayectoria diferente a diferentes routers de borde BGP o conjunto de routers de borde. Los routers de borde deben ser clientes RR del RR. El objetivo es que cada router de borde BGP de ingreso puede tener un router BGP de salida o salida diferente para el mismo prefijo. Si el router de borde de ingreso siempre puede reenviar el tráfico al router AS-exit de cierre, esto permite el ruteo de papa caliente.

El problema es que el RR normalmente sólo envía la misma mejor trayectoria a cada router de borde BGP, lo que evita el ruteo de papas calientes. Para resolver esto, necesita que el RR sea capaz de calcular diferentes mejores trayectorias para el mismo prefijo dependiendo del router de borde BGP de ingreso. El mejor cálculo de trayectoria en el RR se realiza en base a la posición del router de borde BGP de ingreso. Por lo tanto, el RR realizará el cálculo del mejor trayecto BGP desde la perspectiva del router de borde de ingreso. El RR que sólo puede hacer esto es el RR que tiene la imagen completa de la topología de la red desde la perspectiva IGP donde se encuentran los routers de borde de ingreso y RR. Para cumplir este requisito, el IGP debe ser un protocolo de ruteo de estado de link.

En ese caso, el RR puede ejecutar un cálculo de trayecto más corto primero (SPF) con el router de borde de ingreso como la raíz del árbol y calcular el costo para cada otro router. De esta manera, se conocerá el costo del router de borde de ingreso a todos los demás routers de borde de salida. Este cálculo SPF especial con otro router como la raíz, se denomina SPF Inversa (rSPF). Esto sólo puede hacerse si el RR aprende todas las trayectorias BGP de todos los routers de borde BGP. Podría haber tantos rSPF ejecutados como clientes RR. Esto incrementará la carga de la CPU de alguna manera en el RR.

La solución permite que el mejor cálculo del trayecto se base en el algoritmo de selección del mejor trayecto BGP, que llevará al RR eligiendo el mejor trayecto desde la perspectiva del router de borde de ingreso al que el RR envía el trayecto. Esto significa que la mejor trayectoria se elegirá en función del costo IGP más corto para el siguiente salto BGP. La solución también permite seleccionar la mejor ruta en función de algunas políticas configuradas. Los routers de borde de ingreso podrían elegir sus mejores trayectorias en función de alguna política configurada, y no en el costo IGP más bajo. La solución permite al RR implementar la reflexión de ruta óptima en el costo IGP (ubicación en la red) o en alguna política configurada, o en ambas. Si se implementan ambas, la política se aplica primero y luego la reflexión de ruta óptima basada en IGP ocurrirá en las trayectorias restantes.

Implementación de IOS-XR

La implementación de IOS-XR permite hasta tres nodos raíz para el cálculo de rSPF. Si tiene muchos clientes RR en un grupo de actualización, entonces no hay necesidad de un cálculo rSPF por cliente RR si esos clientes RR tendrán la misma política y/o los mismos costos IGP para los diferentes routers de borde BGP de salida. Esto último significa generalmente que los clientes RR están ubicados de manera conjunta (probablemente en el mismo POP). Si ese es el caso, no hay necesidad de configurar cada cliente RR como raíz. La implementación de IOS-XR permite configurar tres, la raíz primaria, la secundaria y la raíz terciaria, por conjunto de clientes RR, con fines de redundancia. Para que la función BGP ORR se aplique a cualquier cliente RR, ese cliente RR se debe configurar para formar parte de un grupo de políticas ORR.

La función BGP ORR se habilita por familia de direcciones.

Se requiere un protocolo de estado de link. Puede ser OSPF o IS-IS.

IOS XR solamente implementa la función BGP ORR basándose en el costo IGP para el siguiente salto BGP, y no en base a alguna política configurada.

Los peers BGP con la misma política saliente se colocan en el mismo grupo de actualización. Este suele ser el caso de iBGP en el RR. Cuando la función BGP ORR está habilitada, los peers de diferentes grupos ORR estarán en diferentes grupos de actualización. Esto es lógico, porque las actualizaciones enviadas desde el RR a los clientes RR en diferentes grupos ORR BGP serán diferentes, porque la mejor trayectoria de BGP es diferente.

El resultado de los cálculos de rSPF se almacena en una base de datos.

ORRSPF es el nuevo componente en IOS-XR que se necesita para la función BGP ORR. ORRSPF se encarga de:

1. Recopilación de la información de estado de link y mantenimiento de la base de datos de estado de link

2. Ejecución de rSPF y mantenimiento de los SPT, por grupo de políticas

3. Descarga de los prefijos del SPT al RIB con las métricas

La base de datos obtiene su información de estado de link directamente desde el IGP de estado de link o desde BGP-LS.

Los cálculos de rSPF resultan en una topología que muestra la trayectoria más corta del cliente RR a cualquier otro router en el área/nivel.

Las rutas que cuelgan de cada router en la topología se almacenan en una tabla RIB especial para la política de grupo ORR y por AFI/SAFI. RSI crea esta tabla. La tabla se completa con las rutas calculadas por los rSPF con la raíz primaria como la raíz. Si la raíz primaria deja de estar disponible, entonces la raíz secundaria es la raíz y rellena las rutas en la tabla ORR RIB. Lo mismo se aplica a la raíz terciaria.

Configurar

La configuración mínima necesaria:

1. ORR debe estar habilitado para la familia de direcciones de BGP, para grupos específicos de vecinos BGP

2. Para cada grupo de vecinos BGP, se debe configurar al menos una raíz. Opcionalmente, se puede configurar una raíz secundaria y terciaria.

3. La redistribución de las rutas ORR del IGP al BGP debe estar habilitada.

Ejemplo de configuración

Como se muestra en la primera imagen, el RR es un router IOS-XR con la función BGP ORR.

Todos los demás routers ejecutan IOS. Estos routers no tienen la función BGP ORR.

PE1, PE2 y PE3 anuncian el prefijo 172.16.2.0/24 en AFI/SAFI 1/1 (unidifusión IPv4). El RR está igual de cerca de PE1 y PE2 que de PE3. El costo IGP de todos los links es 1. La mejor trayectoria para este prefijo es la con R1 como salto siguiente debido al ID de router BGP más bajo.

RP/0/0/CPU0:RR#show bgp ipv4 unicast 172.16.2.0/24 bestpath-compare

BGP routing table entry for 172.16.2.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 34          34

Last Modified: Mar  7 20:29:48.156 for 11:36:44

Paths: (3 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Local, (Received from a RR-client)

10.100.1.1 (metric 3) from 10.100.1.1 (10.100.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 34

best of local AS, Overall best

Path #2: Received by speaker 0

Not advertised to any peer

Local, (Received from a RR-client)

10.100.1.2 (metric 3) from 10.100.1.2 (10.100.1.2)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 6, version 33

Higher router ID than best path (path #1)

Path #3: Received by speaker 0

ORR bestpath for update-groups (with more than one peer):

0.1

Local, (Received from a RR-client)

10.100.1.3 (metric 5) from 10.100.1.3 (10.100.1.3)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 7, version 34

Higher IGP metric than best path (path #1)

PE4 recibirá la trayectoria con PE1 como salto siguiente. Por lo tanto, no hay ruteo de papa caliente para PE4.

Si desea tener un ruteo de papa caliente en PE4, entonces para los prefijos anunciados por PE1, PE2 y PE3 (por ejemplo el prefijo 172.16.2.0/24), PE1 debe tener PE3 como punto de salida. Esto significa que la trayectoria en PE4 debe ser la con PE3 como salto siguiente. Podemos hacer que el RR envíe la ruta con el siguiente salto PE3 a PE4 con esta configuración ORR.

router ospf 1

distribute bgp-ls

area 0

interface Loopback0

!

interface GigabitEthernet0/0/0/0

network point-to-point

!

!

!

router bgp 1

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group 10.100.1.4

!

address-family vpnv4 unicast

!

neighbor 10.100.1.1

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

neighbor 10.100.1.2

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

neighbor 10.100.1.3

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

neighbor 10.100.1.4

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group

route-reflector-client

!

!

neighbor 10.100.1.5

remote-as 1

update-source Loopback0

address-family ipv4 unicast

route-reflector-client

!

!

!

Si el IGP es IS-IS:

router isis 1

net 49.0001.0000.0000.0008.00

distribute bgp-ls

address-family ipv4 unicast

metric-style wide

!

interface Loopback0

address-family ipv4 unicast

!

!

interface GigabitEthernet0/0/0/0

address-family ipv4 unicast

!

!

!

Nota: El estado de link de la familia de direcciones no necesita ser configurado globalmente o bajo los vecinos BGP.

MPLS Traffic-Engineering en Router Raíz

El RR necesita encontrar la dirección raíz configurada en la base de datos IGP, para ejecutar el rSPF. En ISIS, el ID de router está presente en la base de datos de ISIS. Para OSPF, no hay ningún router-ID presente en los LSA OSPF. La solución es hacer que los routers raíz anuncien el ID de router TE de conmutación de etiquetas multiprotocolo (MPLS) que coincida con la dirección raíz configurada en el RR.

Para OSPF, los routers raíz necesitan configuración adicional para hacer que el BGP ORR funcione. Se necesita una configuración MPLS TE mínima en cualquier router raíz para anunciar este ID de router MPLS TE. El conjunto de comandos mínimo exacto depende del sistema operativo del router raíz. La configuración MPLS TE en el router raíz necesita tener habilitada la configuración mínima para MPLS TE de modo que OSPF anuncie el ID del router MPLS TE en un LSA de área opaca (tipo 10).

Una vez que el RR tiene un LSA de área opaca con el router-ID MPLS TE que coincide con la dirección del router raíz configurada, el rSPF puede ejecutarse y el BGP en el RR puede anunciar la ruta óptima.

La configuración mínima necesaria para OSPF en el router raíz si es un router IOS es:

!

interface GigabitEthernet0/2

ip address 10.1.34.4 255.255.255.0

ip ospf network point-to-point

mpls traffic-eng tunnels

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

router-id 10.200.1.155

network 10.0.0.0 0.255.255.255 area 0

!

Observe que:

- MPLS TE se habilita en el área OSPF específica

- el router-ID MPLS TE se configura coincidiendo con la dirección raíz configurada en el RR

- MPLS TE se configura en al menos una interfaz

- no es necesario tener RSVP-TE configurado

- no es necesario que MPLS TE se configure en ningún otro router del área

La configuración mínima necesaria para OSPF en el router raíz si es un router IOS-XR es:

!

router ospf 1

router-id 5.6.7.8

area 0

mpls traffic-eng

interface Loopback0

!

interface GigabitEthernet0/0/0/0

network point-to-point

!

!

mpls traffic-eng router-id 10.100.1.11

!

mpls traffic-eng

!

Si la configuración anterior está en vigor en el router raíz, entonces RR debe tener el router-ID MPLS TE en la base de datos OSPF.

RP/0/0/CPU0:RR#show ospf 1 database

OSPF Router with ID (10.100.1.99) (Process ID 1)

Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count

10.1.12.1       10.1.12.1       1297        0x8000002b 0x006145 3

10.100.1.2      10.100.1.2      646         0x80000025 0x00fb6f 7

10.100.1.3      10.100.1.3      1693        0x80000031 0x003ba9 5

10.100.1.99     10.100.1.99     623         0x8000001e 0x00ade1 3

10.200.1.155    10.200.1.155    28          0x80000002 0x009b2e 5

Type-10 Opaque Link Area Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Opaque ID

1.0.0.0         10.200.1.155    34          0x80000001 0x00a1ad        0

1.0.0.3         10.200.1.155    34          0x80000001 0x0057ff        3

RP/0/0/CPU0:RR#show ospf 1 database opaque-area adv-router 10.200.1.155

OSPF Router with ID (10.100.1.99) (Process ID 1)

Type-10 Opaque Link Area Link States (Area 0)

LS age: 184

Options: (No TOS-capability, DC)

LS Type: Opaque Area Link

Link State ID: 1.0.0.0

Opaque Type: 1

Opaque ID: 0

Advertising Router: 10.200.1.155

LS Seq Number: 80000001

Checksum: 0xa1ad

Length: 28

MPLS TE router ID : 10.100.1.4

Number of Links : 0

LS age: 184

Options: (No TOS-capability, DC)

LS Type: Opaque Area Link

Link State ID: 1.0.0.3

Opaque Type: 1

Opaque ID: 3

Advertising Router: 10.200.1.155

LS Seq Number: 80000001

Checksum: 0x57ff

Length: 132

Link connected to Point-to-Point network

Link ID : 10.100.1.3      (all bandwidths in bytes/sec)

Interface Address : 10.1.34.4

Neighbor Address : 10.1.34.3

Admin Metric : 1

Maximum bandwidth : 125000000

Maximum reservable bandwidth global: 0

Number of Priority : 8

Priority 0 :                    0  Priority 1 :                    0

Priority 2 :                    0  Priority 3 :                    0

Priority 4 :                    0  Priority 5 :                    0

Priority 6 :                    0  Priority 7 :                    0

Affinity Bit : 0

IGP Metric : 1

Number of Links : 1

Observe que el router-ID MPLS TE (10.100.1.4) y el router-ID OSPF son diferentes.

PE4 tiene PE3 como salto siguiente para el prefijo (con la métrica IGP correcta para el salto siguiente):

PE4#show bgp ipv4 unicast 172.16.2.0

BGP routing table entry for 172.16.2.0/24, version 37

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.3 (metric 2) from 10.100.1.8 (10.100.1.8)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.3, Cluster list: 10.100.1.8

rx pathid: 0, tx pathid: 0x0

PE5 todavía tiene PE1 como salto siguiente para el prefijo (con la métrica IGP correcta para el salto siguiente):

PE5#show bgp ipv4 unicast 172.16.2.0/24

BGP routing table entry for 172.16.2.0/24, version 13

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 1

Local

10.100.1.1 (metric 3) from 10.100.1.8 (10.100.1.8)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 10.100.1.1, Cluster list: 10.100.1.8

rx pathid: 0, tx pathid: 0x0

Troubleshoot

Verifique el prefijo en el RR:

RP/0/0/CPU0:RR#show bgp ipv4 unicast 172.16.2.0

BGP routing table entry for 172.16.2.0/24

Versions:

Process           bRIB/RIB  SendTblVer

Speaker                 19          19

Last Modified: Mar  7 16:41:20.156 for 03:07:40

Paths: (3 available, best #1)

Advertised to update-groups (with more than one peer):

0.3

Path #1: Received by speaker 0

Advertised to update-groups (with more than one peer):

0.3

Local, (Received from a RR-client)

10.100.1.1 (metric 3) from 10.100.1.1 (10.100.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best, group-best

Received Path ID 0, Local Path ID 1, version 14

Path #2: Received by speaker 0

Not advertised to any peer

Local, (Received from a RR-client)

10.100.1.2 (metric 3) from 10.100.1.2 (10.100.1.2)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 4, version 14

Path #3: Received by speaker 0

ORR bestpath for update-groups (with more than one peer):

0.1

Local, (Received from a RR-client)

10.100.1.3 (metric 5) from 10.100.1.3 (10.100.1.3)

Origin IGP, metric 0, localpref 100, valid, internal, add-path

Received Path ID 0, Local Path ID 5, version 19

Observe que add-path se agregó a las otras trayectorias no mejores, de modo que también se puedan anunciar, además de la mejor trayectoria. La función add path no se utiliza entre el RR y sus clientes: las trayectorias no se anuncian con un identificador de trayectoria.

Verifique que las rutas se anuncien (todavía) a los vecinos BGP específicos.

Para el PE4 vecino, el salto siguiente es PE3 para el prefijo 172.16.2.0/24:

RP/0/0/CPU0:RR#show bgp ipv4 unicast neighbors 10.100.1.4 advertised-routes

Network            Next Hop        From            AS Path

172.16.1.0/24      10.100.1.5      10.100.1.5      i

172.16.2.0/24      10.100.1.3      10.100.1.3      i

Processed 2 prefixes, 2 paths

Para el PE5 vecino, el salto siguiente es PE1 para el prefijo 172.16.2.0/24:

RP/0/0/CPU0:RR#show bgp ipv4 unicast neighbors 10.100.1.5 advertised-routes

Network            Next Hop        From            AS Path

172.16.1.0/24      10.100.1.8      10.100.1.5      i

172.16.2.0/24      10.100.1.1      10.100.1.1      i

El vecino 10.100.1.4 está en su propio grupo de actualización debido a la política ORR implementada:

RP/0/0/CPU0:RR#show bgp ipv4 unicast update-group

Update group for IPv4 Unicast, index 0.1:

Attributes:

Neighbor sessions are IPv4

Internal

Common admin

First neighbor AS: 1

Send communities

Send GSHUT community if originated

Send extended communities

Route Reflector Client

ORR root (configured): ipv4-orr-group; Index: 0

4-byte AS capable

Non-labeled address-family capable

Send AIGP

Send multicast attributes

Minimum advertisement interval: 0 secs

Update group desynchronized: 0

Sub-groups merged: 0

Number of refresh subgroups: 0

Messages formatted: 8, replicated: 8

All neighbors are assigned to sub-group(s)

Neighbors in sub-group: 0.1, Filter-Groups num:1

Neighbors in filter-group: 0.3(RT num: 0)

10.100.1.4

Update group for IPv4 Unicast, index 0.3:

Attributes:

Neighbor sessions are IPv4

Internal

Common admin

First neighbor AS: 1

Send communities

Send GSHUT community if originated

Send extended communities

Route Reflector Client

4-byte AS capable

Non-labeled address-family capable

Send AIGP

Send multicast attributes

Minimum advertisement interval: 0 secs

Update group desynchronized: 0

Sub-groups merged: 1

Number of refresh subgroups: 0

Messages formatted: 12, replicated: 42

All neighbors are assigned to sub-group(s)

Neighbors in sub-group: 0.3, Filter-Groups num:1

Neighbors in filter-group: 0.1(RT num: 0)

10.100.1.1                10.100.1.2                10.100.1.3                10.100.1.5

El comando show orrspf database muestra el grupo ORR y sus raíces,

RP/0/0/CPU0:RR#show orrspf database

ORR policy: ipv4-orr-group, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: NULL, tertiary: NULL

Actual Root: 10.100.1.4

Number of mapping entries: 1

El mismo comando con la palabra clave detail proporciona el costo de la raíz del rSPF entre el otro router/prefijo en el mismo área OSPF:

RP/0/0/CPU0:RR#show orrspf database detail

ORR policy: ipv4-orr-group, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: NULL, tertiary: NULL

Actual Root: 10.100.1.4

Prefix                                        Cost

10.100.1.6                                    2

10.100.1.1                                    3

10.100.1.2                                    3

10.100.1.3                                    2

10.100.1.4                                    0

10.100.1.5                                    3

10.100.1.7                                    3

10.100.1.8                                    4

Number of mapping entries: 9

El ID de tabla fue asignado por el RSI para el grupo ORR y para el AFI/SAFI:

RP/0/0/CPU0:RR#show rsi table-id 0xe0000012

TBL_NAME=ipv4-orr-group, AFI=IPv4, SAFI=Ucast TBL_ID=0xe0000012 in VRF=default/0x60000000 in VR=default/0x20000000

Refcnt=1

VRF Index=4 TCM Index=1

Flags=0x0 LST Flags=(0x0) NULL

RP/0/0/CPU0:RR#show rib tables

Codes: N - Prefix Limit Notified, F - Forward Referenced

D - Table Deleted, C - Table Reached Convergence

VRF/Table              SAFI  Table ID     PrfxLmt   PrfxCnt TblVersion  N F D C

default/default        uni   0xe0000000   5000000        22        128  N N N Y

**nVSatellite/default  uni   0xe0000010   5000000         2          4  N N N Y

default/ipv4-orr-grou  uni   0xe0000012   5000000         9         27  N N N Y

default/default        multi 0xe0100000   5000000         0          0  N N N Y

El costo de la raíz (R4/10.100.1.4) del rSPF para cada router es el mismo que el costo que se ve con show ip route ospf en PE4:

PE4#show ip route ospf

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP

a - application route

+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 20 subnets, 2 masks

O        10.100.1.1/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.2/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.3/32 [110/2] via 10.1.8.3, 4d06h, GigabitEthernet0/2

O        10.100.1.5/32 [110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.6/32 [110/2] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.7/32 [110/3] via 10.1.8.3, 4d06h, GigabitEthernet0/2

[110/3] via 10.1.7.6, 4d05h, GigabitEthernet0/1

O        10.100.1.8/32 [110/4] via 10.1.8.3, 4d05h, GigabitEthernet0/2

[110/4] via 10.1.7.6, 4d05h, GigabitEthernet0/1

El RIB para el grupo ORR BGP:

RP/0/0/CPU0:RR#show route afi-all safi-all topology ipv4-orr-group

IPv4 Unicast Topology ipv4-orr-group:

-------------------------------------

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, su - IS-IS summary null, * - candidate default

U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP

A - access/subscriber, a - Application route

M - mobile route, r - RPL, (!) - FRR Backup path

Gateway of last resort is not set

o    10.100.1.1/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.2/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.3/32 [255/2] via 0.0.0.0, 00:04:53, Unknown

o    10.100.1.4/32 [255/0] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.5/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.6/32 [255/2] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.7/32 [255/3] via 0.0.0.0, 14:14:52, Unknown

o    10.100.1.8/32 [255/4] via 0.0.0.0, 14:14:52, Unknown

RP/0/0/CPU0:RR#show rsi table name ipv4-orr-group

VR=default:

TBL_NAME=ipv4-orr-group, AFI=IPv4, SAFI=Ucast TBL_ID=0xe0000012 in VRF=default/0x60000000 in VR=default/0x20000000

Refcnt=1

VRF Index=4 TCM Index=1

Flags=0x0 LST Flags=(0x0) NULL

El comando show bgp neighbor muestra si el peer es una raíz ORR:

RP/0/0/CPU0:RR#show bgp neighbor 10.100.1.4

BGP neighbor is 10.100.1.4

Remote AS 1, local AS 1, internal link

Remote router ID 10.100.1.4

Cluster ID 10.100.1.8

BGP state = Established, up for 01:17:41

NSR State: None

Last read 00:00:52, Last read before reset 01:18:30

Hold time is 180, keepalive interval is 60 seconds

Configured hold time: 180, keepalive: 60, min acceptable hold time: 3

Last write 00:00:34, attempted 19, written 19

Second last write 00:01:34, attempted 19, written 19

Last write before reset 01:17:43, attempted 19, written 19

Second last write before reset 01:18:43, attempted 19, written 19

Last write pulse rcvd  Mar  8 10:20:13.779 last full not set pulse count 12091

Last write pulse rcvd before reset 01:17:42

Socket not armed for io, armed for read, armed for write

Last write thread event before reset 01:17:42, second last 01:17:42

Last KA expiry before reset 01:17:43, second last 01:18:43

Last KA error before reset 00:00:00, KA not sent 00:00:00

Last KA start before reset 01:17:43, second last 01:18:43

Precedence: internet

Non-stop routing is enabled

Multi-protocol capability received

Neighbor capabilities:

Route refresh: advertised (old + new) and received (old + new)

4-byte AS: advertised and received

Address family IPv4 Unicast: advertised and received

Received 6322 messages, 0 notifications, 0 in queue

Sent 5782 messages, 4 notifications, 0 in queue

Minimum time between advertisement runs is 0 secs

Inbound message logging enabled, 3 messages buffered

Outbound message logging enabled, 3 messages buffered

For Address Family: IPv4 Unicast

BGP neighbor version 41

Update group: 0.1 Filter-group: 0.1  No Refresh request being processed

Route-Reflector Client

ORR root (configured): ipv4-orr-group; Index: 0

Route refresh request: received 0, sent 0

0 accepted prefixes, 0 are bestpaths

Cumulative no. of prefixes denied: 0.

Prefix advertised 2, suppressed 0, withdrawn 0

Maximum prefixes allowed 1048576

Threshold for warning message 75%, restart interval 0 min

AIGP is enabled

An EoR was received during read-only mode

Last ack version 41, Last synced ack version 0

Outstanding version objects: current 0, max 2

Additional-paths operation: None

Send Multicast Attributes

Advertise VPNv4 routes enabled with  option

Advertise VPNv6 routes is enabled with Local with stitching-RT option

Connections established 6; dropped 5

Local host: 10.100.1.8, Local port: 25176, IF Handle: 0x00000000

Foreign host: 10.100.1.4, Foreign port: 179

Last reset 01:17:42, due to User clear requested (CEASE notification sent - administrative reset)

Time since last notification sent to neighbor: 01:17:42

Error Code: administrative reset

Notification data sent:

None

Como se muestra en esta imagen, varios conjuntos de clientes RR configurados

Hay un conjunto de clientes RR conectados a PE3 y otro conjunto conectado a P1. Cada cliente RR en cada conjunto se encuentra a la misma distancia que cualquier router de borde BGP de salida.

router bgp 1

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1 10.100.1.4 10.100.1.209 10.100.1.210

optimal-route-reflection ipv4-orr-group-2 10.100.1.5 10.100.1.106 10.100.1.107

!

…

neighbor 10.100.1.4

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1

route-reflector-client

!

!

neighbor 10.100.1.5

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.106

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.107

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.108

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-2

route-reflector-client

!

!

neighbor 10.100.1.209

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1

route-reflector-client

!

!

neighbor 10.100.1.210

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1   route-reflector-client

!

!

neighbor 10.100.1.211

remote-as 1

update-source Loopback0

address-family ipv4 unicast

optimal-route-reflection ipv4-orr-group-1

route-reflector-client

!

!

!

La base de datos orspf para ambos grupos:

RP/0/0/CPU0:RR#show orrspf database detail

ORR policy: ipv4-orr-group-1, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: 10.100.1.209, tertiary: 10.100.1.210

Actual Root: 10.100.1.4

Prefix                                        Cost

10.100.1.1                                    3

10.100.1.2                                    3

10.100.1.3                                    2

10.100.1.4                                    0

10.100.1.5                                    3

10.100.1.6                                    2

10.100.1.7                                    3

10.100.1.8                                    4

10.100.1.106                                  3

10.100.1.107                                  3

10.100.1.108                                  3

10.100.1.209                                  3

10.100.1.210                                  3

10.100.1.211                                  3

ORR policy: ipv4-orr-group-2, IPv4, RIB tableid: 0xe0000013

Configured root: primary: 10.100.1.5, secondary: 10.100.1.106, tertiary: 10.100.1.107

Actual Root: 10.100.1.5

Prefix                                        Cost

10.100.1.1                                    3

10.100.1.2                                    3

10.100.1.3                                    4

10.100.1.4                                    3

10.100.1.5                                    0

10.100.1.6                                    2

10.100.1.7                                    3

10.100.1.8                                    4

10.100.1.106                                  3

10.100.1.107                                  3

10.100.1.108                                  3

10.100.1.209                                  5

10.100.1.210                                  5

10.100.1.211                                  5

Number of mapping entries: 30

Si para un grupo la raíz primaria está inactiva o inalcanzable, entonces la raíz secundaria será la raíz real utilizada. En este ejemplo, la raíz primaria del grupo ipv4-o-group-1 es inalcanzable. La raíz secundaria se convirtió en la raíz real:

RP/0/0/CPU0:RR#show orrspf database ipv4-orr-group-1

ORR policy: ipv4-orr-group-1, IPv4, RIB tableid: 0xe0000012

Configured root: primary: 10.100.1.4, secondary: 10.100.1.209, tertiary: 10.100.1.210

Actual Root: 10.100.1.209

Prefix                                        Cost

10.100.1.1                                    4

10.100.1.2                                    5

10.100.1.3                                    2

10.100.1.5                                    5

10.100.1.6                                    4

10.100.1.7                                    3

10.100.1.8                                    4

10.100.1.106                                  5

10.100.1.107                                  5

10.100.1.108                                  5

10.100.1.209                                  0

10.100.1.210                                  3

10.100.1.211                                  3

Number of mapping entries: 14

Conclusión

La función BGP Optimal Route Reflection (ORR) es una función que permite el ruteo de papa caliente en una red iBGP cuando hay reflectores de ruta presentes, sin la necesidad de un software de sistema operativo más nuevo en los routers de borde. El prerrequisito es que el IGP es un protocolo de ruteo de estado de link.