Мартен

оно стОит как самолет :)

таких тоже была парочка, интерфейс cli тормозит дико и жутко неудобно. в остальном вроде ничего. только у меня были в железных корпусах. если ничего другого не найду, то придется с ними заморочиться

спасибо, лайткомов стоит парочка, больше не надо :)

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

powerware тоже симпатичные упсы делает. в том числе с внешними батарейными блоками. http://www.ups-info.ru/index.php?link=160563 насколько ёмкие батареи к ним подключали? штатную при этом выкидывали? зарядный ток какой дают?

IPPON Back Power Pro 400...800. включаются механической кнопкой. при восстановлении питания включаются сами. функция Green Power нейтрализуется выкусыванием резистора R15A с платы упса (проверено десятками инсталляций, проблем нету).

стандартная схема: мелкий БЦ либо жилой дом, когда хватает портов 8..12. схема включения всех абонентов - влан на юзера, поэтому мощный функционал на доступе не требуется. что действительно нужно: 8..12 портов 100Мбит, вланы .1q (от 64х), .1p и cos, snmp, storm-control, igmp snooping, внятное управление через telnet|ssh, крепление в стойку, стоимость до 3000р. пассивное охлаждение приветствуется. ну и надежность конечно, куда без нее. ранее использовались Planet WSD800, подходили по всем параметрам, кроме igmp snooping (оно там есть, но кривое). но они сняты с производства. поэтому ищется замена. кто что посоветует?

достаточно влана.

http://forum.nag.ru/forum/index.php?showto...mp;#entry422782примерно то же обсуждалось, но красивого решения так и не видно...

что-то явно не так. quagga на pentium-D ( :) ) 2FV+IXы. load average: 0.12, 0.19, 0.10

вы имеете в виду две сессии до RS?

предлагают прямой пиринг в основном мелкие. причем, как правило, и на роут-сервере они есть. так зачем прямой-то в этом случае?

Постоянно получаем предложения от участников SPB-IX к прямому пирингу в обход роут-сервера. я вот понять никак не могу: какой толк от такого шага может быть? какие плюсы, помимо возможного обмена локальным трафиком?

ну вот, почти 2 года стабильного полета с IMQ на 2.6.18 (Debian Etch). Пришла пора переползать на Lenny (2.6.26.2) и соответственно, новые проблемы. Патч linux-2.6.26.8-imq-test2.diff не кладется на дебиновские сорцы. Немного напильника и все наложилось. Если кому надо - модифицированный патч во вложении. Новое ядро в бою пока погонять не успел, но о результатах постараюсь отписать. linux_2.6.26.8_imq_test2_lenny.diff.gz

да толку-то теперь :) они с spb-ix'а исчезли, видны через msk-ix. зато работают.

согласен. тем не менее разумного объяснения отсутствия связности по 80му порту TCP пока нету.

не работал гугль только у тех, у кого путь до гугля через SPB-IX. может, еще у кого, у меня других данных нет. а магистралы - так не сам же гугль волокна себе тянул в калифорнию от Боровой 57 :)

traceroute www.google.ru traceroute to www.google.ru (74.125.77.106), 30 hops max, 40 byte packets 1 192.168.14.49 (192.168.14.49) 0.500 ms 0.489 ms 0.763 ms 2 gw1.spb-ix.google.com (194.85.177.138) 3.671 ms 3.673 ms 3.663 ms 3 216.239.43.240 (216.239.43.240) 41.482 ms 42.190 ms 42.181 ms 4 209.85.250.189 (209.85.250.189) 34.848 ms 34.877 ms 32.743 ms 5 66.249.95.132 (66.249.95.132) 36.217 ms 34.204 ms 34.195 ms 6 72.14.239.199 (72.14.239.199) 41.776 ms 39.032 ms 39.141 ms 7 209.85.255.98 (209.85.255.98) 43.473 ms 43.493 ms 43.496 ms 8 ew-in-f106.google.com (74.125.77.106) 38.239 ms 36.469 ms 36.523 ms а телнетом на 80й порт бесполезно, соответственно у клиентов поиск не работает. через левую проксю пашет. у коллег из другой компании то же самое (роут через SPB-IX). со всем остальным на первый взгляд порядок. что это - опять авария у магистралов? странно как-то.

там бабло бюджетное моютпилят в огромных количествах. поработать имхо пока можно :)

Чудеса... Как же ж у нас то оно работает... Правда не на кваге а на сиске 72й. Один в один картинка в первом посте - только два дефолта с одной метрикой. да никаких чудес. сейчас сделано по схеме основной+резервный. в тот момент, когда я писал про отсутствие анонса дефолта, на резерве были погашены все bgp сессии. инжект дефолта с резервного бордера (В) при этом действительно отсутствовал (проверено), несмотря на default-information originate always в настройках оспф. корректное ли это поведение у ospfd, сейчас разбираюсь. стоило поднять одну из сессий, дефолт стал инжектироваться. вот за этот момент спасибо, вроде очевидно, а внимания не обращал :)

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

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

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

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

таак, уже интереснее :) а теперь представим, что бордеры на квагге