BGP Enrutamiento entre SA

GRUPO ACADEMIA POSTAL
Enrutamiento Avanzado mediante BGP
con Tecnología Cisco
Centro de Nuevas Tecnologías de Galicia
12 de marzo de 2015

Presentación
• Francisco Javier Nóvoa
– En twitter: @fjnovoa_
– http://cisconetworkingspain.blogspot.com
• PEN Consultoría y Formación SLU (de Grupo Academia Postal)
– http://www.academiapostal.es
– Cisco Networking Academy Program: ITC, ASC, CA
– CCNA, CCNP, CCNA Security
– Partner de otras tecnologías

Objetivos
• Terminología BGP, Conceptos y Funcionamiento
• Configuración de BGP
• Verificación y Resolución de Problemas
• Manipulación de Rutas en BGP utilizando route Maps
• Filtrado de Rutas en BGP

Terminología, Conceptos y Funcionamiento BGP

Introducción
• Enrutamiento
• Tipos de enrutamiento:
– Enrutamiento estático
– Enrutamiento dinámico
• Clasificación de los protocolos de enrutamiento:
– Protocolos de enrutamiento aplicados dentro de la propia “organización”: IGP.
• RIP, OSPF, IGRP, EIGRP...
– Protocolos de enrutamiento entre “organizaciones”, como por ejemplo, ISPs: EGP.
• BGP4.
• Concepto de Sistema Autónomo
– Interconexión de Sistemas Autónomos:
• Rutas por defecto: Entre clientes e ISPs (habitualmente)
• BGP: Entre ISPs de diferentes niveles

Sistemas Autónomos
• Internet es una colección de Sistemas Autónomos que se interconectan, facilitando el
intercambio de información entre dichos SAs.
– BGP es el protocolo que permite intercambiar información de enrutamiento entre SA
diferentes
– Versión actual BGP 4 (RFC 4271)
– El RFC 4760 define extensiones para BGP, dando lugar a BGP+ o MultiProtocol BGP.
Entre otras aportaciones permite que BGP dé soporte a IPv6
• Un Sistema Autónomo es un “conjunto de redes bajo una sola autoridad de administración
técnica, que utiliza un IGP y métricas comunes para enrutar paquetes dentro del propio SA
y utiliza un protocolo de enrutamiento inter – Sistema Autónomo (EGP) para enrutar como
enviar los paquetes fuera del Sistema Autónomo”
– Pueden utilizarse varios IGPs
– Cada organización (p.ej. ISP) tiene autonomía y puede administrar de forma autónoma
su propio conjunto de redes:
• Plan de enrutamiento interior coherente
• Políticas de enrutamiento
• Políticas de seguridad

Sistemas Autónomos
• Cada SA tiene un número identificador asignado por la IANA, la Regional Internet Registry
que corresponda, que en caso de Europa es realizado por el RIPE, o bien por un ISP.
– El RFC 1930 define que el nº de SA es un nº de 16 bits
• El rango va desde 1 a 65.535.
• Desde el 64.512 al 65.535 se reservan para uso privado (igual que las direcciones
IP privadas).
– Debido a que existe un número muy limitado de números de SA es necesario justificar
de forma razonada la solicitud de un número de SA público.
– Se está promoviendo la asignación de números privados desde los ISP a sus clientes,
de tal forma que el conjunto de las redes del ISP y las de sus clientes se verán desde
el exterior como un único SA después del proceso de traducción.
– El RFC 4893 amplió el tamaño de los nºs de SA de 16 a 32 bits
• EGP3 (protocolo específico) fue el primer EGP (protocolo de pasarela exterior) que se
utilizó de forma generalizada.
• BGP4 es actualmente el protocolo EGP utilizado como estándar “de facto” en Internet.

Enrutamiento BGP entre Sistemas Autónomos
• Objetivo de BGP  Intercambiar información entre SA, garantizando rutas libres de
bucles.
– Grafo de SA por los que ha pasado la ruta (atributo AS_PATH).
• BGP4 es la primera versión de BGP que soporta enrutamiento “classless”  CIDR y VLSM.
– La única implementación actual soportada es BGP4 con sus extensiones
– Ha permitido reducir el tamaño de las tablas de enrutamiento de los routers “core” de
Internet de 2.000.000 de entradas a 300.000 bloques CIDR

Enrutamiento entre Sistemas Autónomos
• Diferencias con los IGPs:
– Es un protocolo de enrutamiento exterior frente a los protocolos de enrutamiento
interiores
– Es un protocolo de tipo vector-distancia mejorado (enrutamiento vector-ruta)
– No requiere diseño jerárquico
– Prima, todavía más, la estabilidad frente a la rapidez
– El enrutamiento en BGP no se basa en métricas, sino en políticas (o directivas)
definidas en función de los atributos de la ruta.
– Utiliza el puerto TCP 179  Se necesita conectividad IP  Establecer relaciones de
vecindad entre routers.
• BGP es orientado a la conexión y utiliza un servicio de capa de transporte fiable.

Comparativa entre BGP y los IGPs
Protocolo
Interior o
Exterior
Tipo
Requiere
Jerarquía
Métrica
RIP Interior
Vector -
Distancia
No Nº de Saltos
OSPF Interior Link state Sí Coste
IS-IS Interior Link state Sí Métrica
EIGRP Interior
Vector –
Distancia
Avanzado
No Compuesta
BGP Exterior Path vector No
Vectores de
Ruta
(atributos)

Conectar Redes Corporativas a un ISP
• Las redes corporativas modernas se conectan a Internet de diferentes modos, en
función de sus requisitos, que pueden ser:
– Espacio de direccionamiento IP público:
• Conexión unidireccional: Direccionamiento Privado + NAT
• Conexión bidireccional: Direccionamiento Público + Privado
– Tipo de conexión y ancho de banda entre la empresa y el ISP
– Redundancia de las conexiones
– Protocolo de enrutamiento

Espacio de Direccionamiento IP Público
• Se utiliza espacio de direccionamiento público si:
– Los clientes internos acceden a Internet utilizando NAT
– Hacer accesibles los servidores desde Internet utilizando NAT estático
• Las direcciones IP públicas se pueden obtener desde un ISP o desde un RIR:
– Muchas organizaciones obtienen sus direcciones IP y sus AS de sus ISPs
– Grandes empresas puede desear obtener sus direcciones IP y un nº de AS
de los RIR directamente

Preguntas a plantear sobre la Conexión y el Enrutamiento
• ¿Qué opciones de conexión ofrece el ISP?
• ¿Qué opciones de enrutamiento ofrece el ISP?
• ¿Estará la red corporativa conectada a múltiples ISPs?
• ¿Es necesario que el enrutamiento soporte un enlace a un ISP, un enlace a
múltiples ISPs o múltiples enlaces a múltiples ISPs?
• ¿Se requiere balanceo de carga sobre múltiples enlaces?
• ¿Cuánta información de enrutamiento es necesario intercambiar con el ISP?
• ¿Es necesario que el enrutamiento responda a los cambio se topología, como
cuando se pierde un enlace?

Ejemplo de Rutas Estáticas
• Las rutas estáticas son el modo más simple de implementar el enrutamiento con un ISP
− Normalmente, el cliente tiene una sola conexión al ISP y utiliza una ruta por defecto
hacia el ISP y el ISP utiliza rutas estáticas para conectarse con sus clientes
PE(config)# ip route 10.0.0.0 255.0.0.0 serial 0/0/1
Company A
Internet
PER1 S0/0/1
10.0.0.0
172.16.0.0
172.17.0.0
ISP
S0/0/0
R1(config)# router eigrp 110
R1(config-router)# network 10.0.0.0
R1(config-router)# exit
R1(config)# ip route 0.0.0.0 0.0.0.0 serial 0/0/0

