Đa phương tiện PIM-SM và HSRP / VRRP


10

Tôi cần thiết lập PC để nghe trên nguồn cấp dữ liệu phát đa hướng (PIM-SM). Các nguồn phát đa hướng và điểm Rendezvous (anycast) nằm phía sau "địa chỉ HSRP / VRRP" ở phía bên kia của liên kết WAN. (Các hướng dẫn thực sự nói "HSRP / VRRP")

Theo tài liệu nhận được, tôi đã thiết lập một bộ định tuyến có tuyến tĩnh đến địa chỉ HSRP / VRRP và phía bên kia đã thêm một tuyến vào mạng của tôi. Lưu lượng Unicast hoạt động tốt, nhưng tôi không nhận được bất kỳ lưu lượng phát đa hướng nào. Wireshark cho thấy không có kết nối PIM nào được gửi bởi bộ định tuyến của tôi.

điều gì sai?

Câu trả lời:


7

Tin nhắn PIM không có nguồn gốc từ HSRP VIP vì vậy kiểm tra RPF không thành công vì HSRP VIP là hàng xóm RPF của bạn. Có hai cách xung quanh điều này mặc dù.

  1. Thiết lập giao thức định tuyến động giữa bộ định tuyến của bạn và các bộ định tuyến bên khác để HSRP không cần thiết.

  2. Định cấu hình mrout tĩnh cho các mặt khác của IP giao diện thực tế, chẳng hạn như:

    ip mroute 0.0.0.0 0.0.0.0 1.1.1.1


2

Vấn đề là các bộ định tuyến từ xa đang tự thông báo với các tin nhắn PIM Hello từ địa chỉ IP của chính họ và bộ định tuyến của tôi đăng ký các địa chỉ này làm hàng xóm PIM.

Tuy nhiên, cổng trong bảng định tuyến chứa địa chỉ ảo HSRP. Khi bộ định tuyến muốn tham gia nhóm phát đa hướng, nó sẽ tìm tuyến đến Điểm Rendezvous có địa chỉ ảo HSRP làm bước nhảy tiếp theo. Vì địa chỉ HSRP tiếp theo này không phải là một trong những hàng xóm PIM đã biết, PFC-SM RFC chỉ định không nên tham gia.

Việc thay đổi tuyến tĩnh để sử dụng địa chỉ IP thực tế của một trong các bộ định tuyến HSRP làm cho đa tuyến hoạt động, nhưng tất nhiên điều này làm cho HSRP trở nên vô dụng.

Tôi chưa thử nghiệm VRRP vì phía bên kia không muốn thay đổi mạng. VRRP có thể sẽ không gặp vấn đề này vì nó không sử dụng IP bộ định tuyến ảo, nhưng sử dụng địa chỉ IP thực của bộ định tuyến chính.


RFC 2362 đã lỗi thời thực sự ghi rõ "Tin nhắn tham gia / Prune chỉ được gửi nếu hàng xóm RPF là hàng xóm PIM." Tôi không thể tìm thấy điều tương tự chính xác trong RFC 4601 hiện tại, nhưng thông báo "Nói chung, thông báo PIM Join / Prune chỉ nên được chấp nhận để xử lý nếu nó đến từ một người hàng xóm PIM đã biết."
Gerben

1
... sẽ tốt hơn nếu chỉnh sửa thông tin bổ sung vào câu hỏi ban đầu của bạn nếu bạn đã học được nhiều hơn kể từ khi viết Q. Hoặc nếu đây có nghĩa là một câu trả lời cho câu hỏi của riêng bạn (điều này hoàn toàn chấp nhận được), thì nó cần rất nhiều của công việc để có ý nghĩa.
Craig Constantine

Bạn sẽ thấy hành vi tương tự với VRRP khi hầu hết các triển khai hiện đại đều sử dụng VIP.
netdad

2

Có lẽ sử dụng một mroute tĩnh trỏ đến địa chỉ IP giao diện 'thực', sau đó một tuyến tĩnh bình thường trỏ đến HSRP. sau đó ít nhất bạn nhận được HSRP cho unicast. HOẶC chỉ đường mroute hoặc tuyến tĩnh đến giao diện thay vì địa chỉ IP.


Trong trường hợp này, thiết lập chỉ được xây dựng để hiển thị thông tin đến thông qua phát đa hướng, nhưng nếu không thì đây có thể là một sự cải tiến.
Gerben

2

Giả sử bạn đang ở trong môi trường Cisco .... bạn đã bật ip pim sparse-mode tất cả các giao diện giữa thiết bị đó và RP chưa?

Cũng đừng quên để ip pim autorp listenernó tự động tìm RP.

Ngoài ra - nếu bạn có các liên kết dự phòng giữa bạn và RP ... định tuyến PIM (hoặc các nhánh) không đi theo cùng một đường dẫn như bảng định tuyến thông thường. Họ S check kiểm tra RPF (chuyển tiếp đường dẫn ngược) để đảm bảo nguồn phát đa hướng đến từ đúng hướng. Nhưng có thể có liên kết HSRP dự phòng là DR (bộ định tuyến được chỉ định) ở phía PIM của ngôi nhà. Bạn có thể thay đổi hành vi này bằng cách đặt mức độ ưu tiên DR. ip pim dr-priority xX càng cao thì giá trị càng cao.

Bạn cũng có thể kiểm tra xem liệu bộ định tuyến có nhìn thấy đa liên kết hay không bằng cách phát hành show ip mroutenó cũng nên liệt kê RP.

show ip pim neigh cũng sẽ cho bạn biết nếu nó thấy hàng xóm phát đa hướng ngược dòng

Tôi tin rằng VRRP tuân theo cùng một khái niệm tuy nhiên tôi không chắc chắn 100% vì tôi không thường xuyên sử dụng các cổng mặc định của nhiều nhà cung cấp.


"Họ" đã ở trên Cisco, "chúng tôi" đã ở trên Juniper.
Gerben
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.