PIM-SM qua VPN: kiểm tra BSR, ánh xạ RP và các đường RPF

Đường hầm đã hoạt động, ping unicast đi qua nó, mà máy thu vẫn hiển thị màn hình đen. Trong một triển khai PIM-SM, triệu chứng đó gần như luôn có nghĩa là một trong bốn đường điều khiển bị hỏng, và đường dữ liệu chưa bao giờ là vấn đề. Hãy đi qua danh sách dưới đây theo thứ tự và dừng ở bước đầu tiên thất bại, vì mọi bước sau đều phụ thuộc vào bước trước. Tôi giữ năm phép kiểm tra này trong một tệp nháp và dán chúng vào terminal khi có khiếu nại về multicast, điều đó giúp chẩn đoán không biến thành phỏng đoán.

Bắt đầu từ máy thu, không phải từ đường hầm

Một máy thu chưa bao giờ yêu cầu nhóm không tạo ra trạng thái nào trên bất kỳ router nào, nên hãy xác nhận rằng việc tham gia tồn tại trên phân đoạn hướng về máy thu trước khi kiểm tra bất cứ điều gì khác. Trên các nền tảng kiểu Cisco, show ip igmp groups trên router chặng cuối in ra các nhóm đã tham gia bên cạnh giao diện đã nghe thấy chúng. Khi nhóm không có trong kết quả đó, đường hầm chỉ là thứ làm phân tâm: yêu cầu đã chết tại switch truy cập, tại socket của máy chủ hoặc trong một VLAN không có querier.

Hai nguyên nhân thông thường giải thích phần lớn các trường hợp thiếu tham gia mà tôi đã thấy: sự không khớp phiên bản IGMP giữa máy chủ và router, và một cuộc bầu querier rơi vào switch không định tuyến. Nguyên nhân thứ ba tinh tế hơn: nhóm đã được tham gia nhưng ở VLAN sai, vì máy chủ có hai card mạng và ứng dụng gắn với card sai. Máy thu IPv6 gặp vấn đề tương tự với MLD, nơi show ipv6 mld groups trả lời đúng câu hỏi đó. Không điều nào trong số này được khắc phục bằng cách chạm vào đường hầm, và đó chính là lý do thứ tự quan trọng.

Khi việc tham gia đã hiển thị, hãy xác nhận PIM được bật trên cả giao diện hướng về máy thu và giao diện dẫn tới điểm hẹn. Một router có tư cách thành viên IGMP nhưng không có PIM trên giao diện thượng nguồn sẽ giữ nhóm trong bảng cục bộ và không gửi gì đi đâu cả.

Tập BSR có tới được phía bên kia không?

Các thông điệp Bootstrap Router di chuyển từng chặng trong một miền PIM duy nhất, và đó là hướng bị vỡ khi qua đường hầm. Các RP ứng viên gửi quảng cáo của mình tới BSR được bầu bằng unicast, nên đoạn RP-tới-BSR thường sống sót nguyên vẹn trong một đường hầm hoạt động. Dòng lũ thông điệp Bootstrap theo hướng ngược lại phụ thuộc vào việc mọi giao diện trung gian đều bật PIM và không có gì chặn thông điệp tại ranh giới. RFC 5059 định nghĩa việc phân phối đó và các ranh giới phạm vi quản trị được phép cắt ngắn nó.

Một câu lệnh ip pim bsr-border, một ACL lọc giao thức 103, hoặc một đường hầm IPsec dựa trên chính sách không thể mang multicast, mỗi thứ đều sẽ cắt dòng lũ trong khi unicast vẫn nguyên vẹn. Chính sự kết hợp đó khiến lỗi trông như vấn đề RP trong khi thực chất là vấn đề khả năng tiếp cận, và đó là lý do tôi đọc trạng thái BSR trước khi đọc cấu hình RP.

Trên router phía xa, show ip pim bsr-router nêu BSR được bầu và tập RP đã học; nếu kết quả trống, phía xa đang ở trong miền riêng của nó và không cấu hình RP nào có thể hòa giải hai bên. Hãy so sánh dải nhóm và địa chỉ RP trong show ip pim rp mapping ở hai phía đường hầm. Một ánh xạ chỉ tồn tại cục bộ sẽ tạo ra cây chia sẻ kết thúc ở sai chỗ, và máy thu chờ mãi mãi.

