Utilice MultiExit Discriminator para Influir en la Selección de la Mejor Trayectoria de BGP

Introducción

Este documento describe el comando bgp deterministic-med y cómo afecta a la selección de trayectoria basada en el discriminador de salida múltiple (MED).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Routing IP básico
• Border Gateway Protocol (BGP)

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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.

Convenciones

Para obtener más información sobre las convenciones de documentación de Cisco, consulte Convenciones de Consejos Técnicos de Cisco.

El atributo MED

MED es un atributo BGP opcional no transitivo que proporciona una pista a los vecinos externos sobre la ruta preferida a un sistema autónomo (AS) con múltiples puntos de entrada. MED también se conoce como la métrica externa de una ruta y se prefiere un valor MED inferior a un valor superior. De forma predeterminada, BGP compara los valores MED sólo entre las trayectorias recibidas del mismo AS vecino.

Nota: De forma predeterminada, BGP compara los valores MED sólo para las trayectorias recibidas del mismo AS vecino, a menos que se configure bgp always-compare-med. Consulte Cómo Difiere el Comando bgp deterministic-med del Comando bgp always-compare-med para obtener información adicional.

Topología de red 

Topología de red

Ejemplo:

En este escenario, el AS 65502 es un usuario del ISP que tiene el AS 65501. R4 está conectado a dos routers diferentes en el lado del ISP para fines de redundancia, y anuncia dos redes al ISP: 10.4.0.0/16 y 10.5.0.0/16. En esta sección se muestra parte de la configuración relevante.

!
hostname r4
!
ip cef
!
!
interface Loopback10
 ip address 10.4.0.1 255.255.0.0
!
interface Loopback11
 ip address 10.5.0.1 255.255.0.0
!
interface Serial0/0
 ip address 192.168.20.4 255.255.255.0
!
interface Serial1/0
 ip address 192.168.30.4 255.255.255.0
!
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 10.4.0.0 mask 255.255.0.0
 network 10.5.0.0 mask 255.255.0.0
 neighbor 192.168.20.2 remote-as 65501
 neighbor 192.168.30.3 remote-as 65501
 no auto-summary
!
ip classless
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 exec-timeout 0 0
 login
!
!
end

!
hostname r2
!
ip cef
!
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Ethernet0/0
 ip address 172.16.0.2 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 serial restart-delay 0
!
interface Serial2/0
 ip address 192.168.20.2 255.255.255.0
 serial restart-delay 0
!
router ospf 1
 log-adjacency-changes
 redistribute connected
 passive-interface Serial2/0
 network 10.2.2.2 0.0.0.0 area 0
 network 172.16.0.2 0.0.0.0 area 0
 network 192.168.1.2 0.0.0.0 area 0
 network 192.168.20.2 0.0.0.0 area 0
!
router bgp 65501
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.1 remote-as 65501
 neighbor 10.1.1.1 update-source Loopback0
 neighbor 10.3.3.3 remote-as 65501
 neighbor 10.3.3.3 update-source Loopback0
 neighbor 192.168.20.4 remote-as 65502
 no auto-summary
!
ip classless
!
!
line con 0
 exec-timeout 0 0
 transport preferred all
 transport output all
line aux 0
 transport preferred all
 transport output all
line vty 0 4
 exec-timeout 0 0
 login
 transport preferred all
 transport input all
 transport output all
!
end

Las configuraciones R1 y R3 relevantes utilizan el mismo diseño que R2. R1, R2 y R3 tienen alcance iBGP a través de interfaces de loopback y el IGP proporciona accesibilidad a los saltos siguientes de BGP. R3 tiene una sesión eBGP con R4 y sesiones iBGP con R1 y R2.

R1 tiene un iBGP que se compara con R2 y uno con R3. Observe lo que las tablas BGP R1, R2 y R3 muestran para las dos redes anunciadas por R4:

r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 7
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal

r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 6
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.3.3.3 
  65502
    192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best

r3#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.2.2.2 
  65502
    192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.30.4 from 192.168.30.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best

