前文我們瞭解了BGP的鄰居建立條件、優化以及BGP認證相關話題，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/15395723.html；今天我們來聊一聊BGP報文結構、型別和狀態相關話題；
BGP報文結構和型別
提示：BGP工作在應用層，其埠號為179；報文結構是7層封裝，BGP報文主要由兩種報文頭部組成，公共頭部和型別頭部；公共頭部主要用來描述bgp AS號，包頭長度，報文型別，版本資訊等等資訊，型別頭部主要用來描述不同型別的BGP報文相關屬性；BGP報文型別有5種，分別是open包、update包、Notification包、keepalive和route-refresh；其中open包主要用來建立鄰居使用，在鄰居建立以後相互傳送一次，後續不再傳送；keepalive包主要作用是維護鄰居關係，預設情況下bgp是每60秒傳送一次keepalive包向鄰居通告自己還“活”著；如果連續三個週期沒有收到鄰居的keepalive包，此時本端會認為鄰居掛掉；update包主要用來路由更新，其包裡的內容主要是用來描述更新的路由資訊和屬性；只要有路由更新對應都會向鄰居傳送更新；notification包主要用來傳送當檢測到錯誤，傳送後關閉BGP連線的資訊；Route-refresh包主要用來觸發請求鄰居重新通告路由；
BGP鄰居狀態
提示：BGP鄰居狀態有6種，分別是idle，connect，active，open-sent，open-confirm，established，其中idel狀態是最開始狀態，表示鄰居為空，沒有鄰居；當配置好鄰居資訊以後，如果在對應路由表中找到去往鄰居的路由，此時鄰居關係會從idel轉變為connect；如果沒有路由，則還是原來的idle狀態，即沒有傳送tcp三次握手請求報文的狀態；connect狀態表示發起TCP連線，等待tcp連線完成，即本端傳送TCP三次握手請求，等待對端回覆完成tcp三次握手的狀態，該狀態會有一個超時時長，如果在規定的時間內還是沒有建立tcp連線，該狀態會超時重試，即沒有鄰居回覆本端的三次握手請求的狀態；active狀態表示tcp建立失敗，繼續嘗試tcp連線，即tcp三次握手的報文已經傳送，但是由於某些錯誤導致tcp三次握手沒能正常建立的狀態，該狀態會有一個嘗試時間，如果嘗試tcp連線還是失敗則該狀態保持，如果tcp建立超時，則會從active狀態轉變為idle狀態，如果tcp建立成功則會從active狀態轉變為open-sent狀態表示tcp連線成功，並已傳送一次open包後的狀態；即本端三次握手成功建立，傳送open包以後的狀態；open-confirm表示對端收到本端傳送的open包後的狀態，如果沒有收到對端的open包，此時會從open-sent狀態進入active狀態，表示tcp連線失敗，或者錯誤的TCP連線，或者對端不認可和本端建立鄰居；established表示鄰居建立完成的狀態；即收到對端的傳送到keepalive包以後的狀態；open-sent/open-confirm/established這三種狀態一旦發生錯誤都會返回到idle狀態；
BGP鄰居建立過程和狀態轉換
提示：idle和connect狀態主要發生在鄰居建立初期，tcp三次握手階段，如果三次握手正常互動，對應狀態會從idle轉變為connect狀態，表示傳送了tcp三次握手請求，等待完成tcp三次握手；三次握手成功以後，如果傳送了open包，對應狀態會從connect狀態轉變為open-sent狀態，如果正確接收到對端的open包以後，對應狀態會從open-sent狀態轉變為open-confirm狀態，並向對端傳送keepalive包，通告本端的存活狀態；如果對端收到本端傳送的keepalive包以後，對應狀態會從open-confirm狀態轉變為established狀態；以上是bgp鄰居建立過程中幾種狀態切換過程；在established狀態下，BGP路由器可以和鄰居交換update、keepalive、Route-refresh報文和notification報文；
實驗：如下拓撲，配置BGP
R1的配置
sys sys R1 int g0/0/0 ip add 12.0.0.1 24 bgp 12 router-id 1.1.1.1 peer 12.0.0.2 as 12
R2的配置
sys sys R2 int g0/0/0 ip add 12.0.0.2 bgp 12 router-id 2.2.2.2 peer 12.0.0.1 as 12
只配置了R1未配置R2時，R1bgp鄰居狀態驗證
提示：此時R1並未傳送tcp三次握手請求，所以對應鄰居狀態還是idle狀態；表示正在查詢路由表去往鄰居的路由；
在R1查詢到對應去往鄰居的路由以後，傳送TCP三次握手請求後，對應鄰居狀態
提示：R1傳送三次握手請求後，對應鄰居從idle狀態轉變為connect狀態，表示傳送了三次握手請求，等待三次握手完成；
在R1上抓包
提示：在R1上抓包只有arp包，其原因是R2沒有配置，R1找不到R2的mac地址，所以一直髮送廣播請求R2的mac地址；
配置R2介面地址
驗證：在R1上檢視bgp鄰居狀態，看看有什麼變化沒有？
提示：可以看到對應鄰居狀態一直處於connect狀態；
在R1上抓包，檢視對應tcp三次握手的情況
提示：可以看到R1向R2的179埠發起三次握手請求，對端R2一直髮送重試；其原因是R2沒有配置bgp，當然179埠並不會處於監聽狀態；所以R1請求R2的179埠，對應R2回覆重試；
配置好R2 bgp鄰居資訊
在R1上檢視鄰居關係
提示：可以看到對應R1的鄰居關係為established，這個過程相對較快，中間的狀態我們看不到，但從上面的提示可以看到對應established的前面一個狀態為openconfirm狀態；
檢視R1上的抓包過程
提示：可以看到R1向R2發起三次握手請求，對應R2響應確認並向R1發起建立連線請求，對應R1確認，對應傳送open包，再後續傳送keepalive包；
在R1上配置鄰居2.2.2.2 對應as號為12
檢視鄰居狀態
提示：可以看到我們配置的2.2.2.2，對應鄰居狀態為idle，表示沒有傳送tcp三次握手請求；其原因是本地沒有去往2.2.2.2的路由，所以對應鄰居會一直處於idle狀態；
驗證：在R1上新增靜態路由去往2.2.2.2，看看對應鄰居狀態是否發生變化？
提示：可以看到在R1上新增靜態路由以後，對應bgp鄰居狀態從idle狀態變為了connect狀態；說明R1通過查詢路由表，已經向2.2.2.2發起tcp三次握手請求；
驗證：檢視R1的抓包，看看R1是否向2.2.2.2發起tcp三次握手？
提示：可以看到對應R1的確在向2.2.2.2傳送tcp三次握手請求；
在R2上新建lo介面並配置介面地址為2.2.2.2/32
再次驗證R1上2.2.2.2的鄰居狀態是否發生變化？
提示：可以看到R1上2.2.2.2鄰居狀態從connect狀態轉變為active狀態，這是為什麼呢？我們知道active狀態是tcp三次握手失敗，對應狀態；
在R1抓包檢視tcp三次握手情況
提示：可以看到R1向2.2.2.2發起三次握手請求，對應2.2.2.2也回覆並建立起tcp連線，對應R1向2.2.2.2傳送了open包以後，對應2.2.2.2又給R1傳送了斷開連線請求；說明R1和2.2.2.2並沒有建立起TCP連線，即tcp連線建立失敗，所以從connect轉態轉變為active狀態；其實這裡的原因是R2回覆R1的包其源地址為12.0.0.2和R1配置的鄰居2.2.2.2地址不匹配導致的；
驗證：在R2上更改更新源為lo2介面地址，看看鄰居狀態的變化
提示：在R2上更改更新源以後，對應和12.0.0.1鄰居狀態從established變為了idle，這是因為更新源發生變化導致tcp連線錯誤；所以從established狀態轉變為idle狀態；
在R1上驗證鄰居狀態
提示：可以看到此時R1上和2.2.2.2建立起鄰居，但是對應和12.0.0.2的鄰居狀態變為了active，這是因為從R2過來的包，其源地址為2.2.2.2，和本端配置的鄰居12.0.0.2不匹配，所以導致tcp連線建立失敗，所以在R1上看到和2.2.2.2正常建立tcp連線，鄰居正常，和12.0.0.2建立不起來TCP連線，鄰居狀態處於active狀態；
總結：指向bgp資料包源ip地址的路由不存在，即沒有鄰居路由，對應鄰居關係為idle；鄰居與錯誤地址建立對等關係，即源地址不匹配，導致鄰居狀態為active狀態；不存在該路由器的鄰居宣告,即對端未配置本端為鄰居，鄰居狀態會卡在active（如果對端未配置bgp會卡在connect狀態）；as號配置錯誤會導致對應鄰居狀態為active；以上原因都可能導致鄰居狀態在idle/active狀態迴圈；