Merhaba arkadaşlar, Quality of Service makalelerimize devam ediyoruz. Makale serimizin bu bölümünde QoS uygulama modellerinden bahsederken genel olarak, Best Effort, IntServ ve DiffServ olarak üç başlıkta incelediğimiz uygulama modellerinin avantaj ve dezavantajları hakkında bilgiler vermeye çalışacağım. QoS uygulama yöntem ve modellerine girmeden önce, QoS uygulamalarını gerçekleştirmek için üç adımlık bir yol katmemiz gerekmektedir. Bu üç adımlık yolun sonunda uygulayacağımız modele ve kullanacağımız yönteme karar vereceğiz.
QoS uygulamaları gerçekleştirirken ilk yapılacak işlem network trafiğini incelemek, dökümante etmek ve bizim için önem taşıyan trafik tipleri için gereksinimleri belirlemek gerekir. Bu gereksinimlerden, konumuz ağırlıklı olarak ses ve görüntü üzerinde QoS olacağı için, bu trafik tipleri için bazı önemli bilgilerin altını çizmekte fayda var. Ses paketleri kayıpsız olmalıdır, karşı tarafa net bir şekilde ulaşmalıdır, gecikme az olmalıdır. Bu noktada des trafiği için önerilen 150 ms’nin altında bir delay ve %1’in altında bir paket kaybıdır. Ancak bu şekilde kaliteli bir telefon görüşmesi sağlanabilecektir.
Görüntü içinde aynı şartlardan bahsetmek mümkün. Belki biraz daha esnek olabilir ama yinede mümkün olduğunca bu rakamların üzerne çıkmayan delay ve paket kaybını sağlamak gerekecektir. Burada untulmaması gereken bu gereksinimlerin tek yön için olduğudur.
Bahsettiğimiz ses ve görüntü dışında da bizim için önemli trafikler varsa, transferinde hızın önemli olduğu trafikler varsa, bunlar ile ilgili gereksinimler tabi ki değişken olacaktır ve sizler tarafından belirlenecektir. Örneğin şirket içerisinde kullanılan ve çok yoğun bir şekilde veri akışı olan program içinde minumum delay ya da minumum paket kaybı gibi gereksinimler olabilir. Ben ağırlıklı olarak ses için görüş bildiriyor olsam da, aynı konfigürasyonlar, örneğin bir CRM ya da ERP uygulaması içinde yapılabilecektir.
Bu gereksinimlere karar verdikten sonra atılacak olan adım ise trafiğimizi tanımlamaktır. Evet biz neyin ne kadar önemli olduğuna yani hangi paket tiplerimizin ne kadar öncelikli olacağına karar verdikten sonra cihazlarımız üzerinde de bu önemi vurgulayabilmemiz için önce cihazımızın da bu trafik tiplerini ayırt edebilmesi gerekir.
Basit bir sınıflandırma şekildeki gibi yapılabilir. Ses, ERP, Mail-Web ve P2P paketleri ayrı sınıflara alınmıştır. Tabi ki daha birçok farklı trafik tipi olacaktır. Bu sadece bir örnek olmasına rağmen şunu da şimdiden belirtmek isterim ki, bizim herhangi bir sınıfa dahil etmediğimiz paketler “class-default” adında ki bir sınıfa otomatik olarak dahil olurlar.
Trafik sınıflarımızı oluşturmak için access-listlerden faydalanabilir. Örneğin belirli portları kullanarak çalışan bir uygulama access-list ile kolaylıkla tanımlanabilecektir. Hatta burada belir ip subnetleri için policy belirleme gibi bir opsiyonumzda olacaktır. (Aklımıza hemen internet bağlantısının büyük bir bölümünü ken ip adresimize rezerve etmek gelmemeli : -) )
Bunun yanında daha sonra detaylı olarak bahsedeceğimiz NBAR’da (Network-Based Application Recognition) sıklıkla kullanılmaktadır. Paketlerimizi Application Layer’da tanımlama imkanı sağlayan NBAR bizlere bir çok kolaylık sağlayacaktır. Trafik sınıflandırma işlemlerinden, daha sonra takip edeceğiniz teknik makalelerde de faydalı olacağını düşündüğüm için makaleler boyunca “Classification”, işaretleme işlemlerinden ise “Marking” olarak bahsedeceğim.
Şu an komutların ne olduğuyla fazla ilgilenmeden, örnekte de görebileceğiniz gibi NBAR sayesinde ses paketlerini direkt olarak router’a gösterebilmekteyim.
Sınıflandırma işlemini, çeşitli yöntemlerden birini kullandıktan sonra son olarak yapılacak işlem, bu trafik tipleri için policyleri belirlemek olacaktır. Bu policyler örnek olarak;
1. Minumum bandwidth belirleme
2. Maximum bandwidth belirleme
3. Sıkıştırma
4. Priority verme
gibi rule’lardan oluşabilir.
Bütün bu sınıflandırma ve policy belirleme işlemlerini eskiden interface bazlı yapılan konfigürasyonların yerini alan ve çok daha kolay tasarlanabilen MQC (Modular QoS Command Line Interface) ve SDM (Security Device Manager) kullanarak yapacağız. (Komut satırında kullanabileceğimiz, özellikle ses trafiği için tasarlanmış AutoQoS komutundan da makalelerimiz içerisinde bahsedeceğiz.)
Module QoS, interfacelerden bağımsız olarak sınıflan oluşturmamıza, bu sınıflar için policyler belirlememize olanak sağladığı için, çok geniş planlanan QoS konfigürasyonları ciddi bir şekilde kolaylaşktırmaktadır. Bütün konfigürasyonlar Global Konfigürasyon modundan başlayarak yapılır ve en sonunda istediğimiz interfacelere uygulanır. Aynı sınıflar birden fazla policy içerisinde kullanılabilir. Aynı policyler birden fazla interface için çalıştırılabilir. Ve hatta policy içerisinde başka policyler çalıştırılabilir. Bütün bu esneklikler ile Modular QoS CLI hepimiz için faydalı olacaktır.
Makalenin devami icin Login ya da Kayit olmalisiniz.
Etiketler: DiffServ, DSCP, IntServ, IP Precedence, QoS, RSVP
“Quality of Service-Bölüm 2: Uygulama Model ve Yöntemleri” için 0 Yorum yapılmış.