Protocolo   de   enrutamiento   exterior   BGP4

INTRODUCCION

El protocolo BGP (Border Gateway Protocol ) es un protocolo de enrutamiento inter-Autonomous System.

Características y algoritmos del protocolo BGP4.

BGP es un protocolo de enrutamiento de un inter sistema; fue diseñado para ser usado entre múltiples sistemas autónomos. Asume que el enrutamiento dentro de un sistema autónomo es hecho por un protocolo de enrutamiento intra- autonomous system.

BGP es un protocolo real de enrutamiento entre sistemas autónomos en los que, la información intercambiada vía BGP, es suficiente para construir un grafo de conectividad entre ellos.

Las características de llave del protocolo son:

+ el conocimiento de los atributos de ruta + la adición de información de las conexiones de la red. (NLRI).

Los atributos de ruta proveen a BGP flexibilidad y expansionalidad. Son divididos en los atributos bien conocidos y los opcionales.

El proveer atributos opcionales permite la experimentación que puede involucrar a un grupo de enrutadores BGP, sin afectar el resto de Internet. Los nuevos atributos opcionales pueden ser agregados a el protocolo como las nuevas opciones pueden ser adicionadas a el protocolo Telnet, por ejemplo.

Uno de los más importantes atributos es el AS-PATH. El AS-PATH permite una adecuada supresión de la información de enrutamiento del loop. En resumen, el AS-PATH sirve como un poderoso y versátil mecanismo de enrutamiento para políticas basadas en enrutamiento.

BGP-4 utiliza el AS-PATH para incluir conjuntos de sistemas autónomos así como listas. Este formato extendido permite generar rutas adicionales para acarrear información de más rutas.

BGP usa un algoritmo que no puede ser clasificado como un vector de distancia puro o un <>. Acarreando una ruta completa AS, con el atributo AS-PATH, oSPF permite reconstruir porciones grandes de toda la topología. Algo similar a "linquetear" algoritmos de estado (link state algorithms). Intercambiar solamente rutas actuales en uso entre los nodos se realiza como lo hacen los algoritmos de vector de distancias.

Para conservar el ancho de banda y el poder de procesamiento, BGP usa incrementos o actualizaciones de información, de donde después de un intercambio inicial de información de enrutamiento, un par de enrutadores BGP, intercambian solamente los cambios de información

Asimismo, BGP-4 ha agregado el concepto de <> para las actualizaciones con incremento. De manera que la información acerca de grupos de redes puede ser representadas como una entidad única. También, BGP especifica la manera de cómo la información de enrutamiento, es intercambiada entre los parlantes BGP en los diferentes sistemas autónomos.

Coexistencia con EGP y OSPF.

Para permitir coexistencia con EGP y OSPF, BGP provee suporte para el acarreo de EGP y OSP. BGP permite también el acarrear estáticamente rutas exteriores definidas o rutas derivadas por la otra información IGP.

NOTA: VER ALGORITMO EN RESUMEN GENERAL

Intercambio de información

Es la primera función, en la red, del sistema parlanchín <> BGP, con otros sitemas BGP. Esta información incluye información de la lista de los sistemas autónomo (ASs). Esta información es suficiente para construir un grafo de conectivad AS desde el cual los ciclos de enrutamiento pueden ser recortados y algunas decisiones de políticas en el nivel pueden ser obligadas a cumplirse.

BGP-4 provee un nuevo set de mecanismos para soportar enrutamiento entre dominios sin clase. Estos mecanismos incluyen soporte para advertir un un prefijo IP y eliminar el concepto de "clase" dentro de BGP. BGP-4 también introduce mecanismos para permitir aggregation of routes, incluyendo rutas AS.

