IP : Protocolo de puerta de enlace fronteriza (BGP)

Cómo los Routers BGP Utilizan el Discriminador de Salida Múltiple para la Selección de la Mejor Trayectoria

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento demuestra el uso del comando bgp deterministic-med y explica cómo puede efectuar la selección del trayecto basada en el discriminador de salidas múltiples (MED).

prerrequisitos

Requisitos

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 se presenta en este documento se originó a partir de dispositivos dentro de 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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Convenciones

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

El atributo MED

El MED es un atributo nontransitive opcional. El MED es una indirecta a los vecinos externos sobre el trayecto preferido en un sistema que tiene puntas de la entrada múltiple. El MED también se conoce como el externo métrico de una ruta. Un valor de MED más bajo se prefiere sobre un valor más alto.

Esta sección describe un ejemplo de cómo utilizar el MED para influenciar la decisión de ruteo tomada por un vecino COMO.

Topología:

/image/gif/paws/13759/37_02.gif

Ejemplo:

En este escenario, COMO 65502 es un cliente del ISP que tiene COMO 65501. El R4 está conectado con dos diverso Routers en el lado ISP para los propósitos de la redundancia y hace publicidad de dos redes al ISP — 10.4.0.0/16 y 10.5.0.0/16. Algo de la configuración pertinente se muestra en esta sección.

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 2.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 2.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 1.1.1.1 remote-as 65501
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 65501
 neighbor 3.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 del r1 y del R3 son similares al r2. El R3 tiene un eBGP que mira con el R4 y un iBGP que mira con el r1.

