Daha önce SD-WAN ile ilgili üretici bağımsız olarak bir yazı yazmıştım. Merak edenler https://gblogs.cisco.com/tr/sd-wan-uzerine/ adresinden ulaşabilirler.

Bu defa ise Cisco’nun iki SD-WAN çözümünden biri olan Meraki SD-WAN  hakkında bir şeyler yazmak istedim. Aslında Meraki SD-WAN Türkiye’de en fazla uç ofiste kullanılan SD-WAN çözümü. Bu yüzden belki de bu yazıyı yazmakta geç kaldım.

Ben SD-WAN üreticilerini router’cılar, firewall’cular, optimizasyon’cular ve doğuştan SD-WAN startup’lar olarak dört gruba ayırıyorum. Meraki bu gruplardan firewall’cular grubunun bir temsilcisi.

Meraki MX ürün ailesi markette bilinen adıyla bir UTM ürünü aslında. Yani L4/L7 firewall, IDS/IPS, anti-malware, content filtering gibi özellikleri bir arada bulunduran bir çözüm. SD-WAN ise Meraki MX’in Auto VPN özelliğinin üzerine inşa edilmiş durumda.

Bundan sonrasını bir senaryo ile açıklayalım….

Diyelim ki; merkez ve ODM için yedekli ve 100 adet uzak ofis için birer adet olmak üzere 104 adet MX firewall sipariş ettik. Ürünler gönderim için hazırlanıyor. Biz meraki.cisco.com üzerinden şirketimiz için bir hesap açarak ayarlamalarımıza başlayabiliriz. Sipariş numaramızı da Meraki Dashboard’ta girerek bize gönderilen tüm cihazları seri numaralarıyla birlikte envanterimize eklemiş oluruz.

 İlk 2 dakika….

Öncelikle merkez ve ODM için birer network tanımlıyoruz. IP, VLAN vb ayarlarını yaptıktan sonra cihazların VPN’deki rolünü seçiyoruz. Doğal olarak bunlar Hub modunda çalışacaklar. Sonrasında da VPN’e dahil olacak subnet’lerini seçiyoruz. Ve bitti. IP adresleri elinizin altındaysa ve fare kullanmayı yeni öğrenmediyseniz iki Hub’ın tüm ayarlamaları maksimum 1-2 dk

Uç noktalar için en mantıklı yöntem

Gelelim uç noktalara. Yüz adet uç noktanın ayarlamalarını tek tek yapmamak için en mantıklı yöntem Meraki şablonlarını kullanmak. Dolayısıyla şablonda değişiklik yapınca, şablona bağlı tüm network’lerde ayarlamalar değişmiş olacak. Bir network şablonu oluşturup yine ilk olarak bu şablondaki IP, VLAN, vb. ayarlamaları yapacağız. Bu defa biraz farklı. Her uç noktanın IP bloğu birbirinden farklı olduğu için “unique” adresleme kullanacağız. Büyük bir subnet vereceğiz ve Meraki’nin rastgele bir şekilde yüz network’e IP subnet atamasını bekleyeceğiz. (Uç noktalarımızda daha önceden belli ve değişemeyecek subnet’ler varsa bunları her network için manuel olarak değiştirmek gerekecek).

Gelelim VPN’e

Daha sonra yine şablonun içinde uç noktalarımızın VPN rolünü “spoke” olarak belirliyoruz. Birincil ve ikincil hub olarak da Merkez ve ODM network’lerini seçiyoruz. Internet trafiğini merkezden ya da lokalden çıkarma durumu için default route alıp almama kararını veriyoruz. Son olarak VPN’e dahil olacak subnet’leri seçtiğimizde tanımlamalarımız sona ermiş oluyor. Yani toplam birkaç dakika içerisinde iki hub ve yüz spoke’tan oluşan VPN tanımlamalarımız bitti

Şimdi şablonumuz üzerinden uç lokasyonlarımıza uygulama ve performans tabanlı yönlendirmelerimizi tanımlayabiliriz. Öncelikle uygulamalarımız için performans kriteri belirliyoruz. Mesela SAP Hana uygulamamız 50ms gecikmeye duyarlı olsun. Ve bir de 8080 portundan çalışan proxy sunucumuz için %5 paket kaybını eşik değerimiz olarak belirleyelim.

Daha sonra diyelim ki; SAP Hana WAN-1 hattından çalışsın ve 50ms gecikme aşılırsa WAN-2’ye dönsün. Proxy ise load-balancing çalışsın ve %5 paket kaybını her iki hat sağladığı sürece ikisini birden kullansın. Eğer biri bu eşiği aşarsa hangisi sağlıyorsa oradan gitsin.  Sanırım bu kısım da IP adreslerini yazmak dahil 1-2 dk civarı sürdü:)

10 dakikadan bile az bir sürede….

Şu anda; sıfırdan tüm tanımlamalarıyla 102 lokasyonlu yapımızın tüm konfigürasyonu 10 dakikadan az bir sürede bitti. Artık siparişin gelmesini bekleyebiliriz

Ürünler gelmeden uç noktalarla seri numarası eşleştirmelerini yapalım. Hem bunu Dashboard’a yükleyip bir defada 100 network’ü açalım ve hepsini şablonumuza bağlayalım, hem de bu listeyi siparişi geçtiğimiz entegratör veya distribütör firmaya gönderelim. Onlar da uç noktaların cihazlarını bize göndermek yerine doğrudan sahaya göndersinler. Harika fikir

Ve büyük gün!

Cihazlar teslim edildi. Merkez cihazlarımıza manuel olarak WAN IP’lerini verdik. DHCP kullanmıyoruz çünkü. Meraki Cloud’a eriştiler ve konfigürasyonlarını çektiler. Aynısını ODM için de yaptık ve hub’larımız hazır ve otomatik olarak aralarında VPN’lerini kurdular.

Burada bir duralım. IKE, IPSec parametreleri falan girmedik. Nasıl oldu da VPN kuruldu? Çünkü tüm MX’ler Meraki cloud’taki kurumumuza ait VPN kayıt sistemine kaydoldular. Bu sistem cihazların kimlik doğrulamasını gerçekleştirdi ve birbirlerinin bilgilerini karşılıklı iletti. Bu sayede hem güven ilişkisi hem de bilgi alışverişi sağlandı ve VPN otomatik olarak kuruldu.

Uç lokasyonlara cihazlar ulaşmaya başladı. Fiber internet, ADSL model, 4G, vb çeşitli bağlantılarımız var. Cihazlar takıldı, Meraki cloud’a erişip kendi seri numaralarıyla eşleştirilmiş network’lerin konfigürasyonlarını çektiler, VPN otomatik ayağa kalktı ve uç lokasyonlarımız çalışmaya başladı. ADSL modemin arkasında olanlar NAT’a rağmen modem ayarlarına dokunmadan VPN’lerini ayağa kaldırdılar.

Artık Meraki Dashboard’tan uç noktalarımızda VPN’lerimizin durumunu gözlemleyebilir, hat istatistiklerini görebilir, hangi uygulamanın hangi hattı tercih ettiğini anlık görebilir durumdayız

Sonuç olarak Meraki’de VPN & SDWAN yapmak makarna yapmaktan daha kolay ve daha kısa sürüyor.

Yalnız bu makarnayı sade yemek yerine biraz sos eklemek de hiç fena olmaz. Biraz analitik sosu bu makarnayı çok lezzetli kılacaktır. Sosumuzun adı Meraki Insight…

 VPN üzerinden akan ya da doğrudan internete erişen web tabanlı uygulamaları izleyip, her noktada nasıl performans gösterdiklerini gözlemleyebiliriz.

Office 365, Sharepoint, SAP Cloud gibi bilinen uygulamalar veya custom uygulamalar tanımlanıp tüm sistemde bu uygulamaların skorlaması yapılabileceği gibi; lokasyon lokasyon da bu uygulamaların skorları görüntülenebilir. Daha sonra da bu skorların sebepleri incelenebilir. LAN problemi mi, WAN hattıyla ilgili bir ISP sorunu mu, sadece belli istemciler mi etkileniyor yoksa herkes mi, yoksa sunucu mu geç cevap veriyor, hangi sunucular geç cevap veriyor gibi soruların cevaplarını basitçe bulabiliriz.

