Border Gateway Protocol

En telecomunicaciones, el protocolo de puerta de enlace de frontera o

BGP (del inglés Border Gateway Protocol)1 es un protocolo mediante el
cual se intercambia información de encaminamiento entre sistemas
autónomos. Por ejemplo, los proveedores de servicio registrados en
Internet suelen componerse de varios sistemas autónomos y para este caso
es necesario un protocolo como BGP.

Entre los sistemas autónomos de los ISP se intercambian sus tablas de

rutas a través del protocolo BGP. Este intercambio de información de Máquina de estados de BGP.
encaminamiento se hace entre los routers externos de cada sistema
autónomo, los cuales deben ser compatibles con BGP. Se trata del
protocolo más utilizado para redes con intención de configurar un protocolo de puerta de enlace exterior (Exterior Gateway
Protocol).

La forma de configurar y delimitar la información que contiene e intercambia el protocolo BGP es creando lo que se conoce
como sistema autónomo o AS. Cada uno tendrá conexiones o sesiones internas (iBGP), así como sesiones externas (eBGP).

El protocolo de puerta de enlace de frontera (BGP) es un ejemplo de protocolo de puerta de enlace exterior (EGP). BGP
intercambia información de encaminamiento entre sistemas autónomos a la vez que garantiza una elección de rutas libres de
bucles. Es el protocolo principal de publicación de rutas utilizado por las compañías más importantes de ISP en Internet. BGP4 es
la primera versión que admite encaminamiento entre dominios sin clase (CIDR) y agregado de rutas. A diferencia de los
protocolos de puerta de enlace internos (IGP), como RIP, OSPF y EIGRP, no usa métricas como número de saltos, ancho de
banda o retardo. En cambio, BGP toma decisiones de encaminamiento basándose en políticas de la red, o reglas que utilizan
varios atributos de ruta BGP.

Índice
Introducción
Relaciones entre AS
Tipos de mensajes
Formato de los paquetes
Ingeniería de tráfico
ORIGIN
AS-PATH
NEXT-HOP
MULTI-EXIT-DISCRIMINATOR (MED)
LOCAL-PREF
ATOMIC AGGREGATE
COMMUNITY
Selección de rutas
Incidencias
Véase también
Referencias
 Bibliografía
Enlaces externos

Introducción
BGP juega un papel crítico en las comunicaciones en Internet. Facilita el intercambio de información sobre redes IP y la
comunicación entre sistemas autónomos (AS). Por tanto, BGP es un protocolo interdominio (entre sistemas autónomos) e
intradominio (dentro del mismo sistema autónomo).

El protocolo BGP se utiliza para intercambiar información mediante el establecimiento de una sesión de comunicación entre los
enrutadores de frontera de los sistemas autónomos. Para conseguir una entrega fiable de la información, se hace uso de una sesión
de comunicación basada en TCP en el puerto número 179. Esta sesión debe mantenerse activa debido a que ambos extremos de la
comunicación periódicamente se intercambian y actualizan información. Al principio, cada router envía al vecino toda su
información de encaminamiento y después únicamente se enviarán las nuevas rutas, las actualizaciones o la eliminación de rutas
transmitidas con anterioridad. Además periódicamente se envían mensajes para garantizar la conectividad.

Cuando una conexión TCP se interrumpe por alguna razón, cada extremo de la comunicación está obligado a dejar de utilizar la
información que ha recibido del otro extremo. En otras palabras, la sesión TCP sirve como un enlace virtual entre dos sistemas
autónomos vecinos, y cuando hay una falta de intercambio de comunicación indica que el enlace virtual se ha caído. Cabe
destacar que esa unión virtual tendrá más de un enlace físico que conecte a los dos enrutadores frontera, pero si una conexión
virtual se cae no indica necesariamente que la conexión física se haya caído.

Desde el punto de vista de su topología, se puede considerar como un gráfico de conexión de sistemas autónomos conectados
mediante enlaces virtuales. En la figura a continuación se pueden ver cuatro sistemas autónomos llamados AS1, AS2, AS3 y AS4
conectados por enlaces virtuales. Es decir, que mantienen sesiones BGP sobre TCP para la comunicación entre los sistemas
autónomos. Cada sistema autónomo contiene una o más redes que se identificaron como N1, N2 y N3 en AS1, y así
sucesivamente. Simplemente observando la figura se puede mostrar que existe más de una ruta posible entre dos sistemas
autónomos determinados. Como también es posible tener uno o más de un router de borde en el mismo sistema autónomo.

Para la puesta en funcionamiento de la red anterior se debe proveer de un mecanismo de intercambio de rutas que permita
comunicar correctamente ambos sistemas. El protocolo BGP utiliza el protocolo de vector de caminos, en inglés, Path vector
protocol para el intercambio de información de encaminamiento en la red. Se transmite una lista con identificación de los AS por
los que pasa el anuncio. De esa manera se conseguirá saber cómo llegar a cualquier dirección del prefijo propagado así como
estar preparado para cursar tráfico para cualquier dirección del prefijo.
Antes de enunciar la mecánica de selección de rutas se deben introducir las dos formas de proceder cuando se cuenta con un
escenario en el que implantar BGP. Se debe distinguir entre BGP externo (eBGP) y BGP interno (iBGP) en función de si la
información se intercambia dentro de un AS o entre dos AS. Se puede observar en la figura anterior que el sistema autónomo AS1
debe propagar tres prefijos IP (N1, N2 y N3) para que sean alcanzables desde los equipos de otros sistemas autónomos. Además,
estas tres redes deberán establecer cierta política de decisión de rutas hacia otros sistemas autónomos. IBGP conforma una
topología virtual mallada de modo que todos los enrutadores de un sistema autónomo se encuentren conectados para que el
intercambio de rutas sea directo desde el router al que le llega el anuncio hacia todos los de su sistema autónomo.

Relaciones entre AS

Las relaciones que existen entre distintos sistemas autónomos son principalmente de interconexión voluntaria (peering) y de
tránsito. Básicamente una relación de tránsito es la que existe entre un proveedor y un cliente, de modo que el cliente pague por
los recursos de Internet que le puede suministrar su proveedor. Las relaciones de peering no suelen ser pagadas y consisten en un
enlace para comunicar dos sistemas autónomos con el fin de reducir costes, latencia, pérdida de paquetes y obtener caminos
redundantes. Se suele hacer peering con sistemas autónomos potencialmente similares en cuanto a tamaño. Por tanto, no se hace
peering con un cliente potencial ya que saldría uno de los dos sistemas autónomos beneficiado.

En la figura se muestra una topología de red con diferentes tipos de relaciones. Los proveedores de nivel 1 (tier 1) son los que por
definición no pagan a otros proveedores y ofrecen servicio y conectividad a muy larga distancia. Los demás proveedores
mostrados pagan al menos el tránsito con un tier 1. Los clientes pagarán a los proveedores con los que tengan un enlace de
tránsito.

BGP además permite la

agregación de rutas de modo
que las rutas manejadas por un
router en concreto sean las
menores posibles.

Un escenario que se suele

repetir es uno llamado
multiconexión, multi-ISP o
multihoming. Este término hace
referencia a un cliente que
contrata a dos proveedores de
tránsito, lo que implica que
existen dos rutas de salida, de
modo que se deberá decidir
entre un camino u otro
dependiendo de ciertas
especificaciones, necesidades o
simples políticas que se
impongan en el sistema
autónomo. Un ejemplo se puede
ver en la figura prestando
atención a Cliente A. Las
especificaciones pueden ser
para equilibrar el tráfico, para
poner un enlace como preferido antes que otro (por ejemplo, porque tenga más velocidad), por tolerancia a fallos, etc. La gestión
de estas prioridades es lo que se llama ingeniería de tráfico y se consigue gracias a los atributos BGP que se definen en el
protocolo.

Tipos de mensajes
Existen cuatro tipos de mensajes BGP que son los siguientes:

OPEN: se utiliza para el establecimiento de una sesión BGP una vez haya sido establecida la conexión TCP. Se suelen negociar
ciertos parámetros que caractericen a esa sesión. Por ejemplo, es muy posible que los miembros de la sesión no tengan la misma
versión de BGP por lo que es importante indicar el número de versión en este mensaje.

UPDATE: es un mensaje de actualización, de mucha importancia en las operaciones de BGP ya que contiene los anuncios de
nuevos prefijos. Se generarán mensajes de actualización cada vez que se determine una nueva mejor ruta para cierto destino o
haya una modificación sobre alguna existente.

KEEPALIVE: una vez que la sesión BGP está activa se envía periódicamente un mensaje para mantener viva la conexión o
KEEPALIVE para confirmar que el otro extremo sigue estando activo en la sesión BGP. Generalmente se acuerda un tiempo
máximo de espera durante el intercambio inicial de mensajes OPEN. El KEEPALIVE suele ser aproximadamente una vez cada
tercio del tiempo de espera, pero no más de una vez cada segundo. Los mensajes KEEPALIVE no se deben generar si el tiempo de
espera es cero ya que en ese caso se entiende que la sesión es completamente fiable.
NOTIFICATION: se envía al cerrar una sesión BGP y esto sucede cuando ocurre algún error que requiera el cierre de la misma.
De modo que es un mensaje que permite informar nada.

Formato de los paquetes

Los paquetes BGP tienen una cabecera de 19 bytes, consistente en los siguientes campos:

• Un campo de 16 bytes de Marcado (Marker): para detectar la pérdida de sincronización o autenticación de mensajes BGP
entrantes,

• Un campo de 2 bytes de Longitud de Paquete (Length): que especifica la longitud del mensaje BGP en bytes (la longitud no
puede ser menor a los 19 bytes de la cabecera sin datos ni mayor a 4096), y

• Un campo de 1 byte de Tipo (Type): que indica el tipo de mensaje.

Los datos que siguen a la cabecera del paquete pueden ser de 0 hasta 4.077 bytes, para dar una longitud máxima posible de 4.096.

Ingeniería de tráfico
La ingeniería de tráfico en BGP es el modo en que se gestiona la red a partir de los atributos con los que cuenta dicho protocolo
para satisfacer determinadas características o imposiciones de un escenario BGP.

Se definen características para el tráfico saliente y para el entrante, siendo este último algo más difícil de controlar. De modo que
esta gestión de la red se hace a partir de la selección de las rutas que cualquier router va a propagar en una red y de las rutas que
va a escoger como preferentes y alternativas.

Para ello se cuenta con un conjunto de atributos que dan información para la toma de decisión para filtrar o seleccionar rutas. Se
definen a continuación dichos atributos:

ORIGIN
Identifica el mecanismo por el cual se anunció el prefijo IP por primera vez. Se puede especificar como IGP (0), EGP (1) o
INCOMPLETE (2). IGP indica que el prefijo IP se aprendió por un protocolo interior al sistema autónomo como por ejemplo
OSPF. EGP indica que el prefijo IP se aprendió por un protocolo exterior como podría ser BGP, por ejemplo puede ser debido a
que se ha realizado agregación. Cualquier otra ruta que no caen en IGP o EGP recaen en INCOMPLETE, ya que la información
de origen está incompleta, y por tanto no se sabe de dónde procede.

Generalmente si el origen es INCOMPLETE es porque se ha aprendido de forma estática. Si se quisiera decidir una selección de
rutas sobre la base de este prefijo se escoge la que tiene un valor ORIGIN más bajo, por lo que se prefieren las rutas aprendidas
por IGP antes que las de EGP y éstas últimas antes que INCOMPLETE.

AS-PATH
El atributo AS-PATH almacena una secuencia de números de AS que identifican la ruta de los AS por los que ha pasado el
anuncio. Cada vez que un router de borde propaga una ruta hacia otro lado añade a este atributo su número de AS constituyendo
así la lista de los AS que se pretendía tener. La lista permanece intacta si se usa IBGP, es decir, si no se sale del sistema
autónomo.
Si se quisiera utilizar el AS-PATH como método de selección de rutas se escogería el que tuviera una lista AS-PATH más
pequeña. Esto es una forma de medir que haya menos saltos hacia el destino aunque no es exactamente así porque no se tienen en
cuenta los posibles saltos debidos a los routers dentro de un sistema autónomo.

NEXT-HOP
NEXT-HOP o siguiente salto identifica la dirección IP del router correspondiente al siguiente salto hacia el destino. Se debe tener
en cuenta que un prefijo IP se anuncia fuera de un sistema autónomo, por lo que el siguiente salto es el destino que se conoce y al
que hay que enviar el tráfico de los usuarios que quieran llegar a un destino final.

La información de NEXT-HOP se procesa con los datos de tabla de encaminamiento IP. Ahora se contará con una tabla IP (con la
que ya se contaba anteriormente) y con una tabla BGP que contendrá el siguiente salto para cada destino. Se obtendrá una ruta
hacia el destino BGP pasando por los saltos que indique la tabla de encaminamiento IP.

Si se quisiera seleccionar una ruta por este atributo se seleccionaría la que suponga menor coste hacia el siguiente salto, es decir,
menor número de saltos hacia el siguiente salto.

MULTI-EXIT-DISCRIMINATOR (MED)
Es un indicador diseñado para ser utilizado cuando desde un sistema autónomo existen múltiples enlaces hacia un mismo sistema
autónomo. Se puede observar más fácilmente en la siguiente figura.

Como puede verse, desde un mismo sistema autónomo se realizan dos enlaces a otro sistema autónomo. Este atributo se puede
utilizar para como balanceo de carga, de modo que hacia unos prefijos se tenga un valor de MED que haga preferente cierto
prefijo y hacia otros prefijos se haga preferente otro diferente. Esta métrica es local entre dos sistemas autónomos, no se propaga
fuera de ese ámbito. Si se quisiera seleccionar una ruta por medio de este atributo se consideraría preferida la que tuviese un valor
de MED menor.

LOCAL-PREF
Este atributo es útil en un escenario en el que un sistema autónomo tiene conectividad con múltiples sistemas autónomos, de
manera que pueda haber múltiples rutas hacia un mismo destino. Este atributo dará preferencia al envío de tráfico por un enlace
en concreto, por tanto solo tendrá sentido dentro de un mismo sistema autónomo, luego solo se transmite por iBGP.

Se escogerá el envío de datos por el enlace que tenga un LOCAL-PREF más alto, siendo el LOCAL-PREF por defecto de valor
100.
ATOMIC AGGREGATE
Este atributo lo que hace es indicarnos que la ruta correspondiente se ha obtenido mediante agregación de otras rutas más
precisas.

COMMUNITY
Se puede gestionar la distribución de información de encaminamiento a un grupo de destinatarios que forman una comunidad
(COMMUNITY). La idea es que una vez suscrito a un grupo de destinatarios se les pueda aplicar una política de encaminamiento
concreta. De ese modo se simplifica el trabajo agregando información de encaminamiento así como se proporciona una
herramienta para tener un entorno más vigilado en la red.

Se consigue mediante un número que actúa como una etiqueta que califica a la ruta.

Selección de rutas
Todos estos atributos pueden ser utilizados conjuntamente para la selección de rutas, sin embargo se debe imponer un orden de
preferencia de manera que si se tienen varias rutas que pueden ser preferente solo se elija una. Se recorrerá la siguiente lista y se
eliminarán las rutas que no empatan en el mejor valor de cada uno de los criterios. Se ha de tener en cuenta que los criterios de
decisión de enrutamiento que incluyen normas de desempate se aplican a cada prefijo IP o conjunto de prefijos IP destino.

1. Si el siguiente NEXT-HOP no está disponible se ignora la ruta.

2. Eliminar las rutas con menor LOCAL-PREF.
3. Eliminar las rutas con AS-PATH más largo.
4. Eliminar las rutas con ORIGIN más alto.
5. Eliminar las rutas con mayor MED.
6. Eliminar las rutas aprendidas por IBGP si las hay aprendidas por eBGP.
7. Eliminar las rutas con mayor coste hacia el NEXT-HOP.
8. Preferir la ruta que ha anunciado el router con menor identificador BGP.
9. Preferir la ruta recibida desde la interfaz con menor dirección para el vecino.
Las últimas dos entradas de la lista son una forma de selección de rutas de alguna manera arbitrarias, ya que no indican una
política regulada como tal por un administrador. Sin embargo es una manera que pone BGP para en el caso en que no se pueda
decidir, se seleccione alguna ruta.

Incidencias
A lo largo de su historia la el Border Gateway Protocol, ha presentado una serie de incidencias,2 de las cuales las más
importantes han sido las siguientes:

Durante las protestas de Egipto de 2011 el gobierno de Hosni Mubarak ordenó a todos los proveedores de
acceso que operan en el país árabe el corte de las conexiones internacionales. Como consecuencia de los
cortes y bloqueos en la noche del 27 al 28 de enero los enrutadores egipcios dejaron de anunciar hasta 3.500
rutas de BGP, dejando al resto de enrutadores sin la información necesaria para intercambiar tráfico con los
servidores egipcios.3
El 24 de junio de 2019 una pequeña compañía en Pensilvania se convirtió en un "embudo" cuando el tráfico de
Verizon AS701,4 5 un gran cliente de tránsito de Internet, se volcó en él por una política de filtrado de rutas.
Esto ocasionó que los sitios web (muchos de ellos alojados y/o monitorizados por Cloudflare, así como otros
proveedores)6 tuvieran un restraso considerable en su servicio.

Véase también
IEEE 802.1aq - Shortest Path Bridging (SPB)
 RIP
