L2 ve L3 Roaming — IP Adresi Korunmazsa Geçiş Kopmaya Dönüşür

Sorun nerede başlar?

802.11 geçişi yalnızca istemcinin hangi AP'ye bağlı olduğunu değiştirir. İstemcinin IP adresi, varsayılan ağ geçidi ve açık TCP/UDP oturumları ise ağ katmanında yaşar. Yeni AP, istemciyi eskisiyle aynı VLAN ve alt ağa yerleştiriyorsa geçiş L2 roaming'dir: IP adresi korunur, uygulama yalnızca kısa bir paket boşluğu yaşar. Yeni AP farklı bir alt ağa bağlıysa ve ağ bunu telafi etmiyorsa istemci yeni bir DHCP adresi almak zorunda kalır; bu, açık oturumların kopması demektir.

Büyük kampüslerde her binanın veya katın ayrı bir alt ağa sahip olması yaygındır. Kablolu ağ için mantıklı olan bu yapı, kablosuz istemciler binalar arasında yürüdüğünde L3 sınırlarının aşılmasına neden olur.

L2 roaming: aynı VLAN, basit ama sınırlı

En basit çözüm, kablosuz istemci VLAN'ını tüm AP'lerin erişebildiği tek bir yayın alanı haline getirmektir. Kontrolcü tabanlı mimarilerde trafik kontrolcüye tünellendiği için istemciler AP'nin bulunduğu kablolu alt ağdan bağımsız olarak aynı VLAN'da kalır. Dağıtık (yerel köprüleme yapan) mimarilerde ise aynı VLAN'ın tüm erişim anahtarlarına taşınması gerekir. Bu yaklaşım büyüdükçe yayın trafiği, ARP ve çok noktaya yayın yükü artar; çok büyük yayın alanları ayrı bir risk haline gelir.

L3 roaming: alt ağ değişse de adres korunur

L3 roaming'de istemci farklı bir alt ağa bağlı AP'ye geçse bile orijinal IP adresini korur. Bunu sağlamanın yaygın yolu, istemcinin trafiğini ilk bağlandığı noktaya (ev/anchor) geri tünellemektir: yeni kontrolcü veya AP, istemcinin trafiğini eski noktaya iletir ve istemci aynı alt ağdaymış gibi davranır. Üreticiler bu işlevi mobilite grubu, anchor, tünel veya overlay adlarıyla uygular. Bazı modern mimariler ise VXLAN tabanlı yapı (fabric) ile istemcinin konumundan bağımsız kimlik ve adresleme sağlar.

DHCP, ARP ve güvenlik duvarı etkisi

• Geçiş sonrası istemci DHCP yenilemesi yapıyorsa ve sunucu yavaşsa kesinti, kablosuz geçişten değil DHCP'den kaynaklanır.
• ARP önbelleklerinin ve anahtarların MAC tablolarının güncellenmesi gecikirse ilk paketler eski porta gider.
• Durum tutan (stateful) güvenlik duvarları, trafiğin farklı bir yol izlemesi halinde oturumu tanımayıp düşürebilir.
• Rol veya VLAN atamasını RADIUS yapıyorsa, farklı AP'lerde farklı politikanın uygulanmadığı doğrulanmalıdır.

Kontrolcü tabanlı ve dağıtık mimaride fark

Merkezi kontrolcü mimarisinde AP'ler istemci trafiğini kontrolcüye tüneller ve istemcinin VLAN'ı kontrolcüde sonlanır. Bu, AP'nin hangi kablolu alt ağda olduğundan bağımsız olarak istemcinin aynı alt ağda kalmasını kolaylaştırır. Bedeli, tüm trafiğin kontrolcüden geçmesi ve kontrolcünün kapasite ve yedeklilik açısından kritik bir nokta haline gelmesidir.

Dağıtık mimaride ise AP trafiği doğrudan bağlı olduğu anahtara köprüler. Bu verimlidir ama istemcinin IP adresini korumak için ya aynı VLAN'ın tüm erişim katmanına taşınması ya da üreticinin dağıtık mobilite mekanizmalarının kullanılması gerekir. Bulut yönetimli birçok platform bu iki yaklaşımı birlikte sunar; hangi SSID'nin tünellendiği ve hangisinin yerel köprülendiği tasarımda açıkça belgelenmelidir.

Fabric ve overlay yaklaşımı