Uso de BGP
• BGP se puede utilizar para intercambiar información dinámicamente
• BGP puede reaccionar ante cambios en la topología más allá de la conexión
cliente - ISP
Company A
AS 65010
Internet
PER1 S0/0/1
ISP
AS 65020
S0/0/0

Redundancia de Conexiones
• La redundancia de conexiones puede conseguirse mediante enlaces
redundantes, utilizando dispositivos redundantes y usando componentes
redundantes en un router
– Las conexiones a un ISP también pueden ser redundantes
• Cuando un cliente se conecta a un solo ISP, la conexión se define como single-
homed o dual-homed
• Cuando un cliente se conecta a múltiples ISPs, la conexión se denomina
multihomed or dual-multihomed

Dual-multihomedDual-homed
MultihomedSingle-homed
Connecting to Two or more ISPsConnecting to One ISP

Conexión a un ISP: Single-Homed
• El tipo de conexión depende de la oferta de ISP y el fallo del enlace provoca la pérdida de
servicio
• La figura muestra dos opciones
– Opción 1: Rutas estáticas, donde se utiliza una ruta estática por defecto en el cliente
hacia el ISP y una ruta estática desde el ISP al cliente
– Opción 2: Cuando se usa BGP, el cliente puede publicar dinámicamente sus redes
públicas al ISP y éste propaga una ruta por defecto al cliente
Company A
AS 65010
Internet
PER1 S0/0/1
ISP
AS 65020
S0/0/0
Static Route(s)Default Route
BGP
Option 1:
Option 2:

Conexión a un ISP: Dual-Homed
• La figura muestra dos opciones:
– Opción 1: Ambos enlaces se conecta al mismo router del cliente
– Opción 2: Para mejorar la tolerancia a fallos, los 2 enlaces finalizan en routers
separados en la red del cliente
Company A
Internet
ISP
Option 1:
PER1
Company A
Internet
ISP
Option 2:
PER1
R2

Conexión a un ISP: Dual-Homed
• Las opciones de enrutamiento incluyen:
– Un enlace primario y otro de backup en caso de que el enlace primario falle
– Balanceo de carga utilizando CEF
• Se puede utilizar tanto enrutamiento dinámico como estático
Company A
Internet
ISP
Option 1:
PER1
Company A
Internet
ISP
Option 2:
PER1
R2

Conexión a múltiples ISPs: Multihomed
• Las conexiones desde los diferentes ISP terminan en el mismo router o en routers
diferentes para proporcionar una mayor tolerancia a fallos
• El enrutamiento debe ser capaz de reaccionar a los cambios dinámicos más allá de los
enlaces directamente conectados.
• Este comportamiento se consigue habitualmente con BGP
Company A
Internet
ISP 1
PE
R1
R2
ISP 2
PE

Conexión a múltiples ISPs: Multihomed
• Las ventajas de “multihomed” incluyen:
– Proporciona una solución independiente del ISP
– Escalabilidad en la solución, más allá de los 2 ISPs
– Resistencia a fallos en un ISP
– Balanceo de carga a diferentes destinos a través de los 2 ISPs
Company A
Internet
ISP 1
PE
R1
R2
ISP 2
PE

Conexión a múltiples ISPs: Dual-Multihomed
• Dual-Multihomed incluye todas las ventajas de la conectividad multihomed con tolerancia a
fallos mejorada
• La configuración típica tiene múltiples routers borde, uno por ISP, y utiliza BGP
Company A
Internet
ISP 1
PE
R1
R2
ISP 2
PE

BGP en Redes Corporativas
• BGP puede ejecutarse para intercambiar información de enrutamiento entre routers que
pertenecen a un mismo SA (IBGP) o entre routers que pertenecen a SAs diferentes (EBGP)
• Ejemplo:
– Como se puede observar un SA es un conjunto de redes sobre los que se aplica una
administración común.
– Desde el interior del SA, este puede ser considerado un conjunto de redes que
intercambian información por medio de IGPs.
– Desde el exterior, se ve al SA como una
“unidad”, que intercambia con los demás
SA información de enrutamiento mediante
EGPs, en este caso BGP.
EBGP
EBGP
IBGP
IBGP
IBGP

BGP en Redes Corporativas
• Ejemplo:
– El SA 65000 aprende rutas tanto desde el ISP-A como desde el ISP-B
– Además, los routers del SA 65000 establecen relaciones de vecindad BGP tanto con
routers de otros SAs como entre ellos
• IBGP
• EBGP
– Los routers del SA 65000 aprenden rutas
y eligen cuál es el mejor camino para
alcanzar el destino, en base a su
configuración y a las rutas aprendidas
– El control de la información de
enrutamiento es crítica en BGP
• Pueden darse casos en los que el
tráfico entre proveedores “circule” a
través de un cliente

Funcionalidad Vector-Distancia
• BGP no publica destinos por medio de dirección de red y máscara de subred, utiliza NLRI.
• NLRI es un conjunto de pares formados por un prefijo de red, la longitud del prefijo y los
atributos de la ruta
– El prefijo representa el destino alcanzable.
– Longitud representan el número de bits del prefijo que identifican al destino.
• Ejemplo: Para 10.1.1.0 255.255.255.0. Prefijo 10.1.1.0. Longitud 24.
– <24, 10.1.1.0>
– Entre los atributos se puede encontrar:
• Lista de SAs que se han de atravesar para alcanzar el destino (AS_PATH)
• Next-hop: IP del SA vecino al que se ha de enviar el paquete para alcanzar el
destino
• Origin: Como se ha introducido la información de enrutamiento en BGP
– Esta información permite construir un grafo de SAs
– BGP ve a Internet como un grafo de SAs autónomos libre de bucles (árbol)

Políticas de Enrutamiento en BGP
• BGP permite que las decisiones de enrutamiento a nivel de Sistema Autónomo
sean manipuladas, mediante políticas o directivas
• BGP puede publicar a sus SAs vecinos solamente aquellas rutas que utilice el
mismo
– Paradigma del enrutamiento “salto a salto”
• No permite aplicar cualquier tipo de directivas:
– No se puede determinar estrictamente como los SAs vecinos van a
enviar información al propio SA
– Sí se puede
determinar como el
tráfico propio
alcanza los SAs
vecinos

Funcionalidades de BGP: Cuando usar BGP
• Un SA “multi-homed” tiene más de una conexión a otros SA, bien con un proveedor o con
varios proveedores. Si este SA pertenece a una organización consumidora de servicios de
Internet (cliente final) no le interesará enrutar tráfico que tenga como origen y destino rutas
que no pertenezcan al propio SA.
– No permite pasar el tráfico a través de él mismo.
– Solamente publica sus propias rutas al resto de SA, de esta forma se asegura que
ISP1 no envíe a ISP2 a través del AS24.
– Para evitar que los ISPs utilicen una ruta por defecto para enviar el tráfico a través de
él se puede usar filtros para el tráfico entrante.
• No necesitan obligatoriamente ejecutar BGP4, aunque es recomendable si los puntos de
salida van a ISP diferentes, debido a que BGP4 proporciona:
– Control del enrutamiento.
– Filtrado de actualizaciones de enrutamiento.

Funcionalidades de BGP: Cuando usar BGP
• Un SA que tiene más de una conexión al exterior y que puede ser utilizado como área de
“tránsito” entre otros 2 SA, se define habitualmente como SA “transit multi-homed”
– Se define como “tráfico de tránsito” aquel que tiene como origen y destino redes que no
pertenecen al propio SA.
– La información de enrutamiento entre los Routers de “borde” se intercambia a través
del propio SA, pudiendo utilizar para ello BGP.
• Cuando BGP sirve para intercambiar información entre routers que pertenecen al mismo SA
se denomina IBGP (Internal BGP).
• Cuando BGP se utiliza para pasar información de enrutamiento entre 2 SA diferentes se
denomina EBGP (External BGP).

