Wi-Fi Controller veya Bulut Giderse Ne Olur? HA ve Failover

Kablosuz ağda “HA var” cümlesi tek başına az şey söyler. Yedek controller’a geçişte AP’ler yayında kalıp istemciler yeniden kimlik doğrulayabilir; istemci bağlı kalsa da IP değişebilir; IP aynı kalsa da bir firewall uygulama oturumunu düşürebilir. Neyin korunacağını modelin adı değil, senkronize edilen bilgi belirler.

WAN kesilince bridge ve tunnel SSID’lerde trafiğin davranışı Local Bridge mı, Tunnel Forwarding mi? yazısında, AP’nin controller’ı nasıl bulup CAPWAP kurduğu AP Online Olmuyor yazısında anlatıldı. Bu yazı onları tekrar etmiyor; controller, gateway ya da bulut erişimi kaybolunca neyin korunduğunu, neyin yeniden kurulduğunu ve geri dönüşün etkisini anlatıyor.

Bilgiler belgelere dayanır, laboratuvarda test edilmedi; süreler ölçüm değil, belgedeki değerlerdir.

Dört ayrı “çalışıyor”

“Wi-Fi çalışıyor” cümlesi, birbirinden bağımsız korunan ya da kaybolan dört durumdan birini anlatıyor olabilir:

AP çalışıyor: AP’nin yönetim oturumu ayakta, SSID yayında. AP yayındayken istemciler kopmuş olabilir.
İstemci bağlı: İstemcinin ilişkilendirmesi ve anahtarları geçerli. Yeni controller anahtarları bilmiyorsa 802.1X istemcisi tam kimlik doğrulamaya girer.
IP korunuyor: İstemci aynı VLAN’da ve aynı adresle kalıyor. VLAN ve rol yeni noktada da aynı olmalıdır. DHCP haricî bir sunucudaysa ve IP ağı değişmiyorsa geçerli kira zaten sunucuda durur; kira veritabanını HA cihazına taşımak gerekmez. DHCP sunucusu HA cihazlarının üzerindeyse kira senkronizasyonu önemlidir. Tünel ucu başka bir IP ağına düşerse bağlı kalan istemci de yeni adres almak zorunda kalabilir.
Uygulama oturumu sürüyor: TCP ve VPN oturumları kopmuyor. Yolda durumlu bir firewall ya da gateway varsa onun oturum tablosu da yedeğe aktarılmış olmalıdır.

Her modelde soru aynıdır: hangi katman senkronize ediliyor, hangisi yeniden kuruluyor?

Model adı, stateful davranışı söylemez

“N+1”, “aktif-yedek” ve “küme” mimariyi tarif eder, istemcinin ne yaşayacağını değil. Huawei’nin dört AC yedekleme modunda da bir aktif ve bir yedek AC vardır ama aktarılan bilgi farklıdır (V200R025C10):

VRRP HSB: AP, istemci ve CAPWAP bağlantı bilgisi aktarılır.
Dual-link HSB: Yalnızca istemci bilgisi aktarılır.
Dual-link cold backup ve N+1: Bilgi aktarılmaz.

Fortinet’in Wireless 1+1 özelliği de aktif-yedek bir düzendir ama yalnızca kablosuz yapılandırmayı eşitler. Aşağıdaki çizimdeki örnekler yalnızca adı geçen üretici özelliği için geçerlidir; aynı adı taşıyan başka bir özelliğe genellenemez.

Üç HA mimarisi. Korunan durumu mimarinin adı değil, senkronize edilen bilgi belirler; her örnek, ilgili üreticinin belgelediği koşullarla geçerlidir.

Arıza nerede?

Controller kaybı, tünel ucundaki gateway’in kaybı ve bulut yönetim erişiminin kaybı farklı düzlemleri etkiler. Kontrol düzlemi AP yönetimini, yapılandırmayı ve izlemeyi; veri düzlemi istemci trafiğini kapsar:

Arıza davranışı haritası. Kontrol düzlemi ile veri düzlemi ayrı satırlarda; hücrelerdeki her ifade, üretici bölümlerinde verilen koşullarla geçerlidir.

