Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

El atributo MED

Ejemplo:

Comando bgp deterministic-med

Examples

Router BGP con bgp deterministic-med Disabled

Router BGP con bgp deterministic-med habilitado

Información Relacionada

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.

R4

!

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

R2

!

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:

R4

!

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 esta configuración tome 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 de 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

- Asistencia técnica y descargas de Cisco