Características de BGP
• Utiliza TCP como protocolo de capa de transporte  No necesita implementar mecanismos
de retransmisión o de reconocimiento
– Puerto 179
– Dos routers BGP establecen una conexión TCP intercambiando mensajes “Open” y
“Keepalive” para negociar los parámetros de esta conexión TCP
• Si la negociación tiene éxito, los routers pasan a ser vecinos o “peers”
• Una vez que la conexión se ha TCP se ha establecido intercambian su tabla de
enrutamiento BGP completa y, a partir de este punto, intercambiarán actualizaciones
incrementales generadas por eventos
• La relación de vecindad se mantiene por medio paquetes Hello de BGP (60 segundos)
• BGP puede llegar a manejar una gran cantidad de rutas y utiliza el mecanismo de ventana
deslizante proporcionado por TCP para realizar un intercambio eficiente de rutas
• Sinónimos de vecinos BGP:
– BGP peers
– BGP neighbors
– Si un router tiene activado BGP, aunque no tenga vecinos BGP, se denomina BGP
speaker

Relaciones de vecindad en BGP
• En BGP dos routers intercambian información de enrutamiento si previamente han
establecido una relación de vecindad.
– Requisito: Debe establecerse previamente una conexión TCP, por lo que debe haber
conectividad entre los dos routers a través de IP, bien por conexión directa o través de
otros routers.
– Los routers vecinos intercambian mensajes para abrir y confirmar los parámetros de la
conexión.
• Si no son compatibles los parámetros establecidos en ambos “peers” se envían
mensajes de notificación de error y se finaliza la conexión.
• Al establecer la primera conexión, los “peer routers” intercambian todas las rutas BGP
candidatas.
• Después de este intercambio de información inicial, se utilizan actualizaciones
incrementales para notificar cambios (rutas nuevas y rutas que se eliminan).
• Los “peers” publican su información mediante mensajes “update” o de actualización:
– Estos mensajes contienen, entre otras, las siguientes informaciones:
• Prefijo de la ruta, AS_PATH, el grado de preferencia de la ruta y los demás
atributos de la ruta.

Relaciones de vecindad en BGP
• Los routers BGP establecen relaciones de vecindad directas, de forma explícita, con sus
vecinos
– Un router BGP intercambia solamente información con sus vecinos BGP
– Sinónimos de routers que ejecutan BGP:
• BGP neighbor
• BGP peer
• BGP speaker
– Configuración de una relación de vecindad:
• Router(config-router)#neighbor

EBGP
• Cuando BGP se utiliza para establecer una conexión entre dos peers que pertenecen a SAs
diferentes se dice que han establecido una sesión EBGP
– En este caso, habitualmente los routers están directamente conectados
– Para que puedan intercambiar información de enrutamiento estos routers deben ser
capaces de:
• Conexión TCP  La dirección IP del vecino debe ser alcanzable siempre
– Red directamente
conectada
– Rutas estáticas

IBGP
• Cuando BGP se ejecuta entre routers dentro del mismo SA, se denomina IBGP. Este tipo
de sesiones permiten intercambiar información de enrutamiento de modo que todos los
routers BGP del SA tengan la misma información de enrutamiento de los SAs externos
– No tienen porqué estar directamente conectados. Solamente han de ser capaces de
establecer conexiones TCP
• Se recomienda utilizar interfaces de loopback para establecer las relaciones de
vecindad BGP

IBGP en Nontransit SAs
• Los Nontransit SAs son organizaciones que utilizan los servicios de dos ISPs, pero que no
pasan ni rutas ni tráfico de un ISP a otro
– En caso contrario sería la organización la que daría servicio a los ISPs y no al contrario
– Sin embargo, todos los routers del SA necesitan tener conocimiento de todas las rutas
BGP para alcanzar todos los posibles destinos de manera óptima
• BGP no fue diseñado como un IGP. Solamente garantiza que no se producen bucles de
SA. No es capaz de garantizar que no se producen bucles dentro del SA
– Para evitar este problema se establece la siguiente norma: Las rutas aprendidas
mediante IBGP nunca se publican de nuevo por IBGP (split-horinzon BGP)
– Se presupone, por lo tanto, que todos los routers IBGP de un SA están conectados en
una topología BGP “full-mesh”, aunque pueden no estar directamente conectados
físicamente

IBGP en Transit SAs
• Topología Full-Mesh:
• Topología Partial-Mesh:

Problemas de enrutamiento en SA de Tránsito
• Todos los routers que están entre dos routers IBGP, se denominan camino de tránsito
“transit path”
– Sincronismo dentro de un SA
• Justificación del sincronismo
• Desactivación del sincronismo
– Configuración de una topología full-mesh BGP en todos los routers del “transit-path”

Continuidad dentro de un SA con BGP.
• BGP NO PUBLICA LAS RUTAS APRENDIDAS DESDE UN PEER IBGP A OTROS
PEERS IBGP.
– En caso contrario, el enrutamiento dentro de un SA podría presentar “loops” de
enrutamiento (el control se lleva a cabo mediante el atributo AS_PATH).
• Para que los routers que ejecutan IBGP aprendan todas las rutas del SA debe estar
conectados en topología “full-mesh” lógica (no hace falta que sea física).
– Es necesario que los routers puedan conectarse vía TCP/IP.
• Ejemplo de un escenario erróneo: Las rutas EBGP aprendidas via San José no se
publicarán a Los Angeles, porque San Francisco aprende dichas rutas desde San José vía
IBGP y por lo tanto no las pública a Los Angeles vía IBGP.

Sincronización en un Sistema Autónomo
• BGP fue diseñado para ser ejecutado en los routers “borde” de un SA, mientras los routers
internos ignoraban los detalles acerca del enrutamiento externo
• Sin embargo, existen SA de Tránsito, que enrutan tráfico desde un SA externo a otro SA
externo (ISPs)
– En este caso, todos los routers del SA deben tener un conocimiento completo de las
rutas externas
• Solución 1  Redistribución de rutas de BGP en el IGP del SA
– Problemas: Carga y Escalabilidad
• Solución 2  IBGP + No sincronización
• Sincronización:
– Cuando la sincronización está activada en BGP, se establece que BGP debe estar
sincronizado con el IGP antes de publicar rutas de tránsito a routers externos
• Este era el comportamiento por defecto en versiones anteriores IOS
• En las versiones actuales, este comportamiento esta desactivado por defecto
– Un router no publicará rutas a sus vecinos EBGP, aprendidas desde vecinos
IBGP, a no ser que dichos destinos también sean conocidos a través de un IGP
 Garantizar la alcanzabilidad

Sincronización en un SA
• Cuando un router IBGP recibe una actualización desde otro router IBGP, intenta
comprobar si es alcanzable a través de un IGP, como OSPF o RIP.
– Si el router IBGP no es capaz de encontrar la red de destino en la tabla de
enrutamiento IBGP, no publicará la ruta a ningún vecino BGP (lo cual incluye tanto
a los vecinos IBGP como a los EBGP).
– Si la ruta no es alcanzable mediante un protocolo IGP en el SA, los routers que no
sean BGP no serán capaces de entregar la información al destino.
– Si se publicasen, los routers EBGP podrían enviar información al SA y una vez allí la
información no podría ser entregada de forma adecuada.
– Si el router IBGP tiene una ruta hacia el destino mediante un IGP se dice que la
ruta está sincronizada, y el router la publicará a sus vecinos.

