Кажется, балкон надо было утеплять лучше:

7206VXR-1-6>sh env all  | i chassis
        chassis inlet    measured at -2C/29F
        chassis outlet 1 measured at -2C/29F
        chassis outlet 2 measured at 0C/32F
        chassis outlet 3 measured at 1C/33F

Чтобы не искать каждый раз пдфку - пишу здесь. Табличка, где описано все основное: количество rx/tx, I/OAT и подобное.

Последние N месяцев я с разной степенью активности/успешности занимаюсь реализацией MPLS в FreeBSD (общая страница со статусом и более общим описанием живет http://freebsd.mpls.in).
В качестве платформы для сигнализации был выбран bird.
Его пришлось пилить много и по-разному, в частности были добавлены:

• общая поддержка абстрактных таблиц внутри bird
• реализация LDP (RFC 5036)
• доделана реализация MP-BGP (RFC 4364)
• много разных внутренних мелочей, чтобы это склеить

Понемножечку код перезжает в официальную ветку: bird@mpls
Крылья оно уже отрастило, пока только учится летать. Вот так это выглядит:
( дальше много текста для любителей bird )

Несколько разных вариантов организации NAT в случае с несколькими провайдерами.

Disclaimer:
Автор не несет ответственности за результаты, возникшие в результате осмысления/применения текст данного поста.
( Read more... )

Предыдущее решение по маршрутизации пачки fib'ов жило себе, жило и хотело жить дальше, но у него не получилось: возникли проблемы с масштабированием. Тут надо сказать, что более, чем активно используется VRF route leaking, который в квагге лучше, чем iBGP сессией не решается. Да и квага без патчей очень удивляется, зачем это вдруг понадобилась iBGP-сессия внутри локальной машины. В общем, стало понятно, что табун^Wнесколько десятков квагг с 50+ iBGP сессий между ними способно растоптать мозг либо мне, либо последователям. Тем более, что все это надо растить и беспорядочные связи пресекать^Wадминить.

Вариантов в плане динамической машрутизации не так много - quagga, open* stuff и bird. Решения вопроса с редистрибуцией через kernel table в openBSD мне никогда не нравилось, поэтому выбор обратился на bird.

( Дальше про то, что в опенсорсе даже птицы без патчей не летают )

Понадобилось для проекта связать FreeBSD-машинку и облачко маршрутизаторов внутри GNS3. Нужная FreeBSD жила (и живет :) ) внутри VBox. Сама хост-машина со всем этим - тоже FreeBSD. Выделил отдельный влан, привязал его к GNS3 ("cloud" -> "generic Ethernet NIO"). Все на вид настроилось правильно, но связности не появилось. В FreeBSD/VBox пакеты от кошек виделись, счетчики же на интерфейсах у кошки показывали, что туда ничего не прилетает.
( А закончилось все в это раз быстро и просто )

Как-то раз, пару лет назад, надо было сделать немного HA для одного из роутеров в месте X. Фревый carp в тот момент не умел отсылать эвенты devd, про ifstated я не знал, поэтому через какое-то время для этой задачи пришел к ucarp'у. Скрипты были написаны, оттестированы, пачки вланов, квагги, dhcpы и прочая нечисть взлетала и исчезала по зеленому свистку весьма исправно. Система исправно работала, но от пары раз в месяц до пары раз в неделю в непредсказуемые моменты стали происходить непредсказуемые срабатывания ucarp'а. Несколько недель я ходило с бубном, подозрительно косясь на кошек, техперсонал и совершало прочие действия такого же порядка. Заменили даже одну из нод.

( собственно, что делать и как жить дальше )

В этом году (вроде бы) дошли руки^Wкрылья до одного FreeBSD-related проекта. Для него же понадобилось заимпортить в svn текущий снепшот 8-STABLE. Снепшот заимпортился, после чего радостно был поднят websvn и практически сразу же выяснилось, что оный websvn тормозит секунд по 30 на каждое действие.
( что это было? )