Большинство дистрибутивов Linux, как и большинство ОС UNIX, в настоящее время используют довольно древние утилиты arp, ifconfig и route. Пока что эти инструменты работают достаточно адекватно, но иногда, на ядрах Linux версии 2.2 и выше, они могут вести себя довольно неожиданно.

Сетевая подсистема, в ядрах 2.2 и выше, была полностью переписана. Новый сетевой код дал увеличение производительности и более высокие эксплуатационные характеристики, что делает Linux еще более привлекательным на рынке операционных систем.

Фактически, реализация сетевой подсистемы в Linux, выполняющая классификацию, маршрутизацию и фильтрацию, оказалась даже более полной, чем в специализированных маршрутизаторах, межсетевых экранах и других устройствах управления трафиком.

По мере появления новых разработок, они "наслаивались" поверх существующих реализаций в существующих операционных системах. Это постоянное наслаивание привело к тому, что код, решающий задачи управления сетевым трафиком, временами проявлял весьма странное поведение.

Эта, заново переписанная, реализация сетевой подсистемы позволила достичь таких характеристик, которые раньше были просто недоступны.

Linux обладает довольно сложной системой управления пропускной способностью, названной Traffic Control (Управление Трафиком). Она поддерживает различные методы классификации, деления по приоритетам, совместного использования, и ограничения как входящего, так и исходящего трафика.

Мы начнем обсуждение проблемы с краткого обзора iproute2 и ее возможностей.

Вам следует установить необходимый инструментарий — набор утилит командной строки. Этот пакет называется iproute, по крайней мере в Red Hat и Debian. Если в вашем дистрибутиве его нет, то пакет можно скачать по адресу: ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz.

Можете попробовать взять самую последнюю версию.

Отдельные утилиты пакета требуют, чтобы в ядре были разрешены некоторые опции. Следует отметить, что все дистрибутивы Red Hat, до версии 6.2 включительно, поставляются с ядром, в котором по-умолчанию большинство необходимых опций отключено.

В Red Hat 7.2 такое положение вещей исправлено.

Кроме того, в ядре должна быть включена поддержка netlink, этого требует iproute2.

Для вас может оказаться сюрпризом, но iproute2 уже сконфигурирована! Существующие команды ifconfig и route уже используют расширенные системные вызовы, но главным образом с настройками, заданным по-умолчанию.

Утилита 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

Здесь приведен результат работы команды ip link list на моем домашнем маршрутизаторе (с "поднятым" NAT), у вас он может несколько отличаться. Я поясню часть того, что вы видите, но не все, а только то, что нас интересует в данный момент.

Первым в списке находится локальный (loopback) интерфейс. В принципе, при крнфигурировании ядра, можно отключить поддержку этого интерфейса, но я бы не советовал этого делать. Размер максимального блока передачи данных (MTU — Maximum Transfer Unit) для этого интерфейса составляет 3924 октета, и для него отсутствует очередь, поскольку он не соответствует никакому физическому устройству и существует только в "воображении" ядра.

Я пропущу фиктивный (dummy) интерфейс, так как он может отсутствовать на вашем компьютере. Дальше у меня идут два физических сетевых интерфейса, один — со стороны модема, другой — обслуживает мою домашнюю локальную сеть. И наконец последним в списке стоит интерфейс ppp0.

Обратите внимание на отсутствие IP-адресов в листинге. iproute отделяет понятие "интерфейса" от понятия "IP-адреса". При назначении нескольких IP-адресов одному интерфейсу (IP-алиасинг), понятие IP-адреса становится достаточно расплывчатым.

Зато показываются MAC-адреса — аппаратные идентификаторы сетевых интерфейсов.

