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 не нужны" по моему рановато, пока в интеле не появятся новые фичи именно под эту задачу (а интелу это нафиг не надо).

Он, вообще-то, по теме. Я такой честной и откровенной самокритики от Сааба даже не ожидал.

Там действительно магия, я в свое время мозг сломал, но докопался (сначала до интегратора, потом до вендора). У ASR1k tcam есть (на ESP), но он только под QoS и, IIRC, акцесс-листы, для route lookup он не используется. RIB живет в RP DRAM, FIB живет в трех местах: RP DRAM (меняемая копия видимо), ESP DRAM (ХЗ под что именно, уже забыл их картинки с архитектурой) и QFP RLDRAM (QFP это quantumflow processor, который в девичестве Tensilica Xtensa, и где route lookup и происходит). Вот в QFP RLDRAM влезает до миллиона маршрутов. Поэтому с 4 гигами на RP упираемся в эти четыре гига (скорее всего софтовое ограничение, наверняка могли бы убрать при отказе от двух копий иоса в памяти), а когда добиваем до 8 - упираемся в предел на QFP. Там еще какие-то заморочки с тем, что у ASR1001 ESP и RP обьединены, и эти четыре гига используются сразу и там, и там. В RIB же влезает побольше, с 8гб вроде миллионов 7 маршрутов, и десять с лишним с 16гб. Как-то так. Поддерживаю. Мне вот МХ-ы нравятся. :-)

Второй вариант, на мой взгляд, лучше. Меньше заморочек, удобней управлять.

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

Опыт у нас, очевидно, разный, но мы спорим не о том :-) Я говорю, что до некоего предела можно отбиваться без блэкхола и это уменьшает частоту ДДоС-ов, Вы начинаете приводить примеры за этим пределом, говоря, что эти меры не помогут отбить всё. Да, спасибо, я в курсе :-) Убеждать Вас в том, что отбивать не запредельные атаки можно и нужно без блэкхола я Вас не стану, Ваша сеть и Вам виднее, что с ней делать, но меня убеждать в том, что у меня всего лишь два варианта, когда я знаю, что это не так, тоже не стоит :-) Остальное можно личкой и обсудить, чтобы не флудить зря.

Blackhole это не защита клиента от ДДоС, это защита инфраструктуры (своей и аплинков) от ДДоС. Нет, он не является единственно верным, это решение на крайний случай, если больше ничего не помогает. Аплинки бесплатно обычно это не делают :-) Но такие, которые предоставляют связность при наличии периодических ДДоС-ов, все же есть, и стоит это не так уж и много. Свои решения плюс аплинки с резервом обходятся дешевле, чем специализированные сервисы, а работает это в плане качества предоставления услуг лучше (потому что своё знаешь всегда лучше). Репутационных потерь (и как следствие разбегающихся клиентов) по сравнению с укладыванием пачки сайтов при первом же флуде на порядки ниже. ДДоС-ы уровня тех, что прилетают порой на cloudflare, предельно редки (и как раз подходят под тот самый крайний случай). Самое смешное, что такие обьемы и масштабы ДДоС-еры обычно оставляют для того, чтобы заДДоС-ить какой-нибудь сайт своих же конкурентов, который лежит как правило...правильно, на cloudflare, чтобы защититься от ДДоС-а конкурентов :-) Тут уж они бросают все, что могут, целыми командами, и получаются такие страшные цифры. В реальной жизни на клиентов обычно прилетает от какого-нибудь script-kiddie с hping-ом на виртуалке с подломаным вордпрессом, или же начинающего ботовода с мелким ботнетиком. Чуток резерва - и сам не заметишь. Эскалация ДДоС-а...маловероятно, если им не хватает своих сил, то конкурентам уровнем повыше своего клиента врядли отдадут :-) Клиенту наверняка говорится "ну не шмогла" и клиент на этом успокаивается вместо поисков кого-нибудь покруче. Атака же в несколько гигабит операторам уровня повыше Зажопинска вообще ни о чем. Атака на блок адресов...смотря какая. Блэкхолом это не решить, зато прекрасно решается распределенными фильтрами и работой с аплинками, а то и даже не замечается. Чуть ли не самая лучшая защита от ДДоС-а это некомпетентность ДДоС-ера, там головастых ребят не так уж и много, и платят таким более серьезные деньги за более серьезные задачи, чем завалить мелкий сайтик на хостинге, поэтому чего-то более сложного ожидать можно, но редко. Если кто поумнее взялся и перебирает варианты, да, головняка побольше, но это даже интересно :-) Впрочем, такой пока был только один. Уточню, задачи держать клиента на плаву несмотря ни на что не стоит, это не какой-нибудь банк, где принципиально важно держать сервис на плаву в любую погоду, этим пусть специализированные конторы и занимаются. Задача - отбивать мелкое и, если получится, среднее, снижая тем самым частоту ДДоС-ов, а не пытаться быть еще одним специализированным сервисом по защите. Если повалило так, что не удержать - да, тут уже blackhole. Но! Только после того, как хотя бы попытался отбить сам, иначе это повторится снова и снова. Раз в неделю - это, гм, очень дохрена на мой взгляд при таком трафике. На мой взгляд это отличный пример того, почему не надо блэкхолить все подряд. Я не знаю, откуда у Вас такое впечатление, что ДДоС это что-то, от чего невозможно защититься кроме как блэкхолом или покупкой специализированного сервиса. По моему опыту это совсем не так.

