¿Cuál es la importancia de tener dos estados diferentes en FSM cuando ambos intentan establecer una conexión TCP?
Respuesta
Los pares de BGP comienzan en Inactivo estado. En estado inactivo, los pares se han configurado para formar una adyacencia entre sí, pero aún no han iniciado ni recibido ninguna comunicación.
BGP usa TCP como transporte. Entonces, para que haya un Adyacencia BGP, el primer paso es establecer una conexión TCP. Si bien ambos pares están en estado IDLE, cada uno de ellos intentará periódicamente iniciar una conexión TCP a intervalos independientes (según el momento en que se completó la configuración de emparejamiento BGP).
Cuando un par inicia el protocolo de enlace de tres vías TCP con un SYN, ese par hace la transición a Active estado. Este estado indica que el enrutador local está activamente intentando iniciar una conexión TCP.
Cuando el otro par recibe el TCP SYN de su par, pasará al estado Connect . Este estado indica que el enrutador local ha recibido una iniciación de TCP del otro enrutador y ha respondido con un SYN ACK.
Desde allí, ambos pares continúan con los estados restantes: Abierto enviado, Abierto confirmado, Establecido.
Para resumir:
- Activo estado – local el enrutador acaba de enviar un TCP SYN
- Connect estado – enrutador local acaba de recibir un TCP SYN de su par
Las transiciones de estado del hablante BGP «iniciador» para formar la adyacencia serán: Idle, Active, Open Sent, Open Received, Established
Las transiciones de estado del altavoz BGP «que responde» para formar la adyacencia serán: Idle, Connect, Open Sent, Open Received, Established
Observe, solo el par que inició el protocolo de enlace de TCP pasa por el estado Active. Y solo el par que NO inició el protocolo de enlace de TCP pasa por el estado Connect.
Añadiendo algunas depuraciones que prueban el comportamiento. Este es el código de enrutador Cisco Versión 15.4 (1) T.
Esto es de una sesión de intercambio de tráfico BGP entre R1 (9.9.12.1) y R2 (9.9.12.2).
R2 es el iniciador de esta sesión TCP:
router1# show ip bgp neighbors | i ^BGP|host BGP neighbor is 9.9.12.2, remote AS 2323, external link Local host: 9.9.12.1, Local port: 179 Foreign host: 9.9.12.2, Foreign port: 43876 Confirmado en el otro enrutador:
router2# show ip bgp neighbors | i ^BGP|host BGP neighbor is 9.9.12.1, remote AS 1111, external link Local host: 9.9.12.2, Local port: 43876 Foreign host: 9.9.12.1, Foreign port: 179 Esta es la depuración (filtrada) en R2, el iniciador:
$ cat BGP-Peering_Initiator.txt | grep -e "TCP src" -e "went from" *Oct 28 17:06:36.971: BGP: 9.9.12.1 active went from Idle to Active *Oct 28 17:06:36.972: TCP src=43876, dst=179, seq=1526684246, ack=0, win=16384 SYN *Oct 28 17:06:36.975: TCP src=179, dst=43876, seq=2072809595, ack=1526684247, win=16384 ACK SYN *Oct 28 17:06:36.975: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK *Oct 28 17:06:36.977: BGP: 9.9.12.1 active went from Active to OpenSent *Oct 28 17:06:36.982: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK PSH *Oct 28 17:06:36.985: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK *Oct 28 17:06:36.985: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.985: BGP: 9.9.12.1 active went from OpenSent to OpenConfirm *Oct 28 17:06:36.985: TCP src=43876, dst=179, seq=1526684304, ack=2072809653, win=16327 ACK PSH *Oct 28 17:06:36.987: TCP src=179, dst=43876, seq=2072809653, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.987: BGP: 9.9.12.1 active went from OpenConfirm to Established Y esta es la depuración (filtrada) en R1, el respondedor:
$ cat BGP-Peering_Responder.txt | grep -e "TCP src" -e "went from" *Oct 28 17:06:36.973: TCP src=43876, dst=179, seq=1526684246, ack=0, win=16384 SYN *Oct 28 17:06:36.974: TCP src=179, dst=43876, seq=2072809595, ack=1526684247, win=16384 ACK SYN *Oct 28 17:06:36.976: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK *Oct 28 17:06:36.976: BGP: 9.9.12.2 passive went from Idle to Connect *Oct 28 17:06:36.983: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK PSH *Oct 28 17:06:36.984: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK *Oct 28 17:06:36.984: BGP: 9.9.12.2 passive went from Connect to OpenSent *Oct 28 17:06:36.984: BGP: 9.9.12.2 passive went from OpenSent to OpenConfirm *Oct 28 17:06:36.985: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.986: TCP src=179, dst=43876, seq=2072809653, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.986: TCP src=43876, dst=179, seq=1526684304, ack=2072809653, win=16327 ACK PSH *Oct 28 17:06:36.986: BGP: 9.9.12.2 passive went from OpenConfirm to Established Comentarios
- De hecho, tiene los estados Activo y Conectado al revés. Por ejemplo, el RFC dice esto sobre el estado activo: " Estado activo: en este estado, BGP FSM está tratando de adquirir un par escuchando y aceptando una conexión TCP. " Además, " Estado de conexión: en este estado, BGP FSM está esperando que se complete la conexión TCP. " Habiendo enviado el TCP SYN.
- Hola @RonMaupin. No ' creo que sí. Sentí curiosidad después de escribirlo y analizarlo, y confirma que los estados Activo / Conectado funcionan como los describí. ' intentaré juntar la salida de depuración " neat " y agregarla a la respuesta.
- @RonMaupin Acabo de agregar las depuraciones, ver arriba. Además, ' estoy mucho más preocupado por lo que hace Cisco hace que lo que dice de Cisco. No dudes en decirme si ves / sospechas que ' estoy interpretando las depuraciones incorrectamente.
- Mirándolo, lo único que veo es que el respondedor fue de Inactivo a Conectar después que se complete la conexión TCP. En mi respuesta dije que fue después de enviar el SYN / ACK. Parece que en realidad cambia después de recibir el ACK final.
- Interpretaría la línea " 28 de octubre 17: 06: 36.971: BGP: 9.9.12.1 activo fue de inactivo a activo " ya que R1 pasa de inactivo a activo. Dado que R2 está iniciando la sesión TCP, esto confirmaría la vista de @RonMaupins.
Responder
TCP crea una conexión entre dos pares, y BGP usa TCP. Un par de TCP intentará conectarse al otro par de TCP, y este es el estado connect.Un par puede escuchar una conexión (especialmente después de un intento de conexión fallido de su parte), y este es el estado active.
BGP tiene varios estados y cada uno está claramente documentado en RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Las descripciones de los estados y el movimiento de uno a otro (y / o de regreso) es realmente demasiado grande para discutirlo aquí. A continuación se muestra una imagen que describe la máquina de estado finito (FSM) de BGP:
El RFC tiene una descripción completa de los distintos estados del FSM y lo que sucede en cada etapa .
Comenzando con el estado inactivo, cuando ocurre un evento ManualStart o AutomaticStart en el sistema, cambia su estado a Connect, pero las versiones pasivas de esos eventos (ManualStart_with_PassiveTcpEstablishment o AutomaticStart_with_PassiveTcpEstablishment) sucede, luego cambia su estado a Active. Básicamente, cuando se le dice que se conecte a un par, cambia a Conectar, pero cuando se le dice que escuche a un par, cambia a Activo.
En el estado Conectar, si falla la conexión TCP, cambia su estado a Activo para escuchar una conexión del par.
Cuando está en el estado Activo, y ocurre el evento ConnectRetryTimer_Expires, entonces intenta la conexión TCP y entra en el estado Conectar.
Realmente hay mucho más que eso, pero es demasiado grande para un sitio como este.