Mất khoảng 15% gói tin qua SFP+ đồng S+RJ10 trên CRS518-16XS-2XQ trong khi đường 100G trực tiếp sạch sẽ
Tôi đẩy traffic từ một server trong lab vào CRS518-16XS-2XQ qua uplink 100G QSFP28, rồi nó rời switch qua một SFP+ đồng MikroTik S+RJ10 để tới một host 1G RJ45 bình thường. Phía nhận thiếu mất một phần lớn gói tin và tôi không quy được cho cái gì rõ ràng cả.
Setup:
- MikroTik CRS518-16XS-2XQ, uplink 100G QSFP28 từ nguồn traffic
- SFP+ đồng MikroTik S+RJ10 trong một cage, thiết bị 1G RJ45 ở đầu xa
- capture chạy trên host nhận
Capture cho thấy:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Đã thử:
- nối cùng nguồn đó trực tiếp ở 100G, không mất gói nào cả, nên bản thân sender ổn
- hạ CPU switch xuống, giờ nó nằm ở 1% mà việc mất gói vẫn xảy ra
- tháo lắp lại S+RJ10 và đổi dây patch sang thiết bị 1G
Module đồng là nghi phạm chính của tôi lúc này, nhưng link sạch và interface không hiện lỗi nào cả. S+RJ10 có tiếng là ăn traffic kiểu này không, hay tôi nên tìm ở chỗ khác trong switch?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Trung bình 400-500 Mbps với một sender bắn burst chính là toàn bộ câu chuyện. Traffic của bạn không trải đều: các burst ngắn rời nguồn nhanh hơn 1 Gbps, và mọi thứ vượt qua ngưỡng đó phải nằm trong egress buffer của port cho tới khi phía 1G rút bớt đi. Khi buffer đầy, switch drop. Đó chính xác là điều rx-overflow đang tăng lên nói với bạn, và đó là lý do kết nối 100G trực tiếp không cho thấy gì cả - ở đó không có bước xuống tốc độ nào để phải buffer chống lại.
Transceiver vô tội. Bất cứ thứ gì trong cage đó, đồng hay quang, cũng sẽ hành xử y như vậy, vì việc drop xảy ra ở bước xuống từ 100G về 1G chứ không phải bên trong module.
Có hai việc cần làm. Cách sửa thật sự nằm ở phía sender: pace nó lại để gói tin trải đều thay vì bị ghi ra theo từng burst. Một khi nguồn ngừng tạo ra burst vượt egress rate, mất gói sẽ biến mất.
Trên switch bạn có thể làm tình hình buffer bớt khắc nghiệt hơn:
Cái đó mua thêm headroom và cho burst chạy được lâu hơn, nhưng không loại bỏ được nguyên nhân - nếu sender burst đủ mạnh trong đủ lâu, không kích thước buffer nào cứu được bạn. Tiếp tục theo dõi QoS statistics của switch và counter rx-overflow sau khi đổi, để xem bạn còn đang chạm trần hay chỉ thỉnh thoảng chạm vào nó thôi.
Bài học chung đáng nhớ: một port với link sạch, không lỗi và module khỏe mạnh vẫn có thể drop một phần traffic tính bằng phần trăm hai chữ số, chỉ đơn giản vì một bước xuống tốc độ giữa các port.
Trước khi đổ lỗi cho module, xem thử port counter thực sự nói gì. Chạy
trên port ingress 100G và trên cage có S+RJ10, và nhắm cụ thể vào dòng rx-overflow thay vì các counter lỗi rx/tx thông thường. Một SFP+ đồng thực sự hỏng sẽ tự báo hiệu bằng FCS error hoặc link chập chờn, chứ không phải một cú cắt gọn 15% khỏi một dòng traffic vốn khỏe mạnh.
Câu hỏi thứ hai: tốc độ trung bình qua đường đó là bao nhiêu, và bạn có ý niệm gì về đỉnh không? Mất một gói trong bảy gói với CPU ở 1% nghe giống egress port hết buffer hơn nhiều so với lỗi transceiver.
Counter trước đã: không lỗi ở port nào cả, link giữ up suốt và module không báo gì bất thường. rx-overflow là chỗ duy nhất mà số liệu có nhúc nhích.
Về tốc độ, đường đó trung bình 400-500 Mbps, nên trên giấy thì còn lâu mới bão hòa phía 1G. Tôi không có số đo đỉnh, nhưng traffic vốn bursty theo bản chất - sender ghi ra một cụm rồi im lặng một lúc. CPU vẫn ở 1% trong khi gói tin cứ biến mất.
Lỗi khác, nhưng cùng bài học về việc tin counter hơn tin trực giác. Tôi từng có một CRS354-48G-4S+2Q+RM trên SwOS 2.18 với Rx FCS Errors tăng đều trên cả hai port QSFP+, và Rx MAC Errors tăng chậm hơn. Cả hai port đều ở 40G full duplex với MTU 1500, và phía bên kia là các host ESXi gắn card Mellanox ConnectX-3 Pro CX324A.
Phần thú vị: phía NIC không báo cáo gì hết.
Sạch trơn. Đổi sang cáp biết chắc là tốt cũng chẳng thay đổi gì, và các port SFP+ 10G của cùng máy đó vẫn không lỗi suốt cả quá trình. Tôi chưa bao giờ có được một chẩn đoán thật sự - chuyển switch từ SwOS sang RouterOS khiến counter biến mất, mà tôi coi đó là che giấu vấn đề chứ không phải giải quyết nó.
Cách duy nhất còn trụ được: xóa counter, đọc lại sau một khoảng thời gian cố định và xem lỗi có bám theo lượng traffic không. Trong trường hợp của bạn chúng sẽ bám theo burst, trong trường hợp của tôi chúng chẳng bám theo gì có ích cả, và chỉ riêng sự khác biệt đó đã nói cho bạn biết nên tiếp tục đào ở phía nào.
Một điều cần nhớ khi bạn thử nghiệm trên port đó: đừng chọn ép speed và duplex như một lối thoát. Hành vi đã được ghi nhận của các module đồng MikroTik, cả S-RJ01 lẫn S+RJ10, là chúng chỉ hoạt động khi auto-negotiation bật - ghim rate cố định là link không lên chút nào. Thực tế phần nào mâu thuẫn với điều đó, vì một số chủ RB5009 và RB4011 báo cáo ngược lại và chỉ ổn định được S-RJ01 bằng cách ép 1G full duplex, nên đây là kiểu "tự thử cả hai trên phần cứng của bạn" chứ không phải một quy tắc cứng. Dù sao thì đó cũng là một lối rẽ khỏi vấn đề thật sự của bạn, vốn nằm ở phía buffer.
Chi tiết khác về S+RJ10 đáng biết để sau này dùng: nó ăn điện nhiều hơn hẳn một optic bình thường và chạy nóng, nên không khuyến khích dùng trong thiết bị tản nhiệt thụ động mà không có thêm luồng khí. Nếu module đó có lúc nào bắt đầu hoạt động bất thường trong một chassis ấm, nhiệt độ là thứ đầu tiên tôi sẽ kiểm tra.