Core Network Bir Ürün Listesi Değildir

Switch – Firewall – AP seçimi, entegrasyon ve kapasite gerçeği

Kurumsal ağ projelerinin çoğu aynı noktada başlıyor: ürün seçimi. Ve çoğu zaman aynı noktada kırılıyor: ürünlerin birlikte çalışmaması. Çünkü “core network” dediğimiz şey, üç kutunun (switch, firewall, access point) yan yana durması değil; bu üç kutunun birlikte kimlik taşıması, birlikte segment üretmesi, birlikte politika uygulatması ve en önemlisi birlikte operasyon kaldırmasıdır.

Benim yıllardır gördüğüm şu: bir şirketin ağı kötü olduğu için değil, ağın karar mekanizması parçalı olduğu içinproblem yaşanıyor. En pahalı cihazlar, en iyi lisanslar, en yüksek throughput… Hepsi var; ama olay anında kim neyi biliyor, hangi cihaz hangi bağlamla karar veriyor, trafik nerede ayrışıyor, nerede kontrol ediliyor—bu soruların net cevabı yok. Sonuç: “network var” ama “network davranışı” yok.

Bu yazıda core network’ü üç bacakta ele alacağım: Firewall, Switching, Access (Wi-Fi). Ama başlamadan önce bir şeyi net koymak istiyorum: seçim sürecinde “teknik özellik” kadar belirleyici olan iki faktör var ve çoğu ekip bunları geç fark ediyor: raporlar/validasyon ve support/lifecycle.

Raporlar, testler ve “pazarlama gürültüsü”nü filtrelemek

Ürün seçerken bakılacak yerlerden biri, evet, Gartner raporları. Çünkü Gartner gibi raporlar sana bir ürünün “pazardaki konumu” hakkında fikir verir: kim lider, kim vizyoner, kim niş oynuyor. Bu özellikle karar verici tarafı ikna etmekte işe yarar; bütçe masasında “neden bu marka?” sorusuna bir çerçeve sunar.

Ama burada kritik bir tuzak var: Gartner sana senin senaryonda hangisinin doğru olduğunu söylemez. Gartner bir “pazar haritası”dır; senin işin “mimari harita” çizmek. Bu yüzden Gartner’ı bir ilk filtre gibi kullanmak daha doğru: seçenekleri daraltır ama final kararı vermez.

Gartner’a ek olarak, üreticilerin ya da bağımsız laboratuvarların yaptığı performans ve güvenlik testleri, karşılaştırmalı raporlar, “real-world” benchmark’lar da işin içine girmeli. Çünkü veri sayfasındaki throughput ile, gerçek hayatta IPS açıkken, SSL decrypt varken, app-control çalışırken alınan throughput aynı şey değildir. Raporlar burada bir ikinci filtre olur: “Bu kutu bu yükte ne yapıyor?” sorusuna pazarlama dışı bir cevap ararsın.

Support ve lifecycle: Projeyi ayakta tutan görünmez kolon

Bir ürünün teknik yetenekleri kadar kritik olan şey, onun destek modeli ve yaşam döngüsüdür. Çünkü network tasarımı yalnızca “kurulum günü”nden ibaret değildir. Asıl mesele 3 yıl sonra ne olacağıdır:

• Bu ürünün EoL / EoS tarihleri nedir?
• Patch, bugfix, security update hızı nasıldır?
• TAC/Support gerçekten erişilebilir mi, escalation süreci nasıl işler?
• RMA süreçleri ve yedek parça gerçekliği nedir?
• Lisans modeli 1 yıl sonra sürpriz çıkarır mı?
• Üretici roadmap’i senin gittiğin yöne mi gidiyor?

Bunu yazıya özellikle koymak istiyorum çünkü sahada en sık gördüğüm problem şu: ekip teknik olarak doğruya yakın bir ürün seçiyor ama support/lifecycle yüzünden 12 ay sonra operasyon kâbusa dönüyor. Sonra suç cihazda kalıyor; oysa sorun cihazın kendisinden çok, seçimin “destek” tarafının ciddiye alınmamasıdır.

Firewall: UTM mi, NGFW mi, yoksa birden fazla rol mü?

