Utilice el Discriminador de Salida Múltiple para Seleccionar la Mejor Trayectoria para el Router BGP

Introducción

Este documento describe la bgp deterministic-med y explica cómo afecta a la selección de la ruta en función del discriminador de salida múltiple (MED).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

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 del documento, consulte Convenciones de Consejos Técnicos de Cisco.

El atributo MED

MED es un atributo opcional no transitivo. MED es una sugerencia para los vecinos externos sobre la ruta preferida a un sistema autónomo (AS) que tiene múltiples puntos de entrada. El MED también se conoce como la métrica externa de una ruta. Se prefiere un valor MED inferior a un valor superior.

Esta sección describe un ejemplo de cómo utilizar MED para influir en la decisión de ruteo tomada por un AS vecino.

Topología de red 

Topología de red

Ejemplo:

En este escenario, AS 65502 es un usuario del ISP que tiene 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.

!
version 12.3
!
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

!
version 12.3
!
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 de R1 y R3 son similares a R2. R3 tiene un eBGP que hace peers con R4 y un iBGP que hace peers con R1.

R1 tiene un iBGP que se une a R2 y uno a 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 como mejor trayectoria la ruta externa desde R4 que se espera en base al algoritmo de selección de 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 2 redes, lo que está de acuerdo con la regla de mejor trayectoria BGP: seleccione la trayectoria con el ID de router más bajo. Debido a que el ID del router R2 es 10.2.2.2 y el ID del router R3 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 quiere balancear la carga del tráfico que recibe de AS 65501. Para hacerlo sin ninguna modificación del ISP 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.

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

!
version 12.3
!
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 MED-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 MED-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: Debe borrar la sesión BGP con el clear ip bgp * soft out , por ejemplo, para que estas configuraciones tomen medidas.

R1 ahora ve la ruta sobre R2 como la mejor trayectoria para la red 10.4.0.0/16 porque la actualización recibida desde R2 tiene un MED de 100 frente a un MED de 200, que es lo que anuncia R3. De manera similar, R1 utiliza R3 y el link R3 - R4 para acceder a 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#sh 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

Observe 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

La razón por la que R2 sólo muestra una trayectoria para 10.4.0.0/16 es porque R3 retira (envía una actualización con una métrica inalcanzable) la actualización para 10.4.0.0/16 una vez que advierte que R3 utiliza R2 para acceder a 10.4.0.0/16 (después de ejecutar BGP bestpath en todas las trayectorias disponibles):

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 haría que R3 enviara una actualización con la ruta R3 para 10.4.0.0/16 vía R4 a R2. R2 podría comenzar a rutear vía R3.

Comando bgp deterministic-med

Si activa el  bgp deterministic-med    , elimina cualquier dependencia temporal de las decisiones de mejor trayectoria basadas en MED. Garantiza que se realice una comparación MED precisa entre todas las rutas recibidas desde el mismo sistema autónomo (AS).

Si desactiva bgp deterministic-med , el orden en que se reciben las rutas puede 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:

entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10
entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5
entry3: ASPATH 1, MED 200, external

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

Router BGP con bgp deterministic-med Disabled

Un router BGP con bgp deterministic-med disabled elige entry2 sobre entry1, debido a una métrica IGP más baja para alcanzar el NEXT_HOP (MED no se utilizó en esta decisión porque entry1 y entry2 son de dos AS diferentes). Entonces prefiere entry3 sobre entry2 porque es externo. Sin embargo, entry3 tiene un MED mayor que entry1. 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 .

Router BGP con bgp deterministic-med habilitado

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 1 y AS 2.

Group 1:  entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10
          entry3: ASPATH 1, MED 200, external
Group 2:  entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

En el Grupo 1, la mejor trayectoria es la entrada 1 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. Cuando habilite bgp always-compare-med   cambia este comportamiento predeterminado). Ahora, cuando se compara la entrada 1 (la ganadora del Grupo 1) y la entrada 2 (la ganadora del Grupo 2), la entrada 2 puede ser la ganadora ya que tiene la mejor métrica IGP para el salto siguiente.

Si bgp always-compare-med   también se habilitó cuando se compara la entrada 1 (el ganador del Grupo 1) y la entrada 2 (el ganador del Grupo 2), la entrada 1 puede ser el ganador debido a la MED inferior.

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

Para obtener más información sobre la bgp deterministic-med y el 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