Host EVPN im lặng không bao giờ được phân giải: theo ARP đến liên kết

Điểm cuối đã được gắn, cổng của nó đang hoạt động, vậy mà host giám sát vẫn không thể chạm tới nó. Ai đó chạy ping từ phía bên kia và nó bắt đầu hoạt động, khiến sự cố trông có vẻ ngắt quãng và fabric trông có vẻ vô can. Mẫu đó chính là dấu hiệu của một host im lặng: nó hiếm khi truyền, nên hành vi khám phá và làm mới của fabric quan trọng hơn trạng thái kết nối của nó. Hãy bắt đầu với một IP, MAC và bridge domain dự định rồi theo dõi lần trao đổi phân giải tiếp theo.

Theo dõi lần trao đổi ARP hoặc ND tiếp theo

Với IPv4, hãy quan sát trao đổi ARP của host yêu cầu; với IPv6, theo dõi Neighbor Solicitation và Advertisement. Xác nhận rằng yêu cầu đi vào segment cục bộ dự định và VNI dự định, vì một yêu cầu không bao giờ đến được bridge domain đúng thì không proxy nào có thể trả lời.

Sau đó xem fabric biết gì về đích. Một tuyến chỉ có MAC có thể xác định đích Layer 2 trong khi proxy vẫn chưa có liên kết IP-to-MAC cho nó. Đây là những bản ghi riêng biệt, và kiểm tra cái này không nói gì về cái kia.

Nếu có một liên kết hợp lệ, proxy có thể trả lời theo chính sách của nó, nhưng MAC trong liên kết đó vẫn cần một đường chuyển tiếp đang hoạt động. Nếu liên kết không có, yêu cầu phải đến được kết nối của điểm cuối qua đường flooding hoặc sao chép trước khi bất cứ thứ gì có thể học từ câu trả lời.

Hai bản ghi phải khớp nhau

Tuyến MAC trả lời địa chỉ Ethernet sống ở đâu. Bảng proxy trả lời IP nào ánh xạ tới MAC nào. Một host không nói gần đây có thể có tuyến MAC hoàn toàn tốt và không có mục proxy nào dùng được, và đó chính là trạng thái tạo ra lỗi phân giải trên một kết nối khỏe mạnh.

Tại kết nối từ xa, hãy kiểm tra xem điểm cuối có thực sự nhận và trả lời trao đổi hay không. Câu trả lời của nó làm mới quá trình học cục bộ và quảng bá EVPN tương ứng, đó là lý do ping thủ công có vẻ sửa được mọi thứ: bạn đã tạo ra lưu lượng mà fabric đang chờ. Điều đó cũng giải thích vì sao bản sửa không bền: khi mục đã làm mới hết hạn, điểm cuối lại im lặng. Một ping theo lịch chỉ trị triệu chứng và che giấu lỗ hổng thiết kế.

Sau câu trả lời, theo tuyến đã chọn và trạng thái chuyển tiếp đã cài đặt ngược về phía bên yêu cầu. Phân giải thành công và chuyển tiếp thành công là hai sự kiện riêng biệt, và một ticket gộp chúng lại sẽ đưa bạn đến sai lớp.

Tiêu chuẩn thực sự giả định điều gì

RFC 9161 mô tả việc học proxy động và flooding mặc định của các yêu cầu ARP và ND không xác định. Việc chặn hoàn toàn flooding đó chỉ giới hạn ở những triển khai mà các giả định về học hoặc cung cấp khiến nó an toàn, đây là điều kiện hẹp hơn nhiều hướng dẫn cấu hình ngụ ý.

Một fabric mong đợi các điểm cuối mới được phát hiện cần một đường hoạt động cho những yêu cầu đó. Nếu ai đó đã tắt flooding yêu cầu không xác định để giảm lưu lượng BUM, thì những host im lặng chính là nhóm phải trả giá, và triệu chứng đến vài tuần sau dưới dạng khiếu nại về khả năng kết nối ngắt quãng.

Hãy đọc thiết lập chặn như một tuyên bố về điều fabric hứa sẽ biết. Nếu không có gì cung cấp các liên kết, lời hứa không đúng với những bên gửi hiếm khi. So sánh mức chặn đã cấu hình với hệ thống cung cấp lẽ ra phải nuôi nó. Khi hai thứ đó không khớp, fabric đang hành xử đúng như đã cấu hình, và kỳ vọng mới là thứ cần sửa.

Làm mới, lão hóa và phương án tĩnh

Tiêu chuẩn mô tả các phép thử làm mới được hỗ trợ trước khi các mục động lão hóa. Câu trả lời làm mới trạng thái bridge và proxy liên quan; việc không có câu trả lời có thể dẫn đến việc xóa và thu hồi tuyến một cách hợp lệ. Đây không phải là lỗi cần bị chặn bằng cách kéo dài mọi bộ định thời.

Kéo dài vô hạn các bộ định thời lão hóa sẽ đổi một lỗi nhìn thấy được lấy một lỗi cũ: fabric tiếp tục quảng bá một vị trí mà host đã rời đi. Hãy dùng các điều khiển có tài liệu của bản triển khai và chọn thời gian sống khớp với tần suất có thể kỳ vọng hợp lý rằng điểm cuối sẽ nói.

Với các điểm cuối đã biết và được quản lý, một liên kết tĩnh hoặc do bộ điều khiển cung cấp là mô hình thứ hai hợp lệ. Nó cần một chủ sở hữu xử lý việc thay thế và di chuyển, vì bản ghi được cung cấp không tự cập nhật khi host chuyển sang cổng khác.

Cần ghi lại gì trước ticket tiếp theo

Giữ nguồn của liên kết, thời điểm làm mới gần nhất, vị trí hiện tại và mọi sự kiện thu hồi bên cạnh tuyến MAC. Bản ghi đó trả lời câu hỏi mà ticket thực sự đặt ra: ứng dụng đang chờ khám phá, dựa vào trạng thái cũ, hay không chuyển tiếp được sau khi phân giải thành công?

Sau đó quyết định bạn sẵn sàng vận hành mô hình nào trong ba mô hình. Khám phá kèm flooding, làm mới với thời gian sống thực tế, hoặc cung cấp có chủ sở hữu đều có thể bảo vệ được. Một fabric được cấu hình cho một mô hình nhưng lại bị kỳ vọng hành xử như mô hình khác chính là nơi những host im lặng biến mất.