Este documento describe la importancia del atributo BGP (Border Gateway Protocol) Weight en los escenarios de failover de red.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información de este documento se basa en un router Cisco con Cisco IOS® versión 15.6(2).
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
BGP se utiliza habitualmente para anunciar los prefijos de red a la red de área extensa (WAN) una vez recibida a través de un protocolo de gateway interior (IGP) desde la red de área local (LAN) y viceversa. Sin la configuración correcta, BGP puede fallar al restaurar la trayectoria de ruteo original sobre la WAN después de que la red se recupere de una falla de link.
Los routers implementados en escenarios de conmutación por fallas pueden tener rutas bloqueadas, lo que puede causar una redirección del tráfico a través de la trayectoria de respaldo luego de una falla y un evento de red de recuperación. Esto puede suceder debido a la naturaleza del atributo de trayectoria BGP Weight.
Una vez que se produce un fallo de red (normalmente con el enlace WAN), la red puede converger y utilizar la ruta de copia de seguridad disponible recibida a través del IGP.
Sin embargo, al recuperar la ruta principal, el router puede seguir utilizando la ruta de copia de seguridad y no restaurar la ruta original a través del enlace WAN. Se pueden observar consecuencias como rutas de ruteo asimétricas y subóptimas.
En escenarios de redundancia con dos routers WAN, estos pueden ejecutar BGP para intercambiar prefijos de red con la WAN. Se puede utilizar un protocolo de routing de gateway interior mejorado (EIGRP) similar a IGP para intercambiar prefijos de red con dispositivos de red LAN. En la topología descrita aquí, las rutas BGP se redistribuyen en EIGRP y una ruta EIGRP se redistribuye en BGP en el router WAN para lograr la conectividad de red completa. En estos escenarios, se necesita el filtrado o etiquetado de rutas apropiado para evitar que las rutas se retroalimenten entre los protocolos
El diseño de alto nivel de esto se puede ver en la siguiente topología:

El siguiente escenario describe el comportamiento del atributo BGP Weight en los casos de failover.
1. La ruta se recibe vía BGP
Como se muestra en la imagen, el router llamado WAN RTR recibe la red 192.168.1.0/24 a través de BGP. Con una distancia administrativa (AD) de 20, la ruta se instala en la tabla de routing.

Tabla BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 0 2 i
|
Esta tabla muestra la ruta instalada por BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip route <snip> B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42 |
2. La ruta se recibe vía EIGRP
La sesión BGP deja de estar disponible debido a una falla de link. Por convergencia de red, la misma ruta 192.168.1.0/24 se recibe ahora a través de EIGRP.

El comando redistribute eigrp origina rutas EIGRP elegibles en BGP. Como resultado, la ruta EIGRP aparece en la tabla BGP local.
Configuración de BGP:
| WAN_RTR |
|---|
WAN_RTR#show running-config | begin router bgp <snip> |
Tabla BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip bgp <snip> |
Esta tabla muestra la ruta instalada por EIGRP:
| WAN_RTR |
|---|
WAN_RTR#show ip route <snip> |
3. Ruta recibida vía BGP (otra vez)
Con la ruta EIGRP ahora redistribuida en BGP, y después de que la ruta original se reciba a través de BGP una vez más; ahora hay 2 entradas para la red 192.168.1.0/24 en la tabla BGP.

Tabla BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.1.2.2 0 0 2 i
*> 10.1.3.3 156160 32768 ?
|
En la tabla BGP:
Desde el punto de vista de la selección de la mejor trayectoria BGP:
Tabla de ruteo:
| WAN_RTR |
|---|
WAN_RTR#show ip route <snip> D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1 |
El valor predeterminado del peso BGP se puede modificar por par BGP con el uso del comando weight o route-map. Los siguientes comandos establecen el atributo de trayectoria Weight en 40000 para todas las rutas recibidas del peer BGP.
Ejemplo 1
| Uso del comando Weight |
|---|
router bgp 1 neighbor 10.1.2.2 weight 40000 |
Ejemplo 2
| Uso del comando Route-Map para establecer el atributo de trayecto de pesaje |
|---|
route-map FROM-WAN permit 10 set weight 40000 ! router bgp 1 neighbor 10.1.2.2 route-map FROM-WAN in ! clear ip bgp * soft in |
Ejemplo 3
| Uso del comando Route-Map para establecer el atributo de trayecto de pesaje para ciertas rutas |
|---|
ip prefix-list NETWORKS permit 192.168.1.0/24 ! route-map FROM-WAN permit 10 match ip address prefix NETWORKS set weight 40000 route-map FROM-WAN permit 100 ! router bgp 1 neighbor 10.1.2.2 route-map FROM-WAN in ! clear ip bgp * soft in |
Nota: La secuencia de permiso final en el mapa de ruta FROM-WAN acepta otras rutas del par sin asignarles el peso 40000.
Nota: El comodín en clear ip bgp * soft in actualiza las rutas entrantes de todos los peers BGP. Para actualizar solamente el peer utilizado en estos ejemplos, ejecute el comando clear ip bgp <ip-address> soft in.
Con el valor del atributo de trayectoria Weight aumentado, las rutas originales recibidas a través de BGP tienen prioridad como se ve en el siguiente caso:
Paso 1. La ruta se recibe a través de BGP
La siguiente tabla de BGP muestra las rutas recibidas vía BGP que ahora tienen un valor de Peso de 40000 en lugar de cero.
Tabla BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip bgp <snip> |
Tabla de ruteo:
| WAN_RTR |
|---|
WAN_RTR#show ip route <snip> B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53 |
Paso 2. La ruta se recibe a través de EIGRP
Las rutas originadas localmente todavía tienen un valor de 32768 en la Tabla BGP.
Tabla BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.3.3 156160 32768 ? |
Tabla de ruteo:
| WAN_RTR |
|---|
WAN_RTR#show ip route <snip> D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1 |
Paso 3. Ruta recibida vía BGP (otra vez)
Con un peso de 40000, la ruta recibida a través de BGP se selecciona sobre la ruta originada localmente. Después de que la ruta WAN reemplace la ruta EIGRP en la tabla de ruteo, la red converge correctamente de nuevo a su estado original.
Tabla BGP:
| WAN_RTR |
|---|
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 40000 2 i
|
Tabla de ruteo:
| WAN_RTR |
|---|
WAN_RTR#show ip route <snip> B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25 |
Paso 1. Estado original de la red

