doubtpoint Опубликовано 12 сентября, 2010 · Жалоба ОС 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. Кто что думает? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 12 сентября, 2010 · Жалоба Обновится до 7.3, для начала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 12 сентября, 2010 · Жалоба Обновится до 7.3, для начала.Совет из серии тех. поддержки длинк :-) Попробуем, только очень не хочется перезагружать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 12 сентября, 2010 · Жалоба Совет из серии тех. поддержки длинк :-) А мне кажется это совет из другой серии. Там еще такие варианты есть: погугли/читай маны/пересобери ядро и т.д. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
umike Опубликовано 13 сентября, 2010 (изменено) · Жалоба 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 с таблицами Изменено 13 сентября, 2010 пользователем umike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 13 сентября, 2010 · Жалоба Заметили проблему когда под правило 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. Насколько я вижу, проблема возникает при массовом добавлении-удалении в таблицу, при наличии трафика по правилу, использующему таблицу . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 13 сентября, 2010 · Жалоба Совет из серии тех. поддержки длинк :-)А мне кажется это совет из другой серии. Там еще такие варианты есть: погугли/читай маны/пересобери ядро и т.д. :) Была такая чухня на 7.2-p4 Вылечилось обновлением до 7.3-Stable, майский снапшот, больше не обновлял. Клиенты цепляются по PPPoE, BW определяется добавлением адреса в соответствующую таблицу, т.е. добавление/удаление происходит по тыще раз в день. Пересборки ядра не достаточно, читаем /usr/src/Makefile Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 сентября, 2010 · Жалоба Остается только проблема с невозможностью удалить записи. Это только ребутом. А пробовали грузить ipfw модулем и в случае проблем перезагружать модуль? (kldunload ipfw, kldload ipfw) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 13 сентября, 2010 · Жалоба Остается только проблема с невозможностью удалить записи. Это только ребутом. А пробовали грузить ipfw модулем и в случае проблем перезагружать модуль? (kldunload ipfw, kldload ipfw) Можно ещё попробовать: sysctl -w net.inet.ip.fw.enable=0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 14 сентября, 2010 · Жалоба Остается только проблема с невозможностью удалить записи. Это только ребутом. А пробовали грузить ipfw модулем и в случае проблем перезагружать модуль? (kldunload ipfw, kldload ipfw) В моем случае - проще ребутнуть. Вся маршрутизация задублирована, пользователи даже не заметят. Наверное еще можно попробовать перед изменением таблиц, если не слишком часто, вставить skipto перед местом, где таблица пользуется, после изменения выкинуть. Ну поработают они долю секунды на полной скорости., без шейпа... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
doubtpoint Опубликовано 14 сентября, 2010 · Жалоба Обновится до 7.3, для начала. Вообще обновился, перезагрузился. Пока после flush список пустой. Но не понятно, когда в следующий раз абонент получит не свой тариф. Причем как писал выше про это можно и не узнать т.к. проблемный ip адрес отсутствует в таблице и ни когда в нее не добавлялся. Наверное еще можно попробовать перед изменением таблиц, если не слишком часто, вставить skipto перед местом, где таблица пользуется, после изменения выкинуть. Ну поработают они долю секунды на полной скорости., без шейпа...Не поможет - в моем случае обновление идет даже между строк:ipfw disable firewall ipfw enable firewall Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
st_re Опубликовано 14 сентября, 2010 · Жалоба Тогда ой. Это было теоретическое предположение, что проблема в локах. Насчет "не узнать" Я мониторю шейпы скриптом, когда оттуда вытряхивается трафик, который отсутствует в биллинге для этого шейпа, шлю себе мыло. (нужно еще проверять момент смены тарифов, я пока забил, это одноразово, если сменилось между проверками, то в первой проверке оно наситает трафик, а потом не будет, а если трафик пойдет с левой записью, то он будет там постоянно.) Обратной ситуации пока не детектировали (чтобы в таблице есть, а в шейп не попадает.) Это будет хуже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andriko Опубликовано 14 сентября, 2010 · Жалоба тож было подобное на 7.2, на 7.3 в тойже конфигурации вылечилось... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 1 октября, 2010 · Жалоба На днях словил такой эффект на 8.1rc1 - ipfw в наглую игнорирует элементы в таблице. Счётчики на правиле "count ip from all to table(100)" не меняются, хотя элементы в таблице есть (можно посмотреть, удалить, добавить обратно) и трафик, судя по trafshow, на них идёт. Помог "ipfw table 1 flush" и повторное заполнение. Загрузка процессора и сетевых интерфейсов низкая, клиентов на этом шлюзе пока мало, трафик небольшой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 26 ноября, 2010 · Жалоба Помог "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. Что ещё имеет смысл проверить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 26 ноября, 2010 · Жалоба pf запускается позже, для этого в заголовок /etc/rc.d/ipfw вставлена строка# BEFORE: pf А это по барабану. Пакет всё равно проходит ipf->pf->ipfw и никак иначе. Вот и не хочу пока переходить на 8-ку, тем более что и 7.4 не за горами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 26 ноября, 2010 · Жалоба Пакет всё равно проходит ipf->pf->ipfw и никак иначе.Не поделитесь пруфлинком на такое поведение восьмёрки?Раньше это было только при статической компоновке модулей в ядро: http://paix.org.ua/freebsd/fwpackets.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 26 ноября, 2010 · Жалоба Раньше это было только при статической компоновке модулей в ядро:http://paix.org.ua/freebsd/fwpackets.html Из предыдущего поста: NAT делается через pf. В ядро вкомпилены и ipfw, и pf. Порядок прохождения будет меняться ТОЛЬКО если ipf, pf и ipfw грузить в нужной последовательности МОДУЛЯМИ. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...