У Делла да, саппорт «специфический», к сожалению.
С Нутаниксом история немного другая — оно живёт, даже в Community edition вполне годно для небольшого продакшена, но всё равно нужны люди «на месте», которые умеют его готовить. Даже если это коммерческая версия.
Но комьюнити весьма хорошее
Странно, конечно — обычно overlay каналы получаются дешевле (и уж точно гибче в эксплуатации). С другой стороны — если расстояния небольшие, и брать не волокно, а лямбду в нём, то получается не так дорого, согласен.
И кстати, почему именно тёмная оптика, а не провайдерские VPN? задержка при размещении в пределах Мск не сильно вырастет, а надёжность и гибкость сильно выше
Про зоопарк прекрасно понимаю :)
А почему остановились именно на вендорском клауде? Почему не тот же opennebula/cloudstack/openstack/vmware поверх commodity железа?
Вот ровно такие боли у меня обычно со связкой ASA<>SRX и бывают, да.
А тут прям удивился, что удалось собрать туннель, который не разваливается раз в сутки
Справедливости ради, первая фаза дебажится через 'request security ike debug local… remote ...', т.е. натравить можно на на конкретное соединение.
В traceoptions, ЕМНИП, тоже можно фильтры задавать
По микротику тоже много гайдов (даже у меня есть парочка, хе-хе). Но там всё несколько веселее — с новыми версиями добавляются новые возможности, и старые гайды могут стать неактуальны или неоптимальны.
Возможно, роляют в т.ч. версии софта с обеих сторон, потому что у меня проблемы возникали частенько (основная — это кратковременное падение туннеля при регенерации).
С дебагом у меня проблем обычно не возникало — включаем debug ike и traceoptions (ну и debug на asa), и погнали. Ну да, «тонны логов», и прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно.
Ну после нашумевшего летом крупного DDoS на servers.com об этой истории даже в рунете можно найти информацию.
А самой атаке tcp amplification уже года три или четыре точно.
Единственное замечание — я думаю, что слово «DevOps» тут исключительно ради хайпа, а всё остальное — суровая действительность быстро растущего проекта, в котором вовремя не оказалось человека, который хочет навести порядок.
Я был ровно в такой же ситуации, только не техдиром, а рядовым админом. Нас была целая команда, но у нас в компании серверов больше, и росли мы примерно на x1.5-2 в год.
В общем, всё очень знакомо :) Многие вещи прям за живое цепляют
Кажется, ему этот вопрос задают почти на каждой встрече с читателями. Последнее, что я слышал (пару лет назад) — до сих пор варианты присылают, он их показывает своему знакомому (прототипу Падлы), но т.к. в реальности этого ключа никогда не существовало, то пока лучшего не нашлось ;)
Например, встроенный компонент IPSec, шифрующий отдельные пакеты данных.
Перестаньте, пожалуйста, тиражировать этот миф. IPSec-компонент в IPv6 давно уже «should» и не поддерживается, примерно, никем (именно в контексте «встроенного прозрачного шифрования»). Что, впрочем, не мешает вам поднять IPSec поверх v6-связности
>Альтернативой NAT является переход на IPv6
IPv6 не является альтернативой NAT. Он даже альтернативой v4 может называться весьма условно.
Легко.
1) PPP (вообще любой коммутируемый доступ) очень плохо масштабируется, по сравнению с plain ethernet. Вам нужно покупать BRAS/BNG коробки, выдавать клиентам инструкции по настройке оконечных устройств и т.д. и т.п. В ethernet оно "просто работает".
2) по поводу выдачи /30 на клиента-юрика (а для хомяков этим никто не помышляет) — это связано с полной изоляцией клиентов друг от друга (которую сделать на L3 гораздо проще, чем в рамках одного широковещательного домена). Да, можно использовать private vlans, ip unnumbered и прочие интересные вещи, но все эти решения, как правило, вендорозависимые и крайне хреново дебажатся в случае проблем.
3) Вы здесь немного подменяете понятия. Клиенту не выдаётся /30 сеть. Клиенту выдаётся 1 (один) ip-адрес. Как провайдер это реализует — это его, провайдера, дело, как и накладные расходы, связанные с выдачей адресов.
Генерация конфига для greenfield — это наименьшая из проблем.
Хотя даже здесь возникает вопрос — как хранить данные? Если конфиг чуть проще, чем банальное прописывание параметров ntp/dns/ssh, то уже возникает вопрос с форматом описания (например, параметров BGP).
А вот когда у вас brownfield, всё становится гораздо интереснее :)
P.S. Вы же уже, надеюсь, читали статьи из АДСМ?
Вы точно не путаете NOC (которые сетевики) и дежурную on-call смену?
С Нутаниксом история немного другая — оно живёт, даже в Community edition вполне годно для небольшого продакшена, но всё равно нужны люди «на месте», которые умеют его готовить. Даже если это коммерческая версия.
Но комьюнити весьма хорошее
А почему остановились именно на вендорском клауде? Почему не тот же opennebula/cloudstack/openstack/vmware поверх commodity железа?
На полноту не претендую, но возможно будет полезна)
А тут прям удивился, что удалось собрать туннель, который не разваливается раз в сутки
В traceoptions, ЕМНИП, тоже можно фильтры задавать
С дебагом у меня проблем обычно не возникало — включаем debug ike и traceoptions (ну и debug на asa), и погнали. Ну да, «тонны логов», и прямо по логу понять, что принимается в proposal, сложно, но обычно параметры «той стороны» всё же есть, так что сопоставить конфигурацию можно.
А самой атаке tcp amplification уже года три или четыре точно.
Если говорить про «что изменилось за год», то лично моё мнение: «лучше пока не стало».
Хотя тот же драфт ASPA внушает робкую надежду.
Но думаю, на каком-нибудь ближайшем ENOG мы поднимем эту тему ещё раз.
Спасибо!
Я был ровно в такой же ситуации, только не техдиром, а рядовым админом. Нас была целая команда, но у нас в компании серверов больше, и росли мы примерно на x1.5-2 в год.
В общем, всё очень знакомо :) Многие вещи прям за живое цепляют
Перестаньте, пожалуйста, тиражировать этот миф. IPSec-компонент в IPv6 давно уже «should» и не поддерживается, примерно, никем (именно в контексте «встроенного прозрачного шифрования»). Что, впрочем, не мешает вам поднять IPSec поверх v6-связности
>Альтернативой NAT является переход на IPv6
IPv6 не является альтернативой NAT. Он даже альтернативой v4 может называться весьма условно.
Можете на досуге посмотреть, сколько сетей у AWS...
Легко.
1) PPP (вообще любой коммутируемый доступ) очень плохо масштабируется, по сравнению с plain ethernet. Вам нужно покупать BRAS/BNG коробки, выдавать клиентам инструкции по настройке оконечных устройств и т.д. и т.п. В ethernet оно "просто работает".
2) по поводу выдачи /30 на клиента-юрика (а для хомяков этим никто не помышляет) — это связано с полной изоляцией клиентов друг от друга (которую сделать на L3 гораздо проще, чем в рамках одного широковещательного домена). Да, можно использовать private vlans, ip unnumbered и прочие интересные вещи, но все эти решения, как правило, вендорозависимые и крайне хреново дебажатся в случае проблем.
3) Вы здесь немного подменяете понятия. Клиенту не выдаётся /30 сеть. Клиенту выдаётся 1 (один) ip-адрес. Как провайдер это реализует — это его, провайдера, дело, как и накладные расходы, связанные с выдачей адресов.
Хотя даже здесь возникает вопрос — как хранить данные? Если конфиг чуть проще, чем банальное прописывание параметров ntp/dns/ssh, то уже возникает вопрос с форматом описания (например, параметров BGP).
А вот когда у вас brownfield, всё становится гораздо интереснее :)
P.S. Вы же уже, надеюсь, читали статьи из АДСМ?