Üretici belgelerine göre: ne korunur, hangi koşulla?

Cisco Catalyst 9800: N+1 ve HA SSO

N+1 (Cisco Live BRKEWN-2846, 2023; Cisco 222935):

Durumsuz (stateless) bir yedekliliktir. Birincil controller giderse AP’ler ikincile katılır, istemciler yeniden kimlik doğrular.
İkincil farklı model ve sürümde, farklı bir alt ağda olabilir. Yapılandırma otomatik eşlenmez: WLAN, profil, politika, tag ve AP-tag eşlemeleri iki tarafta tutarlı tutulmalıdır.
Cisco aynı sürümü önerir; böylece AP imaj indirmez. Sürümler farklıysa AP’nin birincil ve yedek imajına ve hedef sürüme göre imaj değişimi (swap), indirme ya da yeniden başlatma gerekebilir; 222935’teki örnekte AP’ler kısa bir yeniden başlatmayla imaj değiştirir. İmaj uyumsuzluğu kesintiyi uzatabilir.

HA SSO (IOS XE 17.9.x yapılandırma kılavuzu; Cisco 220277, Mayıs 2026):

Aktif controller AP ve istemci veritabanının bir kopyasını yedeğe aktarır. Geçişte katılmış AP’ler keşif durumuna dönmez, istemciler kopmaz.
Bu, RUN durumuna ulaşmış istemciler için geçerlidir. Client SSO, RUN durumuna ulaşmamış istemcileri kapsamaz; kılavuza göre bunlar geçişten sonra kaldırılır ya da yeniden kimlik doğrular. İstatistik tabloları da aktarılmaz.
İki controller aynı yazılım sürümünü ve önyükleme modunu (install ya da bundle) kullanmalıdır. Cisco Live sunumuna göre fiziksel cihazlar aynı model olmalıdır; C9800-L-C ile C9800-L-F çift olamaz.
Senkronizasyon Redundancy Port (RP) üzerinden yapılır. Redundancy Management Interface (RMI) ikinci bir bağlantıdır; ağ geçidine erişimi kontrol etmek için de kullanılır. İki controller arasındaki gidiş-dönüş süresi 80 ms’nin altında tutulmalıdır.
RP ve RMI birlikte koparsa iki controller da aktif olabilir (dual active, split brain). Cisco toparlanmayı recovery modlarıyla tarif eder; örneğin ağ geçidine ulaşamayan yedek standby-recovery moduna geçer ve aktif rolü devralamaz.
SSO çiftine N+1 de eklenebilir; çiftin iki üyesi birden giderse AP’ler N+1 hedefine geçer.

Huawei AC: VRRP HSB, dual-link ve N+1

Kaynak: Wireless Access Controller (AC and Fit AP) V200R025C10 CLI yapılandırma kılavuzu, AC Backup bölümü (güncelleme Haziran 2026).

VRRP HSB: AP, istemci ve CAPWAP bilgisi HSB kanalıyla toplu, anlık ve periyodik olarak aktarılır. İki AC aynı model ve aynı sürümde olmalı, aralarında katman 2 bağlantı bulunmalıdır. AC aynı zamanda DHCP sunucusuysa, V200R019C00 ve sonrasında DHCP hizmeti HSB grubuna bağlandığında (hsb-service-type dhcp hsb-group) kira bilgisi de aktarılır. DHCPv6 ve WIDS kayıtları aktarılmaz.
Dual-link HSB: Yalnızca istemci bilgisi aktarılır. AP, CAPWAP zaman aşımı algılanınca yavaşça yedeğe geçer; geçtikten sonra istemcilerin yeniden çevrimiçi olması gerekmez. Ama geçiş sürerken tunnel forwarding trafiği kesilir, yeni kullanıcı bağlanamaz, roaming çalışmaz. Portal bilgisi aktarılmadığı için portal kullanıcıları yeniden giriş yapar. IP adresi bilgisi aktarılmaz; DHCP’nin başka bir cihazda olması önerilir.
Dual-link cold backup: Bilgi aktarılmaz. Varsayılan olarak open system kimlik doğrulama kullanan istemciler bağlı kalır, diğer kimlik doğrulama yöntemlerini kullananlar yeniden çevrimiçi olur. Yani aynı yedekleme modunda bile sonuç, istemcinin kimlik doğrulama yöntemine göre değişebilir.
N+1: Bilgi aktarılmaz; AP yalnızca aktif AC ile CAPWAP kurar. Huawei’nin karşılaştırma tablosuna göre bu modda AP’ler ve istemciler yeniden çevrimiçi olur ve kesinti cold backup’takinden uzundur. AC’lerin modeli ve sürümü farklı olabilir ama sürümleri AP yazılım sürümüyle uyumlu olmalıdır.
Birlikte kullanım: Yedekleme modları birbirini dışlar; tek istisna VRRP HSB ile N+1’dir. Her iki AC bir VRRP grubu olarak tek bir sanal cihaz gibi görünür, N+1 bu sanal cihazlar arasında çalışır.

