BPDU報文（傳統STP）

bpdu欄位包含的資訊：

protocol id 　　協議id

version　　　　stp版本（三種）

stp（802.1d

）傳統生成樹　　  值為0
rstp（
802.1w）快速生成樹    值為2
mstp（
802.1s）多生成樹　　　 值為3

配置bpdu：負責建立，維護stp拓撲     tcn bpdu：傳達拓撲變更

cost of path　  路徑開銷

bridge id　　    橋id

port id　　　　 埠id

message age    當前訊息年齡（stp每經過一台交換機，該欄位+1，同步不同位置的裝置根橋超時）

max age           最大訊息年齡（超過則代表根橋故障）

hello time　　  問候時間（根橋通過不斷傳送stp維持自己的地位，hello time 是傳送的間隔時間）

forward delay   埠從listening -> learning  或 learning -> forwarding 的轉態需要時間

stp 選舉流程：

1

.選舉根橋
2.非根交換機選舉根埠
3.每個線路選舉指定埠
4.阻塞非根，非指定埠

這些資訊在bpdu中都有。

比較規則：

1.bridge id：優先順序（預設32768） +mac位址

2.cost路徑開銷：根據介面頻寬比例計算
3.port id：優先順序 （預設128）+ 埠號

1.選根橋：每個交換機假設自己為根，互相傳送bpud報文，然後通過比較規則競選根橋

2.選根埠：每個交換機根據接收由根橋傳送的bpdu中的開銷來選舉根埠（最優路徑），交換機接收累加開銷，**不累加

3.選指定埠：每條鏈路根據比較規則來選出指定埠，每條鏈路必須有指定埠。

4.選阻塞埠：除了根埠，指定埠，剩下的為阻塞埠

下面是華為裝置stp  的配置bpdu

從這裡可以分析出，該埠的埠號是2，據開銷20000可知千兆口，所以為g0/0/2

很明顯該埠所屬的交換機不是根橋，並且是根橋的鄰居。bpdu型別是配置bpdu。

下面看下當某條鏈路斷開時，發生了拓撲變化的bpdu報文

比如有一台交換機，乙個埠為根埠，另乙個為阻塞埠。如果根埠被關閉了

那麼阻塞埠會傳送乙個拓撲變更bpdu的報文給相鄰的交換機，這個bpdu型別為：tcn

而相鄰的交換機會向這個阻塞埠傳送乙個確認拓撲變更的bpdu，這樣阻塞埠就知道自己的訊息被收到並將會傳達。

這個bpdu型別為 tca，同時相鄰的交換機就會把繼續把 tcn 向根埠方向**，之後也會收到上層交換機發來的tca確認接收報文

如果根橋收到了這個由阻塞埠傳來的tcn，便會下發拓撲變更bpdu其型別為tc，每台收到此tc報文的交換機都會將自己的mac快取表重新整理或減低過期時間。

然後再向下傳達這個tc報文。

看下下面的拓撲圖

在交換機 lsw5中 ge0/0/1原本為阻塞狀態，ge0/0/0為根埠

但是有一天ge0/0/2埠down掉了

如果沒有上述的拓撲變更bpdu的話，那麼會發生如下情況

client6 傳送 資料 給 client4

快取表裡client6的mac位址對應的卻是ge0/0/2的介面（已經down掉了）

這樣導致client6無法與外界通訊，除非要等mac快取表的過期時間300s也就是5min

這個時間實在太長了，解決的辦法就是傳送拓撲變更給根橋，根橋同意變更後向下傳送

tc bpdu，所有收到此報文的交換機都把mac快取表重新整理或減少過期時間來避免收斂速度慢

與根橋的直連鏈路發生故障

lsw8交換機上的g0/0/1為根埠，g0/0/2為指定埠，

g0/0/1發生故障後，g0/0/2會的埠角色會程式設計根埠

當是狀態要從 listening->learning->forwarding需要30秒的時間

與根橋的非直連鏈路發生故障

在lsw8中ge 0/0/1為根埠，因為hub集線器與根裝置的線down掉了

所以lsw8 會在max age 的時間內不能收到根橋傳送的bpdu，於是他會以

自身為根橋向周圍傳送 bpdu，當lsw9收到兩邊的bpdu則會對比，發現lsw7

才適合做根橋，於是又會通知lsw8，這樣ge0/0/3就會轉變成根埠。

所用的時間為50s（max age +forward delay）

STP有哪些BPDU報文

答 有兩種 1 配置bpdu 35個位元組 2協議號 1版本號 1bpdu型別 1標誌8 根橋id 4 根路徑花銷 2 橋id 2 埠id 2message age 2max age 2hello time 2forward delay 其中標紅的用於檢測最優的bpdu 標黃的標誌位有8位 從左到右...

UDP報文傳輸的差錯控制

了解tcp ip協議的人都知道tcp協議是可靠傳輸的，而udp協議是不可靠傳輸。可靠傳輸 大家基本上可以達成共識，就是協議確保資料正確到達目標機器 但是 不可靠傳輸 可能就存在爭議了，到底是不保證資料到達？還是不保證資料正確？又或者是兩者都不保證？關於這個問題，我想 不保證資料到達 這點是無容置疑的...

BizTalk 2010 EDI 報文傳輸

edi報文可以通過任何協議傳送給我們的 合作夥伴，例如 smtp file ftp http以及其他的許多協議，在這裡就不一一枚舉了。但是，edi標準僅支援van和as2。van可以確保報文是有效的 將報文路由到合適的收件人以及會有交易的記錄，而as2是一種技術，可以讓 合作夥伴允許使用s mime...