[doubtpoint]

ОС FreeBSD 7.2-STABLE

 

 

 

rb# ipfw table 50 flush

rb# ipfw table 50 list

...

172.17.4.102/32 28

172.17.14.222/32 28

172.17.15.19/32 28

...

Выдает около 30 строчек после flush!!!

 

rb# ipfw table 50 delete 172.17.14.222/32

ipfw: setsockopt(IP_FW_TABLE_DEL): No such process

 

 

rb# ipfw table 50 add 172.17.14.222/32 28

rb# ipfw table 50 list

...

172.17.4.102/32 28

172.17.14.222/32 28

172.17.14.222/32 28

172.17.15.19/32 28

...

 

 

Команды выполнялись последовательно как приведено в сообщении. Изначально в таблице было около 5000 адресов. Заметили проблему когда под правило

12000 27056078 20077774294 pipe tablearg ip from any to table(50) out

стал подпадать IP отсутствующий в таблице 50 !!!(после flush его по прежнему в таблице нет, но трафик все равно идет в pipe). Можно добавить этот ip в таблицу 50 и тогда трафик пойдет в другую pipe в правильном соответствии с tablearg.

 

Кто что думает?

 

[Deac]

Обновится до 7.3, для начала.

[doubtpoint]

Обновится до 7.3, для начала.

Совет из серии тех. поддержки длинк :-)

 

Попробуем, только очень не хочется перезагружать...

[xcme]

Совет из серии тех. поддержки длинк :-)

А мне кажется это совет из другой серии. Там еще такие варианты есть: погугли/читай маны/пересобери ядро и т.д. :)

[umike]

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127209

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/135476

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144269

 

в общем-то так

короче проявляется такое на большой нагрузке и при частых манипуляциях add/del с таблицами

Edited September 13, 2010 by umike

[st_re]

Заметили проблему когда под правило

12000 pipe tablearg ip from any to table(50) out

стал подпадать IP отсутствующий в таблице 50 !!!(после flush его по прежнему в таблице нет, но трафик все равно идет в pipe). Можно добавить этот ip в таблицу 50 и тогда трафик пойдет в другую pipe в правильном соответствии с tablearg.

 

Кто что думает?

 

Про репорты уже отписали.

 

Я для себя сделал q&d решение, добавил пайп пустой, без ограничений и вписал всех, кого шейпить не надо в эту табличку с номером того dummy пайпа. Это на тему, что в таблице его нету, а в пайп попадает. Вроде как попадания не в тот пайп, при нализия IP в таблице не замечено. Остается только проблема с невозможностью удалить записи. Это только ребутом. на 6.х не встречалось (как минимум у меня ;) на 8 я такого функционала пока не держу, где бы проблемы могла вылезти. проблема есть с 7.0 по последние 7.3-stable. Насколько я вижу, проблема возникает при массовом добавлении-удалении в таблицу, при наличии трафика по правилу, использующему таблицу .

[Deac]

Совет из серии тех. поддержки длинк :-)

А мне кажется это совет из другой серии. Там еще такие варианты есть: погугли/читай маны/пересобери ядро и т.д. :)

Была такая чухня на 7.2-p4

Вылечилось обновлением до 7.3-Stable, майский снапшот, больше не обновлял.

Клиенты цепляются по PPPoE, BW определяется добавлением адреса в соответствующую таблицу, т.е. добавление/удаление происходит по тыще раз в день.

Пересборки ядра не достаточно, читаем /usr/src/Makefile

 

 

[Ivan_83]

Остается только проблема с невозможностью удалить записи. Это только ребутом.

А пробовали грузить ipfw модулем и в случае проблем перезагружать модуль?

(kldunload ipfw, kldload ipfw)

[Deac]

Остается только проблема с невозможностью удалить записи. Это только ребутом.

А пробовали грузить ipfw модулем и в случае проблем перезагружать модуль?

(kldunload ipfw, kldload ipfw)

Можно ещё попробовать:

sysctl -w net.inet.ip.fw.enable=0

 

[st_re]

Остается только проблема с невозможностью удалить записи. Это только ребутом.

А пробовали грузить ipfw модулем и в случае проблем перезагружать модуль?

(kldunload ipfw, kldload ipfw)