N+1’de yedeğin kapasitesi ayrıca planlanır: desteklediği çevrimiçi AP sayısı, en kalabalık aktif AC’dekinden az olmamalıdır. Huawei’nin örneğinde 500 AP destekleyen yedek, 600 AP’li bir AC’nin yerini aldığında 100 AP çevrimdışı kalır. Bu üst sınırı lisans da belirler.

HPE Aruba AOS 10: küme içi ve kümeler arası geçiş

Kaynak: AOS 10 TechDocs, Cluster features, Cluster failover ve Survivability sayfaları (Ekim 2026).

Küme içi geçiş: Her istemciye kümede bir UDG (User Designated Gateway) ve bir yedek S-UDG atanır. İstemci durumu UDG ile S-UDG arasında tamamen senkronize edilir: istasyon tablosu, kullanıcı tablosu, katman 2 ve katman 3 kullanıcı durumu. UDG giderse S-UDG devralır; Aruba bu geçişi istemciler ve uygulamalar için etkisiz olarak tanımlar. Bunun için ikinci bir düğüm gerekir. Kalan düğümlerde ne kadar boş kapasite gerektiğini belge söylemez; tasarımda ayrıca hesaplanır.
Kümeler arası geçiş: Birincil ve yedek küme genellikle ayrı veri merkezlerindedir. Aruba bu geçişin hitless olmadığını açıkça yazar. Geçiş, birincil kümedeki bütün düğümlere giden tüneller düşünce başlar; tespit tipik olarak 60 saniye içinde olur. Ardından tünelli istemcileri koparmak için profiller 60 saniye kapatılır. VLAN’lar iki kümede de tanımlı olmalıdır; istemciler aynı VLAN’a düşer ama yeni IP adresi alır. Yedek kümenin kapasitesi birincile eşit ya da ondan büyük olmalıdır.
Central erişimi kaybı: Mevcut kümeler çalışmaya devam eder ama düğüm eklenip çıkarılamaz. Cihazlar mevcut yapılandırmayla çalışır; yeni yapılandırma uygulanamaz, izleme verisi kaybolur. Yerel ya da merkezî AAA sunucusuna erişim sürdükçe kimlik doğrulama etkilenmez. Central’daki Cloud Authentication kullanılıyorsa yeni istemciler ağa katılamaz. Mevcut istemciler hızlı roaming’i yalnızca anahtarlarını ve kullanıcı kayıtlarını önceden almış komşu AP’lere yapabilir.

Fortinet FortiGate: FGCP ve Wireless 1+1

Kaynak: FortiAP/FortiWiFi 7.4.4 yapılandırma kılavuzu. Bunlar iki ayrı HA özelliğidir ve Fortinet ikisinin birlikte kullanılamayacağını açıkça belirtir.

