En un mundo cada vez más interconectado, el protocolo BGP (Border

Gateway Protocol) se erige como la columna vertebral de Internet,

permitiendo el enrutamiento eficiente y robusto entre los diversos sistemas
autónomos. Cuando hablamos de la implementación de BGP en entornos de
proveedores de servicios, la tecnología Nokia, con su línea de Service
Routers (SR), ofrece una plataforma robusta y rica en funcionalidades que
se ha convertido en un pilar para la construcción de redes IP/MPLS
modernas.

Este capítulo, "BGP en Nokia Service Routers: Guía de Consulta para

Diseñadores e Integradores", está concebido como un recurso integral
para profesionales que se enfrentan al diseño, implementación y operación
de soluciones BGP sobre equipos Nokia SR. Desde los fundamentos teóricos
del protocolo hasta las configuraciones avanzadas y las mejores prácticas
operacionales, este material busca ser una obra de consulta indispensable
para garantizar la ejecución exitosa de proyectos.

1. Introducción al Protocolo BGP

1.1. ¿Qué es BGP?

El Border Gateway Protocol (BGP) es el protocolo de enrutamiento

exterior estándar de Internet. A diferencia de los protocolos de pasarela
interior (IGP) como OSPF o IS-IS, que operan dentro de un único dominio
administrativo (un Sistema Autónomo o AS), BGP se encarga de intercambiar
información de enrutamiento entre diferentes AS. Su propósito principal es
permitir que las redes de diferentes organizaciones (ISPs, grandes empresas,
universidades) intercambien información de rutas para alcanzar destinos en
Internet.

Imagina Internet como un conjunto de ciudades interconectadas. Cada

ciudad es un Sistema Autónomo, y dentro de cada ciudad hay calles y
direcciones internas (manejadas por un IGP). BGP es el sistema de
señalización que permite a estas ciudades saber cómo llegar a otras
ciudades, informando sobre las mejores rutas para enviar el tráfico entre
ellas.

1.2. Conceptos Fundamentales de BGP

Para comprender BGP, es crucial familiarizarse con los siguientes términos:

 Sistema Autónomo (AS): Una colección de prefijos IP conectados
que tienen una política de enrutamiento única y bien definida,
administrada por una sola entidad o grupo de entidades. Cada AS es
identificado por un número de AS (AS-number), que puede ser público
(asignado por IANA y RIRs, en el rango 1-64495 y 65536-4294967294
para 32 bits) o privado (64512-65534 para 16 bits y 4200000000-
4294967294 para 32 bits, no anunciables en Internet).

 Speaker BGP: Un router que está ejecutando el proceso BGP y

participando en el intercambio de información de rutas.

 Peers BGP (Neighbors): Son dos routers BGP que establecen una
sesión TCP (puerto 179) para intercambiar información de
enrutamiento. Una vez establecida la sesión, se consideran "vecinos".

 Actualizaciones BGP: Son los mensajes que los routers BGP utilizan
para intercambiar información sobre rutas. Estos mensajes incluyen
prefijos de red, sus longitudes y una serie de atributos BGP que
describen la ruta y guían el proceso de selección de la mejor ruta.

 Tabla de Enrutamiento BGP (RIB): Los routers BGP mantienen

varias tablas para procesar la información de enrutamiento:

o Adj-RIB-In: Contiene las rutas BGP sin procesar que han sido
recibidas de un vecino.

o Loc-RIB: Contiene las rutas que BGP ha seleccionado como las

mejores rutas para cada destino. Estas rutas son candidatas para
ser instaladas en la tabla de reenvío global (FIB) del router.

o Adj-RIB-Out: Contiene las rutas que un router BGP ha elegido

anunciar a un vecino específico, después de aplicar las políticas
de exportación.

 Estado de las Sesiones BGP: Una sesión BGP pasa por varios
estados durante su establecimiento y operación:

o Idle: El router está esperando el inicio de la sesión.

o Connect: Se ha iniciado la conexión TCP, esperando

completarse.

o Active: La conexión TCP falló y el router está reintentando.

o OpenSent: Se ha enviado un mensaje OPEN al vecino.

 o OpenConfirm: Se ha recibido un mensaje OPEN del vecino y se
ha enviado un KEEPALIVE.

o Established: La sesión BGP está completamente operativa y los

routers están intercambiando rutas.

1.3. Tipos de BGP

Hay dos tipos principales de sesiones BGP, clasificadas por la relación entre
los AS:

 eBGP (External BGP): Las sesiones eBGP se establecen entre routers

BGP que pertenecen a diferentes Sistemas Autónomos. Estas
sesiones son fundamentales para el intercambio de rutas entre
proveedores de servicios o entre un cliente y su ISP. Por defecto, eBGP
requiere que los routers estén directamente conectados o que se use
el comando disable-connected-check o multihop para vecinos no
directamente conectados (lo cual no es una buena práctica a menos
que sea estrictamente necesario para un propósito específico como un
loopback de interconexión).

 iBGP (Internal BGP): Las sesiones iBGP se establecen entre routers

BGP que pertenecen al mismo Sistema Autónomo. El objetivo de iBGP
es garantizar que todos los routers BGP dentro de un AS tengan una
vista consistente de todas las rutas externas. La regla fundamental de
iBGP es que las rutas aprendidas de un vecino iBGP no se anuncian a
otros vecinos iBGP (split-horizon), lo que tradicionalmente requiere
una malla completa (full mesh) de sesiones iBGP entre todos los
routers BGP dentro del AS para asegurar la propagación completa de
rutas. Para mitigar la complejidad del full mesh, se usan soluciones
como Route Reflectors y Confederaciones.

 MBGP (Multiprotocol BGP): Es una extensión de BGP (RFC 4760)

que permite a BGP transportar información de enrutamiento para
múltiples protocolos de capa de red (Network Layer Reachability
Information o NLRI) más allá de IPv4 unicast. Esto es esencial para
servicios modernos como:

o IPv6: Enrutamiento de prefijos IPv6.

o VPNv4 y VPNv6: Para señalizar las rutas de los servicios MPLS

L3VPN (VPRN en Nokia).
 o EVPN: Para señalizar información de enrutamiento y reenvío de
servicios Ethernet VPN (VPLS en Nokia).

1.4. Atributos BGP

Los atributos BGP son un conjunto de parámetros asociados a cada ruta

que proporcionan información crucial para el proceso de selección de la
mejor ruta y para la aplicación de políticas de enrutamiento. BGP utiliza
estos atributos para determinar la "calidad" o "preferencia" de una ruta y
para influir en cómo se anuncia o se selecciona.

Los atributos se clasifican en:

 Well-Known Mandatory: Deben ser reconocidos por todos los

implementadores de BGP y deben estar presentes en cada
actualización. Ej: ORIGIN, AS_PATH, NEXT_HOP.

 Well-Known Discretionary: Deben ser reconocidos por todos, pero

no necesariamente presentes. Ej: LOCAL_PREF, ATOMIC_AGGREGATE.

 Optional Transitive: No todos los implementadores necesitan

reconocerlos, pero si un BGP Speaker los reconoce, deben ser pasados
a otros BGP Speakers. Ej: COMMUNITY, AGGREGATOR.

 Optional Non-Transitive: No es necesario que todos los

