Перейти к содержимому
Калькуляторы

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.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обновится до 7.3, для начала.
Совет из серии тех. поддержки длинк :-)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 с таблицами

Изменено пользователем umike

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

(kldunload ipfw, kldload ipfw)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

(kldunload ipfw, kldload ipfw)

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

(kldunload ipfw, kldload ipfw)

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

ipfw disable firewall

ipfw enable firewall

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Помог "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.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

# BEFORE: pf

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.