Khớp ánh xạ RP ở hai phía đường hầm

RP tĩnh, BSR và anycast-RP là ba cách trả lời cùng một câu hỏi, và trộn chúng qua đường hầm là cách chắc chắn để xây một miền không bao giờ hội tụ. Nếu đầu trung tâm dùng BSR còn chi nhánh dùng ip pim rp-address tĩnh trỏ tới địa chỉ khác, chi nhánh sẽ xây cây chia sẻ của mình về phía một RP không biết máy thu tồn tại. Ánh xạ phải khớp cả về dải nhóm lẫn địa chỉ, vì dải cụ thể hơn thắng dải rộng hơn.

Anycast-RP tồn tại chính là để hai site có thể chia sẻ một địa chỉ RP, và đáng nhắc ở đây vì nó thay đổi ý nghĩa của «cùng một RP». Hai RP cùng quảng cáo một địa chỉ là nhất quán theo thiết kế; hai RP quảng cáo các địa chỉ khác nhau cho cùng một dải thì không, dù mỗi site trông khỏe mạnh đến đâu khi đứng riêng.

Với multicast đặc thù theo nguồn trong 232.0.0.0/8, RP không bao giờ được hỏi tới, nên một ánh xạ RP trống không tự động là lỗi. Hãy quyết định ứng dụng dùng mô hình dịch vụ nào trước khi đuổi theo một RP chưa bao giờ cần đến.

Đọc tra cứu RPF về phía nguồn

PIM xây cây bằng cách đảo ngược đường unicast, nên phép kiểm tra quan trọng là tuyến quay lại nguồn, hoặc quay lại RP với cây chia sẻ. Một tham gia đến trên giao diện mà router không coi là thượng nguồn sẽ bị bỏ, và lý do được ghi là lỗi RPF chứ không phải lỗi đường hầm. Trên router chi nhánh có tuyến mặc định qua đường hầm và tuyến cụ thể hơn qua WAN, giao diện RPF có thể dễ dàng là WAN dù nguồn chỉ tiếp cận được qua đường hầm. Đó là lý do đơn lẻ phổ biến nhất khiến một tham gia bị bỏ một cách lặng lẽ.

show ip rpf 192.0.2.10 in ra giao diện được chọn, chặng kế tiếp và tuyến đã tạo ra quyết định, thường là đủ để thấy sự không khớp. Một tuyến multicast tĩnh như ip mroute 192.0.2.0 255.255.255.0 tunnel0 ghi đè tra cứu unicast cho tiền tố đó, và đó là cách sửa hợp lý khi topo multicast thực sự khác topo unicast. Hãy coi nó là cấu hình cần được ghi lại, không phải một miếng vá áp dụng trong lúc sự cố rồi bị lãng quên.

Xác nhận tham gia bằng lệnh, không phải bằng ping

Ping chứng minh unicast hoạt động, điều bạn đã biết. Xác nhận đầu-cuối là một chuỗi cho thấy tham gia, ánh xạ, láng giềng và cây theo đúng thứ tự đó, và mỗi lệnh trả lời một câu hỏi khác nhau.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Một mục (S,G) đầy đủ với giao diện vào thật và danh sách ra không rỗng nghĩa là mặt phẳng điều khiển đã hoàn thành việc của nó. Một mục mà giao diện vào được đọc là Null, hoặc một bộ đếm gắn nhãn RPF failed tiếp tục tăng, chỉ ngược về phần trước đó chứ không phải đường hầm.

Nếu cả năm lệnh trông đúng mà máy thu vẫn không thấy gì, nghi phạm còn lại là chính sách của đường hầm: một ACL mã hóa hoặc một quy tắc tường lửa cho phép giao thức định tuyến unicast nhưng không cho PIM, IGMP hay chính lưu lượng nhóm. Trên đường hầm IPsec dựa trên chính sách, multicast hoàn toàn không được mang, nên câu trả lời là thiết kế GRE hoặc VTI chứ không phải một ngoại lệ bộ lọc nữa. Hãy ghi lại phép kiểm tra nào trong năm phép đã thất bại trước khi thay đổi bất cứ điều gì, rồi chỉ thay đổi lớp đó.