Một vấn đề có mới chăng - Rapid Spanning Tree

[phamminhtuan]

Anh chưa trả lời đúng ý em hỏi

Lúc link forward đứt thì gửi topology change. Những link mà có một bên bị block thì khi đứt hay up đều không gửi được topology change, nhưng nó vẫn gửi được CDP.
Port nào bị block thì port nó sẽ màu cam và vẫn gửi CDP được.

Nếu bạn muốn tìm hiểu sâu thêm thì dùng wireshark bắt gói, nó sẽ cho xem khá chi tiết cả proposal lẫn agreement nữa.

Dưới là file mình bắt gói cho trường hợp nối 4 SW với nhau với trường hợp của bạn.

http://www.4shared.com/file/101766012/25d2754e/BPDU.html

[cuibapcaca]

Em vẫn chưa chắc chắn lắm về trạng thái learning của RSTP như anh nói

Theo lí thuyết thì learning thì mới gửi BPDU, chứ Discard chỉ nhận. Vì vậy nó phải chuyển qua learning để gửi BPDU có chứa proposal. Và trong thời gian learning này nó sẽ chờ hồi âm bằng agreement để chuyển thành forward

Khi mới bắt đầu gởi Proposal cũng có thể hiểu là RSTP chưa thật sự hội tụ (phải nhận Agreement rồi trãi qua các quá trình Sync, đàm phán Proposal - Agreement,...). Nếu vừa gởi proposal mà chuyển qua trạng thái learning liền thì học địa chỉ MAC trong khi mạng chưa thật sự hội tụ? Điều này có bất cập không?

[cuibapcaca]

Cho em hỏi thêm:
Giả sử em có topo đơn giản ban đầu như sau (chạy RSTP):

Bây giờ cắm thêm sợi dây giữa SW1 và SW3.

Sau khi cắm dây như hình thứ 2. SW nào sẽ gởi Proposal? Hay là cả 2 đều gởi Proposal?

Thêm 1 câu hỏi nữa:

Giả sử trường hợp SW1 gởi Proposal, sau khi SW3 nhận được Proposal từ SW1 thì SW3 diễn ra quá trình SW3 tạm thời block liên kết giữa SW3 và SW2 sau đó SW3 xử lý gói tin proposal từ SW1, gởi Agreement về cho SW1.
Tiếp sau đó, SW3 unblock liên kết giữa nó với SW2 rồi SW3 lại gởi Proposal cho SW2, SW2 Sync tạm thời block liên kết SW2 với SW1,...
Quá trình cứ thế diễn ra xoay vòng như trong hình. Trên hình chúng ta thấy tiến trình Proposal-Agreement sẽ diễn ra xoay vòn trên từng liên kết

• (1) SW1 - SW3
• (2) SW3 - SW2
• (3) SW2 - SW1

Khi nào thì SW1 biết là đã đàm phán xong 1 vòng và ngừng việc đàm phán Proposal-Agreement? Có hay không việc đàm phán tiếp trên liên kết số (4) như trong hình (lại đàm phán giữa SW1 và SW3)? Dựa vào đâu mà SW1 biết khi nào dừng lại?

1 câu hỏi nữa:
Giả sử ở hình thứ 2, cả SW1 và SW3 đều gởi proposal.

• SW1 gởi proposal rồi đàm phán với các liên kết còn lại như mũi tên màu xanh dương trên hình (trên hình thì SW1 đàm phán các liên kết lần lượt ngược chiều kim đồng hồ).
• SW3 gởi proposal rồi đàm phán với các liên kết còn lại như mũi tên màu xanh lá trên hình (trên hình thì SW3 đàm phán các liên kết lần lượt cùng chiều kim đồng hồ).

Nếu cả 2 SW đều thấy có sự thay đổi trong topo và gởi Proposal thì ta thấy có 2 tiến trình riêng nhưng thật ra kết quả bầu chọn của 2 tiến trình là như nhau. Ví dụ: trên liên kết giữa SW1 và SW2, tiến trình đàm phán proposal-agreement màu xanh dương hay xanh lá đều có kết quả như nhau. Sử dụng 2 tiến trình có cần thiết không?
Câu hỏi trên mang tính lý thuyết. Theo như em debug thấy thì chỉ có 1 tiến trình --> chứng tỏ chỉ có 1 Switch gởi proposal. Nhưng em không biết khi cắm sợi dây màu đỏ vào thì Switch nào sẽ gởi proposal???

