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

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.

 

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


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

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

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

 

7.2-RELEASE-p5

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


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

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

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

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


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

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

 

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


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

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

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


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

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

 

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

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

 

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

 

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


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

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

 

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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

 

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

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


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

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

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


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

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

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


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

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

 

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

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


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

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

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

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

 

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

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


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

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

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

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

 

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

 

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

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


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

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

 

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

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

 

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

 

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

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


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

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

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


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

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

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

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


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

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

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

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

 

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

 

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

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

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

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

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


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

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

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


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

Join the conversation

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

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

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

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

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

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

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