LINUX.ORG.RU
ФорумAdmin

бриджинг & net.ipv4.ip_forward - как оно связано?


0

3

Сделал бридж из трех интерфейсов, и наблюдаю такую хрень:
Если ip_forward выключен, то траффик то вроде как ходит, даже пинги jubmo размеров без фрагментации, а вот iperf подвисает, или выдает какую-то хрень типа 7-10 мегабит.
Но если ip_forward включить, то все начинает бегать на полной скорости.

Это как вообще понять? Я думал что бриджинг работает на уровень ниже роутинга и с ним мало связан.

Ответ на: комментарий от Lego_12239
# ip addr
...
12: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN qlen 30000
    link/ether 00:1b:21:9d:0e:70 brd ff:ff:ff:ff:ff:ff
13: card1_p0.103@card1_p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
    link/ether 00:1b:21:9d:0f:e4 brd ff:ff:ff:ff:ff:ff
14: card1_p1.103@card1_p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
    link/ether 00:1b:21:9d:0f:e5 brd ff:ff:ff:ff:ff:ff
15: card3_p0.103@card3_p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
    link/ether 00:1b:21:9d:0e:70 brd ff:ff:ff:ff:ff:ff
...
# brctl show
...
bridge name     bridge id               STP enabled     interfaces
br1             8000.001b219d0e70       no              card1_p0.103
                                                        card1_p1.103
                                                        card3_p0.103
...

Т.е. я бриджую вланы с трех интерфейсов. Закономерность чёткая - есть ip_forward, iperf-ом получаю 9.8Гбит через бридж между хостами к нему подключенными. Нету его - получаю лажу, описаню в топике.

Ядро 2.6.38.7, сетевухи ixgbe, версия дров последняя.

blind_oracle ★★★★★ ()
Ответ на: комментарий от Lego_12239

iptables вообще отключен в ядре полностью за ненадобностью. Ядро попробую 2.6.39 вскоре я думаю, более ранние пока не охота, ибо через ip_forward проблема-то решается...

blind_oracle ★★★★★ ()
Ответ на: комментарий от Lego_12239
# ls -l /proc/sys/net
total 0
dr-xr-xr-x 0 root root 0 May 31 16:46 core
dr-xr-xr-x 0 root root 0 May 31 16:46 ipv4
dr-xr-xr-x 0 root root 0 May 31 17:21 unix

нэма...

blind_oracle ★★★★★ ()
Ответ на: комментарий от Lego_12239

Да, его уже до 40 версии кажись допатчили.. но с ним проблема - драйвер mpt2sas в нем есть, но вот с моим рейд контроллером (LSI2008 в мамку встроен) оно работать не хочет категорически - пробовал с месяц назад. Девайс определяет, но зависает на инициализации.

Работать начинает то ли с .34, то ли с .35

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Ещё момент. А ты пробовал для теста сделать vlan tag одинаковый? Не уверен, что bridge-utils может разтэгировать и тэгировать трафик налету для этих целей. Да и не нужно это.

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Я к тому, что если на одном из других концов не коммутатор, а unix, то можно будет tcpdump'ом не на vlan'е, а на интерфейсе, на котором он основан, увидеть, что приходят пакеты тэгированные другим vlan'ом и поэтому есть видимость, что нихуа не пашет. А на самом деле мост тупо делает свою работу - копирует ethernet пакеты с одного интерфейса на другой. Это предположение, буду через пару часов на работе - проверю на виртуалках. Не понятно почему всё работает при ip_forward = 1.

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Я лучше проверю на виртуалках, ибо лень флеш еще какойто городить с нужными ядрами-софтом...

blind_oracle ★★★★★ ()
Ответ на: комментарий от Lego_12239

Не совсем понял. Одинаковый влан сделать где? Он и так одинаковый (103) на всех трех бриджованых интерфейсах.

blind_oracle ★★★★★ ()
Ответ на: комментарий от Lego_12239

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Понятно. Т.е. vlan'ы созданы с тэгом, а по ним ходит нетэгированный трафик?

