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

ipfw table два одинаковых ip в таблице Два одинаковых ip в таблице. И не удалить.

Добрый день!

Кто-нибудь может объяснить почему так: (Как может в одной таблице появляться два одинаковых ip?)

 

[root@]# ipfw table 5 list| uniq -d
10.0.66.73/32 0
[root@]# ipfw table 5 list | grep 10.0.66.73/32
10.0.66.73/32 0
10.0.66.73/32 0
[root@]# ipfw table 5 delete 10.0.66.73/32
[root@]# ipfw table 5 list | grep 10.0.66.73/32
10.0.66.73/32 0
[root@]# ipfw table 5 delete 10.0.66.73/32
ipfw: setsockopt(IP_FW_TABLE_DEL): No such process
[root@]# ipfw table 5 list | wc -l  
   4627

 

Удалить это можно только с помощью "ipfw table 5 flush"

 

Если добавить два одинаковых ip, то ругается:

[root@]# ipfw table 5 add 10.0.32.251/32
[root@]# ipfw table 5 add 10.0.32.251/32
ipfw: setsockopt(IP_FW_TABLE_ADD): File exists

 

На машине

7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #1:

NAT с помощью PF

Трафик режется с помощью IPFW.

В table 5 ip добавляет utm5.

 

Share this post


Link to post
Share on other sites

У нас такая же беда на одной машинке иногда случается, вот только "двойные" айпи не удаляются.

Как это получается и как бороться не знаем. :(

 

7.2-RELEASE-p5

Share this post


Link to post
Share on other sites

Плохо то, что когда такое случается, то под правило, где эта таблица, попадает трафик хостов, кот. вообще не значатся в table list.

После того, как делаю

ipfw table 5 list | awk '{print "/sbin/ipfw table 5 add "$1}' > table5.sh
ipfw table 5 flush
./table5.sh

какое-то время (день-два) все нормально.

 

Интересно, есть ли такая проблема на более новых версиях (7.3, 8.0) ?

Edited by versen

Share this post


Link to post
Share on other sites
Плохо то, что когда такое случается, то под правило, где эта таблица, попадает трафик хостов, кот. вообще не значатся в table list.
Да, именно такая беда.

 

Share this post


Link to post
Share on other sites

по моим наблюдениям "то под правило, где эта таблица, попадает трафик хостов, кот. вообще не значатся в table list" верно даже если такое не случается. двойные IP в таблицах встречались пару раз всего, а вот выгребание трафика из пайпов, которого там быть не должно одно время напрягало. фикса так и не нашел, но обошлось тем, что трафик никогда не попадал в неправильную трубу вместо правильной, он попадал в трубы, если вообще в трубы не должен был попадать. Соответсвтено сбацал пустую трубу и завернул туда все оставшееся.

 

это все

  pipe tablearg ip from any to table(1) xmit em1 out
  pipe tablearg ip from table(2) to any recv em1 in

 

Иногда в пайпах попадались IP, которых вообше небыло и нет в таблицах 1 и 2 от ребуа. Причем трафик упорно прет через трубу, (не единичные проскакивания), что соответственно отражается на счетчиках и на скорости у абонента. те. полная иллюзия, что IP есть в таблице. до ребута не меняется. Добавлять еще раз этот IP руками - не пробовал.

 

При этом направление проверяется четко.

 

Ребут не то чтобы лечит, но (иногда сразу, иногда через пару месяцев) нарисовывается новый набор IP, невидимой тенью присутствующих в таблицах.. У меня уже давно есть скрипт, проверяющий сей косяк. После нарисовки левой трубы, с указанием в таблице всех возможных IP скрипт стал срабатывать только при переезде из трубы в трубу (когда IP между снятиями счетчиков в трубах успел переехать в другуу трубу), что нормально.

 

В других способах применения таблиц подобной аномалии не замечено. только в пайпах (причем, что через tablearg, что просто запхать в пайп всю таблицу). Возможно просто в других местах менее заметен эффект.

 

Повторялось на разных версиях 7.х, вплоть до полгода назад (с тех пор не проверял) иногда чаще, иногда реже. Закономерности не выявлено. на 6.х не встречал.

Share this post


Link to post
Share on other sites
Соответсвтено сбацал пустую трубу и завернул туда все оставшееся.
Это тоже сделано, но не помогает.

 

Иногда в пайпах попадались IP, которых вообше небыло и нет в таблицах 1 и 2 от ребуа. Причем трафик упорно прет через трубу, (не единичные проскакивания), что соответственно отражается на счетчиках и на скорости у абонента. те. полная иллюзия, что IP есть в таблице. до ребута не меняется.
У меня попадаются не IP, а целые сети.

Что значит "ребут"? ipfw table flush? В моем случае этого хватает.

 

У меня уже давно есть скрипт, проверяющий сей косяк.
А что именно он делает? Не поделишься?

 

Share this post


Link to post
Share on other sites

В том случае ребут и быстрее и проще. там карпом балансировка на 2 машины. Одну ребутнуть - никто и не заметит.

 

А что делает ? скрипт. ipfw pipe XXX show

парсит че там есть, ищет IP у которых счетчик != предыдущему (т.е. трафик есть). Смотрит по файлу из биллинга, где оно должно быть. Если не тут, то кричит айаййай с диагоностикой (кто, где есть , где должно быть) Запоминает счетчики и отваливает. 2 экрана на перле. больше кода на првоначальный разбор своих конфигов, чем на это.

Share this post


Link to post
Share on other sites

Был PR похожий, надо искать. Полечилось обновлением.

Share this post


Link to post
Share on other sites

Также столкнулся с проблемой 2 ip в таблице. Никто еще не знает как побороть? 8.2-RELEASE-p6

Share this post


Link to post
Share on other sites

Для начала обновиться до stable.

Share this post


Link to post
Share on other sites

Есть примерно такая-же бяда.

Есть три машины под управлением одного биллинга. Он формирует таблицы.

 

1) FreeBSD 8.2 - PRERELISE - косяков не замечено. В 24-00 биллинг из таблиц удаляет клиентов с отрицательным балансом и в 01-00 по крону меняется скорость в пайпах...