Bırakalım WAN işini Meraki çözsün!

Bitti, Artık uç noktaların WAN operasyonu yerine yeteneklerimizi daha değerli işlerde kullanabiliriz. Bırakalım WAN işini Meraki çözsün. Bu senaryo tabi ki elimizdeki tek yöntem değil. Örneğin Meraki Dashboard API’lerini kullanarak eğer varsa programlama yeteneklerimizi de konuşturabiliriz.

8 olmazsa olmaz…

Önceki SD-WAN yazısında SD-WAN için sekiz olmazsa olmazdan bahsetmiştim. Bakalım Meraki bunlara ne kadar uygun;

• Tak çalıştır: Meraki’nin göbek adı diyebiliriz
• Otomatik VPN: Kesinlikle
• Otomatik Yönlendirme: Meraki’de VPN WAN için bir routing protokolü kullanılmaz, her şey otomatik ve merkezi yürür
• Uygulama ve Performans Bazlı Yönlendirme: Kesinlikle
• Segmentasyon ve Güvenlik: MX zaten bir UTM çözümü
• Kolay Yönetim ve Ölçeklenebilirlik: Önceki maddelerde göbek adını kullandık ama tekrar etsek sorun olmaz sanırım
• Analitik: Meraki Insight
• Programlanabilirlik (Software Defined): Meraki Dashboard API

Özetlemek gerekirse Meraki SD-WAN hem SD-WAN’dan beklentileri fazlasıyla karşılıyor hem de tüm kurulumu, operasyonu çok basit hale getirerek hayatınızı kolaylaştırıyor.

The post Meraki’de SDWAN yapmak makarna yapmaktan daha kolay! appeared first on Cisco Türkiye Blog.

SD-WAN’ın özellikle WAN hatlarının aktif kullanımının sağlanması, bağlantı tipi ve alınan hizmetten (MPLS vb.) bağımsız bir şekilde çalışabilmesi gibi yetenekleri tüm kurumların daha az operasyonel maliyetle çalışma hedefiyle örtüştü. Özellikle internetin bir WAN hattı olarak kullanılabilmesi, MPLS hatlarının yedeği ve hatta alternatifi olabilmesi maliyet kalemindeki en ciddi avantaj diyebiliriz. Bu durum sunulan diğer yeniliklerle de birleştiğinde SD-WAN’ın popülerleşmesi kaçınılmaz hale geldi.

Peki SD-WAN’dan neler beklemeliyiz, neler bu çözümün olmazsa olmazlarıdır, ağ yöneticisinin hayatında neleri değiştirmelidir? Ve akla gelebilecek diğer sorular… Bu yazının amacı bu soruların cevaplarını üretici bağımsız şekilde vermeye çalışmaktır. Sistem entegratörü, kurumsal firma ve üretici şapkalarıyla gördüğüm ve yaşadığım sorunlardan yola çıkarak kendi SD-WAN kriterlerimi oluşturdum ve sekiz başlıkta aktarmaya çalıştım. Umarım sizlerin yaşadıklarınız ve düşündüklerinizle de örtüşür ve bu yazı hepimize bir rehber olur.

SD-WAN ve Olmazsa Olmazları…

Tüm SD-WAN çözümleri altyapıdan bağımsız olma ilkesine göre çalışır ve bu bağımsızlığı IPSec VPN tünelleri vasıtasıyla sağlarlar. SD-WAN tüm yeteneklerini bu ilkenin üzerine inşa eder. Bu ilkenin üzerinde ise bize yepyeni bir WAN deneyimi sunar.

Tak Çalıştır: Plug&Play veya Zero Touch Provisioning olarak da bilinen bu konsept bana göre SD-WAN’ın en önemli vaadi. Binden fazla router’a birkaç haftada konfigürasyon ve yazılım atmış, her yeni açılacak banka şubesi bildiriminde elinde bilgisayar ve konsol kablosuyla depoya koşmuş biri olarak bu maddeyi ilk sıraya koyma lüksüm vardır sanırım

Tak-çalıştır sözünden benim beklediğim, cihazların BT personeli dahi olmayan kişiler tarafından kurulabilmesinin sağlanması. Peki hiç ağ teknolojilerini bilmeyen biri bir lokasyonun WAN ağını nasıl ayağa kaldıracak? Çok basit. SD-WAN çözümünün uç bileşenleri sahada fiziksel olarak kurulduğunda merkezi bir sistemle otomatik olarak irtibata geçebilmeli, hem yazılım güncellemesi hem de kendisine atanmış olan konfigürasyonu çekebilmeli ve akabinde de görevini yerine getirmeye başlamalıdır. Bunun için en doğru yöntem fabrika çıkışı olarak cihazın ilk sorguyu yapacağı yeri bilmesidir. Böylelikle cihaza konfigürasyon anlamında hiç dokunmadan hazır hale gelecektir. Cihazın nasıl ve nereden konfigürasyon ve yazılımını çekeceğinin sonradan öğretildiği bir çözüm benim kriterlerime göre tam bir tak-çalıştır değil, maalesef. Servis sağlayıcı vb. kaynaklı istisnai durumlar tabi ki olabilir. Bu özellikle amaç; ilk kurulum sürelerini kısaltmak, saha personel giderlerini azaltmak ve problem anında cihaz değişim sürelerini düşürmek diyebiliriz.

Otomatik VPN: Bugüne kadar harika VPN teknolojileri kullandık. Her geçen gün yeni yetenekler eklendi ve çok büyük WAN projeleri gerçekleştirildi. Fakat artık bu işin arka planda kendi kendine gerçekleşmesi ve bizim bu kısmı dert etmememiz gerekiyor. Peki bu nasıl olacak? Tüm uç cihazlar merkezi bir beyin ile irtibata geçecekler. Bu merkezi beyin hem hangi cihazın hangi cihazla ne şekilde VPN yapacağını iletecek hem de cihazların kendi arasındaki güven ilişkisini sağlayacak. Biliyorsunuz IPSec VPN’de Faz-1 diye bir aşama vardır ve bu aşamada VPN yapacak cihazlar birbirlerini bir nevi kimlik doğrulamasından geçirirler ve şifreleme anahtarı paylaşım kriterlerinde anlaşma sağlarlar. Merkezi beyin olduğu durumda ise faz-1 dediğimiz kavramı hayatımızdan çıkaracağız. Sonrasındaki faz-2 aşamasında ise cihazlar birbirleri ile paylaştıkları şifreleme anahtarı, şifreleme tipi ve VPN’e girecek ağlar konusunda anlaşma sağlarlar ve aralarındaki VPN tünelini ayağa kaldırırlar. SD-WAN ile faz-2 aşaması yine merkezi beyin idaresinde otomatik olarak gerçekleşecek. Artık; parametreler mi uyuşmadı, trafiği tetikleyemedik mi gibi soruları sormayacağız. Ayrıca karşılıklı anlaşma (negotiation) yükünden kurtulan cihazlar sadece trafik şifrelemesine odaklanacak ve daha az yorulup daha fazla performans verecekler.

Otomatik Yönlendirme: VPN’i kurmakla bitmiyor tabi çilemiz. Bunun bir de yönlendirme boyutu var. Dinamik yönlendirme protokollerinin seçimi, konfigürasyonu, ölçeklenmesi, hepsi ayrı dert. Peki gerek var mı? Madem merkezi bir beyin bizim için VPN’i kuruyor, o zaman yönlendirmeyi de o yapsın diyemez miyiz? İşte bu sebeple SD-WAN ağ yöneticisini yönlendirme protokolleri ile uğraştırmamalı ve tüm rota paylaşımı merkezi beyin üzerinden otomatik olarak yapılmalıdır. Bu konseptte tüm uç cihazlar üzerlerindeki VPN’e dahil olacak ağları merkezi beyin dediğimiz SDN mimarisinde “controller” olarak adlandırılan yapıya iletirler. Bu yapı da rotaların cihazlar arasındaki dağıtımını belirlenmiş politikalara göre gerçekleştirir. Bugüne kadar öğrendiğimiz ve deneyimlediklerimizi geride bırakmak gibi görünse de, aslında amaç ağ mühendisinin protokoller deryasında boğulmasını engelleyip, gerçekten değer yaratmasını sağlayacak politika yönetimine odaklanmasını sağlamaktır. Dolayısıyla bundan sonra “hangi yönlendirme protokolünü kullanıyorsunuz” diye soranlara “kullanmıyorum, bıraktım” cevabını veriyoruz