FGCP Active-Passive: Aynı model iki FortiGate bir küme oluşturur. FortiAP iki CAPWAP oturumu kurar: aktif FortiGate ile RUN, yedek ile RUN_STANDBY durumunda. Aktif giderse yedek AP’yi devralır; Fortinet’e göre tunnel ve bridge SSID’lerdeki istemciler bağlantıyı korur.
- Bu CAPWAP hitless failover yalnızca FortiAP AX platformlarında ve F serisi modellerde, FortiGate’ler Active-Passive moddayken kullanılabilir.
- Mevcut oturumların korunması için HA ayarlarında session-pickup açılmalıdır. Bu ayar TCP oturumlarını korur; UDP ve ICMP gibi oturumlar da senkronize edilebilir.
- Override ve öncelik ayarları HA ile eşitlenmez, iki cihazda elle yapılır.
Wireless 1+1 fast failover: Yalnızca kablosuz yapılandırmayı (VAP, WTP ve WTP profili) birincilden ikinciye eşitler. VAP’e bağlı VLAN arayüzleri, firewall politikaları ve WPA2/WPA3-Enterprise için tanımlı RADIUS sunucusu eşitlenmez; bunlar ikincide elle tanımlanır ve güncel tutulur. İki FortiGate yönlendirilmiş alt ağlarda olmalı, aradaki trafiğe NAT uygulanmamalı ve AP ikisine de erişebilmelidir. Birincil giderse ikincil AP’yi devralır ve istemci trafik geçirebilir; belge mevcut oturumların korunduğunu yazmaz.

Cisco Meraki: bulut, WAN ve concentrator ayrı arızalardır

Kaynak: Meraki Documentation, Meraki Cloud Architecture, Behavior during Connection Loss to Cisco Meraki Cloud, Secondary MX Concentrator for MR Teleworker VPN ve Configuring RADIUS Authentication with WPA2-Enterprise sayfaları (2026).

Meraki’de yönetim verisi buluta gider, kullanıcı trafiği buluttan geçmez. Bu yüzden üç arıza ayrı ele alınır.

Bulut yönetim erişimi kaybı: AP son bilinen yapılandırmayla çalışmaya devam eder. Meraki’ye göre istemciler genel olarak WLAN’ı kullanmaya devam eder; yerel kaynaklara ve internet bağlantısı varsa internete erişir.
- Yapılandırma değişiklikleri uygulanmaz, kullanım istatistikleri güncellenmez, kanal optimizasyonları çalışmaz.
- Meraki Cloud Authentication kullanan SSID’lerde yeni istemciler, Controller Disconnection Behavior ayarı Restricted ise doğrulanamaz. Varsayılan budur; ayar Open yapılırsa yeni istemciler kabul edilir. Daha önce doğrulanmış istemciler etkilenmez.
- Meraki’nin barındırdığı splash sayfası yeni istemcilere gösterilmez; erişimi aynı ayar belirler; varsayılanı click-through’da Open, sign-on’da Restricted.
- Kendi RADIUS sunucunuzla çalışan 802.1X’te RADIUS istemcisi AP’dir; belge bu durum için bulut kaybına bağlı bir kısıt yazmaz.
- Kesintinin süresi önemlidir. Wi-Fi 6, 6E ve 7 MR’ler 28.1 ve sonraki yazılımlarda Dashboard’a 8 saat ulaşamazsa yapılandırmadan bağımsız olarak yeniden başlar. Bütün SSID’leri NAT modunda olan ve ağ geçidine ARP testini tamamlayamayan bir MR ise 4 saatte bir yeniden başlar. Yeniden başlatma bütün istemcileri koparır.
Yerel WAN ya da internet kaybı: Meraki’ye göre bulut erişimi kaybının en yaygın nedeni budur. Yukarıdaki etkilere internet kaybı eklenir; yerel trafik sürer.
MX concentrator arızası: Tünelli SSID’lerde trafik bir MX concentrator’a gider ve ikincil bir concentrator tanımlanabilir. MR tünelin sağlığını DHCP sondalarıyla izler; zaman aşımı dolunca ikincil tünele geçer, birincil geri gelince trafiği yeniden ona yönlendirir. Bu SSID’lerde RADIUS istemcisi concentrator’dır. Belge, geçişte istemci IP’sinin ve oturumların korunup korunmadığını yazmaz; bu, iki concentrator arkasındaki VLAN ve DHCP tasarımına bağlıdır ve sahada doğrulanmalıdır.

Arıza anından geri dönüşe

Bir arıza beş aşamada yaşanır ve her aşamada başka bir şey sınanır.

