Giao thức PIM là một tập hợp các giao thức để truyền phát đa hướng trong mạng giữa các bộ định tuyến. Các mối quan hệ lân cận được xây dựng theo cách tương tự như trong trường hợp các giao thức định tuyến động. PIMv2 gửi tin nhắn Hello cứ sau 30 giây đến địa chỉ multicast dành riêng 224.0.0.13 (Tất cả các bộ định tuyến PIM). Thông báo chứa Bộ hẹn giờ giữ - thường bằng 3.5*Bộ hẹn giờ xin chào, nghĩa là 105 giây theo mặc định.
PIM sử dụng hai chế độ hoạt động chính - Chế độ dày đặc và thưa thớt. Hãy bắt đầu với chế độ Dày đặc.
Cây phân phối dựa trên nguồn.
Chế độ dày đặc được khuyến khích sử dụng trong trường hợp có số lượng lớn khách hàng thuộc các nhóm phát đa hướng khác nhau. Khi một bộ định tuyến nhận được lưu lượng multicast, điều đầu tiên nó làm là kiểm tra quy tắc RPF. RPF - quy tắc này được sử dụng để kiểm tra nguồn của multicast bằng bảng định tuyến unicast. Điều cần thiết là lưu lượng truy cập phải đến giao diện phía sau mà máy chủ này bị ẩn theo phiên bản của bảng định tuyến unicast. Cơ chế này giải quyết vấn đề xảy ra vòng lặp trong quá trình truyền multicast.
R3 sẽ nhận ra nguồn multicast (IP nguồn) từ tin nhắn multicast và kiểm tra hai luồng từ R1 và R2 bằng bảng unicast của nó. Luồng từ giao diện được bảng trỏ đến (R1 đến R3) sẽ được truyền đi xa hơn và luồng từ R2 sẽ bị loại bỏ, vì để đến được nguồn phát đa hướng, bạn cần gửi các gói qua S0/1.
Câu hỏi là, điều gì sẽ xảy ra nếu bạn có hai tuyến đường tương đương với cùng một số liệu? Trong trường hợp này, bộ định tuyến sẽ chọn bước nhảy tiếp theo từ các tuyến này. Ai có địa chỉ IP cao hơn sẽ thắng. Nếu cần thay đổi hành vi này, bạn có thể sử dụng ECMP. Thêm chi tiết .
Sau khi kiểm tra quy tắc RPF, bộ định tuyến sẽ gửi một gói multicast đến tất cả các PIM lân cận của nó, ngoại trừ gói được nhận từ đó. Các bộ định tuyến PIM khác lặp lại quá trình này. Đường dẫn mà gói multicast đi từ nguồn đến người nhận cuối cùng tạo thành một cây gọi là cây phân phối dựa trên nguồn, cây đường đi ngắn nhất (SPT), cây nguồn. Ba tên khác nhau, chọn bất kỳ tên nào.
Làm thế nào để giải quyết vấn đề một số bộ định tuyến không từ bỏ một số luồng phát đa hướng và không có ai để gửi nó đến nhưng bộ định tuyến ngược dòng lại gửi nó cho anh ta. Cơ chế Prune được phát minh cho việc này.
Thông điệp cắt tỉa.
Ví dụ, R2 sẽ tiếp tục gửi một multicast tới R3, mặc dù R3, theo quy tắc RPF, loại bỏ nó. Tại sao tải kênh? R3 gửi Thông báo PIM Prune và R2, khi nhận được thông báo này, sẽ xóa giao diện S0/1 khỏi danh sách giao diện gửi đi cho luồng này, danh sách các giao diện mà lưu lượng này sẽ được gửi từ đó.
Sau đây là định nghĩa chính thức hơn về thông báo PIM Prune:
Thông báo PIM Prune được một bộ định tuyến gửi đến bộ định tuyến thứ hai để khiến bộ định tuyến thứ hai xóa liên kết mà Prune được nhận từ một SPT cụ thể (S,G).
Sau khi nhận được thông báo Prune, R2 đặt bộ đếm thời gian Prune thành 3 phút. Sau ba phút, nó sẽ bắt đầu gửi lại lưu lượng truy cập cho đến khi nhận được một tin nhắn Prune khác. Đây là trong PIMv1.
Và trong PIMv2, bộ hẹn giờ Làm mới trạng thái đã được thêm vào (theo mặc định là 60 giây). Ngay sau khi một tin nhắn Prune được gửi từ R3, bộ đếm thời gian này sẽ được khởi động trên R3. Khi hết thời gian hẹn giờ này, R3 sẽ gửi thông báo Làm mới trạng thái, thông báo này sẽ đặt lại Bộ đếm thời gian cắt tỉa 3 phút trên R2 cho nhóm này.
Lý do gửi tin nhắn Prune:
- Khi gói multicast không kiểm tra được RPF.
- Khi không có máy khách nào được kết nối cục bộ đã yêu cầu một nhóm phát đa hướng (Tham gia IGMP) và không có hàng xóm PIM nào có thể gửi lưu lượng phát đa hướng (Giao diện không cắt tỉa).
Tin nhắn ghép.
Hãy tưởng tượng rằng R3 không muốn lưu lượng truy cập từ R2, gửi Prune và nhận multicast từ R1. Nhưng đột nhiên, kênh giữa R1-R3 bị rớt và R3 không còn phát đa hướng. Bạn có thể đợi 3 phút cho đến khi hết thời gian bấm giờ Prune trên R2. 3 phút là một thời gian chờ đợi lâu, để không phải chờ đợi, bạn cần gửi một tin nhắn sẽ ngay lập tức đưa giao diện S0/1 này về R2 ra khỏi trạng thái rút gọn. Tin nhắn này sẽ là tin nhắn Graft. Sau khi nhận được tin nhắn Graft, R2 sẽ phản hồi bằng Graft-ACK.
Cắt tỉa ghi đè.
Chúng ta hãy nhìn vào sơ đồ này. R1 phát đa hướng tới một phân đoạn có hai bộ định tuyến. R3 nhận và phát lưu lượng, R2 nhận nhưng không có ai để phát lưu lượng. Nó gửi bản tin Prune tới R1 trong đoạn này. R1 nên xóa Fa0/0 khỏi danh sách và ngừng phát sóng ở phân đoạn này, nhưng điều gì sẽ xảy ra với R3? Và R3 cũng cùng phân khúc, cũng nhận được tin nhắn này từ Prune và hiểu được sự bi kịch của hoàn cảnh. Trước khi R1 ngừng phát sóng, nó đặt hẹn giờ là 3 giây và sẽ ngừng phát sóng sau 3 giây. 3 giây - đây chính xác là lượng thời gian mà R3 có để không bị mất phát đa hướng. Vì vậy, R3 gửi tin nhắn Pim Join cho nhóm này càng sớm càng tốt và R1 không còn nghĩ đến việc ngừng phát sóng nữa. Giới thiệu về Tham gia các tin nhắn bên dưới.
Khẳng định tin nhắn.
Hãy tưởng tượng tình huống này: hai bộ định tuyến phát sóng tới một mạng cùng một lúc. Họ nhận được cùng một luồng từ nguồn và cả hai đều phát luồng đó đến cùng một mạng phía sau giao diện e0. Vì vậy, họ cần xác định ai sẽ là đài truyền hình duy nhất cho mạng này. Thông báo khẳng định được sử dụng cho việc này. Khi R2 và R3 phát hiện sự trùng lặp của lưu lượng multicast, nghĩa là R2 và R3 nhận được một multicast mà chính chúng phát sóng, các bộ định tuyến sẽ hiểu rằng có điều gì đó không ổn ở đây. Trong trường hợp này, bộ định tuyến gửi tin nhắn Xác nhận, bao gồm Khoảng cách quản trị và số liệu tuyến đường mà nguồn phát đa hướng đạt được - 10.1.1.10. Người chiến thắng được xác định như sau:
- Người có AD thấp hơn.
- Nếu AD bằng nhau thì ai có số liệu thấp hơn.
- Nếu có sự bình đẳng ở đây thì người có IP cao hơn trong mạng mà họ phát multicast này.
Người chiến thắng trong cuộc bỏ phiếu này sẽ trở thành Bộ định tuyến được chỉ định. Pim Hello cũng được sử dụng để chọn DR. Ở đầu bài viết có thông báo PIM Hello hiển thị, bạn có thể thấy trường DR ở đó. Người có địa chỉ IP cao nhất trên liên kết này sẽ thắng.
Dấu hiệu hữu ích:
Bảng MOUTE.
Sau cái nhìn ban đầu về cách hoạt động của giao thức PIM, chúng ta cần hiểu cách làm việc với bảng định tuyến multicast. Bảng mroute lưu trữ thông tin về luồng nào được yêu cầu từ máy khách và luồng nào đang chảy từ máy chủ multicast.
Ví dụ: khi nhận được Báo cáo thành viên IGMP hoặc Tham gia PIM trên một số giao diện, một bản ghi thuộc loại ( *, G ) sẽ được thêm vào bảng định tuyến:
Mục nhập này có nghĩa là đã nhận được yêu cầu lưu lượng truy cập với địa chỉ 238.38.38.38. Cờ DC có nghĩa là multicast sẽ hoạt động ở chế độ Dense và C có nghĩa là người nhận được kết nối trực tiếp với bộ định tuyến, nghĩa là bộ định tuyến đã nhận được Báo cáo thành viên IGMP và PIM Join.
Nếu có bản ghi loại (S,G) thì có nghĩa là chúng ta có luồng phát đa hướng:
Trong trường S - 192.168.1.11, chúng tôi đã đăng ký địa chỉ IP của nguồn multicast, địa chỉ này sẽ được kiểm tra theo quy tắc RPF. Nếu có vấn đề, điều đầu tiên bạn cần làm là kiểm tra bảng unicast để tìm đường tới nguồn. Trong trường Giao diện đến, cho biết giao diện mà multicast được nhận. Trong bảng định tuyến unicast, tuyến đường tới nguồn phải tham khảo giao diện được chỉ định ở đây. Giao diện gửi đi chỉ định nơi multicast sẽ được chuyển hướng. Nếu nó trống thì bộ định tuyến chưa nhận được bất kỳ yêu cầu nào cho lưu lượng này. Thông tin thêm về tất cả các lá cờ có thể được tìm thấy .
Chế độ thưa thớt PIM.
Chiến lược của Chế độ thưa thớt trái ngược với Chế độ dày đặc. Khi Chế độ thưa thớt nhận được lưu lượng truy cập đa hướng, nó sẽ chỉ gửi lưu lượng truy cập qua các giao diện nơi đã có yêu cầu cho luồng này, ví dụ: Thông báo Pim Join hoặc IGMP Report yêu cầu lưu lượng này.
Các yếu tố tương tự cho SM và DM:
- Mối quan hệ lân cận được xây dựng giống như trong PIM DM.
- Quy tắc RPF hoạt động.
- Việc lựa chọn DR cũng tương tự.
- Cơ chế của thông báo Prune Overrides và Assert tương tự nhau.
Để kiểm soát ai, ở đâu và loại lưu lượng multicast nào cần thiết trên mạng, cần có một trung tâm thông tin chung. Trung tâm của chúng tôi sẽ là Điểm hẹn (RP). Bất kỳ ai muốn một số loại lưu lượng multicast hoặc ai đó bắt đầu nhận được lưu lượng multicast từ nguồn thì gửi nó tới RP.
Khi RP nhận được lưu lượng multicast, nó sẽ gửi nó đến các bộ định tuyến đã yêu cầu lưu lượng này trước đó.
Hãy tưởng tượng một cấu trúc liên kết trong đó RP là R3. Ngay khi R1 nhận được lưu lượng truy cập từ S1, nó sẽ đóng gói gói multicast này thành một thông báo Đăng ký PIM unicast và gửi nó đến RP. Làm sao anh ta biết RP là ai? Trong trường hợp này, nó được cấu hình tĩnh và chúng ta sẽ nói về cấu hình RP động sau.
địa chỉ ip pim rp 3.3.3.3
RP sẽ xem xét - có thông tin nào từ người muốn nhận lưu lượng truy cập này không? Hãy giả sử là không phải vậy. Sau đó RP sẽ gửi cho R1 một tin nhắn PIM Register-Stop, nghĩa là không ai cần multicast này, việc đăng ký sẽ bị từ chối. R1 sẽ không gửi phát đa hướng. Nhưng máy chủ nguồn multicast sẽ gửi nó, do đó R1, sau khi nhận được Register-Stop, sẽ bắt đầu bộ đếm thời gian Register-Suppression bằng 60 giây. 5 giây trước khi bộ đếm thời gian này hết hạn, R1 sẽ gửi một thông báo Đăng ký trống có bit Null-Register (nghĩa là không có gói multicast được đóng gói) tới RP. Ngược lại, RP sẽ hoạt động như thế này:
- Nếu không có người nhận thì nó sẽ phản hồi bằng thông báo Register-Stop.
- Nếu người nhận xuất hiện, anh ta sẽ không phản hồi dưới bất kỳ hình thức nào. R1, nếu không nhận được từ chối đăng ký trong vòng 5 giây, sẽ vui lòng gửi tin nhắn Đăng ký với gói multicast được đóng gói tới RP.
Có vẻ như chúng ta đã tìm ra cách multicast đạt được RP, bây giờ hãy thử trả lời câu hỏi RP phân phối lưu lượng truy cập đến người nhận như thế nào. Ở đây cần phải giới thiệu một khái niệm mới - cây đường dẫn gốc (RPT). RPT là một cây bắt nguồn từ RP, phát triển về phía người nhận, phân nhánh trên mỗi bộ định tuyến PIM-SM. RP tạo ra nó bằng cách nhận các tin nhắn PIM Join và thêm một nhánh mới vào cây. Và như vậy, mọi bộ định tuyến xuôi dòng đều làm như vậy. Quy tắc chung trông như thế này:
- Khi bộ định tuyến PIM-SM nhận được thông báo PIM Join trên bất kỳ giao diện nào khác ngoài giao diện mà RP bị ẩn phía sau, nó sẽ thêm một nhánh mới vào cây.
- Một nhánh cũng được thêm vào khi bộ định tuyến PIM-SM nhận được Báo cáo thành viên IGMP từ máy chủ được kết nối trực tiếp.
Hãy tưởng tượng rằng chúng ta có một máy khách multicast trên bộ định tuyến R5 cho nhóm 228.8.8.8. Ngay khi R5 nhận được Báo cáo thành viên IGMP từ máy chủ, R5 sẽ gửi PIM Join theo hướng RP và chính nó sẽ thêm giao diện vào cây nhìn vào máy chủ. Tiếp theo, R4 nhận PIM Join từ R5, thêm giao diện Gi0/1 vào cây và gửi PIM Join theo hướng RP. Cuối cùng, RP ( R3 ) nhận PIM Join và thêm Gi0/0 vào cây. Do đó, người nhận multicast đã được đăng ký. Chúng ta đang xây dựng một cây có gốc R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Sau đó, PIM Join sẽ được gửi đến R1 và R1 sẽ bắt đầu gửi lưu lượng multicast. Điều quan trọng cần lưu ý là nếu máy chủ yêu cầu lưu lượng trước khi quá trình phát đa hướng bắt đầu thì RP sẽ không gửi PIM Join và sẽ không gửi bất cứ điều gì đến R1.
Nếu đột nhiên trong khi gửi multicast, máy chủ ngừng muốn nhận nó, ngay khi RP nhận được PIM Prune trên giao diện Gi0/0, nó sẽ ngay lập tức gửi PIM Register-Stop trực tiếp tới R1, và sau đó là PIM Prune thông báo qua giao diện Gi0/1. Dừng đăng ký PIM được gửi qua unicast đến địa chỉ mà Đăng ký PIM đến.
Như chúng tôi đã nói trước đó, ngay khi một bộ định tuyến gửi PIM Join đến một bộ định tuyến khác, chẳng hạn như R5 đến R4, thì một bản ghi sẽ được thêm vào R4:
Và một bộ đếm thời gian được bắt đầu mà R5 phải liên tục thiết lập lại các tin nhắn PIM Join của bộ đếm thời gian này liên tục, nếu không R4 sẽ bị loại khỏi danh sách gửi đi. R5 sẽ gửi mỗi 60 tin nhắn PIM Join.
Chuyển đổi cây đường dẫn ngắn nhất.
Chúng tôi sẽ thêm giao diện giữa R1 và R5 và xem lưu lượng truy cập di chuyển với cấu trúc liên kết này như thế nào.
Giả sử rằng lưu lượng được gửi và nhận theo sơ đồ cũ R1-R2-R3-R4-R5 và ở đây chúng tôi đã kết nối và định cấu hình giao diện giữa R1 và R5.
Trước hết, chúng ta phải xây dựng lại bảng định tuyến unicast trên R5 và bây giờ đã đạt được mạng 192.168.1.0/24 thông qua giao diện R5 Gi0/2. Bây giờ R5, nhận multicast trên giao diện Gi0/1, hiểu rằng quy tắc RPF không được thỏa mãn và sẽ hợp lý hơn nếu nhận multicast trên Gi0/2. Nó sẽ ngắt kết nối khỏi RPT và xây dựng một cây ngắn hơn gọi là Cây đường dẫn ngắn nhất (SPT). Để làm điều này, anh ta gửi PIM Join tới R0 thông qua Gi2/1 và R1 cũng bắt đầu gửi một multicast thông qua Gi0/2. Bây giờ R5 cần hủy đăng ký RPT để không nhận được hai bản. Để làm điều này, anh ta gửi cho Prune một tin nhắn cho biết địa chỉ IP nguồn và chèn một bit đặc biệt - bit RPT. Điều này có nghĩa là bạn không cần gửi lưu lượng truy cập cho tôi, tôi có cây tốt hơn ở đây. RP cũng gửi tin nhắn PIM Prune tới R1 nhưng không gửi tin nhắn Register-Stop. Một tính năng khác: R5 giờ đây sẽ liên tục gửi PIM Prune tới RP, vì R1 tiếp tục gửi Đăng ký PIM tới RP mỗi phút. Cho đến khi không còn người mới muốn lưu lượng truy cập này, RP sẽ từ chối. R5 thông báo cho RP rằng nó tiếp tục nhận multicast thông qua SPT.
Tìm kiếm RP động.
Tự động-RP.
Công nghệ này là độc quyền của Cisco và không đặc biệt phổ biến nhưng vẫn còn tồn tại. Hoạt động Auto-RP bao gồm hai giai đoạn chính:
1) RP gửi tin nhắn Thông báo RP đến địa chỉ dành riêng - 224.0.1.39, tự khai báo RP cho mọi người hoặc cho các nhóm cụ thể. Tin nhắn này được gửi mỗi phút.
2) Cần có một tác nhân ánh xạ RP, tác nhân này sẽ gửi các tin nhắn RP-Discovery cho biết nhóm nào nên lắng nghe RP. Chính từ thông báo này mà các bộ định tuyến PIM thông thường sẽ tự xác định RP. Tác nhân ánh xạ có thể là chính bộ định tuyến RP hoặc bộ định tuyến PIM riêng biệt. RP-Discovery được gửi đến địa chỉ 224.0.1.40 với thời gian hẹn giờ là một phút.
Chúng ta hãy xem xét quá trình chi tiết hơn:
Hãy định cấu hình R3 là RP:
ip pim gửi-rp-thông báo loopback 0 phạm vi 10
R2 làm tác nhân ánh xạ:
ip pim send-rp-discovery loopback 0 phạm vi 10
Và trên tất cả những thứ khác, chúng tôi sẽ mong đợi RP thông qua Auto-RP:
trình nghe autorp ip pim
Khi chúng tôi định cấu hình R3, nó sẽ bắt đầu gửi RP-Announce:
Và R2, sau khi thiết lập tác nhân ánh xạ, sẽ bắt đầu chờ thông báo RP-Announce. Chỉ khi tìm thấy ít nhất một RP thì nó mới bắt đầu gửi RP-Discovery:
Bằng cách này, ngay khi các bộ định tuyến thông thường (PIM RP Listener) nhận được thông báo này, họ sẽ biết tìm RP ở đâu.
Một trong những vấn đề chính với Auto-RP là để nhận được tin nhắn RP-Announce và RP-Discovery, bạn cần gửi PIM Join tới địa chỉ 224.0.1.39-40, và để gửi, bạn cần biết địa chỉ của RP được định vị. Vấn đề kinh điển về con gà và quả trứng. Để giải quyết vấn đề này, Chế độ thưa thớt PIM đã được phát minh. Nếu bộ định tuyến không biết RP thì nó hoạt động ở chế độ Dày đặc; nếu có thì ở chế độ Thưa thớt. Khi lệnh PIM Sparse-mode và ip pim autorp Listen được định cấu hình trên giao diện của các bộ định tuyến thông thường, bộ định tuyến sẽ chỉ hoạt động ở Chế độ dày đặc để phát đa hướng trực tiếp từ giao thức Auto-RP (224.0.1.39-40).
Bộ định tuyến BootStrap (BSR).
Chức năng này hoạt động tương tự như Auto-RP. Mỗi RP gửi một tin nhắn đến tác nhân ánh xạ, tác nhân này thu thập thông tin ánh xạ và sau đó thông báo cho tất cả các bộ định tuyến khác. Hãy mô tả quá trình tương tự như Auto-RP:
1) Khi chúng tôi định cấu hình R3 làm ứng cử viên là RP, bằng lệnh:
ip pim rp-ứng cử viên loopback 0
Khi đó R3 sẽ không làm gì cả, để bắt đầu gửi những tin nhắn đặc biệt, trước tiên anh ta cần tìm một nhân viên lập bản đồ. Vì vậy, chúng ta chuyển sang bước thứ hai.
2) Định cấu hình R2 làm tác nhân ánh xạ:
ip pim bsr-ứng cử viên loopback 0
R2 bắt đầu gửi tin nhắn PIM Bootstrap, trong đó nó tự cho biết mình là tác nhân ánh xạ:
Tin nhắn này được gửi đến địa chỉ 224.0.013, địa chỉ mà giao thức PIM cũng sử dụng cho các tin nhắn khác của nó. Nó gửi chúng đi mọi hướng và do đó không có vấn đề về con gà và quả trứng như trong Auto-RP.
3) Ngay khi RP nhận được tin nhắn từ bộ định tuyến BSR, nó sẽ ngay lập tức gửi tin nhắn unicast đến địa chỉ bộ định tuyến BSR:
Sau đó, BSR, sau khi nhận được thông tin về các RP, sẽ gửi chúng bằng multicast đến địa chỉ 224.0.0.13, địa chỉ này được tất cả các bộ định tuyến PIM lắng nghe. Do đó, một sự tương tự của lệnh trình nghe autorp ip pim đối với các bộ định tuyến thông thường không có trong BSR.
Anycast RP với Giao thức khám phá nguồn đa hướng (MSDP).
Auto-RP và BSR cho phép chúng ta phân phối tải trên RP như sau: Mỗi nhóm multicast chỉ có một RP hoạt động. Sẽ không thể phân phối tải cho một nhóm multicast trên nhiều RP. MSDP thực hiện điều này bằng cách cấp cho bộ định tuyến RP cùng một địa chỉ IP với mặt nạ 255.255.255.255. MSDP tìm hiểu thông tin bằng một trong các phương pháp: tĩnh, Auto-RP hoặc BSR.
Trong hình chúng ta có cấu hình Auto-RP với MSDP. Cả hai RP đều được cấu hình với địa chỉ IP 172.16.1.1/32 trên giao diện Loopback 1 và được sử dụng cho tất cả các nhóm. Với RP-Announce, cả hai bộ định tuyến đều tự thông báo bằng cách tham chiếu đến địa chỉ này. Tác nhân ánh xạ Auto-RP sau khi nhận được thông tin sẽ gửi RP-Discovery về RP với địa chỉ 172.16.1.1/32. Chúng tôi thông báo cho các bộ định tuyến về mạng 172.16.1.1/32 bằng cách sử dụng IGP và theo đó. Do đó, các bộ định tuyến PIM yêu cầu hoặc đăng ký các luồng từ RP được chỉ định là bước nhảy tiếp theo trên tuyến tới mạng 172.16.1.1/32. Bản thân giao thức MSDP được thiết kế để chính các RP trao đổi thông báo về thông tin multicast.
Hãy xem xét cấu trúc liên kết này:
Switch6 phát lưu lượng truy cập đến địa chỉ 238.38.38.38 và cho đến nay chỉ RP-R1 biết về nó. Switch7 và Switch8 đã yêu cầu nhóm này. Bộ định tuyến R5 và R4 sẽ gửi PIM Join tới R1 và R3 tương ứng. Tại sao? Tuyến đến 13.13.13.13 cho R5 sẽ tham chiếu đến R1 bằng cách sử dụng số liệu IGP, giống như đối với R4.
RP-R1 biết về luồng và sẽ bắt đầu phát nó tới R5, nhưng R4 không biết gì về luồng đó, vì R1 sẽ không chỉ gửi nó. Vì vậy MSDP là cần thiết. Chúng tôi cấu hình nó trên R1 và R5:
ip msdp ngang hàng 3.3.3.3 nguồn kết nối Loopback1 trên R1
ip msdp ngang hàng 1.1.1.1 nguồn kết nối Loopback3 trên R3
Họ sẽ tạo một phiên giữa nhau và khi nhận được bất kỳ luồng nào, họ sẽ báo cáo cho người hàng xóm RP của mình.
Ngay khi RP-R1 nhận được một luồng từ Switch6, nó sẽ ngay lập tức gửi một tin nhắn MSDP Source-Active unicast, tin nhắn này sẽ chứa các thông tin như (S, G) - thông tin về nguồn và đích của multicast. Bây giờ RP-R3 đã biết rằng một nguồn như Switch6, khi nhận được yêu cầu từ R4 cho luồng này, nó sẽ gửi PIM Join tới Switch6, được hướng dẫn bởi bảng định tuyến. Do đó, R1 nhận được PIM Join như vậy sẽ bắt đầu gửi lưu lượng tới RP-R3.
MSDP chạy trên TCP, các RP gửi tin nhắn lưu giữ cho nhau để kiểm tra tính tồn tại. Đồng hồ tính giờ là 60 giây.
Chức năng phân chia các MSDP ngang hàng thành các miền khác nhau vẫn chưa rõ ràng, vì các thông báo Keepalive và SA không biểu thị tư cách thành viên trong bất kỳ miền nào. Ngoài ra, trong cấu trúc liên kết này, chúng tôi đã thử nghiệm cấu hình chỉ ra các miền khác nhau - không có sự khác biệt về hiệu suất.
Nếu bất cứ ai có thể làm rõ, tôi sẽ rất vui khi đọc nó trong phần bình luận.
Nguồn: www.habr.com