# Traffic Shaping and Traffic Police

### **Traffic Shaping:**&#x20;

Gelen trafiğin belirlenen bir bandwith seviyesinde tutulması metodur. Örneğin biz gelen bir trafiği maksimum 40 Mbps seviyesinde tutmak istersek artık gelen trafik 0-40 mbps aralığında direk olarak geçebilecekken 40 Mbps üstünde gelen trafik port buffer'ında tutularak 40 Mbps seviyesi bozulmadan gönderilmeye devam edecektir. Yani aşım olduğundaki durumda, aşım trafiği **drop edilmeyecektir**.

### Traffic Policing:&#x20;

Gelen trafiğin belirlenen bir bandwith seviyesinde tutulması metodudur. Örneğin biz gelen bir trafiği maksimum 40 Mbps seviyesinde tutmak istersek artık gelen trafik 0-40 Mbps aralığında direk olarak geçebilecekken 40 Mbps üstünde gelen trafik drop edilecektir. Yani aşım olduğundaki durumda, aşım trafiği **drop edilecektir.**

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FPm5Osj0W8rfTA2gXVAkX%2Fimage.png?alt=media&#x26;token=253c6b72-3dd1-4146-9a6f-eb20449fff07" alt=""><figcaption></figcaption></figure>

<mark style="color:red;">**Tc( Time Interval) :**</mark> Milisaniyeler seviyesinde olup, Bc'nin tamamının kullanıldığı zaman dilimidir. \
<mark style="color:red;">**Bc( Committed Burst):**</mark> Bir Tc periyodunda geçen trafiğin bit cinsinden miktarıdır, defaultta Tc periyodunun yarısı Bc'ya aittir, Diğer yarısında ise aşım olmadığı sürece bekleme işlemi ya da interface process işlemleri olur. (buffer, queue vb.)\
<mark style="color:red;">**Be(Exceedied Burst):**</mark> Bir Tc periyodunda bilindiği gibi Bc işlemi olur. Be ise, eğer Bc miktarından fazla bir veri gelirse bu verinin iletimi, işlenmesi ve tüm processleri Tc'nin periyodunun defaultta ikinci yarısına sahip olan Be kısmında olmaktadır, eğer Be set edilirse trafik shape olur yani aşımlarda işleme tabi tutulur. queue sırasına göre ama Be set edilmezse trafik drop olur ve bu da traffic policing işlemi olmuş olur.

<mark style="color:red;">**CIR (Committed Information Rate):**</mark>&#x20;

Trafik ile ilgili policy yazarken ne kadarlık bandwidth ayıralım sorusunun karşılığıdır, örneğin 1 Gbps'lik bir interface'in 500 Mbps'lik kısmını bir Qos Policy'si ayırmak istersek, burdaki 500 Mbps bizim CIR'ımız olmuş oluyor.

Aşağıda CIR,Bc ve Tc bağlantı formülü verilmiştir.

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FLwKJOBVkH7tWOYxl6aRY%2Fimage.png?alt=media&#x26;token=8bfd18ec-d6c4-43ae-9442-7cf28a721f1e" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FCm0xPsHZ4MVLOSBVAhmS%2Fimage.png?alt=media&#x26;token=34bea922-9a7f-47ee-aa37-6a1b4ade002e" alt=""><figcaption></figcaption></figure>

Örneğimizde Tc değeri 125 ms olsun;

<div align="left"><figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2F3ndTWryvDRn0ZmC51NYl%2Fimage.png?alt=media&#x26;token=fa243212-2839-4be4-bb9d-bbfdde1ec80c" alt=""><figcaption></figcaption></figure></div>

<mark style="color:red;">**CIR :**</mark> Kullanmak istediğimiz bant genişliğimizdir, örnegin 8 Gbps’ lik bir hattımız var, bunu default Tc degeri olan 0.125sn ile carparsak Burst (Bc) değerimiz yani saniyede yollayabileceğimiz maksimum deger ortaya çıkar.çıkar, sonuc olarak;

<div align="left"><figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FnRZ7357JukCsMuc8w4N6%2Fimage.png?alt=media&#x26;token=614835d1-5993-4dc8-801f-da067a3d05e7" alt=""><figcaption></figcaption></figure></div>

<mark style="color:red;">**TC:**</mark> TC değeri Cisco cihazlarda default olarak 125ms’ dir, dolayısıyla 1 saniyede 8 paket yollanır

