twh.mega

А, и правда ! Тогда первые пару лет не волнуемся, а там может и телекома не останется. :-)

Добавьте в калькулятор замену вышедших из строя дисков хотя бы ? Я расчитывал исходя из 5% дисков в год (если на статистику backblaze смотреть - то по большинству моделей дисков меньше, но не везде есть идеальные условия). Эти 5% в результате вылезают в очень хорошую такую ежемесячную сумму ...

Ага, вполне вариант, не сильно злой по цене (по крайней мере если сравнивать c сисько и иже с ними). Еще наверное всякие длинки и прочее... Но может есть какой-то еще вариант, всем известный, популярный, удобный и недорогой, но по каким-то причинам пролетевший мимо меня. :-) Понимаю, что врядли, но вдруг ?

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

Кстати вот интересный вопрос насчет "свитч с пачкой 1G SFP и несколькими SFP+", что обычно используете из не-шасси свитчей ? Идеально если с мплс. По более-менее крупным вендорам я как-то смотрел, получается по ценникам сплошное порно. Такое впечатление, что пачка гигабитных оптических портов им в производстве стоит столько же, сколько такая же пачка десятковых. Ну или как более реалистичный вариант - зашкаливающая жадность.

Если вам нужны BGP/MPLS и еще какие необычные хотелки, то лучше сразу в сторону МХ-ов смотрите, ЕХ9208 хоть и построен по сути на том же чипе, только что с ТСАМ вместо низколатентной DRAM, но сильно урезан, чтобы не каннибализировать продажи МХ-ов. Фулл вью как в 65й вы в него не вольете. Если же фулл вью не нужен и использоваться будет как Р рутер, возможно с приводом клиентов на них, то я все равно не советую смотреть на шасси. Лучше уж тогда экстримовые свитчи с пачкой десяток и сороковок, вполне неплохо молотят, хотя и не без смешных багов порой. Обойдется сильно дешевле. Ну а если надо фулл вью и пачку внешних линков, и 65я вконец достала - я бы посоветовал МХ-ы (только с учетом того, что два RE есть начиная с МХ104, а в МХ80 он мало того что один, так еще и слабенький). Опять же ничего не мешает совмещать.

На прямые руки поддержку от TAC не купить ;-)

Я как раз AS-Stats использую, очень полезная вещь. И это таки не рисовалка, а в том числе и собиралка. Достаточно простая, перловый скрипт, слушающий указанный порт и укладывающий все в rrd файлики по автономкам, потом отдельный веб-интерфейсик, эти rrd файлы читающий. Показывает довольно наглядно, для оценки с точностью "навскидку" вполне хватает. А что он не показывает - показывает Арборовый Peakflow, это далеко не опен-сурс и совсем не дешево, но с аналитикой там все ОЧЕНЬ замечательно. Даже peering evaluation, предсказывающий, по каким линкам сколько трафика упадет при прямом стыке с такой-то автономкой (понятно что в случае с входящим трафиком будет все равно только примерно, bgp feed он кушает но оценить может только маршруты в своей автономке, впрочем даже это сильно помогает). Как раз с МХ-ов снимаю IPFIX, лью на хост с samplicator-ом, который дальше все копирует на нужные хосты с анализаторами. Советую глянуть хотя бы AS-Stats, ставится/настраивается просто, но хотя бы минимальную видимость по своему трафику получите. Если нужно смотреть инфу только по конкретному IX-у и nexthop-ам в нем - то хватит и каунтеров по МАС-ам, но это самим пилить.

К слову. Как раз с 3560. sh sdm prefer routing <почикано> А, уже неважно :-) Тогда совсем любопытно. Если он на л3 не терминирует, то почему он ругается на уникастовые префиксы ?

number of IPv4 unicast routes: 8K на каждом, но есть нюанс :-) number of IPv4 unicast routes: 8K number of directly-connected IPv4 hosts: 6K number of indirect IPv4 routes: 2K У вас там случаем не больше 2к маршрутов по сети бегает ?

