xg-scale

annotate bridge.tex @ 0:4730a0d07d88

Исходники курса после первого прочтения.
Правки (которых должно быть много),
ещё пока не вносились.
author Igor Chubin <igor@chub.in>
date Tue Jul 01 16:16:44 2008 +0300 (2008-07-01)
parents
children
rev   line source
igor@0 1 \section{Программный мост в Linux}
igor@0 2
igor@0 3 \textbf{Бридж} (англ. \textit{bridge}, мост) — это способ соединения двух сегментов Ethernet на канальном уровне, т.е. без использования протоколов более высокого уровня, таких как IP. Пакеты передаются на основе Ethernet-адресов, а не IP-адресов (как в маршрутизаторе). Поскольку передача выполняется на канальном уровне (уровень 2 модели OSI), все протоколы более высокого уровня прозрачно проходят через мост.
igor@0 4
igor@0 5 Термины коммутатор, мост и бридж могут использоваться на данной странице как взаимознаменяемые.
igor@0 6
igor@0 7 Код bridge в Linux является частичной реализацией стандарта \htmladdnormallinkfoot{ANSI/IEEE 802.1d}{http://standards.ieee.org/getieee802/}.
igor@0 8 Впервые бриджинг в Linux появился в 2.2, затем код был переписан
igor@0 9 Леннертом Буйтенхеком (Lennert Buytenhek).
igor@0 10 Код bridge интегрирован в ядра серий 2.4 и 2.6.
igor@0 11
igor@0 12 \subsection{Коммутация и фильтрация}
igor@0 13 Linux-мосты более мощные чем простые аппаратные мосты и коммутаторы,
igor@0 14 поскольку они могут ещё фильтровать и регулировать трафик.
igor@0 15 Комбинация коммутатора и брандмауэра выполняется с помощью
igor@0 16 родственного проекта
igor@0 17 ebtables.
igor@0 18
igor@0 19 \subsection{Состояние}
igor@0 20 Код обновляется как часть ядра Linux 2.4 и 2.6, доступного на kernel.org.
igor@0 21
igor@0 22 Возможные будущие усовершенствования:
igor@0 23 \begin{itemize}
igor@0 24 \item Описать фильтрацию STP
igor@0 25 \item Использовать Netlink interface для управление бриджами (прототип в 2.6.18)
igor@0 26 \item Добавить поддержку в user space
igor@0 27 \item Сделать поддержку RSTP и других расширений 802.1d STP
igor@0 28 \end{itemize}
igor@0 29
igor@0 30 \subsection{Скачивание}
igor@0 31 Поддержка бриджинга есть в текущих ядрах 2.4 и 2.6
igor@0 32 всех основных дистрибутивов Linux. Требуемый комплект утилит для администрирования
igor@0 33 \textit{bridge-utils} есть практически во всех дистрибутивах.
igor@0 34
igor@0 35 Инсталляция утилит выполняется стандартным для дистрибутива способом.
igor@0 36 Например, в Debian GNU/Linux:
igor@0 37 \begin{verbatim}
igor@0 38 # apt-get install bridge-utils
igor@0 39 \end{verbatim}
igor@0 40
igor@0 41 Исходный код последнего релиза утилит можно получить со \htmladdnormallinkfoot{этой}{http://sourceforge.net/project/showfiles.php?group\_id=26089} страницы.
igor@0 42
igor@0 43 Как вариант можно сделать свою самую последнюю сборку кода
igor@0 44 с kernel.org
igor@0 45 и собрать утилиты bridge-utils из GIT-репозитория.
igor@0 46
igor@0 47 \begin{verbatim}
igor@0 48 $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
igor@0 49 $ cd bridge-utils
igor@0 50 $ autoconf
igor@0 51 $ ./configure
igor@0 52 \end{verbatim}
igor@0 53
igor@0 54 \subsection{Ручная конфигурация}
igor@0 55 \subsubsection{Сетевые карты}
igor@0 56 Перед тем как вы приступите к настройке коммутатора, убедитесь,
igor@0 57 что сетевые карты работают нормально.
igor@0 58 Не устанавливайте на них IP-адресов, и не позволяйте начальным скриптам
igor@0 59 выполнять DHCP-запрос с них.
igor@0 60 IP-адреса должны устанавливаться уже после того как бридж сконфигурирован.
igor@0 61
igor@0 62 Команда ifconfig должна показывать обе (или больше, если их больше) сетевые карты, и они должны быть выключены, т.е. находиться в состоянии DOWN
igor@0 63 (это на момент начала настройки, дальше они будут переведены в UP).
igor@0 64
igor@0 65 \subsubsection{Загрузка модуля}
igor@0 66 В большинстве случаев код коммутатора оформляется в виде модуля.
igor@0 67 Если модуль сконфигурирован и установлен корректно,
igor@0 68 он автоматически загружается при первом вызове команды \textbf{brctl}.
igor@0 69
igor@0 70 Если ваши утилиты bridge-utilities корректно установлены,
igor@0 71 и ядро и его модуль bridge в порядке, вызовом команды \textbf{brctl}
igor@0 72 можно будет просмотреть маленькую сводку о синтаксисе команды:
igor@0 73 \begin{verbatim}
igor@0 74 # brctl
igor@0 75 # commands:
igor@0 76 addbr <bridge> add bridge
igor@0 77 delbr <bridge> delete bridge
igor@0 78 addif <bridge> <device> add interface to bridge
igor@0 79 delif <bridge> <device> delete interface from bridge
igor@0 80 setageing <bridge> <time> set ageing time
igor@0 81 setbridgeprio <bridge> <prio> set bridge priority
igor@0 82 setfd <bridge> <time> set bridge forward delay
igor@0 83 sethello <bridge> <time> set hello time
igor@0 84 setmaxage <bridge> <time> set max message age
igor@0 85 setpathcost <bridge> <port> <cost> set path cost
igor@0 86 setportprio <bridge> <port> <prio> set port priority
igor@0 87 show show a list of bridges
igor@0 88 showmacs <bridge> show a list of mac addrs
igor@0 89 showstp <bridge> show bridge stp info
igor@0 90 stp <bridge> <state> turn stp on/off
igor@0 91 \end{verbatim}
igor@0 92
igor@0 93 \subsubsection{Создание и удаление коммутатора}
igor@0 94 Команда
igor@0 95 \begin{verbatim}
igor@0 96 brctl addbr bridgename
igor@0 97 \end{verbatim}
igor@0 98
igor@0 99 создаёт экземпляр логического коммутатора с именем \textit{bridgename}.
igor@0 100 Для того чтобы выполнять коммутацию пакетов, нужно создать хотя бы один коммутатор .
igor@0 101 Можно воспринимать логический бридж как контейнер интерфейсов,
igor@0 102 принимающих участие в коммутации.
igor@0 103 Каждый экземпляр коммутатора представлен новым сетевым интерфейсом.
igor@0 104
igor@0 105 Соответствующая команда для удаления коммутатора:
igor@0 106 \begin{verbatim}
igor@0 107 brctl delbr bridgename
igor@0 108 \end{verbatim}
igor@0 109
igor@0 110 \subsubsection{Включение устройства в коммутатор}
igor@0 111 Команда
igor@0 112 \begin{verbatim}
igor@0 113 brctl addif bridgename device
igor@0 114 \end{verbatim}
igor@0 115 \noindent включает сетевое устройство \textit{device}
igor@0 116 в коммутатор с именем \textit{bridgename}.
igor@0 117 Все устройства, включенные в один бридж работают как одна большая сеть.
igor@0 118 Нельзя добавить устройство в несколько бриджей одновременно,
igor@0 119 поскольку это не имеет никакого смысла.
igor@0 120 Коммутатору потребуется небольшое время после того как устройство
igor@0 121 подключено, для того чтобы узнать его Ethernet-адрес, а затем
igor@0 122 он начинает делать перенаправление (forward).
igor@0 123
igor@0 124 Соответствующая команда для выключения устройства из коммутатора:
igor@0 125 \begin{verbatim}
igor@0 126 brctl delif bridgename device
igor@0 127 \end{verbatim}
igor@0 128
igor@0 129 \subsubsection{Просмотр устройств}
igor@0 130 Команда \textbf{brctl} \verb|show| показывает состояние всех работающих коммутаторов:
igor@0 131 \begin{verbatim}
igor@0 132 # brctl addbr br549
igor@0 133 # brctl addif br549 eth0
igor@0 134 # brctl addif br549 eth1
igor@0 135 # brctl show
igor@0 136 bridge name bridge id STP enabled interfaces
igor@0 137 br549 8000.00004c9f0bd2 no eth0
igor@0 138 eth1
igor@0 139 \end{verbatim}
igor@0 140 Если выполнить команду \textbf{brctl} \verb|showmacs|,
igor@0 141 будет показана информация о сетевых адресах
igor@0 142 источников трафика, прошедшего через коммутатор
igor@0 143 (и самого коммутатора тоже):
igor@0 144
igor@0 145 \begin{verbatim}
igor@0 146 # brctl showmacs br549
igor@0 147 port no mac addr is local? ageing timer
igor@0 148 1 00:00:4c:9f:0b:ae no 17.84
igor@0 149 1 00:00:4c:9f:0b:d2 yes 0.00
igor@0 150 2 00:00:4c:9f:0b:d3 yes 0.00
igor@0 151 1 00:02:55:1a:35:09 no 53.84
igor@0 152 1 00:02:55:1a:82:87 no 11.53
igor@0 153 ...
igor@0 154 \end{verbatim}
igor@0 155
igor@0 156 Время жизни (aging time) -- это количество секунд, которое
igor@0 157 MAC-адрес будет находится в таблице forwarding database
igor@0 158 после получения пакета с этим адресом.
igor@0 159 Записи в таблице периодически удаляются по тайм-ауту,
igor@0 160 для того чтобы не получилось, что они будут находиться там вечно.
igor@0 161 В нормальной ситуации, не понадобится менять данные параметры,
igor@0 162 но это сделать можно (время указывается в секундах)
igor@0 163
igor@0 164 \begin{verbatim}
igor@0 165 # brctl setageing ''bridgename'' ''time''
igor@0 166 \end{verbatim}
igor@0 167
igor@0 168 Если установить время в ноль, запись становится постоянной.
igor@0 169
igor@0 170 \subsubsection{Spanning Tree Protocol}
igor@0 171 Если используется несколько коммутаторов, для того чтобы избежать петель коммутации, нужно включить поддержку протокола
igor@0 172 Spanning Tree Protocol (Протокол остовного дерева).
igor@0 173
igor@0 174 \begin{verbatim}
igor@0 175 # brctl stp br549 on
igor@0 176 \end{verbatim}
igor@0 177
igor@0 178 Посмотреть параметры STP можно так:
igor@0 179
igor@0 180 \begin{verbatim}
igor@0 181 # brctl showstp br549
igor@0 182 br549
igor@0 183 bridge id 8000.00004c9f0bd2
igor@0 184 designated root 0000.000480295a00
igor@0 185 root port 1 path cost 104
igor@0 186 max age 20.00 bridge max age 200.00
igor@0 187 hello time 2.00 bridge hello time 20.00
igor@0 188 forward delay 150.00 bridge forward delay 15.00
igor@0 189 ageing time 300.00 gc interval 0.00
igor@0 190 hello timer 0.00 tcn timer 0.00
igor@0 191 topology change timer 0.00 gc timer 0.33
igor@0 192 flags
igor@0 193
igor@0 194 eth0 (1)
igor@0 195 port id 8001 state forwarding
igor@0 196 designated root 0000.000480295a00 path cost 100
igor@0 197 designated bridge 001e.00048026b901 message age timer 17.84
igor@0 198 designated port 80c1 forward delay timer 0.00
igor@0 199 designated cost 4 hold timer 0.00
igor@0 200 flags
igor@0 201
igor@0 202 eth1 (2)
igor@0 203 port id 8002 state disabled
igor@0 204 designated root 8000.00004c9f0bd2 path cost 100
igor@0 205 designated bridge 8000.00004c9f0bd2 message age timer 0.00
igor@0 206 designated port 8002 forward delay timer 0.00
igor@0 207 designated cost 0 hold timer 0.00
igor@0 208 flags
igor@0 209 \end{verbatim}
igor@0 210
igor@0 211 \paragraph{Настройка STP}
igor@0 212 Конфигурироваться может несколько параметров, имеющих отношение к Spanning Tree Protocol.
igor@0 213 Код автоматически определяет скорость соединения и другие параметры,
igor@0 214 поэтому, как правило, вручную их менять не нужно.
igor@0 215
igor@0 216 \paragraph{Приоритет коммутатора}
igor@0 217 У каждого коммутатора есть относительный приоритет (priority) и стоимость (cost).
igor@0 218 Каждый интерфейс коммутатора ассоциируется с номером порта в коде STP. У каждого есть приоритет и стоимость, на основе которых принимается решение о том, какой путь для передчи пакета является кратчайшим. Всегда используется путь с наимеьшей стоимостью (за исключением случая, когда этот путь разорван).
igor@0 219 Если у вас несколько коммутаторов и интерфейсов,
igor@0 220 может понадобиться отрегулировать приоритеты, чтобы достичь максимальной
igor@0 221 производительности.
igor@0 222
igor@0 223 \begin{verbatim}
igor@0 224 # brctl setbridgeprio ''bridgename'' ''priority''
igor@0 225 \end{verbatim}
igor@0 226
igor@0 227 Бридж с наименьшим приоритетом избирается как \textit{корневой}.
igor@0 228 Корневой бридж является центром остовного дерева (spanning tree)
igor@0 229 коммутационных связей.
igor@0 230
igor@0 231 \paragraph{Приоритет и стоимость}
igor@0 232 У каждого интерфейса моста может быть своя собственная скорость, и её значение
igor@0 233 используется при выборе какое соединение должно использоваться.
igor@0 234 У более быстрых интерфейсов должна быть более низкая стоимость.
igor@0 235
igor@0 236 \begin{verbatim}
igor@0 237 # brctl ''setpathcost bridge port cost''
igor@0 238 \end{verbatim}
igor@0 239
igor@0 240 Для разных портов, имеющих одинаковую стоимость
igor@0 241 существует ещё \textit{приоритет}.
igor@0 242
igor@0 243 \paragraph{Задержка передачи (Forwarding delay)}
igor@0 244 Задержка передачи (forwarding delay) это время
igor@0 245 в течение которого порт находится в состояниях
igor@0 246 Listening и Learning, прежде чем перейти в состояние Forwarding.
igor@0 247 Это время нужно для того чтобы мост, когда он включается в
igor@0 248 сеть, сначала должен ознакомиться с трафиком, прежде чем включаться
igor@0 249 в работу.
igor@0 250
igor@0 251 \begin{verbatim}
igor@0 252 # brctl setfd ''bridgename'' ''time''
igor@0 253 \end{verbatim}
igor@0 254
igor@0 255 \paragraph{Время Hello}
igor@0 256 Время от времени
igor@0 257 корневой мост (Root Bridge)
igor@0 258 и выделенные мосты (Designated Bridges)
igor@0 259 отправляют пакет \textit{hello}.
igor@0 260 Пакеты hello нужны для обмена информацией
igor@0 261 о топологии все коммутироемой локальной сети.
igor@0 262
igor@0 263 \begin{verbatim}
igor@0 264 # brctl sethello ''bridgename'' ''time''
igor@0 265 \end{verbatim}
igor@0 266
igor@0 267 \paragraph{max age -- таймаут hello}
igor@0 268 Если другой коммутатор в дереве spanning tree не отправляет пакет hello
igor@0 269 в течение долгого времени, считается, что он не в порядке (dead).
igor@0 270 Таймаут устанавливается командой:
igor@0 271 \begin{verbatim}
igor@0 272 # brctl maxage ''bridgename'' ''time''
igor@0 273 \end{verbatim}
igor@0 274
igor@0 275 \subsubsection{Пример настройки}
igor@0 276 Базовая настройка моста выполняется так:
igor@0 277
igor@0 278 \begin{verbatim}
igor@0 279 # ifconfig eth0 0.0.0.0
igor@0 280 # ifconfig eth1 0.0.0.0
igor@0 281 # brctl addbr mybridge
igor@0 282 # brctl addif mybridge eth0
igor@0 283 # brctl addif mybridge eth1
igor@0 284 # ifconfig mybridge up
igor@0 285 \end{verbatim}
igor@0 286
igor@0 287 Хост настраивается как обычный мост.
igor@0 288 У него самого нет IP-адреса, поэтому к нему
igor@0 289 нельзя получить доступ (или взломать) удалённо
igor@0 290 по TCP/IP.
igor@0 291
igor@0 292 Опционально можно настроить виртуальный интерфейс \textit{mybridge}
igor@0 293 на доступ по локальной сети.
igor@0 294 Он будет работать как обычный интерфейс -- как сетевая карта.
igor@0 295 Процесс настройки полностью совпадает с вышеописанным,
igor@0 296 за тем исключением, что нужно заменить
igor@0 297 последнюю команду на такую:
igor@0 298
igor@0 299 \begin{verbatim}
igor@0 300 # ifconfig mybridge 192.168.100.5 netmask 255.255.255.0
igor@0 301 \end{verbatim}
igor@0 302
igor@0 303 Если вы хотите чтобы мост автоматически получал IP-адрес
igor@0 304 у ADSL-модема по DHCP (или в другой похожей ситуации),
igor@0 305 сделайте так:
igor@0 306
igor@0 307 \begin{verbatim}
igor@0 308 # ifconfig eth0 0.0.0.0
igor@0 309 # ifconfig eth1 0.0.0.0
igor@0 310 # brctl addbr mybridge
igor@0 311 # brctl addif mybridge eth0
igor@0 312 # brctl addif mybridge eth1
igor@0 313 # dhclient mybridge
igor@0 314 \end{verbatim}
igor@0 315
igor@0 316 Если делать это много раз, процессов \textbf{dhclient} может расплодиться великое множество. Или безжалостно убейте их, или почитайте об \textbf{omshell}.
igor@0 317
igor@0 318 \subsection{Конфигурирование через /etc/net}
igor@0 319 Сначала в \texttt{/etc/net} настраиваются два ethernet-устройства port0 и port1:
igor@0 320 \begin{verbatim}
igor@0 321 # cat >> /etc/net/iftab
igor@0 322 port0 mac 00:13:46:66:01:5e
igor@0 323 port1 mac 00:13:46:66:01:5f
igor@0 324 ^D
igor@0 325 # mkdir /etc/net/ifaces/port0
igor@0 326 # cat > /etc/net/ifaces/port0/options
igor@0 327 TYPE=eth
igor@0 328 MODULE=via-rhine
igor@0 329 # mkdir /etc/net/ifaces/port1
igor@0 330 # cat > /etc/net/ifaces/port1/options
igor@0 331 TYPE=eth
igor@0 332 MODULE=via-rhine
igor@0 333 ^D
igor@0 334 \end{verbatim}
igor@0 335 После этого описывается мост:
igor@0 336 \begin{verbatim}
igor@0 337 # mkdir /etc/net/ifaces/mybridge
igor@0 338 # cat > /etc/net/ifaces/mybridge/options
igor@0 339 TYPE=bri
igor@0 340 HOST='port0 port1'
igor@0 341 ^D
igor@0 342 # cat > /etc/net/ifaces/mybridge/brctl
igor@0 343 stp AUTO on
igor@0 344 ^D
igor@0 345 \end{verbatim}
igor@0 346 После этого можно поднять бридж командой \textbf{ifup} \texttt{mybridge}. Устройства port0 и port1 поднимутся автоматически.
igor@0 347
igor@0 348 \subsection{FAQ}
igor@0 349 \subsubsection{Что делает мост/коммутатор?}
igor@0 350 Мост прозрачно пересылает трафик между несколькими сетевыми интерфейсами.
igor@0 351 На простом языке это означает, что коммутатор соединяет два или более интерфейсов Ethernet между собой, для того чтобы получилась большая Ethernet-сеть.
igor@0 352
igor@0 353 \subsubsection{Это как-то зависит от используемых протоколов?}
igor@0 354 Нет. Коммутатор ничего не знает о протоколах высокого уровня, он только видит кадры Ethernet. Поэтому функциональность моста является протоколонезависимой и проблем с передачей протоколов таких как IPX, NetBEUI, IP, IPv6 и других быть не должно.
igor@0 355
igor@0 356 \subsubsection{Чем этот код лучше чем аппаратный коммутатор?}
igor@0 357 Пожалуйста, имейте в виду, что этот код не писался
igor@0 358 с целью заменить Linux-боксами выделенное сетевое оборудование.
igor@0 359 Не надо воспринимать Linux с этим кодом как замену аппаратным коммутаторам.
igor@0 360 Это скорее расширение сетевых возможностей Linux. Как бывает, что Linux-маршрутизатор лучше чем аппаратный маршрутизатор (и наоборот),
igor@0 361 есть ситуации, когда Linux-мост лучше чем выделенный мост (и наоборот).
igor@0 362
igor@0 363 Основная сила кода моста Linux это его гибкость.
igor@0 364 И так есть уже огромнейшее количество всяких интересных
igor@0 365 вещей, которые можно делать с Linux (см. например, Linux Advanced Routing and Traffic Control), и мосты -- ещё одно добавление к этой гремучей смеси.
igor@0 366
igor@0 367 Одним из главных преимуществ решения, базирующегося на Linux,
igor@0 368 в сравнении с выделенным коммутатором
igor@0 369 являются разнообразные возможности по фильтрации трафика.
igor@0 370 Можно использовать всю функциональность netfilter (iptables) в комбинации
igor@0 371 с мостами, что даёт больший функционал, чем проприетарные решения.
igor@0 372
igor@0 373 \subsubsection{Чем этот код хуже чем аппаратный коммутатор?}
igor@0 374 Для того чтобы работать в качестве моста,
igor@0 375 устройство должно быть переведено в неразборчивый (promiscuous)
igor@0 376 режим, в котором оно получает весь трафик, приходящий на интерфейс.
igor@0 377 В действительно загруженных сетях, это может занять значительную часть
igor@0 378 процессора, замедляя работу системы.
igor@0 379 Выход -- или использовать выделенную Linux-систему в качестве моста
igor@0 380 или использовать аппаратный коммутатор.
igor@0 381
igor@0 382 \subsubsection{Какова производительность моста?}
igor@0 383 Производительность ограничивается используеммыми сетевыми картами и процессором.
igor@0 384 Джеймс Ю (James Yu) из университета DePaul провёл исследование,
igor@0 385 в котором выполнил сравнение Linux моста и коммутатора Catalyst
igor@0 386 Yu-Linux-TSM2004.pdf
igor@0 387
igor@0 388 \subsubsection{Моего моста не видно в трассе traceroute\rq{}а!}
igor@0 389 И не должно быть видно.
igor@0 390 Работа моста является полностью прозрачной для сети (по крайней мере должна);
igor@0 391 сети, которые мост соединяет между собой должны видеться как одна большая сеть.
igor@0 392 Именно поэтому мост и не виден в traceroute; пакеты и не думают о том, что они пересекают границы подсети.
igor@0 393
igor@0 394 Дополнительная информация об этом в книгах по сетям TCP/IP.
igor@0 395
igor@0 396 \subsubsection{Ничего не работает!}
igor@0 397 Когда я пытаюсь добавить мост, система говорит: \dq{}br\_add\_bridge: bad address\dq{}!
igor@0 398
igor@0 399 Или ваше ядро слишком старое (2.2 или более ранее), или вы забыли включить поддержку бриджей в ядро.
igor@0 400
igor@0 401 \subsubsection{Работает ли бриджинг на ядре 2.2?}
igor@0 402 Изначально разработка велась на 2.2, есть патчи для этого ядра.
igor@0 403 Но сейчас эти патчи уже не поддерживаются и не развиваются.
igor@0 404
igor@0 405 \subsubsection{Есть ли в планах поддержка RSTP (802.1w)?}
igor@0 406 Да. Ведётся работа по включению поддержки RSTP в будущий релиз для ядра 2.6. Код делался для ядра 2.4 и нуждается в доработке, тестировании и обновлении.
igor@0 407
igor@0 408 \subsubsection{Что можно соединять с помощью моста?}
igor@0 409 Мосты Linux очень гибкие; можно соединять
igor@0 410 как традиционные ethernet-устройства, так и псевдоустройства такие
igor@0 411 как PPP, VPN или VLAN\rq{}ы.
igor@0 412
igor@0 413 Ограничения, которые накладываются на соединяемые устройства:
igor@0 414 \begin{itemize}
igor@0 415 \item У всех должен быть одинаковый максимальный размер пакета (MTU). Мост не выполняет фрагментирование пакетов.
igor@0 416 \item Устройства должны выглядеть как Ethernet, т.е. у них должны быть 6-байтные адреса отправителя и получателя.
igor@0 417 \item Должен поддерживаться неразборчивый (promiscuous) режим. Мост должен получать не только трафик, адресованный ему, но и весь сетевой трафик.
igor@0 418 \item Должен быть разрешён спуфинг адресов. У моста должна быть возможность отправлять данные по сети, как если бы они пришли от другого хоста.
igor@0 419 \end{itemize}
igor@0 420
igor@0 421 \subsubsection{Можно ли выполнять коммутацию в сочетании с netfilter/iptables?}
igor@0 422 Да. Соответствующий код включен в большинство ядер. Смотрите проект ebtables.
igor@0 423
igor@0 424 \subsubsection{Работает ли он с Token Ring, FDDI и Firewire?}
igor@0 425 Нет. У этих протоколов отличается адресация и размер кадра.
igor@0 426
igor@0 427 \subsubsection{Я продолжаю получать сообщение \dq{}retransmitting tcn bpdu\dq{}!}
igor@0 428 Это означает, что ваш Linux-мост ретранслирует сообщение
igor@0 429 Topology Change Notification Bridge Protocol Data Unit
igor@0 430 Это означает что где-то есть коммутатор (или другой Linux-мост),
igor@0 431 который не согласен с правилами STP.
igor@0 432
igor@0 433 В каждой коммутируемой сети есть один \dq{}главный коммутатор\dq{},
igor@0 434 который также называется \textit{корневым} (root).
igor@0 435 Какой именно мост является корневым можно узнать с помощью \textbf{brctl}.
igor@0 436
igor@0 437 Когда топология коммутируемой сети меняется (например, кто-то выдернул
igor@0 438 кабель между коммутаторами), коммутатор, который это обнаружил,
igor@0 439 отправляет сообщение корневому коммутатору.
igor@0 440 Корневой коммутатор устанавливает бит \rq{}topology changed\rq{}
igor@0 441 в пакеты hello, которые будут отправляеться в течение следующих X секунд
igor@0 442 (обычно X равно 30). В результате все мосты узнают об изменении топологии,
igor@0 443 и они могут работать с учётом этого -- например удалить устаревшие MAC-записи.
igor@0 444
igor@0 445 После того как коммутатор отправляет сообщение об изменении топологии,
igor@0 446 он ждёт что в hello-сообщении будет установлени бит \rq{}\dq{}topology changed\dq{}.
igor@0 447 Если его нет (бит в данном случае играет роль подтверждения получения информации
igor@0 448 о смене топологии), коммутатор решает, что сообщение было потеряно.
igor@0 449 Поэтому пересылает сообщение повторно.
igor@0 450 Однако, в некоторых коммутаторах реализациия
igor@0 451 STP немного недоделанная, и они не отправляют подтверждение
igor@0 452 получения сообщения об изменении топологии.
igor@0 453 Если один из таких коммутаторов у вас корневой,
igor@0 454 все остальные коммутаторы будут постоянно повторно пересылать
igor@0 455 информацию об изменении топологии.
igor@0 456 В результате чего и будут появляеться такие сообщения.
igor@0 457
igor@0 458 Список вещей, которые можно сделать:
igor@0 459 \begin{itemize}
igor@0 460 \item Найти какой коммутатор является корневым, где он находится и под управлением какого программного обеспечения работает. Пожалуйста, сообщите о таком коммутаторе в список рассылки, чтобы можно было его добавить в blacklist.
igor@0 461 \item Заставить Linux-мост быть корневым. Найдите какой приоритет у коммутатора, который сейчас является корневым, и с помощью команды \textbf{brctl} \verb|setbridgeprio| установите приоритет линуксового моста на 1 меньше (Мост с наименьшим приоритеом всегда становится корневым).
igor@0 462 \item Вообще отключите STP на Linux-мосте. Только смотрите чтобы не появилось петель коммутации! Если у вас есть петли, и не работает STP, пакеты зациклятся и будут гулять по сети вечно, что сделает её нерабочей.
igor@0 463 \end{itemize}
igor@0 464
igor@0 465 \subsubsection{Оно не работает с моей обычной ethernet-карточкой!}
igor@0 466 К сожалению, у некоторых сетевых карт глючные драйверы,
igor@0 467 которые сбоят во время загрузки.
igor@0 468 Ситуация улучшается, поэтому может помочь установка текущего ядра и сетевых драйверов. Ещё можно попробовать устройства другого производителя.
igor@0 469
igor@0 470 Пожалуйста, сообщайте обо всех проблемах
igor@0 471 в список рассылки \dq{}Bridge mailing list\dq{}: bridge@osdl.org.
igor@0 472 Если ваша сетевая карта не работает даже без бриджинга,
igor@0 473 попробуйте обратиться в список рассылки
igor@0 474 \dq{}Linux networking mailing list\dq{} linux-net@vger.kernel.org.
igor@0 475
igor@0 476 \subsubsection{Оно не работает с моей wireless-карточкой!}
igor@0 477 Это известная проблема, и она не связана с кодом моста.
igor@0 478 Большое количество wireless-карт не позволяет делать подмену (spoofing)
igor@0 479 адреса источника. В некоторых чипсетах это ограничение на уровне прошивки (firmware).
igor@0 480 Дополнительная информация может быть найдена в архивах списков рассылки.
igor@0 481
igor@0 482 Удалось ли кому-нибудь обойти проблему связанную с тем,
igor@0 483 что Wavelan не позволяет использовать никакие MAC-адреса за исключением
igor@0 484 своего собственного?
igor@0 485
igor@0 486 \textit{(Отвечает Michael Renzmann, mrenzmann at compulan.de)}
igor@0 487
igor@0 488 99\% пользователей никогда не смогут избавиться от этой проблемы.
igor@0 489 Для такой функции нужна специальная прошивка. Её нужно загрузить
igor@0 490 в память WaveLAN-карточки и тогда карточка сможет выполнять бриджинг.
igor@0 491 Но нет общедоступной документации интерфейса.
igor@0 492 Единственный выход -- иметь полную версию библиотеки hcf,
igor@0 493 которая контролирует все действия карты, и в частности,
igor@0 494 доступ к памяти карты.
igor@0 495 Для получения этой библиотеки нужно убедить компанию Lucent,
igor@0 496 что это ей будет выгодно и помимо этого подписать NDA.
igor@0 497 Поэтому, скорее всего, пока Lucent не передумает,
igor@0 498 вам не удастся получить доступ к коду (а в том, что Lucent передумает
igor@0 499 есть большие сомнения).
igor@0 500
igor@0 501 Если вам срочно нужна wireless-карта которая может работать в мосте,
igor@0 502 нужно использовать те, что построены на базе чипсета \textit{prism}
igor@0 503 (изготавливает Harris Intersil).
igor@0 504 Драйверы для этой карты есть на www.linux-wlan.com
igor@0 505 (веб-сайт от Absoval), и в одном из сообщений говорится,
igor@0 506 что общедоступна необходимая прошивка и программа для загрузки для Linux.
igor@0 507 Если вам нужны какие-то дополнительные возможности, нужно разговаривать
igor@0 508 с Absoval.
igor@0 509
igor@0 510 \subsubsection{И всё же я не понимаю!!}
igor@0 511 Полноценный мост для беспроводных сетей (802.11) требует поддержки WDS.
igor@0 512 В текущей реализации её нет.
igor@0 513
igor@0 514 Можно сделать ограниченную функциональность с некоторыми драйверами.
igor@0 515 Для этого обязательно чтобы устройство поддерживало
igor@0 516 разные адреса отправителя и получателя. Что и обеспечивает WDS.
igor@0 517
igor@0 518 Есть способы добиться чтобы оно заработало, но они достаточно запутанные,
igor@0 519 и их сложно понять без досконального знания 802.11, режимов его работы и формата загловка кадра.
igor@0 520
igor@0 521 \subsubsection{Я получаю ошибку \rq{}too much work in interrupt\rq{}}
igor@0 522 Это связано с тем, что сетевая карта теряет пакеты.
igor@0 523 Можно попробовать несколько вещей. Во-первых, собрать
igor@0 524 драйвер с поддержкой NAPI (если он по умолчанию, не включен).
igor@0 525 NAPI делает так чтобы получал управление по программному прерыванию,
igor@0 526 не по прерыванию низкого уровня.
igor@0 527
igor@0 528 Если драйвер не поддерживает NAPI, можно попробовать
igor@0 529 увеличить объём работы, который драйвер может делать
igor@0 530 в течение обработки прерывания.
igor@0 531 Для 3c59x это делается с помощью опции \verb|max_interrupt_work| (поэтому нужно добавить опцию \verb|options 3c59x max_interrupt_work=10000| в файл \texttt{/etc/modules.conf}).
igor@0 532 У других сетевых карт похожие опции.
igor@0 533
igor@0 534 \subsubsection{Работает ли DHCP через/поверх моста?}
igor@0 535 Мост передаёт DHCP-трафик (широковещательный) и ответы на него.
igor@0 536 Также можно использовать DHCP для установки локального IP-адреса на псевдо-интерфейс моста.
igor@0 537
igor@0 538 Одна из распространённых ошибок при использовании DHCP является установка задержки передачи (forwarding delay) на порту коммутатора равной 30 секунд.
igor@0 539 При такой задержке интерфейс когда он подключился к мосту не может посылать
igor@0 540 через него данные в течении первых 30 секунд. Причина в том, что при использовании моста в сложной топологии он должен сначала обнаружить остальные мосты дабы не создавать петель. Проблема была одной из причин создания протокола
igor@0 541 Rapid Spanning Tree Protocol (RSTP).
igor@0 542
igor@0 543 Если мост используется в одиночку (т.е. поблизости нет мостов)
igor@0 544 можно спокойно отключить задержку передачи (установить её равной 0)
igor@0 545 перед тем как подключать интерфейс к мосту.
igor@0 546 После этого сразу же можно вызывать dhclient:
igor@0 547
igor@0 548 \begin{verbatim}
igor@0 549 # brctl setfd br0 0
igor@0 550 # brctl addif br0 eth0
igor@0 551 # dhclient eth0
igor@0 552 \end{verbatim}
igor@0 553
igor@0 554 \subsection{Дополнительная информация}
igor@0 555 \begin{itemize}
igor@0 556 \item \htmladdnormallinkfoot{Linux Bridge}{http://xgu.ru/wiki/Linux\_Bridge} (рус.)
igor@0 557 \item \htmladdnormallinkfoot{Ethernet VPN bridging}{http://openvpn.sourceforge.net/bridge.html}
igor@0 558 \item \htmladdnormallinkfoot{Ebtables firewalling}{http://ebtables.sourceforge.net}
igor@0 559 \item \htmladdnormallinkfoot{Ethernet-bridge + netfilter HOWTO}{http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO.html}
igor@0 560 \item \htmladdnormallinkfoot{Linux-bridge STP HOWTO}{http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html}
igor@0 561 \item \htmladdnormallinkfoot{Spanning Tree Protocol}{http://en.wikipedia.org/wiki/Spanning\_tree\_protocol} на Wikipedia
igor@0 562 \end{itemize}
igor@0 563