Vì sao MAC của QFX xuất hiện trong EVPN nhưng không có trong bảng chuyển tiếp

Việc tìm thấy MAC trong cơ sở dữ liệu EVPN chứng minh rằng nó đã được quảng bá hoặc nhận như một tuyến, và không hơn thế. Bảng chuyển tiếp là một cấu trúc khác, được lập trình sau đó, nên cùng một MAC có thể xuất hiện ở bảng này và thiếu ở bảng kia trong khi mọi giao thức vẫn hoạt động đúng. Coi hai đầu ra đó là bản sao của nhau khiến các kỹ sư đi tìm lỗi BGP trong khi khoảng trống thật là chính sách nhập khẩu hoặc chặng kế tiếp chưa được giải quyết. Câu hỏi đáng đặt ra không phải là fabric có biết MAC hay không, mà là giai đoạn nào đã ngừng chuyển tiếp nó.

Hai bảng trả lời hai câu hỏi khác nhau

Trên Junos EVPN cơ sở dữ liệu liệt kê địa chỉ MAC theo từng instance cùng với cách mỗi địa chỉ đến: học từ cổng truy cập, nhận trong tuyến Type 2, hoặc được đánh dấu là một phần của nhóm multihoming. Tài liệu tham chiếu của Juniper show evpn database bao gồm các bộ lọc theo MAC và theo instance giúp chế độ xem dễ đọc. Đây là bản tóm tắt mặt phẳng điều khiển có khóa là instance và MAC, không phải bảng mà phần cứng dùng để chuyển frame.

Bảng chuyển mạch chính là trạng thái chuyển tiếp đó. Cả hai đầu ra đều liệt kê MAC bên cạnh ngữ cảnh VLAN hoặc VNI, đó chính là lý do chúng được so sánh từng dòng, và cũng chính là lý do phép so sánh gây hiểu nhầm. Mục trong cơ sở dữ liệu cho biết tuyến tồn tại và đã được chấp nhận vào instance; nó không nói gì về việc nền tảng đã cài đặt nó cho chuyển tiếp hay chưa.

Tuyến Type 2 mang MAC, IP tùy chọn, nhãn hoặc VNI, bộ phân biệt tuyến và chặng kế tiếp nêu tên VTEP từ xa. Bốn thứ có thể hỏng giữa cáp và tuyến đó: máy chủ không bao giờ được học, tuyến không bao giờ được quảng bá, nó bị từ chối khi nhập khẩu, hoặc chặng kế tiếp của nó không phân giải được. Mỗi thất bại để lại một bộ bảng khác nhau đã được điền, và đó là lý do chuỗi này có thể được chẩn đoán.

Học cục bộ vẫn diễn ra trước

Giả định phổ biến là EVPN tiếp quản việc học MAC, nên cơ sở dữ liệu trống phải có nghĩa là sự cố overlay. Việc học cục bộ vẫn chạy ở phía truy cập, đúng như trước khi có VXLAN: switch học MAC nguồn của frame được phép trong VLAN và dịch vụ đúng, rồi sau đó mới tạo Type 2 cho nó. Máy chủ không gửi frame nào liên quan thì không có gì để quảng bá. Máy chủ có frame bị loại bỏ do tư cách thành viên VLAN, bộ lọc hoặc một thành viên down của tổng hợp trông giống hệt nhau từ góc nhìn overlay.

Bắt đầu tại điểm gắn kết và tiến về phía trước bằng các lệnh chỉ đọc. Mục tiêu là chứng minh rằng một frame từ máy chủ đã đi qua dịch vụ dự định, vì không có gì ở hạ nguồn bù đắp cho một frame không bao giờ đến.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Các thành viên LACP được chọn quan trọng hơn việc gói đang hoạt động, vì một tổng hợp có thể hoạt động trên một thành viên trong khi lưu lượng của máy chủ được băm sang một liên kết bị down hoặc bị chặn. Bộ đếm giao diện phân biệt máy chủ im lặng với máy chủ đang rớt frame, vì máy chủ không bao giờ truyền và máy chủ có frame bị loại bỏ do phân loại đều để lại cùng một bảng trống.

