Alper YALÇINER

Token Bucket Filter ( TBF)’in ne olduğunu daha önceki qos yazımda değinmiştim. Egress trafiği basitçe sınırlamak için kullanılabilecek en basit yöntemdir. sonderece düşük cpu ve ram kullanır.

Token Bucket Filter’ı açıklamak için tüm bulduğum kaynaklarda bir benzetme yapılmış sanırım nasıl çalıştığını anlamanın da tek yoluda bu.

Token Bucket Filter direk olarak türkçeye ” Jeton kova filitresi” şeklinde çevirilebilir. Paketlerin kuyrukta beklediklerini ve kernelden interface’e ( örneğin  kernelden ethernete ) teleferik benzeri bir sistemle kova ile taşındıklarını düşünelim. bir kovanın 10 kbit taşıyabildiğini ve kuyrukta 100 kova olduğunu. Saniyede 100 kova nın sırada döndüğünü ve 1 inci kovaya sıra geldiğini düşünelim. 100 kova X 10 kbit =  saniyede 1000 kbit taşınabileceği manasına gelir. ( 1mbits )
Peki 1Mbit’in üstünde paket geldiğinde ne olacak ? kovalar daha fazlasını taşıyamadığı için paketler sırada yığılıp beklemeye başlayacaklardır.  gelen paketlere geçiş haklarını tanımlayıp sıraya koymak için jeton verelim.Böylece kuyrukta bekleye paketlere de bir düzen getirmiş olduk. Bu sisteme kısaca Token Bucket Filter’deniyor
Burada dikkat edilecek nokta TBF in bir paketin önceliğini değiştirmemesi. Sadece bir tarafdan bir tarafa 1 mbit den daha fazla paket geçirilememesini sağlamakta. kovalar saniyede 1 tur attığı 100 kova olduğu için ve her kova 10 kbit taşıya bildiği için üstü mümkün değildir.
Şimdi örneğimizi biraz gerçek hayata çevirelim. Linux umuz da 100 mbit/s ethernet bağlı yani üzerinden saniyede 1000 kova yük geçirebilir. ama internet bağlantımız ADSL ve upload’ımız 1 mbit. yani 100 kova yük taşıyabilmekte.  Linux’umuzun ethernet üzerinden gönderdiği 1000 kova paket sadece 100 kova taşıyabilen ADSL hattımıza geldiğinde tıkanma ve yığılım meydana gelecek ve sorun yaratacaktır. bunu engellemek için linux da sadece 100 kova çıkmasını sağlamak amacıyla TBF yani bu telefirik sistemini kurarak çıkan paketleri 1 Mbit/s sınırlayabiliriz. ADSL hattında oluşabilecek muhtemel tıkanmaları önleyecektir.

Peki nedir bu 100 kova hikayesi ? Linux kernelinde CONFIG_HZ diye tanımladığımız bir zamanlayıcı vardır. ( jiffies ) , tc-tbf man’i yazıldığında default linux için 100 hz olduğu için TBF saniyede 100 bucket refereans alınarak yazılmış peki bizim sistemimizde bunun değeri kaçtır ?

bash-3.2# cat /proc/config.gz | gunzip - | grep ^CONFIG_HZ= | sed s/CONFIG_HZ=//g
300
bash-3.2#

Şu an var olan sistemimde 300 olduğunu görüyoruz. birazdan bunun önemine değineceğim.

Şimdi TBF parametrelerine göz atalım :

limit or latency “(size -in bytes- of the packets queue)” :

limit  kendisine sıra gelmeden önce kaç byte bilginin kuyrukta bekleyebileceğini belirtir. latency ise ne kadar süreyle bekleyebileceğini belirtir. örneğin  : linux üzerinden 100 mbits ile dosya transferi yapılmak isteniyor ve limitimiz 1 mbits. Kuyrukta bekleyen paketler yığılmaya başlayacaktır. limit 1 mbyte verdiğimizde kuyrukta bekleyen paketler 1 mbyte i geçtiğinde droplanmaya başlayacaktır. bunun yerine lanency vrdiğimizde ise paket belirlenen süre kadar kuyrukta bekleyip hala işlem yapılmadıysa droplanacaktır.

burst/buffer/maxburst “(size -in bytes- of the token queue)” :

Rate için bir kovanın taşıyabileceği maximum byte. yapmış olduğum denemelerde 1540 byte dan düşük bucketlerde iletişim de aksama oldu, daha ufağını kullanmamaya özen gösterin.

rate :

sanırım fazla açıklamaya gerek yok kısaca : rate 256kbit şeklinde kullanıyor 1 mbits hat için rate 1000kbit

peakrate :

kurmuş olduğumuz yapının maksimum taşıyabileceği bant genişliği.

mtu/minburst :

Kabaca peakrate . bir kovanın kaç byte taşıyabileceğini işaret eder. örneğin 1 mbits için bir TBF oluşturduğumuzda benim sahip olduğum sistemde HZ=300 olduğuna göre 1000/300=3.3… yani 3 kbyte lık bir bucket yeterli olacaktır.

örnek :

tc qdisc add dev wlan0 root tbf rate 220kbit latency 50ms burst 1540

bu şekilde wlan0 interface imiz üzerinde 220 kbit bant genişliği 50 ms gecikme ve 1540 byte bucket tanımlayıp 220 kbits bant genişliği elde etmemiz gerekiyor ki çalışmıyor ! 140 kbit gibi bir bant genişliği uyguluyor. hemen tbf-man inda ki örneği yapalım :

bash-3.2# tc qdisc add dev wlan0 root tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1mbit minburst 1540
bash-3.2#
ilginç buda çalışmıyor. 0.5 mbit değil 368 kbit gibi bir değer görüyor.

bash-3.2# tc qdisc add dev wlan0 root tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1mbit minburst 5kb
bash-3.2#

şeklinde örneğimizi değiştirdiğimiz de ise sorunsuz olarak çalışıyor ( ölçümleri local de yaptım ) 5kb minburst = 5*300 = 1.5 mbit gibi bir değere denk geliyor. ilk örneğimizin de sorunsuz çalışmış olması lazımdı. tc-tbf man inda verilmiş olan değerler HZ 100 için verildiği için en kötü ihtimal daha yüksek bant genişliği elde etmemiz gerekirdi. ama aksine değerler oldukça düşük çıkıyor.  Sebepleri MTU ile alakalı veya HZ ile alakalı olabilir. açıkçası incelemiyorum, pek zevk almadığımı itiraf etmeliyim. internetteki çalışan tüm örneklerde burst 10k verildiğini belirteyim. 5k ve üstü burst verdiğiniz sürece prolemsiz olarak kullanabilirsiniz.

Daha önceki QOS yazımda Priority queue ne demek anlatmıştım.  Şimdi linux üzerinde bunlara biraz daha yakından bakalım. öncelikle belirtmek istediğim nokta, FIFO hemen hemen hiç kullanılmamakta priority ise bant genişliği yönetemediği için CBQ, TBF gibi algoritmalarla beraber kullanılmaktadır. Ne yaptığınızı bilmiyorsanız mümkün olduğunca tek başına kullanmaktan kaçının. Burada verecek olduğum teorik bilgiler diğer qos algoritmalarıyla beraber kullanıldığında priority queuing’i doğru kullanmak için son derece önemlidir.

FIFO :

Kısaca ilk giren ilk çıkar. interface’imiz üzerinde gelen network paketlerinden ilk ulaşan multiplexer dan geçerek fifo queue’ye girer.  sonra gelen arkasından girer ve precess olur. dolayısyla ilk giren paket ilk işlendiği için ilk çıkan olur. fifo ile ilgili çok ayrıntıya girmeyeceğim. günlük hayatta fifo ile yapılan qos ayarlarının gerçekten pek faydası olmadığı için hemen hemen hiç kullanılmamaktadır. yinede kısaca komutlarını vereyim.

bash-3.2# tc qdisc add dev wlan0 root pfifo limit 10

Default olarak bulunur.

Prio ( Priority ) queue :

Hemen resimle açıklamaya başlayalım.