implementadores los reconozcan y no deben ser pasados a otros BGP
Speakers. Ej: MED, ORIGINATOR_ID, CLUSTER_LIST.

Lista detallada de atributos clave y su función:

1. AS_PATH: Es una secuencia de números de AS a través de los cuales

la ruta ha transitado. Es fundamental para la prevención de bucles (si
un AS ve su propio número en el AS_PATH, descarta la ruta) y para la
selección de rutas (rutas con AS_PATH más corto son generalmente
preferidas).

2. NEXT_HOP: La dirección IP del router del siguiente salto que se debe

usar para reenviar el tráfico al destino de la ruta BGP. Para eBGP, suele
ser la IP del vecino. Para iBGP, el next-hop-self puede ser configurado
para que el propio router BGP sea el siguiente salto.

3. MED (Multi-Exit Discriminator): Un valor numérico que un AS utiliza

para indicar a un AS vecino la preferencia por un punto de entrada
cuando hay múltiples enlaces de interconexión. Un MED más bajo es
 preferido. Este atributo solo se intercambia entre vecinos eBGP y no se
propaga entre iBGP.

4. LOCAL_PREF: Indica el grado de preferencia de una ruta dentro de un

AS. Es un atributo Well-Known Discretionary y solo se utiliza
internamente (iBGP). Un LOCAL_PREF más alto es preferido. Permite a
un AS controlar su tráfico de salida.

5. ORIGIN: Indica cómo se originó la ruta en el AS de origen. Puede ser:

o IGP (i): Ruta aprendida de un IGP y redistribuida en BGP (más

preferido).

o EGP (e): Ruta aprendida de un antiguo protocolo EGP (obsoleto).

o Incomplete (?): Ruta de origen desconocido o aprendida por

otros medios (menos preferido, por ejemplo, rutas agregadas sin
la opción as-set).

6. ATOMIC_AGGREGATE: Un atributo Well-Known Discretionary que se

establece cuando una ruta ha sido agregada, indicando que la
información de las rutas individuales (menos específicas) que
componen la agregación se ha perdido.

7. AGGREGATOR: Un atributo Optional Transitive que indica la dirección

IP y el número de AS del router que realizó la agregación.

8. COMMUNITY: Un atributo Optional Transitive que permite a los

operadores de red etiquetar rutas con valores numéricos para aplicar
políticas de forma más flexible. Es muy usado para la ingeniería de
tráfico y para comunicar información de políticas entre AS. Ejemplos
comunes: no exportar, no anunciar, anunciar solo a clientes.

9. EXTENDED COMMUNITY: Una extensión del atributo COMMUNITY

(RFC 4360) que proporciona un espacio de valores más grande (8
bytes) y permite definir tipos de comunidades para propósitos
específicos, como los Route Targets (RTs) en MPLS VPNs.

10. CLUSTER_LIST: Usado en arquitecturas de Route Reflector para

prevenir bucles de enrutamiento. Contiene una lista de los Cluster IDs
a través de los cuales ha pasado una ruta reflejada.

11. ORIGINATOR_ID: Un atributo Optional Non-Transitive que un

Route Reflector inserta en las rutas que refleja. Contiene el Router ID
 del router que originalmente inyectó la ruta en el AS. Ayuda a prevenir
bucles de enrutamiento en entornos de Route Reflector.

Proceso de Selección de Ruta BGP (Algoritmo de Nokia SR):

Cuando un router BGP recibe múltiples rutas para el mismo prefijo, sigue un
algoritmo estricto para seleccionar la mejor ruta. El orden de preferencia en
Nokia SR (y la mayoría de las implementaciones BGP) es el siguiente (de
mayor a menor preferencia):

1. Preferir rutas con el NEXT_HOP accesible. Si el siguiente salto no

es resoluble en la tabla de enrutamiento, la ruta se descarta.

2. Preferir la ruta con el LOCAL_PREF más alto. (Se aplica solo a

rutas iBGP).

3. Preferir rutas con el AS_PATH más corto. (Contando los AS en el

Path).

4. Preferir la ruta con el ORIGIN más bajo. (IGP (i) < EGP (e) <
Incomplete (?)).

5. Preferir la ruta con el MED más bajo. (Solo se compara entre rutas
aprendidas del mismo AS vecino).

6. Preferir la ruta aprendida de un vecino eBGP sobre una ruta

aprendida de un vecino iBGP. (Si es una ruta externa).

7. Preferir la ruta interna (iBGP) que tiene el costo IGP más bajo
al NEXT_HOP de BGP. (Solo para rutas iBGP).

8. Preferir la ruta de un Route Reflector con el CLUSTER_LIST más

corto. (Para evitar bucles en RR).

9. Preferir la ruta con el ORIGINATOR_ID más bajo. (Si el

ORIGINATOR_ID está presente).

10. Preferir la ruta recibida del vecino BGP con el Router ID

más bajo. (Este es el desempate final).

11. Preferir la ruta con la dirección IP de neighbor BGP más

baja. (Si los Router IDs son iguales, o para desempates finales).

2. Implementación de BGP en Nokia Service Routers

2.1. Arquitectura de Nokia Service Routers para BGP

Los Nokia Service Routers (SR), que operan con el Sistema Operativo
(SR OS), están diseñados para redes de proveedores de servicios de alto
rendimiento. Su arquitectura proporciona una base sólida para la
implementación de BGP:

 SR OS: Es un sistema operativo robusto que ofrece un soporte integral

para BGP, incluyendo todas las extensiones modernas (MBGP, Route
Reflectors, políticas avanzadas).

 Módulos de Red y Procesamiento: Los SRs están construidos con

hardware de alto rendimiento, incluyendo NPUs (Network Processor
Units) y CPUS potentes, lo que permite un procesamiento eficiente de
las tablas BGP masivas y un rendimiento de reenvío de paquetes
elevado.

 Separación de planos de control y datos: Los SRs implementan

una estricta separación entre el plano de control (donde reside BGP,
ejecutado en la CPU) y el plano de datos (donde ocurre el reenvío de
paquetes, ejecutado en el hardware). Esto asegura que los cambios en
las rutas BGP o un alto volumen de actualizaciones no afecten el
reenvío de tráfico, manteniendo la estabilidad de la red.

2.2. Configuración Básica de BGP en Nokia SR

La configuración de BGP en Nokia SR OS se realiza bajo el contexto del router

(o VPRN/VPLS).

Fragmento de código

A:dut-1# configure router bgp

A:dut-1>config>router>bgp#

Creación de grupos de vecinos (group <group-name>):

Los grupos permiten aplicar políticas y configuraciones comunes a un

conjunto de vecinos BGP, simplificando la administración.

Fragmento de código

A:dut-1>config>router>bgp# group ebgp-provider-a

A:dut-1>config>router>bgp>group# type ebgp

A:dut-1>config>router>bgp>group# local-as 65001

A:dut-1>config>router>bgp>group# peer-as 10001

A:dut-1>config>router>bgp>group# description "eBGP peering with

Provider A"

A:dut-1>config>router>bgp>group# family ipv4

A:dut-1>config>router>bgp>group# exit

A:dut-1>config>router>bgp# group ibgp-core