Tespit: Arıza bir canlılık mekanizmasıyla anlaşılır: Cisco SSO’da RP ve RMI keepalive’ları, N+1’de AP’nin CAPWAP heartbeat’i, Aruba kümeler arası geçişte birincil kümeye giden bütün tünellerin düşmesi, Meraki concentrator’da DHCP sondaları. Zamanlayıcıları kısaltmak gereksiz geçiş riskini artırır; Huawei, CAPWAP heartbeat değerlerini düşürmeye karşı uyarır.
Devralma: Durumlu modelde yedek hazır tabloyla devralır. Durumsuz modelde AP yeni controller’a katılır, yapılandırmasını alır; imaj uyumsuzsa önce imaj değişimi ya da indirme gerekebilir. Yedeğin kapasitesi ve lisansı burada sınanır.
İstemcilerin yeniden kurulması: Durumu aktarılmayan istemci (SSO’da RUN olmayan istemci gibi) baştan bağlanır. 802.1X’te bu, çok sayıda tam kimlik doğrulamanın aynı anda RADIUS’a gitmesidir; her biri birden çok tur sürer (Wi-Fi 802.1X Neden Başarısız Olur?). Yeni controller anahtar önbelleğini bilmiyorsa hızlı geçiş de işe yaramaz (AP Değiştirirken Wi-Fi Neden Kopar?). RADIUS isteğini controller gönderiyorsa sunucu yedeği de RADIUS istemcisi olarak tanımalıdır.
Bağımlılıklar: Wi-Fi geri gelse bile IP ve oturum ayrıca korunmalıdır.
- DHCP controller üzerindeyse kira bilgisi aktarılıyor mu? Huawei VRRP HSB’de koşula bağlı, dual-link HSB’de hayır.
- Tünel ucu değişince istemci başka bir IP ağına düşüyorsa yeni adres gerekir (Aruba kümeler arası).
- Trafik durumlu bir firewall’dan geçiyorsa oturum tablosu aktarılmadıkça TCP oturumları düşer (FortiGate session-pickup).
- Portal oturumu aktarılmıyorsa kullanıcı yeniden giriş yapar (Huawei dual-link HSB).
Geri dönüş: Otomatik dönüş (preemption, fallback) ikinci bir geçiştir. Durumsuz modelde AP’ler bir kez daha katılır; durumlu modelde senkronizasyon bitmeden dönülürse veri kaybolabilir.
- Huawei VRRP HSB: Preemption gecikmesi kısaysa toplu yedekleme bitmeden dönülür ve hizmet verisi kaybolabilir; Huawei çoğu durumda 30 dakika önerir.
- Huawei N+1: Geri dönüş açıksa AP, birincil geri geldikten 20 heartbeat aralığı sonra birincile yeniden CAPWAP kurar.
- Aruba kümeler arası: Birincil küme 5 dakika (değiştirilemez) çalışır durumda kaldıktan sonra dönülür ve profiller yine 60 saniye kapatılır.
- Fortinet: FGCP’de override açıksa birincil aktif rolü geri alır. Wireless 1+1’de birincil geri gelince AP’yi yeniden yönetir.
- Cisco: N+1’de fallback açıksa AP’ler birincile yeniden katılır. SSO için incelenen belgelerde eski aktifin rolü otomatik geri aldığına dair bir ifade yok; öncelik değeri iki cihaz aynı anda açıldığında hangisinin aktif olacağını belirler.

Otomatik dönüş açıksa ikinci geçiş de kesinti bütçesine katılır; değilse dönüş, birincil kararlı olunca bakım penceresinde elle yapılır.

Tasarım kararı: yedek ne zaman yeterlidir?

Model, kesintinin hangi katmanda kabul edilebildiğine göre seçilir:

