Modemi/AP'yi Yeniden Başlatınca Düzeliyor: Asıl Sorun Ne?

'Yeniden başlatınca düzeliyor' aslında ne anlama gelir?

Bir ağ cihazının yeniden başlatma (reboot) ile düzelmesi, sorunun kalıcı bir donanım arızası değil, zamanla biriken bir yazılım/durum (state) sorunu olduğunu gösterir. Reboot işlemi, cihazın RAM'ini temizler, tüm açık bağlantı tablolarını, önbellekleri ve çalışan süreçleri sıfırdan başlatır. Eğer sorun reboot sonrası kayboluyor ama saatler veya günler içinde geri geliyorsa, bu neredeyse kesin olarak zamana bağlı bir birikim (accumulation) sorunudur.

Bu paterni fark etmek, sorun giderme sürecinde çok değerlidir çünkü 'her seferinde yeniden başlat' pratiği aslında kök nedeni gizler ve ileride daha ciddi bir kesintiye (örneğin cihazın tamamen donması) zemin hazırlar. Doğru yaklaşım, sorunun ne kadar sürede geri geldiğini not etmek ve bu süreyi olası nedenlerle eşleştirmektir: birkaç saat içinde geri geliyorsa bellek sızıntısı veya bağlantı tablosu dolması; günler içinde geri geliyorsa DHCP lease tükenmesi veya DFS kanal sorunları daha olasıdır.

Kurumsal ortamlarda bu paternin SNMP veya kontrolcü üzerinden izlenen bellek kullanımı, CPU yükü ve bağlı istemci sayısı grafikleriyle doğrulanması önerilir; zamanla sürekli artan bir bellek grafiği, klasik bir bellek sızıntısı imzasıdır.

Bellek sızıntısı (memory leak): en sinsi neden

Bellek sızıntısı, bir yazılım sürecinin kullandığı belleği işi bittikten sonra düzgün şekilde serbest bırakmaması durumudur. AP veya router firmware'inde bu genellikle bağlantı takip tablosu (connection tracking), DNS önbellek yönetimi veya NAT tablosu gibi dinamik yapıların zamanla büyüyüp hiç küçülmemesi şeklinde ortaya çıkar. Bellek dolmaya yaklaştıkça cihaz yavaşlar, paket işleme gecikir, yeni bağlantılar reddedilmeye başlar ve sonunda cihaz ya kilitlenir ya da kendiliğinden yeniden başlar (watchdog reset).

Tüketici sınıfı router'larda bu sorun özellikle çok sayıda IoT cihazının bağlı olduğu ev ağlarında yaygındır, çünkü her IoT cihazının periyodik bulut bağlantıları NAT tablosunu hızla doldurur ve düşük bellekli donanım bu yükü zamanla kaldıramaz hale gelir. Kurumsal sınıf AP'lerde bu sorun genellikle belirli bir firmware sürümüne özgü bir hatadır (bug) ve üretici tarafından bir sonraki sürümde düzeltilir; bu nedenle kronik bellek sorunlarında ilk kontrol edilmesi gereken şey firmware sürüm notlarıdır (release notes / known issues).

Geçici çözüm olarak haftalık otomatik yeniden başlatma zamanlayıcısı (scheduled reboot) kurmak pratikte işe yarasa da, bu bir tedavi değil semptom bastırmadır; kalıcı çözüm güncel ve kararlı bir firmware sürümüne geçmek veya düşük bellekli donanımı daha güçlü bir modelle değiştirmektir.

DHCP lease tükenmesi ve DFS radar sonrası kanal donması

