BGP


¿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ísticaIGP (OSPF, IS-IS, EIGRP)EGP (BGP)
AlcanceDentro de un mismo Sistema Autónomo (AS).Entre Sistemas Autónomos diferentes.
ObjetivoConvergencia rápida y mejor ruta técnica.Estabilidad y aplicación de políticas.
MétricaCoste, ancho de banda, retardo.Atributos (AS Path, Local Pref, MED, etc.).
DescubrimientoAutomático (vía paquetes Hello).Manual (configuración explícita de peers).
TransporteDirecto sobre IP (OSPF 89, EIGRP 88).TCP puerto 179 (conexión confiable).
ConvergenciaMuy rápida (segundos o milisegundos).Lenta (puede tardar minutos).
Prevención de buclesSPF, áreas, topología jerárquica.AS Path (lista de AS recorridos).
EscalabilidadLimitada (cientos o pocos miles de rutas).Muy alta (Internet ~900k+ prefijos).
PolíticasMuy limitadas.Muy flexibles (policy-options, communities).

 

 Estados de BGP:

  

EstadoDescripción y Funcionalidad
IdleEs 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.
ConnectEl 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.
ActiveEl 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.
OpenSentEl 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.
OpenConfirmEl 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.
EstablishedLa 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 : 

 

AtributoCategoríaPropósitoCriterio de Selección
Next HopWell-known Mandatory

Indica la dirección IP del siguiente salto para alcanzar el destino.

Debe ser alcanzable.

AS PathWell-known Mandatory

Lista de los AS que ha atravesado el prefijo para evitar bucles.

El camino más corto gana.

OriginWell-known Mandatory

Define el origen de la ruta (IGP, EGP o Incomplete).

IGP es preferido sobre Incomplete.

Local PreferenceWell-known Discretionary

Define la prioridad de salida dentro de un mismo AS.

El valor más alto gana.

Atomic AggregateWell-known Discretionary

Informa si el prefijo ha sido resumido o agregado.

Informativo.

AggregatorOptional Transitive

Contiene el ID y el AS del router que realizó la agregación.

Informativo.

CommunityOptional Transitive

Etiqueta para agrupar rutas y aplicar políticas comunes.

Basado en política.

MEDOptional 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íaComandoUtilidad Técnica
Resumen Generalshow bgp summaryVer estado de las sesiones (Establ, Active, Idle), AS vecinos y conteo de rutas.
Vecino Específicoshow bgp neighbor 10.1.2.2Ver detalles de la sesión, capacidades negociadas, timers y errores de hold-time.
Rutas Recibidasshow route receive-protocol bgp 10.1.2.2Ver qué te envía el vecino antes de que tus políticas de importación las filtren.
Rutas Anunciadasshow route advertising-protocol bgp 10.1.2.2Ver qué le estás enviando tú al vecino (vital para validar tus políticas de export).
Tabla de Rutasshow route protocol bgpVer todas las rutas BGP que ya fueron aceptadas e instaladas en la tabla inet.0.
Rutas Ocultasshow route hiddenVer rutas rechazadas por políticas o con Next-Hop inalcanzable (común en iBGP).
Detalle de Rutashow route 8.8.8.8 detailVer atributos completos: Local Pref, AS-Path, MED, Comunidades y por qué fue elegida.
Prueba de Origenping 8.8.8.8 source 192.168.10.1Validar 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íaComandoPropó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 Descarteshow route receive-protocol bgp [IP] hiddenCRÍTICO: Ver rutas rechazadas por políticas o por Next-Hop inalcanzable.
Análisis de Descarte (Detalle)show route receive-protocol bgp [IP] hidden detailTe 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 Detalladashow route advertising-protocol bgp [IP] detailVer el AS-Path exacto y las comunidades BGP aplicadas antes de salir.
Proceso de Selecciónshow route [Prefijo] detailVer el historial de la ruta y por qué BGP eligió (o no) ese camino.
Algoritmo de Decisiónshow route [Prefijo] best-pathDesglose paso a paso del algoritmo de selección de BGP para ese prefijo.
Salud de la Sesiónshow bgp neighbor [IP] extensiveVer capacidades negociadas (4-byte AS, Route Refresh) y contadores de error.
Inestabilidad (Flapping)show bgp neighbor [IP] flap-statisticsVer si el vecino está sufriendo de "Route Dampening" por cortes constantes.
Estadísticas de Mensajesshow bgp statisticsVer el volumen de mensajes UPDATE/KEEPALIVE. Útil para medir carga en el CPU.
Rutas Huérfanasshow route resolution unresolvedBuscar rutas BGP que no tienen salida porque el IGP (OSPF/Static) no llega al Next-Hop.
Filtro por Regexshow route aspath-regex "[Regex]"Buscar rutas que pasan por un AS específico (ej: ".* 15169" para Google).
Filtro por Comunidadshow route community [ID]Ver todas las rutas marcadas con una etiqueta de tráfico específica.
Rutas Dual-Stackshow route table inet6.0 protocol bgpVerificación exclusiva de rutas IPv6 aprendidas por BGP.
Limpieza Silenciosa (In)clear bgp neighbor [IP] soft-inRe-procesar políticas de entrada sin tirar la sesión (Soft Reconfiguration).
Limpieza Silenciosa (Out)clear bgp neighbor [IP] softRe-anunciar rutas con nuevos atributos (ej: cambiar el MED) sin corte de tráfico.
Sostenibilidad (Stale)show route protocol bgp staleVer rutas que permanecen activas durante un reinicio (Graceful Restart).
Uso de Memoriashow task statisticsVer cuánto recurso consume el proceso rpd (Routing Protocol Daemon).
Resumen por Gruposhow bgp summary group [Nombre]Filtrar vecinos por grupos (ej: Clientes, Tránsitos, Peerings).
Estado de Sesiones`show bgp summaryexcept Est`

 

Orden de revision de atributos: 

 

OrdenAtributoRegla de Decisión
1Next-hop ReachabilitySi el Next-hop no es alcanzable vía IGP/Estática, la ruta se ignora.
2Local PreferenceEl valor más alto gana. (Es lo primero que mira el router).
3AS-Path LengthEl camino más corto gana (menos saltos de AS).
4OriginPreferencia: IGP < EGP < Incomplete.
5MEDEl valor más bajo gana. (Solo se compara si el AS vecino es el mismo).
6Peer TypePreferencia: eBGP sobre iBGP.
7IGP MetricEl camino con el costo IGP más bajo hacia el Next-Hop de BGP.
8Router IDSi todo lo anterior empata, gana el vecino con el Router ID más bajo.
9Cluster List(Para Route Reflectors) Gana la lista más corta.
10Peer AddressEl último recurso: gana el vecino con la dirección IP más baja.

 

  

 

No hay comentarios:

Publicar un comentario

  ¡Bienvenido/a Si estás aquí, es porque las redes, los cables, los routers y las configuraciones ya no son un misterio… o quizá justo lo ...