2) FreeBSD-8.1 - RELESE-p2 - косяков не замечено. В 24-00 биллинг из таблиц удаляет клиентов с отрицательным балансом и в 01-00 по крону меняется скорость в пайпах...

2) FreeBSD-7.2 - RELESE - косяк. В 24-00 биллинг из таблиц удаляет клиентов с отрицательным балансом и в 24-00 по крону меняется скорость в пайпах... После этих изменений клиент действительно удаляется из таблицы, но проходит мимо пайпов и получает максимальную скорость.

Пока сделали смену скорости в 01-00. Наблюдаем. Пока (2 недели) не замечено проблем. Вот думаем - обновляться или пока подождать? Может проблемы были связаны именно с одновременными переключениями...

Share this post


Link to post
Share on other sites

в ветке 7.х были проблемы с таблицами и пайпами. Есть PR, помоему закрытый, по причине что в 8х не повторялось, а не потому что поправили.

Share this post


Link to post
Share on other sites

На восьмерке, кажется, это тоже встречается, но на порядки реже (жаловался один человек в ML). Скорее всего у вас при обновлении на 8 это пропадет

Share this post


Link to post
Share on other sites

Система Freebsd FreeBSD 8.2-RELEASE-p6 amd64. Проблема сохраняется. Очистка таблиц не помогает, IP остаются в таблице после комманды flash. После перезагрузки некоторое время все нормально....

 

Кто знает как решить проблему и какой патч поставить просьба откликнуться.

Share this post


Link to post
Share on other sites

читал в рассылке что то вроди - "не пользоватся командой flush"

т е вместо flush делать что то вроди

ipfw table 10 list | awk '{print "table 10 delete "$1}'|/sbin/ipfw /dev/stdin

 

сам flush никогда не пользуюсь, все время из билинга удаляю и добавляю только нужное

Share this post


Link to post
Share on other sites

читал в рассылке что то вроди - "не пользоватся командой flush"

т е вместо flush делать что то вроди

ipfw table 10 list | awk '{print "table 10 delete "$1}'|/sbin/ipfw /dev/stdin

 

сам flush никогда не пользуюсь, все время из билинга удаляю и добавляю только нужное

 

