ipfw table два одинаковых ip в таблице

[versen]

Добрый день!

Кто-нибудь может объяснить почему так: (Как может в одной таблице появляться два одинаковых 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.

 

[zlobar]

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

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

 

7.2-RELEASE-p5

[versen]

Плохо то, что когда такое случается, то под правило, где эта таблица, попадает трафик хостов, кот. вообще не значатся в 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 February 2, 2010 by versen

[zlobar]

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

Да, именно такая беда.

 

[st_re]

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

[versen]

Соответсвтено сбацал пустую трубу и завернул туда все оставшееся.

Это тоже сделано, но не помогает.

 

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

У меня попадаются не IP, а целые сети.

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

 

У меня уже давно есть скрипт, проверяющий сей косяк.

А что именно он делает? Не поделишься?

 

[st_re]

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

 

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

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

[Slad]

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

[produmnet]

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

[Hawk128]

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

[ruri]

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

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

 

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 недели) не замечено проблем. Вот думаем - обновляться или пока подождать? Может проблемы были связаны именно с одновременными переключениями...

[st_re]

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

[bird_of_Luck]

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

[produmnet]

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

 

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

[t0ly]

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

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

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

 

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

[vop]

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

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

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

 

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

 

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

[bird_of_Luck]

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

 

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

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

 

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

 

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

[st_re]

У меня проблема была на 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.х, а не по факту, что нашли и починили :)

[bird_of_Luck]

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

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

[t0ly]

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

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

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

 

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

 

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

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

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

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

[bird_of_Luck]

Ага. То есть все-таки ipfw table swap номер номер - актуально?