Firewall, günümüzde ağın “kenarındaki güvenlik cihazı” olmayı çoktan geçti. Doğru konumlandırılırsa politika beynidir; yanlış konumlandırılırsa her şeyin üstüne yıkıldığı için darboğaz olur.

Burada en baştan terminolojiyi netlemek iyi olur: UTM ve NGFW kavramları çoğu ortamda birbirine karışıyor.

UTM yaklaşımı genelde “her şey tek kutuda” düşüncesine yakın durur: temel firewall + IPS + web filter + AV + bazı gateway özellikleri… Özellikle daha küçük/orta ölçekli yapılarda, yönetim kolaylığı ve paket yaklaşımı yüzünden tercih edilir.

NGFW ise daha çok uygulama farkındalığı, kullanıcı/kimlik farkındalığı, daha gelişmiş security services ve policy derinliğiyle konumlanır. Bugünün kurumsal ihtiyacında “sadece port-protocol” ile güvenlik yürütmek çoğu zaman yetmez; NGFW burada devreye girer.

Ama asıl kritik nokta şu: bir şirketin ihtiyacı tek bir “firewall tipi” ile bitmeyebilir. Çünkü firewall dediğimiz şey, aslında farklı amaçlar için farklı katmanlarda görev alabilir.

Aynı şirkette iki (hatta üç) firewall neden normaldir?

Birçok kurumda şu senaryolar çok makuldür:

• Perimeter/Internet Edge Firewall: İnternet çıkışı, VPN, NAT, inbound/outbound policy.
• Internal Segmentation Firewall (ISFW): İç ağda segmentasyon, east-west kontrol, kritik zonlar.
• Data Center / High-performance FW: DC trafiği, yüksek session, yüksek PPS, düşük latency ihtiyacı.
• Bazı yapılarda ayrıca WAF ya da Cloud FW gibi özel bileşenler.

Bu “iki firewall almak” demek değildir; bu, “iki farklı işi doğru araca vermek” demektir. Tek kutuya her şeyi yığdığında, ya performans kaybedersin ya yönetim kaybedersin ya da güvenlik kaybedersin. Genelde üçünden biri mutlaka gider.

Ve bu bizi doğrudan kapasite planlamasına götürür.

Firewall kapasite planlaması: Throughput tek başına yalan söyleyebilir

Firewall seçiminde en tehlikeli yanlış, yalnızca “Gbps throughput” rakamına bakmaktır. Çünkü gerçek hayatta firewall’u öldüren şey çoğu zaman throughput değil:

• PPS (packets per second)
• Concurrent session sayısı
• New session rate
• NAT table ve state
• IPS/AV/App-ID açıkken performans
• SSL/TLS decrypt gibi ağır iş yükleri
• Log üretimi ve log’u taşımak (SIEM entegrasyonu)

Örnek bir gerçek: “10 Gbps firewall aldık” cümlesi tek başına anlam taşımaz. Çünkü o 10 Gbps, çoğu vendor datasheet’inde “ideal koşul” ölçümüdür. Senin ortamında IPS, URL filtering, app control, decrypt aktifse; gerçek kapasite dramatik şekilde değişir. Bu yüzden doğru soru şu olmalı: “Benim açacağım güvenlik özellikleriyle, benim trafik karakterimde, bu firewall ne kadar iş kaldırıyor?”

Bu sorunun cevabı yoksa, seçim risklidir.

Switching: Port sayısından çok, taşıyabileceği yük ve rolü önemlidir

Switch seçimi çoğu zaman port sayısıyla başlar: kaç adet bakır port, kaç adet fiber port, PoE ihtiyacı var mı yok mu… Bunlar elbette önemlidir ama core network perspektifinden bakıldığında yeterli değildir. Çünkü switch yalnızca uçları bağlayan bir priz değildir; trafiğin nerede yoğunlaşacağını, nerede ayrışacağını ve nerede yukarı taşınacağınıbelirleyen bir karar noktasıdır.

Özellikle access switch tarafında yapılan en yaygın hata, bugünkü ihtiyaca göre port planlaması yapmaktır. Oysa access katmanı, ağda en hızlı değişen katmandır. Bugün bakır port yeterli görünen bir noktada, yarın yüksek bant genişliği isteyen bir AP, bir kamera ya da farklı bir edge cihaz konumlanabilir. Bu yüzden bakır portların hız kabiliyeti (1G mi, 2.5G/5G mi destekliyor), PoE bütçesinin yalnızca toplam watt değil port başına sürdürülebilirliği ve uplink’lerin gerçek kapasitesi kritik hale gelir.