A:dut-1>config>router>bgp>group# type ibgp

A:dut-1>config>router>bgp>group# local-as 65001

A:dut-1>config>router>bgp>group# description "iBGP peering with Core

Routers"

A:dut-1>config>router>bgp>group# next-hop-self

A:dut-1>config>router>bgp>group# route-reflector-client

A:dut-1>config>router>bgp>group# family ipv4

A:dut-1>config>router>bgp>group# exit

Configuración de vecinos específicos (neighbor <ip-address>):

Dentro de un grupo, se definen los vecinos individuales.

Fragmento de código

A:dut-1>config>router>bgp# group ebgp-provider-a

A:dut-1>config>router>bgp>group# neighbor 192.0.2.1

A:dut-1>config>router>bgp>group>neighbor# description "Provider A Link

1"

A:dut-1>config>router>bgp>group>neighbor# authentication-key
"SuperSecureKey123" md5

A:dut-1>config>router>bgp>group>neighbor# hold-time 90 keep-alive 30

A:dut-1>config>router>bgp>group>neighbor# local-address 192.0.2.2

A:dut-1>config>router>bgp>group>neighbor# import
"IMPORT_PROVIDER_A"
A:dut-1>config>router>bgp>group>neighbor# export
"EXPORT_OUR_ROUTES"

A:dut-1>config>router>bgp>group>neighbor# max-routes 10000 warning-

threshold 80

A:dut-1>config>router>bgp>group>neighbor# bfd enable

A:dut-1>config>router>bgp>group>neighbor# exit

A:dut-1>config>router>bgp>group# exit

A:dut-1>config>router>bgp# group ibgp-core

A:dut-1>config>router>bgp>group# neighbor 10.0.0.1

A:dut-1>config>router>bgp>group>neighbor# description "Core Router 1"

A:dut-1>config>router>bgp>group>neighbor# local-address 10.0.0.254

(Loopback)

A:dut-1>config>router>bgp>group>neighbor# no shutdown

A:dut-1>config>router>bgp>group>neighbor# exit

A:dut-1>config>router>bgp>group# exit

Parámetros clave de vecinos:

 authentication-key md5: Configura la autenticación MD5 para la

sesión TCP BGP, aumentando la seguridad.

 hold-time / keep-alive: Controlan los temporizadores de la sesión

BGP. El hold-time es el tiempo máximo que un router esperará un
mensaje KEEPALIVE o UPDATE de su vecino antes de declarar la sesión
caída. keep-alive es la frecuencia de envío de mensajes KEEPALIVE.

 local-address: Especifica la dirección IP de origen que el router usará

para establecer la sesión BGP. Es crucial para iBGP usar direcciones de
loopback para resiliencia.

 next-hop-self: Un comando crucial para iBGP. Por defecto, eBGP no

modifica el NEXT_HOP de una ruta. Si una ruta eBGP se anuncia a un
vecino iBGP, el NEXT_HOP original (que probablemente es una IP
directamente conectada del AS vecino) permanece. next-hop-self
cambia el NEXT_HOP al propio router BGP que anuncia la ruta. Esto es
 vital para asegurar que el siguiente salto sea alcanzable dentro del AS
vía IGP.

 route-reflector-client: Designa al vecino como cliente de Route

Reflector. Más detalles en la sección de diseño avanzado.

 import / export: Se utilizan para aplicar políticas de enrutamiento

(definidas en policy-options) a las rutas entrantes (import) y salientes
(export) de la sesión BGP.

 max-routes: Limita el número de prefijos que un vecino puede

anunciar, previniendo ataques o errores de configuración masivos.

 soft-reconfiguration: Permite al router mantener una copia de todas

las rutas BGP sin procesar (Adj-RIB-In) de un vecino. Esto facilita el
"soft reset" (clear router bgp soft), permitiendo reevaluar las políticas
de importación sin restablecer la sesión BGP. Sin embargo, consume
más memoria.

 bfd enable: Habilita Bidirectional Forwarding Detection (BFD) para la

sesión BGP. BFD proporciona una detección de fallos de enlace mucho
más rápida que los temporizadores BGP por sí solos, mejorando
drásticamente la convergencia.

2.3. Configuración de Familias de Direcciones (Address Families)

Nokia SR OS soporta la configuración de múltiples familias de direcciones

bajo BGP, permitiendo que un único proceso BGP maneje diferentes tipos de
información de enrutamiento:

 family ipv4 / family ipv6: Se usan para el enrutamiento unicast de

prefijos IPv4 y IPv6 globales en la tabla de enrutamiento principal.

Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# family ipv4

A:dut-1>config>router>bgp>group>neighbor# family ipv6

A:dut-1>config>router>bgp>group>neighbor# exit

 family vpn-ipv4 / family vpn-ipv6: Se utilizan para las rutas VPNv4

y VPNv6 en el contexto de los servicios MPLS Layer 3 VPN (VPRN).
Estas familias de direcciones permiten a BGP señalizar las rutas de los
clientes entre los PEs (Provider Edge) de la red MPLS.
Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# family vpn-ipv4

A:dut-1>config>router>bgp>group>neighbor# family vpn-ipv6

A:dut-1>config>router>bgp>group>neighbor# exit

 family evpn: Es fundamental para los servicios Ethernet VPN

(EVPN), que permiten extender dominios de capa 2 sobre una
infraestructura MPLS o IP. Esta familia se usa para señalizar MAC/IPs y
rutas Ethernet Segment Identifier (ESI) entre los PEs.

Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# family evpn

A:dut-1>config>router>bgp>group>neighbor# exit

2.4. Redistribución de Rutas en BGP

La redistribución de rutas en BGP, tanto hacia adentro como hacia afuera, es

un aspecto crítico que requiere un diseño cuidadoso para evitar problemas
de ruteo y bucles.

 export policy: Controla qué rutas de la tabla de enrutamiento global

del router (Loc-RIB o rutas aprendidas de otros protocolos/interfaces)
se anuncian a los vecinos BGP. Se aplica en el comando export <policy-
name> a nivel de grupo o vecino BGP.

 import policy: Controla qué rutas aprendidas de un vecino BGP (Adj-

RIB-In) se aceptan y se instalan en la tabla de enrutamiento BGP (Loc-
RIB) del router. Se aplica en el comando import <policy-name> a nivel
de grupo o vecino BGP.

Precaución con la redistribución:

 Evitar Loops: Es fundamental filtrar y manipular cuidadosamente las

rutas redistribuidas para evitar la creación de bucles de enrutamiento,
especialmente entre BGP e IGPs.

 Ruteo Subóptimo: Una mala configuración de redistribución puede

llevar a que el tráfico tome rutas ineficientes.
  Inflación de la Tabla de Enrutamiento: Redistribuir
indiscriminadamente un gran número de rutas IGP en BGP puede
sobrecargar la tabla BGP y consumir recursos del router.

Uso de route-maps (policy options):

En Nokia SR OS, las políticas de enrutamiento se construyen utilizando

policy-options. Estas políticas son esencialmente "route-maps" que
permiten filtrar y modificar atributos de ruta. Veremos más detalles en la
Sección 3.5.

3. Diseño de Soluciones BGP Avanzadas con Nokia SR

3.1. Escalabilidad de iBGP: Route Reflectors