В линуксном ipset есть замечательная фишка - swap. В принципе можно сделать что-то аналогичное и тут. Т.е. просто создать новую табличку, заполнить ее измененым списком, а потом поменять правило под новую табличку. Так и менять два номера туда-сюда.

Share this post


Link to post
Share on other sites

Система Freebsd FreeBSD 8.2-RELEASE-p6 amd64. Проблема сохраняется. Очистка таблиц не помогает, IP остаются в таблице после комманды flash. После перезагрузки некоторое время все нормально....

 

Кто знает как решить проблему и какой патч поставить просьба откликнуться.

Попробуйте обновиться до -STABLE, есть некоторая уверенность, что проблема исчезнет. Если не исчезнет - пишите сюда, или мне на melifaro@freebsd.org - попробуем зачинить. Я давно за ней гоняюсь :)

 

Если возможности обновиться нет - действительно, тогда или не пользоваться flush, и делать точечные add/delete, или действительно придумывать схему с ifpw swap для рулсета, где в правилах меняется только номер таблицы.

 

Ну и да, хочется чуть более точного описания проблемы (можно в приват) с описанием всех вызовов ipfw(8)

Share this post


Link to post
Share on other sites

У меня проблема была на 7.х Флашей не было (если не считать ipfw flush при первом запуске правил фаервола при буте.). Все изменения - считать таблицу, считать из биллинга, привести первое ко второму путем add-delele. И проблема была в 2-х вариантах.

1. (чаще, процентов 85% наверное случаев) IP в таблице нет, а в правилах срабатывает как будто есть.

2. (сильно реже) шз из таблицы не удалялся (возможно он до добавления обрабатывался по варианту 1)

 

часто проблема вылезала после бута (при буте тупо ipfw table X add 1.2.3.4/x много много раз из заранее сгенеренного скрипта.) Трафика до окончания всей конфигурации у меня на машине еще не бывает (ну не считая трафика смой машины, ntp там, в биллинг сходить). Иногда вылезает позже, но сказать, что IP стал срабатывать на 5-й день я не могу, может просто первые 4 дня этот IP не включался. И почти со 100% вероятностью после make installkernel + reboot (т.е. возможно чтото не чистится и таблица получает мусор от прошлой жизни машины) после изменений в ядре почти на автомате уже делал контрольный ребут т.к его все равно придется делать :)

 

у меня на 8.х не повторялось (зачастую машина тупо csup, buildworld/kernel installworld/kernel переводилась с 7 на 8 и _у меня_ проблема уходила, но второй ребут я уже по привычке делал при апгрейде :) ). Была на 7.х написана некая тулза мониторящая вариант 1 по факту наличия трафика в левых местах (т.е. в таблице нет, трафика быть не должно, а он как суслик, есть), на 8 не срабатывала (кроме не обрабатываемых случаев смены тарифа абонентом, когда между проверками он успевал пропасть из таблицы, но в счетчиках наследил. Лениво было обработку делать). На данный момент 9.х с подобной схемой у меня нет вообще.

 

сенд-пр был закрыт по факту неповторения в 8.х, а не по факту, что нашли и починили :)

Share this post


Link to post
Share on other sites

7.x неитнресно, увы, там все совсем другое.

Мне больше интересно, не починилось ли оно после http://svnweb.freebsd.org/base?view=revision&revision=237309 -- дальше там, кажется, остается только в радикс смотреть.

Share this post


Link to post
Share on other sites

читал в рассылке что то вроди - "не пользоватся командой flush"

т е вместо flush делать что то вроди

ipfw table 10 list | awk '{print "table 10 delete "$1}'|/sbin/ipfw /dev/stdin

 

сам flush никогда не пользуюсь, все время из билинга удаляю и добавляю только нужное

 

В линуксном ipset есть замечательная фишка - swap. В принципе можно сделать что-то аналогичное и тут. Т.е. просто создать новую табличку, заполнить ее измененым списком, а потом поменять правило под новую табличку. Так и менять два номера туда-сюда.

очень классно

я тоже об этом думал, даже изучал для этого С

но в результате оказалось что проще написать на bash/perl/php скрипт и вызавать его, т.к. скорость выполнения не критична, а скорость внедрения да.

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