Para caracterizar el conjunto de decisiones de que pueden darse a cumplir usando BGP, hay que tomar en cuenta la regla que advierte el parlante BGP a sus peers ASs (otros otros parlantes BBP con los que está en comunicación) en aquellas rutas que él utiliza. Este regla refleja el paradigma de ruteo "hop-by-hop" generalmente usado en Internet actual. Sin embargo, algunas políticas no pueden ser soportadas por el paradigma de ruteo "hop-by-hop" y de esta manera requiere técnicas tales como source routing. Por ejemplo, BGP no habilita una AS para enviar tráfico a sus vecinos AS con la intención que el tráfico tome una ruta diferente de su original neighboring AS. BGP es altamente aplicable como un protocolo de enrutamiento inter-AS en el Internet actual.

BGP corre sobre un protocolo de transporte confiable cual es el TCP. Esto elimina la necesidad de implementar fragmentación actualizada explícita, retransmisión autenticación y secuenciación. El mecanismo de notificación de error usando en BGP asume que el protocolo de transporte soporta un "graceful" close, i.e., que todo los datos saliente serán entregados antes de que la conexión se cierre.

TCP conoce los requerimientos de transporte de BGP y está presente virtualmente en todos los enrutadores y <> comeciales. BGP utiliza el puerto TCP 179 para establecer sus propias conexiones.

Protocol no necesitan enrutamiento o sea de los enrutadores para intercambiar información. Un non-routing host podría intercambiar información de ruteo con otros enrutadores vía EGP o en un protocolo de enrutamiento interior.Definición de un Sistema Autónomo

Es un conjunto de enrutadores bajo un sola técnica de administración, usando un protocolo de gateway interior y métricas comunes para enrutar paquetes dentro de los otros Ass. Esto con el fin de tener un único plan interior y que sea coherente con un panorama consistente de cuales destinos se van a alcanzar.

Resumen de Operación

Dos sistemas forman un protocolo de transporte para conexión entre uno y otro. Ellos intercambian mensajes para abrir y confirmar los parámetros de conexión. Los datos iniciales fluyen en la tabla de ruteo de BGP. Los cambios por actualizaciones de las tablas son enviadas a la tabla de ruteo. BGP no requiere actualizaciones periódicas a dicha tabla. De manera que un parlante BGP debe retener la versión actual de las entradas de tablas de ruteo de todos sus peers en lo que dure la conexión. Para tales efectos, también los mensajes KeepAlive son enviados periódicamente para asegurar que la conexión esté viva.Mensajes de notificación son enviados de respuesta si ha habido alguna condición de error o por condiciones especiales. Asimismo, si se ha dado una condición de error, luego de que la notificación es enviada, se cierra la conexión.

Los hosts que ejecutan en el Border Gateway

Si un AS particular tiene múltiples speakers BGP y provee servicios para otros Ass deben tener cuidado de tener una vista consistente de las rutas interiores del AS. Esta vista es proveída teniendo todos los parlantes BGP dentro del AS que mantiene conexiones directa BGP con otras similares.

Usando políticas comunes, los parlantes BGP llegan a un acuerdo como a cuál router border se designará como un punto de entrada y/o salida para un particular destino. Esta información es comunicada a los enrutadores internos de los Ass. Asimismo hay un cuidado de asegurarse que los enrutadores interiores, todos han sido actualizados con la información de tránsito, antes que los parlantes BGP anuncien a los otros Ass, el servicio de tránsito por proveer.

Conexiones externas y conexiones internas entre parlantes BGP

Las conexiones entre los parlantes BGP de diferentes Ass son referidas como "external" links. Las conexiones entre parlantes BGP dentro del mismo AS son referidas como "internal" links. Similarmente un peer en un AS diferente es referido como peer externo, mientras un peer en el mismo AS puede ser descrito por un peer interno. Ver figura 1.

Rutas: Anunciamientos y Almacenaje

Para propósitos de este protocolo una ruta es definida como una unidad de información que se une a su destino (a su pareja) con los atributos de una ruta a ese destino.

