CRS518-16XS-2XQ'da bir S+RJ10 copper SFP+ üzerinden yaklaşık %15 packet loss, direkt 100G yol ise temiz
Bir lab sunucusundan trafiği 100G QSFP28 uplink üzerinden bir CRS518-16XS-2XQ'ya itiyoruz, switch'ten de bir MikroTik S+RJ10 copper SFP+ üzerinden düz bir 1G RJ45 host'a çıkıyor. Alıcı tarafta paketlerin büyük bir kısmı kayboluyor ve bunu belirgin bir şeye bağlayamıyorum.
Kurulum:
- MikroTik CRS518-16XS-2XQ, trafik kaynağından 100G QSFP28 uplink
- kafeslerden birinde MikroTik S+RJ10 copper SFP+, uzak uçta 1G RJ45 cihaz
- alıcı host'ta çalışan bir capture
Capture'ın söylediği:
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%Şimdiye kadar denediklerim:
- aynı kaynağı direkt 100G'de bağladım, hiç kayıp yok, yani gönderenin kendisi sorunsuz
- switch CPU'sunu düşürdüm, şimdi %1'de duruyor ama kayıp hâlâ oluyor
- S+RJ10'u yeniden oturttum ve 1G cihaza giden patch kordonu değiştirdim
Bu noktada asıl şüphelendiğim copper modül, ama link temiz ve interface hiç hata göstermiyor. S+RJ10'un trafiği böyle yediği biliniyor mu, yoksa switch'in içinde başka bir yere mi bakmalıyım?
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
Bütün hikaye, bursty bir gönderenle 400-500 Mbps ortalama. Trafiğin eşit dağılmıyor: kısa burst'ler kaynaktan 1 Gbps'ten daha hızlı çıkıyor, o çizginin üzerindeki her şey de 1G taraf onu boşaltana kadar portun egress buffer'ında oturmak zorunda. Buffer dolduğunda switch drop ediyor. rx-overflow hareketinin sana tam olarak söylediği bu, direkt 100G bağlantının hiçbir şey göstermemesinin sebebi de bu - orada karşısına buffer'layacak bir hız basamağı yok.
Transceiver masum. O kafesteki herhangi bir şey, copper ya da fiber, aynı davranırdı, çünkü drop 100G'den 1G'ye inişte oluyor, modülün içinde değil.
Yapılacak iki şey var. Asıl çözüm gönderende: paketler burst'ler halinde yazılmak yerine eşit dağılacak şekilde pace'le. Kaynak egress rate'in üzerinde burst üretmeyi bıraktığında kayıp kayboluyor.
Switch'te buffer durumunu daha az düşmanca yapabilirsin:
Bu biraz headroom kazandırır ve bir burst'ün daha uzun süre idare etmesini sağlar, ama sebebi ortadan kaldırmaz - gönderen yeterince uzun süre yeterince sert burst yaparsa, hiçbir buffer boyutu seni kurtarmaz. Değişiklikten sonra switch QoS istatistiklerini ve rx-overflow sayaçlarını izlemeye devam et, böylece hâlâ tavana çarpıp çarpmadığını yoksa sadece ara sıra mı dokunduğunu görebilirsin.
Genel ders akılda tutmaya değer: temiz linkli, hatasız ve sağlıklı modüllü bir port, sırf portlar arasındaki bir hız basamağı yüzünden trafiğin iki haneli bir yüzdesini yine de drop edebilir.
Modülü suçlamadan önce, port sayaçlarının gerçekte ne söylediğine bak. Şunu çalıştır
100G ingress portunda ve S+RJ10'un olduğu kafeste, olağan rx/tx hata sayaçları yerine özellikle rx-overflow satırına bak. Gerçekten bozuk bir copper SFP+ kendini FCS hataları ya da flap yapan bir link olarak duyurur, aksi halde sağlıklı bir akıştan düzgünce kesilmiş bir %15 olarak değil.
İkinci soru: o yoldaki ortalama hız ne, tepe değerler hakkında bir fikrin var mı? CPU %1'deyken yedi paketten birini kaybetmek, bir transceiver arızasından çok egress portunun buffer'ının tükenmesi gibi kokuyor.
Önce sayaçlar: iki portta da hata yok, link boyunca up kalıyor ve modül anormal bir şey raporlamıyor. Rakamların hareket ettiği tek yer rx-overflow.
Hız konusunda, yol ortalama 400-500 Mbps, yani kağıt üzerinde 1G tarafını doyurmaya hiç yaklaşmıyor. Tepe ölçümüm yok, ama trafik doğası gereği bursty - gönderen bir yığın yazıp bir süre susuyor. Paketler kaybolurken CPU hâlâ %1.
Farklı bir arıza, sayaçlara sezgiden çok güvenmekle ilgili aynı ders. SwOS 2.18'de, iki QSFP+ portunda da sürekli büyüyen Rx FCS Errors ve daha düşük bir oranda Rx MAC Errors olan bir CRS354-48G-4S+2Q+RM'im vardı. İki port da MTU 1500 ile 40G full duplex'te oturuyordu, karşı tarafta da içlerinde Mellanox ConnectX-3 Pro CX324A kartları olan ESXi host'ları vardı.
İlginç kısım: NIC tarafı hiçbir şey raporlamıyordu.
Tertemiz. Bilinen sağlam kablolar hiçbir şeyi değiştirmedi, aynı kutunun 10G SFP+ portları da boyunca hatasız kaldı. Gerçek bir teşhis hiç alamadım - switch'i SwOS'tan RouterOS'a taşımak sayaçların kaybolmasını sağladı, ki bunu sorunu çözmek değil gizlemek olarak sayıyorum.
Ayakta kalan yöntem: sayaçları temizle, sabit bir aralıkta yeniden oku, hataların trafik hacmini takip edip etmediğine bak. Senin durumunda burst'leri takip edecekler, benimkinde işe yarar hiçbir şeyi takip etmediler, o fark tek başına hangi tarafı kazmaya devam edeceğini söylüyor.
O portta denemeler yaparken aklında tutman gereken bir şey: çıkış yolu olarak forced speed ve duplex'e uzanma. MikroTik copper modüllerinin belgelenen davranışı, S-RJ01 ile S+RJ10 aynı şekilde, sadece auto-negotiation açıkken çalışmaları - hızı statik olarak sabitlersen link hiç gelmez. Pratik buna kısmen ters düşüyor, çünkü birkaç RB5009 ve RB4011 sahibi tersini bildiriyor ve bir S-RJ01'i ancak 1G full duplex'i zorlayarak stabil hale getirdi, yani bu bir kural değil, "kendi donanımında ikisini de dene" meselesi. Her hâlükârda bu, asıl sorunundan bir sapma, o da buffer tarafında.
İleride bilmekte fayda olan başka bir S+RJ10 detayı: normal bir optikten belirgin şekilde daha fazla güç çekiyor ve sıcak çalışıyor, bu yüzden ekstra hava akımı olmadan pasif soğutmalı bir cihazda önerilmiyor. O modül sıcak bir şasi içinde bir gün yaramazlık yapmaya başlarsa, ilk kontrol edeceğim şey sıcaklık olur.