FortiGate 101F'te ortak RJ45/SFP portları 17-20, FortiOS yükseltmesinden sonra sönüyor
40 kişilik bir ofis için bir çift FortiGate 101F çalıştırıyoruz, egzotik bir şey yok. port17 core switch'e bir SFP uplink taşıyor, port19 sunucu odasına bir RJ45 hattı, ikisi de ortak RJ45/SFP bloğunun içinde (port 17-20). Geçen ayki bakım penceresinde çifti FortiOS 7.4.4'e çıkardık, o zamandan beri o blok ölü.
- FortiGate 101F, ikinci sahada da aynı şekilde davranan bir FortiGate 100F
- port17: yığınlanmış bir access switch'e 1G SFP modülü
- port19: 1G bir switch portuna RJ45
- 7.2 sürümünden yükseltilmiş FortiOS 7.4.4
Port 1-16 sorunsuz, sadece ortak olanlar düştü. Dikkatimi çeken şey, GUI'deki hız seçeneklerinin artık yükseltmeden önceki gibi görünmemesi, ve running config'te şimdi şu var:
config system interface
edit "port17"
set speed 1000full
next
endBunu burada kimse yazmadı. Yükseltmeden önce bu kutudaki her port auto'daydı.
Şimdiye kadar denenenler:
- SFP'yi yeniden oturttum ve bilinen iyi bir tanesiyle değiştirdim, değişiklik yok
- karşı ucu farklı bir switch portuna taşıdım
- firewall'ın soğuk reboot'u, config yukarıdaki gibi kalıyor
100F/101F'teki ortak RJ45/SFP bloğunun bir yükseltme sırasında auto'yu kaybetmesi beklenen bir şey mi, yoksa config'imiz bir yerde mi bozuldu? Ve onu geri koymanın doğru yolu ne?
Comments 5
Config'inizi ofiste kimse bozmadı, bunu yükseltme yaptı. 100F ve 101F'te yükseltme, karşı tarafın o hızla yaşayıp yaşayamayacağını hiç sormadan, daha önce auto olan ortak RJ45/SFP portlarına sessizce sabit bir 1000full basıyor. Karşı uca bağlı olarak da ya yanlış hızda linkleyen bir port ya da hiç linklemeyen bir port elde ediyorsunuz, 17-20'nin karanlık kalıp özel portların dokunulmamış olmasının sebebi de tam olarak bu. Fortinet bunu bilinen sorun 989629 olarak kayıtlara geçirmiş, 7.2.9 sürüm notlarında yazılı; etkilenen dallar v7.2.8 ve sonrası, v7.4.2 ve sonrası, v7.6.0 ve sonrası.
Hızı elle, port başına geri koyun:
v7.2.8'de ve v7.4.2 ile v7.4.4 arasında düz auto listede sunulmuyor, GUI'nin size farklı görünmesinin sebebi de tam olarak bu, o yüzden orada 1000auto kullanın. v7.2.9, v7.4.5, v7.6.0 ve sonrasında normal seçenek geri geldi ve istediğiniz şu:
Kullanımdaysa port18'den port20'ye kadar tekrarlayın. Bir sonraki pencere için: önce yönetim yolunuzun port 17-20'den herhangi birine düşmediğini kontrol edin, yoksa kutu access portunuz 1000full'a zorlanmış halde geri gelir ve onu konsoldan düzeltmek için sahaya araba sürersiniz.
Gerçekte hangi build'den geldiniz? '7.2 build' çok geniş bir alanı kapsıyor, bunu düzeltmek için yazmanız gereken şey de dallar arasında değişiyor. Bilinmesi gereken diğer şey, karşı uçların autonegotiation sunup sunmadığı yoksa kendilerinin de sabitlenmiş olup olmadığı: sadece autonegotiate eden bir karşı taraf, sabit bir hızda tutulan bir portun karşısında hiçbir şey yapmadan öylece durur.
Herhangi bir şeyi değiştirmeden önce halletmeniz gereken bir şey: yönetim yolunuz port 17-20'den herhangi birinden mi geçiyor? Geçiyorsa, bir sonraki değişikliği ağ üzerinden değil konsoldan yapın.
Buraya kötü davranan bir ortak portla düşen herkes için genel kısmı eklemekte fayda var: çoğu kutuda o çift gerçekten karşılıklı dışlayıcıdır (exclusive). NETGEAR, GS716T-200'de buna dual personality diyor, iki SFP kafesinin her biri son bakır portlardan biriyle eşleştirilmiş durumda, o çiftin sadece yarısı aynı anda aktif olabiliyor, yani bir modül takmak sessizce eşleşen RJ-45'i devre dışı bırakıyor. Zaten o modeldeki her port gigabit, yani optik uplink size bant genişliği değil bir kablo güzergahı satın alıyor.
FortiGate bloğunda da aynı fikir geçerli, o yüzden gerçekte port17'nin hangi yarısına baktığınızı doğrulayın. Kafeste bir modül artı aynı portun bakır yarısında bir patch kordon, klasik bir kendi kalesine gol, ve CLI'dan bakınca da tam bir hız sorunu gibi görünüyor.
Farklı vendor, aynı tür acı. EX-UM-2X4SFP uplink modüllü bir EX4200: xe-0/1/0 gayet mutlu 10G çalışıyordu, xe-0/1/1 bir VLAN'a bile eklenemiyordu ve hiç trafik geçirmiyordu. İki port da 1G'de çalışıyordu, SFP+ show chassis hardware'de eksiksiz görünüyordu, modülleri değiştirdim, yedek bir EX-UM-2X4SFP denedim ve birisi bana modülün gerçekte ne olduğunu söylemeden önce fabrika ayarlarına döndürdüm.
Hiçbir şey arızalı değildi. O modül kafeslerinin sadece ikisine SFP+ kabul ediyor, donanımda 0 ve 2 numaralı olanlara; diğer çift sadece 1G bir optik taşır, daha hızlısını değil. Yani elinizde kalan 10G arayüzler xe-0/1/0 artı xe-0/1/2 oluyor, benim uğraştığım xe-0/1/1 ise içine ne taksam zaten hiçbir zaman 10G çalışmayacaktı. Optiği bir kafes öteye taşıdım, xe-0/1/2'yi yapılandırdım, tamamdır. Karma modlu kafeslerde, herhangi bir şeyi RMA'ya göndermeden önce bloğun neyi desteklediğini okuyun.
Kombo-exclusivity açısına dikkat, bu vakayı açıklamıyor. Portlar yükseltmeden önce çalışıyordu, sadece ortak blok sonradan bozuldu, config'te de kimsenin yazmadığı bir hız satırı var. Bu, cage priority değil, o yeniden yazma.
Ama tersi hata da insanları yakıyor. Bir keresinde fiber üzerinden bir OSNOVO NS-SW-8GX2G'ye uplink edilmiş D-Link DES-1210-52 switch'lerde bir hafta harcadım: optik portlarda link göstergesi var, LAN yok, internet hiç yok, aynı switch'ler bakır üzerinden zincirlendiğinde sorunsuz çalışıyordu, bir firmware güncellemesi de hiçbir şey değiştirmedi. Kombo port günlerce baş şüpheliydi. Gerçek arıza karşı uçtaydı: o SFP modüllerini taşıyan OSNOVO portları içten ölüydü, yanmıştı, içlerindeki optikler ise tamamen sağlıklı oturuyordu.
Yani yerel config doğru olduğunda, kendi kutunuz hakkında herhangi bir sonuca varmadan önce karşı tarafa bilinen iyi bir modülü bilinen iyi bir porta takın.