Kampüs ağlarında giderek yaygınlaşan fabric mimarileri, istemcinin kimliğini ve politikasını fiziksel konumdan ayırır. İstemci hangi erişim noktasından bağlanırsa bağlansın, overlay ağ onu aynı sanal ağda ve aynı politika grubunda tutar. Bu yaklaşım L3 roaming sorununu mimari düzeyde çözer, ancak tasarım, işletme ve sorun giderme becerisi gerektirir. Kablosuz ekibin, fabric kontrol düzleminin istemci konum güncellemesini ne kadar hızlı yaptığını da ölçmesi gerekir.

Hangi yaklaşım seçilirse seçilsin temel ilke aynıdır: istemcinin hareket ettiği alanlar boyunca IP adresi ve politika korunmalı, geçiş anında kablolu tarafta trafiğin yeni konuma yönlendirilmesi hızlı olmalıdır.

Doğrulama adımları

• Yürüyüş testinde istemcinin IP adresini ve ağ geçidini geçiş öncesi ve sonrası kaydedin.
• Geçiş sonrası DHCP Discover/Request görülüp görülmediğini paket yakalamasında kontrol edin.
• Ses veya uygulama oturumunun aynı kalıp kalmadığını uygulama günlüklerinden doğrulayın.
• Binalar arası ve kontrolcüler arası geçişleri ayrıca test edin; en sık sorun bu sınırlarda çıkar.

Çok noktaya yayın ve keşif protokolleri

Geçiş sonrası yalnızca tekil trafik değil, çok noktaya yayın trafiği de yeniden kurulmalıdır. Sesli iletişim sistemlerinde bas-konuş (push-to-talk) gibi grup yayınları, istemci yeni AP'ye geçtiğinde ilgili gruba yeniden katılmayı gerektirir. IGMP bildirimlerinin gecikmesi, istemcinin bir süre grup yayınını alamamasına neden olur. Benzer şekilde mDNS gibi keşif protokolleri, istemcinin farklı bir alt ağa veya farklı bir politika grubuna geçmesi halinde yazıcı ve ekran paylaşımı gibi servisleri göremez hale gelebilir.

Bu nedenle L2/L3 roaming tasarımında yalnızca IP adresinin korunması değil, çok noktaya yayın grupları ve servis keşfi politikalarının da yeni konumda doğru uygulanması doğrulanmalıdır.

Kısa özet

Kablosuz geçişin hızlı olması yetmez; istemcinin IP adresi, politikası ve çok noktaya yayın grupları da yeni konumda korunmalıdır. L2 veya L3 yaklaşımı, binanın büyüklüğüne ve kullanıcıların hareket desenine göre seçilir ve yürüyüş testiyle doğrulanır.

Konuk ve cihaz ağlarında durum

Konuk ağları çoğu zaman güvenlik nedeniyle ayrı bir bölgeye tünellenir ve istemci her zaman aynı noktada sonlanır; bu, binalar arası geçişte IP adresinin korunmasını kolaylaştırır. Nesnelerin interneti cihazları ise genellikle sabittir, ancak tıbbi arabalar veya mobil robotlar gibi hareketli cihazlar varsa bu cihazların ağı da mobilite tasarımına dahil edilmelidir. Her SSID için trafiğin nerede sonlandığı, hangi VLAN'a düştüğü ve hangi alanda hareket ettiği tek bir tabloda belgelenmelidir. Bu tablo, sorun gidermede ilk bakılacak belgedir ve ağ büyüdükçe güncel tutulmalıdır.

Tasarım önerisi

Önce istemcilerin gerçekten hangi alanlarda yürüyerek dolaştığını belirleyin: koridorlar, depolar, hastane katları ve binalar arası geçişler. Bu alanların tamamı tek bir mobilite alanı içinde olmalı ve istemcinin IP adresi korunmalıdır. Sabit kullanıcıların bulunduğu ve binalar arası hareketin olmadığı yapılarda alt ağları bölmek sorun yaratmaz. Tasarımın doğrulaması, geçiş sırasında istemcinin IP adresinin değişmediğini ve ses/uygulama oturumunun sürdüğünü gösteren yürüyüş testleriyle yapılır.

Son olarak, geçiş sürecinde "kablosuz kısım hızlı ama uygulama yine kopuyor" şikayetinin büyük bölümü bu katmanda ortaya çıkar. Kablosuz ve kablolu ekiplerin geçişi birlikte incelemesi, kök nedeni bulmanın en hızlı yoludur.