IGP
OSPF
EIGRP
Filtrado de rutas
Incidente del AS 7007

Referencias
1. Tanenbaum, Andrew S. (1 de enero de 2003). Redes
de computadoras (https://books.google.es/books?id=
WWD-4oF9hjEC&pg=PA459&lpg=PA459&dq=protoc
olo+de+puertas+de+enlace+frontera&source=bl&ots
=Xyl9UcreD5&sig=y-SZW6yXZvGl9y1DmOch2trVfdI
&hl=es&sa=X&ved=0ahUKEwir-arQ5uDTAhVFfRoK
HXL6CTwQ6AEIMzAC#v=onepage&q=protocolo%20
de%20puertas%20de%20enlace%20frontera&f=fals
e). Pearson Educación. ISBN 9789702601623.
5. AS701 Verizon Business/UUnet (https://bgp.he.net/A
Consultado el 8 de mayo de 2017.
2. Real Academia Española y Asociación de
6. Strickx, Tom (24 de junio de 2019). «How Verizon
Academias de la Lengua Española (2014).
«incidencia : Acontecimiento que sobreviene en el
curso de un asunto o negocio y tiene con él alguna
conexión.» (http://dle.rae.es/incidencia). Diccionario
de la lengua española (23.ª edición). Madrid:
Espasa. ISBN 978-84-670-4189-7. Consultado el 23 de
julio de 2018.
3. Egipto desaparece del mapa de Internet, 28/1/2011,
Ciberpaís (http://www.elpais.com/articulo/internacion
al/Egipto/desaparece/mapa/Internet/elpepuint/20110
128elpepuint_7/Tes) El País
4. Strickx, Tom (24 de junio de 2019). «How Verizon
and a BGP Optimizer Knocked Large Parts of the
Internet Offline Today» (https://blog.cloudflare.com/h
ow-verizon-and-a-bgp-optimizer-knocked-large-parts-
of-the-internet-offline-today/) (html). Cloudflare (en
inglés). Consultado el 25 de junio de 2019. «The leak
should have stopped at Verizon. However, against
numerous best practices outlined below, Verizon’s
lack of filtering turned this into a major incident that
affected many Internet services such as Amazon,
Linode and Cloudflare.»
S701)
and a BGP Optimizer Knocked Large Parts of the
Internet Offline Today» (https://blog.cloudflare.com/h
ow-verizon-and-a-bgp-optimizer-knocked-large-parts-
of-the-internet-offline-today/) (html). Cloudflare (en
inglés). Consultado el 25 de junio de 2019. «DQE
announced these specific routes to their customer
(AS396531 - Allegheny Technologies Inc). All of this
routing information was then sent to their other transit
provider (AS701 - Verizon), who proceeded to tell the
entire Internet about these “better” routes. These
routes were supposedly “better” because they were
more granular, more specific.»

Bibliografía
Bartell, Micah (2004). BGP design and implementation (en inglés).
Ramasamy, Karthikeyan (2007). Network routing: algorithms, protocols, and architectures (en inglés).
Black, Uyless (2000). IP routing protocols: RIP, OSPF, BGP, PNNI, and Cisco routing protocols (en inglés).
Van Beijnum, Iljitsch (2002). BGP (en inglés).

Enlaces externos
En español

Problema de Seguridad (https://web.archive.org/web/20080909080040/http://www.kriptopolis.org/revelan-mayor-

agujero-seguridad-internet), por Kriptopolis
Seguridad en BGP (https://web.archive.org/web/20060222182237/http://www.saulo.net/pub/inv/BGP-art.htm), por
Saulo Barajas

En inglés

RFC4274 BGP-4 Protocol Analysis (http://tools.ietf.org/html/rfc4274)

La desconexión de Egipto (http://stat.ripe.net/egypt) vista desde RIPE
Entrevista en la revista Wired sobre un problema de seguridad (https://web.archive.org/web/20080828222315/htt
p://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html)
Obtenido de «https://es.wikipedia.org/w/index.php?title=Border_Gateway_Protocol&oldid=116944498»

Esta página se editó por última vez el 25 jun 2019 a las 15:13.

El texto está disponible bajo la Licencia Creative Commons Atribución Compartir Igual 3.0; pueden aplicarse
cláusulas adicionales. Al usar este sitio, usted acepta nuestros términos de uso y nuestra política de privacidad.
Wikipedia® es una marca registrada de la Fundación Wikimedia, Inc., una organización sin ánimo de lucro.