La limitación de la malla completa (full mesh) en iBGP se vuelve inviable en

redes grandes. Una malla completa de N routers requiere $N \* (N-1) / 2$
sesiones BGP, lo que genera una complejidad de configuración y gestión
insostenible.

 Necesidad de Route Reflectors (RR): Los RRs son la solución

estándar para escalar iBGP. Permiten que los routers BGP se organicen
en clusters, donde solo algunos routers (los RRs) tienen sesiones iBGP
con todos los demás routers del cluster (clientes y no-clientes),
reduciendo drásticamente el número de sesiones requeridas.

 Funcionamiento de Route Reflectors:

o Un router BGP puede configurarse como Route Reflector.

o Los vecinos de un RR se dividen en clientes y non-clients.

o Una ruta aprendida de un cliente se refleja a todos los demás

clientes y a los non-clients.

o Una ruta aprendida de un non-client se refleja solo a los clientes

(no a otros non-clients).

o Una ruta aprendida de un eBGP peer se refleja a todos los

clientes y non-clients.

o Para prevenir bucles, BGP introduce los atributos

ORIGINATOR_ID y CLUSTER_LIST.
  Configuración en Nokia SR: En el grupo BGP o a nivel de vecino, se
usa el comando route-reflector-client. También se puede definir un
cluster-id para el RR si no se quiere usar el Router ID por defecto.

Fragmento de código

A:dut-1>config>router>bgp# group ibgp-rr-clients

A:dut-1>config>router>bgp>group# type ibgp

A:dut-1>config>router>bgp>group# local-as 65001

A:dut-1>config>router>bgp>group# route-reflector-client

A:dut-1>config>router>bgp>group# cluster-id 1.1.1.1

A:dut-1>config>router>bgp>group# exit

 Consideraciones de diseño:

o Ubicación de RRs: Se recomienda que los RRs sean routers

estables y con alta disponibilidad en el core de la red.

o Redundancia: Es crucial tener al menos dos RRs por cluster

para redundancia. Los clientes pueden tener sesiones con
múltiples RRs.

o Impacto en la selección de ruta: El uso de RRs puede afectar

el atributo NEXT_HOP y el ORIGINATOR_ID/CLUSTER_LIST en el
proceso de selección de ruta.

3.2. Confederaciones BGP

Las confederaciones BGP son otra técnica para escalar iBGP, menos
común que los Route Reflectors, pero útil en AS extremadamente grandes.

 Propósito: Una confederación divide un gran Sistema Autónomo en

múltiples Sub-AS (o confederation member-AS), cada uno con su propio
número de AS privado. Dentro de cada Sub-AS, se sigue requiriendo
una malla completa de iBGP (o Route Reflectors). Sin embargo, las
sesiones entre Sub-AS se comportan como eBGP (aunque utilizan el
mismo número de AS externo de la confederación), lo que reduce la
necesidad de sesiones iBGP de malla completa a través de todo el AS
principal.

 Funcionamiento:
 o Se define un confederation-id que es el AS-number público del
AS principal.

o Los Sub-AS se configuran con sus propios AS-numbers privados y

también con el confederation-id.

o Las rutas intercambiadas entre Sub-AS tienen un AS_PATH

especial que incluye los AS-numbers privados, pero estos se
eliminan antes de anunciar las rutas al mundo exterior,
preservando el AS-number público original.

 Configuración en Nokia SR:

Fragmento de código

A:dut-1>config>router>bgp# confederation

A:dut-1>config>router>bgp>confederation# confederation-id 65001

A:dut-1>config>router>bgp>confederation# member-as 65100 65101

A:dut-1>config>router>bgp>confederation# exit

 Ventajas y desventajas: Reduce la complejidad del iBGP full-mesh

en AS masivos. Sin embargo, añade una capa de complejidad de
diseño y operación, y puede impactar la visibilidad de la topología
interna.

3.3. BGP y MPLS VPN (MPLS L3VPN, L2VPN, EVPN)

BGP juega un papel fundamental en la señalización de rutas para diversos

servicios MPLS VPN, permitiendo a los proveedores de servicios ofrecer
conectividad a clientes sobre una infraestructura MPLS común.

 BGP como señalizador de VPN: MBGP (Multiprotocol BGP) se utiliza

para distribuir información de enrutamiento para las VPNs. En lugar de
rutas IPv4/IPv6 estándar, BGP transporta NLRI específicos de VPN.

 Concepto de Route Distinguisher (RD) y Route Target (RT):

o Route Distinguisher (RD): Es un prefijo de 8 bytes

(ASN:number o IP:number) que se antepone a un prefijo IPv4 o
IPv6 del cliente para crear un prefijo VPNv4 o VPNv6 único
globalmente. Esto permite que diferentes clientes usen los
 mismos prefijos IP sin conflictos dentro del backbone del
proveedor. Cada VPRN (VRF) tiene un RD.

o Route Target (RT): Son comunidades extendidas que controlan

la importación y exportación de rutas VPN entre diferentes
VPRNs. Un router PE exporta rutas VPN con RTs específicos y solo
importa rutas VPN que tienen RTs que coinciden con los que está
configurado para importar. Esto permite construir topologías de
VPN complejas (hub-and-spoke, full-mesh).

 Configuración de familias VPN en Nokia SR:

o family vpn-ipv4 / family vpn-ipv6: Se habilitan en las

sesiones iBGP (generalmente entre PEs y RRs) para transportar
las rutas VPNv4/VPNv6.

o family evpn: Habilitada en iBGP para el transporte de

información EVPN (MAC/IPs y ESI) en servicios VPLS.

 Integración con VPRN y VPLS:

o Las rutas BGP de cliente se configuran dentro del contexto de un

VPRN (Virtual Private Routing Network), que es la
implementación de un VRF (Virtual Routing and Forwarding) en
Nokia.

Fragmento de código

A:dut-1# configure service vprn 100 customer "Customer A"

A:dut-1>config>service>vprn# route-distinguisher 65001:100

A:dut-1>config>service>vprn# vrf-target target:65001:100

A:dut-1>config>service>vprn# autodiscover bgp

A:dut-1>config>service>vprn# exit

A:dut-1>config>service>vprn# router bgp

A:dut-1>config>service>vprn>router>bgp# group ibgp-peering

A:dut-1>config>service>vprn>router>bgp>group# type ibgp

A:dut-1>config>service>vprn>router>bgp>group# family vpn-ipv4

A:dut-1>config>service>vprn>router>bgp>group# exit
 o Para EVPN, se asocia el BGP-EVPN a un VPLS (Virtual Private
LAN Service).

Fragmento de código

A:dut-1# configure service vpls 200 customer "Customer B"

A:dut-1>config>service>vpls# bgp-evpn

A:dut-1>config>service>vpls>bgp-evpn# route-distinguisher 65001:200

A:dut-1>config>service>vpls>bgp-evpn# vrf-target target:65001:200

A:dut-1>config>service>vpls>bgp-evpn# exit

3.4. BGP Multihoming y Redundancia

El multihoming es una práctica esencial para los proveedores de servicios y