Ejemplo de sincronización en un SA
• ISP1 e ISP2 están utilizando ISP3 como SA de tránsito.
• ISP3 tiene múltiples routers en su SA, pero solamente ejecuta BGP en sus “border” routers.
– Aunque RTB y RTD se utilicen para enviar tráfico de tránsito, en estos routers no se
configura BGP.
– ISP3 utiliza un protocolo de tipo IGP para conseguir conectividad dentro del SA.
– RTA y RTB no están físicamente conectados, establecen una sesión TCP a través de
RTD y RTB.
• ISP1 publica la red 192.213.1.0/24 al SA ISP3.
• Debido a que RTA y RTC son vecinos IBGP, RTA envía a RTC la ruta 192.213.1.0/24.
Conexión lógica.
No conexión física.

Ejemplo de sincronización en SA II
• Los routers RTD y RTB no están ejecutando BGP y por lo tanto no conocen la ruta
192.213.1.0/24 (no hemos definido redistribución tampoco).
• En esta situación, si RTC envía a ISP2 una actualización publicando la ruta 192.213.1.0/24,
desde ISP2 empezará a enviarse el tráfico con destino 192.213.1.0/24 a RTC.
• RTC inicia una búsqueda recursiva en su tabla de enrutamiento y decide enviar el tráfico a
RTB.
• RTB cuando recibe paquetes con destino 192.213.1.0/24 no sabe a donde enviarlos puesto
que no conoce la ruta. BGP y el IGP no están sincronizados.

Sincronización en un SA. Conclusiones
• La regla de sincronización en BGP establece que un router BGP no debe publicar a sus
vecinos externos ninguna ruta que haya aprendido mediante IBGP, a no ser que sea capaz
de alcanzar la citada ruta también a través del IGP.
– Si el router conoce dicha ruta vía IGP asume que esa ruta ha sido inyectada en el SA, y
que la “alcanzabilidad” interna está garantizada.
• Inyectar rutas externas en un SA tiene un coste asociado importante, debido a que
redistribuir rutas externas en el SA generará una sobrecarga de trabajo al tener que
manejar más rutas de las que, en un principio, serían necesarias.
– Esta opción solo es deseable si el SA es “transit multi-homed”.
– En caso contrario puede ser más interesante trabajar con rutas por defecto, aunque las
rutas no tendrían porque ser las mejores.
• Cisco IOS ofrece una alternativa: no synchronization.
– Este comando permite ignorar la necesidad de cumplir el requisito de sincronización
para publicar las rutas a los vecinos externos.
– Existen dos situaciones en la que es seguro utilizar este comando:
• Cuando todos los routers de “tránsito” en el SA están configurados en topología
full-mesh.
• Cuando un SA no es de tránsito.

Bases de Datos BGP
• Tabla de vecinos:
– Las relaciones de vecindad se configuran de forma explícita
– Conexiones a nivel de transporte TCP 179: Se hace un seguimiento de la conexión
mediante mensajes BGP keepalive (60 segs por defecto)
– Después de establecer adyacencia, los routers intercambian las rutas BGP que están
en la tabla de enrutamiento
• Obtenida de otros vecinos BGP
• Obtenida mediante otros métodos
• Tabla BGP (tabla topológica o base de datos de envío)
– Contiene todas las rutas aprendidas por BGP
– Se seleccionan las mejores rutas BGP (BGP route selection process) y se ofrecen a la
tabla de enrutamiento
• Tabla de enrutamiento:
– Las rutas BGP compiten con las de los demás mecanismos de enrutamiento (distancia
administrativa): EBGP (20) e IBGP (200)

Tipos de Mensajes BGP
• Después de establecer una conexión TCP, el primer mensaje que intercambian los “peers”
BGP es de tipo “open”
– Si se pueden aceptar las condiciones establecidas en dicho mensaje, el receptor de
dicho mensaje lo confirma con un mensaje de tipo “keepalive” que confirma la
recepción y aceptación del mensaje open
– A continuación se establece una conexión BGP, sobre TCP
– Los peers intercambiaran a continuación mensajes de tipo update, keepalive y
notification
• Estructura de la cabecera de los mensajes de control en BGP:
– “Marker field” (16 bytes)  Sincronización y autenticación.
– “Longitud” (2 bytes)  Indica la longitud total del mensaje (incluyendo la cabecera).
• Tamaño mínimo: 19 bytes.
• Tamaño máximo: 4096 bytes.
– “Tipo” (1 byte)  Puede tomar cuatro valores (1-4):

Tipos de Mensajes BGP II
• Open  Establecer conexiones con sus “peers”. Incluye los siguientes campos:
• Versión de BGP.
• Número de SA.
• Hold time: Se selecciona el valor más pequeño establecido en cualquiera de los 2
extremos (por defecto 180 s)
• ID del router (Mismo mecanismo de elección que en OSPF)
• Keepalive  Se envía periódicamente para mantener las conexiones con los “peers”. (Si el
valor es 0 no se envían)
– Solamente lleva la información de cabecera  19 bytes.
– El período de envío debe ser 1/3 del hold time.
• Notification  Informar al receptor de que se han producido errores.
– Incluye campos para códigos de error.
• Update  Contienen la información de redes necesaria para construir rutas libres de
bucles. Se construye un mensaje por “camino”.
– Network Layer Reachability Information (NLRI).
– Atributos de ruta.
– “Withdrawn routes”.

Atributos de “Ruta”
• Todo el trabajo de configuración de BGP se centra en los path attributes.
• Cada ruta tiene su propio conjunto de atributos definidos, como pueden ser: local-
preference, next-hop, ...
• Los administradores tienen que utilizar estos valores para configurar las políticas de
enrutamiento.
– Filtrar información de enrutamiento.
– Marcar preferencias en las rutas.
– ...
• Cada mensaje de actualización contiene una secuencia de longitud variable de:
– <tipo de atributo, longitud, valor>
• NO todos los fabricantes implementan los mismos atributos. Para asegurar la
compatibilidad se agrupan en:
– Well-known Mandatory
– Well-known Discretionary
– Optional transitive: Pueden ser etiquetados como “parciales”
– Optional nontransitive

Atributos de “ruta” II
• Well-known Mandatory: AS_PATH, Next Hop, Origin
– Es un atributo estándar que tiene que existir obligatoriamente en un paquete de
actualización BGP.
– Si falta se produce una Notificación de Error.
– Asegura que todas las implementaciones de BGP utilicen estos atributos
• Well-known Discretionary: LOCAL_PREF, Atomic Aggregate
– Es un atributo estándar que es reconocido por todas las implementaciones de BGP, sin
embargo no es obligatorio que sea enviado en un paquete de actualización
• Optional transitive: Aggregator, Community
– No es necesario que sea reconocido por todas las implementaciones de BGP.
– Al ser transitivo, este atributo es publicado de nuevo, aunque no se conozca su
significado. En este caso, se marca como “parcial”
• Optional nontransitive: Multi Exit Discriminator (MED)
– No es necesario que sea reconocido por todas las implementaciones de BGP.
– Si se recibe un atributo nontransitive, no se publica a los vecinos BGP.

Atributos de “ruta” III

Atributos en BGP. Control del enrutamiento mediante atributos
• El tráfico de “usuario” entra y sale de un SA siempre en función de una planificación
preestablecida mediante rutas.
– Modificar las características de las rutas  Cambia el comportamiento del tráfico.
• Proceso de Toma de Decisiones en BGP.
– Cuando un router BGP recibe actualizaciones desde múltiples SA’s que proporcionan
diferentes caminos a un destino, es necesario seleccionar cual es el mejor camino para
alcanzar el destino.
– Una vez seleccionada la mejor ruta (en BGP), ésta es propagada a los vecinos (BGP),
mediante las actualizaciones BGP.
– La decisión de cuál es la mejor ruta se toma en función de los valores de los atributos
de la actualización y otros factores configurables de BGP.

