Как стать автором
Обновить
5
0

Пользователь

Отправить сообщение
Серия CE 12800 очень крутые коммутаторы
Аутентификация по RADIUS или 802.1X — исправьте, звучит не грамотно. dot1x может использовать Radius аутентификацию. А что насчёт авторизации? Не поддерживается? А аккаунтинг? Ну и так далее. Уже не говоря о том, что Ваше решение — решение для кампусных сетей и не более.
Какой-то колхозный ДЦ. Тунелирование BGP — это что такое? Вы имеете в виду, что для поднятия BGP-пиринга не обязаельно прямое соседство? Но это не называется тунелирование. И нафига вам вообще BGP, если у вас нет PI-адресов и собственной автономки? А какая технология используется для резервирования ЦОДов, как организован DCI? Прокидываются ли L2-сегменты между ЦОДами? Если нет, как будут переезжать виртуалки между цодами или active-standby-оборудование, которое не умеет по L3?
На какой технологии реализована сетевая часть? Как устроен DCI?
За счёт мультиплексирования.
Да, хочу добавить, что де-факто AH больше не используется, используется только ESP.
В статье полно грубых неточностей:

Security Association (SA) — протокол для настройки AH или ESP
SA — это не протокол, это просто Security Association, параметры безопасности.

Туннельный режим. Подписывает (если AH) и шифрует (если ESP) весь пакет.

Во первых, ESP тоже подписывает пакет. Во-вторых, ESP подписывает не весь пакет, а только его часть, AH подписывает весь пакет включая туннельный IP. Именно поэтому не верна следующая информация:

AH и ESP используют свои протоколы (не порты TCP/UDP, а протоколы), но в современном мире, где NAT стоит за NAT у NAT с NAT'ом, следует использовать что-то более привычное, поэтому сейчас повсеместно используется инкапсуляция AH и ESP-пакетов в UDP.

AH не совместим с Travers-NAT, т.к. он подписывает весь пакет вместе с UDP, соответственно при прохождении через NAT при трансляции портов нарушается целостность. Второй момент. Сама формулировка AH и ESP используют свои протоколы кривая. ESP и AH — не используют никакие протоколы. Грамотно было бы написать вот так — AH и ESP — транспортные протоколы, инкапсулируемые прямо в IP и имеют собственные значение для поля Protocol в IP-заголовке, ESP — 50, AH — 51. И кстати у этих протоколов есть аналог портов — SPI, который используется для мультиплексирования, так же, как и порты в UDP/TCP.
По поводу фрагментации ещё одно интересное наблюдение. Если выставить MTU больше минимального на маршруте, то, как я писал выше, будет выполняться фрагментация пакетов после шифрования. При этом, все дополнительные заголовки ВПН, которые формируют значительную долю оверхеада, будут представлены только в первом фрагменте, все остальные фрагменты будут без доп. ВПН заголовков. Т.е. теоретически, больший MTU может позволить уменьшить оверхеад, но только для больших пакетов. Но за этим сразу же следует негативный эффект, по крайней мере в случае с ipsec — деградация производительности. Причина следующая — при фрагментации пакетов после шифрования, терминирующий канал роутер перед расшифровкой пакета должен сначала его собрать, т.е. сборка всех пакетов, фрагментированных таким образом, ложиться на плечи роутера. Если же пакеты будут фрагментироваться до шифрования, они могут быть расшифрованы без сборки на стороне роутера, сборкой в этом случае будет заниматься конечный узел.
Вы никогда не добьётесь скорости канала по ВПН-соединению, т.к. есть такое понятие, как overhead, который складывается из заголовков, в которые инкапсулируются данные. А у ВПН их много, много больше, чем у обычного IP-трафика, т.к. если используется тунель, это как минимум пара IP-заголовков и пара транспортных. И чем меньше пакеты, тем больше доля оверхеда. Если пакеты совсем крошечные, скажем, меньше 100 байт, что характерно для VoIP, оверхеад может достигать 50%, т.е. на канале 100 мегабит 50 будет уходить на служебную информацию. Это первое. Второе. Установка значения MTU большим, чем минимальное на маршруте приведёт только фрагментации уже шифрованных пакетов, что в случае cisco, например, должно избегаться, т.к. это приводит к деградации производительности. В случае openVPN не уверен насчёт деградации, но никакого положительного эффекта от такой манипуляции не будет определённо.
Следуя Вашей логике тогда udp/tcp — тоже труба, потому что есть порт.
Если под трубой понимать тунель, то в транспортном режиме IPSec никакой трубы нет.
Главное и единственное требование, чтобы считаться VPN — эмуляция выделенного канала по ни разу не выделенной инфраструктуре.


