С новите ядра (v2.2.x) Linux започна да придобива мрежовите възможности на Cisco router (благодарение на Алексей Кузнецов).

    Тези възможности се включват от Network Options/Quality of Services и Network Options/Advanced routing". За да използваме тези възможности, ни е нужен пакета iproute2 (или iproute2+tc), достъпен от ftp.inr.ac.ru/ip-routing. В него се съдържат 2 основни програми - ip и tc. Първата служи за манипулация на интерфейси routing-таблици и т.н., а втората - за traffic control. За първата има дълго и подробно ръководство в пакета, а за втората е в процес на разработка. Тук ще опиша, доколкото ми е възможно, и двете команди.

Манипулация на интерфейси

    Този пример за използването на ip link конфигурира eth0 с адрес 2.3.4.5, да използва ARP и да включи интерфейса.

ip link set dev eth0 address 2.3.4.5
ip link set dev eth0 arp on
ip link set dev eth0 up

ip link set dev ppp0 txqueuelen 100

    <[ * Кратка забележка: В linux-2.2.x типовете entry-та на routing-таблица са следните:

ip route add, change и replace поддържат следните опции:

    Тук имаме машина с две мрежови карти, която има три адреса: 192.168.1.1 на eth1, и 192.168.0.4 и 193.200.17.103 на eth0. Това е Samba server на мрежата и, когато осъществява връзки до 192.168.x.x използва 192.168.x.x адресите си, а се свързва към реални адреси, използва реалния си адрес. Също така има два хоста, за които минава през друг router (193.200.17.98), а не през главния си (193.200.17.97), както и три машини, които са и на LAN-а:

ip route add 192.168.0.0/24 dev eth0 srv 192.168.0.4
ip route add 192.168.1.0/24 dev eth1
ip route add 193.200.17.97 dev eth0 src 193.200.17.103 onlink
ip route add 193.200.17.101 dev eth0 src 193.200.17.103 onlink
ip route add 193.200.17.98 dev eth0 src 193.200.17.103 onlink
ip route add 193.200.17.105 via 193.200.17.98 src 193.200.17.103
ip route add 193.200.17.102 via 193.200.17.98 src 193.200.17.103
ip route add default via 193.200.17.97 src 193.200.17.103

ip route add default scope global nexthop dev ppp0 nexthop dev ppp1

ip route add defaulte equalize scope global nexthop via 193.200.17.98 nexthop via 193.200.17.99

ip route show също така има подобни опции, но с него се извеждат route-овете, които имат подобни параметри.

    Ето един пример:

eosnw:~# ip route show 193.200.17.97 dev eth0 scope link 193.200.17.98 dev eth0 scope link 193.200.17.101 dev eth0 scope link 193.200.17.102 via 193.200.17.98 dev eth0 src 193.200.17.103 193.200.17.105 via 193.200.17.98 dev eth0 src 193.200.17.103 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.4 default via 193.200.17.97 dev eth0 src 193.200.17.103

ip route flush пък се различава от ip route show само по това, че изтрива всички route-ове, които имат такива параметри като зададените на командата.

ip route get пък проверява през кой route ще мине пакет със свойства като тези, зададени на командата. (* Внимание! Това не е точно ip route show - при rules и т.н. резултатът може да е различен. ip route get повтаря действията на kernel-а при lookup в routing-таблиците.).

ip rule позволява да се задават правила, на база на които да се прави lookup в други routing-таблици - по този начин може да се прави routing, базиран не само на адреса на целта, но и на база на изходния адрес, на ToS, на входен интерфейс. ip rule има няколко възможни команди: add, delete и show.

    Тези правила могат да бъдат следните типове:  

    Това routе-ира всичко от 192.203.80.0/24 през правилата на таблица 13:

ip rule add from 192.203.80.0/24 table 13 prio 220

ip rule add iif eth0 from 192.168.1.0/24 type blackhole prio 100

ip rule del iif eth0 prio 100

Пример:

eosnw:~# ip rule show0: from all lookup local100: from 192.168.1.0/0 \
iif eth0 lookup main blackhole32766: from all lookup main32767: from all \
lookup 253

ip address add/delete имат следните параметри:  

Примери:

    Тук например се създават три логически мрежи върху една физическа и те могат да работят независимо една от друга, независимо да им се прави shaping и accounting и т.н.:

ip address add 192.168.0.1 dev eth0
ip address add 192.168.1.1 dev eth0
ip address add 192.168.2.1 dev eth0
ip route add 192.168.0.0/24 dev eth0 src 192.168.0.1
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1
ip route add 192.168.2.0/24 dev eth0 src 192.168.2.1

ip address add 194.12.235.195 dev eth0
ip address add 194.12.235.199 dev eth0 name eth0:0

    Така се виждат всички интерфейси:

eosnw:~# ip address show1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueuelink/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo2: teql0: <NOARP> mtu 1500 qdisc noop qlen 100 link/generic3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100link/ether 00:20:af:3c:07:f7 brd ff:ff:ff:ff:ff:ff inet 192.168.0.4/24 brd 192.168.0.255 scope global eth0inet 193.200.17.103/32 scope global eth04: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100link/ether 00:20:af:3c:08:0f brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1

eosnw:~# ip address show label "eth*"3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100link/ether 00:20:af:3c:07:f7 brd ff:ff:ff:ff:ff:ff inet 192.168.0.4/24 brd 192.168.0.255 scope global eth0 inet 193.200.17.103/32 scope global eth04: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:20:af:3c:08:0f brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1

    С ip tunnel се манипулират тези т.нар. тунели. Тази команда има следните подкоманди: add, change, delete, show.

ip tunnel add/change/delete има следните опции:

    <[Това по-надолу е произведение на Renegade в/у traffic control-а ]>

"Traffic Control"

    За да се компилира кернела с тая поддръжка, трябва да се компилират в кернела, или като модули "Class Based Queueing (CBQ)", "Tocken Bucket Flow (TBF)", "Traffic Sharpers", както и RED. След това, необходима е iproute2, за да може да се използват тия функции на кернела. Тя може да се свали от ftp://ftp.sunet.se/pub/Linux/ip-routing. Принципът, на който работи "traffic control (tc)", е следния: входящите пакети се проверяват дали са за дадена точка, и, ако това е така, те се изпращат за обработка на по-висок слой. В противен случай се гледа routing-таблицата, за да се установи следващия hop за пакета. Също така, по-високия слой също може да генерира трафик, който да кара forwarding agent процесите да търсят следващия hop. Когато това стане, forwarding agent-а слага дадения пакет към изходния интерфейс за предаване. Именно тук Linux Traffic Control-а почва да върши работа.

Linux Traffic Control-а е базиран на три основни блока:

• Queueing-дисциплина
• Класове
• Филтри

    Всеки интерфейс има начин за обработване на опашките, асоциирани към него. Най-простата е FIFO. Има няколко типа на queueing, които се поддържат в момента:

• Class Based Queue
• Token Bucket Flow
• CSZ
• First In First Out (FIFO)
• Priority
• TEQL
• SFQ
• ATM
• RED

2. Класове

    Опашките и класовете са тясно свързани. Всеки клас има опашка. Класовете се индетифицират спрямо class ID и internal ID. Class ID-то се задава от потребителя, докато internal ID-то се задава от queueing-дисциплината. Class ID-то има структура "major:minor". Major-номера сочи инстанцията в queueing-дисциплината, от която зависи. Minor-номера идентифицира тоя клас в дадена дисциплина.

    За повече подробности може да се види include/net/pkt_sched.h.

"tc (Traffic Controller)"

Traffic Controller (tc) е потребителска програма, която е грубо казано frontend към създаването и асоциирането на опашки към дадени изходни интерфейси. Тя се използва за създаването на различни видове опашки и асоцииране на класове към всяка от тези опашки. Също така може да се използва за слагане на филтри базирани на routing-таблицата, u32-класификаторите, както и RSVP-класификаторите. Тя използва netlink socket-ите като механизъм за комуникиране с мрежовите функции на кернела.

tc се използва по следния начин:

tc [-s[tatistics]] [-d[etails]] [-r[aw]] < qdiscp | class | filter > { COMMAND | help }

Queuing-дисциплина:

    Синтаксиса за задаване на queueing-дисциплина е следния:

tc qdisc [ add | del | replace | change | get ] dev STRING [ handle QHANDLE ] [ root | parent CLASSID ] [ estimator INTERVAL TIME_CONSTANT ] [ [ QDISC_KIND ] [ help | OPTIONS ] ]
tc qdisc show [ dev STRING ]

    За да се създаде "class based queue (CBQ)":

tc qdisc [ add | del | replace | change | get ] dev STRING \
cbq bandwidth BPS [ avpkt BYTES ] [ mpu BYTES ] [ cell BYTES ] [ ewma LOG ]

Пример:

    tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit allot 1514 cell 8 avpkt 1000 mpu 64

    В дадения пример, Class Based Queue (CBQ) се създава и се връзва към eth0. handle-ът е 1: (което е 1:0). Общата възможна скорост е 10Mbit.

    Класове:
Синтаксисът за създаване на класове е следния:

tc class [ add | del | change | get ] dev STRING [ classid CLASSID ] [ root | parent CLASSID ] [ [ QDISC_KIND ] [ help | OPTIONS ] ]
tc class show [ dev STRING ] [ root | parent CLASSID ]

3. Class Based Queue

    За да се създаде CBQ, синтаксисът е следния:

cbq bandwidth BPS rate BPS maxburst PKTS [ avpkt BYTES ] \
[ minburst PKTS ] [ bounded ] [ isolated ] \
[ allot BYTES ] [ mpu BYTES ] [ weight RATE ] \
[ prio NUMBER ] [ cell BYTES ] [ ewma LOG ] \
[ estimator INTERVAL TIME_CONSTANT ] \
[ split CLASSID ] [ defmap MASK/CHANGE ]

tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit \
rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20 \
avpkt 1000 split 1:0 defmap c0

Синтаксисът за създаване на филтри е:

tc filter [ add | del | change | get ] dev STRING \
[ prio PRIO ] [ protocol PROTO ] [ root | classid CLASSID ] \
[ handle FILTERID ] [ [ FILTER_TYPE ] [ help | OPTIONS ] ] \
tc filter show [ dev STRING ] [ root | parent CLASSID ]

Route-класификаторите класифицират пакетите спрямо routing-таблицата. Синтаксисът е следния:

tc filter [add | del | change | get] dev STRING \
[parent PARENTID] [protocol PROTO] [prio PRIORITY] route

    Ето и един пример:

tc filter add dev eth0 parent 1:0 protocol ip prio 100 route

ip route add 129.237.125.150 via 129.237.125.146 dev eth0 flow 1:2

    И най-накрая, след толкова изписани глупости, нека да разгледам един реален пример:

    Нека да имаме три компютъра: computer1, който е с IP 10.10.10.149. Нека средната големина на пакета да е 1000 байта. И да имаме два класа: един за трафика към машината с IP 10.10.10.146 (computer2), и трафика към машината 10.10.10.148 (computer3). Т.е. с една дума, да се ограничи трафика на машиниcomputer2 иcomputer3. Трафикът къмcomputer2 е с по-висок приоритет от  тоя къмcomputer3. Къмcomputer2 се пуска 1Mbps, а към computer3 - 5Mbps.

На computer1:
--------------

# Attach-ваме queueing-дисциплина към eth0. (там са вързани
# другите две машини). Максималната възможна скорост е 10Mbps.
tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit \
cell 8 avpkt 1000 mpu 64
# Дефинираме root-класа. Той има 10Mbps.
tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 10Mbit \
rate 10MBit allot 1514 cell 8 weight 1Mbit prio 8 maxburst 20 \
avpkt 1000
# Трафик към computer2. Приоритетът е 3, а скоростта е 1Mbps.
tc class add dev eth0 parent 1:1 classid 1:2 cbq bandwidth 10Mbit \
rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20 \
avpkt 1000 split 1:0
# Трафик към computer3. Приоритетът е 7, а скоростта е 5Mbps.
tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 10Mbit \
rate 5Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20 \
avpkt 1000 split 1:0
# Слагаме route класификатора
tc filter add dev eth0 parent 1:0 protocol ip prio 100 route
# Слагаме route и правила за computer2
ip route add 10.10.10.146 via 10.10.10.149 flow 1:2
# Слагаме route и правила за computer3
ip route add 10.10.10.148 via 10.10.10.149 flow 1:3