Bond chủ động-dự phòng của Linux trên EVPN all-active: điều gì vỡ

Đặt một bond chủ động-dự phòng trên máy chủ và một segment Ethernet all-active trên fabric, và một nửa lưu lượng trả về có thể biến mất mà không một bộ đếm lỗi nào nhích lên. Không cấu hình nào sai tự thân. Vấn đề nằm ở việc bàn giao giữa hai bên, khi một phía chọn một cổng duy nhất còn phía kia giả định mọi lá được gắn đều giao được. Theo dõi một khung ở mỗi hướng và sự lệch pha trở nên rõ ràng.

Chế độ chủ động-dự phòng làm gì với một khung đi vào

Chế độ bonding 1 giữ đúng một slave trên đường truyền và chỉ đổi khi slave hiện tại hỏng. Phần đó ai cũng biết. Điều quan trọng ở đây là phía nhận: nhân chỉ đưa khung lên ngăn xếp nếu khung đến trên slave đang hoạt động, và bỏ các khung xuất hiện trên bất kỳ slave khác. Cấu hình all_slaves_active này tồn tại chính là để nới lỏng quy tắc đó, và mặc định nó đang tắt. ip -d link show bond0 in ra giá trị hiện tại bên cạnh chế độ.

/proc/net/bonding/bond0 nêu tên slave đang hoạt động và báo trạng thái liên kết của từng slave. Tệp đó là nguồn trung thực duy nhất cho biết cổng nào đang mang lưu lượng.

Một máy chủ ở chế độ này có một đường nhận dùng được tại một thời điểm, được chọn cục bộ mà không biết gì về fabric. Nếu một khung cho máy chủ đó đến trên cáp kia, cổng switch đếm nó là đã nhận, ngăn xếp của máy chủ không bao giờ thấy, và mọi bộ đếm trừ bộ đếm bỏ của chính máy chủ đều trông hoàn toàn khỏe mạnh.

Multihoming all-active làm gì với next hop ở xa

Multihoming EVPN mô tả một tập lá chia sẻ một segment Ethernet, được nhận diện bằng ESI, và quảng bá segment đó cho phần còn lại của fabric. Trong mô hình all-active, các peer ở xa cài nhiều hơn một next hop cho địa chỉ của segment. Unicast về phía máy chủ khi đó có thể đến bất kỳ lá nào, và fabric được tự do chọn theo luồng. Đó là toàn bộ mục đích của thiết kế, và cũng là giả định mà bond của máy chủ phải đáp ứng.

Lưu lượng bị tràn theo một quy tắc khác. Các lá bầu một forwarder được chỉ định cho mỗi segment, nên broadcast, unicast không xác định và multicast thường vào qua một trong số đó. Vì vậy unicast và tràn đưa ra hai quyết định riêng, và chỉ một trong hai xuất hiện trong trạng thái bond của máy chủ.

Nơi hai lựa chọn không đồng ý

Nhân chọn slave hoạt động từ trạng thái liên kết và chính sách của mình. Fabric chọn next hop từ các tuyến EVPN, và forwarder được chỉ định từ một cuộc bầu chọn giữa các lá. Không tiến trình nào hỏi ý tiến trình kia. Khi chúng chọn lá khác nhau, hỏng hóc phụ thuộc hướng: thứ máy chủ gửi đi ra bình thường, còn các phản hồi biến mất.

Có hai lối ra được hỗ trợ, và chúng không thay thế được cho nhau. Cho máy chủ một bond mà fabric có thể coi là một kết nối logic duy nhất, thực tế nghĩa là một bond LACP đã thương lượng với các lá, và cả hai liên kết thực sự hoạt động cùng nhau. Hoặc chấp nhận cả việc giao single-active từ fabric, để segment đi theo cùng mô hình một cổng tại một thời điểm như bond. Điều không chạy được là một segment all-active đặt trước một bond chỉ nghe trên một cổng, trừ khi bạn cố ý bật nhận trên các slave không hoạt động và chấp nhận việc giao kép kéo theo.

Vì sao cáp dự phòng mãi trông khỏe

Một cáp không mang lưu lượng vẫn báo liên kết lên, và một slave chờ trong bond được thiết kế để trông sẵn sàng. Người vận hành đọc đó là dự phòng và thôi đặt câu hỏi.

Thay vào đó hãy hỏi khung trả về đã dùng cổng vật lý nào. Trên máy chủ, hãy đếm gói nhận theo từng slave chứ không theo bond, vì bộ đếm bond che mất sự bất đối xứng. Trên lá, hãy xem các mục chuyển tiếp của cầu cho MAC của máy chủ và tập next hop mà tuyến EVPN mang theo. Nếu mục đó trỏ tới lá có liên kết máy chủ là dự phòng, thiết kế đang giao vào một cổng mà máy chủ bỏ qua. Đây là lệch cấu hình chứ không phải hỏng phần cứng, và không mức giám sát trạng thái liên kết nào làm nó lộ ra.

Kiểm thử việc giao theo cả hai hướng, không phải trạng thái liên kết

Dựng một ma trận với một hàng cho mỗi hỏng hóc và một cột cho mỗi hướng, rồi điền lưu lượng đã giao thay vì trạng thái giao diện. Hàng đầu là vận hành bình thường, và đó chính là nơi sự lệch pha ẩn náu, vì triệu chứng trông như một vấn đề ứng dụng.

Sau đó gỡ liên kết máy chủ đang hoạt động, gỡ một lá, gỡ các uplink của lá đó, và khôi phục từng thứ theo thứ tự. Sau mỗi bước, ghi lại slave hoạt động, trạng thái segment EVPN, mục chuyển tiếp ở xa và thông lượng quan sát được theo cả hai hướng. Một lá mất đường tới fabric trong khi liên kết máy chủ vẫn lên là trường hợp thú vị, vì kết nối vẫn được quảng bá và có thể lặng lẽ thành ngõ cụt. Kiểm thử với luồng unicast mới và với lưu lượng tràn mà ứng dụng phụ thuộc, vì hai bên dùng quyết định chuyển tiếp khác nhau.

Chỉ chấp nhận thiết kế khi ma trận cho thấy việc giao hai chiều qua đúng đường bạn định. Hai sợi cáp có liên kết lên không phải kết quả đó.