İstemcinin yeniden doğrulanması kabul edilmiyorsa: Durum aktaran bir model gerekir: Cisco SSO, Huawei VRRP HSB, Aruba küme içi geçiş ya da session-pickup ile FGCP. Her birinin koşulu yukarıda ayrı ayrı verildi.
Yedek başka bir yerdeyse: Huawei, VRRP HSB ve dual-link HSB’yi uzak felaket kurtarmaya uygun görmez; Cisco SSO 80 ms’nin altında gidiş-dönüş ister; Aruba’nın kümeler arası geçişi hitless değildir.
Kapasite ve lisans: Yedek, devralacağı en büyük AP ve istemci yükünü taşıyabilmelidir.
Sürüm ve yapılandırma: Durumsuz modellerde eşleme tasarımın parçasıdır (Fortinet 1+1’de elle tutulan tanımlar, Cisco N+1’de imaj uyumu).
Bağımlılıklar ve geri dönüş: RADIUS istemci tanımı, DHCP, portal, firewall oturumları ve geri dönüş politikası önceden belirlenir.

Kendinizi deneyin

Alıştırma 1: Bir kampüste birincil Catalyst 9800 controller 300 AP’yi ve mesai saatinde yaklaşık 4.000 istemciyi yönetiyor; istemcilerin hepsi EAP-TLS kullanan kurumsal SSID’de. AP’ler local mode’da, yani istemci trafiği ve RADIUS istekleri controller üzerinden geçiyor. Yedek, başka bir binadaki ve bir önceki yazılım sürümündeki N+1 ikincil controller. Birincil mesai ortasında arızalanıyor. Hangi sırayla ne olur, RADIUS tarafında yük nasıl oluşur ve önceden neler kontrol edilmeliydi? Kesinti süresi tahmin etmeyin; sırayı ve bağımlılıkları yazın.

Cevap ve açıklama

Sıra:
1. AP’ler birincil kaybını CAPWAP heartbeat’iyle anlar.
2. İkincil farklı sürümde olduğu için AP’lerin, üzerlerindeki imaja göre imaj değişimi, indirme ya da yeniden başlatma yapması gerekebilir; bu kesintiyi uzatabilir.
3. AP’ler ikincile katılır, yapılandırmayı alır, SSID yeniden yayına çıkar; 300 AP’nin aynı anda hazır olması beklenmez.
4. N+1 durumsuz olduğu için anahtarlar ikincilde yoktur; 4.000 istemci tam EAP-TLS kimlik doğrulaması yapar.
RADIUS yükü: Her EAP-TLS oturumu birden çok turdur; tur sayısı sertifika zincirine bağlıdır. Oturum başına 8 tur varsayılırsa (ölçüm değil) 4.000 istemci yaklaşık 32.000 Access-Request demektir ve bunlar gün içine değil, AP’lerin katıldığı dakikalara yayılır.
Sessiz hata noktası: RADIUS isteğini artık ikincil gönderir. Sunucuda ikincil, doğru IP ve shared secret ile RADIUS istemcisi olarak tanımlı değilse hiçbir istemci doğrulanamaz; accounting için de aynısı geçerli.
IP: Trafik controller’dan geçtiği için istemci VLAN’ları ikincil tarafta da aynı alt ağlarla bulunmalıdır.
Önceden kontrol: Sürüm ve imaj uyumu, kapasite, lisans, yapılandırma tutarlılığı ve RADIUS kapasitesi.
Geri dönüş ve alternatif: Fallback açıksa aynı yük dönüşte tekrar oluşur. Yeniden doğrulama kabul edilemiyorsa SSO çifti kurulur, N+1 yedek kalabilir.

Alıştırma 2: Wi-Fi 6 Meraki MR’lerden oluşan ve 28.1’den yeni bir MR yazılımı çalıştıran bir ağda üç SSID var:

Kurumsal: bridge modda, kurum içindeki RADIUS sunucusuyla WPA2-Enterprise.
Misafir: Meraki’nin barındırdığı sign-on splash sayfası.
Taşeron: Meraki Cloud Authentication.

Misafir ve taşeron SSID’lerinde Controller Disconnection Behavior Restricted. Bir firewall değişikliği MR’lerin Meraki bulutuna giden yönetim trafiğini engelliyor; yerel ağ, kurum içi RADIUS ve internet çalışıyor. İlk saatte ve dokuzuncu saatte mevcut istemcilere, yeni kurumsal, misafir ve taşeron kullanıcılarına ve Dashboard’dan yapılan bir değişikliğe ne olur?