Uygulama ve Performans Bazlı Yönlendirme: SD-WAN denildiğinde aslında akla ilk bu madde gelir. Bu maddenin içeriği için, hem bugüne kadar yapamadığımızdan dolayı hem de amacımıza ulaşsak da kırk takla atmak zorunda kaldığımızdan dolayı SD-WAN’ın en cezbedici yeteneği diyebiliriz. SD-WAN ile, bugüne kadar alıştığımız hedef bazlı yönlendirmenin ötesine geçip uygulamaları ve onların performanslarını odak noktasına koyuyoruz. Peki SD-WAN’dan ne beklemeliyiz detaylandıracak olursak; bu çözüm tanıyabildiği uygulamaların ve ağ yöneticisi tarafından tanıtılan uygulamaların kullanacağı hatları seçebilmemize olanak sağlamalıdır. Bir örnek verecek olursak; kritik bir uygulamamızın fiber MPLS hattından, internet ve e-posta trafiğimizin daha az maliyetli DSL internet hattından çift yönlü olarak gitmesini sağlayabilmeliyiz. Burada önemli olan ilgili trafik tipinin çift yönlü olarak, asimetrik trafik oluşturmadan akmasıdır.

“Biz bunu PBR’la yapıyorduk zaten” diyenler vardır ya da “biz NAT’la çözdük diyenler”… Doğru fakat bunlar hem yönetilmesi, hem izlenmesi hem de problem çözümü zor yöntemler.

Ayrıca bu kadar değil. Ya seçtiğimiz hat kötü performans gösteriyorsa ne yapacağız? MPLS hattında paket kaybı varsa, gecikme varsa kullanıcılarım en kritik uygulamamızı kullanırken sorun mu yaşayacaklar? Tabi ki hayır. SD-WAN belirlediğimiz performans kriterlerine göre (paket kaybı, gecikme, jitter gibi) gerektiğinde uygulamaların en performanslı hattan gitmesini sağlayabilmelidir. Biz bunu IP SLA gibi özellikler kullanarak çözüyorduk diyenler varsa işte o zaman ikinci cümledeki kırk taklayı atmış oluyoruz diyebiliriz

SD-WAN’dan beklentim hem uygulama tabanlı yönlendirmeyi ve hem de performansa dayalı hat değişimlerini basit politikalarla tanımlamamızı sağlaması ve çift yönlü olarak uygulayabilmesidir.

Segmentasyon ve Güvenlik: Konumuz WAN olduğu için bu konunun doğası gereği uzak ve merkeze nazaran genelde küçük lokasyonlardan bahsediyoruz. Ve genelde gözden uzak olan gönülden de uzak oluyor ve oralarda merkezde gerçekleştirdiğimiz güvenlik politikalarını tam anlamıyla uygulayamıyoruz. Bu durum da bu lokasyonları doğal bir hedef haline getirebiliyor. Peki SD-WAN bize nasıl yardımcı olmalı? İlk önce uç lokasyonlarımızdaki farklı kaynakları, ağları birbirinden izole edebilmemizi sağlamalı. Bunu bir güvenlik duvarı tadında kurallarla da yapabilir, uçtan uca izole ederek birbirlerine hiç ulaşmamalarını da sağlayabilir. Buna örnek olarak banka şubelerindeki ATM’lerin şubedeki bilgisayarlardan izole edilmesi ya da parekende sektöründeki kasa, POS cihazı, mağaza ağı segmentasyonlarını verebiliriz.

Buraya kadar bazı önlemleri aldık fakat SD-WAN’ın internet’i bir WAN altyapısı olarak kullanma fikri aynı zamanda uç noktadan doğrudan internete çıkma fikrini de tetikliyor. Çünkü “madem interneti bir WAN aracı olarak kullanıyorum neden kullanıcılarımı internete eriştirmek için merkeze kadar getireyim” sorusu ortaya çıkıyor. Henüz bu fikir Türkiye’de çok karşılık bulamadı ama mutlaka önem kazanacaktır. İşte SD-WAN çözümü bu noktada kullanıcıların internete çıkışı için gerekli önlemler konusunda da yardımcı olabilmelidir. Bunun içinde içerik filtreleme, IPS, zararlı yazılımlardan koruma, DNS güvenliği gibi başlıkların ihtiyaca göre sağlanması gerekebilir.

Kolay Yönetim ve Ölçeklenebilirlik: Şu ana kadar beş başlıkta bir çok yeteneği açıklamaya çalıştım. Akla doğal olarak şu su gelecektir; bunları gerçekleştirmek için bugünkü gibi komut satırı tabanlı bir yönetim mi yapacağız? Tabi ki hayır. Sanırım kimse bunun zorluğunu hayal bile etmek istemez. SD-WAN bize merkezi ve olabildiğince basit bir grafik tabanlı arayüz üzerinden yönetim sağlamalıdır. Şablonlar, sihirbazlar, sorun tespit araçları, uyarılar, kontrol panelleri… Hepsi ya da bazıları… Önemli olan tek tek uç cihazları yönetmek yerine artık sistemi bir bütün olarak yönetmemizi sağlayacak araçlara sahip olmaktır.

Bu yönetim sistemleri aynı zamanda da ölçeklenebilir olmalıdır. Yatayda büyüme dediğimiz yöntemi benimsemeli ve bizim büyüme, yaygınlaşma, genişleme gibi ihtiyaçlarımıza da cevap verebilmelidir. Bir banka, şubeleri için yatırım yaptıktan sonra, şubelerinin birkaç katı fazla olan ATM’lerini de aynı yapıya dahil edebilmelidir. Ya da bir parekende firması yurtiçi mağazalarından sonra yurtdışı mağazalarını da sisteme dahil etmek istediğinde yönetim katmanında limitlere çarpmamalıdır.

Analitik: Analitik herkesin kullandığı ama çerçevesini çizmeden bıraktığı bir sözcük. Özellikle SD-WAN için analitik ne anlama geliyor kısmı biraz daha belirsiz. Ben kendime göre şu şekilde açıklıyorum: Bugün itibariyle çalışma yöntemimiz birinin problem bildirip bizim kaynağını aramamız üzerine kurulu. Fakat doğru olan ağımızda ne olup bittiğini birisi bize sorun bildirmeden biliyor olmamız ve aksiyon alarak çözüme kavuşturmamızdır. İşte SD-WAN’da analitik tam da bunu amaçlar. Analitik; ağ mühendisi syslog, SNMP, flow vb. bilgiler ile samanlıkta iğne aramadan, tüm bu araçları kullanıp yanına kendi araçlarını da ekleyerek ağ yöneticisine samanlıktaki iğnenin yerini gösterip, kimsenin ayağına batmamasını sağlamamız için bizi yönlendirmektir. Analitik ile artık hangi uygulama WAN üzerinden düşük bir performansla çalışıyor, hangi lokasyonda performans sorunları var gibi gibi soruların cevaplarını elde edebiliriz. Tabi ki bunun yanına başka fonksiyonlar da eklenebilir, daha farklı ilişkilendirme raporları sağlanabilir. Fakat benim beklentim ve olmazsa olmazım budur.

Programlanabilirlik (Software Defined): Adının hakkını vermek diyebiliriz belki de bu madde için. Fakat sadece bu özellik de olsun diye değil, bu bir ihtiyaç olduğu için. Yönetim arayüzlerinin bize sunduğu yeteneklerin dışına çıkabilmek, hatta cihazların yeteneklerinin kabuğunu kırmak, olaylara karşı otomatik aksiyonlar alabilmek… Tüm bunlar programlanabilirliğin bize sağlayabilecekleri. Ya da sadece hayal edebildiklerimiz.

