Мартен

пытаюсь создать красивую схему ядра с резервированием и балансировкой. уверен, что колесо уже изобреталось, однако что-то не выходит красоты :( схема на картинке. вопрос такой возникает: как от бордеров проанонсировать дефолт так, чтобы исходящий трафик из сети не стекался на какой-то один роутер, а шел на тот бордер, через который сеть назначения ближе? опять же, при отказе канала А трафик должен идти со свитча С на бордер В, однако пока жив А, он будет продолжать анонсировать дефолт с меньшей метрикой и трафик пойдет на него. тут либо редистрибьют делать внешних маршрутов во внутреннюю сеть :( либо... тут мысли кончаются. как красивше сделать (L3 свитчей типа С в будущем может стать больше, как и бордеров)? во всех цисковских мурзилках даются общие принципы, а вот конкретной подобной схемы не встречал. PS чёрт, лишние картинки не убрать. сорри

это их хлеб - рекламу показывать. Пчёлы против мёда :)

металлическая ограда, перекрывающая основной лепесток тарелки порадовала :)

да, сорри, прочитал невнимательно

аски 6-тициферные долбанули по рунету 3го мая. пострадали многие, вплоть до MSK(SPB?)-IX роут серверов. и проблема именно в квагге. либо пачтить либо обновлять. http://www.google.ru/search?hl=ru&clie...mp;aq=f&oq=

идея ограничивать связность клиентам имхо провальна прежде всего с коммерческой точки зрения (если только вы не монополист). юзер проголосует кошельком против таких мер.

в линуксе rpm {-V|--verify} проверит md5 суммы файлов, установленных из пакета. для бинарников и библиотек они, естественно, меняться не должны. если изменены, то достаточно переустановить только 1 конкретный пакет. debsums - аналог в дебиане. хотя думаю, что если вас похакали, то лучше ставить систему с нуля, т.к. нет гарантии, что вы все последствия найдете и устраните и нигде дырочки не останется :)

холиварим? :)на самом деле мне вот ваш код также кажется нечитаемым. тут кто к чему привык, спорить глупо имхо. ваша схема требует внешнего скрипта и хранилища, моя нет. вот пожалуй и вся разница.

против ssh-сканеров легко помогает такая конструкция: -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 -j DROP -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT у бота 3 попытки. потом он блокируется на уровне iptables и, если продолжает ломиться, до ssh демона никогда не доберется :) если же прекратит попытки, то соединение сможет установиться только через минуту. эти цифры легко меняются. PS реально, после введения данной меры в логах стало практически пусто на предмет попыток подбора паролей.

чего-й то мы новую в районе 100к покупали вроде...

в debian lenny только 2009-05-04 20:15 патч наложили :)

level one http://global.level1.com/product_d.php?productid=4 чипсет Realtek. внутри различий с телесином потчи нет. стоят копейки совсем. не подводили ни разу (годами без перезагрузки)

0.99.10, 0.99.11 - точно падают 0.99.5, 0.99.6 - не падают

за эти деньги можно на me3400G-12 посмотреть, там 12 комбо+4SFP. очень приятная железяка, 2 БП опять же

да купите вы SFP у Нага, нормально работают и все циски их едят спокойно

медный sfp стоит копейки

+1

Потому , что мы на столько бедные , что не можем прокопать свою оптику от М9 до Волоколамска ... поэтому арендуем сеть передачи данных у мультисервисников.А они дают VPN только L3 т.е. связность с М9 у вас L3? если так, то только роутер вас спасет, и, если бюджетно, то писи :)

3560 был показан просто для примера, как не самый последний представитель L3 свитчей. дело в том, что, как уже было сказано, терминация VPNов производится процессором свитча, а не фабрикой (именно она(т.е. микросхемы) умеет мегапакеты в сек прожевывать). а проц на свитчах хилый совсем, гораздо слабее среднего писюка. поэтому терминацию впнов на горазо лучше делать на писюке, чем на свитче.

про L3 VPN на свитчах ниже cat6500 забудьде, ибо process-switching. та же 3560 на 10Мбитах ляжет. да и шеститонник много не вытянет, просто проц помощнее. (это все не относится к MPLS). лучше заберите весь бардак обычным .1Q транком себе в ядро, а там разруливайте.

не надо меня пытать :) версия 1.4.17. вероятно, все дело в задействованных модулях. я работаю только по SIP и IAX, без H323. астериск при этом крутится в отдельном контейнере openvz. сервер - 2xDual-Core AMD Opteron Processor 2214. проблем не замечаю. да, до этого была версия 1.2 не помню какая, тоже проблем не было. вообще их на 32х битах не гонял никогда :)

три условия: 1. дырка под VIC-E1 2. место на флешке под Voice IOS, достаточное кол-во RAM, ну и сам IOS 3. дырка для PVDM если все это есть, думаю должно полететь. на практике не проверял

1751v от Нага умеет 100%. http://shop.nag.ru/core.asp?main=catalog&a...3123&cat=86

ram_scan сказал, что не умеет :( а результаты тестов интересны очень

не, не согласен.да, restart now не делает ПОЛНОЙ перезагрузки сервера, но это далеко не только перечитывание конфигов. при restart now рвутся все звонки (это как минимум одно отличие), можно поискать еще.