Rutas son anunciadas entre un par de parlantes BGP mediante mensajes de actualización: el destino es el sistema cuyas direcciones IP son reportadas en el campo NLRI (Network Layer Reachability Information (NLRI) y la ruta es la información reportada en los campos path attributes del mismo mensaje UPDATE .

Las rutas son almacenadas en los RIBs (Routing Information Bases); existen el Adj-RIBs-In, el Loc-RIB, y el Adj-RIBs-Out. Las rutas que serán anunciadas a los otros parlantes BGP deben estar presentes en el Adj-RIB-Out; las rutas que seran usadas por el parlante local BGP debe estar presentes en el Loc-RIB, y el próximo hop de cada una de estas rutas deben estar presente en parlante local BGP que es el centro base para guardar esa información y las rutas que son recibidas de otros parlantes BGP están presentes en el Adj-RIBs-In.

Si el parlante BGP escoje anunciar la ruta, el puede adicionar o modificar los atributos de ruta antes de anunciarla a su destino( peer).

BGP provee mecanismo por los cuales el parlante BGP puede informar a su pareja que una ruta previamente anunciada no es suficiente o su longitud la hace no disponible para usar. Hay 3 métodos para que un parlante BGP pueda indicar que una ruta vive esta situación:

1. El prefijo IP que expresa los destinos de una ruta previamente anunciada puede ser registrada en el campo WITHDRAWN ROUTES del mensaje UPDATE. De esta manera queda marcada como una ruta no longer available for use.

2.Un reemplazo de ruta con la misma información del Network Layer Reachability Information puede ser anunciado, o

3. La conexión del parlante BGP puede ser cerrado, el cual implíticitamente remueve del servicio todas las rutas cuyos pares o destinos (origen-destino) se han anunciado uno al otro.

Formatos de mensaje

Un mensaje es procesado, solamente después que es enteramente recibido. El tamaño máximo del mensaje es 4090 octetos. Todas las implementaciones son requeridas para soportar el tamaño máximo del mensaje. El mensaje más pequeño que puede ser enviado consiste de un encabezado BGP (header) sin la porción de datos or 19 octetos.

Formato del OPEN Message

Después de que una conexión del protocolo de transporte se establece, el primer mensaje enviado por cada extremo del los parlantes BGP es un mensaje OPEN . Si el mensaje OPEN se acepta, un mensaje KEEPALIVE que confirma el OPEN es enviado de regreso. Una vez que es OPEN es confirmado, se intercambian mensajes UPDATE, KEEPALIVE, and NOTIFICATION.

Además del BGP header, (de tamaño fijo) el mensaje OPEN contiene los siguientes

1. Versión:

Este campo de un octeto, entero, sin signo, indica la versión del protocolo. La versión actual de BGP es 4. Es un campo de longitud variable que es interpretado de acuerdo al valor del campo.

2. Tipo de parámetro.

3. My Autonomous System: Este es un entero de dos octetos sin signo que indica el número del despachador del Sistema Autónomo.

4. <>:

Es campo es también un entero de dos octetos sin signo. Indica el número de segundos que el despachador propone para el valor del Hold Timer. Por el acuso de recibo de un mensaje OPEN, un parlente BGP debe calcular el valor del Hold Time, usando el más pequeño de su Hold Time configurado y del Hold Time recibido en el mensaje OPEN.

El valor calculado indica el número máximo de segundos que puede transcurrir entre la recepción de los sucesivos mensajes KEEPALIVE, and/or UPDATE por el despachador.

5. Identificador BGP:

Este campo contiene un entero sin signo de 4 octetos e indica el identificador BGP del despachador. Un parlante BFP dado inicializa el valor de su identificador BGP a una dirección IP asignada al parlante BGP. El valor del identificador BGP es on startup y es el mismo de cada interfase local de cada pareja BGP.

6. Longitud de parametros opciones:

Este campo es de un octeto, entero sin signo que indica la longitud total del campo en octetos de los parámetros. Si el valor de este campo es cero, los parámetros opcionales no están presentes.

7. Parámetros opcionales:

Este campo puede contener una lista de los parámetros opcionales donde cada parámetro es codificado como una tripleta:

7.1 Tipo de parámetro: es un octeto que indentifica parámetros individuales.

7.2 Longitud del parámetro. Es un octeto que contiene la longitud del parámetro <>.

7. <>. Es un campo de longitud variable que es interpretado de acuerdo al valor del campo Tipo de Parámetro.

Parámetros opcionales:

a) Información de autenticación (Parameter Type 1):