Uplink konusu genellikle hafife alınır. “2×10G uplink yeter” gibi cümleler çok duyulur ama bu uplink’lerin hangi trafik karakterini taşıyacağı çoğu zaman konuşulmaz. Access katmanında kullanıcı sayısı arttıkça, east-west trafik ve broadcast davranışı değiştikçe, uplink’ler beklenenden çok daha hızlı doygunluğa ulaşabilir. Bu noktada yalnızca uplink hızına değil, switch’in backplane kapasitesine ve oversubscription oranlarına bakmak gerekir. Çünkü uplink 10G olabilir ama switch içindeki mimari bunu sürdüremiyorsa, darboğaz yine kaçınılmazdır.

Edge switch ile datacenter switch arasındaki fark da çoğu projede net çizilmez. Edge switch’ler genellikle kullanıcı ve cihaz yoğunluğu için optimize edilir: çok sayıda port, PoE, erişim odaklı özellikler. Datacenter switch’ler ise yüksek throughput, düşük latency, yüksek PPS ve east-west trafiği kaldıracak mimariyle gelir. Bu iki rolü aynı cihazdan beklemek çoğu zaman ya maliyeti gereksiz artırır ya da performansı beklenenin altına çeker. Core network tasarlarken “bu switch nerede duracak ve neyi taşıyacak?” sorusu, “kaç portu var?” sorusundan önce gelmelidir.

Inter-VLAN routing kararları da switch seçimiyle doğrudan ilişkilidir. Eğer routing switch üzerinde yapılacaksa, bu switch’in yalnızca L3 desteklemesi yetmez; route scale, TCAM kapasitesi, policy uygulanabilirliği ve bu kararların firewall ile nasıl entegre olacağı düşünülmelidir. Aksi halde, ilk etapta performans kazancı gibi görünen bir tasarım, ileride yönetilemeyen bir karmaşaya dönüşebilir.

ACCESS / AP

Access / Wi-Fi: Radyo kadar uplink ve kontrol katmanı da mimarinin parçasıdır

Kablosuz ağlar konuşulurken odak genellikle Wi-Fi standardına kayar: Wi-Fi 6, 6E, 7… Oysa pratikte kablosuz performansı sınırlayan şey çoğu zaman hava değil, kablodur. Access point ne kadar güçlü olursa olsun, arkasındaki uplink bunu taşıyamıyorsa teorik hızlar hiçbir anlam ifade etmez.

Bugün pek çok kurumsal AP, 1 Gbps uplink ile sınırlandığında potansiyelinin ciddi bir kısmını kullanamaz. Bu yüzden 2.5G ve 5G bakır uplink desteği, özellikle yoğun kullanıcı olan ortamlarda bir “lüks” değil, doğrudan tasarım gereksinimidir. Ancak burada da zincir kopmamalıdır: AP 2.5G destekliyor olabilir ama bağlandığı switch portu bunu desteklemiyorsa, tüm yatırım boşa gider. AP ve switch seçimi bu yüzden ayrı ayrı değil, birlikte yapılmalıdır.

Wi-Fi tarafında bir diğer kritik konu, controller mimarisidir. Controller’ın desteklediği AP sayısı, eş zamanlı client kapasitesi ve roaming davranışı, ağın gerçek hayattaki stabilitesini belirler. Kağıt üzerinde “500 AP destekler” yazan bir controller, yüksek yoğunluklu, hızlı roaming gereken bir ortamda beklenenden çok daha erken zorlanabilir. Controller kapasitesi yalnızca lisans sayısı değil; CPU, bellek, session handling ve policy enforcement kapasitesiyle birlikte değerlendirilmelidir.

Ayrıca kablosuz ağlar çoğu zaman “edge” gibi düşünülür ama gerçekte core network’ü en hızlı zorlayan katmandır. Kullanıcılar hareketlidir, bağlantılar sık sık kopup yeniden kurulur, kimlik doğrulama ve policy uygulama döngüsü kabloluya göre çok daha yoğundur. Bu yüzden access katmanında yapılan küçük bir tasarım hatası, core network’te beklenmeyen yükler yaratır. AP seçimi yalnızca kapsama alanı hesabı değil; core network davranışını doğrudan etkileyen bir mimari karardır.