[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" соответствует термину "Internet (IPv4)". Существует целый ряд типов сетевых адресов, но нас они пока не интересуют.

Взглянем поближе на интерфейс eth0. Из листинга видно, что ему назначен адрес "inet" — 10.0.0.1/8, где "/8" определяет число бит, соответствующих адресу сети. Таким образом, для адресации хостов в сети у нас остается 32 – 8 = 24 бита, что соответствует адресу сети – 10.0.0.0 и маске сети – 255.0.0.0.

Это говорит о том, что любой хост в этой сети, например 10.250.3.13, будет непосредственно доступен через наш интерфейс с IP-адресом 10.0.0.1.

Для ppp0 применима та же концепция, хотя числа в IP-адресе отличаются. Ему присвоен адрес — 212.64.94.251, без маски сети. Это означает, что он обслуживает соединение типа "точка-точка" (point-to-point), и что каждый адрес, за исключением 212.64.94.251, является удаленным. Но и это еще не все. Для этого интерфейса указывается адрес другого конца соединения — 212.64.94.1. Здесь число "/32" говорит о том, что это конкретный IP-адрес и он не содержит адреса сети.

Очень важно, чтобы вы поняли суть этой концепции. Если у вас возникают какие либо затруднения, обращайтесь к документации, упомянутой в начале этого HOWTO.

Вы наверняка обратили внимание на слово "qdisc". Оно обозначает дисциплину обработки очереди (Queueing Discipline). Позднее мы коснемся этой темы подробнее.

Итак, мы теперь знаем, как можно отыскать адреса 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

Этот листинг достаточно "прозрачен". Первые 3 строки сообщают сведения, которые нами уже обсуждались выше. Последняя строка говорит о том, что внешний мир доступен через 212.64.94.1 — шлюз, заданный по-умолчанию. То что это шлюз, видно благодаря наличию слова "via" (в переводе с англ. — "через"). Этот шлюз (с адресом 212.64.94.1) готов перенаправлять наши пакеты в Интернет и возвращать обратно результаты наших запросов.

Для примера, более "старая" утилита route, дает такой результат на моей машине:

[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

ARP — Address Resolution Protocol (Протокол Определения Адреса) описан в RFC 826. Он используется для определения ethernet-адреса по IP-адресу. Машины в Интернет более известны под именами, которые преобразуются в IP-адреса, благодаря чему узел сети, скажем с именем foo.com, имеет возможность связаться с другой машиной, например с именем bar.net. Но в ethernet-сетях для адресации используется не IP-адрес, а ethernet-адрес и здесь на сцену выходит протокол ARP.

Рассмотрим простой пример. Предположим, что имеется сеть из нескольких компьютеров. В ней находятся компьютеры foo, с адресом 10.0.0.1 и bar, с адресом 10.0.0.2. Пусть foo хочет послать пакет ICMP Echo Request (ping) компьютеру bar, чтобы проверить — работает ли он, но увы, foo не знает ethernet-адрес компьютера bar. Таким образом, прежде чем ping-ануть bar, foo должен отослать ARP-запрос. Этот запрос очень похож на то, что обычно кричит человек, пытаясь отыскать в толпе своего товарища: "Bar (10.0.0.2)! Ты где?". В результате все машины в сети услышат "крик" foo, но только bar (10.0.0.2) откликнется на него, послав обратно ARP-ответ, который можно трактовать как: "Foo (10.0.0.1)! Я — здесь! Мой адрес 00:60:94:E9:08:12.". После этой "переклички" foo будет знать ethernet-адрес компьютера bar и сможет связаться с ним, пока опять не "забудет" (в кэше ARP) адрес компьютера bar (обычно записи в ARP-кэше удаляются через 15 минут).

Содержимое ARP-кэша можно просмотреть так:

[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) "знает", как найти компьютер espagate (9.3.76.1). А теперь добавим еще один адрес в наш кэш:

[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, ethernet-адрес последнего был добавлен в кэш. По истечении некоторого тайм аута (если между этими двумя компьютерами больше не было передано ни одного пакета), espa041 "забудет" адрес компьютера espa043 и для того чтобы что-то сообщить ему, опять потребуется послать ARP-запрос.

Удалим адрес компьютера espa043 из кэша:

[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. Если espa041 опять "захочет" что-то сообщить espa043, он будет вынужден вновь послать ARP-запрос. В этом листинге также видно, что в записи для espagate (9.3.76.1), состояние reachable (доступно) изменилось на stale (устарело). Это означает, что ethernet-адрес все еще является допустимым, но он должен быть подтвержден при первой же попытке обмена.