<mark style="color:red;">**BC:**</mark> Her bir zaman zaman aralığında (TC zaman aralığı ) gönderilen bit cinsinden data miktarını BC (Committed Burst) olarak ifade ediyoruz.

<mark style="color:red;">**BE:**</mark> Cisco cihazlar 62,5 ms paket gonder, 62,5 ms ise bekle ile mantığı ile çalısıyor, burada Be kısmı bekleme süresidir. Eğer bir sıkısma olursa Be devreye giriyor ve allta soldaki grafik olması gerekirken Be ile altta sağdaki grafik ortaya cıkıyor

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2Fnc0nSw4j1T9x0qTiPRsZ%2Fimage.png?alt=media&#x26;token=2088debe-fc34-4b85-a74a-35e4098acbb1" alt=""><figcaption></figcaption></figure>



<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FiOizdcdNejvSg4RNrHiz%2Fimage.png?alt=media&#x26;token=2c9fcee1-c069-4631-885b-ea4d292a86ca" alt=""><figcaption></figcaption></figure>

### Qos Modelleri

3 Çeşittir;

1. Best Effort
2. IntServ
3. DiffServ

<mark style="color:red;">**Best Effort:**</mark> Bu modelde QoS trafik oluşturan pakeler için herhangi bir işaretleme, öncelik yada process olmaz.&#x20;

Tüm networkler ve interface' leri Best Effort olarak çalışmaktadır. Tüm paketlerin önceliği aynıdır, queue' ya gelen paket ses paketide olsa, ftp paketide olsa, p2p pakette olsa fark etmez ilk giren ilk çıkar (FIFO). Gönderilen paketin hedefe ulaşıp ulaşmadığını, hedefe ulaşırsa ancak anlayabilirz. Yani paket hedefe ulaşmışsa ulaşmıştır, ulaşmamışsa ulaşmamıştır. Tüm paketler eşit şansta, değerde ve önceliktedir

<mark style="color:red;">**Int Serv:**</mark> Bu modelde trafik oluşturan paketler mutlaka hedefe ulaşır ama bu paketlerin hedefe ulaşmasında tüm path' lerde bir bandwidth rezervasyonu yapılması lazım aksi taktirde bandwidth rezevasyonu yapılan cihazdan paket öncelikli çıkar ama sonraki path' lerde bir bandwidth rezervasyonu yok ise hedef router' ına kadar paketler Best Effort gibi çalışır.&#x20;

Yani bu, şu anlama gelir; eğer Int Serv yapılacaksa tüm path' lerde interes ted paketler için bandwidth rezervayonu gerekir. Bu da normalde mümkün değildir, ancak ISP tarafında RSVP ile çözülebilir. Bu da kullanıcı için ek maliyete sebet olur. Fakat bunda RSVP yapılarak tüm path' lerde bandwidth rezerve edileceğinden delay, jitter çok kararlı olarak istenilen seviyelerde kalacaktır.

<mark style="color:red;">**Diff Serv:**</mark> Diff Serv ile trafiği oluşturan paketleri işaretleriz, bu işaretlemeyi kullanırken farklı policy'ler ile ipv4 header' larındaki ToS bitlerini (Type of Serviice) kullanırız. ToS bitleri 8 bitlik bir alanı kapsar ve bu 8 bitlik ToS bitleriyle ister ip **precedence** ve / veya **DSCP** yöntemleri ile işaretleme, marking yapılır.

<mark style="color:red;">**RSVP:**</mark> Resource Reservation Protocol. RSVP' de data trafiği tüm path' lerde sağlanır. Eğer herhangi bir path' de sağlanamazsa o path, protocol sayesinde RSVP Tear Down notification gönderir ve tüm kaynaklar Best Effort çalışmaya devam eder.



**Moduler QoS:**

&#x20;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.

**NBAR: (Network Based Application Recognization):** \
\
Ağdaki trafiği analiz etmeye yarayan, trafiği oluşturan paketlerin hangi uygulamaya ait olduğunu anlamaya yarayan yöntemdir. Bu şekilde protokolü udp ya da tcp olarak yada hangi portları kullanarak çalıştığı ve ona göre qos yapmamızı sağlar. NBAR, paketlerin veri kısmına da bakarak uygulamayı tanımlıyor. Yani peer to peer uygulaması, dinamik bir port da olsa başka bir uygulamanın portu da olsa yine de tespit edilebilir. Ancak paketlerin veri kısmına bakmak cihaz için fazla işlemci gücü demektir. Bu noktada Cisco’nun geliştirdiği Cef (Cisco Express Forwading - Cisco Hızlı İletim) teknolojisi devreye girmektedir. Bu teknoloji yönlendiricilerin daha hızlı anahtarlama yapmasına yaramakla beraber işlemci gücünü azaltmaktadır. Dolayısıyla paketlerin gecikmesi gibi bir durum söz konusu olmaz.&#x20;

