Алексей Андриянов

# iptables -I OUTPUT -o eth0 -m state --state NEW -j LOG С роутера не должно устанавливаться много соединений во внешний мир, легко будет засечь.

Может просто не может создать запись в conntrack-таблице? Что в syslog от kernel ?

http://racktables.org

Наверное, человек ожидал, что фича будет работать и без установленного линка, например, покажет, где обрыв. Нет, она работает, только когда на порту link up.

еще tail /var/log/messages хорошо бы. Может, там conntrack table full. и ethtool -k eth0 ethtool -k eth1

Посмотрите Racktables http://racktables.org Оно не предназначено для складского учета, но с задачей "сколько осталось, а сколько и куда установлено" справится. Зато позволяет вести учет многих аспектов сети оператора связи.

ядерный модуль pktgen в Linux.

У меня был нехороший опыт с xen: http://forum.nag.ru/forum/index.php?showtopic=52824 Думаю, что проблема в том, что каждый пакет, приходящий на хост-машину, вызывает его обработку, занесение в сonntrack, бриджинг в виртуальную машину, а там все эти операции выполняются заново.

Например, 3627G и multicast нормально маршрутизирует. Что не работает у вас и на каких коммутаторах?

Раз socket buffer overrun, речь идет не о транзитных пакетах, а на это конкретное устройство.

Поставьте irqbalance, или напишите скрипт, пишущий при загрузке битовую маску нужного ядра в /proc/irq/xxx/smp_affinity

А несколько интерфейсов в сторону клиентов или в сторону интернета? Если я правильно понял, и в сторону клиентов, то зачем там вообще объединение трафика на одном интерфейсе - повесьте по шейперу на всех клиентских интерфейсах и все. Локалку не ограничивать можно одним правилом на шейпере, для этого тем более не нужен ifb.

NETMAP не требует трансляции именно 1:1. Зато он строго регламентирует, в какой именно IP из пула будет транслирован src-адрес клиента. То, что вам нужно.

в крон задача поллера добавлена? Если да, смотреть логи крона. Если нет, добавить

Спасибо, только.... Это выглядит нелогично. Тогда бы небыло никакого смысла строить иерархическую структуру, если родительские установки не ограничивают подчиненные. Вы уверены, что именно в этом причина? Если иначе сформулировать, то попадание текущей полосы класса в указанный rate - это сигнал для HTB к пропуску этого трафика, и выше по иерархии классов он при этом не движется. Поскольку у вас rate=ceil, то трафик класса всегда попадает в rate, и никакие rate/ceil указаные в родительских классах уже ничего не значат. Ставьте у всех юзеров rate = 1bit/s, так они будут получать излишек полосы в равных пропорциях и сумма rate точно не превысит rate родительского класса.

Я прекрасно понимаю, что крупняк друг на друга ACL не вешает, да и вообще, если у клиента собственное адресное пространство, ACL на его порту скорее всего не будет. Но хомяки с завирусованными компами в своей массе уже не смогут участвовать в такой атаке. В этом и сложность, но, конечно, все возможно.

Сложность таких атак в том, что IP source spoofing хомячкам недоступен, ни один провайдер такого не допустит.

1 c 3 жестко скрути, 2 и 6 подай на геркон

Как это - обе пары через 1 геркон или два геркона? Мы у себя на DES-3526 делали, одна пара всегда закорочена, вторая - через геркон. На C2950, к примеру, это не работает, там одна пара должна быть всегда разомкнута (забыл какая), вторая - через геркон.

Какая ему разница, сколько приемников в квартире? Он все равно рассылает мультикаст на все порты, не поддерживает IGMP Snooping поэтому и понятия не имеет, где приемник.

А когда уже RIPE начнет отбирать ресурсы? Какой у них сегодня крайний срок?

Да я на самом деле деталей не знаю, т.к. ISG и Radius у себя на сети не использую, скорость ограничиваю через tc, а трафик считаю через netflow. Просто мне очень понравилась идея ISG на Linux, прикидывал, как можно ее прикрутить к своей сети, вот и всплыл этот вопрос про несколько IP. Спасибо большое за участие, но мне эта фича пока не нужна. Думал, может кому-то пригодится. Но похоже реализовать ее довольно просто, так что если соберусь ставить, то или сам допишу, или вернемся к этому разговору :) Умник, то что вы делаете - это круто. Так держать!

Думаю проще всего будет, если радиус-сервер в access-accept будет передавать полный список IP, для которых действительна эта сессия. lISG тогда будет сопоставлять эту сессию с пакетами на/с любого из указанных IP, и все будет работать по-старому. Тогда радиус-сессия будет всего одна, не нужно будет вводить понятие подчиненных сессий.

А планируется ли добавить возможность одной сессии на несколько IP, для случая, когда у пользователя несколько адресов? Чтобы был общий accounting и policer.

По cron-у выбираешь из БД биллинга для каждого пользователя трафик за текущий день. Если превышает порог по его тарифу, добавляешь ему в шейпер понижающее правило до начала следующего дня.