Глава 18. Прочие возможности.

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

Реализация 802.1Q VLAN для Linux

VLAN — очень интересный способ организации нескольких виртуальных локальных сетей в единой физической среде. Много полезной информации о виртуальных сетях вы найдете по адресу: ftp://ftp.netlab.ohio-state.edu/pub/jain/courses/cis788-97/virtual_lans/index.htm. С помощью этой реализации вы сможете использовать Linux в качестве маршрутизатора, на манер Cisco Catalyst, 3Com: [Corebuilder, Netbuilder II, SuperStack II switch 630], Extreme Ntwks Summit 48, Foundry: [ServerIronXL, FastIron].

Отличный HOWTO по организации VLAN: http://scry.wanfear.com/~greear/vlan/cisco_howto.html.

Включено в состав ядра, начиная с версии 2.4.14 (или может быть 13).

Альтернативная реализация 802.1Q VLAN для Linux

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

Linux Virtual Server

Команда блестящих разработчиков. Linux Virtual Server — высоко масштабируемый и очень перспективный сервер который основан на кластере из реальных серверов, с равномерным распределением нагрузки, под управлением операционной системы Linux. Архитектура кластера прозрачна для конечных пользователей, которые 'видят' только один-единственный виртуальный сервер.

Короче говоря, LVS предоставляет возможность равномерного распределения нагрузки при любом объеме трафика. Некоторые из решений, реализованных этой командой, очень необычны! Например, они позволяют нескольким машинам иметь один и тот же IP-адрес, при этом протокол ARP на них отключается. ARP работает только на головной LVS-машине, которая решает какому из внутренних хостов должен быть передан тот или иной входящий пакет, и передает его по MAC-адресу внутреннего сервера. Исходящий трафик передается маршрутизатору напрямую, а не через головную LVS-машину, благодаря чему для нее нет нужды отслеживать весь исходящий трафик, который по своему объему может быть просто ужасающим!

LVS реализован в виде "заплаты" на ядра версий 2.0 и 2.2. Для серий 2.4/2.5 – в виде модуля к Netfilter, т.е накладывать "заплату" на ядра этих версий уже не требуется!

CBQ.init

Конфигурирование CBQ можно немного упростить, особенно в том случае, если вам необходимо лишь сформировать трафик для нескольких компьютеров, стоящих позади маршрутизатора. CBQ.init поможет вам в этом, благодаря упрощенному синтаксису.

Например, если необходимо ограничить скорость загрузки, величиной 28 Кбит/сек, для всех компьютеров в локальной сети 192.168.1.0/24 (на 10 Мбитном eth1), поместите эти строки в файл конфигурации CBQ.init:

DEVICE=eth1,10Mbit,1Mbit

RATE=28Kbit

WEIGHT=2Kbit

PRIO=5

RULE=192.168.1.0/24

Мы рекомендуем эту программу тем, кого не интересуют вопросы "как" и "почему". CBQ.init давно используется нами и зарекомендовал себя с самой лучшей стороны. Здесь приведен очень простой пример конфигурирования CBQ.init, на самом деле он может много больше, например выполнять формирование трафика в зависимости от времени. Описание находится внутри сценария, по этой причине вы не найдете файл README.

Набор скриптов управления трафиком Chronox

Стефан Мюллер (Stephan Mueller smueller@chronox.de) написал два сценария limit.conn и shaper , первый из которых позволяет легко ограничить ширину канала для одиночной сессии, например так:

# limit.conn –s SERVERIP –p SERVERPORT –l LIMIT

Работают с ядрами 2.4/2.5.

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

Реализация протокола Virtual Router Redundancy Protocol (ссылка 1, ссылка 2)

FIXME: Эта ссылка "битая". Может кто подскажет — куда переехал проект?

Применяется исключительно для "горячего" резервирования. Две машины, имеющие свои собственные IP и MAC адреса, образуют третий, виртуальный IP и MAC адрес. Изначально этот протокол предназначался для "горячего" резервирования маршрутизаторов, которые требуют наличия постоянного MAC-адреса, но вполне подойдет и для серверов другого типа.

Вся прелесть этой реализации заключается в простоте настройки и отсутствии необходимости пересборки ядра.

Просто, на каждой из машин запускается команда, например такая:

# vrrpd –i eth0 –v 50 10.0.0.22

и все! Теперь адрес 10.0.0.22 обслуживается одним из серверов, вероятнее всего тем, на котором команда vrrpd была запущена первой. Теперь, если этот сервер отключить от сети, то довольно быстро обслуживание виртуальных IP и MAC адресов возьмет на себя один из оставшихся компьютеров.

Я попытался смоделировать эту ситуацию. Правда по необъяснимой причине у меня сбрасывался шлюз по-умолчанию, но флаг –n решил мои проблемы.

Ниже приводится временная диаграмма "сбойной" ситуации:

64 bytes from 10.0.0.22: icmp_seq=3 ttl=255 time=0.2 ms

64 bytes from 10.0.0.22: icmp_seq=4 ttl=255 time=0.2 ms

64 bytes from 10.0.0.22: icmp_seq=5 ttl=255 time=16.8 ms

64 bytes from 10.0.0.22: icmp_seq=6 ttl=255 time=1.8 ms

64 bytes from 10.0.0.22: icmp_seq=7 ttl=255 time=1.7 ms

НИ ОДИН ICMP-пакет не был потерян! После передачи 4-го пакета мой P200 был отключен от сети и обслуживание виртуальных адресов тут же перехватил 486-й, это можно наблюдать по увеличившемуся времени отклика.

tc-config

tc-config — это набор сценариев для конфигурирования подсистемы управления трафиком на Linux 2.4+ для Red Hat. В качестве корневой дисциплины используется CBQ qdisc, в "листьях" — SFQ qdisc.

Включает утилиту snmp_pass, которая получает статистику управления трафиком через snmp. FIXME: Необходимо дополнить.