SD-WAN çözümü bize sistemimizi izleyebileceğimiz ve kontrol edebileceğimiz bir API sağlamalıdır. Biz ağ mühendisleri de yazdığımız script ve hatta programlarla, uygulamalarla ağımızı bir orkestra şefi gibi yönlendirebilmeliyiz. Çünkü biz sadece ağ mühendisi değil harika birer de yazılımcıyız Yok bu biraz iddialı oldu. Hello World falan yazarız ama en azından Neyse kaçış yok, hepimiz ucundan kıyısından öğreneceğiz kod yazmayı.

SD-WAN ve Olursa iyi Olurlar…

Sanırım olursa iyi olur diyeceğimiz ilk konu oldukça net; o da WAN optimizasyonu. Neden “olmazsa olmaz” kategorisinde değil diye sorabilirsiniz. Çünkü WAN optimizasyonu bir türlü pazarda hak ettiği karşılığı bulamadı. SD-WAN’a ait, yeni bir yetenek olmadığı için de bu kategoride olmasının daha doğru olacağını düşündüm. Ama TCP optimizasyonu ile hat verimliliği, caching ve sıkıştırma konuları kesinlikle yabana atılacak özellikler değiller.

Bir parantezi de bulut uygulamaları için açmak gerekli. Belki bu konuya performans tabanlı yönlendirme kısmında değinebilirdim fakat daha az karşılaştığım bir ihtiyaç olduğundan bu kategoriye aldım. SD-WAN çözümünün, bilinen yaygın bulut uygulamalarına, kullanıcıların en hızlı ulaşabileceği şekilde internet çıkışı seçimini yapması gerekiyor. Örneğin Office 365 için, merkez üzerinden mi yoksa lokal internet çıkışından mı daha hızlı cevap alıyoruz, hesaplanmalı ve kullanıcılar en hızlı yol üzerinden yönlendirilmeli.

Buluttan sadece uygulama hizmeti almıyor olabiliriz. Altyapı için de bulut kullanılıyorsa bu durumda bulut veri merkezinde bize ait kaynakların da WAN’ın bir parçası haline gelmesi gerekiyor. Örneğin bazı uygulamalarımız AWS’teki sunucular üzerinde çalışıyorsa uç lokasyondaki ya da merkezdeki kullanıcılarımız SD-WAN ağı üzerinden bu uygulamalara erişebilmelidirler. Dolayısıyla bulut hizmet sağlayıcıların sistemlerinde çalışacak uç cihazların sanal versiyonları SD-WAN çözümü tarafından sağlanabilmeli ve bu sanal cihazlar SD-WAN sisteminin doğal bir parçası olarak çalışabilmelidir.

QoS konusuna hiç değinmedin diyenler olacaktır. Ortada bir WAN varsa, QoS da mutlaka parçası olacaktır ve SD-WAN’ın uygulama tanıma ve bununla ilişkili olarak uygulama QoS fonksiyonlarını yerine getirmemesi düşünülemez. Açıkçası bu yüzden QoS konusuna değinmeye gerek bile duymadım.

Özetle…

Kendi adıma önemli gördüğüm noktaları, üretici bağımsız bir şekilde açıklamaya çalıştım. Mutlaka atladığım noktalar vardır ama bu haliyle de okuyanlarda farklı bir bakış açısı sağlayabildiğimi umuyorum.  SD-WAN kavramının derinliğinde kaybolmamanız için ufak bir katkım olduysa ne mutlu bana.

The post SD-WAN Üzerine… appeared first on Cisco Türkiye Blog.

Buluta taşınan veri anlamında; e-posta, veri tabanı, döküman, müşteri yönetimi vb. sistemler ile karşılaştırıldığında, Meraki’nin bulut veri merkezlerine taşınan içeriği oldukça zayıf ve masum kalıyor.  Türkiye’de bir veri merkezinin olmaması bir dezavantaj gibi görünse de, veri merkezi yedeklilik ve senkronizasyon gereklilikleri sebebiyle, lokal veri merkezlerinin yurtdışına çıkan bilgi anlamında pek de faydalı olduğu söylenemez.

Tüm bunların ışığında; Meraki’nin kişisel verinin gizliliğine, güvenliğe ve ülkelerin hassasiyetlerine ne kadar önem verdiğini açıklamak istedim ve en çok duyduğumuz soruları cevaplayabilmek adına, biraz soru-cevap formatında bir yazı hazırladım. Eğer sizlerin de burada cevabını bulamadığınız sorularınız olursa yazının altındaki yorum bölümünü kullanabilirsiniz.

Soru: Meraki ürünlerinin üzerinden geçen trafik buluttaki veri merkezlerine iletilmekte midir?

Cevap: Hayır, kullanıcı trafiği bulut sistemine iletilmemektedir. Kullanıcı trafiği Meraki ürünlerin lokalinde işlenmekte ve ağa iletilmektedir. Çalışma prensibinin klasik ağ cihazlarından hiçbir farkı bulunmamaktadır. Detaylı bilgi için tıklayınız.

Soru: Meraki ürünlerinin bulut sistemi ile ilişkisi neleri kapsar?

Cevap: Meraki ürünler bulut sistemi üzerinde hazırlanmış olan konfigürasyonları çekerler ve üzerlerinden geçen trafikle ilgili istatistiki bilgiler ile “event log” bilgilerini bulut sistemine iletirler. Detaylı bilgi için tıklayınız.

Soru: Hangi bilgiler Meraki ürünlerden bulut veri merkezlerine iletilmektedir?

Cevap: Alttaki bilgiler Meraki bulut sistemine iletilmektedir ve bu bilgiler kişisel bir veri içermemektedir.

• İstemci MAC Adresi
• İstemci IP Adresi (Private IP)
• İstemci işletim sistemi ve üretici (IOS, Apple, Android, Samsung, vs.)
• İstemcinin bulunduğu VLAN ID
• Data kullanım miktarı (byte cinsinden)
• Kablosuz ise SSID ismi ve bağlanılan cihazın adı

Soru: Türkiye’de satılan ve kurulan Meraki ürünler hangi ülke veya ülkelerdeki Meraki veri merkezlerini  kullanmaktadır?

Cevap: Türkiye’de satılan ve kurulan Meraki ürünleri Frankfurt, Münih ve Dublin’deki veri merkezlerini kullanmkatdır. Avrupa bölgesi veri merkezleri hakkında bilgi için tıklayınız.

Soru: Hizmet alınan veri merkezinin yerinden bağımsız olarak, buluta iletilen bilgiler hangi ülkelerdeki veri merkezlerine senkronize olmaktadır? 

Cevap: Türkiye’nin de dahil olduğu Avrupa Birliği bölgesine hizmet veren Frankfurt, Münih ve Dublin veri merkezlerindeki bilgiler yedeklilik ve olağanüstü durumlar dahil olmak üzere başka hiçbir veri merkezine senkronize olmamaktadır. Detaylı bilgi için tıklayınız.

Soru: Meraki bulut sistemi Avrupa Birliği Veri Koruma Yönergesi’ne uygun mudur?

Cevap: Evet. Bu uygunluğu gösteren dökümana bu bağlantıdan ulaşabilirsiniz: Avrupa Birliği Veri İşleme Sözleşmesi 

Gerektiğinde bu döküman müşteri ve Meraki arasında bir sözleşme olarak karşılıklı imzalanabilir.

Soru: 5651 yasası kapsamında Meraki ürünlerden alınan log bilgileri bulut sisteminden mi temin edilmektedir?

Cevap: Hayır. Ürünlerin üzerinden geçen trafikle ilgili bilgileri içeren URL ve flow logları doğrudan ürünlerden log kayıt sunucularına gönderim yaparlar. Bu loglar bulut sistemine iletilmezler.

Soru: SNMP, netflow gibi yönetim protokolleri Meraki bulut sistemi üzerinden mi veri iletmektedir?

Cevap: Hayır. SNMP ve netflow protokolleri ile cihazlardan alınan data doğrudan kuruma ait lokal yönetim sistemlerine gönderilir. Bulut sistemi bu iletişimin bir parçası değildir.

Soru: Meraki bulut sistemine iletilen kullanıcı adı, telefon numarası vb. kişisel bilgi içeren verilerin gizlenmesi mümkün müdür? 