Sanırım resim yeterince açıklayıcı. 8 adet paket akışımız var, 3 adet önceliklendirme ile bölünmüş yapıya giriyor. Classifier aracılığıyla tanımlandırılıp sınıflandırılan paketler önceliklerine göre class’lara yönlendiriliyorlar. flow3 en yüksek öncelikli paket olduğu için Highest priority 7 ve 2 orta derece önceliklendirilerek Middle’a diğer paketler ise lowest a gönderiliyor. Gerçektende yapmış oldğumuz priority planımız bu şekilde olmalı. priority queuing yaparken. yüksek öncelikli olarak belirlediğimiz class’a tüm paketleri gönderdiğimizde orada meydana gelecek yoğunluk ve gecikmeyi sanırım vurgulamama gerek yok.

Komut açıklamasına girmeden önce TOS nedir ? sorusuna yüzeysel olarak açıklık getirsek iyi olacak.

TOS RFC1349 da belirtilmiş olan Type of Service in the Internet Protocol Suite’dir hemen tcpdump -v -v diyerek gelen paketlerin içerisinde tos field’imizi görelim ( tcpdump sisteminizde yoksa kurunuz )  :

06:59:30.158310 0us CF +QoS IP (tos 0×0, ttl 64, id 53669, offset 0, flags [DF], proto TCP (6), length 60)
10.70.20.48.53812 > 10.80.20.1.telnet: Flags [S], cksum 0×0a6e (correct), seq 818486010, win 5840, options [mss 1460,sackO

tos 0x0 < tüm tcp ip paketlerinde tos field bulunuyor. En kaba tabiriyle tos field QOS ve routing yapılarında paketlerin tos field ina bakarak işlem yapılabilmesi için çıkartılmıştır. Böylece router üzerine gelen paketin tos field'i referans alınarak paket önceliklendirmesi veya routing planları yapılabilir. örneğin OSPF le TOS a bağlı routing planlaması yapılabilir. günümüzde TOS routerlar da olması şart bir özellik değildir. TOS field in içeriğine bakacak olursak nasıl çalıştığının daha iyi anlaşılacağına inanıyorum.

Binary Decimal  Manası
-----------------------------------------
1000   8         Minimze delay En az gecikme (md)
0100   4         Maximize throughput  Cikis en yuksek "bant genisligi"(mt)
0010   2         Maximize reliability Maksimum kararlılık(mr)
0001   1         Minimize monetary cost en dusuk maliyet(mmc)
0000   0         Normal Service

Sanırım gayet açıklayıcı, TOS field değer hesaplaması linux dosya izin yapısına benzer. örneğin : bir paketin en az gecikme ile "8" en yüksek bant genişliği ile "4" ve en yüksek kararlılıkla "2" gitmesini istiyorsak : 8+4+2=14  = 1110 = e hex yapması lazım ama ! burda sağ da görünmeyen bir değeri "0" olan en sağda bitimiz var onu eklememiz gerekiyor. ( TOS a eklenmiştir ) sonuçta değer binary olarak iki ye katlanıyor 11100 = 16+8+4 = 28 = 1c

Daha fazla için man tc-prio ve RFC 1249 a bakınız. Daha sonraki yazılarımda çok daha iyi anlaşılacağı için daha fazla kafa karışıklığı yaratmak istemiyorum.

TOS gibi kavramlar, QOS içeriisinde yer alsa ve linux hepsini desteklesede TOS kullanarak QOS yapan bir firma şimdiye kadar görmedim. Değişik firmalara ait router ve firewall ların ortak kullanımlarında gerekli olabilir yinede kullanım yerleri çok azdır. Her zaman sistem ve network dizaynında "Design As Simple As Possible" prensipinden uzaklaşmamak gerekir. Linux default olarak TOS içermez tüm paketler tos 0x0 olarak gönderilir. örneklere geçelim.

iptables henüz görmememize rağmen önce iptables ile paketlerimizin TOS'field larını işaretleyelim.

bash-3.2# iptables -A PREROUTING -t mangle -p tcp --dport 22 -j TOS --set-tos Minimize-Delay
bash-3.2#

iptables ile dışarıya giden ssh isteklerimizin TOS'unu Minimize Delay  olarak işaretledik. şimdi hemen tcpdump ile bakalım.

10.70.20.1 e ssh bağlantısı yapıyoruz ve tcpdump -v -v ile bakıyoruz.

13:03:47.362157 0us CF +QoS IP (tos 0x10, ttl 64, id 36525, offset 0, flags [DF], proto TCP (6), length 52)
10.70.20.3.34663 > 10.70.20.1.ssh: Flags [.], cksum 0×3d94 (correct), seq 2213, ack 7657, win 629, options [nop,nop,TS val 712464 ecr 734233734], length 0

tos 0×10 = hex 16 = 10000 en sondaki 0 kalıdırıyoruz = 1000 = 8 decimal yukarıdaki tablomuzda göreceğiniz üzere 8 = Minimze delay En az gecikme (md) gerçektende paketlerimiz en az gecikme olarak işaretlenmiş. şimdi tc ile bunu prioritize edelim.

bash-3.2# tc qdisc add dev wlan0 root handle 1:0 prio
bash-3.2# tc filter add dev wlan0 parent 1:0 prio 1 protocol ip u32 match ip tos 0×10 0xff flowid 1:1
bash-3.2#

Ne yaptık kısaca anlatalım :

priority için 1: handle’i ile bir qdisc oluşturduk.

tc; interface ( device ) wlan0 için filter oluştur. parent olarak 1:0 kullan ( bir önceki satırda oluşturduğumuz qdisc ) , bu filter i priority 1 olarak atadık ( 2.3.4 oluşturulacağını düşünelim ), protocol ip, ip protokokü olduğunu gösterdik. filter imizin u32 filter olduğunu söyledik, match ip tos : tos filed 0×10 olan paketler için 0×10*0xff= 0×10 , flowid 1:1 bu filter’a uyan paketler ilgili class a 1:1 flow id ( tanımlaması ) ile gidecekler.

Burada filter’ımız FWMARK, route gibi değerler olabilirdi. bunlarla ilgili bol bol örnek yapacağımız için şimdilik değinmiyorum. TOS konusuna özelilkle değinme sebebim güncel router ve switchlerin bir çoğunun bunu destekliyor olması.

QOS konusuna ve network’e yabancı olan arkadaşlar için karışık olabilir. demoralize olmamanızı öneririm. diğer QOS algoritmaları linux altında çok daha basit ve anlaşılır.

eklediğimiz kuralları silelim :

bash-3.2# tc qdisc del dev wlan0 root handle 1:0 prio
bash-3.2#

TC nedir ?

TC iproute2 paketinin içerisinde gelen, hemen hemen her linux dağıtımında paket olarak bulunabilen bir qos yapılandırma aracıdır. ” Traffic Control ” tc komutunun nasıl kullanıldığını anlamak içn öncelikle daha önceki yazılarımı okumamış arkadaşların 1′inci ve 2′inci qos yazılarımı mutlaka okumalarını öneriyorum. aksi takdirde bir çok terim askıda kalacaktır. Hemen kullanımına geçelim.

iproute2 paketi Cisco CLI’i örnek alınarak dizayn edilmiştir. daha önceki yazılarımı okuyup buradaki terimlere yabancı olmayan arkadaşlar, genel switch ve router CLI larina yabancı değilse kolayca bundan sonrasını çözeceklerdir. Madem Cisco CLI örnek alınarak yapılandırılmış bizde ona yaklaşır gibi adım adım çözelim.

örneğin : interface wlan0 üzerindeki qos yapısını nasıl görürüz ?

bash-3.2# tc ?
Object “?” is unknown, try “tc help”.
bash-3.2# tc help
Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }
tc [-force] -batch file
where  OBJECT := { qdisc | class | filter | action | monitor }
OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -p[retty] | -b[atch] [file] }
bash-3.2#

Cisco CLI’i gibi “?” desteklemiyor ama bizi help için yönlendiriyor. güzel elimizde neler var bakalım. OBJECT olarak qdisc | class | filter | action | monitor girebiliyormuşuz qdisc ile devam edelim.

