둘 다 TCP 연결을 설정하려고 할 때 FSM에서 두 가지 다른 상태를 갖는 것은 어떤 의미입니까?
답변
BGP 피어는 유휴 상태. 유휴 상태에서 피어는 서로 인접성을 형성하도록 구성되었지만 아직 통신을 시작하거나 수신하지 않았습니다.
BGP는 TCP를 전송으로 사용합니다. BGP 인접성, 첫 번째 단계는 TCP 연결을 설정하는 것입니다. 두 피어가 모두 IDLE 상태에있는 동안 두 피어는 각각 독립적 인 간격으로 주기적으로 TCP 연결을 시작하려고 시도합니다 (BGP 피어링 구성이 실제로 완료된시기에 따라).
한 피어가 SYN을 사용하여 TCP 3 방향 핸드 셰이크를 시작 하면 해당 피어가 활성
상태.이 상태는 로컬 라우터가 활성 TCP 연결을 시도하고 있음을 나타냅니다.
다른 피어가 수신 할 때 해당 피어의 TCP SYN이 있으면 Connect 상태로 전환됩니다. 이 상태는 로컬 라우터가 다른 라우터로부터 TCP 시작을 수신했으며 SYN ACK로 응답했음을 나타냅니다.
여기에서 두 피어는 나머지 상태 인 Open Sent, Open Confirmed, 설립 됨.
요약 :
- 활성 주-지역 라우터가 TCP SYN을 보냈습니다
- 연결 상태-로컬 라우터 해당 피어로부터 TCP SYN을 방금 수신 했습니다
인접성을 형성하기위한 “시작”BGP 스피커의 상태 전환은 다음과 같습니다. Idle, Active, Open Sent, Open Received, Established
인접을 형성하기위한 “응답”BGP 스피커의 상태 전환은 다음과 같습니다. Idle, Connect, Open Sent, Open Received, Established
주의, TCP 핸드 셰이크를 시작한 피어 만 Active 상태를 통과합니다. 그리고 TCP 핸드 셰이크를 시작하지 않은 피어 만 Connect 상태를 통과합니다.
증명하는 몇 가지 디버그 추가 그 행동. Cisco 라우터 코드 버전 15.4 (1) T입니다.
R1 (9.9.12.1)과 R2 (9.9.12.2) 사이의 BGP 피어링 세션에서 가져온 것입니다.
R2는 이 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 다른 라우터에서 확인 됨 :
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 이것은 개시자인 R2의 (필터링 된) 디버그입니다 :
$ 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 그리고 이것은 응답자 인 R1의 (필터링 된) 디버그입니다 :
$ 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 댓글
- 실제로 활성 및 연결 상태가 거꾸로 있습니다. 예를 들어 RFC는 활성 상태에 대해 다음과 같이 말합니다. " 활성 상태 :이 상태에서 BGP FSM은 듣기 하여 피어 획득을 시도합니다. b> 및 TCP 연결 수락 " 또한 " 연결 상태 :이 상태에서 BGP FSM은 TCP 연결이 완료되기를 기다리고 있습니다. " TCP SYN을 보냈습니다.
- 안녕하세요 @RonMaupin. 나는 ' 그렇다고 생각하지 않습니다. 나는 그것을 작성하고 실험 한 후에 궁금 해졌고, 내가 설명했던대로 Active / Connect 상태가 작동하는지 확인했습니다. ' " 깔끔한 " 디버그 출력을 모아서 답변.
- @RonMaupin 방금 디버그를 추가했습니다. 위를 참조하세요. 또한 저는 ' 시스코가 말한 보다 시스코가 하는 일 에 훨씬 더 관심이 있습니다. 제가 ' 디버그를 잘못 해석하고 있다고 생각 / 의심되는 경우 언제든지 알려주세요.
- 내가 보는 유일한 것은 응답자가 갔다는 것입니다. TCP 연결이 완료된 후 Idle에서 Connect로. 내 대답에서 나는 SYN / ACK를 보낸 후라고 말했습니다. 최종 ACK를 수신 한 후 실제로 전환되는 것 같습니다.
- " 10 월 28 일 17 : 06 : 36.971 : BGP : 9.9.12.1 active went을 해석합니다. R1이 Idle에서 Active로 이동하므로 Idle에서 Active로 ". R2가 TCP 세션을 시작하므로 @RonMaupins보기를 확인합니다.