Atributo AS_PATH.
• Es una atributo estándar obligatorio.
• Es la secuencia de números de SA que la ruta ha cruzado desde el destino.
– El SA que origina la ruta coloca su propio número de SA cuando publica la ruta a través
de alguna sesión EBGP.
– Posteriormente, cada SA que recibe la actualización, antepone su número de SA a
todos los que hayan sido incluidos, al pasarla a otro SA.
• La lista final contiene todos los números de SA que ha atravesado la ruta, con el número
del SA que la generó al final de la lista.
– Los números de SA están ordenados secuencialmente.
• Este atributo se utiliza como parte de los paquetes de actualización para determinar si se
ha producido o se va a producir un “loop” de enrutamiento.
• Cuando se publica una ruta a un vecino IBGP el atributo AS_PATH permanece intacto.
• La información proporcionada por el AS_PATH es uno de los atributos que se tiene en
cuenta para determinar el mejor camino hacia un determinado destino.
– Si se comparan dos o más rutas hacia un mismo destino, se elige aquella que tenga un
AS_PATH más corto.

Ejemplo de Atributo AS_PATH

AS_PATH y los AS privados
• Para no dilapidar los números de SA, a los clientes cuyas políticas de enrutamiento sean
las mismas que las de sus proveedores se les asigna un número de SA privado.
– Si el cliente es sigle-homed o multi-homed al mismo proveedor, generalmente el
proveedor le proporcionará al cliente un número de SA privado (64.512 a 65.535).
– Las actualizaciones BGP que proceden del cliente contendrán números de SA no
válidos para ser transportados a través de Internet.
– Los números de SA’s privados deben ser eliminados del AS_PATH antes de ser
transmitidos a Internet.
• BGP debe eliminar los números de SA’s privados cuando envía actualizaciones a vecinos
externos.
– Esta acción debe ser configurada en la relación de vecindad.
– Solamente se ejecuta si todos los números de SA son privados.
– Si una ruta tiene en su AS_PATH una mezcla de números de SA públicos y privados,
es debido a un fallo de diseño.

Ejemplo de AS_PATH y SA privados
RTB(config)#router bgp 1
RTB(config-router)#neighbor 172.16.20.2 remote-as 65001
RTB(config-router)#neighbor 192.168.6.3 remove-private-as

Manipulación del atributo AS_PATH
• La longitud del AS_PATH es utilizada en el proceso de decisión para determinar cual es la
mejor ruta a un destino.
– Si se varía la longitud del AS_PATH se puede cambiar la ruta preferida.
• Para varia la longitud del atributo AS_PATH se incluyen números de SA “dummy”.
• IOS permite que el usuario pueda introducir números de SA al principio del AS_PATH para
hacerlo mayor.
• Debido a que las rutas preferidas son aquellas que tengan la menor longitud, para modificar
el comportamiento del tráfico, se incrementará el tamaño de los AS_PATH
correspondientes a las rutas que NO queramos utilizar.

Ejemplo de manipulación de atributo AS_PATH
RTX(config)#router bgp 100
RTX(config-router)#neighbor 172.16.20.2 remote-as 300
RTX(config-router)#neighbor 172.16.20.2 route-map AddASnumbers out
RTX(config-router)#exit
RTX(config)#route-map AddASnumbers permit
RTX(config-route-map)#set as-path prepend 100 100

The Next Hop attribute
• El atributo Next-Hop es un atributo estándar y obligatorio (Código tipo 3).
• El “next hop” (desde el punto de vista de un IGP) para alcanzar un destino es la dirección IP
del router que ha anunciado la ruta.
• En BGP este concepto es más complejo:
– Sesión EBGP: Next hop = Dirección IP del vecino que ha anunciado la ruta.
– Sesión IBGP:
• Cuando las rutas se generan dentro del SA: Next hop = Dirección IP del router que
ha anunciado la ruta.
• Cuando las rutas se han inyectado en el SA vía una sesion EBGP, el atributo Next
Hop se transmite sin ser alterado dentro del SA. Es decir, permanece como Next
Hop la dirección IP del vecino externo que ha publicado la ruta.
– Cuando la ruta es publicada sobre un medio “multiacceso” (Ethernet o Frame-Relay), la
dirección IP es la de la interfaz del router que ha la publicado.

Atributo Atomic Aggregate.
• Es un atributo estándar opcional.
• Se puede configurar a verdadero o a falso.
– Si es verdadero, este atributo alerta a los routers BGP que se han agrupado múltiples
destinos en una sola actualización.
• Es decir, que el router posee otra ruta más específica para alcanzar el destino pero
no la ha enviado.
• Esto podría acarrear problemas de enrutamiento, con lo que se está comunicando
que esta no es la mejor información de enrutamiento disponible.
– Este atributo se coloca a verdadero cuando se envía información sumarizada.
• La sumarización se puede configurar manualmente en BGP por medio del comando
aggregate-address.
• Usar aggregate-address sin argumentos creará una entrada agregada en la tabla de
enrutamiento BGP, tan amplia como para que hasta la ruta menos específica que el propio
router conozca pertenezca a esa red citada.
• La ruta agregada será publicada como proveniente del SA que la ha generado si y tendrá el
atributo Atomic Aggregate configurado como verdadero.
– Si se utilizar la opción as-set se crea una entrada agregada pero se publicará la
información de todos los SA por los que ha pasado todas las rutas agregadas.

Atributo Atomic Aggregate II.
• Por defecto, se publicará la ruta agregada y las rutas contenidas en la misma de forma
individual. Si se desea publicar únicamente la ruta agregada se deberá utilizar la cláusula
summary-only.
• Ejemplo I:
RTA(config)# router bgp 300
RTA(config-router)# neighbor 3.3.3.3 remote-as 200
RTA(config-router)# network 160.10.0.0
RTA(config-router)# aggregate-address 160.0.0.0 255.0.0.0
• Ejemplo II:
RTA(config)# router bgp 300
RTA(config-router)# network 160.10.0.0
RTA(config-router)# aggregate-address 160.0.0.0 255.0.0.0
summary-only

Atributo Aggregator.
• Es un atributo estándar opcional
• Cuando se configura la agregación de direcciones, se puede configurar el router para que
incluya ID del router y su número de SA local con la ruta agregada.
• Este atributo permite a los administradores determinar cual es el router responsable de una
ruta agregada

Atributo Local Preference.
• Es un atributo estándar opcional.
• Es el grado de preferencia que se le asigna a una ruta en comparación con otras que
puedan existir al mismo destino.
• Se prefiere el Local Prefence más alto.
• Este atributo es local al sistema autónomo y solamente se intercambia entre routers IBGP,
es decir cuando la ruta sale del sistema autónomo vuelve a tener el valor por defecto.
• Los routers “borde” en un SA autónomo multihomed pueden aprender diferentes rutas para
un mismo destino
– Podrían existir diferentes salidas del sistema autónomo para llegar a un mismo destino.
• LOCAL_PREF fuerza a que los routers en el SA elijan un determinado punto de
salida.
– Como este atributo se transmite en las actualizaciones vía IBGP, todos los routers del
SA tendrán la misma visión de la ruta.

Ejemplo de utilización de Local Preference.