bash-3.2# tc qdisc help
Usage: tc qdisc [ add | del | replace | change | show ] dev STRING
[ handle QHANDLE ] [ root | ingress | parent CLASSID ]
[ estimator INTERVAL TIME_CONSTANT ]
[ stab [ help | STAB_OPTIONS] ]
[ [ QDISC_KIND ] [ help | OPTIONS ] ]

tc qdisc show [ dev STRING ] [ingress]
Where:
QDISC_KIND := { [p|b]fifo | tbf | prio | cbq | red | etc. }
OPTIONS := … try tc qdisc add <desired QDISC_KIND> help
STAB_OPTIONS := … try tc qdisc add stab help
bash-3.2#

Güzel  | add | del | replace | change | show | diyebiliyormuşuz . qos yapısını görmek istediğimiz için show dememiz gerekiyor.

bash-3.2# tc qdisc show
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wmaster0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
bash-3.2#

tataaa ! kısa yoldan sonuca ulaştık . yukarıdaki ” tc qdisc help” dediğimizdeki parametrelere bakarsak device’ları ayrı ayrı görüntüleyebileceğimizide görüyoruz. Sanırım CLI da yolumuzu nasıl bulacağımızı kısaca anladık. şimdi kullanımı daha iyi anlamak için bir kaç örneğe göz atalım.

basit bir kural atayalım ve kaldıralım :

mevcut durum :
bash-3.2# tc qdisc show dev wlan0
qdisc pfifo_fast 0: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

kuralımızı ekleyelim :
bash-3.2# tc qdisc add dev wlan0 root handle 1:0 htb

eklediğimiz kuralı görüntüleyelim :
bash-3.2# tc qdisc show dev wlan0
qdisc htb 1: root r2q 10 default 0 direct_packets_stat 0
eklediğimiz kuralı silelim :

bash-3.2# tc qdisc del dev wlan0 root handle 1:0 htb

gayet basit hemen eklediğimiz kuralı inceleyelim :

tc qdisc :

bash-3.2#tc qdisc add \ (1)
> dev wlan0 \ (2)
> root \ (3)
> handle 1:0 \ (4)
> htb (5)

1. qdisc kural ekliyoruz. kaldırırken gördüğümüz gibi “del” diyerek silebilirizde.
2. eklemek istediğimiz device’i yani interface’i belirtiyoruz buradaki gibi wlan0 veya eth0 vb .
3. eklediğimiz qdisc’in root yani en üst seviye bir qdisc olduğunu belirtiyoruz
4. Handle değerlerini giriyoruz.  qdisc olduğu için minor 0 olmak zorundaydı. major değeri geleneksel olarak en üsteki handle 1 ile başladığı için bizde öyle yaptık. 1-65534 arası bir rakam olabilirdi. buna benzer bir örnekte “1:” şeklinde girilip minor verilmemesi minor=0 demektir.
5. qdisc’in yani kullanacak olduğumuz qos algoritmasının ismini giriyoruz. bundan sonra htb ile ilgili diğer değerler girilecek. bu konulara daha sonra değineceğim için şimdilik geçiyorum..

tc class :

bash-3.2# tc class add dev wlan0 parent 1:1 classid 1:6 htb rate 256kbit ceil 512kbit

bash-3.2# tc class show dev wlan0
class htb 1:6 root prio 0 rate 256000bit ceil 512000bit burst 1599b cburst 1599b
bash-3.2#

açıklayalım :

bash-3.2# tc class add    \ (1)
>                  dev wlan0     \ (2)
>                  parent 1:1   \ (3)
>                  classid 1:6  \ (4)
>                  htb          \ (5)
>                  rate 256kbit \ (6)
>                  ceil 512kbit   (7)

1. class ekleyeceğimizi belirttik.
2. interface imizi belirttik. wlan0 device’i
3. parent ( ana ) handle imizi belirtiyoruz. yukarıdaki örnekde ki 1:0 handle ini gösterdik 1:1 diyerek yeni bir class bağlıyoruz.
4. bu class i tanımlayan unique handler i gösteriyoruz. bu sayede diğer objeler bu class a ulaşabilecekler. class lar qdisc içeremiyecekleri için classid’de minor handle 0 olamaz !
5. htb algoritmasını belirtiyoruz
6. ve 7. parametreleri daha sonra htb yi incelerken göreceğiz.

tc filter :

bash-3.2# tc filter add dev wlan0 parent 1:0 protocol ip prio 5 u32 match ip dport 22 0xffff match ip tos 0×10 0xff flowid 1:6 police rate 32000bps burst 10240 mpu 0 action drop/continue
bash-3.2# tc filter show dev wlan0
filter parent 1: protocol ip pref 5 u32
filter parent 1: protocol ip pref 5 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:6
match 00000016/0000ffff at 20
match 00100000/00ff0000 at 0
police 0×3 rate 256000bit burst 10Kb mtu 2Kb action drop/continue overhead 0b
ref 1 bind 1

bash-3.2#

açıklayalım :

bash-3.2# tc filter add \ (1)

>    dev wlan0 \ (2)

> parent 1:0 \ (3)

>   protocol ip \ (4)

>   prio 5 \ (5)

>   u32 \ (6)

>   match ip port 22 0xffff \ (7)

>   match ip tos 0×10 0xff \ (8)

>   flowid 1:6 \ (9)

>   police \ (10)

>   rate 32000 bps \ (11)

>   burst 10240 \ (12)

>   mpu 0 \ (13)

>   action drop/continue (14)

1. Filter ekliyoruz ( del ile de silebilirdik )

2. wlan0 interface imiz üzerinde yapmak istediğimizi belirtiyoruz.
3. bu filter in bağlayacağımız  qdisc’i belirtiyoruz.
4. filter’in ip protokolünde çalışacağını belirtiyoruz.
5. filter’in priority’sini belirliyoruz ( öncelik ). ip route da olduğu gibi priority ve pref aynı manada kullanılabilir.
6. tc filter tarafından ihtiyaç duyulan classifier.
7. 8 ile beraber u32 parametreleridir. burada interaktif olarak 22 nolu porta gelen ( ssh ) TOS belirtilmiştir. bu şartlara uyan paketler için filter’imiz aktif olacaktır.
8. 7 ile birlikte u32 parametrelerini tamamlar.
9. flowid filter şartlarına uyan paketlerin gönderileceği qdisc veya class in handle ini belirtiyoruz. bir önceki örnekte eklemiş olduğumuz class a gönderdik.
10. policier. filterlarda opsiyonel olarak policier ekleyebilirsiniz.
11. 32000 bits per second’ üzerine çıktığında policier in görev yapmasını istediğimizi belirtik.
12. burst htb örnekleri yaptığımızda daha iyi anlaşılacak kısaca en fazla izin verilen paket.
13. kısaca bir paketin içerebileceği minumum byte i gösterir ( minumum policed unit ) ethernet frame leri gibi paketlerde 64 byte a eşit gelir. ayırt etmeden tüm paketlerin işlenmesi için “0″ demeliyiz.
14. policier de belirttiğimiz değerler aşılıyorsa ne yapılacağı ( burada drop ) aşılmamışsa ne yapılacağı gösteriliyor ( burada continue )

Kısaca ne yaptık ?

1. Bir qdisc oluşturarak htb kullanacağımızı belirttik.
2. oluşturulan qdisc e class atayarak bant genişliği tanımladık.
3. filter oluşturarak özellikle hangi servisin ( burada ssh ) ve policier la hangi şartlar içinde bu class a dahil olacağını belirttik.

Linux altında QOS’u daha iyi anlamak için QOS bileşenlerine daha yakından bakalım.

Geleneksel Element	Linux Bileşeni
shaping	Class
scheduling	Qdisc
classifying	Filter Classfilter
policing	policier filter
dropping	policier filter
marking	dsmark

.

Kavramları daha iyi anlamak için bir önceki yazımdaki resimden faydalanacağım.

1. qdisc :