Kapanış: Üretici Seçimi, Mimari Olgunluk ve Gerçekler

Bu noktada şunu özellikle belirtmek istiyorum: aşağıda bahsettiklerim tamamen kişisel saha tecrübelerime ve gözlemlerime dayanıyor. Bir üreticiyi övmek ya da yermekten çok, nerede güçlü olduklarını ve nerede zorlandıklarınıaçıkça söylemek niyetindeyim. Çünkü core network tasarımı, marka fanatizmiyle değil; gerçek ihtiyaçlar ve operasyonel gerçeklerle yapılır.

Cisco ile başlamak doğal. Switching ve routing tarafında hâlâ sektörün en güçlü oyuncularından biri. Özellikle büyük ve karmaşık yapılarda, campus ve datacenter switching konusunda ciddi bir olgunlukları var. Wireless tarafında da uzun yıllardır güçlüler; bu alanda ciddi bir ekosistem ve deneyim birikimi mevcut. Firewall tarafında ise özellikle Asya pazarından sonra ve Power gibi satın almalarla birlikte ciddi bir gelişim gösterdiler; NGFW tarafında artık daha rekabetçi bir konumdalar.
Ancak şunu net söylemek gerekir: tüm ürünleri Cisco seçtiğinizde, bu ürünlerin birbiriyle entegrasyonu çoğu zaman bir admin için yorucu ve zahmetli olabiliyor. Her şey mümkün ama çoğu zaman “kolay” değil; entegrasyon tarafında ciddi emek ve deneyim istiyor.

Yaklaşık on yıldır gelişimini yakından izlediğim HPE Aruba tarafı ise farklı bir hikâye sunuyor. Ben bu ekosisteme ilk girdiğimde ürün yelpazesi oldukça sınırlıydı. Zamanla HP tarafının Aruba satın almalarıyla portföy genişledi; bugün gelinen noktada Juniper ürün ailesinin de eklenmesiyle yelpaze ciddi şekilde büyüyor. Switching tarafında Aruba ailesi oldukça yaygın ve sevecen bir kullanıcı kitlesine sahip. Wireless tarafında ise Aruba kökenli altyapının da etkisiyle, benim kişisel görüşüm, sektördeki en güçlü Wi-Fi çözümlerinden birine sahipler.
Routing tarafında geçmişte eksikler vardı; fakat Juniper ürün ailesiyle bu boşluğun büyük ölçüde kapanacağını düşünüyorum. Buna karşın, kendi başına güçlü bir firewall ürün ailesinin olmaması, bu alanda bir miktar eksik kalmalarına sebep oluyor.

Fortinet tarafı ise çok geniş bir ürün yelpazesi sunuyor. Firewall, switching ve wireless tarafında “tek çatı altında” komple bir çözüm sunabilmeleri, birçok kurum için ciddi bir avantaj. Fortinet’in kökeninin güvenlik olması sebebiyle firewall tarafında oldukça güçlü oldukları biliniyor. Switching ürün ailesi nispeten daha geç olgunlaşmaya başladı; bu yüzden yaygınlaşması zaman aldı ama son yıllarda sahada daha sık görmeye başladık.
Fortinet ekosisteminin bana göre en büyük artılarından biri, kullanım ve arayüz kolaylığı. Ürünlerin birbirine entegrasyonu görece daha az sancılı ve bu da operasyonel yükü ciddi şekilde azaltabiliyor. Özellikle sınırlı IT ekibi olan kurumlarda bu fark çok net hissediliyor.

Palo Alto Networks tarafına geldiğimizde tablo daha net: Palo Alto, firewall konusunda çok güçlü ve bu alanda tartışmasız şekilde lider üreticilerden biri. Ancak switching ya da wireless gibi alanlara bilinçli olarak girmiyorlar; zaten odakları da bu değil. Birçok kurum Palo Alto’yu yalnızca firewall tarafında tercih ediyor ve bunun çok mantıklı sebepleri var.
Application visibility, policy derinliği ve özellikle SASE gibi alanlarda Palo Alto’nun ciddi bir fark yarattığını düşünüyorum. Bugün dünyanın en büyük siber güvenlik üreticilerinden biri olmaları da tesadüf değil. Firewall tarafında “en iyisini” arayan birçok kurumun Palo Alto’ya yönelmesi gayet doğal.