Manipulación del atributo Local-Preference.
RTC(config)#router bgp 256
RTC(config-router)#neighbor 1.1.1.1 remote-as 100
RTC(config-router)#neighbor 128.213.11.2 remote-as 256
RTC(config-router)#bgp default local-preference 150
RTD(config)#router bgp 256
RTD(config-router)#neighbor 3.3.3.4 remote-as 300
RTD(config-router)#neighbor 128.213.11.1 remote-as 256
RTD(config-router)#bgp default local-preference 200

Atributo Weight
• Es un atributo propietario de Cisco.
• Es un atributo muy similar a Local Preference, pero solamente tiene validez de forma local
en un router.
– Este valor no se intercambia entre BGP “peers”.
– Tiene sentido solamente si un router tiene establecidas varias sesiones EBGP.
• Es el atributo que primero se considera en el proceso de selección de rutas.
• Se prefieren las rutas que tengan asignado un valor mayor en weight.

Atributo Multi Exit Discriminator.
• Es un atributo opcional no transitivo.
• Informa a los vecinos externos de nuestras preferencias a la hora de recibir tráfico de ellos
(complemento de Local Pref).
• MED se intercambia entre sistemas autónomos (directamente conectados).
• Cuando la ruta es generada por el propio SA el valor de MED se basa en la métrica IGP de
la ruta. Es útil cuando un cliente tiene múltiples conexiones al mismo proveedor.
– El IGP refleja lo cerca o lejos que se está de un determinado punto de salida, con lo
cual la menor MED determina la ruta preferida.

Ejemplo de configuración MED.
RTB(config)#route-map setmedout permit 10
RTB(config-route-map)#set metric 50
RTB(config-router)#neighbor 4.4.4.4 route-map setmedout out

Atributo Origin
• Es un atributo “well-known mandatory”
• Puede tomar tres valores:
– IGP: Interno, generado mediante un comando “network”.
– EGP: Externo, aprendido vía EGP, el protocolo de pasarela exterior antiguo que no
soportaba ni VLSM ni CIDR.
– Incomplete: Aprendido normalmente mediante redistribución.

Proceso de decisión en BGP.
1. Si el Next Hop es inaccesible, la ruta es ignorada.
2. Se examina el atributo Weight  Se selecciona la ruta con mayor Weight.
3. En caso de empate, se examina el atributo Local Preference  Se selecciona la ruta con
mayor valor.
4. En caso de empate, se comprueba si la ruta ha sido generada por el propio router. Si es así
es seleccionada.
5. Si persiste el empate, se selecciona la ruta con el AS_PATH más corto.
6. En caso de empate, se comprueba el atributo Origin. Las prerencias son, de mayor a
menor, IGP, EGP e Incomplete.
7. En caso de igualdad, se selecciona la ruta con MED más bajo.
8. A continuación se discrimina por: ruta aprendida por EBGP, ruta aprendida desde una
confederación externa y ruta aprendida vía IBGP.
9. A continuación se procede a seleccionar por la proximidad del siguiente salto, según el IGP.
10. Si aún así persiste el empate, se utiliza el ID del router para deshacer el empate.
• Se prefiere la ruta proporcionada por el vecino con el ID más bajo.
• ID = IP más alta o Loopback (si hay varias, la IP más alta).

Configuración BGP básica
• La configuración parece similar a la de cualquier IGP, sin embargo los comandos pueden
tener significados distintos.
• Para comenzar el proceso de enrutamiento:
– Router(config)#router bgp AS-number
• AS-number: Es un nº entero entre 1 – 65.535
– Cisco IOS Solamente permite un proceso BGP al mismo tiempo, con lo que un router
solamente podrá pertenecer a un SA.
– Debe introducirse como mínimo un “subcomando” dentro del modo “config-router” para
activar el proceso de enrutamiento

Configuración BGP Básica II
• Para establecer relaciones de vecindad con otros routers BGP es necesario configurarlo de
forma específica.
– neighbor {ip-address | peer-group-name} remote-as autonomous-
system
– Este comando sirve para identificar la dirección IP de la interfaz del “peer” a través de la
cual vamos a realizar la conexión y para indicar si el router remoto pertenece al mismo
SA o a otro  EBGP o IBGP.

Desactivación de una relación de vecindad
• Para evitar eliminar la configuración de una relación de vecindad, así como para
evitar tirar una “intefaz” físicamente, si se pretende reiniciar una relación de
vecindad debe utilizarse el comando:

Consideraciones de configuración en BGP
• El comando neighbor informa al router de la dirección IP de destino que debe coloca en
cada paquete “update”
– La dirección IP origen que pone en el paquete será la de la interfaz más próxima a la
router destino, es decir, utilizará la dirección IP de la interfaz que envía el paquete
“update”
– Es obligatorio que la dirección IP que se pone como dirección IP origen en el paquete
coincida con la IP que el otro router ha configurado en su comando neighbor para
establecer la relación de vecindad
– En caso contrario, no se establece relación de vecindad

Aspectos relacionados con el “peering” IBGP
• Utilización de la interfaz de loopback para el establecimiento de relaciones de vecindad
• Configuración: neighbor <ip-vecino> remote-as <as-vecino> update-source loopback 0

Comando update-source

Aspecto relacionado con las relaciones de vecindad EBGP
• Si se desea configurar una interfaz de loopback para establecer una relación de vecindad
EBGP, hay que tener especial cuidado puesto que para EBGP parte de la suposición de
que los dos vecinos están directamente conectados.
• Para indicar que los vecinos EBGP no están directamente conectados se utiliza el comando
ebgp-multihop <nº de saltos>

EBGP Multihop
• Característica proporcionada por Cisco IOS.
• Ejemplo de configuración:
RTW(config)#router bgp 200
RTW(config-router)#neighbor 1.1.1.2 remote-as 300
RTW(config-router)#neighbor 1.1.1.2 ebgp-multihop 2
RTU(config)#router bgp 300
RTU(config-router)#neighbor 2.2.2.1 remote-as 200
RTU(config-router)#neighbor 2.2.2.1 ebgp-multihop 2

Comportamiento de “Next-hop”
• En las relaciones de vecindad EBGP, cuando se publica una ruta, el next-hop asociado es
la dirección IP del router que ha enviado dicha actualización
• En las relaciones de vecindad IBGP, cuando se publica una ruta, el next-hop permanece
intacto
– Este comportamiento se puede cambiar utilizando el comando neighbor next-hop-
self
• Sintaxis:
Router(config-router)#
neighbor {ip-address |
peer-group-name}
next-hop-self

Ejemplo de Next-Hop-Self
R2(config)# router bgp 65101
R2(config-router)# neighbor 172.16.1.1 remote-as 65100
R2(config-router)# neighbor 192.168.3.3 remote-as 65101
R2(config-router)# neighbor 192.168.3.3 update-source loopback0
R2(config-router)# neighbor 192.168.3.3 next-hop-self
R2(config-router)# exit
R2(config)# router eigrp 1
R2(config-router)#
AS 65102
AS 65100
R1 R4
Lo0 192.168.2.2
.1
192.168.1.1172.16.1.1
R2 R3
10.1.1.0/24
10.2.2.0/24
.1 .2
.2
Lo0 192.168.3.3
AS 65101
EIGRP

Ejemplo de Atributo Next Hop.
• RTC mantiene una sesión IBGP con RTZ y una IBGP con RTA.
• RTC aprende la ruta 128.213.1.0/24 mediante una actualización desde RTZ, y además
inyecta dicha ruta en el SA.
• RTA aprende la ruta 128.213.1.0/24 vía el router RTC desde la interfaz 2.2.2.2, así que la
2.2.2.2 será el siguiente salto para que desde RTA se alcance la red 128.213.1.0/24.
• RTC aprende la ruta desde la interfaz 1.1.1.1 de RTZ, teniendo como atributo Next Hop
1.1.1.1.
• Cuando RTC pase a RTA una actualización con dicha ruta, RTC mantendrá el atributo Next
Hop sin modificar, es decir, RTA verá que el atributo Next Hop para alcanzar el destino será
1.1.1.1.