Cevap: Kimlik doğrulaması ile ağa dahil olunan durumlarda, Radius tabanlı bir lokal sistem ağ cihazına Radius cevabını iletirken bu bilgileri maskeleyebilir, anonimleştirebilir ya da hiç göndermeyebilir. Böylelikle bulut sistemine bu tip bilgilerin hiçbirisi iletilmez.

Soru: Meraki bulut sistemine iletilen ağ kullanım istatistik verilerinin saklanması engellenebilir mi? 

Cevap: Eğer istenirse günlük olarak bu bilgilerin otmatik olarak silinmesi sağlanabilir.

Soru: İstemcilerin ağ kullanım ayrıntılarının bulut sistemine gönderilmesi engellenebilir mi?

Cevap: Evet. Tüm trafik analizi bilgilerinin bulut sistemine iletimi kapatılabilir ve ağ cihazları bulut sistemine bu bilgilerin gönderimini durdurur. İleride açılmak dahi istense geçmişe dönük bilgilere ulaşılamaz. 

Soru: Lokasyon Analitiği için alınan veriler kişisel veri içermekte midir?

Cevap: Hayır. Bu özellik için kullanılan MAC adresleri tek yönlü bir hash fonksiyonundan geçirilerek anonim olarak tutulur. Açıklamanın detayı için tıklayınız.

Soru: Lokasyon Analitiği verilerinin bulut sisteminde tutulması tamamen engellenebilir mi?

Cevap: Evet. Lokasyon analitiği özelliği kapatılarak bu verinin bulut sistemine iletilmesi engellenebilir.

Soru: Meraki bulut yönetim arayüzlerinin yetki güvenliği nasıl sağlanmaktadır?

Cevap: SMS ile iki faktörlü kimlik doğrulama, SAML kimlik doğrulama, rol bazlı yetkilendirme, şifre güvenliği politikaları ve oturum açık kalma süreleri güvenlik ihtiyaçları doğrultusunda tanımlanabilir. Detaylar için tıklayınız.

Soru: Internet bağlantısı olan ve gerekli bilgileri elde eden herkes bir kurumun yönetim arayüzüne erişebilir mi?

Cevap: Hayır. Kurum kendi Meraki yönetim arayüzüne hangi IP adreslerinden erişilebileceğini tanımlayabilir.

Soru: Cisco/Meraki çalışanları bir kurumun Meraki bulut yönetim arayüzlerine erişebilir mi?

Cevap: Hayır. Kurumun yönetim arayüzüne Meraki support ekibinin dahi erişimi engellenebilir. Bu konudaki açıklama için tıklayınız.

Meraki support ekibinin erişiminin kapatılması ve gereken durumlarda açıklması ile ilgili dökümana da buradan ulaşabilirsiniz.

Soru: Meraki ürünleri ile bulut arasındaki iletişimin güvenliği nasıl sağlanmaktadır?

Cevap: Meraki ürünleri ile bulut sistemi arasındaki iletişim SSL tabanlı şifrelenmiş bir protokol aracılığıyla yapılmaktadır. Detaylı bilgi için tıklayınız.

Soru: Meraki veri merkezlerinin güvenlik ve sürekliliği nasıl sağlanmaktadır?

Cevap: Meraki veri merkezlerinde klasik güvenlik önlemlerinin yanında günlük zafiyet ve sızma testleri yapılmaktadır. Ayrıca veri merkezleri ISO 9001:2008, ISO 27001, PCI DSS, SSAE16 ve ISAE 3402 (SAS70) sertifikasyonlarına sahiptir. Veri merkezleriyle ilgili detaylı bilgi almak için tıklayınız.

Soru: Meraki bulut sistemleri siber saldırılara karşı nasıl korunmaktadır?

Cevap: Klasik yöntemlerin dışında Meraki bir güvenlik açığı ödüllendirme program sunmaktadır. Meraki’ye raporlanan güvenlik açıkları açığın seviyesine göre ödüllendirilmektedir. Ödül programı ile ilgili detaylı bilgi almak için tıklayınız.

Soru: Bulut veri merkezlerine ulaşımda bir sorun olması durumunda Meraki ürünleri fonksiyonlarını yitirir mi? 

Cevap: Hayır. Tüm Meraki ürünler üzerlerindeki son konfigürasyon ile çalışmaya devam ederler. Bulut bağlantısı gelene kadar konfigürasyon ve yazılım güncellemesi alamazlar, istatistik ve event log bilgilerini iletemezler. Davranış hakkındaki detaylar için tıklayınız.

Avrupa Birliği kişisel veri gizliliği regulasyonları için hazırlanmış Meraki dökümantasyonları:

Veri İşleme Sözleşmesi

Teknik ve Organizasyonel Detaylar

Meraki AB Gizlilik SSS

The post Meraki Bulut Güvenliği ve Gizlilik Üzerine… appeared first on Cisco Türkiye Blog.

Bulut tabanlı ağ şu anda çok popüler ve ilgi çekici bir başlık. Amerika başta olmak üzere Avrupa ülkeleri ve diğer ülkelerde Meraki’nin bulut tabanlı ağ çözümlerine yönelik yatırımlar hızla artıyor. Türkiye’de de bu ilgi hızla artıyor. Fakat bu başlık insanların ilgisini çektiği kadar bazı önyargılar sebebiyle endişe duyulmasına da sebep oluyor. Bu yazıda elimden geldiğince bu önyargıları kırmaya, akıllardaki soru işaretlerini azaltmaya çalışacağım.

En çok korkulan konu Meraki’de kullanıcı trafiğinin bulutta bulunan sistemlere gideceği ve bunun yaratacağı gizlilik problemleri. İlk olarak bu konuyu açığa kavuşturalım. Meraki’de kullanıcı trafiği kesinlikle bulut sistemlerine gitmez. Bulut tarafından yönetilen her cihaz trafiği kendi üzerinde döndürür.

Buluta giden tek trafik yönetim trafiğidir. Yani yapılan konfigürasyon buluttan cihazlara gönderilir. Cihazlarla ilgili trafik istatistikleri ve olay günlükleri (event log) buluta gönderilir. Buluta gönderilen bilgiler içerisinde trafik akışları (flow bilgisi) ya da yazının sonunda değineceğim 5651 nolu yasa için anlamlı olan trafik logları kesinlikle bulunmaz. Bunlar istenildiğinde doğrudan cihazlar tarafından gönderilir. Yani sonuç olarak gizlilik için sorun yaratabilecek hiçbir veri bulut sistemlerine gitmez.

Bir diğer çok karşılaştığım önyargı ise iş sürekliliği ile ilgili. Buluttan yönetilen bir cihazın Meraki veri merkezinin erişelebilir olmaması ya da cihazın veri merkezine erişim sağlayamaması durumunda fonksiyonlarını yerine getiremeyeceği şeklinde bir endişe mevcut.