Хочется:

ip -d link show на этой машине

и

ip -d link show на двух других (ESXi где), которые должны между собой общаться через эту машину.

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Траффик то тегированый, но если смотреть влан-субинтерфейс eth0.123 тем же tcpdump к примеру, то на нём-то траффик видится уже не тегированый, правильно?

# ip -d link show
...

12: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UNKNOWN qlen 30000
    link/ether 00:1b:21:9d:0e:70 brd ff:ff:ff:ff:ff:ff
13: card1_p0.103@card1_p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
    link/ether 00:1b:21:9d:0f:e4 brd ff:ff:ff:ff:ff:ff
    vlan id 103 <REORDER_HDR>
14: card1_p1.103@card1_p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
    link/ether 00:1b:21:9d:0f:e5 brd ff:ff:ff:ff:ff:ff
    vlan id 103 <REORDER_HDR>
15: card3_p0.103@card3_p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP
    link/ether 00:1b:21:9d:0e:70 brd ff:ff:ff:ff:ff:ff
    vlan id 103 <REORDER_HDR>
...

Вот меня флаг REORDER_HDR смущает, я его не включал в vconfig, хотя сказано в мане, что «Default is OFF.»

А на гипервизорах всё виртуализовано, и iproute2 там нету в сервисной консоли... можно в виртуалке посмотреть, но это будет не показательно я думаю.

Тем более что между виртуалками на ESXi хостах и бриджом (если на него IP повесить) iperf и без ip_forward показывает нужную производительность.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

На vlan-интерфейсе не тэгированный будет траффик, на интерфейсе, на котором он основан - тэгированный должен сыпаться.

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Ну вот о том и речь, в бридж попадает чистый траффик, и он о вланах ничего знать не должен в общем-то.

1. Пакет приходит
2. Считывается влан метка модулем 8021q
3. Влан-заголовок отрезается
4. Пихается в нужный влан-интерфейс
5. Оттуда в бридж
6. Пункты 1-4 в обратном порядке

как-то так я понимаю...

blind_oracle ★★★★★ ()
Ответ на: комментарий от Lego_12239

tcpdump на одном из vlan-интерфейсов что говорит, когда пинг идёт транзитом?

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Да ща времени нет, мы эту железку пустили в продакшен.
Я запостил баг в багзиллу ядра, там люди говорят что проблема в LRO (Large Receive Offload) и в том, что бридж не отключает этот механизм, если бриджуются вланы, а не физические интерфейсы, и что это пофикшено в 3.0 ядре.

У меня правда LRO отключен еще на стадии компиляции драйвера, так что хрен знает в этом ли дело, но пока проблема решена и ладно :)

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

А можно ссылку на баг?

Жесть, они это не собираются фиксить в стабильных ядрах? Совсем ядроделы офигели :-).

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Никак не связано.

Вообще как-то связано. Забридженные пакеты проходят через цепочку FORWARD в ip(6)tables.

Deleted ()
Ответ на: комментарий от Lego_12239

Ага, но ни по умолчанию установлены. И кстати без них в работе моста *иногда* наблюдаются какие-то странности...

Deleted ()
Ответ на: комментарий от Lego_12239

Вообще, конечно, непонятно нафига так сделали. Вызывать цепочки iptables для пакетов гуляющих через мост, когда есть ebtables для этого... Кто-нибудь, может объяснить?

Lego_12239 ★★ ()
Ответ на: комментарий от Lego_12239

Баг тут: https://bugzilla.kernel.org/show_bug.cgi?id=36602
Ток сайт тупит что-то страшно...

А насчёт иптаблеса, у меня его один хрен нет, как и ебтаблесов.
И ветки /proc/sys/net/bridge тоже нету, так что некуда ему попадать :)
Опять таки не понятно тогда, если в ядре выпилен сам код роутинга, зачем оставлять рубильник net.ipv4.ip_forward ...

Дойдут руки - попробую вообще без LRO всё собрать на стенде, позырить что как.

blind_oracle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.