Este parámetro opcional puede ser usado para autenticar un compañero de una pareja BGP. El campo Valor del parámetro contiene un código de autenticación que es de un octeto y un campo llamado <> que es de longitud variable.

Código de autenticación:

Este es un entero de 1 octero que indica el mecanismo de autenticación por usarse. Cuando un mecanismo de autenticación se especifica para usar dentro de BGP, tres cosas deben incluirse en la especificación cuales son:

- el valor del Authentication Code que indica el uso del mecanismo. - la forma y el significado del Authentication Data - el algoritmo para los cálculos computacionales de los campos de marca (Marker fields).

COMENTARIO IMPORTANTE:

Note que un mecanismo de autenticación separado puede ser usado en el establecimiento de la conexión del nivel de transporte

<>:

La forma y significado de este campo de longitud variable, depende del Authentication Code.

NOTA: La longitud mínima del mensaje OPENe es 29 octetos incluyendo el encabezado.

Formato del mensaje UPDATE.

Los mensajes UPDATE son usados para transferir información de ruteo entre parejas origen-destino BGP. La información en el paquete UPDATE puede ser usada para construir un grafo que describiría las relaciones entre varios Sistema autónomos. Aplicando las reglas, los ciclos de información de rutas y algunas otras anomalías pueden ser detectadas y removidas del enrutamiento inter-AS routing.

Un mensaje UPDATE se usa para anunciar una factible ruta a su destino o múltiples rutas que no son factibles en el servicio. Un mensaje UPDATE siempre incluye el header BGP (de tamaño fijo), y puede opcionalmente incluir otros campos como:

Longitud de rutas no factible: En un campo de 2 octetos, esta información indica la longitud total del Withdrawn Routes y permite al Network Layer Reachability Information determinar lo siguiente:

Un valor de 0 indica que ninguna ruta está siendo retirada del servicio withdrawn from y que el campo de rutas separadas (WITHDRAWN ROUTES ) no está presente en el mensaje UPDATE.

1. Campo Withdrawn Routes:

Esta es un campo de longitud variable que contiene una lista de prefijos de direcciones IP para las rutas que están siendo separadas del servicio. Cada prefijo de las direcciones IP está codificado en 2 tuplas de la forma , cuyos campos son descritos como sigue:

+---------------------------+ | Length (1 octet) | +---------------------------+ | Prefix (variable) | +---------------------------+

a) Length:

Es la longitud en bits del prefijo de la dirección IP. Cero indica que el prefijo corresponde (matches) a todas las direcciones IP.

b) Prefix:

Este campo contiene prefijos de direcciones IP. 2. Total Path Attribute Length: De dos octetos, indica la longitud total del campo Path Attributes y su valor lo siguiente:

Un valor de 0, que el NLRI no está presente en el mensaje UPDATE.

3. Path Attributes:

Es una secuencia de longitud variable presente en cada UPDATE. Asimismo, hay 4 tipos de atributos de ruta cuales son: 1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive.

Los atributos Well-known deben ser reconocidos por cada UPDATE. Algunos de estos atributos son mandatory o sea, no son opcionales y deben ser incluidos en cada mensaje. Otros son discrecionales y pueden que no sean enviados en un mensaje particular de UPDATE.

