Добрый день, коллеги.

Столкнулся со странной проблемой со старым, добрым ipfw, прошу подключить коллективный разум.

Входные параметры:
# uname -a
FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sun Oct 25 14:52:29 KRAT 2012     root@firewall :/sys/amd64/compile/bgp_w_ipfw amd64

# kldstat
Id Refs Address            Size     Name
1   13 0xffffffff80200000 11eaf08  kernel
2    1 0xffffffff81612000 2a120    pf.ko
3    5 0xffffffff8163d000 8dfa     netgraph.ko
4    1 0xffffffff81646000 5833     ng_netflow.ko
5    1 0xffffffff8164c000 2041     ng_ksocket.ko
6    1 0xffffffff8164f000 1561     ng_ether.ko
7    1 0xffffffff81651000 1b8d     ng_socket.ko

Ядро собрано с поддержкой ipfw, dummynet, пара девайсов типа device lagg.

Раз в минуту прилетает с крона команда:
/sbin/ipfw -qn /scr/deny.ipfw && /sbin/ipfw table 1 flush && /sbin/ipfw -q /scr/deny.ipfw

как видно - проверка синтаксиса, очистка таблицы, добавление адресов с файлика.

#ipfw show 3
00003        12963         149159 deny ip from table(1) to any via em5
00003        90985        5786356 deny ip from any to table(1) via em5

при очередном проходе скрипта по перечитке адресов таблицы "залип" один адрес:
# ipfw table 1 list
123.123.123.105/32 0

# ipfw table 1 delete 123.123.123.105
ipfw: setsockopt(IP_FW_TABLE_DEL): No such process

# ipfw table 1 delete 123.123.123.105/32 0
ipfw: setsockopt(IP_FW_TABLE_DEL): No such process

# ipfw table 1 flush
нормально отрабатывается, трет все но именно этот адрес остается.

# ipfw table 1 add 123.123.123.105 - добавляется адрес

получается вот что:
# ipfw table 1 list
123.123.123.105/32 0
123.123.123.105/32 0  (вторая строка не ошибка)

потом делаем ipfw table 1 delete 123.123.123.105 - один адрес пропадает, второй на месте :)

Как бэ хрен с ним, но проблема проявилась в том, что вся сетка 123.123.123.0/24 стала попадать под это правило. Причем маршрутизатор знает её в составе сети с бОльшей маской - /21, а адреса с этой сети но с диапазона отличного от 123.123.123.0/24 ходят нормально.

На лицо странный баг фаервола. Тут собственно вопрос - как грохнуть этот адрес, как убить таблицу, чё вапще делать? :) Ребут не предлагать, флуш фаервола тоже.

Испробовали с коллегами всякие прямолинейные комбинации типа ipfw delete table 1, ipfw table 1 delete ip, ipfw table 1 flush итд - ничего не помогло.

Прошу помощи :)

• ipfw table 1 delete 192.168.0.1/32,кегна, 17:03 , 03-Ноя-15
  • ipfw table 1 delete 192.168.0.1/32,2ihi, 06:26 , 05-Ноя-15
    • ipfw table 1 delete 192.168.0.1/32,butcher, 18:47 , 06-Ноя-15
    • ipfw table 1 delete 192.168.0.1/32,кегна, 11:27 , 07-Ноя-15

>[оверквотинг удален]
> сетка 123.123.123.0/24 стала попадать под это правило. Причем маршрутизатор знает её
> в составе сети с бОльшей маской - /21, а адреса с
> этой сети но с диапазона отличного от 123.123.123.0/24 ходят нормально.
> На лицо странный баг фаервола. Тут собственно вопрос - как грохнуть этот
> адрес, как убить таблицу, чё вапще делать? :) Ребут не предлагать,
> флуш фаервола тоже.
> Испробовали с коллегами всякие прямолинейные комбинации типа ipfw delete table 1, ipfw
> table 1 delete ip, ipfw table 1 flush итд - ничего
> не помогло.
> Прошу помощи :)

старая бага с таблицами... по-моему решений так и нет... странно что проявляется на 9.0... вроде бы было пофикшено в 8-ых ветках, но видимо тут либо обновлять ядро и мир до текущего состояния... либо ребут )

А что является причиной, не помните?

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

Задача стоит в том чтоб плавно мигрировать на новое железо, удалив из цепочек 4.7, повешав задачи на 9ку и заменить 9ку на 10.2.. Как думаете, в 10.2 проблема может присутствовать? Вроде как фаервол подвергался переработкам где-то между 9 и 10.2...?

И может есть идеи как повторить глюк?

Да, асинхронных правок таблиц нет.

>[оверквотинг удален]
> На всякий случай между флушем и добавлением вписал паузу, такой костыль, помнится,
> помог с багом удалений пайпов в которых могли находиться пакеты, но
> это еще было на фре 4.7 (к слову эта фря еще
> в работе :) ), на ней так же активно используются таблицы,
> даже более чем на "проблемной" 9ке, но залипаний нет, аптаймы уж
> годами исчисляются...
> Задача стоит в том чтоб плавно мигрировать на новое железо, удалив из
> цепочек 4.7, повешав задачи на 9ку и заменить 9ку на 10.2..
> Как думаете, в 10.2 проблема может присутствовать? Вроде как фаервол подвергался
> переработкам где-то между 9 и 10.2...?

Эта проблема была исправлена уже после выхода 9.0. Так что вам нужно обновляться, для того чтобы не сталкиваться с ней.
https://svnweb.freebsd.org/base?view=revision&revision=257389

>[оверквотинг удален]
> это еще было на фре 4.7 (к слову эта фря еще
> в работе :) ), на ней так же активно используются таблицы,
> даже более чем на "проблемной" 9ке, но залипаний нет, аптаймы уж
> годами исчисляются...
> Задача стоит в том чтоб плавно мигрировать на новое железо, удалив из
> цепочек 4.7, повешав задачи на 9ку и заменить 9ку на 10.2..
> Как думаете, в 10.2 проблема может присутствовать? Вроде как фаервол подвергался
> переработкам где-то между 9 и 10.2...?
> И может есть идеи как повторить глюк?
> Да, асинхронных правок таблиц нет.

Обновите ядро и мир до 9.0-RELENG, по-моему как раз правили этот баг после 9.0-RELEASE.