Самый правильный вариант в данном случае будет перенести серверы хостинга туда, где каналы пошире, продаваны аплинков поадекватней, а инженеры не боятся слов типа bgp flowspec или, если нет техвозможности, хотя бы автоматически выставляемых фильтров на вашем интерфейсе. Дальше несколько гигабитных портов с оплатой мелкой полосы по 95-процентили и вас большинство ДДоС-ов и волновать-то особо не будут. Если в городе с каналами проблемы, то хостинг там держать не очень хорошо. Да, если сервера будут стоять в другом городе - это головняк, доп.расходы, и нужно больше резервировать, но если на вас раз в неделю ДДоС-ы идут с перерывом сервиса для всех клиентов, то у вас репутационные потери возможно уже больше. И, кстати, блэкхол - это самый дурацкий способ борьбы с ДДоС, потому что это значит, что ДДоС удался, заказчик его закажет снова, а ДДоС-ер не постесняется по накатанной снова ботнет зарядить.

Они, заразы, жрут как не в себя...

Поэтому две, одну в ЗИП. Но вообще б/у кошки ценятся за то, что они как правило довольно стабильно работают и дальше. Ну и потому, что в интернете полно инфы, конечно. Кошка будет пакеты молотить асиком, фильтры и QoS прогоняя через TCAM на line rate, а не через CPU и медленный DRAM, как результат латентность лучше, при флуде мелкими пакетами не помрет и так далее. Если нет задачи клиентов натить и шэйпить, например, то ставить писюк не просто бессмысленно, а еще и вредно. И дороже, если сравнивать с все той же парой б/у 3550. А на L3 как ? Задача поставлена была именно между вланами форвардить. И кстати зачем 10г с 200-250 абонентов ?

У нас сейчас ищутся неспешно адекватные люди, так критерий как правило либо "молодежь с огнем в глазах" либо "уже не молодежь, но с огнем в глазах и опытом". Если человек уже много знает и умеет, не боится нового, но уже набил шишки, то это вообще отличный вариант. А вот если это кто-то за 30, но опыта работы год или два на офисной админской должности...да даже если и больше...тут да, сразу отсеиваем, и наверняка таким крайне сложно найти что-то кроме такой же офисно-админской должности. Тоже Замкадье, правда Питер. В регионах подальше мы вообще ищем разве что тех же офисных админов на смешные зарплаты, либо удаленные руки...