AFI và SAFI: đọc cặp số trước tên dịch vụ

Bạn có thể thấy một phiên đi lên, thấy một tuyến xuất hiện và vẫn đang đọc sai dịch vụ. Cặp số ở đầu mỗi thông báo, định danh họ địa chỉ và định danh họ địa chỉ kế tiếp, quyết định bộ phân tích nào đọc phần tải và bảng nào giữ kết quả. Nhầm cặp số thì chính sách nhập, việc khớp mục tiêu tuyến và tìm bước nhảy kế tiếp đều chạy trên một cấu trúc mà không ai công bố. Hành trình dưới đây bắt đầu từ cặp số đó và kết thúc ở kết quả chuyển tiếp.

Hai con số quyết định tuyến thuộc bảng nào

Cặp số xuất hiện hai lần: bên trong năng lực đa giao thức, nơi một bên nói công bố một họ, và trước mọi NLRI mà họ đó mang theo. Điều này khiến nó là thuộc tính của tuyến chứ không phải thiết lập trên hộp nguồn. Các hãng in nó thành tên như Address family VPNv4 Unicast, và cách diễn đạt thay đổi giữa các bản phát hành trong khi con số giữ nguyên.

Bốn cách mã hoá bao gồm gần như mọi trường hợp doanh nghiệp: 1 với 128 cho VPN-IPv4 gắn nhãn MPLS, 2 với 128 cho tương đương IPv6, 25 với 65 cho VPLS được báo hiệu bằng BGP và 25 với 70 cho EVPN. Lỗi đầu tiên là cho rằng mọi dịch vụ Layer 2 nằm sau 25 với 65, điều này che mất EVPN. Lỗi thứ hai là coi hai họ IP là một họ với địa chỉ dài hơn, trong khi chúng được thương lượng riêng và có thể được chấp nhận trên các đối tác khác nhau. Lỗi thứ ba xuất hiện khi một mẫu được sao chép từ bản phát hành chỉ biết một trong hai. Tra cứu trong sổ đăng ký giải quyết cả ba nhanh hơn phỏng đoán dựa trên tên dịch vụ.

Coi bốn dòng là ví dụ từ sổ đăng ký IANA, không phải chính sổ đăng ký. Khi một con số không khớp với bất cứ điều gì đã biết, hãy tra nó trước khi dựng chính sách quanh nó.

AFI 25 mang hai định dạng NLRI không liên quan

Cả hai họ Layer 2 đều nằm dưới AFI 25, và sự giống nhau dừng ở đó. NLRI của VPLS trong RFC 4761 section 3.2.2 mang độ dài, bộ phân biệt tuyến, VE ID, độ lệch khối VE, kích thước khối VE và cơ sở nhãn, những thứ này cùng nhau đặt tên cho một điểm cuối pseudowire và nhãn của nó. EVPN giữ AFI 25 và chuyển sang SAFI 70, nơi phần tải là một kiểu tuyến: tự động khám phá Ethernet, thông báo MAC/IP, multicast bao gồm, đoạn Ethernet, tiền tố IP. Vì vậy cùng một độ lệch byte mang nghĩa khác nhau trong hai họ. Bộ phân tích viết cho họ này đọc họ kia mà không phàn nàn và tạo ra điều vô nghĩa. Cặp số là cảnh báo duy nhất rằng cách diễn giải sai.

Trường mang nghĩa độ lệch khối VE trong họ này không có tương đương ở họ kia, và tuyến thông báo MAC/IP chỉ tồn tại trong EVPN. Trích dẫn một thuộc tính như thể nó áp dụng cho cả hai chính là cách một buổi soát bắt gói đi sai.

Khi ai đó đưa bạn một bản bắt gói hoặc bảng của hãng, hãy hỏi thuộc tính thuộc họ nào. Sau đó xác nhận rằng bản triển khai nhận hỗ trợ họ đó, không phải tên dịch vụ trên tờ dữ liệu. Hai nền tảng có thể cùng tuyên bố hỗ trợ VPLS trong khi triển khai các họ báo hiệu khác nhau. Cặp số phân biệt chúng; nhãn sản phẩm thì không.