Qdisc, tüm linux trafik kontrol sisteminin üzerine inşa edildiği ana bloktur, aynı zamanda queuing discipline şeklinde de bilinir. ” Kuyruk yöneticisi gibi çevrilebilir sanırım türkçeye”

qdisc gelen trafic için yapılandırıldığında “ingress qdisc” giden için yapılandırıldığında ise “egress qdisc” olarak isimlendirilir. daha önceki QOS yazımdan hatırlayacağınız üzere, Gelen trafik üzerinde söz hakkımız olmadığını belirtmiştim. Günlük kullanımda gerçekten bir faydası olmasada qdisc bize bu sınırlamayı yapma imkanı sunar. egress qdisc de child class tanımlayabildiğimiz halde ingress de sadece filter tanımı yapıp child class tanımı yapamayız.qdisck daha sonra değineceğimiz gibi classless ve classfull olmak üzere ikiye ayrılırlar.

2. Class :

Class’i QOS için tanımlamanın en güzel yolu “tasnif etmek” manasında kullanmaktır. gelen bir paketi tasnif ederek class’lara ayırabilir, class’ların içerisine childclass oluşturulabilir. hatta bu classlar içerisinde yukarıdaki resimde görüldüğü gibi yeni qdisc’ ler tanımlanabilir. Özellikle qos’a yabancı kişiler içn burada bir anlam kopukluğu olabilir. örneklendirirsek daha iyi anlaşılacağını sanıyorum.

Şirketimize gelen 4 mbit hattımız üzerinde şu şekilde bir plan yapalım : 4 mbit hattımız root qdisc tir. içinden server ler için 2 mbit ayırmak için bir child class ve içerisine qdisck tanımlarız. sonra 756 kbit mail server ler için ayırmak istiyoruz bir child  class daha tanımlıyoruz. aynı şekilde 256k voice hizmeti için ve manager ler için 1  mbit ayırıyoruz. böylece iş planımız aşağıdaki gibi oluyor.

Burada 4 mbit root qdisc altına 2 adet child class yöneticiler için 1 mbit server ler için 2 mbit tanımlamamız gerekiyor. Sonra Server Child class i altına yeniden child class oluşturarak mail child class 1 mbit voice 256kbit oluşturuyoruz.

Class lar bize hepsi için ayrı ayrı filter tanımlamamızı sağlar. Bunların yanında dikkat edilmesi gereken diğer nokta, QOS sadece bant genişliği olmadığı için class lar bant genişliği hariç örneğin önceliklendirme için kullanılabilirler. Buradaki örnek daha kolay anlaşılacağını umduğum için bant genişliği olarak verilmiştir.

Hiç bir class barındırmayan class’lar leaf class, barındıranlar ise inner class ( veya root ) olarak adlandırılırlar.

3. Filter:

Filter kavramının daha iyi anlaşılabilmesi için önce Classifier ve Policier’a girsek iyi olacak.

3.1. Classifier :

Classifier lar filter objeler veya araçlarıdır. Bir paket in yada paket metadata’snın tanımlanması amacı ile kullanılırlar.

” Paket metadata :fiziksel link ( osi layer 1 ) üzeri bilgileri içerir. kim kiminle haberleşiyor  , nasıl haberleşiyor ? , ne zaman ? , nerede ? gibi bilgilerdir. örneğin. kaynak ve hedef ip adresleri , protokol ( tcp udp ) , port ( tcp 80 portu ) , routing bilgileri  gibi bilgilerin genel adı.  örneğin : Email / Webmail sender / receiver / subject, IM contact list / status / sender / receiver, route update in routing protocol,”

Linux trafik kontrolünde kullanılan Classifier lar kısaca :

• U32 : En çok kullanılan ve en gelişmiş Classifier ” Sınıflandırıcı ” dır.  Paket header’da bulunan herhangi bir şey u32 ile sınıflandırıcı olarak kullanılabilir.
• filter fw : fwmark
• filter route
• tcindex

Classifier’lar qos örnekleri yaptıkça daha çok anlaşılacaktır.

3.2 Policer :

Policer “policing” QOS içerisinde gelen paketin belirlenen trafiğin üstünde veya altında olmasına göre işlem yaparlar. örneğin : istenilen trafikden aşağısı geliyorsa paket geçsin üstüne çıkıldı ise drop ( düşürme göz ardı etme ) yapılsın şeklinde. shaper lardan farkı paketin bir kuyuruk işlemine sokularak bekletilememesidir.

Sonuç olarak Filter’lar classifier ve policer leri içerirler, bir filter içerisinde mutlaka Classifier olmak zorundadır. Policier Classifier ile birlikte olabilir veya kullanılmaya bilir.

4. Handle :

Her class ve classfull qdisc  trafik kontrol yapısında bir tanımlayıcıya ihtiyaç duyar. Linux trafik kontrol sisteminde bu tanımlayıcılar numara ile yapılır.bu numaralandırma sistemi Major ve Minor olmak üzere iki öğeye sahiptir.  <major>:<minor>  şeklinde kullanılırlar. örneğin : 1:0 major ( ana ) ve minor ( alt ) sayıların kullanılması aşağıdaki kurallara göre yapılmalıdır.

• Major sayılar için linux kernelinde bir sınırlama olmamakla beraber , aynı parente ait tüm objelerin, bir major ( ana ) handle  numarası paylaşması gerekir. kural olmamakla beraber genellikle root qdisc e atanmış olan numaralar 1 ile başlarlar.
• Minor sayılar kenrel tarafından eğer 0 ise qdisc başka bir rakam ise class olarak tanımlanır. bir parent içerisinde aynı numaraya sahip birden fazla class olamaz.
• ffff:0 ( 65535:0 ) numarası, 0:0 in giden ( eggress )trafik için root qdisc olması için ayrıldığı gibi gelen trafik ( ingress ) için qdisc olarak rezerve edilmiştir kullanılamaz.

Handle konusunun yapacak olduğumuz örneklerle daha iyi anlaşılacağını düşünüyorum.

5. Shaper :

Shaper’lar ( Şekillendirici ) basitçe geçen trafiğin bant genişliğini ( rate ) şekillendirmek için kullanılırlar. Söz konusu işlemi yapabilmek için gelen paketler izin verilen miktarın üzerinde bir paket genişliği istiyorsa, örneğin 1 Mbps bant genişliği sınırlaması yaptık ve 2 mbits bantgenişliğinde trafik geçmek istiyor. söz konusu paketleri bir kuyuruğa atıp bekleterek bu hızı geçmemesi sağlanır. Policier de tanımlanan filter’lar ise shaper’dan farklı olarak direk olarak fazladan gelen paketi droplamaktadır.

Kernel : linux altında QOS için, genel olarak linux kernelinde derlenmiş veya modul olarak bulunması gerelenler :

CONFIG_NET_SCH_CBQ=m

CONFIG_NET_SCH_HTB=m

CONFIG_NET_SCH_CSZ=m

CONFIG_NET_SCH_PRIO=m

CONFIG_NET_SCH_RED=m

CONFIG_NET_SCH_SFQ=m

CONFIG_NET_SCH_TEQL=m

CONFIG_NET_SCH_TBF=m

CONFIG_NET_SCH_GRED=m

CONFIG_NET_SCH_DSMARK=m

CONFIG_NET_SCH_INGRESS=m

CONFIG_NET_QOS=y

CONFIG_NET_ESTIMATOR=y

CONFIG_NET_CLS=y

CONFIG_NET_CLS_TCINDEX=m

CONFIG_NET_CLS_ROUTE4=m

CONFIG_NET_CLS_ROUTE=m

CONFIG_NET_CLS_FW=m

CONFIG_NET_CLS_U32=m

CONFIG_NET_CLS_RSVP=m

CONFIG_NET_CLS_RSVP6=m

CONFIG_NET_CLS_POLICE=y

Daha önce QOS un ne olduğu hakkında kısa bir yazım olmuştu QOS kavramına yabancı arkadaşların öne o yazıyı okumalarını tavsiye ederim.  Bundan sonra linux altında qos konusuna daha ayrıntılı olarak değineceğim. en çok referans olarak kullanmayı düşündüğüm site Leonardo Balliache’ e ait sitedir.