Голый IPSEC в транспортном режиме эмулирует выделенный канал? Может ли он считаться VPN? Согласен, с терминологией относительно VPN нужно быть предельно осторожным.
GRE и mGRE сам по себе, без ipsec не может считаться VPN-технологией, т.к. он не реализует функции целостности, конфиденциальности, аутентификации и т.п. Это просто туннель, данные идут чистым текстом.
Причины возникновения MPLS какие-то совсем бестолковые, L2 протоколы поверх MPLS — это одно из множества приложений MPLS и далеко не самое важное. Причины возникновения MPLS следующие:
1. Когда не было ещё технологии CEF mpls позволял достичь производительности сравнимую с коммутацией L2, которую нельзя было достичь на IP-роутерах того времени.
2. MPLS позволяет реализовать концепцию BGP-free core, что значительно уменьшает требования к ресурсам роутеров и упрощает инфраструктуру.
3. Методы построения VPN на момент возникновения mpls были не эффективны и плохо масштабировались, особенно громоздкими и неудобными были попытки реализовать L3 VPN. MPLS эффективно решает все связанные задачи. Хотя тут есть множество компромиссов, например, в таком VPN трафик без доп телодвижений не шифруется.
4. MPLS TE оптимизирует распределение потоков трафика внутри сети, используя концепцию source-routing. DS-TE позволяет дополнительно учитывать классы трафика при организации туннелей.
5. Как пишут в книжках, провайдеры тех лет были вынуждены поддерживать несколько независимых инфраструктур, mpls позволял построить общее унифицированное ядро, по которому можно было передавать любые виды трафика — то, о чём Вы и пишете, только немного в ином приложении, это не для построения VPN клиентов было важно, а для самой сети провайдера.
голый IPSec не масштабируется. Слишком трудоемкое у него сопровождение.


Это не совсем корректно. Вы говорите только об одном аспекте масштабируемости, причём не самом важном, так называемом административном оверхеде. Да, поддержка большого количества туннелей — это головная боль для администратора. Но чем в этом смысле IPSEC хуже, например, full-mesh mpls-TE, где на каждом устройстве может терминироваться тысячи туннелей? На IPSEC ничто чисто технически не мешает построить очень большую сеть, поэтому, всё же, основной ограничивающий фактор масштабируемости ipsec — это топология spoke-and-hub, которая тянет за собой большую нагрузку на хабы по трафику, и увеличение delay в случае телефонии или видео между spoke-сайтами. Развитие DMVPN подтверждает это, т.к. только первая фаза решала проблему административного оверхеда. Вторая и третья фаза направлена на решение более острой проблемы масштабирования — разгрузить хабы от трафика и уменьшить задержку путём ввода spoke-to-spoke туннелей. Кстати, в статье нет ничего про отличие второй и третьей фазы, хотя бы архитектурно. А раз мы говорим про масштабирование, это очень важно. Вторая фаза имела серьёзные проблемы с масштабированием, т.к. она требует использование daisy-chain. Вторая проблема — невозможность создавать spoke-to-spoke между роутерами, которые находятся в разных NBMA. Третья фаза очень эффектно решает эти ограничения.
mGRE — это часть технологии DMVPN, о которой тут упоминается. Там кроме mGRE задействован ещё NHRP и IGP. Ну и ipsec естественно.
Я бы добавил в описание класс ошибок, связанный с тем, что на одной стороне есть SA, а на другой его нет. Такая ситуация может возникнуть например при перезагрузке одного из роутеров, на котором терминируется IPSEC-канал. В общем случае при возникновении данных условий, сторона, которая имеет SA будет по прежнему шифровать трафик, который не может быть расшифрован другой стороной, т.к. она не имеет соответствующего SA. Данная ситуация может сохраняться в течении lifetime для SA, который по умолчанию кажется что-то около суток. Особенно данная ошибка критично там, где используются dynamic crypto map, т.к. в этом случае обмен пакетами ISAKMP может начать только одна сторона, как правило это spoke, и если там есть stale SA, то это закончится описанной ситуацией. Проблема решается включением isakmp keepalive.

Ну и хотелось бы услышать в статье, чем отличается DMVPN Phase 2 от Phase3. Самое важное архитектурное отличие — Phase3 позволяет строить spoke-to-spoke туннели между разными NBMA.
2.1 Cisco об этом не просто упоминает, а это стандартный дизайн всех современных сетей, де-юре и де-факто. Если Вы строите сеть на Cisco у Вас собственно только два возможных варианта — Local-Vlan или L3 на аксессе, end-to-end vlan должны избегаться. Как на это смотрят другие вендоры я не знаю, возможно для кого-то сети без STP — действительно откровение.
Как я понимаю политику Cisco, теперь все коммутаторы должны быть L3, потому что традиционно 2960 всегда был аксесс коммутатором L2. Т.е. выпуском данной серии вроде бы как приканчивается L2 на аксессе, по крайней мере в ближайшей перспективе. При этом Cisco не кричат о новом мире, для них это всё та же иерархическая модель, и про полностью L3-ethernet без STP рассказывается ещё в учебниках примерно 10-летней давности. Т.е. пост чистой воды маркейтинговый, технологически ничего нового.
Вы пишите про отказ от L2 и STP, и, как я понимаю, это камень преткновения «нового мира», о котором повествует данный топик. А чем «новый мир» принципиально отличается от хорошо известной концепции local-vlan, когда vlan не выходит за границы аксесс-коммутатора и двух дистрибьюшен-коммутаторов? Т.е. при использовании loca-VLAN у вас STP только на краю сети, а ядро исключительно L3 с использованием OSPF/ISIS?
Второй момент — сейчас Cisco производит L3 аксесс коммутаторы 2960 XR, которые поддерживают IGP, т.е. они позволяют строить сети, где STP сужен до размера коммутатора, т.е. вся сеть, включая access получается маршрутизируемой без STP. Т.е. не понятно, чем отличается Leaf-Spine от обычной практики построения сетей на основе L3-коммутаторов.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность