¿Qué es BGP?
BGP (Border Gateway Protocol) es un protocolo de enrutamiento del tipo EGP (Exterior Gateway Protocol). Su trabajo específico es intercambiar información de reachability (accesibilidad) entre Sistemas Autónomos (AS).
Pero, ¿qué es un Sistema Autónomo?
Un
AS es un conjunto de redes IP bajo el control de una o más entidades
(una empresa, una universidad, un ISP) que presenta una política de
enrutamiento común y coherente hacia el exterior. Cada AS tiene un
número único llamado ASN (Autonomous System Number).
En términos simples:
Dentro de un AS → los routers hablan protocolos IGP (OSPF, EIGRP, IS-IS).
Entre AS diferentes → los routers hablan BGP.
BGP se considera un protocolo de vector de rutas (path-vector), porque además de conocer el destino, conoce la lista completa de AS por los que pasa una ruta. Eso es clave para evitar bucles y para tomar decisiones de enrutamiento basadas en políticas, no solo en métricas técnicas.
¿Por qué es crucial en Internet?
Para entender su importancia, pensemos en la estructura de Internet: no es una red única, sino miles de redes independientes (los AS) que necesitan conectarse entre sí.
BGP es el único protocolo capaz de:
Conectar ISP gigantes (Tier 1) con ISP regionales.
Permitir que una empresa con dos proveedores de Internet (multihoming) siga funcionando si uno falla.
Aplicar políticas comerciales: "prefiero esta ruta porque me sale más barato", "no quiero transportar tráfico de este competidor", "bloqueo estas redes por seguridad".
Sin BGP, cada red solo conocería sus rutas internas. No habría forma de que un usuario de Movistar (AS en España) llegue a Google (AS 15169) pasando por Level3, Cogent, etc. BGP es, literalmente, el protocolo que anuncia qué redes existen y cómo llegar a ellas en el ámbito global.
Diferencia entre IGP y EGP (BGP)
Esta es una de las confusiones más comunes al empezar. Aquí va la tabla definitiva con las diferencias clave.
| Característica | IGP (OSPF, IS-IS, EIGRP) | EGP (BGP) |
| Alcance | Dentro de un mismo Sistema Autónomo (AS). | Entre Sistemas Autónomos diferentes. |
| Objetivo | Convergencia rápida y mejor ruta técnica. | Estabilidad y aplicación de políticas. |
| Métrica | Coste, ancho de banda, retardo. | Atributos (AS Path, Local Pref, MED, etc.). |
| Descubrimiento | Automático (vía paquetes Hello). | Manual (configuración explícita de peers). |
| Transporte | Directo sobre IP (OSPF 89, EIGRP 88). | TCP puerto 179 (conexión confiable). |
| Convergencia | Muy rápida (segundos o milisegundos). | Lenta (puede tardar minutos). |
| Prevención de bucles | SPF, áreas, topología jerárquica. | AS Path (lista de AS recorridos). |
| Escalabilidad | Limitada (cientos o pocos miles de rutas). | Muy alta (Internet ~900k+ prefijos). |
| Políticas | Muy limitadas. | Muy flexibles (policy-options, communities). |
Estados de BGP:
| Estado | Descripción y Funcionalidad |
| Idle | Es el estado inicial. El proceso BGP espera un evento de inicio (Start Event), generalmente la configuración del peer o un reset manual. En este punto, no hay recursos asignados a la sesión. |
| Connect | El router intenta establecer una conexión TCP de tres vías (Three-way handshake) en el puerto 179 con el vecino. Si tiene éxito, envía un mensaje Open y pasa a OpenSent. |
| Active | El router no pudo establecer la conexión TCP en el estado Connect y reintenta la conexión. Si este estado persiste, suele indicar fallas de conectividad de Capa 3 o bloqueos por firewall. |
| OpenSent | El router ha enviado su mensaje Open (que incluye el AS, Hold Time y BGP Identifier) y está a la espera de recibir el mensaje Open por parte del peer. |
| OpenConfirm | El router recibió un mensaje Open válido del vecino. En este punto, se envía un mensaje Keepalive y se espera la confirmación (Keepalive) del otro extremo para validar los parámetros. |
| Established | La sesión está plenamente operativa. Es el único estado donde los vecinos intercambian mensajes Update (prefijos/rutas), Keepalives y mensajes de Notification. |
Atributos de BGP :
| Atributo | Categoría | Propósito | Criterio de Selección |
| Next Hop | Well-known Mandatory | Indica la dirección IP del siguiente salto para alcanzar el destino. | Debe ser alcanzable. |
| AS Path | Well-known Mandatory | Lista de los AS que ha atravesado el prefijo para evitar bucles. | El camino más corto gana. |
| Origin | Well-known Mandatory | Define el origen de la ruta (IGP, EGP o Incomplete). | IGP es preferido sobre Incomplete. |
| Local Preference | Well-known Discretionary | Define la prioridad de salida dentro de un mismo AS. | El valor más alto gana. |
| Atomic Aggregate | Well-known Discretionary | Informa si el prefijo ha sido resumido o agregado. | Informativo. |
| Aggregator | Optional Transitive | Contiene el ID y el AS del router que realizó la agregación. | Informativo. |
| Community | Optional Transitive | Etiqueta para agrupar rutas y aplicar políticas comunes. | Basado en política. |
| MED | Optional Non-transitive | Sugiere al AS vecino el punto de entrada preferido. | El valor más bajo gana. |
Profundización:
Local Preference en Junos OS
La Local Preference (LP) es un atributo de tipo Well-known Discretionary (reconocido por todos pero opcional en su inclusión) que se utiliza para influir en la selección de la ruta de salida dentro de un Sistema Autónomo (AS). Es la herramienta principal para la ingeniería de tráfico saliente en entornos multi-homed.
Mecanismo de Funcionamiento
A diferencia de otros atributos, la Local Preference tiene un alcance limitado exclusivamente a la sesión iBGP (Internal BGP). Cuando un router recibe una actualización de un par eBGP, el atributo LP no suele estar presente. Es responsabilidad del router receptor asignar este valor antes de redistribuir la ruta a sus pares internos.
Regla de Decisión: El algoritmo de selección de rutas de Junos prefiere el valor de Local Preference más alto.
Valor Predeterminado: En Junos, el valor por defecto es 100.
Lógica de Aplicación: ¿Por qué en la Importación?
Aunque el objetivo es controlar el tráfico que sale de la red, la configuración debe realizarse sobre las rutas que entran (mensajes BGP Update).
La lógica técnica es la siguiente: al asignar una métrica de preferencia superior a los prefijos recibidos a través de un enlace específico, se le indica a todo el AS que ese punto de salida es el más óptimo para alcanzar dichos destinos.
Implementación mediante Routing Policy
En Junos OS, la manipulación de la Local Preference se realiza de forma granular mediante policy-statements.
Escenario: Se dispone de dos proveedores (ISP-A e ISP-B). Se requiere que el tráfico hacia internet utilice prioritariamente al ISP-A.
Configuración de la Política:
[edit policy-options]
policy-statement IN-ISP-A-PREFER {
term 1 {
from protocol bgp;
then {
local-preference 200;
accept;
}
}
}
Aplicación al Protocolo:
[edit protocols bgp group EBGP-VECINOS]
neighbor 10.0.0.1 {
import IN-ISP-A-PREFER;
peer-as 65100;
}
Verificación en el Plano de Control:
Para validar la correcta aplicación del atributo y la selección de la ruta activa, se utiliza el comando operativo:
show route protocol bgp [Prefijo] detail
En la salida detallada, se debe verificar el campo Localpref. El router marcará con un asterisco (*) la ruta seleccionada, que será aquella con el valor de Local Preference superior, asumiendo que el Next-hop es alcanzable.
Multi-Exit Discriminator (MED)
El MED es un atributo de tipo Optional Non-transitive. A diferencia de la Local Preference, que influye en el tráfico de salida, el MED se utiliza para influir en cómo el tráfico de un Sistema Autónomo (AS) vecino entra a nuestra red cuando existen múltiples puntos de conexión hacia el mismo vecino.
Mecanismo de Funcionamiento
El MED se transmite desde nuestro AS hacia el AS vecino a través de sesiones eBGP. Su propósito es "sugerir" al vecino cuál es el punto de entrada preferido.
Regla de Decisión: El algoritmo de selección de rutas de Junos prefiere el valor de MED más bajo.
Valor Predeterminado: En Junos, si no se especifica, el valor por defecto es 0.
Propagación: Al ser Non-transitive, el AS vecino que recibe el MED puede usarlo para sus decisiones internas, pero no debe reenviarlo a un tercer AS.
Lógica de Aplicación: Exportación de Métricas
En Junos OS, el MED se gestiona mediante el comando metric dentro de una política de exportación (export).
La lógica técnica es la siguiente: al enviar nuestros prefijos hacia el exterior, les adjuntamos una métrica. El router del vecino comparará los anuncios recibidos por sus distintos enlaces; el enlace que anuncie la métrica más baja será el seleccionado para enviarnos el tráfico de retorno.
Implementación mediante Routing Policy
Supongamos un escenario con dos enlaces hacia el mismo ISP. Se desea que el Enlace 1 sea el principal y el Enlace 2 sea el de respaldo.
Configuración de la Política:
[edit policy-options]
policy-statement ENVIAR-METRICA-RESPALDO {
term 1 {
from protocol direct;
then {
metric 50;
accept;
}
}
}
Aplicación al Protocolo (Enlace de Respaldo):
[edit protocols bgp group EBGP-VECINO]
neighbor 192.168.1.2 {
export ENVIAR-METRICA-RESPALDO;
peer-as 65200;
}
Verificación y Comportamiento Especial
Para verificar el MED enviado o recibido, se utiliza:
show route advertising-protocol bgp [Vecino] (para ver qué enviamos).
show route receive-protocol bgp [Vecino] detail (para ver qué recibimos).
TOPOLOGIA BASICA:
El router A se conectara con 2 proveedores distintos para publicar sus prefijos y recibir la full table de internet.
Router-A ge-0/0/0 -> Router-B ge-0/0/0 (Red: 10.1.2.0/30)
Router-A ge-0/0/1 -> Router-C ge-0/0/0 (Red: 10.1.3.0/30)
Router-A Loopback lo0.0: 192.168.10.1/32 (Red a anunciar).
Configuracion de ROUTER A :
# Direccionamiento de Interfaces
set interfaces ge-0/0/0 unit 0 family inet address 10.1.2.1/30
set interfaces ge-0/0/1 unit 0 family inet address 10.1.3.1/30
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
# Definición del Sistema Autónomo
set routing-options autonomous-system 65000
# Configuración de BGP
set protocols bgp group EBGP-ISPS type external
set protocols bgp group EBGP-ISPS neighbor 10.1.2.2 peer-as 65001
set protocols bgp group EBGP-ISPS neighbor 10.1.3.2 peer-as 65002
Configuracion de ROUTER B :
set interfaces ge-0/0/0 unit 0 family inet address 10.1.2.2/30
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set routing-options autonomous-system 65001
set protocols bgp group CLIENTE-A type external
set protocols bgp group CLIENTE-A neighbor 10.1.2.1 peer-as 65000
Configuracion de ROUTER C :
set interfaces ge-0/0/0 unit 0 family inet address 10.1.3.2/30
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set routing-options autonomous-system 65002
set protocols bgp group CLIENTE-A type external
set protocols bgp group CLIENTE-A neighbor 10.1.3.1 peer-as 65000
En Junos BGP no anuncia nada por defecto. Necesitamos aplicar Políticas de Exportación en los ISPs para que el Router-A reciba información.
Router A:
edit policy-options
set policy-statement EXPORT-MI-RED term 1 from protocol direct
set policy-statement EXPORT-MI-RED term 1 from route-filter 192.168.10.1/32 exact
set policy-statement EXPORT-MI-RED term 1 then accept
edit protocols bgp group EBGP-ISPS
set export EXPORT-MI-RED
Router B:
set policy-options policy-statement SEND-LO0 term 1 from protocol direct
set policy-options policy-statement SEND-LO0 term 1 from route-filter 2.2.2.2/32 exact
set policy-options policy-statement SEND-LO0 term 1 then accept
set protocols bgp group CLIENTE-A neighbor 10.1.2.1 export SEND-LO0
commit
ROUTER C :
set policy-options policy-statement SEND-LO0 term 1 from protocol direct
set policy-options policy-statement SEND-LO0 term 1 from route-filter 3.3.3.3/32 exact
set policy-options policy-statement SEND-LO0 term 1 then accept
set protocols bgp group CLIENTE-A neighbor 10.1.3.1 export SEND-LO0
commit
Verificaciones :
Las sesiones contra los Routers A y B estan establecidas
Revisamos en ROUTER A :
Estamos aprendiendo las redes que nos publican los ROUTER B y C que simulan ser salidas a Internet como podria ser TELXIUS o CIRION.
Probando LOCAL PREFERENCE:
Configuraremos ambos proveedores (B y C) para que anuncien el mismo prefijo: 8.8.8.8/32. Esto creará un escenario de "empate" en el Router-A, lo cual es la base perfecta para aplicar ingeniería de tráfico.
Router B
# Crear una ruta estática de descarte para que el protocolo pueda anunciarla
set routing-options static route 8.8.8.8/32 discard
# Actualizar la política para incluir la nueva red
set policy-options policy-statement SEND-LO0 term 2 from route-filter 8.8.8.8/32 exact
set policy-options policy-statement SEND-LO0 term 2 then accept
commit
Router C
# Crear la misma ruta estática
set routing-options static route 8.8.8.8/32 discard
# Actualizar la política
set policy-options policy-statement SEND-LO0 term 2 from route-filter 8.8.8.8/32 exact
set policy-options policy-statement SEND-LO0 term 2 then accept
commit
Router A:
edit policy-options
set policy-statement PREFERIR-C term 1 then local-preference 200
set policy-statement PREFERIR-C term 1 then accept
exit
edit protocols bgp group EBGP-ISPS
set neighbor 10.1.3.2 import PREFERIR-C
top
commit
Revision:
Se observa en la imagen que esta prefiendo la ruta por 10.1.3.2 de la politica que creamos arriba
Si bajamos la interface en C y revisamos de nuevo nos da que se va por la otra ruta que seria la 10.1.2.2
| Categoría | Comando | Utilidad Técnica |
| Resumen General | show bgp summary | Ver estado de las sesiones (Establ, Active, Idle), AS vecinos y conteo de rutas. |
| Vecino Específico | show bgp neighbor 10.1.2.2 | Ver detalles de la sesión, capacidades negociadas, timers y errores de hold-time. |
| Rutas Recibidas | show route receive-protocol bgp 10.1.2.2 | Ver qué te envía el vecino antes de que tus políticas de importación las filtren. |
| Rutas Anunciadas | show route advertising-protocol bgp 10.1.2.2 | Ver qué le estás enviando tú al vecino (vital para validar tus políticas de export). |
| Tabla de Rutas | show route protocol bgp | Ver todas las rutas BGP que ya fueron aceptadas e instaladas en la tabla inet.0. |
| Rutas Ocultas | show route hidden | Ver rutas rechazadas por políticas o con Next-Hop inalcanzable (común en iBGP). |
| Detalle de Ruta | show route 8.8.8.8 detail | Ver atributos completos: Local Pref, AS-Path, MED, Comunidades y por qué fue elegida. |
| Prueba de Origen | ping 8.8.8.8 source 192.168.10.1 | Validar conectividad usando la IP que estás anunciando (evita falsos negativos). |
MED:
En este laboratorio, exploramos cómo un Proveedor de Internet (ISP) puede influir en la ruta que toma el tráfico de un cliente para entrar a su red. Mientras que el Local Preference se usa para decidir por dónde salir, el MED se utiliza para sugerir por dónde entrar.
El Escenario
Nuestra topología cuenta con un cliente (AS 65000) conectado a un ISP (AS 65001) a través de dos puntos distintos: el Router-B y el Router-D.
Objetivo: Queremos que el tráfico del cliente prefiera entrar por el Router-B y use el Router-D solo como respaldo.
Configuración Aplicada
Para lograr esto, configuramos métricas (MED) en los anuncios que el ISP envía hacia el cliente. Nota: En BGP, una métrica menor es preferida.
En el Router-B (Prioridad Alta - MED 50)
Definimos una política que marca las rutas (su Loopback y la de Google) con una métrica de 50.
# Creamos la política de exportación con MED bajo
set policy-options policy-statement SEND-MED-LOW term 1 from protocol direct
set policy-options policy-statement SEND-MED-LOW term 1 from route-filter 2.2.2.2/32 exact
set policy-options policy-statement SEND-MED-LOW term 1 then metric 50
set policy-options policy-statement SEND-MED-LOW term 1 then accept
set policy-options policy-statement SEND-MED-LOW term 2 from protocol bgp
set policy-options policy-statement SEND-MED-LOW term 2 from route-filter 8.8.8.8/32 exact
set policy-options policy-statement SEND-MED-LOW term 2 then metric 50
set policy-options policy-statement SEND-MED-LOW term 2 then accept
set policy-options policy-statement SEND-MED-LOW then reject
# Aplicamos al vecino (Router-A)
set protocols bgp group CLIENTE-A neighbor 10.1.2.1 export SEND-MED-LOW
En el Router-D (Prioridad Baja - MED 150)
Configuramos una métrica más alta para que este camino sea menos atractivo.
# Creamos la política con un "costo" mayor
set policy-options policy-statement SEND-MED-HIGH term 1 from protocol direct
set policy-options policy-statement SEND-MED-HIGH term 1 from route-filter 4.4.4.4/32 exact
set policy-options policy-statement SEND-MED-HIGH term 1 then metric 150
set policy-options policy-statement SEND-MED-HIGH term 1 then accept
set policy-options policy-statement SEND-MED-HIGH term 2 from protocol bgp
set policy-options policy-statement SEND-MED-HIGH term 2 from route-filter 8.8.8.8/32 exact
set policy-options policy-statement SEND-MED-HIGH term 2 then metric 150
set policy-options policy-statement SEND-MED-HIGH term 2 then accept
set policy-options policy-statement SEND-MED-HIGH then reject
# Aplicamos al vecino (Router-A)
set protocols bgp group CLIENTE-A neighbor 10.1.4.1 export SEND-MED-HIGH
Verificacion:
Comandos para revision
| Categoría | Comando | Propósito de Ingeniería / Uso Senior |
| Visibilidad de Entrada (Adj-RIB-In) | show route receive-protocol bgp [IP] | Ver las rutas puras que envía el vecino antes de tus filtros. |
| Diagnóstico de Descarte | show route receive-protocol bgp [IP] hidden | CRÍTICO: Ver rutas rechazadas por políticas o por Next-Hop inalcanzable. |
| Análisis de Descarte (Detalle) | show route receive-protocol bgp [IP] hidden detail | Te da la razón exacta (ej: AS path contains local AS o Next-hop unreachable). |
| Visibilidad de Salida (Adj-RIB-Out) | show route advertising-protocol bgp [IP] | Confirmar qué prefijos y atributos (MED, Communities) estás enviando. |
| Salida Detallada | show route advertising-protocol bgp [IP] detail | Ver el AS-Path exacto y las comunidades BGP aplicadas antes de salir. |
| Proceso de Selección | show route [Prefijo] detail | Ver el historial de la ruta y por qué BGP eligió (o no) ese camino. |
| Algoritmo de Decisión | show route [Prefijo] best-path | Desglose paso a paso del algoritmo de selección de BGP para ese prefijo. |
| Salud de la Sesión | show bgp neighbor [IP] extensive | Ver capacidades negociadas (4-byte AS, Route Refresh) y contadores de error. |
| Inestabilidad (Flapping) | show bgp neighbor [IP] flap-statistics | Ver si el vecino está sufriendo de "Route Dampening" por cortes constantes. |
| Estadísticas de Mensajes | show bgp statistics | Ver el volumen de mensajes UPDATE/KEEPALIVE. Útil para medir carga en el CPU. |
| Rutas Huérfanas | show route resolution unresolved | Buscar rutas BGP que no tienen salida porque el IGP (OSPF/Static) no llega al Next-Hop. |
| Filtro por Regex | show route aspath-regex "[Regex]" | Buscar rutas que pasan por un AS específico (ej: ".* 15169" para Google). |
| Filtro por Comunidad | show route community [ID] | Ver todas las rutas marcadas con una etiqueta de tráfico específica. |
| Rutas Dual-Stack | show route table inet6.0 protocol bgp | Verificación exclusiva de rutas IPv6 aprendidas por BGP. |
| Limpieza Silenciosa (In) | clear bgp neighbor [IP] soft-in | Re-procesar políticas de entrada sin tirar la sesión (Soft Reconfiguration). |
| Limpieza Silenciosa (Out) | clear bgp neighbor [IP] soft | Re-anunciar rutas con nuevos atributos (ej: cambiar el MED) sin corte de tráfico. |
| Sostenibilidad (Stale) | show route protocol bgp stale | Ver rutas que permanecen activas durante un reinicio (Graceful Restart). |
| Uso de Memoria | show task statistics | Ver cuánto recurso consume el proceso rpd (Routing Protocol Daemon). |
| Resumen por Grupo | show bgp summary group [Nombre] | Filtrar vecinos por grupos (ej: Clientes, Tránsitos, Peerings). |
| Estado de Sesiones | `show bgp summary | except Est` |
Orden de revision de atributos:
| Orden | Atributo | Regla de Decisión |
| 1 | Next-hop Reachability | Si el Next-hop no es alcanzable vía IGP/Estática, la ruta se ignora. |
| 2 | Local Preference | El valor más alto gana. (Es lo primero que mira el router). |
| 3 | AS-Path Length | El camino más corto gana (menos saltos de AS). |
| 4 | Origin | Preferencia: IGP < EGP < Incomplete. |
| 5 | MED | El valor más bajo gana. (Solo se compara si el AS vecino es el mismo). |
| 6 | Peer Type | Preferencia: eBGP sobre iBGP. |
| 7 | IGP Metric | El camino con el costo IGP más bajo hacia el Next-Hop de BGP. |
| 8 | Router ID | Si todo lo anterior empata, gana el vecino con el Router ID más bajo. |
| 9 | Cluster List | (Para Route Reflectors) Gana la lista más corta. |
| 10 | Peer Address | El último recurso: gana el vecino con la dirección IP más baja. |
No hay comentarios:
Publicar un comentario