QOS bugün gitgide artan internet kullanımı, internetten alınan ses vb hizmetler dolayısıyla özellikle şirket kullanımında kaçınılmaz olmuştur. Özellikle vurgulamak istediğim bir nokta var, QOS denildiğinde ilk akla gelen kısıtlamadır. Bu görüş yerine göre doğru olsada genel olarak yanlıştır. QOS özgürlüktür ! ister büyük bir şirkette olun, ister evinizde ufak bir network de, hatta kendi kendinize tek bir host bile olsanız QOS kullanmanın sağladığı avantajlar sayısızdır. İnternetten bir dosya download ettiğinizde, torrent den dosyaları download için sıraladığınızda diğer insanların, hatta sizin kendi uygulamalarınızın çalışma kalitesinin düşmesi kaçınılmazdır. QOS size tüm bunları göz ardı etme imkanı sunar. iyi yapılandırılmış bir qos la internet yada network de neler olacağını, çalıştırmış olduğunuz proğramın diğer çalışmalarınızı nasıl etkileyeceğini düşünmeksizin özgürce internetin tadını çıkarabilirsiniz.

Linux QOS konusunda özellikle diğer user ların geliştirmiş olduğu extension’larla inanılmaz özellikler sunuyor. Klasik router ve firewall ların sağladığı tüm QOS algoritmalarını sağlarken, iptables entegrasyonu ile resmen oyuncak halini alıyor.

Hemen linux da qos çalışma mantığına girelim.

En basit anlatımıyla bilgisayarımıza gelen bir paketin izlediği yol, NIC0 örneğin eth0 a fiziksel kablo ile gelen paket linux networking kodu tarafından yorumlanarak NIC1 e ( ikinci interface ) oradan fiziksel kablo ile bir sonraki hedefine yollanıyor.  Şimdi QOS un buradaki yerini daha iyi anlamak için Linux Networking Code a daha yakından bakalım.

Yukarıdaki şekilde kernelin gelen bir paketi nasıl process ettiği  ve gönderdiği görülmektedir. “input De-multiplexing” denilen kısım gelen paketin hedefinin local yani linux un kendisine mi yoksa, başka bir hedefemi gönderildiğini analiz eder, şayet paket başka bir hedefe gönderilmişse, FORWARDING block denilen kısam gönderir, burada routing table a bakılır paket herhangi bir rule ile kesişiyorsa çıkış için OUTPUT QUEUE block una gönderir. Paket kendisine geldi ise , bir üst katmana göndererek paketi işlemeye gönderir, işlenen paket yine FORWARDING block a döndürülerek hedefine yollanır.  İşte bu noktada linux QOS devreye girer, burada yapılan işlemlere az sonra değineceğiz.

Yukardaki şekil Linux networking code nasıl çalıştığı hakkında fikir versede tamamen yeterli değil, gelen paketleri, local bir hizmet vermeyeceğimiz durumda De_multiplexing den geçirmek veya daha yüksek katmana göndermek istemeyiz, Dahada basite imdirgenmiş hali Policy ( kural ) koyarak istemediğimiz paketleri sınıflandırmak isteriz ( Netfilter/ iptables )

Sanırım bu şekil çok daha açıklayıcı kısaca : NIC e gelen paket → Ingress policing ( giriş kuralları ) bu paket istediğimiz standartlara uyuyormu ?uymayan paketler göz ardı edilir. uyan paketler → Inpur De-multiplexing → forwarding → Output Queuing QOS un işlendiği yer → çıkış interface.

Paketlerin işlenme sırasını gördüğümüze göre en basit qos algoritması fifo ya bir göz atalım( firs in first out = ilk giren ilk çıkar )

fifo ( ilk giren ilk çıkar ) mantığında yukardaki şekilde görüldüğü gibi , 16 paketin kuyrukda buluna bildiği bir sistemimiz olduğunu düşünelim. 1 ve 2 nolu paketler işlenip işlerini bitirerek sistemden çıkmış durumdalar 18 nolu paket yeni işlenmeye başlamış olmakla beraber henüz kuyruğa girebilmiş değildir. Bu işlem sırasında network den paket gelmeye devam ettiğini düşünelim, gitgide kuyrukda ( sırada ) bekleyen paketlerimiz çoğaldı. Kernel in kuyruğu bir paket terk etmeden diğerini alması söz konusu değildir. Bu şart altında belirli sayıdan fazla gelen paketler gecikmeye veya düşürülmeye başlayacaktır.

Şimdi başka bir resime bakalım :

Ne güzel değilmi . Qdisc içerisinde birden fazla queue tanımlanmış. Bir paket qdisc e gelince ( Queuing Discipline ) , 1 inci kural ( Filter ) bu paketin kendisine uyup uymadığına bakıyor, uyuyorsa 1 inci Class a yani qos kuralımıza yolluyor, uymuyorsa ikinci ve üçüncü kural bu paketin kendilerine uyup uymadıklarına sırasıyla bakıyorlar, şekilde görüldüğü gibi bir qos class’ı için birden fazla filter tanımlanabilir.

Bunun qdisc’ in çalışma mantığını anlamamız için gayet yeterli olduğuna inanıyorum . Gelen paket filter tarafından kontrol ediyor, standartları sağlıyorsa yüksek öncelikli kuyruğuna atılıyor ve TBF ile 1 Mbps bant genişliğine  kavuşuyor, şayet uymuyorsa yani geri kalan tüm paketler düşük öncelikle default kuyruğa gönderiliyor.

örnek : eğer kişi webde gezmek istiyorsa 1 mbit bant genişliği ile yüksek öncelikli işlem görür, geriye kalan tüm işlemleri düşük önceliklidir tanımı yapılmış olabilir.

Bu kavramlarla daha fazla oyalanmanın faydası olduğunu sanmıyorum, genel olarak linux da QOS un nasıl çalıştığını anlamış olduk, geri kalan ayrıntılar bundan sonraki uygulamalarda daha net anlaşılacaktır.

Linux hangi qos algoritmalarını destekler ?

* Class Based Queue (CBQ)
* Token Bucket Flow (TBF)
* Clark-Shenker-Zhang (CSZ)
* First In First Out (FIFO)
* Priority Traffic Equalizer (TEQL)
* Stochastic Fair Queuing (SFQ)
* Asynchronous Transfer Mode (ATM)
* Random Early Detection (RED)
* Generalized RED (GRED)
* Diff-Serv Marker (DS_MARK)

Gre Nedir ? :

Generic Routing Encapsulation (GRE) Cisco tarafından geliştirilen bir tunneling protokoldür, multiple protcols ve multiplexing destekler. GRE tunnel tamamen statless olarak dizayn edilmiştir. yani site lar karşı tarafın ulaşılabilir olup olmadığı hakkında hiç bir bilgi tutmaz.

Tunneling protokolleri ne için kullanırız ?

örnek bir network çizelim :

Yukarıdaki örnekdeki gibi bir yapıya sahipsek, ve 2 site ( bölge ) içerisinde bulunan istemci veya server’ların birbirlerine ulaşması gerekiyorsa, söz konusu erişimin diğer internet kullanıcıları tarafından ulaşılamaması gerekiyorsa;  Tunneling protokollerini kullanırız.

Linux altında Gre tunneling yapmak için şu şekilde bir sıralama yapmalıyız :

1. Kernel Desteğini sağlamak,

2. Tunnel device ini oluşturmak ( /dev/eth0 gibi )

3. Tunnel device a ip adresi atamak

4. routing tanımlamalarını yapmak.

Şİmdi site2 için örnek bir gre yapılandırması yapalım :

1. Kernel de ip_gre module olarak derlendiyse modulümüzü yükleyelim.

modprobe ip_gre

2. Tunnel device oluşturalım.

ip tunnel add netb mode gre remote 195.174.6.140 local 85.8.5.43 ttl 255

