Hola Juan.
Van respuestas a las preguntas. No dudes en repreguntar si algo no se entiende o no te convence.
1. El objetivo del mensaje de OPEN no es específicamente distinguir entre iBGP y eBGP.
El mensaje de OPEN es el primer mensaje intercambiado entre dos peers BGP, y en el cada enrutador envía información propia (por ejemplo su número de AS y su identificación), valor de parámetros (por ejemplo el Hold Time), y opcionalmente otros valores, por ejemplo las "capabilities" soportadas como el soporte de AS de 32 bits, el soporte de otras familias de direcciones (multiprotocol BGP), etc.
Si las opciones enviadas por el peer son compatibles con las del enrutador, entonces se establece la sesión, de lo contrario no se establece.
Como entre los datos intercambiados se encuentra el número de AS, entonces el enrutador puede verificar que coincide con el AS que tiene configurado para el vecino, a partir de esto si coincide con el suyo corresponde con BGP interno, de lo contrario es BGP externo.
Respecto a la verificación de la compatibilidad de las configuraciones entre ambos peers, se refiere justamente a lo que hace el enrutador con la información que recibe del vecino en el mensaje de OPEN. Por ejemplo si el enrutador A tiene configurado que su vecino pertenece al AS 12345, pero el vecino indica en el OPEN el AS 54321, el primer enrutador no completará el establecimiento. Otro ejemplo, si en el enrutador A se configura la familia de direcciones IPv6, y el enrutador B no indica que soporte la familia de direcciones correspondiente en sus capabilities, entonces A puede definir no establecer la sesión BGP
2. El campo Hold Time indica cuánto tiempo está dispuesto a mantener la sesión abierta el enrutador que lo envía sin recibir un keepalive o update del vecino. Cada enrutador envía su propuesta de Hold Time (en segundos), y se toma el mínimo de ambos valores para utilizarlo en ambas direcciones
Por defecto el keepalive se elige automáticamente como 1/3 del hold-time negociado
3. Un Route reflector es un enrutador como cualquier otro, solo que para ciertos vecinos (sus clientes) cambia la regla de reenvío de los prefijos recibidos por BGP interno.
Entonces cuando hablamos de "vecinos" del RR, hablamos de cualquier enrutador que tiene una sesión BGP con el enrutador.
Cuando te refieres a "directamente conectado", me gustaría clarificar por las dudas que para ser vecino en BGP no precisa tener una conexión directa, alcanza con poder llegar por IP, lo comento solo para que no genere confusiones.
Los clientes del RR son aquellos enrutadores que fueron configurados como clientes en el RR. Reciben todos los prefijos reflejados, y los prefijos que envían son reflejados a otros enrutadores.
Por ejemplo, si tenemos los siguientes enrutadores y sesiones BGP, donde RA es el enrutador que tiene a R1 y R2 configurados como clientes, asumiendo que hablamos de las rutas elegidas como mejor camino y no hay reglas de filtrado configuradas:
R5 (eBGP)
| / R1 (iBGP, cliente)
| /
RA ----- R2 (iBGP, cliente)
| \
| \ R3 (iBGP, no cliente)
R4 (iBGP, no cliente)
Cualquier prefijo recibido de R5 (BGP externo) se reenviará a todos los otros enrutadores conectados a RA (R1, R2, R3, R4).
Cualquier prefijo recibido de R4 se reenviará a R1 y R2 (clientes de RA), así como a R5 (externo), pero NO a R3. Es decir, NO se refleja entre vecinos iBGP no clientes.
Cualquier prefijo recibido de R1 se reenviará a R2 (cliente), R3 y R4 (no clientes) y R5 (externo). Es decir, lo enviado por un cliente SI se refleja tanto a clientes como no clientes.
Espero haber respondido las dudas.
Saludos,
Eduardo.