DHCP havuzunun (address pool) tükenmesi, özellikle misafir ağlarında veya çok sayıda geçici cihazın (ziyaretçi telefonları, IoT) bağlandığı ortamlarda görülen bir başka 'reboot ile düzelen' sorundur. DHCP sunucusu, istemci ağdan habersiz ayrılsa bile (örn. telefon kapsama dışına çıkmış) adresi lease süresi dolana kadar o cihaza ayrılmış tutar; MAC rastgeleleştirme aynı cihazın birden fazla adres almasına da yol açabilir. Havuz küçükse (örneğin /24 yerine /27 gibi dar bir subnet), bu 'hayalet' lease'ler zamanla tüm havuzu doldurur ve yeni cihazlar IP alamaz hale gelir. DHCP sunucusu AP'nin veya yönlendiricinin içindeyse ve lease tablosunu yalnızca bellekte tutuyorsa, reboot bu tabloyu temizler (ayrı bir sunucu kullanılıyorsa AP'yi yeniden başlatmak havuzu boşaltmaz); ama kalıcı çözüm, lease süresini kısaltmak (örn. 24 saat yerine 4-8 saat) veya havuzu büyütmektir.

DFS (Dynamic Frequency Selection) kanalları kullanan 5 GHz AP'lerde ise farklı bir mekanizma işler: AP, kullandığı DFS kanalında bir radar sinyali algıladığında (gerçek bir hava radarı veya bazen yanlış pozitif bir algılama), yasal zorunluluk gereği o kanalı derhal terk etmek ve farklı bir kanala geçmek zorundadır. Bazı firmware'lerde bu geçiş düzgün yönetilmez; AP yeni kanalda kararsız kalır, istemcileri düzgün taşıyamaz veya kanal geçişi sırasında radyo tamamen devre dışı kalabilir (yeni kanal da DFS kanalıysa, yayına başlamadan önce en az 60 saniyelik 'channel availability check' gerekir; hava radarı bandında bu süre 10 dakikaya çıkar).

Bu durumda yeniden başlatma AP'yi normal kanal tarama sürecine geri döndürüp sorunu geçici olarak çözer, ama radar algılaması tekrar tetiklenirse sorun yeniden ortaya çıkar. Kalıcı çözüm, mümkünse DFS olmayan sabit bir kanala (Türkiye'de 36, 40, 44 ve 48 numaralı kanallar; U-NII-3 kanalları Türkiye/AB'de kurumsal iç mekan Wi-Fi için kullanılamaz) geçmek veya üreticinin DFS yönetim algoritmasını iyileştiren güncel firmware'i kullanmaktır.

Kalıcı çözüm için doğru teşhis süreci

Kalıcı çözüme ulaşmanın ilk adımı, sorunun geri gelme süresini ve çevresel tetikleyicileri (örn. belirli saatlerde yoğunluk artışı, hava durumu radar algılaması tetikliyorsa) not etmektir. Kurumsal AP ve kontrolcülerde syslog kayıtları bu konuda altın değerindedir: 'DFS event', 'DHCP pool exhausted', 'out of memory', 'watchdog reset' gibi log girdileri kök nedeni doğrudan işaret eder.

İkinci adım, cihazın mevcut firmware sürümünü üreticinin bilinen hatalar (known issues) listesiyle karşılaştırmaktır; birçok 'periyodik reboot gerektiren' sorun aslında belgelenmiş ve bir sonraki sürümde düzeltilmiş bir hatadır. Üçüncü adım ise, donanımın mevcut ağ yüküne (bağlı istemci sayısı, trafik hacmi) göre yetersiz kaldığı durumlarda daha yüksek kapasiteli bir modele geçiştir — özellikle tüketici sınıfı router'ların kurumsal yüke maruz kaldığı küçük işletme ortamlarında bu çok sık karşılaşılan bir durumdur.

Geçici bir önlem olarak günlük/haftalık otomatik reboot zamanlayıcısı, kalıcı çözüm bulunana kadar kesintiyi öngörülebilir ve düşük trafikli saatlere (örn. gece 03:00) taşımak için kullanılabilir; ancak bu asla nihai çözüm olarak sunulmamalıdır.

F2 sahada nasıl çözüyor?

F2 mühendisleri 'reboot ile düzeliyor' şikayetlerinde önce cihazın syslog ve SNMP geçmişini inceleyerek bellek/CPU trendini ve DFS olaylarını tespit eder, ardından firmware sürümünü üreticinin bilinen hatalar listesiyle karşılaştırır. Saha deneyiminde bu sorunların büyük çoğunluğu, doğru firmware sürümüne geçiş, DHCP lease süresinin optimize edilmesi veya DFS dışı sabit kanala geçişle kalıcı olarak, bir daha reboot gerektirmeden çözülmektedir.