Gerçek hayatta şirketler bu üç temel ürün grubu için çok farklı seçimler yapabiliyor. Bazı kurumlar tek bir üreticiyleilerlemeyi tercih ediyor: switch, wireless ve firewall aynı markadan olsun; entegrasyon ve destek tek noktadan gelsin, sorun çıktığında muhatap belli olsun istiyorlar. Bazı kurumlar ise firewall tarafında bir üretici, switch ve wireless tarafında başka bir üretici kullanıyor. Hatta daha olgun yapılarda, her katmanı farklı üreticilerden seçmek de sık görülen bir durum.

Bu tercihler çoğu zaman teknik olduğu kadar organizasyonel. Kurumun IT’ye bakışı, ekip yapısı, network ekibindeki kişilerin alışkanlıkları ve geçmiş deneyimleri bu kararları ciddi şekilde etkiliyor. Burada tek bir doğru yok.
Benim kişisel görüşüm şu: her alanda kendini daha fazla ispatlamış üreticiler var ve eğer IT ekibi bu ayrımı yönetebilecek olgunluktaysa, farklı katmanları farklı üreticilerden seçmek teknik olarak çok daha güçlü sonuçlar üretebiliyor. Öte yandan, bazı kurumlar entegrasyon sorunları, kurulum karmaşası ve konfigürasyon hatalarıyla uğraşmak istemediği için tek üreticiyle ilerleyip, tüm sorunları tek bir destek kanalından çözmeyi tercih edebiliyor. Bu da tamamen geçerli bir yaklaşım.

Son olarak özellikle altını çizmek istediğim bir nokta var: günümüzde neredeyse tüm büyük üreticiler otomasyon tarafına ciddi yatırım yapıyor. Bu noktada ürünlerin API desteği artık bir “ekstra” değil, doğrudan bir seçim kriteri. API üzerinden nelerin yapılabildiği, neyin otomatikleştirilebildiği, entegrasyonun ne kadar açık olduğu; ürün seçerken mutlaka masada olmalı.

İlk yazımda da bahsettiğim gibi, bence ürün seçimi yapılırken otomasyon süreçleri sonradan eklenen bir katman olarak düşünülmemeli. Aksine, piramidin en üstüne otomasyon ve operasyonel süreçler konulmalı; ürünler bu çerçeveye göre seçilmeli. Hangi switch, hangi firewall, hangi AP sorusu; “bu mimariyi nasıl otomatik yöneteceğim?” sorusundan sonragelmeli. Bana göre doğru core network tasarımı tam olarak burada başlar.

Sistem Odası ve Kablolama: Kimsenin Konuşmak İstemediği Ama Herkesin Bedelini Ödediği Gerçek

Network projelerinde en çok konuşulan konular genelde en “parlak” olanlardır: hangi switch, hangi firewall, hangi wireless çözümü… Ama sahada yaşanan problemlerin önemli bir kısmı, bu ürünlerden çok daha temel bir yerde başlar: sistem odası tasarımı ve kablolama altyapısı.

Benim yıllar içinde defalarca gördüğüm bir gerçek var: ne kadar iyi ürünler seçersen seç, ne kadar doğru mimari kurgularsan kurgula; eğer sistem odası ve kablolama altyapısı zayıfsa, o ağ eninde sonunda problem üretir. Ve bu problemler genelde “network arızası” gibi görünür ama kök sebep hiçbir zaman gerçekten network değildir.

Sistem odası çoğu kurumda hâlâ bir “eşya odası” gibi ele alınıyor. İlk başta küçük bir alana birkaç rack konuyor, işler büyüdükçe aynı odaya yeni cihazlar ekleniyor, kablolar üst üste geliyor, geçici çözümler kalıcı hale geliyor. Bir noktadan sonra kimsenin dokunmak istemediği, ama herkesin bağımlı olduğu bir alan oluşuyor. İşte asıl risk tam burada başlıyor.