Los atributos New transitive optional pueden ser ligados a la ruta por el despachador o por cualquier AS en la ruta. Si ellos no son atados por el originador, el bit parcial en el octero Attribute Flags es inicializado a 1. Las reglas para ligar nuevos atributos non-transitive optional dependerán de la naturaleza el atributo especificado. Los atributos opcionales (transitive and non-transitive) pueden ser actualizados, si es necesario, por los ASs en la ruta

El despachador de un mensaje UPDATE debería ordenar path attributes dentro de un mensaje UPDATE . El receptor de un mensaje UPDATE debe ser preparado para manejar atributos dentro del UPDATE que están fuera de orden. El mismo atributo no puede aparecer más que una vez dentro del campo Path Attributes de un mensaje particular UPDATE.

Cada atributo de ruta es una tripleta: .

Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet.

0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr. Flags |Attr. Type Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

El bit de más alto rango (bit 0) del octeto Attribute Flags es el bit que define cuando el atributo es opcional (si = 1) o si no lo es ((si = 0).

Uso del Path Attribute 1 ORIGIN 2 AS_PATH 3 NEXT_HOP 4 MULTI_EXIT_DISC 5 LOCAL_PREF 6 ATOMIC_AGGREGATE 7 AGGREGATOR 1. ORIGIN (Type Code 1):

Este es un octeto con los atributos no opcional (well-known mandatory) del origen de la ruta de información.. Será generado por el sistema autónomo que origina la información de enrutamiento asociada. Será incluido en los mensajes UPDATE de todos los parlante BGP que fueron escogidos para propagar esta información a otros parlantes BGP.

Los valores son los siguientes:

Valor Significado

0 IGP - Network Layer Reachability Information is interior to the originating AS

1 EGP - Network Layer Reachability Information learned via EGP

2 INCOMPLETE - Network Layer Reachability Information learned by some other means

2. AS_PATH (Type Code 2):

AS_PATH es un atributo mandatory. Identifica los Sistemas Autónomos a través de los cuales pasa la información de enrutamiento acarreada en el mensaje UPDATE .

Cuando un parlante BGP propaga una ruta, la cual fue aprendida desde otro mensaje UPDATE de otro parlante BGP, modificará el atributo de ruta AS_PATH . Esto lo hará con base en la localización del parlante BGP al cual la ruta será enviada.

Cuando un parlante BGP anuncia la ruta a otro parlante que se localiza en su propio Sistema Autónomo, el parlante anunciador no modificará el atributo AS_PATH asociado con la ruta. Pero si la ruta es anunciada a un parlante BGP del sistema autónomo vencidario, sí actualizará el atributo AS_PATH.

Cuando un parlante BGP origina una ruta:

El parlante origen incluirá su propio número AS en el atributo AS_PATH de todos los mensajes UPDATE que se enviaron a los parlantes BGP localizados en la vecindad de los sistemas autónomos. Sin embargo, también incluye un atributo AS_PATH vacío ( cuyo valor es 0) a todos los mensajes UPDATE que se enviaron a los parlante BGP localizados en su propio sistema autónomo.

Este atributo es compuesto de una secuencia de segmentos de ruta AS. Cada AS path segment es representado por una tripleta: .

The path segment type es 1 octeto con los siguientes valores:

Valor Tipo de segmento

1 AS_SET: unordered set of ASs a route in the UPDATE message has traversed

2 AS_SEQUENCE: ordered set of ASs a route in the UPDATE message has traversed

3. NEXT_HOP (Type Code 3):

Este atributo también es un a well-known mandatory que define la dirección IP del del próximo hop de los destinos listados en el NLR.

4. MULTI_EXIT_DISC (Type Code 4):

El atributo MULTI_EXIT_DISC para discriminar entre múltiples puntos de salida o de entrada a un mismo AS. El valor del atributo MULTI_EXIT_DISC es un número sin signo llamado métrica.

5. LOCAL_PREF (Type Code 5):

LOCAL_PREF es un atributo que se incluye también en todos los mensajes UPDATE. LOCAL_PREF lo utiliza el parlante BGP para informar a otros parlantes BGPs en su propio Sistema Autónomo de su preferencia por una ruta anunciada.

Un parlante BGP calculará el grado de preferencia para cada ruta externa e incluye el grado de preferencia también cuando anuncia una ruta a sus propias parejas internas (internal peers).

AGGREGATOR

AGGREGATOR es un atributo opcional transitivo que puede ser incluido en actualizaciones formadas por agregación. Un parlante BGP que ejecuta route aggregation puede adicionar el atributo AGGREGATOR. Este contendrá su propio número de AS y su propia dirección IP.

4. Network Layer Reachability Information:

Reachability information es compuesto por::

+---------------------------+ | Length (1 octet) | +---------------------------+ | Prefix (variable) | +---------------------------+

a) Length:

Indica la longitud e bits del prefijo de la dirección IP. Cero indica que el prefijo corresponde (matches) a todas las direcciones IP.

b) Prefix:

El campo Prefix contiene prefijos de direcciones. Resumiendo

Longitud mínima del mensaje e UPDATE : 23 octetos -- 19 octetos para el encabezado +

2 octetos para Unfeasible Routes Length +

2 octetos para el Total Path Attribute Length (el valor del campo Unfeasible Routes Length es 0 y el valor de Total Path Attribute Length is 0).

Un mensaje UPDATE puede anunciar más de una ruta, las cuales pueden ser descritas por varios path attributes.

Un mensaje UPDATE puede listar múltiples rutas por separar del servicio.

Un mensaje UPDATE podría anunciar solamente rutas que van a ser separadas del servicio, en tal caso, no incluye path attributes o Network Layer Reachability Information. Asimismo, puede anunciar rutas posibles, en tal caso el campo WITHDRAWN ROUTES no estará presente.

KEEPALIVE Message Format

BGP no usa cualquier protocolo de transporte basado en mecanismos keep-alive para determinar si los destinos son alcanzables. Los mensajes KEEPALIVE son intercambiados entre las parejas origen-destino lo suficiente para que el Hold Timer no expire. Estos mensaje no deben ser enviados más que 1 por segundo.

Si el intervalo Hold Time es cero, entonces, los mensajes periódicos KEEPALIVE no deben ser enviados.

Estos mensajes consisten de un encabezado y tiene una longitud de 19 octetos.

Formato del mensaje NOTIFICATION.

Un mensaje de NOTIFICATION es enviado cuando un error es detectado. La conexión BGP se cierra inmediatamente después que se envía este mensaje.

El mensaje NOTIFICATION contiene los siguientes campos:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error code | Error subcode | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Error Code:

Código de error Descripción

1 Message Header Error

2 OPEN Message Error

3 UPDATE Message Error

4 Hold Timer Expired

5 Finite State Machine Error

6 Cease

Error subcode:

Este es un octeto, cuyo valor es un entero sin signo que provee información acerca de la naturaleza del error reportado. Entre ellos están:

1 - Connection Not Synchronized. 2 - Bad Message Length. 3 - Bad Message Type.

SubCódigos de error del mensaje OPEN:

1 - Unsupported Version Number. 2 - Bad Peer AS. 3 - Bad BGP Identifier. ' 4 - Unsupported Optional Parameter. 5 - Authentication Failure. 6 - Unacceptable Hold Time.

SubCódigos de error del mensaje UPDATE:

1 - Malformed Attribute List. 2 - Unrecognized Well-known Attribute. 3 - Missing Well-known Attribute. 4 - Attribute Flags Error. 5 - Attribute Length Error. 6 - Invalid ORIGIN Attribute 7 - AS Routing Loop. 8 - Invalid NEXT_HOP Attribute. 9 - Optional Attribute Error. 10 - Invalid Network Field. 11 - Malformed AS_PATH.

Data:

Este campo de longitud variable se usa para diagnosticar la causa para el mensaje NOTIFICATION. El contenido de este campo depende de Error Code and Error Subcode