Глава 3. Запознаване с iproute2
3.1. Защо iproute2?
Повечето линукски дистрибуции, както и повечето Unix-ски, в момента използват добре познатите arp, ifconfig и route команди. При работата с тези команди обаче, се появяват някои странности при (линукски) ядра с номер по-голям от 2.2. Например, GRE тунелите са неизменна част от рутирането в днешно време, но те изискват напълно нови програми.
Със пакета iproute2 IP-тунелите са вградени във...(tool set)
В линукските ядра с версия 2.2 и нагоре кода на мрежовата подсистема е напълно пренаписан. Този нов мрежови код прави Линукс почти без конкуренция сред основните производители на ОС. Този нов рутиращ, филтриращ и класифициращ код е по-богат на възможности, от този, който се използва в много специализирани устроиства(рутери, защитни стени, продукти за оформяне на трафика и т.н.).
Тъй като са измислени нови мрежови концепции, хората са намерили начини да ги приложат във съществуващия мрежови код, във съществуващите операционни системи. Това постоянно разслояване на кода неизбежно води до появата на мрежови код със странно поведение, както е например при повечето човешки езици(пишеш едно, казваш друго). В миналото, Линукс емулираше начина по които SunOS се справяше с много от тези проблеми, но той се оказа несъвършен.
Тази нова мрежова подсистема прави възможно чисто да се направят неща, които преди са били отвъд възможностите на Линукс.
3.2. Запознаване с iproute2
Линукс има усъвършенствана система за контрол на трафика наречена Traffic Control(TC). Тази система поддържа няколко метода за класифициране, приоритетизиране, споделяне, и ограничаване на входящия и изходящия трафик.
Ще започнем с кратко представяне на възможностите на iproute2.
3.3. Необходими условия
Трябва да сте сигурни, че имате подходящите програмни пакети инсталирани. Този пакет се нарича 'iproute'
в Redhat и Debian дистрибуциите, и може да бъде намерен на <a href="" target="_blank">
ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz</a>
<a href="" target="_blank">
ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz</a> - тук е най-новата версия на iproute пакета.
Някой части от пакета iproute изискват да сте компилирали ядрото с някои допълнителни опции. Трябва да се отбележи, че всички Redhat-и до 6.2 включително идват компилирани без повечето опции за контрол на трафика в оригиналното(слединсталационно) ядро, и затова трябва да се прекомпилират.
RedHat 7.2 включва всички опции по подразбиране.
Също така трябва да включите и netlink support, в случай че си прекомпилирате ядрото. Iproute2 се нуждае от него.
3.4. Разглеждане на текущата конфигурация(настройки)
Това може да ви изненада, но iproute2 е вече конфигуриран! Командите ifconfig и route вече използват разширените syscalls, но в повечето случаи с настроиките по подразбиране(т.е. не винаги най-оптималните настроики.)
Тук ip командата е централна, и ние ще и кажем да ни покаже нашите интерфейси.
3.4.1. ip ни показва нашите връзки
[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
при вас това може да доведе до различни резултати, но ето какво се появявя на моя NAT рутер вкъщи. Ще обясня само частично изхода, защото не всичко ни интересува директно.
Най-напред виждаме интерфейса loopback. Въпреки че компютъра ви може да функционира и без него, не бих ви съветвал да го изключвате. MTU-то(Maximum Transfer Unit) е 3924 октета, и не би трябвало да има опашка. Това има смисъл, тъй като loopback интерфейса е функция от ?kernel's imagination?.
Засега ще пропусна dummy(фиктивния) интерфейс, тъй като той може да не присъства на вашия компютър. Следват два физически мрежови интерфейса, единия от страната на кабелния ми модем, а другия обслужва домашната ми мрежа. След това виждаме и ppp0 интерфейс.
Забележете отсъствието на IP адреси. iproute разбива традиционните концепции за връзката между интерфейсите и IP адресите. С IP aliasing, концепцията за IP адреса стана твърде неуместна(непълна?).
ip ни показва както MAC адресите така и хардуерния идентификатор на нашите мрежови интерфейси.
3.4.2. ip ни показва нашите IP адреси
[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
link/ppp
inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0
Тук виждаме повече информация. Тук са показани всичките ни (ip) адреси, и на кои интерфейси са настроени. inet стои е за Интернет (IPv4). Има много други фамилий адреси, но те не ни интересуват в момента.
Хайде да прегледаме eth0 по отблизо. Този интерфейс е свързан с inet адреса '10.0.0.1/8'.
Какво означава това? /8 е за броя на битовете на мрежовия адрес. Има 32 бита, така че ни остават 24 бита за хостовете на нашата мрежа.
Първите 8 бита на 10.0.0.1 отговарят на 10.0.0.0, нашия мрежови адрес(Network Address), а нашата мрежова маска(netmask) е 255.0.0.0.
Другите битове които са свързани с този интерфейс, така че 10.250.3.13 е директно достъпен от eth0, както и 10.0.0.1 например.
При ppp0 имаме същата концепция, въпреки че номерата са различни. Неговия адрес е 212.64.94.251, без мрежова маска(netmask). Това означава, че имаме връзка тип ppp(point-to-point) и всеки адрес, с изключение на 212.64.94.251, е външен. Има още нещо, което ip ни казва. То ни казва, че от другата страна на връзката има само един адрес 212.64.94.1. /32 ни казва, че няма битове за мрежа.
Изключително важно е да разберете тези концепции. Обърнете се към документацията,спомената в началото на това HOWTO ако имате проблеми.
Вие може да забележите 'qdisc', което е съкратено от Queueing Discipline(?ред на опашка?). Това ще стане важно малко по-нататък.
--------------------------------------------------------------------------------
3.4.3. ip ни показва маршрутите(routes)
Е, всички знаем как да намерим 10.x.y.z адресите, и сме способни да достигнем до 212.64.94.1. Това обаче не е достатъчно, така че се нуждаем от инструкции как да достигнем света.
Интернет е достъпен през нашата ppp(тт ;)) връзка, и изглежда, че 212.64.94.1 желае да разпространява нашите пакети към света, и да ни доставя резултатите от това обратно.
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0 proto kernel scope link src 212.64.94.251
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0
Първите 4 линии от изхода показват кои ip адреси към кои интерфейси са, последния ред ни казва че останалия свят може да бъде достигнат през 212.64.94.1, нашият шлюз по подразбиране (efault gateway). Ние разбираме че това е шлюз заради думата "via"(през), която ни казва че трябва да изпращаме пакетите до 212.64.94.1, и то ще поеме нещата нататък.
За справка, ето какво би ни показало старото route utility:
[ahu@home ahu]$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
212.64.94.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 212.64.94.1 0.0.0.0 UG 0 0 0 ppp0
--------------------------------------------------------------------------------
3.5. ARP
ARP е съкратено от Address Resolution Protocol както е описано в RFC 826. ARP се използва от машина, работеща в мрежа, за разпознаване на физическия (hardware location/address) на друга машина във същата локална мрежа. Машините в Интернет по принцип са известни с техните имена на хостове, които се преобразуват до IP адреси. Ето как машината на foo.com мрежата е способна да комуникира със друга машина, която е в bar.net мрежата. Въпреки това, IP адреса не може да ви каже физическото разположение на машина(хост). Ето къде е приложението на ARP.
Нека разгледаме един прост пример. Представете си, че имам мрежа състояща се от няколко машини.
Две от машините които са в момента в мрежата са foo с IP адрес 10.0.0.1 и bar с IP адрес 10.0.0.2. Сега foo иска да ping-не bar за да види дали то е "alive"(активно, работещо), но уви, foo няма представа къде се намира bar. Така че когато foo реши да ping-не bar, той ще трябва да изпрати ARP request(запитване). Този ARP request(запитване) е аналогично на foo да крещи по мрежата "Bar (10.0.0.2)! Къде си?" Като резултата е, че всяка машина по мрежата ще "чуе" крясъците на foo, но само bar (10.0.0.2) ще отговори. Bar ще изпрати ARP reply(отговор) директно на foo, което е като bar да каже, "Foo (10.0.0.1) Аз съм тук на 00:60:94:E9:08:12." След тази проста транзакция която се използва за да установи foo къде е bar, foo е способен да комуникира с bar докато тои (неговия arp кеш) не "забравят" къде е bar (обикновенно след 15 минути на Unix).
Сега нека видим как това работи. Вие можете да видите arp/neighbor(съсед) кеш таблица като
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Както виждате, моята машина espa041 (9.3.76.41) знае къде да намери espa042 (9.3.76.42) и espagate (9.3.76.1). Сега нека вмъкнем друга машина в arp кеш-а.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms
--- espa043.austin.ibm.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Като резултат от опита за контакт между espa041 и espa043, хардуерният адрес/локация espa043's е вмъкнат в arp/neighbor кеша. Така че докато не изтече определен период от време(time out) за espa043 (като резултат на отсъствието на връзка между двата хоста) espa041 знае къде да намери espa043 и няма нужда да изпраща ново ARP request(запитване).
Сега нека изтрием espa043 от нашия arp кеш:
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale
Сега espa041 отново е забравил къде да намери espa043 и ще трябва да изпрати друг ARP request(запитване) следващия път когато му се наложи да комуникира с espa043. Вие забелязвате от горния изход, че статуса espagate (9.3.76.1)
е променен на "stale" статус. Това означава, че горния хардуерен адрес е все още валиден, но трябва да бъде потвърден при първата транзакция към тази машина.
Автор
Тема: linux advanced routing with iproute2+tc (Прочетена 10563 пъти)
Jul 02, 2003, 12:41