Bir sistem odası yalnızca cihazların durduğu bir yer değildir. O oda, ağın kalbidir. Isı, enerji, hava akışı, erişilebilirlik ve düzen; hepsi birlikte düşünülmelidir. Örneğin soğutma konusu çoğu zaman geç fark edilir. Cihazlar çalışıyor gibi görünür ama sürekli yüksek sıcaklıkta çalışmak, hem performansı hem de donanım ömrünü ciddi şekilde etkiler. Ani reboot’lar, beklenmeyen donmalar ya da “zaman zaman yaşanan” hataların arkasında çok sık şekilde yetersiz soğutma çıkar.

Enerji tarafı da benzer şekilde hafife alınır. Yedekli güç kaynakları olan cihazlar alınır ama bu güç kaynaklarının gerçekten farklı enerji hatlarına gidip gitmediği kontrol edilmez. UPS var denir ama kapasite hesabı yapılmaz. Elektrik kesildiğinde sistemlerin ne kadar süre ayakta kalacağı net değildir. Bunlar kağıt üzerinde küçük detay gibi görünür ama kriz anında tüm mimariyi anlamsız hale getirir.

Kablolama altyapısı ise genelde “bir kere yapılır ve unutulur” diye düşünülür. Oysa kablolama, network’ün en uzun ömürlü parçasıdır. Switch’i, firewall’u, access point’i değiştirirsin; ama kablo orada kalır. Bu yüzden yapılan en büyük hatalardan biri, bugünkü ihtiyaca göre kablolama yapmaktır. Bugün 1G yeterli diye planlanan bir altyapı, yarın 2.5G/5G uplink isteyen AP’lerle veya daha yüksek hız gerektiren edge cihazlarla ciddi bir sınıra dayanır.

Fiber ve bakır kabloların nerede, hangi amaçla kullanılacağı da mimari bir karardır. Sadece “fiber daha hızlıdır” diye her yere fiber çekmek de doğru değildir; bakırın avantajlı olduğu, PoE gerektiren ya da kısa mesafeli bağlantılar hâlâ çoktur. Asıl mesele, kablolamanın gelecekteki genişlemeye izin verecek şekilde tasarlanmasıdır. Patch panel düzeni, kablo etiketleme, rack içi ve rack arası kablo yönetimi… Bunlar estetik değil, doğrudan operasyonel konulardır.

Kötü etiketlenmiş bir kablolama altyapısında yapılan her değişiklik risktir. Bir portu kapatırken yanlış cihazı etkilersin, bir kabloyu sökerken başka bir servisi düşürürsün. Sonra bu “network yine gitti” diye konuşulur. Oysa problem network değil, yıllar önce yapılan özensiz kablolamadır.

Sistem odasının erişim güvenliği de çoğu zaman göz ardı edilir. Kimlerin bu odaya girebildiği, kimin hangi saatlerde erişimi olduğu, yapılan değişikliklerin nasıl kayıt altına alındığı net değilse; en iyi güvenlik politikaları bile bir noktada anlamını yitirir. Fiziksel erişimi kontrol edemediğin bir ortamda, mantıksal güvenliği konuşmak çoğu zaman teoride kalır.

Benim bakış açıma göre sistem odası ve kablolama, core network tasarımının “alt katmanı” değildir; temelidir. Üzerine ne kadar sofistike çözümler koyarsan koy, temel zayıfsa yapı sallanır. Bu yüzden network tasarlarken yalnızca diyagramlara değil, o diyagramların hayata geçeceği fiziksel ortama da bakmak gerekir. Rack düzeni, kablo yolları, enerji ve soğutma planı; bunların hepsi mimarinin bir parçasıdır.

Bu konular genelde heyecan verici değildir, sunumlarda çok yer kaplamaz, CV’ye yazması zordur. Ama gerçek şu ki, iyi çalışan bir network’ün arkasında çoğu zaman iyi tasarlanmış bir sistem odası ve temiz bir kablolama altyapısı vardır. Kimse bunu fark etmez; çünkü zaten sorun çıkmaz. Ve bana göre bu, bir altyapı tasarımının alabileceği en büyük övgüdür.

Bu makale ilk olarak Substack’te daha kısa, anlatısal bir biçimde yayınlanmıştı.

Bu versiyon, serinin mimari temelini genişletiyor.

👉 Makaleyi Substack’te okuyun: Burayı Tıklayın