iproute2 ye yeni tunnel ekle çalışma modu gre olsun device ismi netb olsun, bağlanacak olduğun karşı tarafın internet ip adresi 195.174.6.140 dır. bizim internet  ip adresimiz ise 85.8.5.43 dir ulaşmak için  ttl ( time to live ) ise 255 dir diye tanımladık.

3. tunnel device imiza ip adresimizi verelim

ip address add dev netb 192.168.2.12 peer 10.70.20.80

4. netb device ini up yapalım;

ip link set netb up

5. routing imizi tanımlayalım

ip addr add 192.168.2.12/24 dev netb

ip route add 10.70.20.0/24 dev netb

Burada dikkatinizi çekmek istediğim nokta, netb device i için routing bilgilerini girdik ama localden ulaşacak istemciler için ayrıca nat yapılandırması yapmanız gerekiyor. bu ayarlar sadece router’in kendisinin ulaşması içindir. netb device inin ip ve routing yapılandırmaları için diğer dökümanlarıma başvurabilirsiniz.

Aynı ayarları ip adreslerini düzenleyerek karşı tarafada yapınız. Karşı tarafda linux olmaması ihtmaline karşı ( ve elimde karşı tarafa koyacak linux olmamasından dolayı ) örneklemeyi linux ile yapmayacağım.

1. FreeBSD GRE ile Sİte1 i yapılandırmak :

[root@gariban ~]# kldload ip_gre

[root@gariban ~]# ifconfig gre0 create

[root@gariban ~]#  ifconfig gre0 tunnel  195.174.6.140  85.8.5.43

[root@gariban ~]# ifconfig gre0 inet 10.70.20.80 192.168.2.12

[root@gariban ~]#  ifconfig gre0 up

[root@gariban ~]# ping -c 1 192.168.2.12
PING 192.168.2.12 (192.168.2.12): 56 data bytes
64 bytes from 192.168.2.12: icmp_seq=0 ttl=64 time=116.005 ms

— 192.168.2.12 ping statistics —
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 116.005/116.005/116.005/0.000 ms
[root@gariban ~]#

Linux Policy Routing Structures yazımda Multiple Routing tables’in ne olduğundan bahsetmiştim şimdi iproute2 ile bunun nasıl yönetildiğine bakalım.

Multiple Routing tables’i kullanmak için kernel’in CONFIG_IP_ROUTE_MULTIPATH=y olarak derlenmiş olması gerekiyor. güncel linux sürümlerinin hepsinde mevcuttur. Yapmış olduğum tüm örnekler Archlinux’da uygulanmıştır. Debian,Ubuntu,Slackware,Centos,Fedora üzerinde sadece genel kontrolleri yaptım herhangi bir soruna rastlamadım.

Mevcut tabloların görüntülenmesi :

Mevcut olan tablolar  /etc/iproute2/rt_tables dosyası içerisinde yer alır,

bash-3.2# cat /etc/iproute2/rt_tables
#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
bash-3.2#

Yeni Tablo eklenmesi :

Bundan pek tatmin olmadığımı açıkça belirteyim, yani iproute2 paketinin bukadar ayrıntılı ve kapsamlı düşünülmüş olmasına karşın, table in sadece dosyaya eklenerek yönetilmesi, ve default routing priority gibi özelliklerin tanımlananaması ilginç…

örnek bir network yapalım :

Şimdi networka ve networkb için iki yeni tablo ekleyelim.

bash-3.2# echo “10 networka” >> /etc/iproute2/rt_tables
bash-3.2# echo “20 networkb” >> /etc/iproute2/rt_tables
bash-3.2# cat /etc/iproute2/rt_tables
#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
10 networka
20 networkb
bash-3.2#

Tabloların oluşturulması bukadar basit, ilerde oluşabilecek ekstra ihtiyaçlarda okunabilirliği bozmamak için 10 ve 20 nolu tablo isimleri verdim tabiki 1 ile 252 arası istediğiniz tablo numarasını kullanmakta özgürsünüz. peki ekstra nasıl bir ihtiyaç olabilir ? local e eklediğimiz bir web server i olduğunu düşünelim yada mail server’i dışarıdan gelen paketleri bu hostlara yönlendirmek için ekstra tablo kullanmak isteyebilirsiniz, yada en azından DMZ tablosu. Şimdilik örneğimizi basit tutalım.

tablolarla ilgili routing eklenmesi :

ip route add from 192.168.0.1/24 via 1.1.1.1 dev eth0 table networka prio 100

ip route add from 192.168.0.1/24 via 2.2.2.2 dev eth1 table networkb prio 200

şimdi kendi sistemimde bu komutlar hata vereceği için benzer bir örneği interface ve gateway i değiştirerek yaptım (olası hatalara karşı  tüm yazılarımdaki örnekleri mutlaka uygulayıp deneyerek koyuyorum ):

bash-3.2# ip route add from 192.168.0.1/24 via 10.70.20.1 dev wlan0 table networka prio 100
bash-3.2# ip route show table networka
default via 10.70.20.1 dev wlan0  metric 100
bash-3.2#

Sanırım ayrıntılara ip route2 ile temel static routing tablosu yönetmek yazımda değinmiştim. burada priority tanımlaması yaptık ekstradan.

Not : Yeni bir routing girdisi yaptığınızda Route Cache Flush yapmayı unutmayınız.

Policy routing nedir ?

Kısaca Policy Routing router, üzerinden geçen paketlerin belirli kriterlere göre sınıflandırılarak nereden gideceğini ve önceliklerinin belirlenmesi işlemidir .

Linux policy routing’in üç elementi :

• Adress : Servisin olduğu lokasyonu tanımlar
• Route  : Adresin lokasyonunu tanımlar
• Rule : Route un olduğu lokasyonu tanımlar.

Şİmdi sanırım bir örnek versek iyi olacak :

[alper@doshiba ~]$ ip route show
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.2
default via 10.70.20.1 dev wlan0
[alper@doshiba ~]$
www.google.com.tr adresinin bir ip’sine ulaşmak için örneğin :

[alper@doshiba ~]$ ip route get 74.125.79.103
74.125.79.103 via 10.70.20.1 dev wlan0  src 10.70.20.2
cache  mtu 1500 advmss 1460 hoplimit 64
[alper@doshiba ~]$
şeklinde routing imizi aldık şimdi burada ;

src 10.70.20.2 ve  74.125.79.103 adreslerimiz oluyor,

via 10.70.20.1 adresin lokasyonu yani 10.70.20.1 in arkasında Route

sözkonusu route u sağlayan rule ise default via 10.70.20.1 dev wlan0

Türkçe meali :

Adress : source ve destination adresleri
Route : gittiği yol
Rule : yolu belirlemesine sebep veren kural

