IP Adresi Alamıyorum: DHCP'nin Wi-Fi'da Kırıldığı Noktalar

DHCP DORA Döngüsü ve Kablosuzun Getirdiği Kırılganlık

DHCP, istemcinin ağa IP adresi alması için dört aşamalı bir süreç yürütür: Discover, Offer, Request, Acknowledge (DORA). İstemci önce ağa bir broadcast Discover paketi gönderir, sunucu bir Offer ile IP teklif eder, istemci bu teklifi Request ile onaylar, sunucu da Acknowledge ile işlemi tamamlar. Kablolu bir anahtar portunda bu dört paket genelde milisaniyeler içinde, kayıpsız tamamlanır.

Kablosuz ortamda ise bu dört paketin her biri RF üzerinden, çekişmeli bir ortamda, değişken gecikmeyle taşınır. Özellikle Discover ve Request paketleri broadcast/multicast olarak gönderildiği için, 802.11 ağlarında en düşük temel hız (basic rate) üzerinden iletilir ve unicast trafiğe göre çok daha az güvenilir şekilde ulaşır. Yoğun bir ortamda, zayıf sinyalde ya da roaming anında bu paketlerden biri kaybolursa istemci IP alamadan kalır.

Bir diğer kritik nokta, istemcinin DHCP isteğini AP'ye bağlandığı anda, henüz RF bağlantısı tam oturmamışken göndermesidir. 802.11 ilişkilendirmesi tamamlanır tamamlanmaz işletim sistemi DHCP isteğini tetikler; ancak bu sırada AP ile istemci arasında henüz kararlı bir hız anlaşması oluşmamış olabilir. Bu da ilk DORA denemesinin başarısız olup, saniyeler süren yeniden deneme döngülerine girilmesine yol açar.

VLAN ve DHCP Relay Hataları

Kurumsal kablosuz ağlarda SSID'ler genellikle belirli VLAN'lara eşlenir ve bu VLAN'lar AP'den anahtara, anahtardan da DHCP sunucusuna veya relay noktasına kadar uçtan uca doğru taşınmalıdır. Sahada en sık karşılaşılan hatalardan biri, AP'nin trunk portunda ilgili VLAN'ın izinli (allowed) listede olmamasıdır. Bu durumda istemci AP'ye bağlanır, ancak DHCP Discover paketi hiçbir zaman sunucuya ulaşmaz.

Bir diğer yaygın problem, WLC veya AP üzerinde tanımlı VLAN ID'si ile anahtar tarafındaki VLAN ID'sinin eşleşmemesidir — özellikle çok siteli kurulumlarda, her lokasyonda VLAN numaralandırmasının standartlaştırılmamış olması bu hatayı tetikler. Ayrıca DHCP relay (ip helper-address) yapılandırılmış ağlarda, relay'in yanlış arayüze veya yanlış sunucu IP'sine işaret etmesi de aynı belirtiyi — sessizce IP alamama — doğurur.

Bu tür sorunların teşhisinde en güvenilir yöntem, AP'nin bağlı olduğu anahtar portunda ilgili VLAN için paket yakalamaktır. Eğer Discover paketleri anahtar portuna ulaşıyor ama DHCP sunucusu tarafında hiç görünmüyorsa, sorun kesinlikle L2/L3 iletim zincirindedir; RF ile ilgisi yoktur.

• AP trunk portunda ilgili VLAN izinli mi?
• WLAN profilindeki VLAN ID anahtar tarafıyla birebir eşleşiyor mu?
• ip helper-address doğru DHCP sunucusunu mu gösteriyor?
• Relay arayüzünün IP'si DHCP scope'unun gateway'iyle uyumlu mu?

Scope Tükenmesi: Görünmeyen Ama Çok Sık Rastlanan Sebep

Özellikle misafir ağlarında, etkinlik alanlarında veya yoğun BYOD ortamlarında DHCP scope'unun dolması, 'bağlandım ama IP alamadım' şikayetinin en sık rastlanan nedenlerinden biridir. Lease süresi gereğinden uzun tutulmuş (örneğin 24 saat) bir scope'ta, cihazlar ağdan ayrılsa bile IP adresleri hemen boşa çıkmaz; bu da scope'un fiilen kullanılan cihaz sayısından çok daha hızlı dolmasına yol açar.

Bu durumun belirtisi karakteristiktir: sorun belirli saatlerde (örneğin sabah 09:00-09:30 arası, herkesin ofise girdiği an) yoğunlaşır ve gün içinde kendiliğinden azalır. DHCP sunucu loglarında 'no addresses available' veya benzeri bir hata mesajı bu teşhisi kesinleştirir.

Çözüm genellikle iki yönlüdür: lease süresini ortamın kullanım desenine göre kısaltmak (misafir ağında 1-4 saat, kurumsal ağda 8-24 saat gibi) ve scope büyüklüğünü gerçek eşzamanlı istemci sayısının en az %30 üzerinde tutacak şekilde yeniden boyutlandırmak.

Sahada Hızlı Teşhis Sırası

DHCP ile ilgili şikayetlerde zaman kaybetmemek için sistematik bir sıra izlemek gerekir. İlk adım her zaman aynı istemcinin kablolu bir porttan IP alıp alamadığını test etmektir; eğer kablolu bağlantıda da sorun varsa mesele kablosuzla değil DHCP sunucusu veya ağ mimarisiyle ilgilidir.

İkinci adım, AP ile anahtar arasındaki trunk portunu ve VLAN eşleşmesini doğrulamaktır. Üçüncü adım DHCP sunucusu loglarını incelemek, scope doluluğunu ve relay yapılandırmasını kontrol etmektir. Dördüncü adım ise RF tarafını devreye almaktır: eğer istemci zayıf sinyal bölgesinde ise veya yoğun bir ortamda roaming yapıyorsa, DORA paketlerinin kaybolma ihtimali artar ve bu durumda çözüm kanal planlaması ile hücre boyutlandırmasından geçer.

• 1) Aynı istemciyi kablolu portta test et
• 2) AP-anahtar trunk/VLAN eşleşmesini doğrula
• 3) DHCP sunucu loglarını ve scope doluluğunu kontrol et
• 4) RF tarafında sinyal seviyesi ve roaming davranışını incele
• 5) Gerekirse AP ile anahtar arasında paket yakalama yap

F2 Sahada Nasıl Çözüyor?

F2 mühendisleri bir 'IP alamıyorum' şikayetine asla tek bir katmandan bakmaz. Saha ziyaretinde önce Ekahau Sidekick ile ilgili bölgede RF kalitesini doğrular, ardından AP-anahtar trafiğini eş zamanlı paket yakalama ile izleyerek DORA döngüsünün hangi aşamada kesildiğini tespit eder. Çok sayıda vakada, sorun RF değil; yanlış yapılandırılmış trunk portu, unutulmuş VLAN izni veya aşırı uzun lease süresinden kaynaklanan scope tükenmesi olarak ortaya çıkar. F2, çözümü sadece bir anlık düzeltmeyle değil, VLAN standardizasyonu ve scope boyutlandırma politikasıyla kalıcı hale getirir; böylece aynı sorun farklı bir lokasyonda tekrar yaşanmaz.