Öncelikle Meraki veri merkezleri %99.99’luk ayakta kalma garantisi veriyor. (Bknz. https://meraki.cisco.com/trust#data-centers) Geriye kalan %00.01 yani yılda 52dk.’lık kısımda da erişilemeyen yer sadece yönetim için kullanılan Meraki Dashboard. Ürünler veri merkezine erişemese dahi üzerindeki konfigürasyonla hizmet vermeye devam ediyor ve erişilemeyen durumda buluta göndermesi gereken istatistiki bilgileri önbelleğinde saklıyor. Erişim geri geldiğinde de bu bilgileri tekrar buluta gönderiyor. Aynı durum veri merkezinin ayakta olduğu ama cihazların buluta erişiminin sağlanamadığı durumda da geçerli. Yani sonuç olarak cihazların çalışması bulut erişiminin sağlanamaması durumundan etkilenmiyor.

Son önyargı ise kurum içinde bulunmayan bir yönetim platformuna erişimin güvensiz olacağı yönünde. Fakat bununla ilgili önlemler de Meraki tarafından alınmış durumda. Kısaca özetlersek;

• İstenirse bulut arayüzüne iki faktörlü kimlik doğrulaması ile girmeye olanak tanıyor
• Şifre politikaları, periyodik şifre değişimleri, üst üste hatalı girişlerde hesap kilitleme, vs.
• Bulut tabanlı yönetimin faydasını azaltsa da IP tabanlı filtreleme
• Yönetim hesaplarının yetki seviye ayarlamaları
• Konfigürasyon değişikliklerinde yapılan değişikliğin ayrıntılarını içeren e-posta bilgilendirmeleri
• Ayrıntılı değişiklik günlüğü ve yapılan değişikliklerin ayrıntıları
• SSL doğrulaması
• Aktivite olmadığında otomatik log out

Bunlar dışındaki PCI uyumluluğu, güvenlik testleri, güvenlik ödülleri programı, SLA ve gizlilik ile ilgili diğer konular için https://meraki.cisco.com/trust adresine gözatabilirsiniz.

5651 uyumluluğu

Çok duyduğumuz sorulardan birisi de Meraki’nin 5651 uyumlu olup olmadığı. Aslında buradaki doğru soru Meraki’nin sağladığı log’ların 5651 uyumlu bir platforma gönderilip gönderilemeyeceği ve log içeriği olmalı.

Meraki kablosuz erişim noktaları ve güvenlik duvarları kuruma ait herhangi bir 5651 ya da SIEM uygulamasına trafik log’larını gönderebilir.

Örneğin altta benim kendi evimde kullandığım Meraki kablosuz erişim noktasından dışarıda başka bir log sunucusuna gönderdiğim log’dan aldığım bir satırı görebilirsiniz.

• Mar 15 17:37:37233.139.175 logger: <134>1 0.0 OzgurEv urls src=192.168.1.22:59327 dst=85.111.27.167:80 mac=78:31:C1:CD:74:A4 request: GET https://www.milliyet.com.tr/

Bu log’un sadece kablosuz erişim noktasından alınmış durumda, ortamda bir güvenlik duvarı bulunmuyor. Burada benim bilgisayarımın public ve private IP adresleri, bilgisayarımın MAC adresi, zaman bilgisi ve yaptığım GET isteğinin URL ve IP bilgisi mevcut. Dolayısıyla Meraki’nin verdiği log’lar için 5651 uyumlu diyebiliriz. Daha da ayrıntılı trafik loğu almak için eğer istenirse “flow” loğu da gönderilebilir. Örnek;

• Mar 15 17:46:40 233.139.175logger: <134>1 0.0 OzgurEv flows allow src=192.168.1.22 dst=85.111.27.167 mac=78:31:C1:CD:74:A4 protocol=tcp sport=59327 dport=80

Aslında Bulut Tabanlı Ağ Güvenli ve Güvenilirmiş!

Tabi ki bir yazının içerisinde tüm soru işaretlerini yok etmek, bütün önyargıları kırmak mümkün değil ama bazı noktaları aydınlatabildiysem ne mutlu bana. Burada dokunamadığım konular veya aydınlanmayan noktalar için LinkedIn veya e-posta aracılığıyla bana ulaşabilirsiniz.

Özgür Güler

ozgguler@cisco.com

https://tr.linkedin.com/in/gulerozgur

The post Meraki Bulut Önyargıları ve 5651 Yasası appeared first on Cisco Türkiye Blog.

          Meraki Challenge

Oyunumuzun adı Meraki Challenge. Katılımcılar için dört farklı zorluk seviyesinde (çok kolay, kolay, orta ve zor) görevler hazırladık. Her seviyeye de sırasıyla 1,3,5 ve 7 puan tanımladık. Herkese ilk olarak “çok kolay” seviyesinden bir görev verilecek. Eğer görev doğru şekilde tamamlanırsa bir üst seviye görev verilecekti. Cevaplanamayan her görev için bir alt seviyeden devam edilecek, en son seviyedeki görevi doğru şekilde tamamlayanlara da aynı seviyeden görevler verilmeye devam edilecekti. Tüm bunlar için de süremiz 4 dakikaydı.

Oyunumuzun ödülü ise ilk üçe giren yarışmacılara verilecek birer adet Meraki Access Point’ti.

Görevler etkinlik alanında hazır bulunan demo sistemimiz üzerinde Meraki Cloud Dashboard aracılığıyla yapılacaktı. Ve üç temel kuralımız vardı:

1. Halihazırdaki Meraki müşterilerimiz değerlendirme dışı, çünkü onlar zaten herşeye hakimler.
2. İşortaklarımız değerlendirme dışı
3. Aynı firmadan ilk üçe giren birden fazla kişi olursa sadece biri ödül alacak.

Yani aslında amaç; hayatında Meraki Dashboard arayüzünü hiç görmemiş kişilerle bu oyunu oynamaktı.

          Ve oyun…

Aslında beklentimizden az kişi katıldı yarışmamıza. Toplam 37 kişi değerlendirmeye alındı. Yarışmacılar dört dakika içinde; SMS doğrulamalı SSID’ler açtılar, uygulama tabanlı QoS tanımladılar, Hub&Spoke mimaride VPN kurdular, group policy’ler yaratıp kullanıcılara uyguladılar, URL filtering tanımları yaptılar, switch’te link aggregation yaptılar, farklı cihazlardan packet capture’lar yaptılar, kamera görüntülerini filtreleyip geçmiş hareketleri buldular, ve daha neler neler…

Katılan kişiler hayatlarında daha önce Meraki Dashboard’u görmedikleri için, tahminimiz çoğu kişinin en zor seviyeye gelemeyeceği şeklindeydi. Fakat yanıldık. Oyunu lider bitiren ve ödül almaya hak kazanan 4 kişi toplamda dörder adet en üst seviye görevi tamamladılar. Biz de mecburen ödül sayısını dörde çıkardık:)

Kazanan yarışmacılarımızı kutlarız. Bizim için keyifliydi, umarım katılanlar da keyif almıştır.

Kazananlar:

Sebahattin Türkeç – Divan Hotel Istanbul Asia

Emre Kayhan – Yıldırım Holding

Said Temelli – İTÜ Bilgi İşlem

Sinan Tekincan – Garanti Teknoloji

Özgür Güler – Sistem Mühendisi

ozgguler@cisco.com

Twitter: @ozggulercisco

The post Meraki Challenge Oyunu – Cisco Connect appeared first on Cisco Türkiye Blog.

            Her ne kadar hem Türkiye hem de dünyada yapılan başarılı projeler Meraki ile ilgili tüm soru işaretlerini kaldırmış olsa da bunu bir de canlı ortamda kendimiz göstermek istedik. Ve Cisco Türkiye ekibi olarak 17 Ocak 2017 günü Swisshotel’de gerçekleştirdiğimiz Cisco Connect etkinliğimizde misafirlerimizin hotspot erişimi için ve fuaye alanında kendi bağlantılarımız için geleneksel Cisco yerine Meraki Access point’leri kullanma kararı aldık.

          Bizim için de ilkti…

Ekip olarak ilk defa Meraki ile bunu yapacağımız için ufak bir endişe oldu tabi. Çünkü bu tip etkinlikler, özellikle önceki Cisco Expo, Cisco Connect ve Cisco Live gibi etkinliklerden bildiğimiz üzere, sorun yaşanmasına uygun ortamlardır. Özellikle birkaç farklı sorun sık görülür. En önemlisi insanların yoğun olarak bulunacağı alanlarda Access point başına düşen istemci sayısının artması sonucu yaşanan performans düşüklüğüdür. Bunu aşmak için uygulanan daha yoğun access point yerleşimi ise enterferans sorunlarını beraberinde getirir. Özellikle 2.4Ghz’te enterferans yaşanmaması için bazı Access point’lerde 2.4GHz yayınını kapatmak bile gerekebilir. 5Ghz’teki kanal sayısı durumu biraz rahatlatsa da orada da kulanılabilir kanal sayısını yüksek tutmak için çoğu zaman 20MHz’lik kanallara mahkum olunur.