(Multiple Routing Tables : ( Çoklu Routing tabloları )

Kullanmış olduğumuz hemen hemen tüm router ve işletim sistemlerinde tek bir routing tablosu olur,  Söz konusu routing tablosundan bir işlem geçtiğinde işleme en iyi uyan kural bulunur ve uygulanır.

Farklı bir senaryo düşünelim 3 tane internet bağlantımız var, istemcilerimizim ihtiyaçlarına göre bunlardan gerekli olanı kullanmasını istiyoruz. Normal şartlar altında Routing tablomuz içerisinde bunları ayrı ayı belirtmek zorundaydık. Linux Multiple Routing tables ( Çoklu/Katmanlı routing tabloları ) sayesinde, bunları ayrı routing tabloları içerisinde tanımlayabiliyoruz. Routing kurallarımıza anlaşılabilirlik ve yönetilebilirlik kazandırıyor.

RPDB - The Linux Policy Routing Implementation ( Linux Policy Routing Uygulaması )

RPDB nedir ? : Routing policy database route ların, routing tablolarının , ve rule ların oluşturduğu set dir. RPDB sayesinde Linux Routing Policy ve multiple tables ( çoklu routing tabloları ) kullanılabilir hale gelmiştir.

RPDB linux 2.1 ve üzeri kernellerde tamamen yeniden yazılarak oluşturulmuştur. 255 routing tablosu ve 2^32 rule destekler, Bu da ipv4 protokollünde kullanabileceğimiz her ip için bir rule yapar. ( 4 milyar civarı )

İnternette kullanılan klasik routing algoritmaları , routing kararlarını destination ( hedef ) adres e göre veya teoride TOS ( type of service ) a göre yaparlar. bazı durumlarda routing düzenlemerini farklı verilere göre örneğin :  paket alanına , kaynak adresine, ip protokolüne , transport protokolü portuna hatta paket yüklerine göre yapılması gerekebilir. Bu işlemlere Policy Routing denir.

Geleneksel hedefe dayalı routing tabloları, Bir çok anahtar ve doğaya sahip olup doğal bir sıralamaya (network yöneticisi tarafından zorlanmadıkça) sahip değillerdir. Gelen pakete, kurallar içinden en çok uyan ( en uzun ) kuralın belirttiği routing i alarak RPDB’de değiştirir.

Linux RPDB’sinde kurallar numerik öncelik ( priority )  değeri ile linear olarak llistelenmiştirler.
Linux RPDB aşağıdaki şartlara göre kural yazmamıza izin verir.

• Paketin Kaynak adresi ( Source Address)
• Paketin Hedef adresi ( Destination Address )
• TOS ( Type Of Service )
• Paketin geldiği interface ( eth0 gibi meta datadır )
• FWMARK ( Netfilter entegrasyonu için )

Sanırım burada FWMARK nedir?  kısaca değinsek iyi olacak, FWMARK : networkculerin package tag diye bildikleri , iki nokta yada iki proğram arasında paket alışverişi olduğunda karşı tarafın anlayamayacağı veya karşı tarafa iletilemiyecek bilgileri belirtmek için kullanılan etiketlerdir. örneğin. desktop linux umuzda çalışan alper UID i ile çalışan bir proğramı router da anlaşılması  imkansızdır. alper uid’i ile çalışan proğramın paketini etiketleyerek router’a göndermiş olsaydık, router gelen paketteki alper etiketini okuyarak sınıflandıracak, ve paket için ekstra kurallar oluşturmamıza olanak sağlayacaktı.  FWMARK birbirinden farklı lokasyonlarda çalışan iptables/netfilter’ın birbiriyle veya aynı host üzerinde çalışan iproute2 gibi farklı proğramlarla haberleşmesini sağlar.

RPDB nin çalışma şekli firewall lardaki ilk giren kural ikinci kuralı ezer mantığına benzer. bir paket geldiğinde routing kurallarını öncelik en düşükten başlayıp artarak tarar. herhangi bir kural ile paket eşleştiğinde, kuralın göstermiş olduğu routing uygulanarak RPDB taramayı keser. uygulanan kuralın başarılı veya başarısız olması önemsizdir. multiple routing tables okumayı ve yönetmeyi kolaylaştırmakla beraber bu sıralamayı etkilemez.

Linux boot ederken kernel 3 adet RPDB kuralı yapılandırır. bunlar :

bash-3.2# cat /etc/iproute2/rt_tables
#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
bash-3.2#

1. 255 table local

bash-3.2# ip route show table local
broadcast 10.70.20.255 dev wlan0  proto kernel  scope link  src 10.70.20.2
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast 10.70.20.0 dev wlan0  proto kernel  scope link  src 10.70.20.2
local 10.70.20.2 dev wlan0  proto kernel  scope host  src 10.70.20.2
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
bash-3.2#

Yukarda görüldüğü üzere table local içeriği local host ve broadcast adresleri içerir priority 0 dir silinemez ve değiştirilemez.

2. 254 table main

bash-3.2# ip -s route show table main
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.2
default via 10.70.20.1 dev wlan0
bash-3.2#

Burada da görüldüğü üzere 254 table main policy olmayan ağ geçidi gibi klasik routing bilgileri içerir, bu kurallar silinebilir ve değiştirilebilirler. Priority 32766 dir.

3. 253 table

bash-3.2# ip -s route show table default
bash-3.2#
Görüldüğü üzere bu tablo boştur priority si 32767 olan bu table son işlem içn ayrılmıştır. daha önce belirlenen hiç bir kural a uymayan paket burda işlem görür. bu tabloya bir paketin gelmesi için default gateway bilgisinin 254 table main içerisinde olmaması gerekir.

RPDB kuralları aşağıdaki tipleri destekler :

unicast: host dan host a routing diğer bir hosta yani ip adresine direk olarak routing bilgisini içerir

blackhole : paketi sessizce düşürür, bir nevi paketi /dev/null a göndermek gibidir.

unreachable : bu kurala denk gelen pakete network ulaşılamaz mesajı dönülür. ( network unreachable )

prohibit : bu kurala denk gelen pakete Cominication is Administratively Prohibited mesajı dönülür ( Haberleşme Yönetimce engellendi )

nat : kaynak başka bir değere değiştirilir ( Network Adress Transilation )

Linux RPDB tamamen geriye dönük uyumludur. sisteminizde hala ifconfig ve route gibi utilityleri kullanabilirsiniz. bir pakete RPDB de birden çok rule denk gelebilir ( birden çok kuralla eşleşebilir ) . Klasik utilty’lerin tersine iproute2 bu durumu imkansız hale getirmektedir. yinede klasik utilty kullanıp bu şekilde bir durum meydana geldiğinde RPDB en iyisini seşmek için aşağıdaki sıralamayı kullanır.

1. En uzun uyan paket prefix i seçilir. tüm kısa olanlar droplanır.
2. Eğer en uzun uyan birden çok rule kaldıysa, farkı olan TOS ( type of service ) içeren rule lar droplanır.
3. Hiçbir TOS uyumu bulunmazsa ve TOS=0 mevcut ise, gerikalan tüm route lar droplanır, aksi takdirde route fail olur.
4. İlk 3 basamak uygulandığında hala birden fazla rule kaldı ise, en iyi refranslı route değeri seçilir.
5. Hala birden fazla route kaldıysa, ilk route kuralı uygulanır.

Geleneksel linux routing tablosu malesef 5 inci duruma izin verir, default gateway ( ağ geçidi ) tanımlamasının olduğu durumda bu durum söz konusu değildir.

Linux un desteklediği routing kuralları yukarda belirttiğimiz policy routindekiler hariç klasik routing methodlarıyla beraber aşağıdakileri de kapsar :

local : destination address ( hedef adres)  router’ın direk olarak üstündedir. paketler loopback olur ve local olarak alınırlar.

broadcast : destination address broadcast adresidir. link in bağlı olduğu boradcast adreslerine yollanır.

throw : policy route ile kullanılan özel bir kuraldır. route bilgisi isteyen host a net unreachable icmp code ( 3 0 ) dönülür.

anycast : henüz linux RPDB sine eklenmemiştir.  kullanımı local e benzer, ama söz konusu host kaynak adresi olarak kullanılamaz.

multicast : multicast router yapılandırmasında kullanılır. normal routing tablolarında yer almaz.

Sanırım  Bukadar söz etmek yeterli. Geri kalan ayrıntılar diğer yazılarımda vereceğim örneklerle daha iyi anlaşılacaktır.

Iproute2 ile routing tablosunu görüntülemiştik. şimdi sanırım basit olan static routing le başlayalım.

Statik routing nedir : Statik routing routing  bilgilerinin manual olarak network yöneticisi tarafından elle girdiği routing bilgileridir. burada belirtmek istediğim nokta  policy based routing gibi kavramlara daha sonraki yazılarımda gireceğim. şimdilik basit temel routing işlemlerini yapacağız.

Statik routing in avantajları :

• Router da daha az cpu ram tüketir.
• Routing Discovery işlemi yapılmadığı için dış etkenlerden dolayı aksaklık yaşamnaz.
• Genellikle göz ardı edilecek kadar az olmasına karşın ekstra bir band genişliği tüketmez.

Statik routing dez avantajları :

• Yönetici network route işlemini bilmeli ve planlamalıdır.
• Yeni bir routing işlemi eklendiğinde veya değişiklik olduğunda yönetici elle yapılandırmalıdır.
• Büyük networklerde bu işlemler çok büyük zaman alır . Hatta imkansız hale gelebilir.

Hemen uygulama örnekleri ile başlayalım :

ip route add :

ip route add komutu yeni bir routing bilgisi girmek için kullanılır.

örnekler :

Default gateway ( ağ geçidi girmek )

bash-3.2# ip route add 0.0.0.0/0 via 10.70.20.1
bash-3.2# ip route show
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.2
default via 10.70.20.1 dev wlan0
bash-3.2#

Burada sanırım routing konusuna yabancı arkadaşlar için bir açıklama girsem iyi olacak Default gateway ( ağ geçidi ) nedir ? Ağ geçidi kısaca bir işlem yapılacağı zaman routing tablosuna bak herhangi bir veri varmı ? hiç bir routing kuralına uymuyorsa ağ geçidine git o ne yapacağını biliyordur ( umarım )

Şimdi daha değişik bir örnek yapalım, örnek networkümüz :

Şimdi örneğimizdeki gibi bir internet bağlantımız olduğunu farzedelim. ISP1 ( İnternet Service Provider ) , bize adsl gibi ucuz ve geniş bant genişliği sunuyor, ISP2 ise bize daha düşük bant genişliği ama hızlı ping süreleri imkanı sunuyor, alper.web.tr domain inde çalışan server lerimize ulaşıp web içeriği görüntülemek için Servissağlayıcı 1′i domain de çalışan ses hizmetlerine ( voice ) ulaşmak için ise daha düşük ping süresini tercih etmek istiyoruz. alper.web.tr adresindeki tüm server ler internet üzerinden ulaşılabiliyor ve voice hizmeti 9.9.9.1 ip sine sahip server tarafından sağlanıyor. iproute 2 ile voice hizmeti için 2 diğer tüm hizmetler için 1 nolu servis sağlayıcıdan giden route belirleyelim..

ip route add 9.9.9.1/32 via 2.2.2.1

ip route add 0.0.0.0/0 via 1.1.1.1

9.9.9.1 e gideceğimiz zaman 2.2.2.1 gatway i kullan , geri kalanlar için default gateway 1.1.1.1 dir dedik ( NAT yapılandırmasında bu ayarlar farklıdır )

route eklerken device belirtebiliriz.

ip route add 9.9.9.1/32 via 2.2.2.1 device eth1

ip route add 0.0.0.0/0 via 1.1.1.1 device eth0

ip route change :

ip route change komutu ile var olan bir routing bilgisini silemeden değiştirebiliriz. kullanımı iproute add ile aynıdır.

örnek :

bash-3.2# ip route change 0.0.0.0/0 via 10.70.20.1 dev wlan0
bash-3.2#
var olan default gateway imizi 10.70.20.1 olacak şekilde ve interface wlan0 i kullanacak şekilde değiştirdik.

iproute del :

istemediğimiz bir routing girdisini silmek için kullanılır.

bash-3.2# ip route show
9.9.9.9 via 10.70.20.100 dev wlan0
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.2
default via 10.70.20.1 dev wlan0
bash-3.2# ip route del 9.9.9.9 via 10.70.20.100 dev wlan0
bash-3.2# ip route show
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.2
default via 10.70.20.1 dev wlan0
bash-3.2#

ip route flush :

toplu olarak routing girdileri silmek için kullanılır :

bash-3.2# ip route show table main
9.9.9.9 via 10.70.20.100 dev wlan0
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.2
default via 10.70.20.1 dev wlan0
bash-3.2# ip route flush table main
bash-3.2# ip route show
bash-3.2#

ip route flush komutu bir çok parametre içerebilir table içeriklerini silmek, bgp tarafından oluşturulanları silmek gibi. daha fazla ayrıntı için iproute2 orjinal dökümantasyonuna bakınız.

ip route show :

Kısaltmaları :  show, list, sh, ls, l

ip route show komutu routing tablosunun içeriğini görmeye ve seçilmiş kriterler içerisindeki routing  tablosu içeriklerini görmeye yarar.

basit örnek :

bash-3.2# ip route show
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.59
default via 10.70.20.1 dev wlan0
bash-3.2#

hemen yine burada gördüklerimizin manalarını açıklayarak başlayalım :

proto : routing protokolü kernel kernel lvl routing örn : rip bgp vs. bakınız : cat /etc/iproute2/rt_protos

scope : kapsama alanı

link : direk bağlı olan interface link

src : linux un bu route a gitmek için kullandığı source ( kaynak ) interface’i

via : yolu ile

default : default router ağ geçidi

kısaca  : 10.70.20.0/24 networküne ulaşacak olursak wlan0 cihazı yoluyla ulaşırız, bu cihaz üzerindeki 10.70.20.59 nolu bize ait ip adresi kaynak ip si ( source ip address ) olarak kullanılır, network direk olarak bu device a bağlıdır. Default gateway imiz ( ağ geçidi ) wlan0 interface i üzerinden ulaşılan 10.70.20.1 dir.

all : tüm tabloları görüntüle

bash-3.2# ip route show all
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.3
default via 10.70.20.1 dev wlan0
bash-3.2#

cache : linux kerneli yakın zamanda ulaşılan adresleri hızlı referans kartı olarak cache tutar, kısa zaman içerisinde yeniden bu adreslere ulaşmanız gerekirse bu referans tablosundan aldığı routing bilgisi ile hızlı olarak ulaşır. tablo içerisindeki adresler periyodik olarak yine kernel tarafından silinirler. cache routing tablosuna bakmak için.

bash-3.2# ip route show cache
local 10.70.20.3 from 65.54.228.46 dev lo  src 10.70.20.3

cache <local>  iif wlan0

<<<< kalabalık yapmaması için bu arayı kesiyorum >>

78.129.231.111 from 10.70.20.3 via 10.70.20.1 dev wlan0
cache  mtu 1500 rtt 770ms rttvar 765ms cwnd 5 advmss 1460 hoplimit 64
bash-3.2#

-s statstics “istatistikler” parametresi yine ip route show ile kullanılıp istatistiki bilgi alınabilir.

ip route show table local :

/etc/iproute2/rt_tables  içerisinde belirtilen tablolara ait routing leri ayrı ayrı listelemek için kullanılır. burada local local interface ler için ihtiyaç duyulan routing leri gösterir, ne yaptığınızdan tamamen emin olmadıkça kurcalanmamalıdır. main ise direk örnek verirsek sanırım kolayca anlaşılacaktır.

bash-3.2# ip route show table main
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.3
default via 10.70.20.1 dev wlan0
bash-3.2#

belirli bir ip bloğuna ait routing görüntülemek :

bash-3.2# ip route list 10.70.20.3/24
10.70.20.0/24 dev wlan0  proto kernel  scope link  src 10.70.20.3
bash-3.2#

ip route get :
ip route get komutu ile hernagi bir ip ye ait routing i elde edebilirsiniz örneğin google a ait  74.125.77.104 nolu ip ye hangi route üzerinden giderim ? öğrenmek için extradan -s parametreside vererip istatistiki bilgi de alarak :

bash-3.2# ip -s route get 74.125.77.104
74.125.77.104 via 10.70.20.1 dev wlan0  src 10.70.20.3
cache  users 1 used 3 mtu 1500 advmss 1460 hoplimit 64
bash-3.2#

Routing tablosu görüntülenmesi oldukça uzun bir konu sanırım daha sonraki konularda ( rip bgp realms vb ) kullanacağımız için şimdilik daha fazlasına girmek gereksiz. daha fazla ayrıntıya ihtiyaç duyanlar için iproute2 orjinal dökümanı : http://www.policyrouting.org/iproute2.doc.html#ss9.5

Yinede bazı kısa örnekler verelim :

ip route list 192.168.1.1 table cache
cache table i içerisinden 192.168.1.1 ip’sine ait routing görüntülenir.

ip route list proto gated/bgp
/etc/iproute2/rt_protos dosyasında görebileceğimiz listeden. gated programı ile sağlanan bgp protokolünde sağlanmış olan routing bilgilerini gösterir