Huawei CE6800'ün Profitap XX-3200G'ye 100GE uplink'i SR4 optiklerle hiç gelmiyor
Müşterinin mevcut aggregation çiftini CloudEngine donanımıyla değiştiriyorum, gelmeyi reddeden tek link de packet broker'ına giden 100GE besleme. Switch'teki geri kalan her şey dramsız girdi.
- Huawei CloudEngine 6800, 100GE port
- 100GBASE-SR4 QSFP28 modülleri, Huawei parça, her uçta bir tane
- karşı tarafta Profitap XX-3200G packet broker
Her iki uç da kendi modülünü görüyor. Switch log'unda benim yeniden oturttuğum sıradaki transceiver takma/çıkarma kayıtlarından başka hiçbir şey yok, hiç alarm yok, interface de basitçe down duruyor:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECŞimdiye kadar denediklerim:
- iki modülü de yedeklerle değiştirdim ve MPO uçlarını temizledim, değişen bir şey olmadı;
- linki switch'te başka bir 100GE porta taşıdım;
- broker tarafını kontrol ettim, kendi modülünü tespit ediyor ve yanlış bir şey rapor etmiyor.
Yani optikler her iki uçta da tanınıyor, hiçbir şey şikayet etmiyor, ve link yok. Bir CloudEngine 100GE portu ile üçüncü parti bir kutu arasında link train olmadan önce başka ne eşleşmeli?
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 3
Bu bir FEC uyuşmazlığı. CloudEngine, SR4 optikli 100GE portlarda RS-FEC'i varsayılan olarak açıyor, broker'da FEC ayarı yok, dolayısıyla onsuz çalışıyor, FEC konusunda anlaşamayan iki uç da training'i hiç bitirmiyor. Hiçbir şey bozuk değil, o yüzden hiçbir şey loglanmıyor, log'unda sadece takma/çıkarma mesajlarının olmasının sebebi de bu.
Switch'te, interface view'da kapat:
undo fec modeaynı işi yapıyor. Önemli olan ikinci satır. CE iki aşamalı configuration kullanıyor, commit edilmemiş birfec mode noneconfig'i geri okuduğunda tamamen doğru görünür, port da tam olarak öncekiyle aynı şekilde down kalmaya devam eder. Bu yüzden bir müşteri case'inin fazladan bir gün sürdüğüne tanık oldum, herkes FEC'in zaten kapatıldığına ikna olmuşken.Commit'ten sonra
display interface, FEC: NONE göstermeli ve port train olmalı.Karşı uç bir gün FEC ayarı kazanırsa, daha iyi çözüm orada RS-FEC'i açıp switch'i varsayılanında bırakmak, çünkü 100G'de düzeltmeyi gerçekten istersin. İki farklı vendor arasında, bir şeyin negotiate etmesine güvenmek yerine FEC'i her iki tarafta da açıkça ayarlardım.
Broker kendi tarafında FEC hakkında ne diyor, bir şey diyorsa tabii? İlginç yarısını zaten kendin paylaşmışsın: switch portu RS-FEC çalıştırıyor. Huawei, bir 100GE linkinin iki ucunun da aynı FEC modunu kullanması gerektiğini açıkça belirtiyor, aksi halde interface'ler hiç gelmiyor, bu arıza da tam olarak seninki gibi görünüyor: her iki modül de sağlam, alarm yok, log yok, port down.
Birlikte çalıştığım packet broker'ların ve tap'lerin çoğu bir FEC ayarı hiç sunmuyor, bu da onsuz çalıştıkları ve taviz vermesi gereken tarafın switch olduğu anlamına geliyor. Önce bunu doğrula, sonra tek bir şeyi değiştir.
Eklemekte fayda var: CloudEngine varsayılanı tek bir değer değil, modüle bağlı. QSFP28-100G-LR4 ve QSFP28-100G-LR1, IEEE 802.3'e göre FEC kapalı çalışıyor, diğer tüm QSFP28 tipleri ise varsayılan olarak FEC açık geliyor. Yani sadece kapat tavsiyesi bir LR4 linkinde yanlış, orada switch zaten kapalı ve uyuşmazlık diğer uçta yaşıyor.
Beni yakalamış olan aynı bölümden iki kural daha:
O yüzden FEC'i hangi yöne itmeye karar vermeden önce
display transceiver interface 100GE1/0/1 verboseile elinde gerçekte ne olduğunu kontrol et, ve her iki durumda da commit'i unutma.