las grandes empresas, ya que proporciona redundancia y balanceo de carga
al conectarse a Internet a través de múltiples proveedores de servicios (ISPs)
o múltiples puntos de interconexión con un solo ISP.

 Multihoming con diferentes AS: Implica establecer sesiones eBGP

con dos o más ISPs diferentes. Esto proporciona resiliencia ante fallos
de un ISP o de un enlace.

 Consideraciones de AS-Path prepending, LOCAL_PREF, MED:

Estas son las herramientas clave para influir en cómo el tráfico
entrante y saliente utiliza las múltiples conexiones de multihoming:

o AS-Path Prepending: Al anunciar sus propios prefijos, un AS

puede "engordar" su AS_PATH hacia un proveedor específico,
haciendo que esa ruta parezca menos deseable para otros AS,
influyendo así en el tráfico de entrada.

o LOCAL_PREF: Este atributo se usa internamente (iBGP) para

indicar la preferencia de rutas salientes. Un LOCAL_PREF más
alto significa una ruta más preferida. Permite que un AS controle
qué salida prefiere para el tráfico de salida.

o MED (Multi-Exit Discriminator): Se usa para influir en cómo

un AS vecino enruta el tráfico hacia su AS cuando hay múltiples
puntos de interconexión. Un MED más bajo es más preferido.
Sirve para influir en el tráfico de entrada de un vecino
específico.
  Balanceo de carga BGP:

o ECMP (Equal-Cost Multi-Path): Si BGP selecciona múltiples

rutas como "mejores" y tienen el mismo costo IGP hacia el
NEXT_HOP (para iBGP) o el mismo AS_PATH/NEXT_HOP (para
eBGP bajo ciertas condiciones), Nokia SR puede instalar múltiples
entradas en la FIB y balancear la carga entre ellas. Esto se
configura con ecmp <number> bajo el contexto BGP del router.

 BGP y BFD para convergencia rápida: La combinación de BGP con

BFD (Bidirectional Forwarding Detection) es crucial para una rápida
detección de fallos. Si un enlace de interconexión falla, BFD detectará
el fallo en milisegundos y notificará a BGP, permitiendo una re-
convergencia casi instantánea del tráfico a través de la ruta
alternativa.

3.5. Filtrado y Manipulación de Atributos BGP (Policy Options)

Las políticas de enrutamiento son el corazón de la ingeniería de tráfico

BGP. En Nokia SR OS, se implementan bajo el contexto config>router>policy-
options. Permiten un control granular sobre qué rutas se aceptan, cuáles se
anuncian y cómo se modifican sus atributos.

 policy-options: Este es el contenedor principal para definir listas y

declaraciones de políticas.

 prefix-list: Permite definir listas de prefijos IP (IPv4 o IPv6) con sus

longitudes. Se usan para filtrar rutas basándose en su prefijo.

Fragmento de código

A:dut-1>config>router>policy-options# prefix-list MY-CUSTOMERS

A:dut-1>config>router>policy-options>prefix-list# prefix 10.0.0.0/8 exact

A:dut-1>config>router>policy-options>prefix-list# prefix 200.1.1.0/24

longer

A:dut-1>config>router>policy-options>prefix-list# exit

 community / extended-community lists: Listas de valores de

comunidad BGP. Útiles para agrupar rutas y aplicar acciones basadas
en esas agrupaciones.

Fragmento de código
A:dut-1>config>router>policy-options# community-list NO-EXPORT-
COMMUNITY

A:dut-1>config>router>policy-options>community-list# community "no-

export"

A:dut-1>config>router>policy-options>community-list# exit

 as-path-list: Permite filtrar rutas basándose en patrones de su

AS_PATH. Útil para identificar el origen de una ruta o para aplicar
políticas a rutas que han pasado por AS específicos.

Fragmento de código

A:dut-1>config>router>policy-options# as-path-list MY-ISP-ASPATH

A:dut-1>config>router>policy-options>as-path-list# expression ".* 10001$"

A:dut-1>config>router>policy-options>as-path-list# exit

 route-map (policy statement): Es el componente central donde se

definen las reglas de filtrado y manipulación. Una policy-statement
consiste en una secuencia de entry (entradas) numeradas, que se
procesan en orden. Cada entry tiene:

o from clause: Define las condiciones de coincidencia (qué rutas

queremos que coincidan). Se pueden usar prefix-list, community-
list, as-path-list, protocol, etc.

o to clause: Define las condiciones de destino (dónde se aplicará

la política, útil en políticas más complejas).

o action: accept (aceptar la ruta y seguir con la siguiente entrada

o aplicar acciones) o reject (descartar la ruta).

o set clause: Permite modificar los atributos BGP de la ruta que

coincide.

 set local-pref <value>

 set med <value>

 set as-path prepend <asn1> <asn2>...

 set community <value> / set community add <value> /

set community delete <value>

 set next-hop <ip-address> / set next-hop self

  set origin <igp|egp|incomplete>

Ejemplo de una política de exportación:

Fragmento de código

A:dut-1>config>router>policy-options# begin

A:dut-1>config>router>policy-options# policy-statement
EXPORT_OUR_ROUTES

A:dut-1>config>router>policy-options>policy-statement# entry 10

A:dut-1>config>router>policy-options>policy-statement>entry# from

A:dut-1>config>router>policy-options>policy-statement>entry>from#
prefix-list "OUR-PREFIXES"

A:dut-1>config>router>policy-options>policy-statement>entry>from# exit

A:dut-1>config>router>policy-options>policy-statement>entry# action
accept

A:dut-1>config>router>policy-options>policy-statement>entry>action# set

A:dut-1>config>router>policy-options>policy-
statement>entry>action>set# med 100

A:dut-1>config>router>policy-options>policy-
statement>entry>action>set# as-path prepend "65001"

A:dut-1>config>router>policy-options>policy-
statement>entry>action>set# exit

A:dut-1>config>router>policy-options>policy-statement>entry>action# exit

A:dut-1>config>router>policy-options>policy-statement>entry# exit

A:dut-1>config>router>policy-options>policy-statement# entry 20

A:dut-1>config>router>policy-options>policy-statement>entry# action
reject

A:dut-1>config>router>policy-options>policy-statement>entry# exit

A:dut-1>config>router>policy-options# commit

Aplicación de políticas:
Las políticas se aplican a nivel de grupo o vecino BGP usando los comandos
import y export:

Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# import
"IMPORT_PROVIDER_A"

A:dut-1>config>router>bgp>group>neighbor# export
"EXPORT_OUR_ROUTES"

4. Operación y Troubleshooting de BGP en Nokia SR

Dominar los comandos de verificación y depuración es crucial para la

operación diaria y la resolución de problemas de BGP en Nokia SR.

4.1. Comandos de Verificación BGP

 show router bgp summary: Proporciona un resumen rápido del

estado de todas las sesiones BGP (establecidas, inactivas, etc.), el
número de prefijos recibidos y anunciados.

Fragmento de código

A:dut-1# show router bgp summary

 show router bgp neighbor <ip-address> detail: Muestra

información detallada sobre un vecino BGP específico, incluyendo
temporizadores, capacidades negociadas, rutas recibidas/enviadas, y
estado de la sesión.

Fragmento de código

A:dut-1# show router bgp neighbor 192.0.2.1 detail

 show router bgp routes: Muestra todas las rutas en la tabla BGP