Họ địa chỉ của chính phiên là câu hỏi riêng

VPN-IPv6 thường được công bố qua một phiên có kết nối TCP chạy trên IPv4, và đó là thiết kế được hỗ trợ, không phải lỗi. Vì vậy chỉ đọc bản tóm tắt phiên thì không nói gì về việc các đối tác trao đổi những họ VPN nào.

Họ NLRI, họ vận chuyển và họ chuyển tiếp là ba quyết định độc lập. Một router có thể nói IPv4 với đối tác, chấp nhận khả năng tiếp cận VPN-IPv6 và cài một tuyến có bước nhảy kế tiếp là địa chỉ IPv6 tiếp cận được qua một đường bạn không định trước. Mỗi lớp cần xác nhận riêng. Những trang báo đích IPv6 không tiếp cận được trong khi thông báo trông đúng thường đã mất phân giải bước nhảy kế tiếp, không phải mất thương lượng họ.

Hãy thử họ địa chỉ của phiên riêng, rồi các họ mà nó mang, rồi những gì lõi có thể chuyển tiếp. Giữ ba thứ tách rời ngăn chẩn đoán sai phổ biến trong đó một thông báo đúng bị đọc thành bằng chứng IPv6 chạy từ đầu đến cuối. Nó chỉ chứng minh một đối tác đã nói với đối tác kia về một tiền tố.

Đã thương lượng, đã nhận, đã nhập, đã cài

Với một tuyến mong đợi, bốn trạng thái phải đúng theo thứ tự, và mỗi trạng thái quan sát được. Họ phải được thương lượng với đối tác đó, tuyến phải đến, một mục tiêu tuyến phải nhập nó vào ngữ cảnh dự định và bước nhảy kế tiếp phải phân giải để tuyến được cài. Bỏ qua trạng thái đầu khiến ba trạng thái còn lại không trả lời được, vì một họ chưa thương lượng không sinh ra tuyến để kiểm tra. Trên nền tảng kiểu Cisco, bản tóm tắt họ và năng lực theo từng đối tác là các lệnh riêng.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

Thương lượng hiện ra trong việc trao đổi năng lực được in theo từng đối tác, và một phiên đã thiết lập mà không liệt kê họ nào không mang gì trong những gì bạn yêu cầu. Việc nhập do các mục tiêu tuyến mang dưới dạng cộng đồng mở rộng quyết định, nên một cặp đúng với mục tiêu gõ sai để bảng trống. Việc cài sau đó phụ thuộc vào phân giải bước nhảy kế tiếp trong ngữ cảnh nhận, điều có thể thất bại trong khi mọi thông báo trông hoàn hảo.

Xác nhận mặt phẳng dữ liệu sau cùng, vì một tuyến trong bảng là lời khẳng định, không phải sự giao hàng. Bốn trạng thái như nhau áp dụng cho mọi họ; chỉ lệnh và tên bảng thay đổi.

Điều mà một cặp họ không bao giờ chứng minh

Đọc cặp đúng cho bạn biết cách diễn giải thông tin định tuyến theo sau, và đó là toàn bộ lời khẳng định. Nó không nói gì về khả năng tiếp cận, về chính sách hay về sức khoẻ mặt phẳng dữ liệu. Lẫn hai điều đó tạo ra những phát biểu tự tin về một mạng mà không ai kiểm chứng. Lệch mục tiêu tuyến và bước nhảy kế tiếp hỏng trông giống nhau chỉ từ cặp số. Cặp số là chỉ dẫn đọc, không bao giờ là phán quyết.

Khi bạn nâng cấp sự cố, hãy đặt cặp số, mục tiêu tuyến và bước nhảy kế tiếp đã phân giải vào cùng một ghi chú. Khi đó kỹ sư tiếp theo có ba thứ độc lập để thử thay vì một tên dịch vụ để diễn giải lại. Nếu thiếu thương lượng họ thấy ngay, mục tiêu sai để việc nhập vắng mặt rõ ràng, và bước nhảy kế tiếp chưa phân giải để tuyến hiện diện nhưng không dùng được.