Phiên BGP đã lên nhưng đường của khách hàng bị đứt: MPLS trên DMVPN

Phiên peering đã lên từ nhiều tuần, số tiền tố trông có vẻ đúng, vậy mà lưu lượng của một khách hàng vẫn đi đường vòng hoặc không bao giờ đến nơi. Hai thứ khác nhau đang bị đánh giá bằng cùng một chỉ báo. Một phiên BGP báo rằng hai peer có thể trao đổi thông điệp qua kết nối TCP; nó không nói gì về việc lớp phủ có thể mang gói tin có nhãn cho đúng khách hàng đó hay không.

Khoảng trống đó dễ thấy nhất trong một thiết kế MPLS trên DMVPN, nơi đường qua hub và đường trực tiếp qua spoke có thể hành xử khác nhau vì những lý do không liên quan gì đến peering.

Phiên thực sự chứng minh điều gì

BGP chạy trên TCP, nên mỗi peer cần một tuyến đến địa chỉ đầu bên kia trước khi bất cứ điều gì khác xảy ra. Nếu chọn một loopback làm đầu đó, bạn đã tạo ra một yêu cầu về khả năng tiếp cận, không phải bảo đảm chuyển tiếp. Phiên sau đó có thể vẫn hoạt động qua một giao diện mà lưu lượng của khách hàng sẽ không bao giờ dùng.

Ghi lại bốn sự kiện ở cả hai đầu trước khi kết luận: địa chỉ nguồn của phiên, địa chỉ đích, ngữ cảnh định tuyến mà nó nằm trong đó, và giao diện nào mà nhân hệ điều hành hoặc router sẽ chọn cho cặp đó. Những sự kiện này mô tả mặt phẳng điều khiển. Các gói của khách hàng thêm vào bên trên một VRF, một ngăn xếp nhãn và một ánh xạ lớp phủ.

Bốn cơ chế, không phải một

Tài liệu của Cisco về MPLS trên DMVPN tách các thành phần một cách rõ ràng. MP-BGP phân phối nhãn lớp phủ của khách hàng giữa các thiết bị ở biên nhà cung cấp. MPLS dùng các nhãn đó để chọn ngữ cảnh chuyển tiếp cho một gói. NHRP ánh xạ một địa chỉ lớp phủ tới đầu vận chuyển mà một đường hầm động cần. IPsec bảo vệ đường peer ở nơi nó áp dụng.

Bất kỳ cơ chế nào trong bốn cũng có thể đúng trong khi cơ chế khác sai, và chính sự kết hợp mới mang lưu lượng. Trao đổi tuyến có thể hoàn tất trong khi thiếu ràng buộc nhãn cho một VRF, trong khi ánh xạ NHRP trỏ tới một địa chỉ vận chuyển cũ, hoặc trong khi đường hầm tồn tại nhưng không có chính sách nào cho phép gói bên trong. Không điều kiện nào trong số đó làm phiên sập.

So sánh đường qua hub với đường tắt, mỗi lần một biến

Cố định host nguồn, host đích và VRF, rồi theo cùng một luồng hai lần. Trên đường qua hub, ghi lại chặng kế tiếp, nhãn dịch vụ xác định ngữ cảnh khách hàng từ xa và ánh xạ lớp phủ sang vận chuyển đang dùng. Trên đường trực tiếp dự kiến, ghi lại đúng ba thứ đó. Khác biệt giữa hai danh sách chính là lỗi, hoặc sự vắng mặt của lỗi.

Giữ luồng không đổi trong khi so sánh. Thay đổi host nguồn, VRF hoặc đích giữa các lần quan sát tạo ra hai câu chuyện không liên quan, và đó là cách phổ biến nhất khiến bài tập này hỏng.

Giữ các bài kiểm tra loopback trong ngăn riêng

Ping xuất phát từ loopback của router là một bài kiểm tra hữu ích, và nó thử một trường hợp khác với luồng từ host. Địa chỉ nguồn thuộc về router, ngữ cảnh định tuyến của nó có thể là toàn cục thay vì VRF, và đường phản hồi có thể khác đường mà một tiền tố của khách hàng sẽ đi. Vì vậy loopback trả lời và ứng dụng chạy qua đường tắt là hai kết quả riêng, và chỉ kết quả thứ hai mới mô tả khách hàng.

Hãy thử cả hai, rồi ghi chú chúng riêng ra. Khi chúng không khớp nhau, bạn đã học được điều cụ thể về chỗ thiết kế lệch hướng, và điều đó nhiều hơn bất cứ dấu kiểm xanh đơn lẻ nào từng nói.

Các khẳng định về phiên bản và về lỗi cần bằng chứng riêng

Báo cáo hiện trường đôi khi khuyên đổi mặt nạ host hoặc địa chỉ nguồn BGP, và những báo cáo như vậy chỉ đáng đọc cùng với lỗi mà chúng viết về và các bản phát hành bị ảnh hưởng. Một cách vòng tránh từ một bản phát hành không phải là tuyên bố rằng kiến trúc không hỗ trợ bất kỳ tiền tố /32 nào.

Dùng tài liệu khớp với giai đoạn DMVPN, nền tảng và bản phát hành của bạn, và nhớ rằng một chương có thể bao quát nhiều cách bố trí, kể cả FlexVPN. Một ví dụ từ cách bố trí này không tự động chuyển sang cách khác. Chọn các đầu phiên theo thiết kế mặt phẳng điều khiển mà bạn thực sự cần, rồi kiểm tra riêng đường chuyển tiếp của khách hàng, vì viết lại mọi mặt nạ loopback không thay thế việc tìm ra công việc nào đã thất bại.