Nbar TCP ve UDP bazlı paketlerin ikisi için de geçerlidir. Klasik uygulamalar dışındaki bazı kullanıcıdan kullanıcıya uygulamaları yönlendiriciye tanıtmak gerekir. Bu uygulamalar "bittorrent", "direct connect", "gnutella" veya "kazaa2" gibi uygulamalardır. Bu işlem ilgili PDLM’leri (Packet Description Language Modules - Paket Tanıtma Dil Modülü) yönlendiriciye yüklenerek yapılabilir. Bu şekilde yönlendirici, üzerinde yüklü kullanıcıdan kullanıcıya uygulamaları tanımlayabilir. Kısacası NBAR kullanması durumunda paketler tanımlanacağı için istenilen paket türleri çöpe atılabilir, istenilen paket türleri de işaretlenip öncelik verilmek süretiyle ağda daha hızlı hareket edebilir. Bu şekilde daha iyi ağ bir yönetimi sağlanır. Aşagıda örnek bir NBAR yapılandırması vardır.

<div align="left"><figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FamDH7rQGf12ZGSR9ZnLc%2Fimage.png?alt=media&#x26;token=407d8b30-9c06-4304-a149-22023560fe97" alt=""><figcaption></figcaption></figure></div>

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FEmVLwA6Whnvh4bjrsV65%2Fimage.png?alt=media&#x26;token=fcc2fc1e-8be5-4ad5-8118-40cfd90987fa" alt=""><figcaption></figcaption></figure>

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2F2Fck6gVT3HBfIgHSKs5t%2Fimage.png?alt=media&#x26;token=6cb7baee-e3e1-4475-9d12-321e8909d86b" alt=""><figcaption></figcaption></figure>

QoS yapılırken dikkat edilmesi gerek birkaç unsur var ve QoS yapılırken bir yapım hiyerarşisi var bunları atlamamak gerekli, özetleyecek olursak,



* **Access-list ve Portlar;** öncelikle QoS yapılcak trafiğin iyi belirlenmesi ve bu trafik için bir access-list yazılması gerekli. Bu accesslist yazılırken interested trafiğin yani bizim önceliklendirmek istediğimiz trafiğin iyi belirlenmesi, portların udp ya da tcp iyi analiz edilip belirlenmesi gereklidir.
* **Class-map;** class map asıl olarak QoS’ in interested traffic ile ilişkilendirildiği kısımdır yani policy’ ler QoS yapılcak trafiği classmap’ ler yardımı ile class-map’ lerin içindeki access-list’ ler vasıtası ile öğrenirler. Yani class-map’ ler QoS’ in access-list ile ilişkilendirildiği kısımıdır. Ayrıca class-map’ ler içinde protocol ya da hazır tos bitleride (precedence 1-2-3-4-5-6-7) belirtilebilir.
* &#x20;**Policy Map;** policy-map’ ler ise bir ya da birkaç farklı class-map’ in aynı anda QoS yapılcak interface’ e aktarılmasına yarayan kısımdır yani interface’ ler QoS poltikassını policy-map’ ler sayesinde almaktadırlar. Policy-map’ ler çok geniş kapsamlı yapılardır yani değişik yöntemde yapılcak QoS’ lerin yapılamsını sağlarlar (Hierarchial Parent-Child Policy, Best-Efort Policy, Integrated (benzer servislerin olduğu) Service Policy, Differentiated (ayrılmış, farklı servislerin olduğu)Service
* **Interface Altına Uygularma;** bu 3 aşamadan sonra service-policy output ile port altına uygulanması lazım. Yalnız eğer class-map ya da polcy-map’ lerde değişiklik yapılırsa bu service-poliy port altından silinebiliryor. Bundan dolayı her değişiklikten sonra bu tanımın port altında olduğundan, silinmediğinden emin olmamız lazımdır.
* **Class class-default;** bu komut ise QoS trafiğine sokulmayan diğer tüm trafiklerin match edildiği isteğe bağlı default policy’ dir. Interested trafik dısındaki tüm trafik bu class’ a match eder. Parent policy altındadır.



