El Border Gateway Protocol (BGP) es el lenguaje que permite que miles de sistemas autónomos (AS) compartan rutas y políticas para sostener Internet. A diferencia de los IGP interiores, BGP prioriza el control y la estabilidad sobre la velocidad, permitiendo que cada operador modele cómo se intercambia el tráfico con socios, clientes y proveedores.
Este tema repasa su naturaleza como protocolo externo, la lógica de path vector, los atributos que definen la selección de rutas, las diferencias entre eBGP e iBGP y las ventajas y desventajas operativas que conlleva su uso.
BGP es el único protocolo de gateway exterior (EGP) estandarizado por la RFC 4271. Opera sobre TCP puerto 179 para garantizar sesiones confiables y se basa en el intercambio de prefijos con información de atributos. Cada participante representa a un sistema autónomo con un número asignado por registros regionales.
Los objetivos principales de BGP son:
Gracias a estas capacidades, BGP enlaza tanto proveedores Tier-1 como redes empresariales con presencia multihomed, centros de datos y nubes públicas.
BGP no calcula distancias numéricas; cada anuncio incluye la secuencia de AS atraviesa (AS_PATH). Este enfoque de path vector permite detectar bucles (si un AS se ve a sí mismo en la lista, descarta la ruta) y da visibilidad completa de por dónde viajará el tráfico.
El proceso de decisión de BGP sigue un árbol de prioridades: primero la ruta con mayor LOCAL_PREF, luego la que tenga el AS_PATH más corto, después la menor MED y, en caso de empate, criterios adicionales como Menor costo IGP hacia NEXT_HOP o menor Router-ID.
Este script de Python replica esa lógica simplificada para elegir entre varias rutas a un mismo prefijo:
def seleccionar_ruta(rutas):
def clave(r):
return (
-r["local_pref"],
len(r["as_path"]),
r["med"],
r["igp_cost"]
)
return sorted(rutas, key=clave)[0]
rutas = [
{"nombre": "Proveedor-A", "local_pref": 200, "as_path": [64512, 13335], "med": 50, "igp_cost": 20},
{"nombre": "Proveedor-B", "local_pref": 150, "as_path": [64513, 64514, 13335], "med": 10, "igp_cost": 5},
{"nombre": "IXP", "local_pref": 200, "as_path": [65535, 13335], "med": 80, "igp_cost": 15}
]
print(seleccionar_ruta(rutas)["nombre"])
El resultado demuestra cómo LOCAL_PREF actúa antes que el largo del AS_PATH: incluso si dos rutas tienen la misma preferencia, ganará la de menor salto entre sistemas autónomos.
BGP define múltiples atributos de ruta que influyen en la decisión. Se dividen en obligatorios (well-known mandatory), discrecionales y opcionales. La tabla resume los más relevantes:
| Atributo | Tipo | Función | Ejemplo de uso |
|---|---|---|---|
| AS_PATH | Well-known mandatory | Secuencia de AS atravesados. | Evitar bucles y preferir trayectos cortos. |
| NEXT_HOP | Well-known mandatory | Dirección IP del siguiente salto para alcanzar el prefijo. | Determinar qué vecinos deben ser alcanzables vía IGP. |
| LOCAL_PREF | Well-known discretionary | Preferencia interna dentro de un AS (más alto es mejor). | Dar prioridad a enlaces con clientes o MPLS. |
| MED | Optional non-transitive | Sugerencia hacia AS vecinos sobre qué entrada usar (más bajo es mejor). | Balancear tráfico entrante entre regiones. |
| COMMUNITIES | Optional transitive | Etiquetas para aplicar políticas (por ejemplo, no exportar a peers). | Automatizar acuerdos comerciales o blackholes. |
Cada operador diseña políticas basadas en estos atributos combinándolos con filtros de prefijos, route-maps u objetos similares. La flexibilidad de BGP radica en esta capacidad de ajustar qué rutas se anuncian, a quién y con qué preferencia.
BGP se ejecuta tanto entre AS distintos (eBGP) como dentro de un mismo AS (iBGP). Aunque comparten sintaxis, sus comportamientos difieren:
| Criterio | eBGP | iBGP |
|---|---|---|
| TTL por defecto | 1 (vecinos directamente conectados). | 255 (puede usar loopback y redes internas). |
| Reescritura de NEXT_HOP | Sí, al anunciar a otro AS. | No automáticamente; requiere políticas. |
| Distribución de rutas | Cada AS decide qué exportar/importar. | Se necesita malla completa o mecanismos como route reflectors. |
| Funciones comunes | Interconexión con proveedores, peers y clientes. | Transportar rutas aprendidas en el borde hacia el resto del AS. |
En redes grandes, los route reflectors y las confederaciones evitan la necesidad de configurar una sesión iBGP entre cada par de routers. Estos mecanismos preservan la consistencia del AS_PATH e introducen atributos internos como CLUSTER_LIST para prevenir bucles.
En entornos Windows Server que utilizan BGP (por ejemplo, con Remote Access o SDN), se pueden revisar los vecinos con PowerShell:
Get-BgpPeer |
Select-Object -Property LocalIPAddress, PeerIPAddress, ASNumber, State
El comando muestra el estado de cada sesión (Established, Idle, Connect) y ayuda a confirmar que las sesiones eBGP/iBGP cumplen los temporizadores configurados.
BGP es imprescindible para el enrutamiento global, pero su potencia trae complejidad. La tabla resume los aspectos a considerar:
| Aspecto | Ventajas | Desventajas |
|---|---|---|
| Control de políticas | Gran granularidad con atributos y communities. | Requiere documentación rigurosa y coordinación entre áreas. |
| Escalabilidad | Maneja cientos de miles de prefijos y múltiples sesiones. | Consumo elevado de memoria/CPU en equipos antiguos. |
| Convergencia | Mecanismos como route dampening reducen flapping global. | Lenta comparada con OSPF; segundos o minutos según políticas. |
| Seguridad | Permite autenticación TCP MD5 y filtrado avanzado. | Vulnerable a anuncios erróneos sin RPKI o validaciones. |
La tendencia actual refuerza BGP con prácticas como prefix filtering, listas de clientes confiables y validación de rutas mediante MANRS y RPKI para disminuir incidentes de secuestro de prefijos.
Entender BGP es clave para integrar redes empresariales con proveedores y para operar infraestructuras multicloud. En el siguiente tema compararemos sus características con RIP y OSPF para identificar qué protocolo conviene en cada escenario.