sh sdm prefer гляньте на обоих, может просто забыли прописать нужный темплэйт ?

8 октетов преамбулы, говорящие "щас попрет хедер". Ну или "щас будет амбула". Преамбула уже на сотке нафиг не нужна была, но остается для совместимости. Затем идет л2 хедер, потом л2 пэйлоад (минимум 46, или 42 если л2 хедер с влановым тэгом). Затем 4 октета под CRC. Потом interpacket gap, "тишина" минимум 12 октетов (или точнее 9.6мс). Поэтому размер фрэйма со всеми оверхедами - это минимум 84 октета. Гигабит, если что, это не 1024 килобита :-) А 1000*1000*1000 бит. Делим на 8, получаем 125 миллионов байт в секунду, делим на 84, получаем 1,488 мегапакетов в секунду. Таким же образом считаем и максимальный ппс при максимальном размере фрэйма (1538 октетов), получаем 81кппс. "По неизвестным причинам". Спасибо, посмеялся :-)

1 гигабит самыми мелкими пакетами = 1.5мппс (ну, 1.48). Как вы получили 1.5мппс при 700мбит я не очень представляю :-) Может микротик каунтер инкрементит, но реально в интерфейс не шлет ? Edit: А, он наверное л2 хедеры не считает. В общем, вы банально в гигабит уперлись.

Они вроде как v5600 на вьятте допилили, но как оно работает - не знаю. В любом случае под другие задачи, не под generic routing, а на сервера с виртуализацией. Вот тут пишут, что 80гбит line-rate вытянуло на х86 железе, в качестве одной из виртуалок под KVM. Фактически замена OVS/bridge. Но. Я это не тестил. Если интересно, они вроде триал дают. Все равно они врядли будут выпускать Вьятту в качестве именно обычного рутера, смысл им со своими же продуктами конкурировать ? Наверняка ограниченный функционал под одну задачу и все. Его и написать проще. А если и будут, то только на продаваемой ими самими х86 железке без возможности поставить на что-то левое и с ценником, сравнимым с ценниками на рутера других вендоров со схожими ТТХ. С "ничего не дает" не соглашусь. Дает, просто надо это дальше использовать. Чтобы заменить рутер на линухе на рутер на линухе с DPDK, нужно линуху все части сетевого стэка переписать, где обработка транзитного трафика идет, а это задача не самая простая :-) netmap дает ровно то же самое, вот тебе инструмент, дальше сиди пиши обработку всего сам как хочешь. В линухе, кстати, схожие вещи есть, PF_RING например. Не в базе, правда. На нем разные appliance вполне эффективно работают. Просто Интел DPDK разрекламировал, как будто они все такие самые умные и единственные :-)

Intel DPDK дает то, что другие делали на других процах и так. Смысл менять, скажем, Джуниперу Cavium-ные процы в SRX-ах, где они снимают напрямую с интерфейса трафик и обрабатывают своим софтом, на x86 с DPDK ? Они под Cavium-ы уже свой написали, при этом проц с оффлоадами и доп.фичами именно под сетевую обработку. То же и по другим. Вон взять FreeScale-овые новые процы, которые тебе пакеты сразу парсят на 50гбит/с. Или Broadcom-овые XLP. Если за тот же ценник на железо можно прожевать больше pps, а софт все равно писать (или уже есть готовый), то DPDK не так уж и важен. Да, в линухе дохрена оверхеда и средствами ядра обрабатывать трафик получается не очень шустро. Но это не значит, что такой оверхед везде. Некоторые подсуетятся, да. Вон вроде Brocade как раз Vyatta допиливает под DPDK. Разные чисто софтовые компании будут на эту тему шевелиться тоже. Но орать про "NP не нужны" по моему рановато, пока в интеле не появятся новые фичи именно под эту задачу (а интелу это нафиг не надо).