Cisco *

Сегодня я бы хотел поделиться своими наблюдениями о том, как работают inter‑VRF контракты внутри ACI, включая маршрутизацию и реализацию политик. Пристегивайтесь!

Что вам известно о распространении BUM трафика в underlay ACI? Если термин FTAG о чём-то вам говорит, в статье есть пара деталей о том, как именно реализованы эти деревья.

Спустя неожиданно длительный перерыв возвращаюсь для продолжения разбора технологий, использующихся в построении сетей ЦОД. Настало время разобрать тему подключения внешних устройств, таких как Firewall, Proxy и других сетевых сервисов. А что делать, когда необходимо создать целую цепочку из таких сервисов, пропустив через них весь или только часть трафика? Конечно, использовать статику, но не обычную же.

EIGRP stuck-in-active – почему одного holddown таймера недостаточно? Копаемся в деталях времён IOS 12.0 (это археология, детка!).

Не так давно я рассказал про одну из причин появления RFC 2328 на смену RFC 1583. Впрочем, описанный сценарий возникновения петли маршрутизации совсем не единственный. Помимо изменения метрики агрегированных маршрутов, RFC 2328 также изменил процесс выбора лучшего маршрута для внешних префиксов; а всё потому, что старый алгоритм мог приводить к петле маршрутизации без регистрации и СМС.

Общеизвестно, что существуют несколько версий протокола OSPF. Однако не только лишь все знают о том, что для OSPFv2 есть несколько вариантов RFC; подавляющая часть реализаций OSPF соответствуют RFC 1583 или RFC 2328. Пикантность ситуации в том, что эти RFC несовместимы между собой, о чём говорит и показывает вендор-которого-нельзя-называть. Ну и зачем же тогда IETF заморочилось созданием второго стандарта? Ответ прост: RFC 1583 содержит архитектурные недостатки, которые могут привести к образованию в сети петель маршрутизации.

Одно из наиболее ярких отличий между стандартами – вычисление метрики суммарного маршрута на ABR.

В нашу лабораторию небольшим, но стабильным потоком потекли железки, которые раньше обслуживались в сервис-центрах производителей. Вместе с ними появились и новые загадочные случаи с почти необъяснимыми багами. Скажу честно, что мы не были к этому готовы, но стараемся изо всех сил. Сегодня расскажу о том, как искали причины и устраняли одну такую странную поломку в ASA, а заодно объясню, как наш отдел справляется со сложившейся ситуацией.

Старина IPv4… В сетевом мире он распространён так же, как и воздух на Земле. Однако несмотря на то, что миллионы людей используют этот протокол в повседневной жизни, у IPv4 всё ещё есть пара сюрпризов в рукаве. Сегодня мы рассмотрим один из них.

В предыдущей заметке я описал, как можно заткнуть дыру в кривом дизайне OSPF – костылём, который усложняет и так запутанный OSPF.

NSSA-зона ещё больше усугубляет ситуацию: OSPF использует Forwarding Address в Type-5 LSA, которые транслированы из Type-7 LSA, чтобы обеспечить оптимальную маршрутизацию.

В первой заметке я описал типичный (насколько его проповедуют в интернете) сценарий использования Forwarding Address (FA): два ASBR подключены к одному внешнему сегменту, причём redistribution маршрутов настроен только на одном из них.

Очевидно, что такой дизайн плох с точки зрения отказоустойчивости, но, возможно, существуют сценарии, когда использование OSPF FA уместно?

Один из моих читателей прислал мне любопытный вопрос об NSSA (подробнее в будущей статье), который побудил меня копнуть глубже вопрос о том, зачем понадобилось поле OSPF Forwarding Address (FA) в Type-5 и Type-7 LSA.

Внедрение Inter-AS Multicast VPN сопряжено с рядом узких мест в случае, когда в ядре сети не используется протокол BGP. Эта статья описывает распространённое решение таких проблем, реализованное на базе Cisco IOS с использованием расширений протоколов MP-BGP и PIM.

Всем доброго времени суток!

Захотелось поделиться реализацией Hun-and-Spoke VPN между Cisco ISR (в качестве споков) и Linux+StrongSwan swanctl (в качестве хабов).

Небольшая предыстория.

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

Хабы располагаются в ДЦ в виде Cisco CSR. И вот с ними и была основная проблема, так как отечественные решения не могут пока предложить что-то наподобие полностью готового виртуального роутера (поправьте в комментариях, если я ошибаюсь).

В итоге, пока остановились на решении Linux+StrongSwan+FRR.

Добрый день.

Меня зовут Василий и я сетевой инженер.

В данной статье хочу рассказать вам про шишки, которые мы насобирали, чтобы достичь удобного в администрировании и поддержке корпоративного VPN.

Хочу сразу предупредить, что в статье будет больше слов чем кода, так как больше хочется показать подход, нежели чем предоставить готовое решение.

Итак, поехали.

Это первая статья из цикла “BlueTeam Trainings”. CyberDefenders является учебно-тренировочной платформой, которая предоставляет возможность на практике проверять уже имеющиеся навыки и приобретать новые в области информационной безопасности.

• ucs-6100-k9-kickstart.5.2.3.N2.2.23e.bin;
• ucs-6100-k9-system.5.2.3.N2.2.23e.bin;
• ucs-manager-k9.2.2.3e.bin.

Если вы хоть раз настраивали MPLS L3VPN, то у вас не возникнет сомнения в том, что весь подход вертится вокруг BGP. Будучи протоколом маршрутизации с развитым чувством собственного достоинства (в конце концов, он является основой для интернета), BGP использует внушительный список атрибутов префикса, которые лежат в основе алгоритма выбора лучшего маршрута. Несмотря на неприличную длину этого списка, большинство параметров предназначены для обеспечения детерминированности результата алгоритма, а не для управления трафиком руками инженера. Впрочем, иногда даже самые популярные параметры не подходят для решения определённой задачи. Если вы видите EIGRP в связке с L3VPN, возможно, это наш сегодняшний пациент.

Недавно встретил среди своей команды некоторое непонимание принципов работы ремарок в списках доступа. Ремарки расценивались, как еще еще одна строка с правилом. Не было понимания, как работать с блоками правил под одной ремаркой и т.п.

Хотел найти внятное описание по этой теме, но к своему великому удивлению, ничего не нашел. Поэтому решил описать данную тему сам.

Роли LSA довольно подробно разобраны в разных источниках: router LSA описывает узлы графа, network LSA предназначен для широковещательных сегментов сети, summary LSA обеспечивает взаимодействие разных зон между собой… Однако собрать эти структуры данных воедино в целостный граф кажется мне достаточно нетривиальной задачей. Безусловно, RFC является источником абсолютного знания в такого рода вопросах, но лично мне сравнительно долго не удавалось его полноценно осознать. В этой статье я хотел бы поделиться своим представлением о назначении типов LSA, а также процессом построения графа на основе LSDB.