前文我們了解了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狀態循環；