настройка бриджа на Linux
up! Чё, никто бридж не настраивал, что ли?
настраивали
такой фигни не было
была фигня, потому что iptables не пускало
такой фигни не было
была фигня, потому что iptables не пускало
а если в iptables вообще пусто - разве может между интерфейсами что-то ходить?
если default policy — ACCEPT, то почему бы и нет?
> такой фигни не было
Может такой баг возникать из-за каких-то особенностей работы DHCP? По типу того, как например, HTTP через NAT работает, а FTP — нет (если не passive mode)?
Чем может быть вызвано то, что два компа напрямую соединены линком, но при этом tcpdump на этот линк у них показывает разные результаты?
Может такой баг возникать из-за каких-то особенностей работы DHCP? По типу того, как например, HTTP через NAT работает, а FTP — нет (если не passive mode)?
Чем может быть вызвано то, что два компа напрямую соединены линком, но при этом tcpdump на этот линк у них показывает разные результаты?
сказки какие-то
Чем может быть вызвано то, что два компа напрямую соединены линком, но при этом tcpdump на этот линк у них показывает разные результаты?Нуу.... может быть вызвано массой разных причин
> Нуу.... может быть вызвано массой разных причин
Приведи хотя бы несколько. Честное слово, не знаю, чего делать...
Факты:
- линк 100% нормальный, packet loss отсутствует, в остальное время все работает на ура (12 MB/s файлы качает);
- tcpdump одинаковой версии (3.9.5);
- с обоих сторон Linux 2.6.18;
- файрволл девственно чист (на все ACCEPT).
Приведи хотя бы несколько. Честное слово, не знаю, чего делать...
Факты:
- линк 100% нормальный, packet loss отсутствует, в остальное время все работает на ура (12 MB/s файлы качает);
- tcpdump одинаковой версии (3.9.5);
- с обоих сторон Linux 2.6.18;
- файрволл девственно чист (на все ACCEPT).
> Приведи хотя бы несколько.
Перечисли все уровни, которые проходит пакет после того, как его увидел tcpdump. В каждом из них может быть баг или проблема.
Перечисли все уровни, которые проходит пакет после того, как его увидел tcpdump. В каждом из них может быть баг или проблема.
на всякий случай убедись, что в /proc/sys/net/bridge/bridge-nf-call-iptables стоит 0
DHCP через бридж работает нормально
DHCP через бридж работает нормально
Кажется, удалось обнаружить где собака зарыта.
Ситуация примерно такая. Клиент посылает несколько DHCP-запросов с увеличивающимся интервалом. К нему не приходит ни одного ответа, и после 4-го пакета пишет "Извини, чувак, не склалось. Работать не буду." Однако, дальше траффик от него начинает форвардиться.
Посмотрев логи обнаружил, что в них сыплются примерно такие сообщения:
br0: port 2(eth0) entering listening state
br0: port 2(eth0) entering learning state
br0: topology change detected, propagating
br0: topology change detected, propagating
и так примерно 30 секунд. После этих 30 секунд, траффик начинает нормально ходить и все ок. А в первые 30 секунд бридж тупит и не пересылает пакеты. Клиент же, успевает послать все свои 4 запроса как раз в эти 30 секунд, и поэтому ничего не видит.
Пробовал делать команду brctl setfd br0 2 чтобы уменьшить forward delay. Теперь бридж тупит не 30 секунд, а всего 4. Первый DHCPOFFER при этом по-прежнему игнорируется, зато второй уже проходит и клиент получает адрес. Однако дальше бридж опять почему-то тупит, часть пакетов теряется и ничего не работает.
Вопрос: как отрубить этот противоестественный интеллект с learning state, topology change detected итп. Необходимо, чтобы бридж просто пересылал в eth0, все что пришло в eth1, и пересылал в eth1, все что пришло в eth0. Без каких-либо попыток что-то подрюхать.
Ситуация примерно такая. Клиент посылает несколько DHCP-запросов с увеличивающимся интервалом. К нему не приходит ни одного ответа, и после 4-го пакета пишет "Извини, чувак, не склалось. Работать не буду." Однако, дальше траффик от него начинает форвардиться.
Посмотрев логи обнаружил, что в них сыплются примерно такие сообщения:
br0: port 2(eth0) entering listening state
br0: port 2(eth0) entering learning state
br0: topology change detected, propagating
br0: topology change detected, propagating
и так примерно 30 секунд. После этих 30 секунд, траффик начинает нормально ходить и все ок. А в первые 30 секунд бридж тупит и не пересылает пакеты. Клиент же, успевает послать все свои 4 запроса как раз в эти 30 секунд, и поэтому ничего не видит.
Пробовал делать команду brctl setfd br0 2 чтобы уменьшить forward delay. Теперь бридж тупит не 30 секунд, а всего 4. Первый DHCPOFFER при этом по-прежнему игнорируется, зато второй уже проходит и клиент получает адрес. Однако дальше бридж опять почему-то тупит, часть пакетов теряется и ничего не работает.
Вопрос: как отрубить этот противоестественный интеллект с learning state, topology change detected итп. Необходимо, чтобы бридж просто пересылал в eth0, все что пришло в eth1, и пересылал в eth1, все что пришло в eth0. Без каких-либо попыток что-то подрюхать.
Вопрос: как отрубить этот противоестественный интеллект с learning state, topology change detected итп. Необходимо, чтобы бридж просто пересылал в eth0, все что пришло в eth1, и пересылал в eth1, все что пришло в eth0. Без каких-либо попыток что-то подрюхать.Круто! Этож работает как настоящий умный бридж. Это все линуксы так, или только твой?
ЗЫ, чтобы отключить STP там же в самом начале написано:
Second, we do not need the STP (Spanning Tree Protocol). I.e. we do only have one single router, so a loop is highly improbable. We may then deactivate this feature. (Results in less polluted networking environment, too):
bridge:~> brctl stp br0 off
Только не очень работает это отключение.
Только не очень работает это отключение.Неужто глюкавый линукс?
Можно ли там замутить RSTP попробовать, если такое поддерживается линуксовым бриджом, тогда должен порт сразу в состояние forwarding перейти
RSTP нет
ну вон тот forward delay в 0 выставить
Однако, наблюдаются проблемы. Через eth1 подключена сеть, где есть DHCP-сервер. Через eth0 — ноутбук. Надо сделать бридж между eth1 и eth0. Если ноутбук подключить непосредственно к кабелю, который идет в eth1 (без бриджа то он нормально получает адрес от DHCP сервера.
Ну а кабель там какой между Линукс-бриджом и ноутом? Хотя не, раз иногда работает.
Какой-то глюк, ХЗ
Вообще, поставь другую сетевуху вместо e0.
С ней посмотри лог.
С ней посмотри лог.
Are there plans for RSTP (802.1w) support?
Yes, work is being done to integrate RSTP support in a future 2.6 release. The code was done for a version of 2.4 and needs to be cleaned up, tested and updated.
from http://linux-net.osdl.org/index.php/Bridge#Are_there_plans_f...
в общем как тебе уже правильно советовали, нужно просто включить бридж без STP
brctl stp <bridge> <state>
brctl stp <bridge> <state>
> bridge:~> brctl stp br0 offИ так уже STP отключено, не помогает Надо еще что-то отключать...1.
может все-таки есть что-то нехорошее в iptables ?
2.
не получается каким-нибудь чудом кольцо ?
3.
ведь с STP тоже должно работать, если на ноубуке сказать ipconfig /renew после того как на бридже отработает STP.
> http://linux-net.osdl.org/index.php/Bridge#Are_there_plans_f...
Спасибо за ссылку, там много полезной информации. В частности, описан косяк про 30-секундную задержку с DHCP. Не знал что forwarding delay может быть 0.
Сегодня попробую c delay 0 и сообщу результаты.
Спасибо за ссылку, там много полезной информации. В частности, описан косяк про 30-секундную задержку с DHCP. Не знал что forwarding delay может быть 0.
Сегодня попробую c delay 0 и сообщу результаты.
Оставить комментарий
Landstreicher
Пытаюсь настроить бридж на базе Linux 2.6.18. Делаю в соответствиие с этой докой.Однако, наблюдаются проблемы. Через eth1 подключена сеть, где есть DHCP-сервер. Через eth0 — ноутбук. Надо сделать бридж между eth1 и eth0. Если ноутбук подключить непосредственно к кабелю, который идет в eth1 (без бриджа то он нормально получает адрес от DHCP сервера. Если же делать через бридж, то dhclient на ноутбуке показывает только DHCPDISCOVER и ни одного DHCPOFFER.
tcpdump на бридже показывает наличие ответа DHCPOFFER от сервера через eth1 и его посылку в eth0. Однако, tcpdump на ноутбуке не видит этих DHCPOFFER.
Что может быть не так? Все файрволлы везде отключены.
Есть ли какие-то подводные камни при настройке бриджа.