Resim 1: Cisco Connect öğle yemeği arasında fuaye alanının bir kısmı

            Ayrıca bazı oturumlarda sahnede kablosuz bağlantı kullanılarak demolar yapılacak olması, hatta bazı demolarda video görüşme gibi bantgenişliği ihtiyacı duyan uygulamalar olması riski artıran faktörlerdir.

           Pilavdan dönenin kaşığı kırılsın!

            Soru işaretlerini kaldırmanın tek yolu bu riski almak ve Meraki’ye güvenmekti. Biz de kararımızdan dönmedik. İşortağımız Biltam ile ortaklaşa bir çalışma yaparak, 5651 loglaması ve login ekranlarıyla tüm çözümü planladık. Biltam ekibinin yaptığı site survey sonucunda 24-25 adet Access point ile istemci yoğunluğunu karşılayacak şekilde planlama yaptık.. Access point olarak 4×4 antenli 802.11ac Wave2 destekli Meraki MR52 modelini kullanmaya karar verdik. Hotspot login ekranları ve 5651 loglaması ise Biltam’ın Wingy çözümü ile gerçekleşecekti.

            Ve kurulum…

            Kablolama ve montaj kısmını saymazsak aslında kurulum kısmına yazılacak fazla bir şey yok Çünkü yayınlanan üç SSID için tüm konfigürasyon işlemi toplamda 1dk civarı sürüyor Sonrası zaten tak-çalıştır…

Resim 2:  Kurulumdan önceki Access Point yerleşim planı

          Üç SSID’miz vardı. Birisi stand alanında demolarımızı gösterirken kullandığımız, birisi IOT cihazlarını bağladığımız, diğeri ise etkinliğin ziyaretçilerinin bağlandığı hotspot SSID’miz olan Cisco Connect.

            Cisco Connect SSID’si açık bir SSID olup, kimlik doğrulama için Wingy portaline yönleniyordu. Burada cep telefonu numarası girildikten sonra gelen SMS’in girilmesiyle kimlik doğrulama tamamlanıyordu. Kullanıcılar başına bantgenişliğini ise bir sorun gelmedikçe sınırlamama kararı almıştık. Ayrıca uygulama bazlı bir kısıtlama da yapmamıştık. Riski sevdiğimiz doğrudur

Resim 3: Wingy kimlik doğrulama portali

            Biltam ekibinin yaptırdığı 3 metre boyundaki şık totemler hem stand alanına hem de oturum salonlarına yerleştirildi ve gerekli kablolamalar tamamlandı. Access point’ler monte edilip switch bağlantıları yapıldığı anda Meraki cloud bağlantısını sağlayıp önceden hazırlanan konfigürasyonu çekerek hemen çalışmaya başladılar.

           Gelelim istatistiklere…

Cisco Connect etkinliğine toplamda 1000’e yakın kişi katıldı. Özellikle 10.00-15.00 saatleri arasında hem oturum salonlarında hem de fuaye alanında iğne atsanız yere düşmeyecek durumdaydı.

Meraki Dashboard’un bize sunduğu bazı istatistiki bilgilere göz attığımızda toplam 317 farklı kişinin kablosuz ağı kullandığını görüyoruz. Toplam katılımcı sayısının 900+ olduğu düşünülürse hiç fena bir sayı değil.

Resim 4: Meraki Dashboard Summary Report – Etkinliğe ait istemci sayısı istatistikleri

            Tabi ki ağırlıklı olarak kullanılan misafir bağlantısı olan “Cisco Connect” yayınıydı. Gün boyunca 291 kişi bu yayını kullandı. En çok data kullanımı olan SSID de doğal olarak buydu.

Resim 5: Meraki Dashboard Summary Report – Data kullanım istatistikleri

            Kişi sayısı göz önüne alındığında kullanılan data miktarı çok görünmeyebilir ama belli bir zaman aralığında yüksek olması ve en fazla data çeken uygulama olan Bittorrent’i tek bir kişinin o saat aralığında kullanmış olması dikkat çekici bir detaydı. Kim bilir belki de bir misafirimiz akşam izleyeceği filmi indirmiş olabilir Fakat neredeyse Bittorrent kadar datayı VPN UDP portlarının kullanmış olması iş amaçlı kullanımın da oldukça yüksek olduğunu gösteriyor.

Resim 6: Meraki Dashboard Summary Report – Etkinlikteki uygulama kullanım istatistikleri

            Yaklaşık 8 saat süren bir etkinlikte 291 kişinin hostpot SSID’sini kullanması saat saat bölündüğünde access point başına pek fazla yük düşmeyeceğini düşündürebilir. Ama bu noktada da Wingy’nin Meraki API’sinden elde ettiği location analytics verileri yardımımıza koşuyor ve görüyoruz ki hotspot wifi’a bağlanan kullanıcıların etkinlik alanında ortalama bulunma süresi beş buçuk saat. Bunun anlamı wifi kullanan kullanıcıların neredeyse tamamı aynı zamanda etkinlikteymiş.

Resim 7: Wingy arayüzünden etkinlik gününe dair location analytics verileri

            Bu tabi bir çıkarım. Bunun kanıtını yine Wingy’nin 6-12 saat arası lokasyonda bulunanları gösteren raporundan görmek mümkün. Öğlen saatlerinde 300’ün üzerinde wifi’a bağlı kişi aynı anda görülüyor. Hatta 10.00-15.00 arası bu sayının aşağı yukarı aynı kaldığı net şekilde raporlanmış.

Resim 8: Wingy arayüzünden etkinlik alanında 6-12 saat geçirenlerigösteren grafik. Sarı çizgi wifi ağına bağlı bulunanları gösteriyor.

            Peki ya performans? 

            Gün boyunca tüm Cisco ekibi ve tabi ki Biltam ekibi standlardaki demolar için “Staff” isimli SSID’yi kullandık. İki elektrik kesintisi dışında hiç bağlantı veya bantgenişliği sorunu yaşamadan günü bitirdik.

Misafirlerimizin bağlandığı SSID’mize bağlantıda da yabancı misafirlerimizi saymazsak ciddi bir bağlantı sorunu yaşanmadı. SSID’ye bağlanıp giriş portalini görüntüleyen kişilerin %80’i başarılı bir şekilde login işlemini tamamladılar.

Resim 9: Keynote oturumu sırasında ana salondan bir kare

            En çok merak ettiğimiz konu, özellikle açılış konuşması ve onu takip eden konuşmalarda tıklım tıklım olacak olan ana salonda, performansın ne seviyede olacağıydı. TÜSİAD başkanı Erol Bilecik’in, direktörümüz Osama Al-Zoubi’nin konuşmaları ve en kalabalık oturum olan CIO paneli sırasında yaptığımız testler gayet başarılıydı.

Resim 10: Performans testi – Erol Bilecik’in konuşması sırasında

Resim 11: Performans testi – Osama Al-Zoubi’nin konuşması sırasında

Resim 12: Performans testi – CIO paneli sırasında

            Öğleden sonra kalabalık bir salonda Collaboration ekibimizden Pınar Yıldız ve Ali Saygıvar’ın sahnede yaptığı video görüşmeli Spark demosu da aynı kablosuz ağ üzerinden başarılı bir şekilde gerçekleşti.

            Zero Touch

            Hiçbir kanal ayarlamasına dokunmadık. Hiçbir Access point üzerinde anten çıkış gücü ayarlarını değiştirmedik. Hiçbir Access point’te 2.4GHz’i kapatmadık. Hiçbir bantgenişliği sınırlaması ya da uygulama sınırlaması yapmadık. Dürüst olmak gerekirse bu kadar da “zero touch” olacağını biz bile tahmin etmedik. En azından ufak tefek enterferans sorunları olur ya da salonlardaki Access point yerleşimini kısıtlı imkanlarla yapabilmemiz sebebiyle yük paylaşımı sorunları yaşanabilir diye düşünmüştük. Yanılmışız

            Bundan sonra hep Meraki…

Meraki, Türkiye’de alışveriş merkezleri, mağazalar, yoğun ofis ortamları ve hatta bazı depo ortamlarında bile kullanılıyordu. Real Madrid’in basketbol salonunun da Meraki Access point’ler ile kapsandığını biliyorduk. Fakat bunu bir kez de böyle göstermek istedik. Bundan sonraki bütün Cisco etkinliklerinde de kablosuz erişimin Meraki Access point’ler ile yapılacağını da söylememe gerek yoktur sanırım. Çünkü o kadar zahmetsiz ve o kadar sorunsuz oldu ki bir daha bu rahatlıktan vazgeçebileceğimizi sanmıyorum