(Loc-RIB) del router. Se pueden aplicar filtros.

Fragmento de código

A:dut-1# show router bgp routes

A:dut-1# show router bgp routes active (solo rutas seleccionadas como
mejores)

A:dut-1# show router bgp routes family ipv6

  show router bgp routes <prefix>/<length>: Muestra los detalles
de las rutas BGP para un prefijo específico, incluyendo todos los
atributos y de qué vecino se aprendió.

Fragmento de código

A:dut-1# show router bgp routes 198.51.100.0/24

 show router bgp routes received-routes: Muestra las rutas tal

como se recibieron de un vecino específico antes de que se apliquen
las políticas de importación. Es invaluable para verificar si un vecino
está enviando las rutas esperadas.

Fragmento de código

A:dut-1# show router bgp neighbor 192.0.2.1 received-routes

 show router bgp routes advertised-routes: Muestra las rutas que

el router está anunciando a un vecino específico después de aplicar
las políticas de exportación. Útil para verificar lo que se está enviando.

Fragmento de código

A:dut-1# show router bgp neighbor 192.0.2.1 advertised-routes

 show router bgp group <group-name>: Muestra la configuración y

estado de un grupo BGP.

Fragmento de código

A:dut-1# show router bgp group ebgp-provider-a

 show router bgp policy: Muestra las políticas BGP (import/export)

aplicadas en el router.

Fragmento de código

A:dut-1# show router bgp policy

4.2. Comandos de Troubleshooting BGP

 debug router bgp: Habilita la depuración para eventos BGP. ¡Úsalo

con extrema precaución en entornos de producción! Puede
generar una gran cantidad de logs y afectar el rendimiento de la CPU.
Se recomienda usar filtros específicos.

Fragmento de código
A:dut-1# debug router bgp peer 192.0.2.1 events

A:dut-1# debug router bgp updates (muy verboso)

 clear router bgp neighbor <ip-address>: Restablece (cierra y

vuelve a abrir) una sesión BGP. Esto fuerza un re-envío completo de las
rutas.

Fragmento de código

A:dut-1# clear router bgp neighbor 192.0.2.1

 clear router bgp soft: Realiza un "soft reset" de una sesión BGP. Si el
vecino soporta la capacidad Route Refresh (la mayoría de los routers
modernos sí), se reevalúan las políticas de importación/exportación sin
restablecer la sesión TCP. Si el soft-reconfiguration está habilitado, el
router usa su Adj-RIB-In para reevaluar.

Fragmento de código

A:dut-1# clear router bgp neighbor 192.0.2.1 soft

 Verificación de logs del sistema: Los logs (show log log-id <id>)
pueden proporcionar mensajes importantes sobre el estado de las
sesiones BGP, errores de autenticación, problemas de conectividad,
etc.

 ping y traceroute: Utiliza estas herramientas para verificar la

conectividad de la capa IP al vecino BGP o a los destinos anunciados
por BGP.

 Análisis del proceso de selección de ruta BGP: Cuando una ruta

no se comporta como se espera (no es la mejor, no se instala), es
fundamental seguir el algoritmo de selección de ruta BGP paso a paso,
examinando todos los atributos de las rutas candidatas. Los comandos
show router bgp routes <prefix>/<length> son muy útiles aquí.

4.3. Escenarios Comunes de Troubleshooting

 Sesiones BGP en estado Idle/Active:

o Problemas de conectividad: Verificar ping al vecino.

o Configuración incorrecta de IP: local-address, peer-address.

o AS-numbers incorrectos: local-as, peer-as.

 o Autenticación MD5 fallida: Claves no coincidentes.

o Firewall o ACL bloqueando el puerto TCP 179.

o Next-hop inaccesible: Para iBGP, asegurar que la dirección de

loopback sea alcanzable vía IGP.

o Loopback interface not up/active.

 Rutas no anunciadas o no recibidas:

o Errores en las políticas de importación/exportación: Usar

show ... received-routes y show ... advertised-routes para ver si
las rutas están llegando o saliendo del router.

o Prefijo no existiendo en la tabla BGP (Loc-RIB).

o max-routes alcanzado.

o AS-Path loop prevention: Si el AS propio está en el AS_PATH.

o Next-hop inaccesible.

 Looping de tráfico:

o Inconsistencias en las políticas BGP.

o AS-Path prepending incorrecto o faltante.

o Problemas con el next-hop-self en iBGP.

 Ruteo suboptimal:

o Atributos BGP incorrectos: LOCAL_PREF, MED, AS_PATH no

configurados o manipulados correctamente para influir en el
tráfico.

o Asimetría de rutas: Tráfico de ida y vuelta por diferentes

caminos, común en multihoming.

 Problemas de convergencia:

o Temporizadores BGP altos.

o Falta de BFD.

o Problemas en el IGP subyacente que resuelve el NEXT_HOP.

4.4. Monitoreo de BGP

Un monitoreo proactivo de BGP es vital para la salud de la red.

 SNMP: Los Nokia SRs exponen MIBs BGP que pueden ser consultadas
por sistemas de monitoreo para obtener estadísticas de sesión,
número de rutas, eventos, etc.

 NetFlow/IPFIX: Aunque no es directamente para BGP, el monitoreo

de flujos puede ayudar a identificar patrones de tráfico y verificar si el
tráfico sigue las rutas BGP esperadas.

 Integración con sistemas de gestión de red (NMS): Plataformas

como Nokia NSP (Network Services Platform) o herramientas de
terceros pueden recopilar datos BGP, mostrar el estado de la red y
generar alertas.

5. Mejores Prácticas y Consideraciones de Diseño para BGP en Nokia

SR

Un diseño e implementación robustos de BGP son críticos para la estabilidad

y el rendimiento de la red de un proveedor de servicios.

5.1. Seguridad BGP

 Autenticación MD5/TCP MD5 Signature Option (RFC 2385):

Siempre configurar la autenticación MD5 en las sesiones BGP. Esto
protege contra intrusiones no autorizadas y ataques de
restablecimiento de sesiones BGP.

Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# authentication-key
"MySecretKey" md5

 GTSM (Generalized TTL Security Mechanism): (RFC 5082) Protege

las sesiones BGP contra ataques basados en TTL, como ataques DoS.
Asegura que los paquetes BGP tengan un TTL específico (generalmente
255) y descarta los paquetes con un TTL diferente. Esto asume que los
vecinos BGP están directamente conectados.

Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# ttl-security

 Prefix-list para filtrar prefijos inválidos/no autorizados: Filtrar

los prefijos IP recibidos de los vecinos para aceptar solo los que se
 esperan y rechazar los prefijos no válidos (bogons, privadas) o los que
no deberían ser anunciados por ese vecino.

 RPKI (Resource Public Key Infrastructure) / ROA (Route Origin

Authorization): Implementar o participar en RPKI y usar Route Origin
Authorizations (ROAs) para validar que un prefijo está siendo
anunciado por el AS autorizado. Aunque no es una función directa del
router, el SR puede consumir feeds de validación RPKI para filtrar
prefijos inválidos.

Fragmento de código

A:dut-1>config>router>bgp# rpki validation-state enable

A:dut-1>config>router>bgp# rpki server 192.0.2.10 port 323 refresh 60