r3#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.2.2.2 
  65502
    192.168.30.4 from 192.168.30.4 (10.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal

r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  65502
    192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
  65502
    192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal

r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #2, table Default-IP-Routing-Table)
  Not advertised to any peer
  65502
    192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Tanto R2 como R3 eligen la mejor trayectoria como la ruta externa de R4 que se espera en base al algoritmo de selección de la mejor trayectoria BGP. Si desea obtener más información, consulte Algoritmo de Selección de la Mejor Trayectoria de BGP.

De manera similar, R1 elige R2 para acceder a las dos redes porque los atributos de mejor trayectoria de BGP anteriores empatan, y el ID de router BGP más bajo se utiliza como el desempate. R2 tiene el ID de router 10.2.2.2, y R3 tiene el ID de router 10.3.3.3. Debido a que el ID de router de R2s es 10.2.2.2 y el ID de router de R3s es 10.3.3.3, se elige R2. En esta configuración básica, todo el tráfico a las dos redes en AS 65502 pasa de R1 a R2 y luego a R4 de forma predeterminada. Ahora, suponga que R4 desea equilibrar la carga del tráfico que recibe del AS 65501. Para hacerlo sin ninguna modificación del ISP de R4, configure R4 para utilizar MED a fin de forzar el tráfico de una red por una trayectoria y el tráfico de la otra red por la otra trayectoria.

Nota: Tenga en cuenta que el ejemplo de configuración MED descrito proporciona una ingeniería de tráfico por prefijo, no un verdadero equilibrio de carga de igual costo.

Ésta es la configuración de R4 después de aplicar la configuración necesaria:

!
hostname r4
!
ip cef
!
!
!
interface Loopback10
 ip address 10.4.0.1 255.255.0.0
!
interface Loopback11
 ip address 10.5.0.1 255.255.0.0
!
interface Serial0/0
 ip address 192.168.20.4 255.255.255.0
!
interface Serial1/0
 ip address 192.168.30.4 255.255.255.0
!
router bgp 65502
 no synchronization
 bgp log-neighbor-changes
 network 10.4.0.0 mask 255.255.0.0
 network 10.5.0.0 mask 255.255.0.0
 neighbor 192.168.20.2 remote-as 65501
 neighbor 192.168.20.2 route-map setMED-R2 out
 neighbor 192.168.30.3 remote-as 65501
 neighbor 192.168.30.3 route-map setMED-R3 out
 no auto-summary
!
ip classless
no ip http server
!
!
access-list 1 permit 10.4.0.0 0.0.255.255
access-list 2 permit 10.5.0.0 0.0.255.255
!
route-map setMED-R3 permit 10
 match ip address 1
 set metric 200
!
route-map setMED-R3 permit 20
 match ip address 2
 set metric 100

!--- The route-map setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 
!--- network and a MED of 100 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R3. 

! 
route-map setMED-R2 
permit 10 match ip address 1 
set metric 100 
! 
route-map setMED-R2 permit 20 
match ip address 2 
set metric 200 

!--- The route-map setMED-R2 is applying a MED of 100 to the 10.4.0.0/16 
!--- network and a MED of 200 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R2.  
! 
! 
! 
line con 0 
exec-timeout 0 0 
line aux 0 
line vty 0 4 
exec-timeout 0 0 
login 
! 
! 
end

Nota: En este ejemplo, sólo se anuncian 10.4.0.0/16 y 10.5.0.0/16. Si se anuncian prefijos adicionales al mismo vecino, agréguelos a la lista de acceso o secuencia de route-map apropiada. Agregue una secuencia de permiso final si los prefijos no coincidentes deben anunciarse sin ser filtrados por el mapa de ruta saliente.

Nota: Una vez que se aplica el route map saliente, actualice las actualizaciones de BGP saliente ejecutando el comando clear ip bgp * soft out. En la producción, utilice un soft outbound específico del vecino clear cuando sea posible, por ejemplo, clear ip bgp 192.168.20.2 soft out y clear ip bgp 192.168.30.3 soft out.

Después de aplicar MED, R2 selecciona el trayecto/link R2 a R4 como el mejor para 10.4.0.0/16, y R3 selecciona el trayecto/link R3 a R4 como el mejor para 10.5.0.0/16. En el estado convergente mostrado, R1 recibe el mejor anuncio iBGP elegible para cada prefijo y utiliza R2 para 10.4.0.0/16 y R3 para 10.5.0.0/16:

r1#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 14
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
  Not advertised to any peer
  65502
    192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best

r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
  Not advertised to any peer
  65502
    192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best

Vea el siguiente ejemplo de la pantalla R2:

r2#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.1.1.1 10.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 100, localpref 100, valid, external, best


r2#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 11
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.20.4 
  65502
    192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.20.4 from 192.168.20.4 (10.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

R2 muestra una trayectoria para 10.4.0.0/16 porque R3 ya no anuncia su trayectoria R4 aprendida después de que R3 seleccione la trayectoria aprendida iBGP a través de R2 como la mejor. R3 retira la actualización (envía un retiro de ruta BGP, esta actualización contiene una métrica inalcanzable) para 10.4.0.0/16 una vez que advierte que R3 utiliza R2 para acceder a 10.4.0.0/16. Las reglas de anuncio iBGP estándar impiden que R3 anuncie la trayectoria aprendida de iBGP de vuelta a otro peer iBGP en esta topología:

r3#show ip bgp 10.4.0.0
BGP routing table entry for 10.4.0.0/16, version 20
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  192.168.30.4 
  65502
    192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.30.4 from 192.168.30.4 (10.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

Esto permite que R2 guarde algo de memoria ya que no tiene que almacenar esta información inútil. En el caso de que la sesión BGP entre R2 y R4 falle, R2 enviaría una actualización inalcanzable a R3 para 10.4.0.0/16. Esta actualización activaría a R3 para enviar una actualización con la ruta R3 para 10.4.0.0/16 vía R4 a R2. R2 puede comenzar a rutear vía R3.

El comando MED

Para habilitar la comparación determinista MED, configure el comando bgp deterministic-med en el modo de configuración del router BGP. Cuando está habilitado, bgp deterministic-med elimina la dependencia temporal de las decisiones de mejor trayectoria basadas en MED agrupando las trayectorias del mismo AS antes de la comparación. Esto garantiza una comparación MED precisa entre todas las rutas recibidas desde el mismo sistema autónomo (AS).

Si inhabilita bgp deterministic-med, las rutas de orden recibidas pueden afectar las decisiones de mejor trayectoria basadas en MED. Esto puede ocurrir cuando se recibe la misma ruta desde varios AS o subAS de confederación, con exactamente la misma longitud de trayectoria, pero con diferentes MED.

Examples

Por ejemplo, considere las siguientes rutas:

Un router BGP con MED desactivado

Ejemplo de pedido de llegada 1

El orden en que se recibieron las rutas BGP es (la entrada 1 es la entrada más antigua de la tabla BGP y la entrada 3 es la más reciente):

1. entry1
2. entry2
3. entry3

Inicialmente, sólo existe una ruta, por lo que la entrada 1 se convierte en la mejor ruta. Cuando la entrada 2 de AS65002 se compara con la entrada 1 de AS65001, MED se ignora porque las rutas provienen de diferentes AS vecinos; dado que todos los atributos restantes son iguales, el router mantiene la mejor trayectoria actual, entry1.

Cuando la entrada 3 de AS65001 con MED 20 se compara con la entrada 1 de AS65001 con MED 100, MED se evalúa porque ambas rutas provienen del mismo AS vecino. Dado que 20 es menor que 100, entry3 se convierte en la mejor ruta final.

Ejemplo de pedido de llegada 2

Ahora suponga que las mismas rutas llegan en un orden diferente:

1. entry2
2. entry3
3. entry1

Inicialmente, la entrada 2 se selecciona como la mejor ruta. Cuando la entrada 3 de AS65001 se compara con la entrada 2 de AS65002, MED no se evalúa porque las rutas provienen de AS vecinos diferentes; dado que todos los atributos restantes son iguales, el router mantiene la mejor trayectoria actual, entry2.

Cuando la entrada 1 de AS65001 se compara con la entrada 2 de AS65002, MED se ignora nuevamente porque las rutas provienen de diferentes AS vecinos. Como resultado, el router mantiene la entrada 2 como la mejor trayectoria final.

Con MED inhabilitado, el orden de llegada de la ruta influye en la secuencia de comparación. Observe que el router recibido es exactamente las mismas tres rutas, pero seleccionó diferentes mejores rutas porque las rutas llegaron en un orden diferente. Esta es la dependencia temporal que bgp deterministic-med está diseñado para eliminar.

Nota: Para obtener más información sobre los criterios de selección de trayectoria BGP, consulte Algoritmo de Selección de la Mejor Trayectoria BGP.

Un router BGP con MED habilitado

Con MED habilitado, el router primero agrupa las rutas por AS vecino antes de tomar cualquier decisión basada en MED. En este caso, las rutas del mismo AS se agrupan y se comparan las mejores entradas de cada grupo. En el ejemplo dado, hay dos AS, AS 65001 y AS 65002.

En el Grupo 1, la mejor trayectoria es la entrada 3 debido al MED inferior (MED se utiliza en esta decisión ya que las trayectorias son del mismo AS). En el Grupo 2, sólo hay una entrada (entrada 2). El mejor camino entonces se determina con una comparación de los ganadores de cada grupo, MED no se utiliza en esta comparación por defecto porque los ganadores de cada grupo son de diferentes AS.

En este momento, MED ya no se considera, porque las rutas restantes se originan en AS vecinos diferentes. El algoritmo de mejor trayectoria BGP continúa con los atributos subsiguientes (como eBGP frente a iBGP, métrica IGP para el salto siguiente, trayectoria más antigua, ID de router, etc., dependiendo de los atributos que difieran).

La ventaja clave es que este proceso es independiente de las rutas que se recibieron. Si el router aprende las rutas como:

• entry1 → entry2 → entry3
• entry2 → entry3 → entry1
• entry3 → entry1 → entry2

Como resultado, los pedidos de llegada producen el mismo resultado porque la decisión se basa en los atributos de ruta en lugar del orden en que se recibieron las actualizaciones.

Nota: Si bgp always-compare-med también se habilitó al comparar la entrada 3 (el ganador del Grupo 1) y la entrada 2 (el ganador del Grupo 2); la entrada 3 es la ganadora debido a la reducción de MED.

Nota: La habilitación del comando bgp deterministic-med garantiza la comparación de la variable MED al elegir rutas anunciadas por diferentes peers en el mismo AS. La habilitación del comando bgp always-compare-med garantiza la comparación de MED para las trayectorias de vecinos en diferentes AS.

Este ejemplo asume que todos los atributos BGP de prioridad más alta (como Weight, Local Preference, AS Path Length, Origin, etc.) son idénticos. El propósito es aislar el efecto de MED e ilustrar por qué la inhabilitación de bgp deterministic-med puede garantizar que la decisión de la mejor trayectoria dependa del orden de llegada de la ruta.

Cisco recomienda habilitar bgp always-compare-med en todas las nuevas implementaciones de red. Además, si se habilita bgp always-compare-med, las decisiones BGP MED son siempre determinísticas.

Para obtener más información sobre los comandos bgp deterministic-med y bgp always-compare-med, consulte Cómo se Diferencia el Comando bgp deterministic-med del Comando bgp always-compare-med.

Información Relacionada

• Ejemplo de Configuración de BGP con Dos Proveedores de Servicio Diferentes (Multihoming)
• Compatibilidad con IP/BGP
• Casos Prácticos de BGP
• Soporte técnico y descargas de Cisco