Cisco Connect’e katılma nezaketinde bulunarak performans testimize katkı veren herkese çok teşekkür ederiz…

Özgür GÜLER

Sistem Mühendisi

ozgguler@cisco.com

Twitter: @ozggulercisco

The post Hayat Çok da Zor Değilmiş! appeared first on Cisco Türkiye Blog.

Data Broker ve benzer çözümlerde kampüs ve veri merkezi anahtarlarından SPAN yapılarak veya TAP’lar yardımıyla kopyalanan trafik,  veri iletiminde kullanılan geleneksel anahtarlar topluluğuna paralel olarak oluşturulmuş ikinci bir izleme ağına gönderiliyor, buradan da istenen izleme, ölçme veya güvenlik sunucularına analiz amacıyla iletiliyor. Bu sunucu sistemlere örnek olarak DLP ve IDS gibi güvenlik çözümlerini veya Cisco açısından bakacak olursak Prime NAM, Lancope veya SourceFire çözümlerini verebiliriz.

2014 yılında yaklaşık 500 Milyon dolarlık bir pazara ulaşan bu çözümde, yıllık olarak da %30’luk bir büyüme söz konusu. Pazara hakim tek bir üretici bulunmamakla beraber gerek ürünler gerekse istenen özellikler için biçilen lisans ücretleri ise oldukça yüksek. Bu çözüm için özel donanımlar üreten firmaların yaşadığı bir diğer problem ise birbirlerinden farklılaşma konusunda ortaya çıkıyor. Cisco bu noktada hem fiyatı daha ekonomik olan, hem de genişleyebilme, yönetim kolaylığı ve esnekliği ile farklılık yaratacak Data Broker çözümü ile bu firmalar arasına katılmış durumda. Fiyatın ekonomik olmasının bu noktada dikkatinizi çektiğini düşünerek yavaş yavaş sağlanan çözümün avantajları konusuna geçmek istiyorum.

Cisco Data Broker çözümünü SPAN ve TAP’lar üzerinden gelen trafiği hedef izleme sistemlerine ileten anahtarlama cihazları ile bu anahtarları yönetmek için kullanılan Data Broker yazılımından oluşuyor. Anahtarlama parçasını yakından tanıdığımız Nexus 3000/3100/3500’ler veya Nexus 9300/9500’ler ile inşa ediyoruz. Bu anahtarlara tek eklemeniz gereken ise Data Broker lisansı. Oluşturulan bu ağı yönetmek için kullanılan Data Broker yazılımı ise aslında bir “SDN Controller”. Anahtarları OpenFlow veya NxAPI ile yönetebiliyor.

İhtiyaç duyulan port sayısına bağlı olarak bu parçaları iki farklı modelde bir araya getirmek mümkün.

1. Gömülü Model: Tek bir Data Broker anahtardan oluşur. DataBroker yazılımı için ayrı bir sunucuya ihtiyaç duyulmaz ve anahtar içindeki “Linux container” üzerine bir OVA dosyası aracılığıyla kurulur.

2. Merkezi Model: Eğer çok sayıda anahtar kullanılacaksa, merkezi bir data broker yazılımı ayrı bir sunucuya kurulur. Bu yazılım herhangi bir topolojide birbirine bağlanmış anahtarlardan sonsuz döngü oluşturmayacak bir iletim yapısı oluşturur ve bu yapıyı yönetir.

Data Broker yazılımı sahip olduğu GUI aracılığı ile hangi anahtarların hangi portlarına gelen SPAN/TAP trafiğinin birleştirilerek hangi anahtarların hangi çıkış portlarına iletileceği belirlememize yardımcı olurken bir yandan da her hangi bir kesinti sonucu topolojide bir değişiklik oluşması durumunda tekrar sonsuz döngüye sahip olmayan yeni bir yapının oluşturulmasını otomatik olarak sağlar.

Cisco’nun sunduğu DataBroker çözümünün öne çıkan bazı özelliklerini listelersek:

Çok Noktadan çok noktaya iletim (Mutipoint to multipoint): Seçilen kaynaklardan gelen SPAN/TAP trafiği filtrelendikten sonra istenen sayıda hedefe gönderilebilir. Kaynak ve hedef portlar farklı databroker anahtarlara dağıtılmış olabilir.

Tüm portlardan çok noktaya iletim (Any-to-Multipoint): İstenen trafiğin hangi portlardan geldiği bilinmiyorsa, tüm kaynak portlardan gelen trafik filtrelere uygun olarak istenen sayıda hedefe ulaştırılabilir. Kaynak ve hedef portlar yine farklı databroker anahtarlarda dağıtılmış olabilir.

Filtremele: Paketlerin L1-L4 başlıklarına göre (Vlan-tag, IP, port vb.) filtreleme yapılabilir. Filtreleme istenen trafik için çift yönlü de sağlanabilir (bidirectional packet filtering). Böylece örneğin izlenen trafik içindeki yalnızca belli sunuculara yönelik HTTP trafiğini bir güvenlik sunucusuna yönlendirmek mümkün. Filtreme işlemi istenmeyen paketlerin tamamen yok sayılması amacıyla da kullanılabiliyor.

Yük Paylaşımı: İzleme sunucusunun kapasitesinin üstünde bir trafik varsa bu uygulamadan birden fazla kurularak veya sunucuya port kapasitesinin üzerinde bir trafik göndermek gerekiyorsa sunucuya yeni port eklemek ve bunlar arasında yük paylaşımı yapmak mümkün. 3100, 9300, 9500 anahtarlar ek olarak simetrik hash’leme ile paylaştırılan trafiğin çift yönlü olarak aynı uygulamaya/porta gönderilmesi de sağlayabiliyor (bi-directional packet matching). Yük paylaşımı yapmak için tüm hedef portların aynı data broker portlarına bağlı olması gerektiğini hatırlatmakta fayda var (en azından bugün için).

Çoklu Veri Merkezi Yönetimi: Farklı veri merkezlerine dağıtılmış DataBroker topolojilerinin tek bir DataBroker yazılımı ile yönetilmesi mümkün.

Topoloji değişiklikliklerine adaptasyon: DataBroker anahtarları arasındaki bağlantıların kesilmesi gibi durumlarda DataBroker yazılımı tekrar sonsuz döngüye neden olmayan yeni bir topoloji oluşturabilir.

Başlık slime/ekleme: Orjinal pakette bulunmasa da giriş trafiklerini ayırt etmek ve filtreleme esnasında kullanmak için giriş yönünde paketlere vlan-tag eklemek mümkün. Orjinal paketin MPLS başlığı varsa bu başlığı da kaldırabilirsiniz.

PTP bigisi ekleme: Bugün için yalnızca Nexus 3500 anahtarlarda paketlere giriş yönünde PTP (IEEE 1588) bilgisi eklemek mümkün.

Paket Kırpma: Yine bugün için yalnızca Nexus 3500 anahtarlarda databroker ağına giren paketlerin yalnızca belli bir boyutunun izleme sistemlerine iletilmesi mümkün (örneğin paketlerin ilk 64-byte’lık kısmı)

Büyümekte olan bir pazara girerek oyunun akışını değiştirmeyi sıklıkla yapan Cisco’nun bu çözümü yukarıda listelediğim bir çok özellikle rakiplerinden farklılaşıyor. Port başına maliyet olarak (1/10/40/100Gbps portlar) bakıldığında sağladığı ekonomik çözüm ise bir diğer artı değer. Çözümü biraz daha detaylı incelemek isterseniz aşağıdaki link’teki dokümanı okuyabilirsiniz. Cisco iş ortaklarının erişebildiği dCloud üzerinde bir demo da mevcut. Bu demo ortamı son kullanıcıların talep etmesi durumunda iş ortakları tarafından kendileriyle de paylaşılabiliyor. Israrla demo erişimi isteyin derim

Cisco Data Broker White Paper

Kubilay Akgül – CCIE #29500

Cisco Türkiye – Sistem Mühendisi

The post Cisco Data Broker Nedir? appeared first on Cisco Türkiye Blog.