Linux Advanced Routing & Traffic Control HOWTO
Шрифт:
FIXME: Место редактора вакантно!
Multicast-HOWTO достаточно сильно устарел и по этой причине может быть местами неточен, а иногда и совершенно неверным.
Для того, чтобы иметь возможность маршрутизации групповых сообщений, необходимо определенным образом сконфигурировать ядро Linux. Это, в свою очередь, требует, чтобы вы определились — какой из протоколов групповой маршрутизации будет использоваться. На сегодняшний день, существует четыре основных протокола: DVMRP (групповая версия протокола RIP unicast), MOSPF (то же самое, но для OSPF), PIM-SM (Protocol Independent Multicast-Sparse Mode) — Протокол Групповой Маршрутизации, не зависящий от "обычного" протокола маршрутизации, который применяется
Однако, в ядре Linux, эти опции отсутствуют, потому что собственно протокол обслуживается отдельными приложениями, выполняющими маршрутизацию, такими как Zebra, mrouted или pimd . Тем не менее включение дополнительных опций в ядре необходимо.
Независимо от протокола групповой рассылки необходимо включить опции IP: multicasting и IP: multicast routing. Для DVMRP и MOSPF этого будет вполне достаточно. Если вы предполагаете использовать протокол маршрутизации PIM, то вы дополнительно должны разрешить опции PIM-SM version 1 или PIM-SM version 2 , в зависимости от версии протокола PIM , используемого в вашей сети.
После того, как вы разберетесь с необходимыми опциями и пересоберете ядро, вы заметите, что во время загрузки, среди прочих, в списке присутствует протокол IGMP. Это Протокол Управления Группами (IGMP — Internet Group Management Protocol). К моменту написания этих строк, Linux поддерживал только версии 1 и 2 протокола IGMP , хотя версия 3 уже вышла. Однако для нас это не имеет большого знаения, поскольку IGMP v3 достаточно нов и его дополнительные возможности еще не скоро найдут широкое применение. В дальнейшем описании мы будем предполагать использование самых основных характеристик протокола IGMPv2, хотя будем встречаться и с IGMPv1.
Итак, мы разрешили групповую маршрутизацию в ядре. Теперь необходимо "сообщить" ему — что собственно со всем этим делать. Это означает, что нужно добавить в таблицу маршрутизации виртуальную сеть для групповых рассылок.
(Естественно, в данном случае предполагается, что маршрутизация производится через устройство eth0! Если вы используете другое устройство – измените команду соответствующим образом)
А теперь "включим" перенаправление (forwarding):
и попробуем – что у нас получилось. Для этого ping– анем предопределенную группу, с адресом 224.0.0.1 (этот адрес зарезервирован IANA и обозначает "все узлы в данной сети". прим. перев.). В результате все машины в локальной сети, на которых включена поддержка возможности обслуживания групповых рассылок, должны ответить. Вы наверняка заметите, что все ответившие "подписываются" своим собственным IP-адресом, а не адресом 224.0.0.1. Вот это сюрприз! :) Все члены группы устанвливают в качестве исходящего, свой адрес, а не адрес группы.
С
этого момента вы готовы производить групповую маршрутизацию. При этом предполагается, что у вас имеется две сети, между которыми и выполняется маршрутизация.(Продолжение следует…)
Глава 9. Дисциплины обработки очередей для управления пропускной способностью
Когда я узнал об этом, я был в полнейшем восторге. Linux 2.2/2.4 содержит все необходимое для управления полосой пропускания на уровне специализированных систем управления пропускной способностью.
Linux предоставляет даже больше возможностей, чем FrameRelay и ATM.
Чтобы избежать путаницы, утилита tc использует следующие единицы измерения для задания пропускной способности:
Хранятся данные в bps и b.
Но при выводе, tc использует сделующее соглашение:
9.1. Понятие очереди и дисциплины обработки
Организация очереди (очередизация) определяет способ отсылки данных. Важно понимать, что мы можем управлять лишь скоростью передачи отправляемых данных.
В том виде, в каком сейчас существует Internet, мы не можем контролировать объем входящего трафика. Это что-то вроде почтового ящика (не электронного!). Нет никакого способа влиять на то, какой объем почты приходит к вам, разве что общаясь с каждым респондентом.
Однако, Internet, в большистве своем, основан на протоколе TCP/IP, а у него есть несколько свойств, которые могут нам помочь. TCP/IP не может узнать пропускной способности сети между двумя хостами, поэтому он начинает передавать данные все быстрее и быстрее (это называется "медленный старт"). Когда пакеты начинают теряться из-за перегрузки передающей среды, передача тормозится. На самом деле все немного сложнее и умнее, но об этом позже.
Продолжая нашу аналогию, это можно сравнить с выбрасыванием половины вашей почты в надежде на то, что люди перестанут вам писать. Разница лишь в том, что в случае с Internet этот прием срабатывает :-)
Если у вас есть маршрутизатор и вы хотите ограничить скорость загрузки во внутренней сети, вам нужно это делать на внутреннем интерфейсе маршрутизатора, с которого данные передаются вашим компьютерам.
Кроме того, вы должны быть уверенны, что контролируете узкое место соединения. Так, если у вас есть 100-мегабитная сетевая карта и маршрутизатор с соединением в 256 Кбит/сек, вы должны убедиться, что не посылаете данных больше, чем ваш маршрутизатор может передать. Иначе канал будет контролировать маршрутизатор и именно он будет ограничивать доступную пропускную способность. Нам нужно, так сказать, "владеть очередью" и быть самым медленным звеном. К счастью это легко реализуется.
9.2. Простые бесклассовые дисцплины обработки очереди.
Как уже говорилось, дисциплины обработки очереди определяют способ передачи данных. Бесклассовые дисциплины, в общем, получают данные, переупорядочивают, вносят задержку или уничтожают их.
Они могут использоватся для ограничения пропускной способности интерфейса целиком, без какого-либо разделения по классам. Крайне важно, чтобы вы поняли назначение этого типа очередей перед тем, как мы перейдем к классовым дисциплинам!