Jump to content
Калькуляторы

ipfw глюк

ОС 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.

 

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

 

Share this post


Link to post
Share on other sites
Обновится до 7.3, для начала.
Совет из серии тех. поддержки длинк :-)

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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 by umike

Share this post


Link to post
Share on other sites
Заметили проблему когда под правило

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. Насколько я вижу, проблема возникает при массовом добавлении-удалении в таблицу, при наличии трафика по правилу, использующему таблицу .

Share this post


Link to post
Share on other sites
Совет из серии тех. поддержки длинк :-)
А мне кажется это совет из другой серии. Там еще такие варианты есть: погугли/читай маны/пересобери ядро и т.д. :)

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

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

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

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

 

 

Share this post


Link to post
Share on other sites
Остается только проблема с невозможностью удалить записи. Это только ребутом.

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

(kldunload ipfw, kldload ipfw)

Share this post


Link to post
Share on other sites
Остается только проблема с невозможностью удалить записи. Это только ребутом.

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

(kldunload ipfw, kldload ipfw)

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

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

 

Share this post


Link to post
Share on other sites
Остается только проблема с невозможностью удалить записи. Это только ребутом.

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

(kldunload ipfw, kldload ipfw)

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

 

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

Share this post


Link to post
Share on other sites
Обновится до 7.3, для начала.

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

 

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

ipfw disable firewall

ipfw enable firewall

 

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

 

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

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

Share this post


Link to post
Share on other sites
Помог "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.

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

Share this post


Link to post
Share on other sites
pf запускается позже, для этого в заголовок /etc/rc.d/ipfw вставлена строка

# BEFORE: pf

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

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

 

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

Share this post


Link to post
Share on other sites
Пакет всё равно проходит ipf->pf->ipfw и никак иначе.
Не поделитесь пруфлинком на такое поведение восьмёрки?

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

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

Share this post


Link to post
Share on other sites
Раньше это было только при статической компоновке модулей в ядро:

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

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

 

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

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

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this