Читать онлайн «Linux Advanced Routing & Traffic Control HOWTO». Страница 26

Note

Сообщения ICMP Destination Unreachable обычно отсылаются тогда, когда невозможно определить дальнейший маршрут движения пакета. Этому могут быть три причины:

1. Невозможно выполнить передачу хосту.

2. Не известен маршрут к заданному сегменту сети или хосту.

3. Если данный маршрут запрещен набором правил маршрутизации.

В этих трех случаях сетевая подсистема генерирует сообщение ICMP Destination Unreachable, свое для каждого случая:

1. ICMP Host Unreachable — когда хост, находящийся в той же сети, что и наш роутер — недоступен.

2. ICMP Network Unreachable — когда в таблице маршрутизации роутера нет ни одного маршрута, по которому пакет мог бы быть отправлен дальше.

3. ICMP Communication Administratively Prohibited By Filtering — когда пакет не может быть переправлен из-за наличия правил маршрутизации явно запрещающих передачу.

Значение по-умолчанию — 500. Учитывая значение по-умолчанию переменной error_cost (100) это соответствует 5-ти сообщениям ICMP Destination Unreachable в секунду. 

/proc/sys/net/ipv4/route/flush

Запись любой информации в эту переменную (само собой разумеется, запись может быть произведена только, если вы обладаете правами root) приведет к очистке кэша маршрутов.

/proc/sys/net/ipv4/route/gc_elasticity

Значения, управляющие частотой и поведением алгоритма сборки "мусора" в кэше маршрутизации. Может оказаться полезным при восстановлении после сбоев. Прежде чем Linux сможет перейти к другому маршруту, пройдет не менее gc_timeout секунд (по-умолчанию — 300), если использовавшийся ранее оказался недоступным. Это число можно немного уменьшить, чтобы ускорить восстановление после сбоев.

См. также это сообщение, которое отправил Ard van Breemen.

/proc/sys/net/ipv4/route/gc_interval

См. описание /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_min_interval

См. описание /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_thresh

См. описание /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/gc_timeout

См. описание /proc/sys/net/ipv4/route/gc_elasticity.

/proc/sys/net/ipv4/route/max_delay

Максимальный размер задержки перед сбросом кэша маршрутов.

/proc/sys/net/ipv4/route/max_size

Максимальный размер кэша маршрутов. Устаревшие записи будут удаляться из кэша только после достижения размера кэша этой величины

/proc/sys/net/ipv4/route/min_adv_mss

FIXME: Восполните этот пробел.

/proc/sys/net/ipv4/route/min_delay

Минимальный размер задержки перед сбросом кэша маршрутов.

/proc/sys/net/ipv4/route/min_pmtu

FIXME: Восполните этот пробел.

/proc/sys/net/ipv4/route/mtu_expires

FIXME: Восполните этот пробел.

/proc/sys/net/ipv4/route/redirect_load

Факторы, влияющие на принятие решения о пересылке сообщений перенаправления на заданный хост. Перенаправление не производится в случае, если величина нагрузки или количество отправленных сообщений достигли своего предела.

/proc/sys/net/ipv4/route/redirect_number

См. описание /proc/sys/net/ipv4/route/redirect_load

/proc/sys/net/ipv4/route/redirect_silence

Таймаут перенаправления. По истечении этого периода времени, сообщение о переадресации посылается снова, независимо от того были ли достигнуты пределы redirect_load или redirect_number.

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

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

Длина pfifo измеряется в пакетах, bfifo — в байтах.

limit

Задает длину очереди. Для pfifo измеряется в пакетах, для bfifo — в байтах. По-умолчанию имеет значение: для pfifo — txqueuelen интерфейса (см. раздел pfifo_fast), в пакетах, и txqueuelen * mtu байт — для bfifo.

Этот алгоритм настолько "заумный", что даже Алексей (главный автор CBQ) утверждает — будто бы не до конца понял его суть. С его слов:

David D. Clark, Scott Shenker и Lixia Zhang. Поддержка Приложений Реального Времени в Пакетных Сетях c Интеграцией Сервисов: Архитектура и Механизм.

Насколько я понял, основная идея заключается в создании WFQ-потоков для каждого из сервисов с гарантированным качеством обслуживания и привязка оставшейся пропускной способности к фиктивному потоку flow-0 . В поток flow-0 отправляется весь предиктивный трафик и трафик, который обслуживается по принципу "лучшее из оставшегося" (best effort). Планировщик потока в первую очередь пропускает предиктивный трафик, а оставшаяся пропускная способность отдается трафику "best effort".

Примечательно, что в CSZ-потоках (Clark-Shenker-Zhang) НЕ производится наложения ограничений пропускной способности. Предполагается, что поток уже прошел входной контроль QoS сети и не нуждается в дополнительном формировании. Любая попытка что-то улучшить или ограничить, на промежуточных переходах, может привести к нежелательным задержкам и увеличению нестабильности.

На сегодняшний день CSZ – единственный планировщик, который может дать настоящую гарантию качества обслуживания. Другие схемы (включая CBQ) не гарантируют величину задержки.

В настоящее время не может быть рекомендован к использованию, если вы не читали или не достаточно четко понимаете содержимое упомянутого документа.

Esteve Camps

< [email protected]>

Этот текст — отрывки из моих тезисов Поддержка QoS в Linux, сентябрь 2000 года.

Исходные документы:

• Draft-almesberger-wajhak-diffserv-linux-01.txt

• Примеры, прилагаемые к дистрибутиву iproute2

• White Paper-QoS protocols and architectures и IP QoS Frequently Asked Questions.

Автор главы: Esteve Camps < [email protected]>.

Прежде всего, было бы неплохо, если бы вы предварительно ознакомились с RFC, посвященными данной теме (RFC2474, RFC2475, RFC2597 и RFC2598) по адресам: IETF DiffServ working Group и домашняя страничка проекта diffserv.

Dsmark -— это дисциплина организации очереди, которая предлагает возможности, необходимые в "Differentiated Services" (известной также, как DiffServ, или просто — DS). DiffServ — фактически одна из двух архитектур QoS (вторая называется "Integrated Services"), которая базируется на значении поля DS в заголовке IP-пакетов.

Одним из первых решений в IP, которое предлагало некоторый уровень QoS, был "Type of Service" (Тип Обслуживания) — поле TOS в IP-заголовке. Изменяя это поле, можно было выбрать высокую/низкую пропускную способность, минимальную задержку или высокую надежность. Но это решение не обеспечивало достаточной гибкости, которую требовали вновь появляющиеся услуги (например, приложения реального времени, интерактивные приложения и т.п.). С появлением новых требований, появились и новые архитектуры. Одна из них — DiffServ, которая подменяет первые шесть битов ToS в пакете IPv4 или октет "класс трафика" в пакете IPv6, полем, с названием DS, в котором можно указать до 64 классов трафика.

Differentiated Services (Дифференцированное Обслуживание) ориентирован на группы. Имеется ввиду, что эта технология ничего не знает о потоках, она ориентирована на группы, а применяемые правила зависят от того, к какой группе направляется пакет.

Сеть маршрутизаторов с поддержкой механизмов DiffServ называют "облаком DiffServ" (или "доменом DiffServ"). Классификация, формирование и установка меток (под установкой меток понимается установка значений в поле DS) происходит на входе в "облако". Внутри домена метка определяет — какой уровень QoS должен применяться к трафику внутренними маршрутизаторами сети.

Самым большим преимуществом модели DiffServ является то, что она действует на границе "облака". После того как данные пересекли границу, внутренним маршрутизаторам можно не заниматься поддержанием информации о статусе QoS и полностью сосредоточиться на своей основной функции — маршрутизации.

Фактически, внутри своих локальных доменов, вы можете диктовать любую политику обслуживания, но при соединении с другими DS-доменами вы должны следовать Соглашению об Уровне Обслуживания (SLA).