Pull to refresh

Comments 4

Спасибо, статья интересная
Причем интересная в технической части, а не в той, которая заявлена в названии
Согласитесь, причина по которой компании приходят к концепции ОЦОД + РЦОД могут быть совершенно разными,
Но техническая реализация все же больше зависит от требований по надежности, производительности, катастрофоустойчивости и конечно от затрат. А не от того иностранная это компания или местный энтерпрайз переросток

Это я к тому, что информация в статье весьма ценная, но заголовок и водянистое начало статьи могут оттолкнуть целевую аудиторию от дальнейшего прочтения, а там самый жир

Пару вопросов по сетевому дизайну:
1. EIGRP — это такой мощный вендор-лок.
Вы аргументировали применение EIGRP тем что в OSPF необходимо тюнить много таймеров.
Но все перечисленное вами сетевое оборудование поддерживает BFD. OSPF как и остальные реализованные в современном железе протоколы могут использовать BFD вместо keepalive. BFD реализованы прям в ASIC-ах а там субсекунды гораздо субсекундней.

2. тунели и DMVPN — второй вендор-лок и заплесневелая технология.
Если операторы филиальной сети разные то относительно удобно. Иначе используя динамику на стыке с оператором можно получить полносвязную подсеть организации без всяких тунелей. Правда в идеале для этого должен быть единый оператор. Но ведь с интернетом получилось найти 2-х операторов с присутствием на двух площадках

3. GRE тунель между граничными BGP маршрутизаторами. Из рисунка непонятно на чем тунель держится. Если отдельный линк через DCI то зачем GRE. А если тунель через интернет то получается уроборос.
BGP зависит от EIGRP, а EIGRP от BGP. Как такое траблшутить в случае чего?

4. BGP conditional. Я конечно не знаю подробностей задачи. Но почему было не разделить /24 на две /25 и анонсировать с каждого сайта свою половинку, благо оператор один?

з.ы. Картинки красивые. В чем рисовали?
Добрый день, iddqda, большое спасибо за отзыв.

Отвечаем на вопросы:

1. Это один из аргументов. Детальнее по пунктам:

· «Вендор-лок» уже был до начала проекта. Этим вендором заказчик доволен, поэтому решено не менять его на другого производителя.
· Про AISC. BFD хорошо использовать на оборудовании, если есть специализированный ASIC, где может работать BFD. В распределенной сети заказчика, включая ЦОД есть множество маршрутизаторов, а также Cisco ASA, которые не поддерживают аппаратно BFD.

· BFD между Main и DR ЦОД через L3VPN каналы и тем более к офисам лучше не ставить. Обязательно будет периодически флаппать OSPF, не говоря уже про то, что у нас в сети еще криптошлюзы.

· BFD – технология, позволяющая уменьшить таймеры обнаружения проблемы. Но вот время конвергенции после обнаружения отказа она никак не уменьшит. OSPF по умолчанию просто ждет 5 секунд для стабилизации сети. Если сеть флаппает, этот таймер увеличивается до 10 секунд. Также есть и другие таймеры, связанные с пересчетом LSA. Конечно, есть guide, где можно настроить конвергенцию меньше, чем в одну секунду, но это нужно делать очень аккуратно.

2. Это уже было так реализовано, и переделывать все филиалы не было возможности в связи со сроками. Конечно, было 3 общих L3VPN облака (оператора). У каждого филиала было как минимум 2 оператора, которые доходили до ЦОД. Каналы в филиалах равнозначны. А сами туннели нужны для шифрования, без них никак в Банках.

А в чем ее заплесневелость? Cisco с IWAN до сих пор продвигает DMVPN.

3. Там 2 типа GRE. Первые через интернет, просто с внешних интерфейсов. Вторые GRE специально сделаны через всю сеть Банка iBGP (Main)<->EiGRP (Main+DR)<->статика (DR). Таким образом, проверяется вся связность между ЦОД внутри и во вне сети заказчика, чтобы исключить все false positive и true negative описанные выше сценарии.

Такой проблемы с траблшутингом не будет, т.к. второй EIGRP процесс – это по сути overlay сеть. В той цепочке EIGRP процессы разные. И на практике все оказалось не так сложно.

4. Даже, если мы бы договорились отправлять операторам по /25, а они в аплинкам отправляли /24, это нам не помогло бы.

· У заказчика уже используется более половины доступных адресов для Main ЦОД.
· Представьте ситуацию. Часть интернет-клиентов прилетает к оператору А и попадает в основной ЦОД. Если канал этот падает, то оператор начинает перенаправлять всех клиентов в DR ЦОД. А вычислительные мощности переезжать не должны. Пришлось бы тогда делать заворот интернет потока из DR ЦОД в Main ЦОД обратно. Ведь клиент будет продолжать прилетать к оператору А. Таким образом, сильно возрастают задержки для бизнес приложений, т.к. DR в другом городе. Да и схема тоже усложняется.

з.ы. Все схемы рисовались в Ms Visio.

"При модернизации связь между Main ЦОД и DR ЦОД, а также между ЦОД и филиалами должна быть переведена на шифрование с ГОСТ алгоритмами. Между ОЦОД и РЦОД достаточно было L3 связности."


А зачем ГОСТ?

В России согласно ФЗ 152 все персональные данные надо защищать, а в Банках особенно.
Есть требование 21 приказа ФСТЭК России (ЗИС 3. Обеспечение защиты персональных данных от раскрытия, модификации и навязывания (ввода ложной информации) при ее передаче (подготовке к передаче) по каналам связи, имеющим выход за пределы контролируемой зоны, в том числе беспроводным каналам связи).
Шифрование по AES не признается как достаточная защита для такого типа данных.
Разрешается только ГОСТ 28147-89.
Sign up to leave a comment.