El switch de capa 3 de CORE recibe la ruta 192.168.1.0/24 a través de EIGRP desde WAN RTR A y WAN RTR B. Se elige la ruta a través de WAN RTR A.
El siguiente resultado muestra cómo el switch CORE mantiene una adyacencia EIGRP con los routers WAN y se elige WAN RTR A para alcanzar la red 192.168.1.0/24.
| NÚCLEO |
|---|
CORE#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.2.2 (WAN_RTR_A) Fa0/0 10 00:05:15 79 1066 0 10
1 10.1.3.3 (WAN_RTR_B) Fa0/1 12 00:06:22 76 456 0 5
CORE#show ip route
<snip>
D EX 192.168.1.0/24 [170/28416] via 10.1.2.2, 00:00:32, FastEthernet0/0
CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.2.2 (28416/2816), FastEthernet0/0
via 10.1.3.3 (281856/2816), FastEthernet0/1 |
Paso 2. Fallo del enlace WAN principal

Si se produce un fallo de enlace, el switch CORE instala la ruta a través de la segunda mejor ruta EIGRP, que es WAN RTR B.
| NÚCLEO |
|---|
CORE#show ip route
<snip>
D EX 192.168.1.0/24 [170/281856] via 10.1.3.3, 00:00:05, FastEthernet0/1
CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.3.3 (281856/2816), FastEthernet0/1 |
Paso 3. Restauración del enlace WAN principal

Se ha restaurado el enlace WAN principal. Sin embargo, el switch CORE todavía rutea sobre la trayectoria de respaldo como se ve en el siguiente resultado:
| NÚCLEO |
|---|
CORE#show ip route
<snip>
D EX 192.168.1.0/24 [170/281856] via 10.1.3.3, 00:06:09, FastEthernet0/1
CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.3.3 (281856/2816), FastEthernet0/1 |
La razón de este comportamiento se debe al atributo BGP Weight, como se ha explicado.
En el estado actual, WAN RTR A instala la ruta EIGRP en la tabla de routing. En la tabla BGP, la ruta redistribuida desde EIGRP tiene un peso mayor que la ruta recibida a través del link WAN restaurado y sigue siendo la mejor trayectoria.
| WAN_RTR_A |
|---|
WAN_RTR_A#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.2.4.4 0 0 4 i
*> 10.1.2.1 284416 32768 ?
WAN_RTR_A#show ip bgp summary
BGP router identifier 10.20.20.20, local AS number 2
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.2.4.4 4 4 12 12 16 0 0 00:03:54 (UP) 4
WAN_RTR_A#show ip route
<snip>
D EX 192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0
|
Este comportamiento puede ocurrir cuando un router WAN redistribuye una ruta de respaldo IGP en BGP y la ruta que se originó localmente tiene un peso mayor que la ruta aprendida de WAN restaurada. Las topologías de red y los síntomas iniciales pueden diferir de este ejemplo. Verifique la configuración de redistribución, los pesos de BGP y las rutas seleccionadas antes de atribuir el ruteo de trayectoria de respaldo persistente a esta condición.
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
5.0 |
07-Oct-2026
|
Actualización de ortografía, gramática, espaciado, líneas horizontales insertadas para separar secciones para facilitar su lectura. |
4.0 |
16-Apr-2025
|
Recertificación |
3.0 |
23-Jan-2024
|
Formato actualizado. |
2.0 |
09-Dec-2022
|
PII eliminado.
Texto alternativo agregado.
Actualizado para el título, traducción automática, requisitos de estilo, gerundios y formato. |
1.0 |
06-Jun-2018
|
Versión inicial |