Atributo Next Hop. Conclusiones.
• Next Hop no tiene por qué corresponder a la dirección IP de un dispositivo que esté
directamente conectado, como en el caso de RTA.
• La naturaleza de Next Hop obliga a que el router haga una búsqueda recursiva en la tabla
de enrutamiento para determinar a dónde a de enviar el paquete.
• En este caso, para alcanzar la red destino desde RTA, primero es necesario encontrar
como llegar al Next Hop, consultando la tabla de enrutamiento IGP.
– Esta búsqueda se hace de forma recursiva hasta que es capaz de asociar una interfaz
de salida al Next Hop.
• Si no podemos alcanzar el Next Hop a través de un IGP, la red de destino correspondiente
será inalcanzable.

Inyección de información de enrutamiento en BGP
• El comando network se utiliza en los IGP para dos funciones:
– Activar las interfaces por las que se van a enviar y recibir las actualizaciones.
– Definir las redes directamente conectadas que se van a publicar.
• El comando network en BGP se utiliza única y exclusivamente para indicar que rutas
aprendidas localmente se van a publicar (rutas presentes en la tabla de enrutamiento). No
establece relaciones de vecindad.
– Pueden ser rutas directamente conectadas, rutas estáticas o rutas aprendidas
mediante un IGP.
– Estas redes debe existir en la tabla de enrutamiento local antes de poder ser
publicadas.
– Router(config-router)#network network-number [mask network-mask]
[route-map tag]
– Problemas con los resúmenes de rutas que exceden las redes de clase: Solución rutas
estáticas null0
• En las versiones anteriores a IOS 12.2(8)T el auto-resumen (autosummary) estaba activado
por defecto en BGP. En las versiones actuales está desactivado.

Inyección de información de enrutamiento en BGP
– Router(config-router)#network network-number [mask network-mask]
[route-map tag]
• La máscara permite configurar subredes
• Deben especificarse todas las redes que deban ser publicadas,
tanto las directamente conectadas como las configuradas
estáticamente o aprendidas mediante un protocolo de
enrutamiento
• Si no se especifica máscara de subred, se publica la red de
clase siempre que el router posea, como mínimo, una subred
perteneciente a la red de clase.
• Si se usa máscara de subred, la ruta que se especifica debe
existir exactamente en la tabla de enrutamiento: debe
coincidir tanto el prefijo especificado como la máscara

Configuración de mecanismos de autenticación
• Configuración de mecanismos de autenticación en BGP:
– Se utiliza autenticación de vecinos basada en MD5
– Si los vecinos no son capaces de autenticarse, no establecen relación de
vecindad

Negociación de Vecinos BGP.
• La negociación de vecinos BGP es un proceso que pasa a través de varios pasos definidos
por una máquina de estados finitos.
• Una vez configurado el comando neighgor, BGP comienza a buscar en la tabla de
enrutamiento un camino para alcanzar al vecino especificado en el comando

Negociación de vecinos BGP II
• Idle: Es el estado de partida para una conexión BGP. Se está buscando un camino para
alcanzar al vecino/s configurados. Cuando se encuentra dicha ruta:
– Se intenta establecer una conexión TCP mediante el envío de un comando SYN ACK
– Si una relación de vecindad permanece en este estado quiere decir que:
• No hay ruta estática o directamente conectada, en caso de EBGP
• El IGP no sabe como alcanzar al vecino, en caso de IBGP
• Razones: Comando neighbor mal configurado
• Connect:
– Si se completa la conexión TCP se pasa al estado  OpenSent (paquete Open)
– Si la conexión TCP falla se pasa al estado  Idle.
• Active: En este estado se reintentan la conexión TCP.
– Si se consigue establecer  OpenSent / Connect
– Si expira el temporizador de conexión TCP, se reinica y se vuelve al estado Connect.
– Si se produce algún evento erróneo  Idle.
– Razón habitual para permanecer en este estado: El otro “peer” no es capaz de alcanzar
la IP que estamos utilizando para establecer la relación de vecindad BGP o bien no
tiene configurado el comando neighbor

Negociación de vecinos BGP III
• Opensent: BGP está esperando una respuesta a un mensaje de tipo “open” enviado o ha
recibido un mensaje de tipo “open”.
– Se chequea la información del mensaje open enviado por el peer.
– Si se produce alguna incompatibilidad (p.ej. Número de versión) se utilizan un mensaje
de tipo Notificación para indicar que se ha producido un error  Idle.
– Si no hay errores, los “peers” BGP empiezan a enviar mensajes “keepalive” y se
resetea el temporizador de keepalive  OpenConfirm
– Se negocia el hold timer y se elige el más pequeño de los dos.
• En caso de que sea 0 no se utilizan mensajes keepalive.
– En este estado se determina si el “peer” está en el mismo SA o en otro  EBGP o
IBGP.
– Si se pierde la conexión TCP se pasa al estado Active.

Negociación de vecinos BGP IV
• OpenConfirm: Se está a la espera de un paquete “keepalive” o de un mensaje de
notificación de error.
– Si se recibe keepalive (o un update) Established. (Negociación completa).
• Se resetea el hold timer.
• Se envían periódicamente mensajes keepalive.
– Si se recibe notificación  Idle.
• Established: Es el estado final de la negociación.
– Se envían updates, al conectar y cuando se producen cambios en las rutas.
– Se envían mensajes keepalive para mantener el enlace.
– Cuando se reciben mensajes update o keepalive se resetea el hold timer.
• Excepción: Hold timer = 0.
– Los mensajes se chequean y si se producen errores se genera una Notificación de
Error y se envía al vecino.
– En caso de recibir una Notificación de error se vuelve al estado Idle.

Negociación de vecinos BGP IV
• Tabla de estados BGP
• Información del estado
de los vecinos

Visualización de la tabla de vecinos

Comandos útiles para la resolución de problemas

Reinicio de las sesiones BGP
• Aplicación de directivas en BGP
• Mecanismos para forzar actualizaciones
– Hard Reset
• Cuando se cambia la configuración de BGP los cambios no aparecen
inmediatamente. Para forzar el borrado de la tabla BGP y resetear las sesiones
BGP se utiliza:
– Router#clear ip bgp *
– Resetea todas las sesiones con todos los routers “peer” : Established  idle
– Invalida el contenido de la tabla BGP
– Esto se puede utilizar en un laboratorio, pero se desaconseja en un router en
producción.
• Si se quiere reiniciar la relación de vecindad con un vecino en concreto se debe
utilizar:
– Router#clear ip bgp 10.1.1.1

Borrado de la tabla BGP.
• Soft Reset: clear ip bgp soft out
– Genera un reinicio en la información de salida
• Genera nuevos paquetes “update”
• No reinicia las sesiones o relaciones de vecindad BGP
• Es útil para le cambio de directivas salientes
• No tiene efecto si se cambian las directivas de modificación de tráfico entrante
– Neigbor [ip-address] soft-reconfiguration inbound
» Este comando debe utilizarse con precaución porque consume gran
cantidad de memoria

Debug ip bgp

