HCIP-17? BGP基礎2

一、bgp的路由黑洞問題

1.bgp的同步功能

ipv4-family unicast? IPV4的地址簇

undo synchronization? 關閉BGP同步功能

bgp的同步功能原理

當邊界路由器從ibgp鄰居收到一條路由后，會使用該路由和igp路由表進行比較。

如果在igp路由表中存在該路由即BGP同步

如果在igp路由表中不存在該路由即BGP不同步

如果bgp同步，邊界路由器將會把該路由條目傳遞給其他的ebgp鄰居。

如果bgp不同步，邊界路由器將不會把該路由條目傳遞給其他ebgp鄰居。

2.將bgp路由引入igp

不推薦。

原理上可以，但是，從路由承載能力上不行

3.as內部采用全互聯模式（fullmesh）

4.使用gre隧道技術

[R2]int Tunnel 0/0/0

[R2-Tunnel0/0/0]ip add 24.1.1.2 24

[R2-Tunnel0/0/0]tunnel-protocol gre

[R2-Tunnel0/0/0]source g0/0/0

[R2-Tunnel0/0/0]destination 34.1.1.4

[R4]int Tunnel 0/0/0

[R4-Tunnel0/0/0]ip add 24.1.1.4 24

[R4-Tunnel0/0/0]tunnel-protocol gre

[R4-Tunnel0/0/0]source g0/0/1

[R4-Tunnel0/0/0]destination 23.1.1.2

5.通過lsp隧道解決路由黑洞

二、bgp的路由是如何產生的

1.通過network宣告路由表中已存在的路由條目

2.import-route 引入路由

被引入的路由需要在全局路由表加表。

3.自動聚合產生的路由條目

只能聚合import-route進來的路由條目，進行主類聚合。

被聚合的明細路由會被抑制。無法進行傳遞，只會傳輸聚合后的主類的路由

4.手動聚合產生

[R1-bgp]aggregate 172.16.2.0 255.255.254.0 detail-suppressed?? 手動抑制明細。

三、bgp報文open報文

open報文

它就相當于OSPF里面的hello報文。用于建立bgp的鄰居的連接，協商bgp參數的報文

update報文用于bgp鄰居之間交互路由信息及路由屬性的報文。

notification報文，差錯報文。用于報錯的信息的傳遞，并且中斷鄰居關系的報文。

keepalive報文用于保持鄰居連接的報文

refresh報文用于在改變策略之后。請求鄰居重新發送路由信息，并且只有支持刷新能力的設備才能響應這個報文

四、bgp的鄰居狀態機

1.idle叫初始狀態，bgp初始狀態。

在進入這個idle狀態時，會觸發華為的start事件，這個事件時間為32秒。

在這個時間之后，才開始建立該peer的三次握手。建立TCP連接，在發送了syn以后。

進入到connect狀態

常見的幾種idle狀態的原因：

如果沒有去往該peer的路由，就無法發送syn。此時，該peer會一直卡在idle狀態。

收到了notification報文之后會回退到idle狀態。

手動掛起鄰居：在鄰居表中表現為idle (admin)。

2.connect狀態（連接狀態）

在這個狀態下，bgp會啟動連接重傳定時器（connect retry默認為32秒鐘），用于等待TCP完成三次握手。

向鄰居發起syn后，就會進入到這個狀態。在這個狀態完成TCP三次握手。

如果TCP三次握手完成，則向該鄰居發送open報文，然后轉到opensent狀態。

如果TCP三次握手失敗，將會把這個peer狀態改為active。

如果重傳定時器超時，bgp沒有收到鄰居的響應。那么會卡在connect狀態

常見的幾種connect狀態原因。

鄰居沒有給我響應。

我發出的syn在沿途中遇到了阻礙，沒有到達對方。沿途路由不可達

ebgp鄰居沒有配置ttl多跳。

總結：卡在connect狀態其實就是鄰居沒有給我響應。

3.active狀態（活躍的狀態）

當TCP三次握手失敗時。才會進入這個狀態。

如果在多次嘗試下，TCP三次握手成功了。那么bgp會向該peer發送open報文。關閉重傳定時器，轉至opensent狀態

如果在多次嘗試下，TCP三次握手仍然失敗，那么bgp會將該peer停留在active狀態。

如果重傳定時器32秒超時，且沒有得到該peer的響應那么會轉至connect狀態

4.opensent狀態（open報文已發送狀態）

在這個狀態下。bgp已經向該peer發送了open報文，在等待對方給我發送open報文

如果收到了對方發來的open報文并且參數協商成功，則會向該pere發送keepalive報文，然后轉到openconfirm狀態

如果收到了對方發來的open報文參數，協商失敗，則會向該pere發送notification報文，然后轉到idle狀態。

5.openconfirm狀態

在這個狀態下bgp等待對方的keepalive報文。

如果收到了對方發來的keepalive報文則轉換為establisheded。

在這個狀態下bgp如果收到了notification報文，則轉換為idel狀態

6.Establisheded（鏈接已建立），

在這個狀態下說明鄰居已經建立完畢，這個狀態下可以交互的報文：

update；Notification；keepalive；Route-refresh

如果在這個狀態下收到正確的update和keepalive報文。bgp會認為鄰居處于正常狀態，繼續保持。

如果在這個狀態下收到了錯誤的update.和keepalive，那么bgp會認為鄰居處于異常狀態，會發送notification報文，轉到idle狀態。

Route-refresh報文的發送不影響鄰居關系。

七、bgp的報文細節

主要由兩部分組成，分別是bgp報文頭和具體報文內容

bgp報文頭：

Marker：占用16個字節。默認為全f。用于檢查bgp鄰居頭部的消息是否完整

Length：占用兩字節，用于描述bgp報文的總長度，包括報文頭+具體報文內容。

type是用于描述當前bgp報文類型的分為12345。

1.具體報文：

version：bgp版本。默認都是四，

my as用于描述發出該open報文的路由器所屬as號，同時校驗對端的as號和本地配置的as號是否一致

Hold time是描述路由器鄰居失效時間的。默認情況為keepalive時間的3倍。

當兩端holdtime時間不一致時，需要協商為數值較低的執行

<R1>dis bgp peer 12.1.1.2 verbose 查看該鄰居的具體信息。

BGp id描述發出該open報文的路由器bgp router ID

Optional parameter length? ：bgp協商參數字段長度

Optional parameters ：bgp協商參數