s.lobanov

ну это снизит вероятность совпадения момент отправки аккаунтинга с моментом падения радиуса.

ISC DHCPD снимает трафик до ebtables/iptables, так что только если в контейнер его помещать и фильтровать на хосте

ну вообще сброс сессии когда нет ответа на аккаунтинг это придумали для того, когда по какой-то причине BRAS не получил PoD когда абонент расторг договор или просто не платит. В некоторых случаях даже не делают отправку PoD-ов, а просто дают абоненту работать с точностью до Acct-Interim-Interval Т.е. пример - bras не получил PoD или некорректно обработал его, радиус/биллинг у себя убил сессию и (если динамические IP выдаются биллингом/радиусом), то в следующий раз другому абоненту может выдастся такой же IP-адрес так что вы там поаккуратнее с несбросом сессии при неответе на аккаунтинг

так тут дело не в канале до УФСБ. Если у вас белые динамические IP и вы хотите пользовать СОРМ вышестоящего оператора, то надо лить аккаунтинг на СОРМ, а не в УФСБ. Нафиг им не сдался ваш аккаунтинг, который прилетит на пульт Относительно NAT, нужно чтобы ваш nat лил netflow v9 nat-трансляции /syslog на СОРМ, чтобы можно было ставить абонента на мониторинг, ну и вообще знать кому же принадлежит трафик. Но опять же это всё с технической точки зрения, с точки зрения денег все эти схемы не выгодны производителям СОРМа и они помогать не будут, а ФСБ лишний гемор с вашими "мудренными схемами" тоже не нужен. Иногда пишут или намекают что УФСБ имеют % с продаж СОРМа, но пусть это останется на совести комментаторов и чекистов. Второй вопрос в плане денег это то, что СОРМирование на вышестоящем операторе далеко не всегда выгодно для того, кто СОРМ предоставляет. Но у крупняка может гореть план продаж по ip-транизиту или просто план продаж по хз какому критерию, а расходы на СОРМ это другая статья и у какого-нибудь "отдела финансвого контроля" крупного РФ-оператора (такие отделы это такие же одноклеточные клоуны как "безопасники") никогда в жизни не хватит мозгов выяснить сколько стоит 1мбит/с, который копируется на СОРМ и сопоставить это с тем, что продается оператору. Просто в какой-то момент при расширении большой оператор говорит, что полоса на СОРМе закончилась и дальше расширяться давайте без него...

LostSoul В самом деле, зря вы на нетап нагоняете. Если использовать просто как биллинг+радиус сервер, то свои задачи он решает и очень неплохо. DCHP-сервер у них говно, ЛК некрасивый конечно, но кроме функции оплаты абоненту Интернет в ЛК ничего и не надо. Готовые модули интеграции выйдут дешевле, если в штате или под рукой нет программиста/админа с опытом программирования, чтобы прикрутить, что-то найденное на форумах

ну как уже написали выше, то лучше конечно переделать дизайн, чтобы петлящий порт не влиял на зависание свитча и другие свитчи (т.е. vlan-per-user и broadcast/multicast/unicast лимит, чтобы не убивать брас) но понятно что сделать это непросто и поэтому можно просто пихать сислоги в БД и сделать простенькие триггеры, которые по инсерту будут решать что делать

http://c-bgp.sourceforge.net/ должно работать под windows xp

>>г) инфраструктура автономных систем сети "Интернет", критерии отнесения к которым устанавливаются федеральным органом исполнительной власти в области связи. >Корневые серверы также уходят под контроль государства. Дальше можно не читать. Ведь как изветсно весь трафик ходит через те самые 13 корневых серверов

Negator А что с агрегацией и ядром? Чтобы сгенерить их конфиги нужно хранить формализованно топологию и инфу о всех "дополнительных" вланах типа B2B подключений и прочего

ну тогда да, вас просто послали на 3 буквы некрасиво с учетом того что это баг, а не новая фича

Так может этот свитч давно end-of-support. если это так, то ни один вендор не будет править баги

может я отстал от жизни, но такого не бывает Используйте VRRP

Специально для этого придумали DHCPINFORM RFC2131

нет, ну они подтвердили что это нерешаемо?

я научил, точнее просто поставил git-web и там всё находили без проблем монтёры