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

nguyenquang

30-10-2003, 09:12 PM

Mình có đọc trong một tài liệu ICND của Odom viết, có đề cập đến một thuật ngữ nghe cũng khá lạ: Rapid Spanning Tree Protocol, viết tắt là RSTP.
Cũng dùng trong các Switch của Cisco thế hệ Catalys. Được kí hiệu là 802.1w, trước kia ta đã biết là có 2 loại Spanning Tree là 802.1d và Spanning Tree. Hiện nay thấy xuất hiện thêm cái này, mình đọc và rút được một số vấn đề về nó, nhưng chưa thực sự hiểu được thấu đáo, anh em có thể giúp mình hiểu thêm???
Một vài đặc điểm của RSTP:
-Nhanh hơn trong Convergence Time (Việc tìm đường khi Root Bridge bị down) có thể Update ngay lập tức sau khoảng thời gian là 1-2s, tối đa là 10s, rất nhanh cho các Switch.
-Trong RSTP có qui định thêm một số thuật ngữ: Link-type Point-to Point, Link-type Shared, Edge-type.
-Không dùng thuật ngữ Blocking mà dùng thuật ngữ Discarding để chỉ những port không có khả năng Forward mà chỉ nhận BPDU.
-Các kiểu Port ngoài RootPort và Designated Port còn có thêm Alternate, Back up, và Disabled Port.

Còn lại một số vấn đề đọc mà không thể hiều được, anh em bổ sung dùm mình, rất muốn tìm hiểu thêm.

lee

31-10-2003, 03:05 PM

theo mình biết thì RSTP dược sử dụng trong các Vlan vì trong từng vlan cũng có STP nhung do vấn đề delay nên mới đưa ra RSTP,vì trong STP mặc định là cho toàn bộ VLAN của tất cả các switch ,nên 1 host thuộc vlan trong switch này muốn wa 1 host khác thuộc cùng vlan trong switch kế cận phải đi wa nhiều switch để đến đích==>chậm ,vì trong STP chỉ có nhiệm vụ chống loop chứ không có giải thuật tìm đường tối ưu,do đó,RSTP là STP cho nội bộ các VLAN trong các switch,mặc dù vẫn không tìm đường tối ưu nhưng cũng cải thiện được phần nào.Rất mong các bạn chỉ bảo thêm nếu mình có gì sai.

sinhvienngheo

01-11-2003, 12:15 PM

STP "truyền thống" có chức năng đảm bảo một hệ thống mạng switch không bị loop. Khi có một thay đổi về topology, khoảng thời gian bị mất đi để điều chỉnh những thay đổi này là 30 giây. Đối với trình độ công nghệ siêu phát triền hiện nay, 30 giây trên là quá nhiều. Mỗi khi mạng có một thay đổi nhỏ, ta phải chờ 30 giây để mạng ổn định lại. ;-)

802.1w được thiết kế dựa trên các nguyên lý của 802.1d và cải tiến thời gian hội tụ, khắc phục điểm yếu nêu trên.

Một vài cải tiến là RSTP không dựa nhiều vào các BPDU. Thay vào đó, các switch sẽ giao tiếp với nhau thông qua các trạng thái port. Một port trong RSTP sẽ có ba trạng thái: root port, designated port và blocking port. RSTP đạt được tốc độ nhanh là nhờ vào việc gán trước vai trò các port này.

Mong được trao đổi tiếp tục chủ đề này,

Chúc vui,

nguyenquang

01-11-2003, 06:57 PM

