Qual é a importância de ter dois estados diferentes no FSM quando ambos tentam estabelecer uma conexão TCP?
Resposta
Os pares do BGP começam em Inativo estado. No estado Idle, os pares foram configurados para formar uma adjacência um com o outro, mas ainda não iniciaram ou receberam qualquer comunicação.
O BGP usa TCP como seu transporte. Portanto, para que haja um Proximidade BGP, a primeira etapa é estabelecer uma conexão TCP. Enquanto ambos os pares estão no estado IDLE, eles tentarão, periodicamente, iniciar uma conexão TCP em intervalos independentes (com base em quando a configuração de peering BGP foi realmente concluída).
Quando um par inicia o handshake TCP de três vias com um SYN, esse par transita para Ativo estado. Este estado indica que o roteador local está ativamente tentando iniciar uma conexão TCP.
Quando o outro par recebe o TCP SYN de seu par, ele fará a transição para o estado Conectar . Este estado indica que o roteador local recebeu uma iniciação TCP do outro roteador e é / respondeu com um SYN ACK.
A partir daí, os dois pares continuam pelos estados restantes: Aberto, enviado, Aberto confirmado, Estabelecido.
Para resumir:
- Ativo estado – local roteador acaba de enviar um TCP SYN
- Conectar estado – roteador local acaba de receber um TCP SYN de seu par
As transições de estado do “iniciando” alto-falante BGP para formar a adjacência serão: Idle, Active, Open Sent, Open Received, Established
As transições de estado “respondendo” do alto-falante BGP “para formar a adjacência serão: Idle, Connect, Open Sent, Open Received, Established
Observe, apenas o par que iniciou o handshake TCP passa pelo estado Active. E apenas o par que NÃO iniciou o handshake TCP passa pelo estado Connect.
Adicionando algumas depurações que provam o comportamento. Este é o código do roteador Cisco Versão 15.4 (1) T.
Isso é de uma sessão de peering BGP entre R1 (9.9.12.1) e R2 (9.9.12.2).
R2 é o iniciador para esta sessão 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 no outro roteador:
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 é a depuração (filtrada) em R2, o 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 E esta é a depuração (filtrada) em R1, o respondente:
$ 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 Comentários
- Na verdade, você tem os estados Active e Connect para trás. Por exemplo, o RFC diz o seguinte sobre o estado ativo: " Estado ativo: neste estado, o BGP FSM está tentando adquirir um par escutando , e aceitando, uma conexão TCP. " Além disso, " Estado da conexão: neste estado, BGP FSM está esperando a conexão TCP ser completada. " Tendo enviado o TCP SYN.
- Olá @RonMaupin. Eu não ' acho que não. Fiquei curioso depois de escrevê-lo e analisá-lo, e ele confirma que os estados Active / Connect funcionam como eu os descrevi. Eu ' tentarei reunir " elegante " saída de depuração e adicioná-la ao resposta.
- @RonMaupin Acabei de adicionar as depurações, veja acima. Além disso, eu ' estou muito mais preocupado com o que a Cisco faz do que com o que a Cisco diz . Sinta-se à vontade para me dizer se você vir / suspeitar que eu ' estou interpretando as depurações incorretamente.
- Olhando para ele, a única coisa que vejo é que a resposta foi acionada de Inativo para Conectar após a conexão TCP ser concluída. Na minha resposta disse que foi após o envio do SYN / ACK. Parece que realmente faz a transição após receber o ACK final.
- Eu interpretaria a linha " 28 de outubro 17: 06: 36.971: BGP: 9.9.12.1 ativo foi de Inativo para Ativo " já que R1 vai de Inativo para Ativo. Visto que R2 está iniciando a sessão TCP, isso confirmaria a visualização @RonMaupins.
Resposta
O TCP cria uma conexão entre dois pares, e o BGP usa TCP. Um par TCP tentará se conectar ao outro par TCP e este é o estado connect.Um par pode escutar uma conexão (especialmente após uma tentativa de conexão malsucedida de sua parte), e este é o estado active.
O BGP tem vários estados, e cada um está claramente documentado no RFC 4271, A Border Gateway Protocol 4 (BGP-4) . As descrições dos estados e a movimentação de um para outro (e / ou vice-versa) são muito extensas para serem discutidas aqui. Abaixo está uma imagem que descreve a BGP Finite State Machine (FSM):
A RFC tem a descrição completa dos vários estados do FSM e o que acontece em cada etapa .
Começando com o estado Idle, quando um evento ManualStart ou AutomaticStart acontece no sistema, ele muda seu estado para Connect, mas as versões passivas desses eventos (ManualStart_with_PassiveTcpEstablishment ou AutomaticStart_with_PassiveTcpEstablishment) acontecem, então ele muda seu estado para Ativo. Basicamente, quando é instruído a se conectar a um par, ele muda para Conectar, mas quando instruído a escutar um par, ele muda para Ativo.
Quando no estado Conectar, se a conexão TCP falhar, ele muda seu estado para Ativo para ouvir uma conexão do par.
Quando no estado Ativo, e o evento ConnectRetryTimer_Expires acontece, ele tenta a conexão TCP e vai para o estado Conectar.
Há muito mais do que isso, mas é muito grande para um site como este.