|
Border Gateway Protocol
Introducción
Terminología BGP
Operación de BGP
Formato de la cabecera del mensaje
Negociación de Vecindad
Finite State Machine
Selección de Rutas
Configuración de BGP
Configuración iBGP and eBGP
Configuración de eBGP Multihop
BGP es conocido como el routing protocol para la Internet. Es usado para compartir información de ruteo entre los diferentes Sistemas Autónomos (AS).
BGP v1 fue un classfull y no permitió sumarización de rutas. BGP v4 puede hacer sumarización de rutas y CIDR.
BGP utiliza TCP como protocolo confiable para la transmisión. Usa la puerto 179 para establecer las conexiones.
BGP no se preocupa del ruteo INTRA-AS
AS: Conjunto de dispositivos bajo el mismo control administrativo, que es usado por un IGP para ruteo INTRA-AS y un EGP para ruteo INTER-AS.
BGP Speaker: Cualquier equipo de ruteo que esta arrancando un BGP routing procedo.
PEERS: Se forman cuando dos BGP Speakers hacen una conexión TCP entre ellos.
eBGP: External Border Gateway Protocol, es el protocolo de ruteo usado para intercambiar información de ruteo entre BGP peer en diferentes AS
iBGP: Internal Border Gateway Protocol, es el protocolo de ruteo usado para intercambiar información de ruteo entre BGP peers en el mismo AS.
INTER-AS routing: Es el routing que ocurre entre diferentes AS.
INTRA-AS routing: Es el routing que ocurre dentro del mismo AS.
- Todos los BGP Speakers dentro del mismo AS usan iBGP para comunicarse entre ellos.
- Multiples BGP speaking dentro del mismo AS deben ser peer con cada otro.
- iBGP debe ser un full mesh, no significa que todos los dispositivos deban ser conectados con cada otro, aunque todos deben ser alcanzables a través de capa 3.
- eBGP requiere conectividad capa 3 entre ellos.
- Después de formar peers, se usa la información para crear mapas libres de loop del AS involucrado (BGP Tree)
- Una vez formado los peers, y se ha creado el árbol BGP, ellos inician el intercambio de información de ruteo.
- El BGP speaking, primero intercambia su tabla BGP enteramente y luego son actualizaciones incrementales de su tabla de ruteo BGP y Keepalive messages para mantener la conexión.
El mensaje básico del fomato de la cabecera está dividido en:
- Un campo Marker de 16 Byte
- Un campo Length de 2 Byte
- Un campo Type de 1 Byte
Marker: Es usado para detectar una pérdida de sincronismo entre un conjunto de peers y también autentifica mensajes entrantes.
Length: Indica el largo del mensaje entero incluyendo el campo Marker. El valor es entre 19 y 4096 octetos.
Type: Indica el tipo de código de los mensajes. Hay 4 valores:
Type Field Values |
Type Value |
Message Type |
1 |
OPEN message |
2 |
UPDATE message |
3 |
NOTIFICATION message |
4 |
KEEPALIVE message |
Mensaje Open
Es el primer mensaje enviado después que una sesión TCP se ha formado. Cuando el mensaje Open es aceptado, un mensaje Keepalive confirma el mensaje Open. Luego incrementales mensajes Updates, mensajes de Notificación y Keepalive serán intercambiados entre los BGP peers.
El mensaje Open es de tamaño fijo en el BGP Header
Mensaje Update
Después que se ha formado peers, ellos intercambian incrementales mensajes Update. Contienen la información de ruteo para BGP y es usado para construir un ambiente libre de loop.
El mensaje Update contiene al menos una ruta feasible y multiples rutas unfeasible para retirar.
Mensaje Keepalive
Son usados para asegurar conectividad entre peers, es de tamaño fijo. Un keepalive mensaje es enviado para restaurar el Hola Timer. El intervalo es de un tercio del valor del hola timer. Esto es porque el hola timer debe ser al menos 3 segundos si este no es cero.
Un keepalive no será enviado si un mensaje update fue enviado. Si el hola timer es seteado a cero, un keepalive nunca será enviado.
Mensaje de Notificación
Cada vez que un error ocurre durante una sesión BGP, el BGP speaker genera un mensaje de notificación. Tan pronto como el BGP speaker genera la notificación la sesión es terminada
Negociación de Vecindad (Neighbor)
Antes que BGP puedan comunicarse deben ser vecinos o peers. El primer paso es formar una sesión TCP 179 con cada otro. Después el BGP speaker envía un mensaje Open, para luego enviar incrementales mensajes Update, notificación y keepalive.
El proceso de la formación de vecinos es conocido como Finite State Machine
Hay seis posibles estados:
- Idle: Es el primer estado, el BGP speaker espera por un BGP Start event, para luego iniciar el connect retry timer, se inicia el TCP connector al BGP speaker que quiere como peer y escucha cualquier conexión iniciado por el otro BGP speaker.
El BGP speaker entonces cambiará su estado a connection . Si hay errores la sesión TCP finaliza y el estado vuelve a estado Idle .
- Connection: BGP está esperando por la conexión TCP sea formado. Una vez que la conexión es completada, se limpia el connect retry timer, y se envía un mensaje Open al remoto BGP speaker y pasa al estado Open Sent. Si la conexión TCP no es formada, se restaura el connect retry timer, continua escuchando un intento de conexión del remoto BGP speaker y su estado pasa a Activo. Si el connect retry timer expira, se resetea el timer, se inicia una sesión TCP, se sigue escuchando por intentos de conexión del remoto y permanece en el estado conexión. Si hay un error se cierra la conexión TCP y se pasa al estado Idle.
- Active: El BGPspeaker está intentando iniciar una sesión TCP. Una vez que la conexión es completada, se limpia el conté retry timer, inicialización completa, y se envía un Open al remoto BGP speaker y pasa al estado Open Sent .
- Open Sent: El BGP speaker está esperando recibir un Open desde el remoto BGP speaker. Al recibir el Open todos los campos serán chequeados. Si un error es detectado enviará un mensaje de notificación al remoto y terminará el TCP y pasa al estado Idle. Si ningún error se ha encontrado en el Open el BGP speaker enviará un keepalive y negocian los valores del keepalive timer y hold timer. Un valor de 0 significa que el keepalive timer y el hold timer nunca serán reseteados. Después de la negociación se determinará si la conexión será iBGP o eBGP, porque esto afectará el proceso de UPdate. Una vez que que el tipo de BGP es determinado, pasa al estado Open Confirm. Durante este estado es posible recibir un TCP disconnect, si esto ocurre el estado pasa a Activo. Si hay un error pasa al estado Idle.
- Open Confirm: El BGP speaker esperará recibir un keepalive desde el remoto. Una vez recibido, se resetea el hola timer y pasa al estado Establecido . En este punto la relación de peer ha sido formada. Si una notificación es recibido en vez de un keepalive pasa al estado Idle. En caso que el hola timer expira antes que el keepalive es recibido, el BGP speaker enviará una notificación al remoto y terminará la sesión TCP y su estado a Idle.
- Establecido: Todas las negociaciones están completadas. Los BGP peers intercambiarán Update, Keepalive. Cada vez que se recibe un Update o Keepalive éste reseteará su hold timer. Si el hold timer expira antes que un Update o Keepalive es recibido, el BGP speaker enviará una notificación a su peer, terminará la sesión TCP y pasará al estado Idle. Una vez alcanzado el estado Establecido se inicia el intercambio de información de ruteo.
Cuando se aprende una ruta, esta necesita pasar a través del Routing Information Base (RIB). Un RIB está dividido en:
- Adj-RIBs-In
- Loc-RIB
- Adj-RIBs-Out
- El BGP speaker recibe las rutas BGP
- Las rutas son colocadas en el Adj-RIBs-In
- Las rutas son enviadas al Inbound Policy Engine
- el IPE filtra y manipula rutas basadas en la política seteada por el administrador. Las rutas que son filtradas son sacadas
- Las demás rutas BGP son enviadas al Loc-RIB
- Se almacena las rutas en el Loc-RIB. El router usa estas rutas para hacer decisiones de ruteo BGP
- Las rutas son direccionadas al Outboind Policy Engine.
- El OPE filtra y manipula rutas basado en las políticas seteada por el administrador. Las rutas que son filtradas son sacadas.
- Las rutas son enviadas al Adj-RIBs-Out
- Las rutas recibidas son almacenadas en el Adj-RIBs-Out
- Todas las rutas son advertidas a los peers.
Para habilitar BGP se ocupan el siguiente comando:
router bgp Autonomous System Number
Para formar relación de vecindad se utiliza el siguiente comando:
neighbor address remote-as autonomous system number
Usaremos el siguiente ejemplo para hacer la configuración:
R1# conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)# router bgp 100 R1(config-router)# ^Z R1# R2# conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)# router bgp 200 R2(config-router)# ^Z R2# R3# conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)# router bgp 300 R3(config-router)# ^Z R3# Después de habilitar BGP configuraremos la relación con los otros vecinos R1# conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)# router bgp 100 R1(config-router)# neighbor 10.10.10.2 remote-as 200 R1(config-router)# ^Z R1# R2# conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)# router bgp 200 R2(config-router)# neighbor 10.10.10.1 remote-as 100 R2(config-router)# neighbor 20.20.20.1 remote-as 300 R2(config-router)# ^Z R2# R3# conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)# router bgp 300 R3(config-router)# neighbor 20.20.20.2 remote-as 200 R3(config-router)# ^Z R3#
Esto es todo para configurar básicamente BGP
Ahora configuraremos iBGP en la figura de arriba. Usaremos direcciones Loopback para cada participante del iBGP. Se necesita entrar el siguiente comando adicional
neighbor address update-source interface
Sin este commando el BGP speakers nuca formará peers con el otro. La razón es porque el BGP speaker espera recibir el paquete desde la dirección loopback del BGP speaker , sin el commando update-source, el paquete BGP usará la dirección de la interface de salida del BGP speaker. El remoto BGP speaker recibirá el paquete y lo ignora puesto que no es la dirección que esperaba ver
Las direcciones Loopback son la siguientes
R2 Lo0-2.2.2.2
R3 Lo0-3.3.3.3
R4 Lo0-4.4.4.4
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router bgp 100
R1(config-router)# ^Z
R1#
R2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# router bgp 200
R2(config-router)# no synchronization
R2(config-router)# ^Z
R2#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router bgp 200
R3(config-router)# no synchronization
R3(config-router)# ^Z
R3#
R4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# router bgp 200
R4(config-router)# no synchronization
R4(config-router)# ^Z
R4#
R5# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)# router bgp 300
R5(config-router)# ^Z
R5#
Ahora que está habilitado BGP asignaremos los vecinos
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router bgp 100
R1(config-router)# neighbor 10.10.10.2 remote-as 200
R1(config-router)# ^Z
R1#
R2# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)# router bgp 200
R2(config-router)# neighbor 10.10.10.1 remote-as 100
R2(config-router)# neighbor 3.3.3.3 remote-as 200
R2(config-router)# neighbor 4.4.4.4 remote-as 200
R2(config-router)# neighbor 3.3.3.3 update-source Lo0
R2(config-router)# neighbor 4.4.4.4 update-source Lo0
R2(config-router)# ^Z
R2#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router bgp 200
R3(config-router)# neighbor 2.2.2.2 remote-as 200
R3(config-router)# neighbor 4.4.4.4 remote-as 200
R3(config-router)# neighbor 2.2.2.2 update-source Lo0
R3(config-router)# neighbor 4.4.4.4 update-source Lo0
R3(config-router)# ^Z
R3#
R4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# router bgp 200
R4(config-router)# neighbor 20.20.20.1 remote-as 300
R4(config-router)# neighbor 3.3.3.3 remote-as 200
R4(config-router)# neighbor 2.2.2.2 remote-as 200
R4(config-router)# neighbor 3.3.3.3 update-source Lo0
R4(config-router)# neighbor 2.2.2.2 update-source Lo0
R4(config-router)# ^Z
R4#
R5# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)# router bgp 300
R4(config-router)# neighbor 20.20.20.2 remote-as 200
R5(config-router)# ^Z
R5#
La configuración del iBGP comparado a eBGP no es diferente
Hay veces en que el remoto BGP speaker no está directamente conectado. Cuando esto ocurre es conocido como un eBGP multihop. Hay un par de diferentes razones que esto puede ocurrir:
- Hay otro router entre el local BGP speaker y el remoto BGP speaker que no puede arrancar BGP.
- La fuente de una conexión BGP de una interface loopback en al menos un BGP speakers.
Se usa el siguiente commando:
neighbor address ebgp-multihop [ ttl ]
En la figura R2 no participa en BGP
R1 Lo0-1.1.1.1
R3 Lo0-3.3.3.3
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router bgp 100
R1(config-router)# neighbor 3.3.3.3 remote-as 200
R1(config-router)# ^Z
R1#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router bgp 200
R3(config-router)# neighbor 1.1.1.1 remote-as 100
R3(config-router)# ^Z
R3#
R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router bgp 100
R1(config-router)# neighbor 3.3.3.3 update-source Lo0
R1(config-router)# neighbor 3.3.3.3 ebgp-multihop
R1(config-router)# ^Z
R1#
R3# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)# router bgp 200
R3(config-router)# neighbor 1.1.1.1 update-source Lo0
R3(config-router)# neighbor 1.1.1.1 ebgp-multihop
R3(config-router)# ^Z
R3#
Por ahora terminamos con la configuración Básica de BGP en un segundo curso abordaremos opciones avanzadas de BGP
Temario |
Cursos enviados |
|
Haz AulaFácil tu página de inicio 
Envía esta página a un amigo