:( RSTP không còn dùng thuật ngữ Blocking nữa, mà là dùng thuật ngữ Discarded Port.

dangquangminh

01-11-2003, 07:58 PM

Trạng thái discarding trong RSTP bao gồm ba trạng thái của STP truyền thống: disable, blocking và listening. Ba trạng thái vừa nêu thật ra không forward frame đi. Trạng thái listening cũng không còn cần thiết vì RSTP có thể chuyển sang trạng thái mới mà không cần lắng nghe BPDU.

Hai trạng thái còn lại của RSTP là learning và forwarding.

Thân mến,

bestirboy

23-11-2003, 07:20 AM

Sao mình không nghe nhắc đến 2 type port mới trong RSPT nhỉ? Đó là alternat port và back up port. 2 port trên đều giúp cho việc convergence nhanh hơn. Khi forwarding port fail, ngay lập tức nó chọn 1 port kế tiếp từ discard ---> forward. Do vậy thời gian convergence đc rút ngắn chỉ còn 1 đến 2 s mà thôi.
Nhưng cơ chế làm việc của 2 loại port trên khác nhau. Mọi người viết tiếp phần phân biệt giữa 2 port và công dụng ưu việt của 2 loại port đó nhé.

nhaque321

25-03-2004, 10:54 AM

Sao mình không nghe nhắc đến 2 type port mới trong RSPT nhỉ? Đó là alternat port và back up port. 2 port trên đều giúp cho việc convergence nhanh hơn. Khi forwarding port fail, ngay lập tức nó chọn 1 port kế tiếp từ discard ---> forward. Do vậy thời gian convergence đc rút ngắn chỉ còn 1 đến 2 s mà thôi.
Nhưng cơ chế làm việc của 2 loại port trên khác nhau. Mọi người viết tiếp phần phân biệt giữa 2 port và công dụng ưu việt của 2 loại port đó nhé.

alternative port - a port blocked by receiving more useful BPDUs from another bridge (dĩ nhiên là kém hơn BPDU nhận được từ root-port).
backup port - a port blocked by receiving more useful BPDUs from the same bridge it is on.

Hai loại trên đều ở trạng thái blocking. Hoạt động của nó như sau:
alternative-port: Khi root-port của switch không còn nhận được hello-BPDU nưa, alternative-port sẽ được SW sử dung ngay để làm root-port.
backup-port: Chú ý rằng backup-port chỉ có được khi một SW có hơn 1 port kết nối vào cùng một segment. Khi port tới segment đó đang ở trạng thái forwarding bỗng dưng bị fail, SW chọn ngay backup-port để thay thế và đặt nó trong trạng thái forwarding.

Trên đây là ý kiến của mình, mong mọi người đóng góp!

nguyenthanhtung32

04-04-2004, 09:51 PM

ban sinhvienngheo oi,
nếu không dựa nhiều vào các BPDU thì chúng giao tiếp như thế nào để biết trạng thái của network thông qua trạng thái các port?
Cám ơn .

dangquangminh

09-04-2004, 01:22 AM

hi

Như các bạn trên đã đề cập, RSTP không hoạt động hoàn toàn dựa vào BPDU mà dựa trên các khái niệm port-role. BPDU vẫn được dùng để bầu ra ROOT Switch giống như trong 802.1d spanning-tree. Các rule mà nhaque321 mô tả là một trong những điểm giúp RSTP hội tụ nhanh.

Một trong những đặc điểm khác cần biết là RSTP gửi các BPDU mỗi hello-interval (2 giây). các switch cũng sẽ kết luận neighbor switch bị down nếu không nhận được bpdu trong 3 interval (6s). Khoảng thời gian để biết một neighbor bị down trong spanning-tree cũ là 20 giây.

Vậy trong RSTP vẫn có dùng BPDU. Định dạng của BPDU này cũng giống như của 802.1d spanning-tree, chỉ dùng thêm 1 số bit trong frame.

Về hoạt động chi tiết của RSTP, thân mời bạn tham khảo giáo trình Cisco Press Certification Guide - BCMSN.

Cám ơn,

VoThanhDuy

11-10-2004, 03:54 PM

Trong SPT kiểu cũ, khi có một thay đổi diễn ra, khoảng thời gian để một port chuyển từ blocking sang fwding là 30s. RSTP sẽ định nghĩa các switch giao tiếp với nhau như thế nào. RSTP cũng có hai phiên bản. Phiên bản đơn hoặc phiên bản RPSTP+.

Root switch trong RSTP cũng sẽ được bầu giống như trong spanning tree truyền thống.

Vấn đề kế tiếp là làm thế nào để RSTP có tốc độ được cải thiện so với 802.1d?

trung tam kn

09-11-2004, 09:22 PM

các điểm then chốt giúp cho rapid spanning tree có tốc độ hội tụ nhanh hơn hẳn spanning tree truyền thống

1/ Định nghĩa thêm các kiểu port mới (port type): alternate port và back-up port. Bản chất của hai kiểu port này là các port có thểm các tính năng port fast hoặc uplink fast. Khi các tính năng này được cho phép, mỗi khi mạng có thay đổi, thời gian mạng hội tu nhanh hơn

2/ Cơ chế push-pull trên các kết nối point-to-point: các thông điệp proposal-agreement tốn ít thời gian để xác định designated port hơn trước đây.

3/ Định nghĩa chỉ có 3 kiểu port -role thay vì 5 như trước đây. Các bạn cần phân biệt rõ port role và port type nhé.

Cám ơn mọi người

nervetnova

10-11-2004, 07:09 AM

trong spanning tree kiểu cũ, có các port role là:

Root Port
Designated Port
Blocking Port (neither Root nor Designated).

Các port trên có 5 trạng thái là

Disabled
Blocking
Listening
Learning
Forwarding

trpng RSTP thì có những kiểu port sau:

Root Port—Port nối về root

Designated Port—Port trên một segment có đường đi tốt nhất về root.
Alternate Port—Port dự phòng cho root port , có thêm tính năng uplink fast
Backup Port—Port dự phòng cho port fast

nervetnova

10-11-2004, 07:16 AM

RSTP cũng dùng định dạng BPDU theo kiểu 802.1D để tương thích. Một vài field trong gói BPDU cũ được dùng. Version của BPDU sẽ được gán lên bằng 2 để phân biệt BPDU cũ. Ngoài ra RSTP dùng các quá trình tương tác để hai switch có thể dò tìm ra các thay đổi. Các BPDU được gửi ra ở khoảng thời gian hello time, bất chấp việc BPDU có nhận được từ root hay không? BPDU được gửi bởi tất cả các switch trong hệ thống mạng. Nếu 3 BPDU bị mất, switch láng giềng sẽ bị giả sữ là DOWN và tất cả các thông tin liên quan đến switch đó sẽ bị loại bỏ.

Như vậy trong mạng chạy RSTP, một neighbor bị down có thể phát hiện trong 6 giây. Trong khi trong SPT truyền thống, cần khoảng thời gian là 20 giây (MaxAge)

changchancuucodon

11-11-2004, 09:58 PM

Thật ra tất cả các switch port có thể thuộc về các kiểu sau:

Edge port: port nằm ở ngoài rìa của mang. Port này thường được dùng thêm tính năng port fast.

Root Port: port có đường đi tốt nhất về root. Chỉ có một root post là có thể chọn lựa trong một thời điệm Nếu có các port về root cũng tồn tại, các port này gọi là alternate root port. Khi root port hiện hành bị fail, alternate port sẽ được đưa về trạng thái forwarding ngay lập tức.

Point-to-point port: Bất cứ port nào kết nối với các switch khác và trở thành designated port.

VoThanhDuy

12-11-2004, 06:07 AM

Xin được đính chính về kiểu point-to-point: là các kết nối full duplex giữa các switch.

Point-to-point = kết nối giữa các switch theo chế độ full duplex

Lúc này quá trình hội tụ của các port cũng rất nhanh do chỉ giải quyết trên các kết nối point-to-point này.

Các port còn lại vẫn phải dùng spanning tree bình thường

Southern big boss

01-08-2007, 07:40 PM

hi moi nguoi ,
cho em hoi lam sao cai RSTP hoi tu ,
em doc sach nhung trong do ko noi ro la thi du khi 1 cai duong link fail thi lam sao mang hoi tu duoc 1 cach nhanh chong so voi STP 802.1D

Em doc sach thi noi la thi du 1 duong link bi fail thi 1 con switch fat hien duoc va gui ra cho tat ca cac con khac biet nhung trong sach ko noi cu the hon

Thanks , hope for reply from everyone

dangquangminh

02-04-2008, 12:00 AM

trong rapid spanning tree, khi có một sự cố mạng xảy ra, các frame TCN BPDU gửi cho tất cả các switch, ra tất cả các cổng. Trong khi trong 802.1d SPT, TCN BPDU chỉ được gửi ra root port để đi về root switch. Sau đó root switch sẽ gán bit TCN=1 trong tất cả các frame Configuration BPDU gửi ra từ nó. Khi các non root switch nhận được thông báo này (TCN từ root), các non root switch sẽ xóa tất cả các hàng trong bảng CAM của nó và cập nhật lại.

Như vậy khi có sự cố mạng xảy ra, hình thức gửi BPDU là điểm khác biệt so với 802.1d SPT.

Thêm vào đó, cách thức mà Rapid SPT phát hiện nhanh sự cố xảy ra (chỉ có 3 hello, tương 6 giây) là điểm cải tiến nữa so với 802.1d SPT. Trong SPT kiểu cũ, thường các switch phải chờ hết khoảng thời gian Max Age tương đương 20 giây thì mới bắt đầu tính lại thuật toán.

trungtruc82

02-07-2008, 10:36 AM

Nhiều người nói là RSTP tiến bộ hơn STP truyền thống và 802.1d nhưng tại sao các nhà sản xuất cisco lại để default là STP truyền thống mà không để RSTP làm mặc định? Vậy RSTP và MSTP còn có những nhược điểm nào mà các nhà sản xuất không để default là RSTP va MSTP

Thank!!!

tranmyphuc

02-07-2008, 02:27 PM

Nhiều người nói là RSTP tiến bộ hơn STP truyền thống và 802.1d nhưng tại sao các nhà sản xuất cisco lại để default là STP truyền thống mà không để RSTP làm mặc định? Vậy RSTP và MSTP còn có những nhược điểm nào mà các nhà sản xuất không để default là RSTP va MSTP

Thank!!!

Chào !!!
Theo mình thì dòng sản phẩm của hãng nào cũng phải đưa ra những chuẩn chung nhất và thường gặp nhất để làm cấu hình default. Với RSTP và MSTP là những tính năng mới và không phải dòng sản phẩm nào của cisco cũng như của hãng khác hỗ trợ. tất nhiên cái mới đã cải thiện nhiều so với các cũ.
Như
+ RSTP giúp ta hội tụ nhanh hơn
+ MSTP thường dùng cho hệ thống gồm quá nhiều VLAN khi đó chạy MSTP sẽ ổn định và tốt hơn nhiều : tiết kiệm băng thông, resource ...

Chúc bạn vui !!!

dressup9

29-11-2008, 09:14 PM

sao ko hiểu gì hết vậy trời. :((

http://img139.imageshack.us/img139/2019/banner01ie8.png (http://www.dressup9.com)
Click Here (http://www.dressup9.com)

longphi11

07-12-2008, 01:59 PM

alternative port - a port blocked by receiving more useful BPDUs from another bridge (dĩ nhiên là kém hơn BPDU nhận được từ root-port).
backup port - a port blocked by receiving more useful BPDUs from the same bridge it is on.

Hai loại trên đều ở trạng thái blocking. Hoạt động của nó như sau:
alternative-port: Khi root-port của switch không còn nhận được hello-BPDU nưa, alternative-port sẽ được SW sử dung ngay để làm root-port.
backup-port: Chú ý rằng backup-port chỉ có được khi một SW có hơn 1 port kết nối vào cùng một segment. Khi port tới segment đó đang ở trạng thái forwarding bỗng dưng bị fail, SW chọn ngay backup-port để thay thế và đặt nó trong trạng thái forwarding.

Trên đây là ý kiến của mình, mong mọi người đóng góp!

cho hỏi chút

Vậy có nghĩa là alternative port và back up port đều là port ở trạng thái discarding khi topo stable.Còn khác nhau chẳng qua là việc backup port có tới 2 connect vào segment,còn alternative port chỉ có 1 connect thôi,đúng vậy ko bạn

cuibapcaca

16-03-2009, 12:06 PM

Cho mình hỏi là sau khi RSTP thực hiện tiến trình proposal-agreement, port sẽ vào trạng thái forwarding liền hay learning rồi mới đến forwarding? Nếu trường hợp thứ 2 thì learning trong RSTP cũng là 15 giây?? --> chậm???

inetd

27-03-2009, 08:51 PM

SwRoot(D-P)__________
(D-P)aaaaaaaaaaaaaaaa|
|aaaaaaaaaaaaaaaaaaaa|
|aaaaaaaaaaaaaaaaaaaa|
(R-P)aaaaaaaaaaaaaaaa(R-P)
SwA(A-P)________(D-P)SwB
aaaaaaaaaaaa|aaaaaaaa(B-P)
aaaaaaaaaaaa|aaaaaaaaa|
aaaaaaaaaaaa------------

Chú thích:
aaaa: Bỏ qua nhé
D-P: Designated Port
R-P: Root Port
A-P: Alternate Port
B-P: Backup Port

Khi R-P của swA failed, A-P của swA sẽ trở thành R-P
Khi D-P của swB failed B-P của swB sẽ trở thành D-P

Đó là ý hiểu của mình về Port Role. Mọi người có ý kiến gì thì cùng thảo luận nhé :D

cuibapcaca

30-03-2009, 02:30 PM

Cho mình hỏi là sau khi RSTP thực hiện tiến trình proposal-agreement, port sẽ vào trạng thái forwarding liền hay learning rồi mới đến forwarding? Nếu trường hợp thứ 2 thì learning trong RSTP cũng là 15 giây?? --> chậm???

Có người cho rằng, proposal gởi mà không nhận được agreement thì đi vào trạng thái learning. Còn nhận được agreeement thì vào thẳng forwarding. Tuy nhiên, mình vẫn chưa thỏa mãn lắm vì giả sử trường hợp không nhận được agreement thì cũng đâu có đạt được sự hội tụ, đãm bảo sự chính xác mạng hội tụ, vậy chẳng lẽ như thế thì sau 15 giây lại chuyển sang forwarding à?
Mình nghĩ đây là câu hỏi hay, các cao thủ giúp mình với.

netbaby

02-04-2009, 07:33 PM

Hix, khi học mình cũng không để ý trường hợp này. Các cao thủ VNPro hãy ra tay nghĩa hiệp ....

cuibapcaca

15-04-2009, 12:19 AM

Cho mình hỏi là sau khi RSTP thực hiện tiến trình proposal-agreement, port sẽ vào trạng thái forwarding liền hay learning rồi mới đến forwarding? Nếu trường hợp thứ 2 thì learning trong RSTP cũng là 15 giây?? --> chậm???

Có người cho rằng, proposal gởi mà không nhận được agreement thì đi vào trạng thái learning. Còn nhận được agreeement thì vào thẳng forwarding. Tuy nhiên, mình vẫn chưa thỏa mãn lắm vì giả sử trường hợp không nhận được agreement thì cũng đâu có đạt được sự hội tụ, đãm bảo sự chính xác mạng hội tụ, vậy chẳng lẽ như thế thì sau 15 giây lại chuyển sang forwarding à?
Mình nghĩ đây là câu hỏi hay, các cao thủ giúp mình với.

Hix, đợi mòn mỏi mà không thấy ai trả lời hết

cuibapcaca

15-04-2009, 09:19 PM

up cho ngày hôm nay!

logmeinvietnam

16-04-2009, 06:58 AM

http://img8.imageshack.us/img8/5397/111ciy.jpg (http://img8.imageshack.us/my.php?image=111ciy.jpg)

<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CADMINI%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtml1%5C01%5Cclip_filelist.xml"><style>  </style> Trong 802.1D, khi một port được lựa chọn bời spanning tree thành DP, nó cần chờ 2 khoảng thời gian listening và learning để có thể trở thành forwarding được.
RSTP tăng tốc độ UP bằng cách tính toán lại việc xử lý sau khi sơ đồ mạng thay đổi, nó không chỉ dựa vào thời gian hết hạn của port như STP.
<o></o>
Ví dụ như hình trên.
SWA mới đầu đi qua B->C->Root. Sau khi ta gắn thêm dây nối giữa A và Root và giả sử con đường này trở nên tốt nhất so với các con đường khác thì port của A->ROOT trong con đường này sẽ trở thành root port. Và trạng thái nó xử lí như sau.

Cả hai port nối [giữa root và A] designated này đang trong trạng thái block cho tới khi chúng nhận được BPDU từ đối phương. Khi DP trong trạng thái Discard hoặc learning (chỉ duy nhất trường hợp này), Con nào là root bridge thì sẽ thiết lập bit proposal trong BPDU của nó trước khi gửi ra ngoài.
SW A nhận được proposal BPDU với cost tốt hơn những con đường khác. Nó sẽ block tất cả các port designated mà không là EDGE (edge là port nối với PC), đều này nhằm tránh SWA là nguyên nhân gây loop trong quá trình proposal và agreement process. Cái này gọi là Sync dùng động bô tránh loop.
SW A send lại một thông điệp agreement để cho phép port trên cổng P0 của ROOT vào trạng thái forwarding state, đồng thời lúc này P1 của A trở thành Root Port.

<o>
Còn đối với trường hợp SWA không nhận được proposal, thì vẫn giữ nguyên sơ đồ mạng cũ cho tới khi nhận được thì thôi, chứ forward loop thì SWA sẽ gây ra loop.
</o>

cuibapcaca

16-04-2009, 06:21 PM

Cả hai port nối [giữa root và A] designated này đang trong trạng thái block cho tới khi chúng nhận được BPDU từ đối phương. Khi DP trong trạng thái Discard hoặc learning (chỉ duy nhất trường hợp này), Con nào là root bridge thì sẽ thiết lập bit proposal trong BPDU của nó trước khi gửi ra ngoài.Em chưa hiểu câu in đâm ở trên, anh có thể giải thích rỏ hơn được không ạ? Sau khi đọc trả lời của anh, em cũng chưa hiểu khi nào SW trong RSTP vào trạng thái learning???

Xin cảm ơn!

logmeinvietnam

16-04-2009, 09:54 PM

Em chưa hiểu câu in đâm ở trên, anh có thể giải thích rỏ hơn được không ạ? Sau khi đọc trả lời của anh, em cũng chưa hiểu khi nào SW trong RSTP vào trạng thái learning???

Xin cảm ơn!

Khi DP trong trạng thái Discard hoặc learning (chỉ duy nhất trường hợp này)
+ Discard: lúc ban đầu cả hai port mới gắn vào.
+ learning:
- Cụ thể ở đây nếu RB nhận thấy sự thay đồi topology trước SWA, thì port P0 của RB sẽ learning trước và gửi proposal tới P1 của A, lúc đã nhận proposal và block các cổng không phải edge designated, SWA learning rồi send agreement.
- Nếu A nhận biết sự thay đổi topology trước thì nó sẽ gửi BPDU ra trước và sau đó cũng thương lượng với RB như trên.

cuibapcaca

18-04-2009, 11:32 AM

Khi DP trong trạng thái Discard hoặc learning (chỉ duy nhất trường hợp này)
+ Discard: lúc ban đầu cả hai port mới gắn vào.
+ learning:
- Cụ thể ở đây nếu RB nhận thấy sự thay đồi topology trước SWA, thì port P0 của RB sẽ learning trước và gửi proposal tới P1 của A, lúc đã nhận proposal và block các cổng không phải edge designated, SWA learning rồi send agreement.
- Nếu A nhận biết sự thay đổi topology trước thì nó sẽ gửi BPDU ra trước và sau đó cũng thương lượng với RB như trên.

Ý của anh là con SW nào nhận biết được sự thay đổi trước thì sẽ vào trạng thái learning (ở ví dụ này là root) hoặc là sau khi nhận được BPDU, sync rồi vào learning (ở ví dụ này là SW A)?
Ok, như vậy sau khi nhận được agreement thì SW Root sẽ đi từ learning vào trạng thái forwarding ngay lập tức (trong sách ghi thế)? Như vậy thời gian từ learning qua forwarding trong trường hợp này là mấy giây?

logmeinvietnam

19-04-2009, 01:22 PM

STP, BPDU được sinh ra chỉ từ ROOT.
RSTP, BPDU được sinh ra từ mỗi SW trong domain đó.

Khi RSTP đã quyết định chuyển từ trạng thái discarding sang fowarding, cổng đó sẽ đi vào trạng thái learning. Từ thời điểm này, quá trình tiếp tục giống như trong STP, 802.1D. RSTP không còn cần trạng thái listening bởi vì SW sẽ chủ động hỏi láng giềng bằng các Frame truy vấn Root Link Query trên tất cả các cổng mà đáng lẽ ra phải nhận được hello khi gói tin BPDU [BPDU làm luôn nhiệm vụ keepalive] đầu tiên bị mất, đảm bảo sao cho không bị vòng lặp.
Đối với mô hình trên thực tế làm nếu port đã listening rồi thì chỉ mất thêm chừng 3-4 giây để nó thành forwading.
Thân.

cuibapcaca

19-04-2009, 09:41 PM

Khi RSTP đã quyết định chuyển từ trạng thái discarding sang fowarding, cổng đó sẽ đi vào trạng thái learning. Từ thời điểm này, quá trình tiếp tục giống như trong STP, 802.1D. RSTP không còn cần trạng thái listening bởi vì SW sẽ chủ động hỏi láng giềng bằng các Frame truy vấn Root Link Query trên tất cả các cổng mà đáng lẽ ra phải nhận được hello khi gói tin BPDU đầu tiên bị mất, đảm bảo sao cho không bị vòng lặp.
[B]Đối với mô hình trên thực tế làm nếu port đã listening rồi thì chỉ mất thêm chừng 3-4 giây để nó thành forwading.Dòng in đậm thứ nhất, ý anh nói là sau khi nhận agreement thì sẽ vào learning trước khi qua forwarding.
Dòng in đậm thứ 2, chưa đúng ở chổ RSTP không có trạng thái listenning (gạch dưới). Anh còn nói "mất 3 đến 4 giây để thành forwarding". Tóm lại, ý anh là sau khi đã nhận agreement thì switch sẽ vào trạng thái learning rồi sau đó 3 đến 4 giây sẽ chuyển sang forwarding??? (theo lý thuyết thì từ learning qua forwarding là 15 giấy ---> mâu thuẩn)

logmeinvietnam

19-04-2009, 10:59 PM

Dòng in đậm thứ nhất, ý anh nói là sau khi nhận agreement thì sẽ vào learning trước khi qua forwarding.

Không nhất thiết phải nhận agreement thì nó mới learning, nó có thể learning trước khi nhận được agreement, vì ở trên có nói rồi, mỗi SW trong topology đều có khả năng phát sinh ra BPDU.

Dòng in đậm thứ 2, chưa đúng ở chổ RSTP không có trạng thái listenning (gạch dưới). Anh còn nói "mất 3 đến 4 giây để thành forwarding".
Đối với mô hình trên thực tế làm nếu port đã listening rồi thì chỉ mất thêm chừng 3-4 giây để nó thành forwading.
Câu này mình ghi nhầm, là learning.

Tóm lại, ý anh là sau khi đã nhận agreement thì switch sẽ vào trạng thái learning rồi sau đó 3 đến 4 giây sẽ chuyển sang forwarding??? (theo lý thuyết thì từ learning qua forwarding là 15 giấy ---> mâu thuẩn)

Trên đó mình có nói rõ, Từ thời điểm này, quá trình tiếp tục giống như trong STP, 802.1D, 15 giây đó là lí thuyết.

RSTP phản ứng với sự thay đổi không cần phải chờ cho qua những khoảng thời gian giống STP.
Vì thế thực tế làm bài này bạn show ra nó lên rất lẹ. Bạn lấy ra làm thử bài đó đi, đợi lúc learning tới forward nhanh hay không.

Nếu mô hình nào cũng phải đợi 15 giây chuyển từ learning thành forward thì làm sao cisco lại nói hội tụ nhanh có khi chỉ mất vài giây.

cuibapcaca

19-04-2009, 11:24 PM

<o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"></o:smarttagtype> <o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"></o:smarttagtype> Xin phép trích 1 câu trong White paper RSTP của Cisco:
Quote:
<table class="MsoNormalTable" style="width: 100%;" width="100%" border="0" cellpadding="0" cellspacing="0"> <tbody><tr style=""> <td style="border: 1pt inset ; padding: 4.5pt;"> Once p0 receives that agreement, it can immediately transition to the forwarding state
</td> </tr> </tbody></table> Câu này cho biết khi nhận được agreement thì vào forwarding ngay lập tức.
Theo em hiểu đến đây thì trạng thái learning chỉ xuất hiện khi Switch vừa phát hiện có sự thay đổi và chưa nhận được agreement
Quote:
<table class="MsoNormalTable" style="width: 100%;" width="100%" border="0" cellpadding="0" cellspacing="0"> <tbody><tr style=""> <td style="border: 1pt inset ; padding: 4.5pt;"> Không nhất thiết phải nhận agreement thì nó mới learning, nó có thể learning trước khi nhận được agreement, vì ở trên có nói rồi, mỗi SW trong topology đều có khả năng phát sinh ra BPDU.
</td> </tr> </tbody></table> "Không nhất thiết nhận BPDU mới vào learning", ý anh là khi phát hiện có sự thay đổi thì nó vào trạng thái learning liền. Nếu giả sử đợi hoài không thấy agreement thì nó vào trạng thái discarding? Thời gian timeout cho việc đợi agreement là mấy giây?
Quote:
<table class="MsoNormalTable" style="width: 100%;" width="100%" border="0" cellpadding="0" cellspacing="0"> <tbody><tr style=""> <td style="border: 1pt inset ; padding: 4.5pt;"> Trên đó mình có nói rõ, Từ thời điểm này, quá trình tiếp tục giống như trong STP, 802.1D, 15 giây đó là lí thuyết.
RSTP phản ứng với sự thay đổi không cần phải chờ cho qua những khoảng thời gian giống STP.
Vì thế thực tế làm bài này bạn show ra nó lên rất lẹ. Bạn lấy ra làm thử bài đó đi, đợi lúc learning tới forward nhanh hay không.
Nếu mô hình nào cũng phải đợi 15 giây chuyển từ learning thành forward thì làm sao cisco lại nói hội tụ nhanh có khi chỉ mất vài giây.
</td> </tr> </tbody></table> Em đã làm lab rồi, chính vì những gì không giống như lý thuyết nên mới vào forum hỏi đó chứ. Theo như anh nói thì sau khi phát hiện có sự thay đổi topo thì Switch vào trạng thái learning rồi qua forwarding trong tích tắc chứ không phải đợi 15 giây như lý thuyết. Em làm thấy đúng là chỉ mất 2 giây để thực hiện điều đó. Như vậy learning có 2 giây thì làm được gì chứ. Mục đích của learning là hạn chế việc forward broadcast data khi chưa học trong bảng <st1:place w:st="on">CAM</st1:place> nên sẽ ảnh hưởng đến performance của mạng. Nhưng mà learning chỉ trong 2 giây thì có thật sự cần thiết không?

logmeinvietnam

19-04-2009, 11:48 PM

"Không nhất thiết nhận BPDU mới vào learning", ý anh là khi phát hiện có sự thay đổi thì nó vào trạng thái learning liền. Nếu giả sử đợi hoài không thấy agreement thì nó vào trạng thái discarding? Thời gian timeout cho việc đợi agreement là mấy giây?

BPDU [hello] gửi mỗi 2 giây. Nếu neighbor 3 lần không nhận được hello [BPDU],còn ở đây là agreement, tức 6 giây thì port của SW sẽ chuyển đổi sang trạng thái khác, đối với ở đây sẽ là discarding luôn mà không cần hỏi những SW khác trong mạng nữa vì là connected với nó.

logmeinvietnam

19-04-2009, 11:59 PM

"Không nhất thiết nhận BPDU mới vào learning", ý anh là khi phát hiện có sự thay đổi thì nó vào trạng thái learning liền. Nếu giả sử đợi hoài không thấy agreement thì nó vào trạng thái discarding? Thời gian timeout cho việc đợi agreement là mấy giây?

Em đã làm lab rồi, chính vì những gì không giống như lý thuyết nên mới vào forum hỏi đó chứ. Theo như anh nói thì sau khi phát hiện có sự thay đổi topo thì Switch vào trạng thái learning rồi qua forwarding trong tích tắc chứ không phải đợi 15 giây như lý thuyết. Em làm thấy đúng là chỉ mất 2 giây để thực hiện điều đó. Như vậy learning có 2 giây thì làm được gì chứ. Mục đích của learning là hạn chế việc forward broadcast data khi chưa học trong bảng CAM nên sẽ ảnh hưởng đến performance của mạng. Nhưng mà learning chỉ trong 2 giây thì có thật sự cần thiết không?

BPDU [hello] gửi mỗi 2 giây. Nếu neighbor 3 lần không nhận được hello [BPDU],còn ở đây là agreement, tức 6 giây thì port của SW sẽ chuyển đổi sang trạng thái khác, đối với ở đây sẽ là discarding luôn mà không cần hỏi những SW khác trong mạng nữa vì là connected với nó nhưng chưa hình thành được kết nối lần nào cả.

logmeinvietnam

20-04-2009, 12:06 AM

<o:smarttagtype namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"></o:smarttagtype> Xin phép trích 1 câu trong White paper RSTP của Cisco:
Quote:
<table class="MsoNormalTable" style="width: 100%;" width="100%" border="0" cellpadding="0" cellspacing="0"> <tbody><tr style=""> <td style="border: 1pt inset ; padding: 4.5pt;"> Once p0 receives that agreement, it can immediately transition to the forwarding state
</td> </tr> </tbody></table> Câu này cho biết khi nhận được agreement thì vào forwarding ngay lập tức.
Theo em hiểu đến đây thì trạng thái learning chỉ xuất hiện khi Switch vừa phát hiện có sự thay đổi và chưa nhận được agreement
<link rel="File-List" href="file:///C:%5CDOCUME%7E1%5CADMINI%7E1%5CLOCALS%7E1%5CTemp%5 Cmsohtml1%5C01%5Cclip_filelist.xml"><style>  </style>
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.

cuibapcaca

20-04-2009, 06:12 PM

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.Sau khi hội tụ, giả sử có 1 link giữa 2 Switch, 1 bên SW1 có vai trò là designated port (trạng thái là forwarding) và 1 bên SW2 là alternate port (trạng thái là discarding). Nếu trong trạng thái discarding không gởi BPDU thì rốt cuộc chỉ có SW1 gởi BPDU cho SW2 à? port trên sw2 có trạng thái discarding nên sẽ không gởi BPDU cho Sw1 biết. Sw1 đợi 6 giây không nhận BPDU.... rồi nghĩ bên phía SW2 down????

Em thì nghĩ discarding vừa gởi và nhận BPDU. Do you think so?

logmeinvietnam

20-04-2009, 09:48 PM

Sau khi hội tụ, giả sử có 1 link giữa 2 Switch, 1 bên SW1 có vai trò là designated port (trạng thái là forwarding) và 1 bên SW2 là alternate port (trạng thái là discarding). Nếu trong trạng thái discarding không gởi BPDU thì rốt cuộc chỉ có SW1 gởi BPDU cho SW2 à? port trên sw2 có trạng thái discarding nên sẽ không gởi BPDU cho Sw1 biết. Sw1 đợi 6 giây không nhận BPDU.... rồi nghĩ bên phía SW2 down????

Em thì nghĩ discarding vừa gởi và nhận BPDU. Do you think so?

Nếu theo như bạn nói một bên là forward và bên còn lại là discard và mạng đã hội tụ thì đường này đâu có UP nữa, nên sẽ không có BPDU gửi qua.
6 giây ở đây là đối với những đường forward được traffic nhưng nó bỗng dưng đứt, qua 6 giây nó sẽ công nhận neighbor down. Ví dụ đường từ Root port tới RB đứt, với SW1 là RB và SW2 là con SW client bình thường. Khi BPDU bị mất lần đầu tiên thì SW2 đã lo gửi các Frame truy vấn Root Link Query qua láng giềng của nó tới khi nào tìm được RB lại qua con đường khác thì thôi.

Còn về trường hợp mà Discard nhận được BPDU khi mà SW2 chỉ có 2 nối, một tới RB và một tới SW3. Khi đường tới RB mất thì SW 2 sẽ gửi BPDU qua cho cổng discard của R3.

cuibapcaca

21-04-2009, 10:24 AM

Nếu theo như bạn nói một bên là forward và bên còn lại là discard và mạng đã hội tụ thì đường này đâu có UP nữa, nên sẽ không có BPDU gửi qua.
6 giây ở đây là đối với những đường forward được traffic nhưng nó bỗng dưng đứt, qua 6 giây nó sẽ công nhận neighbor down. Ví dụ đường từ Root port tới RB đứt, với SW1 là RB và SW2 là con SW client bình thường. Khi BPDU bị mất lần đầu tiên thì SW2 đã lo gửi các Frame truy vấn Root Link Query qua láng giềng của nó tới khi nào tìm được RB lại qua con đường khác thì thôi.Như vậy đối với những link tạm thời bị disable (về mặt logical) trong RSTP, nếu những link này có bị đứt về mặt vật lý đi chăng nữa thì cũng chẳng ảnh hưởng gì đến hòa bình thế giới, đúng không anh?
Đối với những trường hợp thế này thì SW nhận biết trực tiếp link bị đứt (ý em là đứt về mặt vật lý, còn trước khi đứt thì nó nghĩ về mặt logic thì bị block) thì có gởi TCN lên cho RB không nhĩ?

logmeinvietnam

21-04-2009, 04:08 PM

Như vậy đối với những link tạm thời bị disable (về mặt logical) trong RSTP, nếu những link này có bị đứt về mặt vật lý đi chăng nữa thì cũng chẳng ảnh hưởng gì đến hòa bình thế giới, đúng không anh?
Đối với những trường hợp thế này thì SW nhận biết trực tiếp link bị đứt (ý em là đứt về mặt vật lý, còn trước khi đứt thì nó nghĩ về mặt logic thì bị block) thì có gởi TCN lên cho RB không nhĩ?

Bạn thông cảm, có lẽ do lúc test mình có vấn đề về cáp.
Một bên block và một bên forward thì vẫn UP. nhưng block port không sinh ra BPDU. Bạn có thể test bằng lệnh "SW#debug spanning-tree bpdu" sẽ thấy ngay.

cuibapcaca

21-04-2009, 05:00 PM

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

Đối với những trường hợp thế này thì SW nhận biết trực tiếp link bị đứt (ý em là đứt về mặt vật lý, còn trước khi đứt thì nó nghĩ về mặt logic thì bị block) thì có gởi TCN lên cho RB không nhĩ?

cuibapcaca

23-04-2009, 06:25 PM

Anh logmeinvietnam ơi, tiếp tục thảo luận đi anh!!!

logmeinvietnam

23-04-2009, 09:03 PM

Anh logmeinvietnam ơi, tiếp tục thảo luận đi anh!!!

Uh vấn đề này mình sẽ test lại giùm cho, chứ trả lời thì không chắc lắm. Có gì mình sẽ trả lời sau.

logmeinvietnam

26-04-2009, 10:54 AM

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

04-05-2009, 03:08 PM

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

04-05-2009, 03:28 PM

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

http://i609.photobucket.com/albums/tt178/cuibapcaca_photos/1.jpg

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

http://i609.photobucket.com/albums/tt178/cuibapcaca_photos/2.jpg

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:

http://i609.photobucket.com/albums/tt178/cuibapcaca_photos/3.jpg

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.

http://i609.photobucket.com/albums/tt178/cuibapcaca_photos/4.jpg

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???

logmeinvietnam

04-05-2009, 06:27 PM

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

04-05-2009, 08:31 PM

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

07-05-2009, 11:43 AM

Tiếp tục đi nhĩ

logmeinvietnam

07-05-2009, 11:13 PM

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"><style>  </style> 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

13-05-2009, 10:19 AM

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ĩ?

logmeinvietnam

13-05-2009, 11:17 AM

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.