[phamminhtuan]

Nếu muốn biết SW nào gửi trước bạn chỉ cần gắn thêm một cái Hub đặt giữa SW1 và SW3. Sau đó cắm thêm một PC vào Hub thì sẽ bắt được gói gửi lẫn nhau của cả 2 SW.

[cuibapcaca]

Cái vấn đề mình hỏi là suy luận từ lý thuyết chứ debug để xem SW nào gởi trước thì mình làm rồi. Câu hỏi ở đây là tại sao? Tại sao cả 2 đều phát hiện có sự thay đổi mà chỉ có 1 bên gởi proposal?

[cuibapcaca]

Tiếp tục đi nhĩ

[phamminhtuan]

Cái vấn đề mình hỏi là suy luận từ lý thuyết chứ debug để xem SW nào gởi trước thì mình làm rồi. Câu hỏi ở đây là tại sao? Tại sao cả 2 đều phát hiện có sự thay đổi mà chỉ có 1 bên gởi proposal?

Trong sách study guide, từ trang 188 trở xuống đó có nói. Khi TC, hoặc đồng bộ hóa, việc truyền frame chỉ có thể diễn ra sau khi đã xử lí xong proposal và agreement.
Như hình của bạn, nếu với R2 mà làm RB thì có cắm vào dây mạng giữa SW1 và SW3 thì cũng chẳng thay đổi gì cả => không cần proposal và agreement.


Trường hợp SW1 là RB.

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CADMINI%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtml1%5C01%5Cclip_filelist.xml"><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w:DontGrowAutofit/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" LatentStyleCount="156"> </w:LatentStyles> </xml><![endif]--><style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> </style><!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} </style> <![endif]--> SW3 chỉ block f0/1 khi nào nó cần thiết chuyển port f0/2 là root port khi nhận được proposal. Vì lúc này nó vẫn nhận được BPDU từ cả 2 phía, và nó có thể so sánh được bên nào tốt hơn để chon root port.
Cho nên chỉ có bước 1 là xảy ra. Còn tiếp theo là SW3 nhận BPDU qua f0/1 đến từ SW2, và SW2 ngược lại cũng nhận BPDU đến từ SW3 để thượng lượng xem port nào bị block. và port nào sẽ designated. Port block (discard) sẽ chuyển đổi trạng thái khi nào không còn nhận được BPDU nữa.


Nếu theo suy luận như trên của mình thì sau quá trình proposal và agreement, cả đoạn segment đó sẽ đều nằm ở trạng thái forwarding ở cả 2 đầu.


Còn bạn debug mà thấy có gửi proposal, tức mình nghĩ SW1 làm RB. Còn làm bắt gói bằng Wireshark thì bạn nên chú ý chỗ yes và no mặc dầu đều có chữ proposal.

[cuibapcaca]

Trong sách study guide, từ trang 188 trở xuống đó có nói. Khi TC, hoặc đồng bộ hóa, việc truyền frame chỉ có thể diễn ra sau khi đã xử lí xong proposal và agreement.
Như hình của bạn, nếu với R2 mà làm RB thì có cắm vào dây mạng giữa SW1 và SW3 thì cũng chẳng thay đổi gì cả => không cần proposal và agreement.

Chưa chắc, giả sử em chỉnh cost trên SW1 sao cho đường ngắn nhất đến root bridge (SW2) thông qua SW3 thì có sự thay đổi topo chứ.
Còn câu hỏi làm sao biết SW nào sẽ gởi trước thì sao nhĩ?

[phamminhtuan]

Chưa chắc, giả sử em chỉnh cost trên SW1 sao cho đường ngắn nhất đến root bridge (SW2) thông qua SW3 thì có sự thay đổi topo chứ.
Còn câu hỏi làm sao biết SW nào sẽ gởi trước thì sao nhĩ?

Tùy theo chứ không nhất thiết con phải phải gửi trước. Nếu con nào gửi BPDU có proposal trước thì và có priority bé hơn con nhận thì, thì con nhận so sánh. Thấy BPDU bé hơn thì nó sẽ gửi lại BPDU cùng proposal của nó. Và con nào bé hơn lúc này sẽ nhận agreement. Vì thế mới nói chỉ duy nhất trong trường hợp này port có khả năng discard vẫn có khả năng gửi BPDU.