MAC từ xa mất ở đâu

MAC từ xa thất bại theo hướng ngược lại, và một cách âm thầm. Tuyến Type 2 đến, nhưng nó chỉ vào một instance khi đích tuyến và VNI khớp với cấu hình cục bộ, và chỉ trở nên dùng được khi chặng kế tiếp phân giải thành một VTEP có thể đến được. Sự không khớp của đích tuyến để lại một tuyến hợp lệ trong bảng BGP mà không instance nào yêu cầu.

Đọc ba chế độ xem theo thứ tự: sự tồn tại của tuyến, mục trong cơ sở dữ liệu, mục chuyển tiếp. Các lệnh bên dưới hỏi cùng một MAC ở mỗi giai đoạn, và địa chỉ mẫu giữ các đầu ra có thể so sánh được.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Những đầu ra đó trả lời ba câu hỏi riêng biệt. Một tuyến trong bgp.evpn.0 không có mục trong cơ sở dữ liệu chỉ vào chính sách nhập khẩu, đích tuyến hoặc cấu hình instance. Một mục trong cơ sở dữ liệu không có mục chuyển tiếp chỉ vào việc lập trình nền tảng, thuộc một đường leo thang khác. Một tuyến đang hoạt động mà chặng kế tiếp không phân giải được là vấn đề vận chuyển hoặc nhãn, và không lượng gỡ lỗi MAC nào sửa được nó.

Một lần khởi động lại đã sửa được nó chứng minh rất ít

Khi việc khởi động lại khiến triệu chứng biến mất, kết luận hấp dẫn là cấu hình phải lành mạnh. Khởi động lại lập trình lại mọi bảng từ đầu, nên nó cũng che giấu trường hợp một mục cũ đang che khuất lỗi chính sách; sự cố thường quay lại ở thay đổi tiếp theo, nhấp nháy liên kết hoặc rút tuyến.

Trước mọi cửa sổ bảo trì, hãy ghi lại những gì việc khởi động lại sẽ xóa. Ba lệnh này đủ để so sánh trước và sau, và chúng không thay đổi gì trên thiết bị.

show evpn database instance blue
show route table bgp.evpn.0
show version

Lưu trữ những đầu ra đó cùng ngày và bản dựng phần mềm bên cạnh. Một báo cáo sau này rằng cùng lần khởi động lại đã từng hiệu quả là manh mối chứ không phải bằng chứng, và sự khác biệt chỉ hiện ra khi có người giữ lại đầu ra trước đó.

Bốn quan sát giải quyết hầu hết các trường hợp

Bốn quan sát bao quát gần như mọi trường hợp: điểm gắn kết và dịch vụ của nó, MAC như một giá trị mẫu, trạng thái của tuyến và cơ sở dữ liệu, và bản dựng đang dùng. Chọn một MAC rõ ràng là mẫu để không ai nhầm nó với địa chỉ sản xuất: octet đầu tiên 02 đánh dấu một địa chỉ unicast được quản lý cục bộ, các octet còn lại tự do, và do đó 02:00:00:00:00:5c là một chỗ giữ chỗ an toàn.

Sau đó để các câu trả lời chỉ ra giai đoạn đã thất bại. Không có học tại điểm gắn kết nghĩa là phía truy cập; một tuyến không có mục trong cơ sở dữ liệu nghĩa là nhập khẩu; một mục trong cơ sở dữ liệu không có trạng thái chuyển tiếp nghĩa là lập trình. Dù là gì, hãy bàn giao các đầu ra đã thu thập cùng với máy chủ, giao diện, dịch vụ và bản dựng, để kỹ sư tiếp theo có thể tái tạo đường đi thay vì lặp lại truy vấn.