El r1 tiene un iBGP que mira al r2 y a uno al R3. Miremos qué el r1, el r2, y las tablas BGP R3 visualizan para las dos redes des divulgación por el 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:
  1.1.1.1 3.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.30.4 (metric 74) from 3.3.3.3 (3.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:
  1.1.1.1 3.3.3.3 
  65502
    192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 from 192.168.20.4 (4.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:
  1.1.1.1 2.2.2.2 
  65502
    192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.30.4 from 192.168.30.4 (4.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:
  1.1.1.1 2.2.2.2 
  65502
    192.168.30.4 from 192.168.30.4 (4.4.4.4)
      Origin IGP, metric 0, localpref 100, valid, external, best
  65502
    192.168.20.4 (metric 74) from 2.2.2.2 (2.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 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
  65502
    192.168.30.4 (metric 128) from 3.3.3.3 (3.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 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  65502
    192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Como podemos ver, el r2 y el R3 escogen mientras que mejor trayecto la ruta externo del R4 que se espera que acuerda bgp bestpath el algoritmo de selección. Si desea obtener más información, consulte Algoritmo de Selección de la Mejor Trayectoria de BGP.

Semejantemente, r2 de los choses del r1 para acceder las 2 redes, que está de acuerdo con la regla del mejor trayecto BGP — seleccione la trayectoria con el Router ID más bajo, en igualdad de circunstancias. Porque el Router ID del r2 es 2.2.2.2 y el Router ID R3 es 3.3.3.3, se elige el r2. En esta configuración básica todo el tráfico a las dos redes adentro COMO 65502 pasos del r1 con el r2 y entonces al R4 por abandono. Ahora suponga que el R4 quiere cargar la balanza el tráfico que recibe COMO de 65501. Para hacer tan sin pedir el R4 ISP para hacer cualquier modificación, usted puede configurar el R4 para utilizar el MED para forzar el tráfico para una red abajo de una trayectoria, y el tráfico para la otra red abajo de la otra trayectoria.

Esto es lo que la configuración del R4 después de que apliquemos 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: Usted necesita borrar a la sesión de BGP con el comando clear ip bgp * soft out, por ejemplo, de hacer que éstos la configuración toman medidas.

El r1 ahora ve la ruta sobre el r2 como el mejor trayecto para la red 10.4.0.0/16 porque la actualización recibida del r2 tiene un MED de 100 contra un MED de 200, que es de lo que hace publicidad el R3. Semejantemente, las aplicaciones R3 del r1 y el R3- R4 conectan para acceder 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 2.2.2.2 (2.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 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best

Miremos la visualización del 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:
  1.1.1.1 3.3.3.3 
  65502
    192.168.20.4 from 192.168.20.4 (4.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 3.3.3.3 (3.3.3.3)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.20.4 from 192.168.20.4 (4.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

La razón por la que el r2 muestra solamente una trayectoria para 10.4.0.0/16 es porque el R3 se retira (envía una actualización con métrico inalcanzable) la actualización para 10.4.0.0/16 que nota una vez que el R3 utiliza el r2 para acceder 10.4.0.0/16 (después de ejecutarse bgp bestpath en todos los trayectos 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 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 100, localpref 100, valid, internal, best
  65502
    192.168.30.4 from 192.168.30.4 (4.4.4.4)
      Origin IGP, metric 200, localpref 100, valid, external

Esto permite que el r2 salve una cierta memoria puesto que no tiene que salvar esta información inservible. En caso que la sesión de BGP entre el r2 y el R4 fallara, el r2 enviaría una actualización inalcanzable al R3 para 10.4.0.0/16. Esta actualización accionaría el R3 para enviar una actualización con la ruta R3 para 10.4.0.0/16 vía el R4 al r2. El r2 podía comenzar a rutear vía el R3.

Comando bgp deterministic-med

Habilitar el comando bgp deterministic-med quita cualquier dependencia temporal de las decisiones MED-basadas del mejor trayecto. Se asegura de que una comparación MED exacta esté hecha a través de todas las rutas recibidas del mismo sistema autónomo (COMO).

Si usted inhabilita el deterministic-med BGP, la orden en la cual se reciben las rutas puede afectar las decisiones MED-basadas del mejor trayecto. Esto puede ocurrir cuando la misma ruta se recibe del AS múltiple o de la confederación sub-AS, con exactamente la misma longitud del trayecto, pero diversos MED.

Ejemplos

Por ejemplo, considere las rutas siguientes:

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

La orden en la cual las rutas BGP fueron recibidas es entry3, entry2, y entry1 (el entry3 es la más vieja entrada de la tabla BGP y el entry1 es el más nuevo).

Un router BGP con el deterministic-med BGP inhabilitado

Un router BGP con los minusválidos del deterministic-med BGP elige el entry2 sobre el entry1, debido a un IGP más bajo métrico para alcanzar el NEXT_HOP (el MED no fue utilizado en esta decisión porque el entry1 y el entry2 son a partir de dos diversos AS). Entonces prefiere el entry3 sobre el entry2 porque es externa. Sin embargo, el entry3 tiene un MED más alto que el entry1. Para más información sobre el criterio de selección de trayecto BGP, refiera al algoritmo de selección del mejor trayecto BGP.

Un router BGP con el deterministic-med BGP habilitado

En este caso, las rutas lo mismo QUE se agrupan junto, y las mejores entradas de cada grupo se comparan. En el ejemplo dado, hay dos AS, AS1 y AS2.

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 group1, el mejor trayecto es entry1 debido al MED más bajo (el MED se utiliza en esta decisión puesto que las trayectorias son lo mismo QUE). En el group2, hay solamente una entrada (entry2). El mejor trayecto entonces es determinado comparando a los ganadores de cada grupo (el MED no se utiliza en esta comparación por abandono porque los ganadores de cada grupo son de diversos AS - habilitar el always-compare-med BGP cambia este comportamiento predeterminado). Ahora, al comparar el entry1 (el ganador del grupo 1) y entry2 (el ganador del grupo 2), entry2 será el ganador puesto que tiene el mejor IGP métrico al salto siguiente.

Si el always-compare-med BGP también fue habilitado entonces que comparaba el entry1 (el ganador del grupo 1) y del entry2 (el ganador del grupo 2), entry1 será el ganador debido a un MED más bajo.

Cisco recomienda el habilitar del deterministic-med BGP en todas las nuevas instrumentaciones de red. Además, si se habilita el always-compare-med BGP, las decisiones BGP MED son siempre deterministas.

Para más información sobre el deterministic-med BGP y los comandos bgp always-compare-med, refiérase a cómo el comando bgp deterministic-med diferencia del comando bgp always-compare-med.


Información Relacionada


Document ID: 13759