5.2. Escalabilidad y Rendimiento

 Optimización de Route Reflectors:

o Diseñar clusters RR con redundancia (al menos dos RRs por

cluster).

o Evitar que un solo RR sea un punto de fallo.

o Distribuir los clientes BGP entre varios RRs para balancear la

carga de procesamiento.

 Uso de Soft Reconfiguration y Route Refresh Capability:

o Habilitar soft-reconfiguration si es necesario para el

troubleshooting, pero ser consciente del consumo de memoria.
Idealmente, confiar en route-refresh (habilitado por defecto) para
reevaluar políticas sin mantener Adj-RIB-In.

 Minimizar la cantidad de rutas anunciadas (agregación,

sumarización): La agregación de prefijos (resumir múltiples rutas
específicas en una ruta más general) reduce el tamaño de las tablas
BGP y el procesamiento.

Fragmento de código

A:dut-1>config>router>bgp# aggregate 192.168.0.0/16

A:dut-1>config>router>bgp>aggregate# summary-only (para anunciar solo

la agregada y suprimir las específicas)
  Consideraciones sobre el tamaño de la tabla de enrutamiento:
Los routers SR de Nokia tienen capacidades de memoria y
procesamiento significativas, pero es vital monitorear el crecimiento de
la tabla BGP para asegurar que no se excedan los límites y se afecte el
rendimiento.

 Impacto de las políticas BGP en el rendimiento de la CPU: Las

políticas de enrutamiento complejas, especialmente aquellas con
muchas entradas o expresiones regulares complejas, pueden consumir
ciclos de CPU. Diseñar políticas eficientes.

5.3. Convergencia Rápida

 BFD para BGP: Habilitar BFD en todas las sesiones BGP críticas
(especialmente eBGP). BFD es fundamental para una detección de
fallos de enlace en sub-segundos, lo que permite a BGP converger
rápidamente.

Fragmento de código

A:dut-1>config>router>bgp>group>neighbor# bfd enable

 Configuración de temporizadores BGP (hold-time, keep-alive):

Ajustar los temporizadores BGP para equilibrar la estabilidad de la
sesión con la rapidez de detección de fallos. Con BFD, los
temporizadores BGP pueden ser más relajados (ej: hold-time 90 keep-
alive 30).

 Fast Reroute (FRR) con MPLS: En redes MPLS, la implementación

de FRR (como LFA o TI-LFA) en el IGP subyacente proporciona
protección para el siguiente salto, asegurando que el tráfico se desvíe
en milisegundos incluso antes de que BGP re-conveja.

5.4. Documentación y Gestión de Cambios

 Mantener una documentación detallada de la configuración

BGP: Incluir diagramas de red, AS-numbers, políticas de enrutamiento,
justificación de las decisiones de diseño.

 Proceso de gestión de cambios riguroso para configuraciones

BGP: Dada la criticidad de BGP, cualquier cambio debe ser planificado,
 probado en un entorno de laboratorio y ejecutado con un proceso de
roll-back claro.

5.5. Diseño jerárquico de políticas BGP

 Uso de grupos BGP: Agrupar vecinos con características y políticas

similares para simplificar la configuración y reducir errores.

 Diseño modular de políticas: Crear políticas específicas para

diferentes propósitos (filtrado de prefijos, manipulación de
comunidades, prepending de AS-Path) y combinarlas de manera lógica.
Esto mejora la legibilidad, mantenibilidad y reusabilidad de las
políticas.

6. Casos de Uso y Escenarios de Implementación

6.1. Interconexión con un ISP (Single-Homed, Multi-Homed)

 Single-Homed: Un AS se conecta a un único ISP. Configuración básica

de eBGP con el ISP.

 Multi-Homed: Un AS se conecta a múltiples ISPs para redundancia y/o

balanceo de carga.

o Dual-homed a un ISP: Dos enlaces a un mismo ISP. Se puede

usar iBGP entre los routers de borde del cliente o ECMP si las
políticas lo permiten.

o Dual-homed a múltiples ISPs: Conexión a dos ISPs diferentes.

Aquí, la manipulación de atributos BGP (LOCAL_PREF, AS_PATH
prepending, MED) es crucial para controlar el tráfico entrante y
saliente.

6.2. Implementación de una Red MPLS L3VPN para Clientes

Corporativos

Los Nokia SR son ampliamente utilizados para ofrecer servicios VPRN (MPLS
L3VPN). BGP es el motor de señalización:

 Se configuran instancias VPRN para cada cliente.

 Cada VPRN tiene su propio route-distinguisher y vrf-target.

  Las sesiones iBGP entre los PEs (y RRs) transportan las rutas
VPNv4/VPNv6 utilizando la familia de direcciones vpn-ipv4 o vpn-ipv6.

 Las políticas BGP controlan qué rutas se importan/exportan entre las

diferentes VPRN (topologías full-mesh, hub-and-spoke).

6.3. Despliegue de EVPN para Data Centers y Servicios de

Interconexión

EVPN (Ethernet VPN) está ganando tracción para extender la conectividad de

capa 2 a través de una red IP/MPLS. Nokia SR soporta EVPN:

 Se configura una instancia VPLS (Virtual Private LAN Service) para cada
servicio EVPN.

 BGP (family evpn) se encarga de la señalización de direcciones MAC,

rutas IP de hosts, y la información de los segmentos Ethernet (ESI).

 Permite la movilidad de máquinas virtuales, balanceo de carga de

tráfico capa 2 y resiliencia en data centers distribuidos.

6.4. Migración de Redes BGP Existentes a Nokia SR

Un escenario común para los integradores es migrar una red BGP de un

fabricante a Nokia SR:

 Planificación meticulosa: Inventario de rutas, políticas, atributos.

 Fase de coexistencia: Operar los routers antiguos y los nuevos SR en

paralelo.

 Pruebas exhaustivas: Validar la tabla de enrutamiento BGP, las

políticas y el flujo de tráfico en el nuevo SR.

 Cutover controlado: Transición gradual del tráfico a los nuevos SR.

6.5. Peering con IXP (Internet Exchange Point)

Un IXP es un punto de encuentro físico donde múltiples ASs intercambian

tráfico directamente. Los Nokia SRs son adecuados para este propósito:

 Se configuran sesiones eBGP con los Route Servers del IXP o

directamente con otros miembros del IXP.

 Políticas BGP robustas para filtrar prefijos no deseados y para controlar

el tráfico que entra y sale del IXP.
  Consideraciones de seguridad y capacidad para manejar un gran
volumen de rutas.

Apéndice A: Referencias de Comandos BGP en Nokia SR OS

(Sección a expandir con listados de comandos específicos y sus parámetros

clave para una referencia rápida).

 configure router bgp

o group <name> [type ebgp | ibgp]

 neighbor <ip-address>

 authentication-key <key> md5

 local-address <ip-address>

 peer-as <asn>

 family [ipv4 | ipv6 | vpn-ipv4 | vpn-ipv6 | evpn]

 import <policy-name>

 export <policy-name>

 next-hop-self

 route-reflector-client

 bfd enable

 max-routes <number> [warning-threshold

<percent>]

o router-id <ip-address>

o local-as <asn> [no-prepend-global-as]

