Nhãn theo VRF hay theo tiền tố? Hóa đơn dung lượng thật sự

Hai thiết kế quảng bá cùng một tiền tố khách hàng trong cùng một lõi nhà cung cấp. Một bên cấp một nhãn cho mỗi tiền tố, bên kia cấp một nhãn duy nhất cho toàn bộ VRF, và bên thứ hai trông rẻ hơn trên mọi trang trình bày. Số nhãn là thật, nhưng đó không phải là ngân sách thường cạn trước. Chọn giữa hai bên nghĩa là đếm bốn tài nguyên, không phải một, và nhãn là thứ nhỏ nhất trong số đó.

Lựa chọn cũng phụ thuộc vào việc bộ định tuyến đầu ra phải làm gì với gói sau khi bóc nhãn. Chính khác biệt chức năng đó, chứ không phải số học nhãn, mới nên dẫn dắt quyết định.

Mỗi cách cấp phát thực sự tiết kiệm điều gì

Cấp phát theo tiền tố mang thông tin chuyển tiếp trong nhãn. Bộ định tuyến đầu ra có thể gửi gói thẳng tới láng giềng đúng mà không cần tra cứu đích, đó là lý do nó mở rộng tốt cho các tập tuyến VRF lớn và là lý do nó tiêu một nhãn cho mỗi tiền tố được quảng bá trong mỗi VRF. Cấp phát theo VRF, như Junos vrf-table-label, quảng bá một nhãn cho mỗi phiên bản định tuyến và dùng nhãn đó để chọn bảng VRF; sau đó bộ định tuyến thực hiện tra cứu IP bên trong bảng.

Đó là khác biệt kiến trúc thật sự chứ không phải nút tinh chỉnh. Gắn nhãn theo VRF cho không gian nhãn nhỏ hơn và quảng bá nhãn đơn giản hơn, đổi lại là một lần tra cứu và một nhãn không nói gì về đích. Gắn nhãn theo tiền tố cho card đường đầu ra nhiều thông tin hơn ngay từ đầu và tiêu nhãn tỷ lệ với các tuyến bạn mang.

Sổ nhãn là cuốn nhỏ

Nhãn MPLS là hữu hạn, nhưng không gian nhãn đủ lớn để các nhà cung cấp dịch vụ thông thường không cạn kiệt nó với vài nghìn tiền tố. Nơi gắn nhãn theo VRF thực sự giúp ích là trên các nền tảng có bảng nhãn phần cứng nhỏ, hoặc trong các thiết kế mà một VRF mang toàn bộ nguồn cấp Internet và nhãn theo tiền tố sẽ nhân nhu cầu nhãn với số tuyến. Đây là những ràng buộc thật, và chúng là lý do tính năng này tồn tại. Không điều nào trong số đó nói về số tiền tố trong bảng.

Đếm nhãn cho cả dịch vụ và vận chuyển trước khi chọn. Thiết kế theo VRF vẫn cần nhãn vận chuyển cho loopback và cho từng bước trên đường, và vẫn cần trạng thái láng giềng. Nếu bản tóm tắt thiết kế chỉ đếm nhãn dịch vụ, khoản tiết kiệm đang được đo trên cuốn sổ sai.

Nguồn cấp tuyến tốn bộ nhớ trước nhãn

Mỗi đường nhận được đều tiêu bộ nhớ mặt phẳng điều khiển, xử lý cập nhật và thời gian hội tụ, dù VRF dùng một nhãn hay mười nghìn. Nguồn cấp Internet đầy đủ bên trong một VRF đắt vì các đường BGP, RIB, mục FIB và sự xáo trộn phía sau chúng, không phải vì nhãn đứng trước bảng. Cùng nguồn cấp đó cũng tăng bán kính ảnh hưởng của rò rỉ tuyến hoặc lỗi chính sách bên trong người thuê đó.

Vì vậy hãy hỏi khách hàng thực sự cần gì. Nếu hợp đồng là các site riêng cộng lối ra mặc định, một bảng đầy đủ thêm chi phí mà không thêm yêu cầu. Đó là câu hỏi thương mại, và nó xứng đáng có câu trả lời bằng văn bản thay vì một giả định thừa hưởng từ thiết kế trước. Nếu dịch vụ thực sự cần nguồn cấp cho chính sách hoặc cho việc chọn lối ra cục bộ, hãy biến nó thành một dòng rõ ràng với phần dự trữ dung lượng riêng và hành vi khi lỗi riêng.

Khi nào gắn nhãn theo VRF là mặc định đúng

Đó là mặc định tốt khi nền tảng ghi nhận nó được hỗ trợ, khi số tuyến VRF lớn và khi chi phí tra cứu ở đầu ra chấp nhận được với hồ sơ lưu lượng. Đây cũng là lựa chọn tự nhiên khi sự đơn giản vận hành quan trọng hơn việc vắt kiệt microsecond cuối cùng khỏi chuyển tiếp, vì một nhãn cho mỗi người thuê dễ giải thích và kiểm toán hơn một nhãn cho mỗi tiền tố.

Đó là mặc định sai khi tài liệu của nền tảng gắn tính năng với các ràng buộc phần cứng hoặc bản phát hành cụ thể, hoặc khi thiết kế phụ thuộc vào các quyết định chuyển tiếp theo tiền tố ở đầu ra. Hãy đọc tham chiếu statement của chính nền tảng trước khi giả định hành vi; lệnh Junos được ghi lại, nhưng chính các giới hạn phần cứng và bản phát hành xung quanh nó mới thực sự quyết định việc triển khai.

Một ngân sách bạn có thể bảo vệ

Xây dựng hồ sơ dung lượng thành năm con số riêng biệt: đường nhận được, tuyến được chọn, mục chuyển tiếp đã cài đặt, nhãn dịch vụ và nhãn vận chuyển. Thêm trạng thái next-hop và láng giềng, số người thuê và mô hình dự phòng. Ảnh chụp đường đi thuận lợi của một VRF không phải là con số quy mô, và kích thước danh nghĩa của không gian nhãn không phải là bảng phần cứng sẵn có.

Sau đó thống nhất cả chế độ lỗi, không chỉ trạng thái ổn định. Điều gì xảy ra khi nguồn cấp tăng một nửa, khi người thuê thêm VRF thứ hai, hoặc khi nền tảng cần khởi động lại để đổi kích thước bảng? Một ngân sách chịu được những câu hỏi đó đáng giá hơn số nhãn chỉ hoạt động trên giấy.

Chọn cách cấp phát dựa trên hành động ở đầu ra và giới hạn của nền tảng, rồi biến nguồn cấp tuyến thành quyết định dịch vụ rõ ràng. Nhãn là phần hữu hình của thiết kế; tuyến là phần phải trả tiền mỗi ngày.