Filtrado de rutas y Políticas de enrutamiento.
• El filtrado de rutas permite definir que rutas vamos a intercambiar los vecinos BGP.
– Es el elemento fundamental que se utiliza para definir las políticas de enrutamiento.
• Se puede determinar el “tráfico de datos” que se va a aceptar filtrando en las
actualizaciones salientes las rutas que se van a publicar.
• Se puede determinar que rutas utilizará el tráfico saliente, estableciendo filtros para
las actualizaciones entrantes enviadas desde los vecinos EBGP.
– Estos filtros permiten determinar que actualizaciones se inyectan en el SA y que
actualizaciones se publican fuera del SA.
– Además, estos filtros permiten manipular los atributos de las actualizaciones para
establecer políticas de enrutamiento más detalladas.
• Los filtros se pueden aplicar entre routers, que tienen establecidas sesiones BGP, y entre
protocolos de enrutamiento de un mismo router.
– Entre routers:
• Filtros entrantes  Rutas recibidas de otros vecinos BGP.
• Filtros salientes  Rutas que “deberían” ser publicadas a los vecinos.
– Entre protocolos de enrutamiento:
• Filtros entrantes  Rutas que se van a inyectar en el protocolo BGP.
• Filtros salientes  Rutas que se van a redistribuir en desde BGP a otro protocolo.

Introducción al proceso de enrutamiento en BGP.
• Descripción del proceso de enrutamiento en BGP. ¿Cómo se toman las decisiones de
enrutamiento en BGP?.
• Las rutas se intercambian en routers a través de mensajes de actualización.
• Un router BGP recibe un mensaje de actualización, aplica una serie de reglas y políticas al
mensaje de actualización, y después se pasa al resto de vecinos BGP (cumpliendo las
normas vistas anteriormente).
• La implementación de Cisco de BGP, mantiene una tabla de información con todas las
actualizaciones BGP en una tabla separada a la tabla de enrutamiento.
– En caso de que existan múltiples rutas al destino, BGP no publica todas esas rutas.
– Selecciona la mejor ruta y la envía a sus vecinos.
– El router puede generar actualizaciones de las redes que conoce por sí mismo.
– La rutas válidas generadas en el SA y las mejores rutas aprendidas de los vecinos
BGP se colocan en la tabla de enrutamiento, que es el elemento que determina por
donde se va a enviar la información.

Modelo del proceso de enrutamiento en BGP.
• Un router que ejecuta BGP tiene diferentes conjuntos de rutas y de “motores de políticas”
que se aplicarán a las rutas.
• Descripción del modelo:
– Rutas recibidas de los “peers”: BGP recibe rutas, mediante actualizaciones.
Dependiendo de la política de entradas, ninguna, algunas o todas estas rutas se
añadirán a la tabla BGP.
– Motor de políticas de entrada: Aplica las reglas de filtrado de rutas y manipulación de
atributos. (AS_PATH, IP prefix, ...).
• El motor de políticas de entrada se utiliza para manipular los atributos de ruta e
influir en el proceso de decisión. Afecta a las rutas que se van a utilizar para
alcanzar un determinado destino.
– Proceso de decisión: BGP aplica una serie de normas que se basan en el valor de los
atributos de la ruta para determinar cual es el mejor camino hacia un destino.
– Rutas utilizadas: Las mejores rutas son candidatas a ser publicadas a los demás
“peers”. Estas rutas también son candidatas a colocarse en la tabla de enrutamiento.

Modelo de procesamiento en BGP II.
– Motor de políticas de salida: Mecanismo para filtrar las rutas que se publican a los
vecinos y para modificar los atributos de las mismas. Este motor se aplica las mejores
rutas publicadas por los vecinos y a las generadas por el propio router, antes de que se
envíen a los demás vecinos.

Implementación de políticas con BGP.
• Las políticas se definen mediante “route-map”.
– Controlar y modificar la información de enrutamiento: atributos.
– Definir las rutas que son publicadas y a donde son publicadas.
Router(config)#route-map map-tag [permit | deny] [sequence-
number]
• Map-tag  Identifica al route-map.
• Sequence-number  Indica la posición que ocupa la sentencia dentro del route-
map.

Utilización de filtros para la implementación de políticas.
• Existen dos pasos básicos:
– Identificar el prefijo (la red) y la longitud del prefijo (máscara de subred) de la ruta a la
cual le queremos aplicar el filtro. Esta información es lo que hemos denominado NLRI
(Network-Layer Reachability Information), aunque muchas veces se hace referencia a
él simplemente como “prefijo”.
– Determinar la política a aplicar. Por ejemplo: permitir/denegar la actualización o
manipular alguno de los atributos.
• Técnicas para aplicar filtros.
– ROUTE-MAP: Los prefijos se pueden seleccionar en función de:
• Red de destino (prefijo de destino), Número de AS que generó la ruta, AS_PATH...
– La identificación se realiza mediante la sentencia match dentro del modo de
configuración de route-map.
– Cuando una ruta coincide con el criterio especificado en el route-map, se le
aplica la acción especificada en la sentencia set asociada.
– Pueden existir múltiples parejas de comandos match/set. Cuando se produce
la primera coincidencia (match), finaliza el proceso de comparación (como en
las ACL).
» El orden de las sentencias match/set es muy importante.

Redistribución de rutas en BGP
• En BGP es necesario considerar un factor que es crucial para el buen funcionamiento de
Internet: la estabilidad de las rutas. Existe una estrecha relación entre la estabilidad de la
rutas y el método con el que son inyectadas en BGP.
• Dinámicamente.
– Redistribución dinámica pura: Todas las rutas del IGP se redistribuyen en BGP.
Comando redistribute.
– Redistribución semiautomática: Solamente ciertas rutas se inyectan en BGP, por medio
del comando network  Se precisa un comando network por prefijo a publicar
• Se verifica que las rutas publicadas mediante network se han aprendido mediante
algún método válido IGP (Comando no synchronization).
• Estáticamente  Asegura la estabilidad de las tablas de enrutamiento.
– Problema: definición manual de las rutas.

Problemas en la redistribución de rutas dinámica en BGP
• El modelo semiautomático no siempre es posible: ¿cómo publicamos 60.000 redes?
• El modelo automático presenta una serie de inconvenientes:
– Direcciones privadas, prefijos inadecuados
• La redistribución mútua  Bucles de enrutamiento.
• Solución?
– Diseño adecuado de una estrategia de filtrado de rutas.
• Por ejemplo: Solamente se redistribuyen en BGP las rutas internas de los
protocolos IGP que son capaces de determinar si la ruta es interna o externa
(OSPF, EIGRP).

Problemas en la redistribución de rutas dinámica en BGP

Ejemplo de redistribución en BGP.
RTB(config-router)#neighbor 10.1.1.2 route-map BLOCK-BAD-ADDRESSES out
RTB(config-router)#redistribute ospf 1 match internal metric 50
RTB(config-router)#redistribute static
RTB(config-router)#neighbor 10.1.1.2 route-map BLOCK-BAD-ADDRESSES out
RTB(config-router)#network 192.168.1.0
RTB(config-router)#network 192.168.2.0

Ejemplo de VPN sobre MPLS en Capa 3
• Los proveedores de serivicos también suelen ofrecer VPNs sobre MPLS en capa 3
– Las VPN proporciona un servicio de capa 3 a través del núcleo del ISP
• los routers borde de la empresa A se conectan a los routers borde del ISP
utilizando diferentes subredes
– Se necesita enrutamiento entre el cliente y el proveedor

BGP Enrutamiento entre SA

Recommended

More Related Content

What's hot

What's hot (20)

Similar to BGP Enrutamiento entre SA

Similar to BGP Enrutamiento entre SA (20)

More from Francisco Javier Novoa de Manuel

More from Francisco Javier Novoa de Manuel (6)

Recently uploaded

Recently uploaded (20)

BGP Enrutamiento entre SA