QoS yöntemi seçilirken, hangi trafiğe (icmp, mail, voip, torrent, ftp, mpls, routing multicast, multicast) yapılcağı ve onlara uygu tos bitlerinin seçiminin de iyi yapılması lazımdır. \
Show policy-map multipoint, show policy-map policyismi gibi birçok komut ile paketlerin match edildiği verify edilebilir.\
&#x20;Voip tarafı olarak en çok önerilen QoS yöntemi ise <mark style="color:blue;background-color:purple;">LLQ’ dur (low latency queueing).</mark>



* **Hierarchial Parent-Child Policy;** Burada parent policy’ ler altına child policy’ ler service-policy olarak girilir. \
  Child policy’ ler altına <mark style="color:yellow;">priority’ ler (öncelik)</mark>; <mark style="color:purple;">percent (yüzdelik)</mark>, ya da <mark style="color:orange;">bandwidth</mark> (band genişliği) miktar olarak girilebilir. \
  <mark style="color:red;">Shape Average</mark> komutu ile Parent policy altında ortalama bandwidth değeri belirlenir.
  * **Bandwidth (bandgenişliği) percent (yüzdelik)**= mevcut trafiğin band genişiğliğini yüzde olarak olarak “%x” kadarını garanti et.
  * **Band genişliği (bandwidth) miktar**; trafiğin eğer interface’ in band genişliği 100 Mbit ise 20 Mbit’ olarak rezerve et, ayır şekilinde rezerve edilebilir. \
    Shape Average komutu’ da parent altında kullanılabilir. Yalnız bandwidth komutu kullanılacaksa, interface altında bir bandwidth değerinin girili olması iyi olacaktır.

Aşağıda bir Hierarchial Parent-Child Policy örneği vardır;

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2Fyx0YgjtJZEvgBFvmsjj3%2Fimage.png?alt=media&#x26;token=193f54b7-bc8a-4ad1-b756-a95ee015b247" alt=""><figcaption></figcaption></figure>

### <mark style="color:red;">QoS’ da IP Header, ToS Bye, ToS Label, IP Precedence ine DSCP bitleri;</mark>

<figure><img src="https://2292156749-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfDBccroFkvJ25uVFqYX%2Fuploads%2FC3CU3hiaCPF5RFwNuu3y%2Fimage.png?alt=media&#x26;token=b986ac0f-3b0d-46b3-baf5-b709d8e88547" alt=""><figcaption></figcaption></figure>

Ip Header’ ı incelendiğinde üzerinde 8 bitlik alanı kaplayan bir ToS byte´ı mevcuttur.

&#x20;Tos bitlerinde 8 bit’ in son iki biti (ECN bitleri), hesaplamalar ve uygulamalarda kullanılmaz, soldan 6 biti kullanılır. QoS uygulanırken marking metodlarında IP Precedence yapılacaksa soldan 3 bit kullanılır (CoS bitleri) ve toplamda 8 tane IP Precedence sınıflandırılması oluşmuş olur. Bu CoS bitleri ile belirlenen ip precedence durumları 111’ den 000’ a kadar Network control (major)’ dan Routine (Best Effort)’ a kadar uzanır. Biz QoS yapmak istediğimizde paketlerin önemine göre ip CoS bitlerini belirleriz. Fakat bazen bu işaretlemeyi yaparken ip precedence yani CoS bitleri bize yetersiz kalabilir. Bu durumda ise daha kapsamlı ve editasyonu yüksek olan DSCP (Differentiated Services Code Point) bitlerini kullanırız. Bu DSCP bitlerini kullanarak aynı zamanda DiffServ metodunu uygulamış oluruz. DSCP bitleri CoS bitlerini’ de kapsayan, CoS bitlerinin soldan altı adet bitine denir. Bu soldan 6 adet DSCP bitlerinin soldan ilk 3’ ü ip precedence’ de kullanılan bitler, sonraki 3 biti ise Delay (gecikme), Throughput (sn’ de geçen bit miktarı) ve Reliability (güvenirlik, paketin dst.’ na mutlaka ulaşması )’ nin belirleneceği bitlerdir. Bunlara göre belirlenen DSCP bitleri bize DSCP name’ leri; cs0’ dan cs7’ ye kadar 22 adet dscp durumununu oluşturur. Burada cs0’ en önemsiz paket, cs7 en önemli paket olarak hiyerarşide yerlerini almaktadırlar



