CRS518-16XS-2XQ पर S+RJ10 copper SFP+ से करीब 15% packet loss, जबकि direct 100G path बिलकुल clean है
हम एक lab server से traffic को CRS518-16XS-2XQ में 100G QSFP28 uplink के ज़रिए भेजते हैं, और वहाँ से यह switch से निकलकर MikroTik S+RJ10 copper SFP+ के रास्ते एक plain 1G RJ45 host तक जाता है। receiving side पर packets का एक बड़ा हिस्सा पहुँच ही नहीं रहा, और मैं इसे किसी साफ वजह से जोड़ नहीं पा रहा।
Setup:
- MikroTik CRS518-16XS-2XQ, traffic source से 100G QSFP28 uplink
- एक cage में MikroTik S+RJ10 copper SFP+, दूसरे छोर पर 1G RJ45 device
- receiving host पर capture चल रहा है
Capture क्या बताता है:
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%अब तक जो try किया:
- वही source सीधे 100G पर connect किया, कोई loss नहीं, यानी sender खुद बिलकुल ठीक है
- switch का CPU load नीचे लाया, अब यह 1% पर है और loss फिर भी वैसे ही हो रहा है
- S+RJ10 reseat किया और 1G device तक का patch cord बदला
फिलहाल copper module ही मेरा मुख्य शक है, लेकिन link clean है और interface पर कोई error नहीं दिख रहा। क्या S+RJ10 इस तरह traffic खाने के लिए जाना जाता है, या मुझे 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
Bursty sender के साथ 400-500 Mbps average, यही पूरी कहानी है। आपका traffic evenly spread नहीं है: छोटे bursts source से 1 Gbps से तेज़ रफ्तार में निकलते हैं, और उस line से ऊपर जो भी है उसे port के egress buffer में तब तक बैठना पड़ता है जब तक 1G साइड उसे drain न करे। जब buffer भर जाता है, switch drop करता है। rx-overflow की हलचल ठीक यही बता रही है, और यही वजह है कि direct 100G connection में कुछ नहीं दिखता - वहाँ buffer करने लायक कोई speed step down है ही नहीं।
Transceiver बेकसूर है। उस cage में copper हो या fibre, कुछ भी हो, वैसा ही व्यवहार करता, क्योंकि drop 100G से 1G वाले step down पर होता है, module के अंदर नहीं।
दो चीज़ें करने लायक हैं। असली fix sender पर है: उसे pace करें ताकि packets bursts में लिखे जाने की बजाय evenly spread हों। जैसे ही source egress rate से ऊपर bursts बनाना बंद कर देता है, loss गायब हो जाता है।
Switch पर आप buffer की situation को थोड़ा कम hostile बना सकते हैं:
इससे थोड़ा headroom मिल जाता है और burst थोड़ी देर और टिक जाता है, लेकिन वजह खत्म नहीं होती - अगर sender काफी ज़ोर से और काफी देर तक burst करे, तो कोई भी buffer size नहीं बचाएगा। बदलाव के बाद switch की QoS statistics और rx-overflow counters देखते रहें, ताकि पता चले कि आप अब भी ceiling से टकरा रहे हैं या बस कभी-कभार छू रहे हैं।
एक बात याद रखने लायक है: clean link, बिना किसी error के और healthy module वाला port भी सिर्फ ports के बीच speed step down की वजह से traffic का double-digit हिस्सा drop कर सकता है।
Module को दोष देने से पहले, port counters असल में क्या कह रहे हैं वो देखें। यह चलाएँ:
100G ingress port पर और S+RJ10 वाले cage पर, और खास तौर पर rx-overflow वाली line देखें, सामान्य rx/tx error counters नहीं। सच में खराब copper SFP+ खुद को FCS errors या flapping link के तौर पर जाहिर करता है, किसी otherwise healthy stream से साफ-सुथरे 15% कटौती के तौर पर नहीं।
दूसरा सवाल: उस path से average rate कितनी है, और peaks का कोई अंदाज़ा है? CPU 1% पर होते हुए हर सात में से एक packet खोना transceiver की खराबी से कहीं ज्यादा egress port के buffer खत्म होने जैसा लगता है।
पहले counters: दोनों ports पर कोई error नहीं, link पूरे समय up रहता है और module कुछ भी unusual report नहीं करता। rx-overflow ही अकेली जगह है जहाँ numbers हिलते हैं।
Rate की बात करें तो path का average 400-500 Mbps है, तो कागज़ पर यह 1G साइड को saturate करने के आसपास भी नहीं है। मेरे पास peak का कोई measurement नहीं है, लेकिन traffic स्वभाव से bursty है - sender एक chunk लिखता है और फिर कुछ देर चुप हो जाता है। CPU अब भी 1% पर है जबकि packets गायब हो रहे हैं।
अलग तरह की खराबी, पर सीख वही: counters पर भरोसा करो, intuition पर नहीं। मेरे पास एक CRS354-48G-4S+2Q+RM था SwOS 2.18 पर, जिसमें दोनों QSFP+ ports पर Rx FCS Errors लगातार बढ़ रहे थे, और Rx MAC Errors थोड़ी कम रफ्तार से। दोनों ports 40G full duplex पर MTU 1500 के साथ थे, और दूसरी तरफ Mellanox ConnectX-3 Pro CX324A cards वाले ESXi hosts थे।
दिलचस्प हिस्सा: NIC साइड कुछ भी report नहीं कर रहा था।
Clean। Known-good cables से कुछ नहीं बदला, और उसी box के 10G SFP+ ports पूरे समय error free रहे। मुझे कभी असली diagnosis नहीं मिली - switch को SwOS से RouterOS पर ले जाने से counters गायब हो गए, जिसे मैं problem solve करना नहीं, छिपाना मानता हूँ।
जो तरीका काम आया: counters clear करें, एक fixed interval में उन्हें दोबारा पढ़ें और देखें कि errors traffic volume के साथ चलते हैं या नहीं। आपके case में वे bursts के साथ चलेंगे, मेरे case में वे किसी काम के track नहीं हुए, और बस यही फर्क बताता है कि किस तरफ खोदते रहना है।
उस port पर experiment करते वक्त एक बात ध्यान में रखें: रास्ता निकालने के लिए forced speed और duplex मत आज़माइए। MikroTik copper modules का documented behaviour, S-RJ01 और S+RJ10 दोनों का, यह है कि वे सिर्फ auto-negotiation enabled रहने पर काम करते हैं - rate को statically pin करने पर link आता ही नहीं। Practice इससे थोड़ा उल्टा भी दिखाती है, क्योंकि कुछ RB5009 और RB4011 owners इसके उलट बताते हैं और उन्हें S-RJ01 सिर्फ 1G full duplex force करके ही stable मिला, तो यह कोई rule नहीं बल्कि "अपने hardware पर दोनों try करो" वाली बात है। किसी भी तरह यह आपकी असली problem से भटकाव है, जो buffer साइड पर है।
S+RJ10 की एक और बात आगे के लिए जान लेने लायक है: यह सामान्य optic से काफी ज्यादा power खींचता है और गरम चलता है, इसलिए बिना extra airflow वाले passively cooled device में इसकी सलाह नहीं दी जाती। अगर वह module कभी गरम chassis में गड़बड़ करने लगे, तो सबसे पहले मैं temperature ही check करूँगा।