Cùng một /24 cho hai khách hàng? VPNv4 cần RD và nhãn

Hai bên thuê đánh số chi nhánh của mình bằng cùng 10.50.0.0/24, và sau một thay đổi tuyến của một bên biến mất khỏi biên của nhà cung cấp trong khi bên kia vẫn hoạt động. Cách đơn giản hóa đằng sau phiếu đó thường là bỏ bộ phân biệt tuyến (RD) vì „nhãn đã nhận diện khách hàng“. Không phải vậy. RD và nhãn trả lời hai câu hỏi khác nhau, và khoảng cách chỉ lộ ra khi các địa chỉ chồng lấn buộc phải thế.

Một tuyến ở nơi lẽ ra phải có hai

IPv4 unicast thông thường so sánh hai đường tới cùng một tiền tố và cài đặt đường tốt hơn. 10.50.0.0/24 từ bên thuê A và 10.50.0.0/24 từ bên thuê B là một khóa, nên một đường thắng và đường kia chỉ tồn tại như đường dự phòng. Giao thức làm đúng như được bảo; mặt phẳng điều khiển được yêu cầu lưu hai tuyến khác nhau dưới một định danh.

Kết quả trông như một tuyến bị thiếu chứ không phải lỗi: PE thua cuộc vẫn chuyển tiếp bên thuê của mình cục bộ, nên kiểm tra trong nội bộ site thành công còn kiểm tra giữa các site thất bại. Hãy đếm các mục cho tiền tố đó trong bảng VPNv4 trước khi chạm vào bất kỳ chính sách nào.

RD biến một khóa thành hai

Một bộ phân biệt tuyến dài tám byte được đặt trước tiền tố IPv4, và đối tượng mà BGP mang theo trở thành địa chỉ VPN-IPv4 thay vì tiền tố IPv4. Hai bên thuê có thể giữ cùng 32 bit vì 64 bit phía trước khác nhau. Có các kiểu định dạng cho RD dựa trên AS và cho RD dựa trên địa chỉ, và việc chọn thuộc về PE gốc. RD dựa trên AS là phổ biến khi các PE chia sẻ một AS, còn loại dựa trên địa chỉ khi họ không chia sẻ.

Đừng đọc RD như một thẻ thành viên. Các đích tuyến chi phối nhập và xuất và quyết định VRF nào được cài đặt tuyến; RD chỉ bảo đảm tuyến có danh tính riêng. Gán cho mỗi VRF một RD riêng là thực hành phổ biến vì nó giữ ánh xạ đó dễ đọc trong trình xem tuyến.

Nhãn là một chỉ thị chuyển tiếp cục bộ

Mỗi quảng bá cũng mang một nhãn MPLS, và ý nghĩa của nó chỉ giới hạn ở router đã cấp phát nhãn đó. Một PE khác có thể phát cùng con số cho một đích không liên quan. Chính vì thế nhãn không thể thay thế danh tính khách hàng: con số chỉ đúng bên cạnh bước nhảy tiếp theo và trạng thái chuyển tiếp đã cài đặt nó.

Độ chi tiết của việc cấp phát thay đổi theo cách triển khai và thiết kế: một số nền tảng cấp một nhãn cho mỗi VRF, số khác cho mỗi tiền tố, và nhãn có thể nhận diện một hành động chuyển tiếp thay vì một khách hàng. Hai nhãn khác nhau cùng đến một đích không phải mâu thuẫn, và cùng một số nhãn trên hai PE cũng không.

Vì sao cái này không thể thay thế cái kia

Đọc một quảng bá nghĩa là nhìn bốn thứ cùng lúc: tiền tố được RD định chuẩn, các đích tuyến, bước nhảy tiếp theo và nhãn. Đọc một gói của người dùng nghĩa là nhìn ngăn xếp được cài từ thông tin đó. Một thiết kế lành mạnh cho thấy hai phía khớp nhau, còn thiết kế hỏng thường có một phía đúng và phía kia lỗi thời. Sự so sánh đó tách vấn đề danh tính khỏi vấn đề chuyển tiếp.

Sự tương phản gọn gàng giữa mặt phẳng điều khiển và mặt phẳng dữ liệu là một công cụ giảng dạy, không phải mô tả của việc mã hóa. RFC 8277 đặt nhãn vào bên trong NLRI được gắn nhãn, nên bản thân quảng bá mang theo ràng buộc; dùng nó để chuyển tiếp là bước sau, tách biệt.

Khi thiếu tuyến của một bên thuê, hãy kiểm tra theo thứ tự này: hai mục VPNv4 cho tiền tố, đích tuyến đúng trên mỗi mục, một bước nhảy tiếp theo phân giải được, và một nhãn mà PE nhận có trạng thái cho nó. Sửa danh tính bằng một giá trị chuyển tiếp, hoặc ngược lại, sẽ qua một kiểm tra và hỏng ở kiểm tra kế tiếp.