В моем случае - проще ребутнуть. Вся маршрутизация задублирована, пользователи даже не заметят.

 

Наверное еще можно попробовать перед изменением таблиц, если не слишком часто, вставить skipto перед местом, где таблица пользуется, после изменения выкинуть. Ну поработают они долю секунды на полной скорости., без шейпа...

[doubtpoint]

Обновится до 7.3, для начала.

Вообще обновился, перезагрузился. Пока после flush список пустой. Но не понятно, когда в следующий раз абонент получит не свой тариф. Причем как писал выше про это можно и не узнать т.к. проблемный ip адрес отсутствует в таблице и ни когда в нее не добавлялся.

 

Наверное еще можно попробовать перед изменением таблиц, если не слишком часто, вставить skipto перед местом, где таблица пользуется, после изменения выкинуть. Ну поработают они долю секунды на полной скорости., без шейпа...

Не поможет - в моем случае обновление идет даже между строк:

ipfw disable firewall

ipfw enable firewall

 

[st_re]

Тогда ой. Это было теоретическое предположение, что проблема в локах.

 

Насчет "не узнать" Я мониторю шейпы скриптом, когда оттуда вытряхивается трафик, который отсутствует в биллинге для этого шейпа, шлю себе мыло. (нужно еще проверять момент смены тарифов, я пока забил, это одноразово, если сменилось между проверками, то в первой проверке оно наситает трафик, а потом не будет, а если трафик пойдет с левой записью, то он будет там постоянно.) Обратной ситуации пока не детектировали (чтобы в таблице есть, а в шейп не попадает.) Это будет хуже.

[andriko]

тож было подобное на 7.2, на 7.3 в тойже конфигурации вылечилось...

[Ilya Evseev]

На днях словил такой эффект на 8.1rc1 - ipfw в наглую игнорирует элементы в таблице.

 

Счётчики на правиле "count ip from all to table(100)" не меняются,

хотя элементы в таблице есть (можно посмотреть, удалить, добавить обратно)

и трафик, судя по trafshow, на них идёт.

 

Помог "ipfw table 1 flush" и повторное заполнение.

Загрузка процессора и сетевых интерфейсов низкая, клиентов на этом шлюзе пока мало, трафик небольшой.

[Ilya Evseev]

Помог "ipfw table 1 flush" и повторное заполнение.

После перезагрузки снова повторилась та же проблема - ipfw игнорирует адреса в таблице,

только после flush и повторного заполнения теперь ничего не меняется.

 

Причём

"ipfw add 100 count all from any to table(1) in" не работает,

"ipfw add 100 count all from any to table(1) out" - работает.

 

Естественно предположить, что виновен NAT,

т.е. когда срабатывает правило "in", оно видит не IP-адреса из таблицы, а внешний IP шлюза.

NAT делается через pf. В ядро вкомпилены и ipfw, и pf.

pf запускается позже, для этого в заголовок /etc/rc.d/ipfw вставлена строка

# BEFORE: pf

Кроме того, "/etc/rc.d/pf restart" не помогает.

 

Проблема обнаружилась на единственном сервере из многих с одинаковыми настройками.

Единственное отличие - на нём FreeBSD 8.1, на остальных 7.x.

 

net.inet.ip.fw.one_pass, естественно, установлен в 0.

Что ещё имеет смысл проверить?

[Deac]

pf запускается позже, для этого в заголовок /etc/rc.d/ipfw вставлена строка

# BEFORE: pf

А это по барабану.

Пакет всё равно проходит ipf->pf->ipfw и никак иначе.

 

Вот и не хочу пока переходить на 8-ку, тем более что и 7.4 не за горами.

[Ilya Evseev]

Пакет всё равно проходит ipf->pf->ipfw и никак иначе.

Не поделитесь пруфлинком на такое поведение восьмёрки?

Раньше это было только при статической компоновке модулей в ядро:

http://paix.org.ua/freebsd/fwpackets.html

[Deac]

Раньше это было только при статической компоновке модулей в ядро:

http://paix.org.ua/freebsd/fwpackets.html

Из предыдущего поста:

 

NAT делается через pf. В ядро вкомпилены и ipfw, и pf.

Порядок прохождения будет меняться ТОЛЬКО если ipf, pf и ipfw грузить в нужной последовательности МОДУЛЯМИ.