Операционная система IOS/IOS-XE роутеров Cisco — источник вдохновения для большого числа других производителей. В Сети навалом инструкций, как сконфигурировать типовой роутер Cisco для сценариев SOHO. Однако, в отличие от «бытовых» роутеров, с настройкой такого конструктора, как Cisco IOS, придётся действовать аккуратно. Если не напрягать голову, то роутер начнёт жить своей жизнью и станет, к примеру, DDoS-амплификатором.

Вы ещё ощущаете жжение ниже поясницы при обсуждении MPLS? Даже если это уже давно пройденная стадия изучения сетей, технология коммутации меток всё ещё способна преподнести пару сюрпризов, особенно в сочетании с OSPF. Если Вам нравятся голые указатели в C++, а broadcasting в Numpy кажется естественным и непринуждённым – добро пожаловать под кат.

Несмотря на то, что два режима unicast Reverse Path Forwarding (uRPF) довольно известны, не только лишь все знают причину, по которой эти два режима существуют. В этой статье я постараюсь построить мостик между loose uRPF и одним из типовых сценариев его применения.

Настройка Cisco Catalyst 2950,2960,3750 + RADIUS Windows NPS

enable
conf t
hostname S1 #Где S1 ваше имя коммутатора
enable secret cisco #где cisco ваш привилегированный пароль
service password-encryption #обязательно шифруем пароли в конфигурации
banner motd $ WARNING: This system is for the use of authorized personnel only.Unauthorized access is a violation of state and federal,civil and criminal laws.$

int vlan 25 # настраиваем management доступ (SVI), у меня это VLAN25, у вас это может быть VLAN 1
ip address 10.25.0.10 255.255.255.0
description MGM
no shutdown
exit

ip default-gateway 10.25.0.1 # указываем шлюз

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

Добрый день дорогие читатели, в этой статье я хочу рассмотреть однин из основных способов логирования событий в cisco – syslog. Так же помимо него рассмотрим snmp traps, попробуем настроить "красивый" сбор логов на сервере linux.

Если EPG – provider для inter-VRF контракта, то он не может общаться внутри Preferred Group из-за некоего ограничивающего фильтра. Однако ведь подобные фильтры возникают при явном использовании контракта, не так ли? Спровоцируем баг и посмотрим, что же происходит на самом деле.

Сегодня я бы хотел поделиться своими наблюдениями о том, как работают 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.