Jaka jest różnica między stanem połączenia a stanem aktywnym protokołu BGP?

Peery BGP zaczynają się za Bezczynny stan. W stanie bezczynności peery zostały skonfigurowane tak, aby tworzyły wzajemne sąsiedztwo, ale jeszcze nie zainicjowały ani nie odebrały żadnej komunikacji.

BGP używa protokołu TCP jako transportu. Przyleganie BGP, pierwszym krokiem jest ustanowienie połączenia TCP. Podczas gdy obaj peery są w stanie IDLE, każdy z nich będzie okresowo próbować zainicjować połączenie TCP w niezależnych odstępach czasu (na podstawie faktycznego zakończenia konfiguracji komunikacji równorzędnej BGP).

Kiedy jeden peer inicjuje potrójne uzgadnianie TCP z SYN, ten peer przechodzi w Aktywny stan. Ten stan wskazuje, że lokalny router aktywnie próbuje zainicjować połączenie TCP.

Gdy drugi peer odbiera TCP SYN od swojego peera, przejdzie w stan Połącz . Ten stan wskazuje, że lokalny router odebrał inicjację TCP od innego routera i odpowiedział / -a potwierdzeniem SYN ACK.

Stamtąd obaj peery przechodzą przez pozostałe stany: Open Sent, Open Confirmed, Utworzono.

Podsumowując:

• Aktywne stan – lokalna router właśnie wysłał TCP SYN
• Connect stan – router lokalny właśnie otrzymał TCP SYN od swojego partnera

„Inicjujące przejścia stanu głośnika BGP” w celu utworzenia przylegania będą wyglądać następująco: Idle, Active, Open Sent, Open Received, Established

Przejścia stanu „odpowiadającego głośnika BGP” w celu utworzenia przylegania będą wyglądać następująco: Idle, Connect, Open Sent, Open Received, Established

Zauważ, że tylko peer, który zainicjował uzgadnianie TCP przechodzi przez stan Active. I tylko peer, który NIE zainicjował uzgadniania TCP, przechodzi przez stan Connect.

Dodanie kilku debugów, które dowodzą zachowanie. To jest kod routera Cisco w wersji 15.4 (1) T.

Pochodzi z sesji komunikacji równorzędnej BGP między R1 (9.9.12.1) a R2 (9.9.12.2).

R2 jest inicjator tej sesji 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 

Potwierdzony na drugim routerze:

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 

To jest (filtrowany) debug na R2, inicjator:

$ 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 

A to jest (filtrowany) debug na R1, odpowiadający:

$ 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 

Komentarze

• W rzeczywistości stany Aktywny i Połącz są wstecz. Na przykład dokument RFC mówi to o stanie aktywnym: " Stan aktywny: w tym stanie BGP FSM próbuje pozyskać partnera, nasłuchując i akceptując połączenie TCP. " Ponadto " Stan połączenia: w tym stanie BGP FSM czeka na zakończenie połączenia TCP. " Po wysłaniu TCP SYN.
• Cześć @RonMaupin. Nie ' nie wydaje mi się. Zaciekawiło mnie to po napisaniu tego i przetestowaniu, a to potwierdza, że stany Active / Connect działają tak, jak je opisałem. ' spróbuję połączyć " zgrabne " wyjście debugowania i dodać je do odpowiedź.
• @RonMaupin Właśnie dodałem debugowania, patrz wyżej. Ponadto ' bardziej interesuje mnie to, co Cisco robi , niż to, co mówi Cisco . Możesz mi powiedzieć, jeśli widzisz / podejrzewasz, że ' interpretuję błędy nieprawidłowo.
• Patrząc na to, widzę tylko, że odpowiadający poszedł z trybu bezczynności do połączenia po zakończeniu połączenia TCP. W mojej odpowiedzi powiedziałem, że było to po wysłaniu SYN / ACK. Wygląda na to, że faktycznie przechodzi po otrzymaniu ostatniego potwierdzenia.
• Zinterpretowałbym linię " 28 października 17: 06: 36.971: BGP: 9.9.12.1 poszedł ze stanu bezczynnego na aktywny ", gdy R1 przechodzi ze stanu bezczynnego do aktywnego. Ponieważ R2 inicjuje sesję TCP, potwierdziłoby to widok @RonMaupins.

TCP tworzy połączenie między dwoma peerami, a BGP używa TCP. Jeden uczestnik TCP spróbuje połączyć się z drugim uczestnikiem TCP i jest to stan connect.Jeden peer może nasłuchiwać połączenia (zwłaszcza po nieudanej próbie połączenia z jego strony) i jest to stan active.

BGP ma kilka stanów i każdy jest jasno udokumentowany w RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Opisy stanów i przechodzenie od jednego do drugiego (i / lub z powrotem) są naprawdę zbyt obszerne, aby je tutaj omawiać. Poniżej znajduje się obraz opisujący skończoną maszynę stanową BGP (FSM):

Dokument RFC zawiera pełny opis różnych stanów FSM i tego, co dzieje się na każdym etapie .

Zaczynając od stanu Idle, kiedy zdarzenie ManualStart lub AutomaticStart ma miejsce w systemie, zmienia swój stan na Connect, ale dzieje się pasywne wersje tych zdarzeń (ManualStart_with_PassiveTcpEstablishment lub AutomaticStart_with_PassiveTcpEstablishment), a następnie zmienia swój stan na Active. Zasadniczo, kiedy mówi się, że ma połączyć się z peerem, zmienia się w Connect, ale gdy mówi się, że ma nasłuchiwać peera, zmienia się na Active.

W stanie Connect, jeśli połączenie TCP nie powiedzie się, zmienia swój stan na Aktywny, aby nasłuchiwać połączenia od peera.

Gdy jest w stanie Aktywnym i ma miejsce zdarzenie ConnectRetryTimer_Expires, wówczas próbuje nawiązać połączenie TCP i przechodzi w stan Połącz.

To naprawdę dużo więcej, ale jest o wiele za duża dla takiej witryny.