Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
! объявлять о всех подключенных маршрутах (= непосредственно подключенных интерфейсах)
redistribute connected
! объявлять о корневых маршрутах (= подставленных вручную)
redistribute kernel
Блок "router bgp" должен содержать сведения о своих "соседях":
neighbor 192.168.1.1 remote-as 1
neighbor 192.168.1.1 distribute-list local_nets in
neighbor 10.10.1.1 remote-as 50
neighbor 10.10.1.1 distribute-list local_nets in
17.2.3. Проверка конфигурации.
Note
vtysh — это мультиплексор, соединяющий все интерфейсы Zebra.
anakin# sh ip bgp summary
BGP router identifier 192.168.23.12, local AS number 23
2 BGP AS-PATH entries
0 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.0.1 4 50 35 40 0 0 0 00:28:40 1
192.168.1.1 4 1 27574 27644 0 0 0 03:26:04 14
Total number of neighbors 2
anakin#
anakin# sh ip bgp neighbors 10.10.0.1
BGP neighbor is 10.10.0.1, remote AS 50, local AS 23, external link
BGP version 4, remote router ID 10.10.0.1
BGP state = Established, up for 00:29:01
....
anakin#
А теперь посмотрим — какие маршруты были получены от "соседей":
anakin# sh ip ro bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
B - BGP, > - selected route, * - FIB route
B>* 172.16.0.0/14 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 172.30.0.0/16 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.10/32 [20/0] via 192.168.1.1, tun0, 2d10h27m
B>* 192.168.5.26/32 [20/0] via 192.168.1.1, tun0, 10:09:24
B>* 192.168.5.36/32 [20/0] via 192.168.1.1, tun0, 2d10h19m
B>* 192.168.17.0/24 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.17.1/32 [20/0] via 192.168.1.1, tun0, 3d05h07m
B>* 192.168.32.0/24 [20/0] via 192.168.1.1, tun0, 2d10h27m
anakin#
Глава 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 [email protected]) написал два сценария 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: Необходимо дополнить.
Глава 19. Рекомендуемая литература.
http://snafu.freedom.org/linux2.2/iproute-notes.html
Содержит большое количество технических сведений и комментариев к исходным текстам ядра.
http://www.davin.ottawa.on.ca/ols/
Джамал Хади Салим (Jamal Hadi Salim), один из авторов Linux traffic control.
http://defiant.coinet.com/iproute2/ip-cref/
HTML-версия документа, написанного Алексеем -- очень подробное описание части iproute2.
http://www.aciri.org/floyd/cbq.html
Неплохая страничка Салли Флойд (Sally Floyd), посвященная CBQ, содержит оригинальные документы, написанные ее рукой. Не относится к специфике Linux, но основным предметом дискуссии является теория применения SBQ. Можно рекомендовать тем, кого интересуют сугубо технические сведения.
Differentiated Services on Linux
Этот документ (созданный Вернером Альмсбергером (Werner Almesberger), Джамалом Хади Салимом (Jamal Hadi Salim) и Алексеем Кузнецовым) описывает возможности DiffServ в ядре Linux, в том числе TBF, GRED, DSMARK qdisc и классификатор tcindex.
http://ceti.pl/~kravietz/cbq/NET4_tc.html
Еще один HOWTO, но только на польском языке! Здесь вы найдете неплохие примеры, поскольку командная строка выглядит абсолютно одинаково на любом языке человеческого общения! Автор этого документа уже вступил с нами в контакт и возможно вскоре станет нашим соавтором!