o confederation [confederation-id <asn>] [member-as <asn1>

<asn2> ...]

o ecmp <number>

o disable-connected-check

o no shutdown

 configure router policy-options

 o prefix-list <name>

 prefix <prefix>/<length> [exact | longer | through

<length>]

o community-list <name>

 community "<string>"

o as-path-list <name>

 expression "<regex>"

o policy-statement <name>

 entry <id>

 from [prefix-list <name>] [community <name>] [as-

path <name>] [protocol <bgp | direct | static | ospf |
isis>]

 action [accept | reject]

 set [local-pref <value>] [med <value>] [as-

path prepend <asn>] [community <value> |
add <value> | delete <value>] [next-hop <ip-
address> | self]

 show router bgp summary

 show router bgp neighbor <ip-address> [detail | received-routes |

advertised-routes]

 show router bgp routes [family <family>] [active] [prefix

<prefix>/<length>]

 clear router bgp [neighbor <ip-address>] [soft | hard]

 debug router bgp [peer <ip-address>] [events | updates | keepalives]

Apéndice B: Glosario de Términos BGP

(Sección a expandir con definiciones concisas de todos los términos técnicos

utilizados en el capítulo).

 AS: Sistema Autónomo

 BGP: Border Gateway Protocol

 eBGP: External BGP

 iBGP: Internal BGP

 MBGP: Multiprotocol BGP

 NLRI: Network Layer Reachability Information

 RIB: Routing Information Base

 FIB: Forwarding Information Base

 AS-Path: Atributo de ruta BGP que lista los AS por los que ha pasado
una ruta.

 NEXT_HOP: Atributo de ruta BGP que indica el siguiente salto.

 MED: Multi-Exit Discriminator

 LOCAL_PREF: Atributo de ruta BGP para la preferencia interna de

salida.

 ORIGIN: Atributo de ruta BGP que indica cómo se originó una ruta.

 COMMUNITY: Atributo de ruta BGP para etiquetar y aplicar políticas.

 Route Reflector (RR): Mecanismo para escalar iBGP.

 Confederación: Mecanismo avanzado para escalar iBGP en AS muy

grandes.

 MPLS VPN: Redes Privadas Virtuales sobre MPLS.

 VPRN: Virtual Private Routing Network (implementación de VRF en

Nokia).

 VPLS: Virtual Private LAN Service.

 EVPN: Ethernet VPN.

 RD: Route Distinguisher.

 RT: Route Target.

 Multihoming: Conexión a múltiples ISPs o puntos de interconexión.

 ECMP: Equal-Cost Multi-Path.

 BFD: Bidirectional Forwarding Detection.

 Policy Options: Marco de políticas de enrutamiento en Nokia SR OS.

  Prefix-list: Lista de prefijos IP para filtrado.

 Route-map (Policy Statement): Reglas para filtrar y modificar

atributos.

 RPKI: Resource Public Key Infrastructure.

 ROA: Route Origin Authorization.

 GTSM: Generalized TTL Security Mechanism.

 IXP: Internet Exchange Point.

Apéndice C: Ejemplos de Configuración Detallados

(Sección para incluir configuraciones completas para escenarios específicos,

como multihoming básico, VPRN con BGP, EVPN, etc.).

Ejemplo 1: Configuración eBGP Básico con un ISP

Fragmento de código

# Configuración del Router ID BGP

configure router bgp

router-id 192.168.1.1

local-as 65001

no shutdown

# Grupo para el peering con ISP A

group ISP-A

type ebgp

local-as 65001

peer-as 10001

description "eBGP Peering with ISP A"

family ipv4

exit
 # Vecino específico ISP A

neighbor 203.0.113.1

description "Link to ISP A Router"

local-address 203.0.113.2

authentication-key "SecurePasswd" md5

bfd enable

import "IMPORT-ISP-A"

export "EXPORT-OUR-PREFIXES"

no shutdown

exit

exit

# Definición de Prefijos Propios

configure router policy-options

prefix-list OUR-PREFIXES

prefix 192.168.10.0/24 exact

prefix 192.168.20.0/24 exact

exit

# Política para exportar nuestros prefijos al ISP

policy-statement EXPORT-OUR-PREFIXES

entry 10

from

prefix-list "OUR-PREFIXES"

exit

action accept
 set

med 100 # Ejemplo: set MED bajo para ser preferidos

as-path prepend "65001 65001" # Ejemplo: Prepending para

influir en el tráfico de entrada

exit

exit

exit

entry 20 # Reject all other prefixes by default

action reject

exit

exit

exit

# Política para importar rutas del ISP (filtrado básico)

policy-statement IMPORT-ISP-A

entry 10

from

# Opcional: Filtrar por AS-Path del ISP

# as-path-list "ISP-A-AS"

# Mejor: Filtrar por prefijos específicos que esperamos

# prefix-list "EXPECTED-ISP-A-PREFIXES"

exit

action accept

set

local-pref 200 # Dar alta preferencia a rutas de este ISP

exit

exit
 exit

entry 20

action reject

exit

exit

exit

commit save

Ejemplo 2: Configuración iBGP con Route Reflector

Fragmento de código

# Configuración en el Router "Cliente" de RR (ej: PE)

configure router bgp

router-id 192.168.1.10

local-as 65001

no shutdown

group IBGP-CORE-RR

type ibgp

local-as 65001

description "iBGP Peering with Route Reflector"

next-hop-self # Crucial para iBGP

family ipv4

family vpn-ipv4 # Para VPRN si aplica

exit

neighbor 192.168.1.100 # IP del Loopback del Route Reflector

description "RR-1"

local-address 192.168.1.10 # IP del Loopback de este router

 no shutdown

exit

exit

commit save

# Configuración en el Router "Route Reflector" (ej: Core Router)

configure router bgp

router-id 192.168.1.100

local-as 65001

cluster-id 1.1.1.1 # Opcional, si no se usa router-id por defecto para

cluster-id

no shutdown

group IBGP-CORE-CLIENTS

type ibgp

local-as 65001

description "iBGP Peering with RR Clients"

route-reflector-client # Este router es el RR y el vecino es un cliente

family ipv4

family vpn-ipv4

exit

neighbor 192.168.1.10 # IP del Loopback del Cliente 1

description "PE-1"

local-address 192.168.1.100

no shutdown

exit
 neighbor 192.168.1.11 # IP del Loopback del Cliente 2

description "PE-2"

local-address 192.168.1.100

no shutdown

exit

exit

commit save

Conclusión

Este capítulo ha proporcionado una inmersión profunda en el protocolo BGP,

con un enfoque particular en su implementación y diseño en los Service
Routers de Nokia. Desde los fundamentos teóricos hasta las
configuraciones avanzadas, el troubleshooting y las mejores prácticas, el
objetivo ha sido equipar a los diseñadores e integradores con el
conocimiento necesario para enfrentar los desafíos de la construcción y
operación de redes IP/MPLS de gran escala.

La comprensión sólida de BGP y su dominio en la plataforma Nokia SR son

esenciales para garantizar la estabilidad, escalabilidad y seguridad de las
redes de los proveedores de servicios en la era digital. Este material servirá,
esperamos, como una referencia invaluable en la ejecución exitosa de sus
proyectos.