IP : Protocolo de puerta de enlace fronteriza (BGP)

¿En qué se diferencia el comando bgp deterministic-med del comando bgp always-compare-med?

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


Contenido


Introducción

Existe a veces confusión entre los dos comandos de configuración BGP (Border Gateway Protocol) bgp deterministic-med y bgp always-compare-med. Este documento explica las diferencias del modo en que pueden afectar los comandos bgp deterministic-med y bgp always-compare-med a la selección del trayecto basada en el MED (Multi Exit Discriminator), y cómo cada comando cambia el comportamiento del BGP al elegir la mejor ruta.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información en este documento se basa en el Software Release 12.2(10b) de Cisco IOS�.

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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

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

Antecedentes

Hay dos comandos de configuración BGP que pueden influenciar la selección de trayectos en base a MED, el deterministic-med BGP y los comandos bgp always-compare-med.

Habilitar el comando bgp deterministic-med asegura la comparación de la variable MED al elegir las rutas des divulgación por diversos pares en el mismo sistema autónomo. Al activar el comando bgp always-compare-med se garantiza la comparación de MED para trayectos de vecinos en distintos sistemas autónomos. El comando bgp always-compare-med es útil cuando proveedores de servicios múltiples o empresas, concuerdan en una política uniforme para configurar MED. Así, para la red X, si Proveedor de servicios de Internet A (el ISP A) fija el MED a 10, y el ISP B fija el MED a 20, ambos ISP está de acuerdo que el ISP A tiene la trayectoria más de funcionamiento satisfactorio al X.

Nota: No habilitan a los comandos bgp deterministic-med y bgp always-compare-med por abandono. También, los dos comandos son separados; habilitar uno no habilita automáticamente el otro.

Ejemplos de comando

Los ejemplos en esta sección demuestran cómo los comandos bgp deterministic-med y bgp always-compare-med pueden influenciar la selección de trayectos en base a MED.

Nota: Cisco Systems recomienda el habilitar del comando bgp deterministic-med en todas las nuevas salidas de la red. Para las redes existentes, el comando se debe desplegar en todos los routers al mismo tiempo, o en incrementos, tratando de evitar los posibles loops de ruteo BGP internos (iBGP).

Por ejemplo, considere las rutas siguientes para la red 10.0.0.0/8:

entry1: AS(PATH) 500, med 150, external, rid 172.16.13.1
entry2: AS(PATH) 100, med 200, external, rid 1.1.1.1
entry3: AS(PATH) 500, med 100, internal, rid 172.16.8.4

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.)

Nota: Cuando el BGP recibe las rutas múltiples a un destino determinado, las enumera en la orden inversa que fueron recibidas, del más nuevo al más viejo. El BGP entonces compara las rutas en pares, empezando por la más nueva entrada y la mudanza hacia la más vieja entrada (que comienza en la parte superior de la lista y que se baja). Por ejemplo, se comparan la entrada 1 y la entrada 2. El mejor de estos dos entonces se compara al entry3, y así sucesivamente.

Ejemplo 1: Ambos comandos desactivados

El entry1 y el entry2 se comparan primero. El entry2 se elige como el mejor de estos dos porque tiene un Router ID más bajo. El MED no se marca porque las trayectorias son de un diverso sistema autónomo vecino. Luego, la entrada 2 se compara con la entrada 3. La entrada2 se elije como el mejor trayecto debido a que es externo.

Ejemplo 2: bgp deterministic-med Disabled, bgp always-compare-med Enabled

La entrada 1 se compara con la entrada 2. Estas entradas son de diversos sistemas autónomos vecinos, pero puesto que habilitan al comando bgp always-compare-med, el MED se utiliza en la comparación. De estas dos entradas, el entry1 es mejor porque tiene un MED más bajo. Después, el entry1 se compara al entry3. El MED se marca otra vez porque las entradas ahora son del mismo sistema autónomo. El entry3 se elige como el mejor trayecto.

Ejemplo 3: bgp deterministic-med Enabled, bgp always-compare-med Disabled

Cuando habilitan al comando bgp deterministic-med, las rutas del mismo sistema autónomo se agrupan juntas, y las mejores entradas de cada grupo se comparan. La tabla BGP parece esto:

entry1: AS(PATH) 100, med 200, external, rid 1.1.1.1
entry2: AS(PATH) 500, med 100, internal, rid 172.16.8.4 
entry3: AS(PATH) 500, med 150, external, rid 172.16.13.1

Hay un grupo para el AS100 y un grupo para el AS500. Se comparan las mejores entradas de cada grupo. El entry1 es el mejor de su grupo porque es la única ruta del AS100. El entry2 es el mejor para el AS500 porque tiene el MED más bajo. Después, el entry1 se compara al entry2. Puesto que las dos entradas no son del mismo sistema autónomo vecino, el MED no se considera en la comparación. La ruta del BGP externo gana sobre la ruta del Internal BGP, haciendo entry1 la mejor ruta.

Ejemplo 4: Ambos comandos habilitados

Las comparaciones en este ejemplo son lo mismo que en el ejemplo 3, a excepción de la comparación más reciente entre el entry2 y el entry1. El MED se tiene en cuenta para la comparación más reciente porque habilitan al comando bgp always-compare-med. El entry2 se selecciona como el mejor trayecto.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 16046