Русский
Русский
English
Статистика
Реклама

Cisco

Обзор Cisco Umbrella защита на уровне DNS и не только

24.11.2020 12:18:29 | Автор: admin

Мы постоянно тестируем новые решения для наших проектов и недавно решили разобраться, что под капотом у Cisco Umbrella. Сам вендор заявляет, что это облачное решение для защиты угроз со стороны интернета из пяти компонентов:

  • защищенный рекурсивный DNS;

  • веб-прокси с возможностью отправки подозрительных файлов на анализ в песочницу;

  • L3/L4/L7 межсетевой экран (Cloud Delivery Firewall);

  • Cloud Access Security Broker (CASB);

  • инструмент для проведения расследований.

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

Защищенный рекурсивный DNS

Когда мы пытаемся попасть на какой-то ресурс по доменному имени, вне зависимости от протокола, мы резолвим доменное имя, то есть преобразуем его в IP-адрес.

Можно ограничивать доступ к ресурсам на основе URL (фактически уже HTTP-трафик), а можно делать это на шаг раньше исходя из DNS-запроса.

Cisco Umbrella в данном случае выступает как облачный рекурсивный DNS.

Решение может детектировать и блокировать DNS-обращения по таким категориям:

  • скомпрометированные системы;

  • связь с серверами управления (C2C);

  • Malware и Phishing;

  • автосгенерированные домены;

  • новые домены;

  • построение DNS-туннелей (DNS Exfiltration).

С точки зрения архитектуры, это выглядит так:

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

Пользователей как-то нужно перенаправить в облако для анализа их DNS-запросов, и здесь есть два способа.

1) У пользователей на площадках прописан локальный DNS (обычно адрес домен-контроллера). Нам достаточно просто прописать адреса Cisco Umbrella в настройках DNS Forwarders:

2) Удаленным пользователям достаточно установить AnyConnect (модуль Roaming Client) или Umbrella Lightweight Client, в котором будут прописаны адреса DNS и подцеплен профиль организации.

Доступность указанных адресов 208.67.222.222 и 208.67.220.220 обеспечивается с помощью BGP Anycast (когда одни и те же маршруты анонсируются из разных географических точек).

Таким образом, при обращении на эти адреса для уменьшения задержек вы будете направлены в ближайший ЦОД в зависимости от своего географического расположения.

Если провести небольшой тест измерения задержки утилитой dig при обращениях через Cisco Umbrella и публичный Google DNS (8.8.8.8), то получим следующие результаты.

Таблица 1. Результаты измерения задержки через Umbrella

Имя сайта

Замер 1

Замер 2

Замер 3

Замер 4

Замер 5

Среднее

1

mos.ru

89

39

41

94

86

69,8

2

admomsk.ru

46

96

90

39

95

73,2

3

state.gov

53

59

39

47

44

48,4

4

gov.cn

43

127

45

135

62

82,4

5

gov.uk

62

55

63

67

52

59,8

6

governo.it

59

64

66

58

39

57,2

Таблица 2. Результаты измерения задержки через Google

Имя сайта

Замер 1

Замер 2

Замер 3

Замер 4

Замер 5

Среднее

1

mos.ru

24

35

34

32

29

30,8

2

admomsk.ru

50

28

50

52

28

41,6

3

state.gov

29

51

289

56

39

92,8

4

gov.cn

375

30

30

557

359

270,2

5

gov.uk

74

68

32

75

89

67,6

6

governo.it

102

26

93

27

91

67,8

Как видно, Cisco Umbrella не вносит каких-то значительных дополнительных задержек по сравнению с публичными DNS.

Дашборд управления настройками располагается по адресу https://dashboard.umbrella.com/o/<OrgID>/#/overview, где <OrgID> это персональный номер вашей организации, выданный Cisco.

Со стороны Cisco Umbrella достаточно добавить ваш белый IP (адрес или несколько адресов, с которых площадка выходит в интернет) в список Networks, для roaming clients (удаленных пользователей) ничего дополнительно добавлять не надо.

Если у вас несколько домен-контроллеров, то скрипт автоконфигурирования (регистрации в Cisco Umbrella) и настройки DNS Forwarders необходимо будет настроить на них всех, а OpenDNS AD Connector (о нем позже) поставить только на отдельных VM.

Когда на домен-контроллере настроены DNS-forwarders, а у удаленных пользователей установлен Roaming Client, можно проверить, что вы находитесь под защитой Umbrella, перейдя по адресу https://welcome.umbrella.com.

Всё, вы под защитой!

Что же идет по умолчанию в этой защите? Посмотрим Default Policy.

Политика по умолчанию и её основные компоненты

Вот так выглядит основное меню настройки политики по умолчанию:

Applied to All Identities значит, что политика применяется ко всем, кто посылает запросы через Umbrella (в пределах вашей организации). Если делать свою политику, то можно указать много разных типов, к чему ее применять: AD группы пользователей, Roaming Computers, IP-адреса и др.

Security Setting Applied означает блокируемые категории:

Следует отметить, что DNS-политика по умолчанию не строится по принципу implicit deny (все запрещено), блокируются только категории Malware, C2C, Phishing Attacks.

Content Setting Applied подразумевает, какие DNS-запросы блокируются на основе содержащегося контента.

Если домен категоризирован как содержащий Drugs, он будет целиком попадать в эту категорию, даже если по ссылке www.example.com/Sports будет располагаться спортивный вестник о последних достижениях местной команды. А вот если блокировка на основе контента будет применяться в Web Policy, а не DNS Policy, то здесь как раз будет разграничение в зависимости от конкретного URL.

Application Settings Applied означает блокировку в зависимости от используемого приложения.

Destination list блокировка по конкретному FQDN, IP-адресу, URL (для Web-Policy).

Если вы добавили что-то в Global Allow List в виде IP-адреса или, например, FQDN, то это этот ресурс по категории или контенту уже не будет блокироваться (если он подпадает под эту категорию/контент).

Настройка File Analysis доступна, если вы включили в Advanced Settings функцию Intelligent Proxy. По умолчанию она отключена.

Intelligent Proxy предназначен для работы с так называемыми grey доменами, когда на них может быть размещен нежелательный контент или вредоносные файлы, но целиком блокировать домен нельзя или нет необходимости. В обычном режиме работы Umbrella либо возвращает в DNS-ответе адрес целевого ресурса, либо вот такую блокирующую страницу:

При включенной же опции Intelligent Proxy Umbrella будет возвращать вам адрес облачной прокси, через который будет проксироваться трафик с сертификатом Cisco (нужно установить сертификат Cisco в доверенные и включить опцию SSL Decryption). Большое количество очень популярных доменов, например, Google или Facebook, не проксируются из-за низкой вероятности размещения там вредоносного контента.

Grey домены

Grey домены включают в себя домены одновременно с нормальным и вредоносным контентом, поэтому Cisco категоризирует их как risky domains.

Самостоятельно категоризировать какой-то домен как серый нельзя, можно только исключить определенный домен из раскрытия трафика и проксирования.

При включенной настройке файлы будут отправляться на анализ в облачную песочницу Threat Grid Malware Analysis (для веб-политик) либо анализироваться статически в случае применения в DNS-политиках.

Например, при попытке скачать eicar файл у меня появилась надпись Этот сайт был заблокирован прокси Сisco Umbrella:

Block Page веб-страница, которая будет отображаться у пользователя при блокировке запроса. Настроить отображаемую страницу можно в разделе Block Page Appearance.

Можно модифицировать страницу блокировки, например, отразить, что запрос заблокирован из-за отнесения к конкретной категории или содержащегося контента, указать e-mail админа для контакта.

Создание политики на основе пользователей Active Directory

В большинстве организаций политики как на межсетевых экранах, так и на прокси, сейчас пишутся на основе пользователей групп Active Directory.

Cisco Umbrella тоже пошла по этому пути: интеграция с AD возможна путем установки OpenDNS коннектора на виртуальную машину для отправки LDAP-запросов к домен-контроллеру, либо на сам домен-контроллер.

Домен-контроллер регистрируется в дашборде Cisco Umbrella автоматически (путем запуска wsf-скрипта на домен-контроллере):

Я установил OpenDNS-коннектор на домен-контроллер. После этого в политиках, в разделе Identity, можно указать конкретного пользователя или группу, для которых будет применяться политика:

Попробую разрешить пользователю категорию Malware, а на уровне всей сети запрещу её.

Политики выполняются, как обычно, сверху вниз. Есть удобный инструмент для проверки уже созданных политик Policy Tester.

Для пользователя Barney получаю результат Разрешено:

Для обращения с домен-контроллера или любого другого пользователя получаю результат Запрещено:

Обращения к внутренним доменам обычно не нужно подвергать дополнительной проверке, поэтому их можно исключить из проверки средствами Umbrella двумя способами:

1) Через управление доменом в дашборде Umbrella.

2) Через установку отдельной VM Umbrella Virtual Appliance:

Umbrella Virtual Appliance выступает в роли DNS-forwarder, локальные DNS-запросы отправляет на локальный DNS, внешние DNS запросы в Cisco Umbrella.

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

А так выглядит лог без VA (локальные IP-адреса не видны):

Защита удаленных пользователей (Roaming Users) обеспечивается либо включением модуля Umbrella Roaming в Cisco AnyConnect, либо установкой Lightweight Umbrella roaming-клиента.

Интересный факт: Сisco Umbrella можно обойти, если прописать на рабочей станции нужные записи до закрытых ресурсов в hosts.

Лучшие практики при работе с DNS-политиками

1) Политики надо делать неперекрывающимися. Например, если вы сделаете явно allow destination list, а по категории у вас он вредоносный, трафик будет разрешен.

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

3) Политики нужно строить снизу верх от широких к узким. То есть в целом для одной группы пользователей запрещена категория облачные хранилища, но для отдельных пользователей вверху списка она разрешена.

4) Используйте в политиках группы All Networks, All Roaming Computers. Когда появится новый Roaming Computer, он просто автоматически подпадет под эту политику. Также желательно сделать разные политики для локальной сети и для Roaming Computers. Когда пользователь будет уходить из офиса, он будет подпадать под другую политику безопасности (возможно, более строгую).

Эти рекомендации применимы также и к работе с веб-политиками, которые я разберу ниже.

Работа в режиме веб-прокси

Решение может работать не только как рекурсивный DNS, но и как облачный веб-прокси.

Трафик в облачный веб-прокси от пользователей направляется точно так же, как и в земной с помощью PAC-файлов (proxy auto-config). Сам PAC-файл можно разместить в Umbrella. Проксируется только HTTP/HTTPS-трафик (TCP 80/443).

Вы можете задаться вопросом: А как аутентифицировать пользователей в облачном прокси? Ведь мы не можем здесь применить Kerberos/NTLM.

Ответ на него кроется как раз на картинке выше SAML.

В качестве IDP (Identity Provider) можно использовать как раз земной AD (ADFS) с установленным AD-коннектором, который я рассматривал в разделе защиты DNS.

В веб-политиках можно использовать все то же самое, что и в DNS-политиках, а также:

1)Антивирусная защита файлов с помощью движка Cisco AMP (Advanced Malware Protection) и отправка их в песочницу Threat Grid Malware Analysis. Ограничения здесь максимум 200 файлов в день с размером файла не более 50 Мб.

2) Контроль по типам файлов (File Type Control). Позволяет блокировать скачивание в зависимости от категории (исполняемые файлы, изображения, аудио и т.п.) и конкретного расширения (js, jpeg, exe и т. п.).

Вот так будет выглядеть попытка скачать файл из заблокированной категории Executables:

3)Tenant Control (CASB) позволяет явно разрешить использование корпоративного тенанта и запретить использование личного доступа для облачных сервисов Office 365, Google G Suit, Slack. То есть, например, пользователям надо ходить в облачный офис 365 по корпоративным нуждам, но по личным нам надо его прикрыть. Классический Application Control здесь не сработает, поэтому:

Tenant Control работает просто: Umbrella смотрит в authentication request, и если видит там корпоративный домен, явно разрешенный в политике, то пропускает трафик.

Вот так выглядит меню настройки:

Я добавил в список разрешенных доменов свой тестовый домен в Office 365 mx365x986845.onmicrosoft.com. Все остальные домены по умолчанию запрещены.

Попробую зайти в Office 365.

После корректного ввода пароля я успешно попадаю на главную страницу Office 365:

А теперь я попробую зайти в свою корпоративную учетную запись:

После ввода пароля я получил обескураживающее сообщение: Невозможно добраться отсюда туда:

Причем сообщение от Microsoft, а не от Cisco Umbrella. Немного погуглив это сообщение на английском языке, я нашел следующее в документации Microsoft: You can't get there from here. This message means your organization has put a policy in place that's preventing your device from accessing your organization's resources. Прелести русификации я оценил :)

Из недостатков данного облачного веб-прокси можно отметить отсутствие IPS-профилей.

Cloud Delivery Firewall

Решение может также дополнительно выступать в роли L3/L4/L7 межсетевого экрана в облаке, для этого потребуется завернуть трафик с площадки через IPSec-туннель.

Важное ограничение: в политиках МСЭ можно писать только приватные IP-адреса в поле Source и публичные адреса в поле Destination и никак иначе. То есть применение здесь вполне конкретное только ограничение доступа для внутренних ресурсов наружу.

Еще один нюанс: максимально допустимая полоса на каждый туннель 250 Mбит/с. Если потребуется передавать больше трафика, нужно будет строить дополнительные туннели и балансировать между ними нагрузку (например, ECMP).

В политиках можно добавлять Applications, но добавлять группы пользователей AD нельзя.

Пример настроенного правила:

Такой МСЭ может в принципе подойти организациям, на площадках которых нет своего МСЭ и есть только каналы в интернет (т.е. нет выделенных каналов до ЦОД, где можно централизованно выпускать пользователей в интернет).

Работа с отчетностью и расследованиями

В Umbrella представлен довольно хороший функционал для проведения расследований и анализа отчетности.

Можно смотреть как общее состояние по компании:

Так и детальное (кто-куда-когда-почему):

Имеется много разных типов отчетов (App Discovery, Threats, Top Destinations и другие). Отчеты можно выгружать в форматах csv и pdf, выгрузку отчетов можно делать автоматически, например, еженедельно, с отправкой на почту.

Пример выдержки из отчета App Discovery:

Функционал для помощи в расследованиях располагается на отдельном ресурсе https://investigate.umbrella.com/.

Работает это очень просто: вводите FQDN, ASN, IP, hash и получаете риск-скоринг и другую полезную информацию:

  • данные записей WHOIS;

  • атрибуция ASN;

  • геолокация;

  • репутация доменов и IP;

  • анализ вредоносных файлов;

  • связи между доменами;

  • обнаружение аномалий (DGA, FFN);

  • шаблоны запросов DNS.

Вот так выглядит риск-скоринг домена по версии Cisco:

WHOIS-информация и геолокация:

Семплы, собранные Cisco AMP Threat Grid и ассоциированные с данным хостом, приведены ниже и кликабельны внутри дашборда:

Можно сразу провести анализ по хешу:

В части работы с логами в SIEM вас ждет разочарование: выгрузка логов возможна с задержкой в 10 мин только в Amazon S3 bucket, а уже оттуда в SIEM.

Итоги

С момента покупки OpenDNS Cisco неплохо прокачала функционал этого решения и добавила много новых фич: веб-прокси, CASB, отправка файлов на анализ в песочницу. Решение занимает нишу защиты от угроз со стороны интернета и ограничения доступа к внешним ресурсам. Архитектура позволяет использовать решение как для удаленных, так и для on-site пользователей.

Полезные ссылки
Подробнее..

Как мы мониторили киберполигон Positive Technologies Standoff

23.12.2020 16:22:50 | Автор: admin
Каждый год мы с друзьями ходим в баню. Каждый год, когда наши большие друзья, компания Positive Technologies проводит свое глобальное мероприятие для настоявших экспертов в области информационной безопасности PHDays. И каждый год мой друг и коллега Алексей Лукацкий говорит мне Миша, давай что-нибудь технологическое сделаем!. А потом выясняется, что заваленный рутиной, я опять все пропустил. Но этот год, как мы все уже заметили, глубоко особенный. И вместо PHDays было проведено очень эффективное и масштабное мероприятие под названием Standoff. В этот раз я решил послушать Алексея Викторовича и успеть что-то сделать! Тем более, что мероприятие существенно превосходило все, что когда-либо делалось ранее. Посмотреть детали этого впечатляющего киберполигона можно вот тут: https://standoff365.com/battlefield.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам свои навыки обнаружения и отражения угроз.

Итак, возник вопрос, как же нам понаблюдать за этой битвой, с точки зрения информационной безопасности? Собственно, эта статья именно о подробностях построении такого процесса наблюдения и полученных нами результатах.

Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA Network Traffic Analytics) это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и бесшовнее, чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и обучиться за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее шумными с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание на вот такой материал:
http://personeltest.ru/aways/habr.com/ru/company/cisco/blog/348532/

Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово просто и теперь попробую развернуть его подробнее.

Итак, как же выглядит процесс?

Надо запросить триалку, это занимает пару минут.
Ссылка тут:
https://www.cisco.com/c/en/us/products/security/stealthwatch/stealthwatch-cloud-free-offer.html?dtid=osscdc000283

Потом, в течение пары дней начинают приходить разные полезные письма и в конце концов приходит письмо про то, что портал активирован!
После этого получаешь себе личный портал, ссылка на который выглядит так:

cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.

Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги:
https://ebooks.cisco.com/story/swc-sensor-install/
Сразу скажу, что у сенсора есть два интерфейса один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.

После установки сенсор бежит в облако, где размещена консоль это на самом деле AWS и выдает прекрасное сообщение:
{error:unknown identity,identity:185.190.117.34}

Это тот самый IP адрес, под которым сенсор считает, что видит себя во внешнем мире, пробившись через корпоративный межсетевой экран, трансляцию адресов и т. п. На всякий случай, сразу скажу, что сенсору нужен HTTP и HTTPs, а также настройка DNS-а. После получения указанного выше сообщения надо просто взять этот адрес и добавить его в список своих сенсоров на консоли:

image

И через некоторое время сенсор окрашивается в зеленый цвет это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт https://configurenetflow.info/

На нем мы можем выбрать нужное нам сетевое устройство, ввести пару параметров и получить готовую конфигурацию:

image

И скопировать полученную информацию на наши сетевые устройства. Все система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия например Cisco Tetration, IBM QRadar и т. п.

Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она прилагается по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут: https://www.cisco.com/c/ru_ru/products/security/securex.html

Итак, первым делом и настроил такую интеграцию:

image

Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: http://personeltest.ru/aways/habr.com/ru/company/jetinfosystems/blog/529174/

image

Особых надежд на нее я не возлагал, пологая, что все самое интересное будет происходить внутри полигона, а обеспечивать защиту этого полигона в мои задачи не входило.

После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:

image

image

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

image

Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:

image

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

Ну а теперь что же мы увидели?

В первые дни Standoff телеметрию мне отдавала парочка наших виртуальных межсетевых экранов ASAv, но потом количество источников несколько увеличилось добавилось еще межсетевых экранов, а также Netflow с центрального брокера трафика.
Первые уведомления пришли очень быстро, и, как и следовало ожидать, они были связаны с многочисленными сканированиями. Ну а потом наблюдать за процессом становилось интереснее с каждым часом. Я не буду тут расписывать весь процесс наблюдения, а просто расскажу о нескольких фактах. Во-первых, удалось собрать неплохую информацию что есть что на полигоне:

image

image

Во-вторых, оценить масштабность мероприятия с какими же странами был наиболее активный обмен трафиком:

image

На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными внешними, помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:

image

Конечно, мы могли посмотреть, кому принадлежат увиденные адреса:

image

И при желании, спросить про них у других полезных аналитических источников:

image

Что позволило увидеть, например, активное взаимодействие с ресурсами компании Microsoft во многих странах.
Причем таблицу наиболее активных взаимодействий можно было увидеть и в виде динамической картинки соединений с возможностью ее более подробного анализа:

image

Но что-же все-таки мы собрали именно с точки зрения атак?
Об этом нам рассказывает список уведомлений, часть которого вы видите ниже:

image

Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:

image

image

Итак, немного коротких выводов по результатам этого небольшого и занимательного пилота.
Первый компания Positive Technologies провела прекрасные киберучения и было очень интересно немного понаблюдать за ними изнутри, причем это было удобно, легко и просто.

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

Третий участники полигона тоже активно пользовались облачными сервисами, например сервисами компании Microsoft

Четвертый автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут: https://cisco.bravais.com/s/kCvJYJKyhuyQqAZSU6Xk.

Ну и маленький заключительный комментарий в этой статье я сознательно не стал подробно перечислять полученные списки адресов IP, доменов, детали взаимодействия и т. п., понимая, сколько усилий стоило компании Positive Technologies собрать данный полигон и надеясь, что он неоднократно пригодится им и нам и в дальнейшем. И облегчать жизнь будущим атакующим мы не будем.
Подробнее..

Как я прошел обучение в учебном центре Специалист при МГТУ им.Н.Э.Баумана по курсу CCNA Безопасность в сетях Cisco

01.03.2021 22:20:48 | Автор: admin

Здравствуй, дорогой читатель!

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

Курс представлял собой несколькочасовое занятие, часть которого состояло из вебинара, а вторая часть представляла собой практику в виде выполнения лабораторных работ.

В обучении я увидел несколько плюсов:

  • Доступность стендов;

  • Очень подробное описание лабораторных работ и команд;

  • Быстрое решение технических проблем (редко возникали);

  • Учебный материал можно оставлять себе;

  • Лабораторный стенд доступен после окончания обучения еще неделю, что дает возможность отточить полученные знания;

  • Отзывчивость преподавателя, всегда готов ответить на любые вопросы.

Из минусов могу выделить один пункт, но кому-то он может не показаться минусом:

  • Выдача сертификата/удостоверения/свидетельства без проведения тестирования на усвоения программы.

В целом, при достаточном количестве времени на выполнение лабораторных работ и закрепления материала, обучение является качественным.

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

Подробнее..

5 причин не уходить из техподдержки во внедрение

15.04.2021 18:16:38 | Автор: admin

Привет, Хабр! Несмотря на то, что информационная безопасность и все, что связано с этой сферой, сейчас на хайпе, найти инженера технической поддержки по ИБ задача непростая. Еще больше ее усложняет расхожее мнение, что техподдержка только для джунов, а более опытные специалисты должны переходить в проектную деятельность. Чтобы развенчать этот миф, подробнее расскажем о профессии и возможностях, которые она открывает.

В сервисном департаменте STEP LOGIC на двух линиях технической поддержки работает более 50 специалистов. Сейчас они обслуживают порядка 150 сервисных контрактов это более 10 тыс. инцидентов в год. Первая линия поддержки проводит классификацию обращений заказчиков и если проблему можно решить по скрипту, то закрывает заявку своими силами. Если сделать это в течение первого часа не удается или требуются дополнительные компетенции, то инцидент передается на вторую линию поддержки, инженеры которой обладают более глубокими техническими знаниями и навыками.

Как сервисные партнеры нескольких крупных вендоров, мы имеем право оказывать услуги по технической поддержке оборудования от их имени. Например, при обслуживании оборудования Cisco наши специалисты решают до 80-90% проблем самостоятельно, за помощью к вендору мы обращаемся только при гарантийной замене или обнаружении программных ошибок. Для того, чтобы вендор авторизовал партнера на предоставление совместных услуг, в штате обязательно должны быть сертифицированные инженеры, имеющие CCIE или, как минимум, CCNP. Еще два обязательных условия прохождение ежегодных аудитов на соответствие уровня услуг, требования к которым схожи с лучшими практиками ITIL, и принцип оказания технической поддержки, основанный на практиках Cisco CX Specialization.

Конечно, оптимальное решение для компаний, у которых есть локальная задача поддержки оборудования конкретного вендора, это покупка его стандартных пакетов обслуживания. У того же Cisco, например, есть варианты на разный вкус и кошелек: контракты Cisco SMARTnet или расширенная версия Solution Support, Next Calendar Day, если нужна замена оборудования в выходной или праздничный день, профессиональные услуги вендора Advanced Services (AS) и Business Critical Services (BCS), если заказчику необходим дизайн сети. Но бизнесу, в котором требования постоянно меняются, зачастую удобнее работать с компанией, которая будет жить в конкретной инфраструктуре, понимать, как она построена, в чем ее плюсы и минусы, узкие места и иметь опыт работы с технологиями разных производителей. Востребованы наши услуги и в системах высокой критичности, где нужен высокий SLA с фиксированным временем решения и круглосуточный сервис. Совместное оказание услуг часто удобно и самому производителю, так как он может не держать большой штат поддержки и сосредоточиться на основном бизнесе, не переживая при этом об уровне сервиса.

В локдаун значительно увеличилось число запросов на организацию и сопровождение VPN-каналов, Next Generation Firewall, SIEM-систем, расследование инцидентов безопасности, поэтому остро встал вопрос расширения команды инженеров по информационной безопасности на вторую линию поддержки.

Коротко портрет потенциального кандидата можно описать так: инженер, который более года работал в поддержке безопасности с оборудованием ведущих ИБ-вендоров и хорошо разбирается в сетевых технологиях.

График работы предлагаем стандартный 8 часов 5 дней в неделю. Иногда по отделу назначаются дежурства. Если ночью появилась критичная проблема, то дежурному придется подключиться и разобраться с ней. Но есть и небольшой плюс ехать никуда не нужно, специалисту выдается доступ в систему, с помощью которого он может работать удалено. Собственно, поэтому мы и не зацикливались на Москве или области, а сразу расширили зону поиска на всю Россию.

Почему возникли проблемы

  • Небольшое число подходящих специалистов. Забив перечисленные выше параметры на hh.ru, мы видим чуть более 70 человек, находящихся сейчас в поиске работы. Если бы мы искали сотрудника в московский офис, то ситуация была бы еще хуже. Для сравнения, при поиске бухгалтера сайт выдает более 1000 подходящих резюме.

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

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

5 причин обратить внимание на вакансию инженера технической поддержки

  1. Быстрый горизонтальный рост компетенций

    Минимальные начальные требования для кандидатов знание сетевых технологий, основ информационной безопасности, шифрования, принципов работы межсетевого экрана и системы предотвращения вторжений. Кроме стандартных файрволов и VPN, инженеры техподдержки работают с такими классами решений как Next Generation Firewall, SIEM, Web Application Firewall, DLP, IPS/IDS, Identity/AccessManagement, IRP/SOAR, Threat Intelligence. Это помогает развиваться не по одному направлению предметной деятельности, а более широко. Наши специалисты детально изучают оборудование ведущих ИБ-вендоров, тестируют в лаборатории его новые версии.

    Идеальный кандидат должен уметь работать в режиме многозадачности, быстро адаптироваться к изменениям и все схватывать буквально на лету. Такой темп работы позволяет быстро продвигаться по карьерной лестнице: в среднем, путь от младшего инженера техподдержки до ведущего эксперта в STEP LOGIC составляет 5 лет.

  2. Возможность стать экспертом, так как нужно "копать" глубоко

    Работа инженера внедрения заканчивается после ввода проекта в эксплуатацию. Как сотрудники техподдержки, мы можем с уверенностью заявить, что все самое интересное на этом только начинается. Техническая поддержка это не только консультации клиентов по вопросам функционирования оборудования, удаленная диагностика и настройка, решение проблем, локализация и мониторинг аварий, но и совместная работа с вендором по устранению багов, разработка планов по развитию и миграции инфраструктуры. Недавно мы приняли участие в проекте по миграции, который стал для нас своеобразным челленджем. Немного предыстории: крупный российский банк для защиты периметра продолжительное время использовал межсетевые экраны Cisco ASA. За последний год объем трафика увеличился в несколько раз, и оборудование перестало с ним справляться. Заказчик закупил межсетевые экраны нового поколения Cisco Firepower и перед ним встала задача провести максимально бесшовную замену, так как инфраструктура критическая и должна работать 24х7. Необходимо было перенести с одной ОС на другую большое количество настроек: сотни интерфейсов, тысячи правил межсетевого экранирования, сотню VPN и сделать это в короткое окно работ. Была проведена комплексная работа, включающая в себя изменение настроек маршрутизации, трансляции NAT, редистрибуции и фильтрации тысяч маршрутов, учитывающая переходные процессы с целью минимизации возможных потерь трафика.

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

  3. Развить командные навыки работы и soft skills

    Работа в техподдержке помогает развивать креативный подход к решению задач. Предположим, у заказчика перестал работать сервис по продажам через выделенный канал связи. SLA в этом случае короткий и инженер не смог быстро определить причину сбоя. Но он придумал временное решение, настроил новый шифрованный канал, выиграв таких образом дополнительное время.

    Жесткие SLA позволяют научиться работать со временем и совершенствовать стрессоустойчивость и упорство. При решении сложных проблем наши инженеры создают команды и привлекают в них представителей вендора и заказчика, то есть проявляют свои лидерские качества. При расследовании причин сбоя не обойтись без аналитического склада ума и упорства. Переговоры с заказчиками, встречи с вендорами, презентации новых решений способствуют развитию навыков делового общения.

  4. Научиться работать с технической документацией

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

  5. Усовершенствовать технический английский

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

По законам жанра дальше должен быть абзац про систему грейдов и возможностях профессионального роста. И они, действительно, есть: при желании инженер может вырасти в:

  • эксперта по классу решений или технологии

  • менеджера/сервис-менеджера/product owner по продукту или услуге

  • руководителя нового направления/услуги

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

Таким образом, если работа с оборудованием и устранение неполадок приносит радость, среди soft skills присутствует пресловутая коммуникабельность и клиентоориентированность, имеется стойкое желание развить свои технические знания и стать экспертом в конкретной области ИТ, то у вас есть веский повод обратить внимание на вакансию инженера технической поддержки.

Подробнее..

Wi-Fiв офис, на склад, завод, банк Сценарии внедренияи сборкиWi-Fiв сферы бизнеса.(Часть2)

27.04.2021 12:23:09 | Автор: admin

Оглавление

  1. Введение

  2. Wi-Fi и размер бизнеса

    2.1для малого бизнеса

    2.2для среднего

    2.3дляenterprise

  3. Сценарии примененияWi-Fiв сферах бизнеса

    3.1 Wi-Fiна заводе

    3.2Умный ритейл.Wi-Fiв магазины и ТРЦ.

    -Сеть магазинов

    -МаркетингТРЦ

    3.3Wi-Fiв отеле, ресторане, кафе.

    3.4Wi-Fiвбанках

    3.5Wi-Fiна складе

  4. Заключение

Введение

В прошлойстатьерассказ шел о технологиях и инструментах, которые внедряют вWi-Fi. Часть 2 будет о типовых сценариях внедрения. Если лень читать- проматывай(ссылка на ту же статью в блог)вниз, там будет калькулятор. Калькулятор учитывает вендора, количество точек доступа и дополнительный функционал.

Сразу оговорюсь, статья будет не только оWi-Fi6в вакууме. В каждом кейсе будет примеси других технологийи оборудования. Все статьи я составлял с помощью решений отCiscoи Aruba/Huaweiкакальтернатива.Но это не значит, что мы не найдем аналогов наZyxel.

Начнем с решений в зависимости от масштаба бизнеса. Каждый класс предприятий имеет свой подходк построение беспроводной сети.

Wi-Fi и размер бизнеса

Малый бизнес

В малом бизнесе требования к WI-Fiсетям минимальные. В офисе на20-30человек хватит1-2точек доступа.Контроллер не нужен, либо им может стать точка доступа.Если в офис приходят посетители, стоит позаботиться о гостевом доступе.Возможна интеграция склада и терминалов сбора данных через беспроводноесоединение.Кибербезопасность ограничивается антивирусами на конечном устройстве и двухфакторной аутентификацией(CiscoDuo).

Средний бизнес

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

Еще всреднем бизнесе появляется понятие кибербезопасности. Дополнительно к аутентификации добавляется межсетевой экран для анализа вирусов в трафике.В теории каждый узел может быть защищен.Вопрос: стоит ли объект защитыпотраченныхсредств.

Офис нашей компанииОфис нашей компании

В офисе любого размера есть потребность в мобильных сотрудниках.Удаленкаэкономит деньги на аренду и содержания офиса. Командировки помогают вести проект и разговаривать с сотрудниками на месте. Выезды к заказчику приближают его к покупке.Чтобы безопасно подключаться к инфраструктуре нуженбезопасный канал.CiscoAnyConnectего предоставляет.

Типовой дизайн:

Требуется подключенияWi-Fiи сетевых служб в офисе под ключ. В офисе должны быть проводная и беспроводная инфраструктура, гостевой доступ, система безопасности, унифицированные коммуникации.

Помещение 1500 м2

Кол-во сотрудников: 150 человек

Решения кейса

На уровень ядра устанавливается коммутатор доступа-Catalyst9500.

На уровне доступа-Catalyst9200.Точки доступа-CiscoAironet9117или 9120.

КонтроллерCatalyst9800-L.(может быть виртуальным)

Управление и контроль:CiscoISE(Опция)

Безопасность периметра:Firepower1010+Duo(Опция)

Продукты:CiscoDNA,Firepower+Duo+ESA/WSA,Cisco ISE, Cisco Aironet 9117.

ИнфраструктураСМБв вакуумеИнфраструктураСМБв вакууме

Enterprise

Организация

WLANна уровнебранча(офиса компании), не отличается от среднего.На глобальномуровне добавляются коммутаторы ядра иDNACenter.Enterpriseотличается от СМБпостроением кибербезопасности в компании,интеграциейбизнес-приложений(но о них мы поговорим в другой статье)и повышенной отказоустойчивостью.

Так может выглядетьIT-инфраструктураEnterpriseТак может выглядетьIT-инфраструктураEnterprise

ВEnterpriseсегментекибербезопасность более актуальна,чем в среднем бизнесе.Точекпроникновения злоумышленниковбольше, чем в среднем бизнесе.Цена ошибкивыше. Стоимость простоя региональнойсети магазиновможетдостигатьсотен миллионов рублей.

Категории средств безопасности:

  • Сканеры уязвимости

  • SIEM-системы

  • Защита приложений

  • WebApplicationFirewall

  • CDN

Каждая категория закрываетпотребностьEnterpriseв безопасности.Но эта статья больше для СМБ, поэтому не будем углубляться вподробностирешенийдля большого бизнеса.

Сценарии применения Wi-Fi в сферах бизнеса

Описание сценариев применения будет по принципу.

  • Типовой дизайн предприятия сценария

  • Технологии для решения задач сценария

  • Решения кейса

  • (Иногда) Схема исполнения

Все описанныесценарии- общее среднее по сфере бизнеса. Типовые проблемы, которые мы часто встречаем у заказчиков, описаны ниже.

Каждый бизнес особенный, и кейс может отличаться от Вашего.

Wi-Fi на заводе

Wi-fiсеть на заводе строится по подобию складской сети. Разница в производственной линии и более агрессивной среде.

Типовой дизайн:в промзоне размещенарматурныйзавод.Управление завода намерено внедритьтерминалы сбора данныхдлямаркировкиконечной продукции. На территории цеха отсутствует беспроводная сеть- ее нужнопостроить с нуля. Финансовые потери от 1 дня простоя составляютот10до 80млн рублейв зависимости от контракта.

Стандартный вид производственного предприятия изнутриСтандартный вид производственного предприятия изнутри

Применимые технологии:

Задача похожа на организациюWi-Fiна складе, с важным отличием. Есть производственная линия, управляемая промышленными ПК. Терминалы сбора данных, вместе с высоким темпом производства нагружают беспроводную сеть. Высокая цена простоя требует вложений в кибербезопасность.

Основной акцент делается на непрерывности производственного процесса.

Риски прерывания по частиITинфраструктуры:

  • Прерывание сигналовIOTустройств из-за перекрытий и чугунного оборудования

  • Физическое повреждениеIT-оборудования

  • Остановка процессов вследствие вредоносного ПО и хакерской атаки

Направленные антенны

Электромагнитные помехи, изоляционные материалы, плотные перекрытия, балки, опоры мешают распространениюWi-Fiсигнала. Без направленной антенны сигнал потеряется.ТехнологияBeamFormingподойдет для агрессивной среды завода.

Wi-Fi антенна (не в вакууме)Wi-Fi антенна (не в вакууме)

Кибербезопасность

Атака на производственную цепь- цель для злоумышленников.Основные цели- бизнес-данные,энергоснабжение, АСУ-ТП.Отвязать сеть, возможно, лучшее решение для безопасности производственного цикла. Все управление производством сводится к1-2ПК. На них установлены специальное ПО управления.

Атака на производственные процессы может проходить не впрямую на ПК управления. А через офис. Фишинговая рассылка может быть адресована в центральный офис компании, а затем прислана директору завода. Поэтому для защиты сети нужен мониторинг трафика.

Задача безопасностисводится к безопасности этихпромышленныхПК и смежных устройств.Фаерволлы, Многофакторная аутентификация и анализ трафика сети обезопасят промышленную сеть.

Пример использования:

Складское помещение нуждается в бесперебойномwi-fi.Работа на территории ведется в 3 смены. Стоимость простоя:10 млн. руб./сутки.

Одноэтажное здание

Площадь: 20000 м2

Кол-во ТСД: 20шт.

Кол-во ноутбуков15шт.

Решения кейса

На уровень ядра устанавливается коммутатор доступа-Catalyst9400.

На уровне доступа-Catalyst9200.Точки доступа-CiscoAironet9117с внешнимиантенами.

Промышленные коммутаторы:CiscoIE1000с защищенными портамиTACACS(Опция)

Контроллервотказоустойчивой конфигурации(может быть виртуальным).

Управление и контроль:CiscoISE(Опция)

Безопасность периметра:Firepower+Duo(Опция)

Продукты:

Cisco:МаршрутизаторCisco ISE(Опция),МСЭFirepower+Duo,КонтроллерточекдоступаWiFiC9800-40-K9,точкидоступаCisco Aironet 9117 Out-Door.

Huawei:USG6320,КонтроллерHuawei AC6508,точкидоступаAirEngine6760X1

Aruba:КонтроллерMobility Conductor Hardware Appliance,точкидоступа518 Series,управлениеAruba Central

Умный ритейл. Wi-Fi в магазинах и ТРЦ

Wi-Fiв ритейле использует службы склада, создает гостевой доступдля посетителейи служит для маркетинговых исследований иуведомлений.Wi-Fiмаркетинг, наверное, единственное применение технологии, которое может приносить прямую прибыль компании. ФактическиWi-Fiвмагазинеили в офисе продаж являетсяобразующейтехнологией.Склад магазина использует терминалы сбора данных, они беспроводные.

Сеть магазинов

Кейс: сетьпродуктовыхмагазиновне имеет беспроводной сети в каждой точке продаж. Проблемы недочета товарапривели к модернизации системы склада ивнедрению терминалов сбора данных (ТСД). Каждый ТСД требует подключения к беспроводной сети,значитв каждой точке продаж должен быть местныйWi-Fi.

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

Может выглядеть такМожет выглядеть так

Технологии и средства

Виртуальный контроллер

WLC(Опция)

(WirelessLocalController)может контролировать разветвленные сети, вроде той, что в кейсе. Основныепроблемыв управлении такими сетями:

  • нехватка информации о магазине(качество покрытия,загруженность устройств, безопасность в сетях, время на устранение ошибок и их кол-во)

  • Отдельные дорогостоящие специалисты на конечныхточках (магазины, офисы ит.п.)

  • Увеличение человеко-часов на обслуживание инфраструктуры как в магазине, так и в центральном офисе

WLC управляет всеми точкамидоступаизцентра управления. Центр управления это веб-интерфейсы, или CLI с которого администратор управляет параметрами каждой подключенной точки.

DNA(Опция)

DNAуправляет всеми сетевыми устройствами, чего не может сделать WLC. Этовиртуальные маршрутизаторы, коммутаторы, межсетевые экраны,контроллеры точек доступа и сами точки доступа.

Вот как выглядит пункт управления DNAВот как выглядит пункт управления DNA

Обычно DNA внедряется как подспорье раздутомуштатуинженеров.Однако внедрение DNA- дорогостоящий процесс.

Система по своим характеристиками и цене подходит среднему иEnterpriseбизнесу.

Продукты:

Cisco:МСЭFirepower 2100,контроллерКонтроллерWiFiC9800-40-K9(может быть виртуальным),точкидоступаCatalyst 9113, DNA(возможно).

Huawei:МСЭUSG 6320,КонтроллерHuawei AC6508,точкидоступаAirEngine8760-X1

Aruba:КонтроллерMobility Conductor Hardware Appliance,точкидоступа515 Series,управлениеAruba Central

МаркетингТРЦ

Кейс: Маркетинговый отдел торгового центра Юпитер сообщил о снижении спроса на продукцию. Маркетологи сошлись во мнении, что посетители хотят более индивидуального подхода. Было принято решение внедрить систему умногоWi-Fiивидеоаналитики.

WI-Fiзона в ТРЦWI-Fiзона в ТРЦ

Решение:

Технологии трекинга на территории магазина появились4-5лет назад.Последние 2 года маркетинг активно внедрял эти технологии. И сейчас Вы наблюдаете их у себя в уведомлениях на телефоне.

Эта связка дает информацию:

  • о поле

  • возрасте

  • предпочтениях

  • семейном положении

  • покупательской способности

В умелых руках эти инструменты продают посетителю те товары, которые, возможно, хочет купить покупатель.

Пример: В середине зимы вы пришли в торговый центр, в котором уже были раньше. После 10 мин прогулки в таком центре, на телефон приходитpush-уведомление магазина N с предложением купить пальто по скидке. Система предложила пальто, по нескольким причинам.

1.Скоро будет весна

2. Вы уже покупали в магазине N одежду

3. Вы даже примеряли пальто в магазинах конкурентов.

Точки доступа поддерживаютBluetoothТочки доступа поддерживаютBluetooth

Каждаякрупицаинформации- процентквероятности покупки. Как только количество информации наберет критическую массу произойдет продажа.

Точность предложения, зависит от количества информации о покупателе. Никто не любит, когда "впаривают" ненужный товар. Системы аналитики на базеwi-fiсделают предложение точнее.

Продукты:

Cisco:МСЭFirepower 2100,контроллерКонтроллерWiFiC9800-40-K9(может быть виртуальным),точкидоступаCatalyst 9130,DNA(Опция), Duo(Опция).

Huawei:МСЭUSG6320,КонтроллерHuawei AC6508,точкидоступаAirEngine8760-X1

Aruba:КонтроллерMobility Conductor Hardware Appliance,точкидоступа530Series,управлениеAruba Central

Wi-Fi в отеле, ресторане, кафе (HoReCa)

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

По факту,внедрение передовых технологий вотель- имиджевый вопрос.ХорошееWi-Fiсоединение воспринимается пользователями как стандарт, а не как дополнительное удобство.

Типовой дизайн(на примере гостиницы):

Для гостиниц характерна разветвленная сетьwi-fiточек. Так как каждый номер должен быть покрытWi-Fiсигналом, сетьпотребность в большом количестве точек.На территории отеля нет посторонних точек, значит нет конфликтамежду сигналами,интерференциии пр. Есть только большое количество перекрытий и стен.

Типовой дизайн этажа гостиницыТиповой дизайн этажа гостиницы

Технологиии сферы применения:

ГостеваяWi-Fiсеть отеля

Гостевой беспроводной сети уделяют особое внимание. Гости приезжают на командировку, по работе, или в качестве фрилансеров. Оставлять их без качественнойWi-Fiсети- удар по репутации. Вряд ли они вернутся при следующей поездке или порекомендуют отель друзьям, если сеть будет прерываться и мешать работе.

BeamForming

Поможет преодолеть стены между номерами.BeamFormingусиливает слабый сигнал, в частности, для преодоления стен.Следовательно, чтобы покрыть всю площадь сигналом, потребуется меньше точек доступа.

BSSColoring

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

IOTи умное управление отелем(Опция)

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

Управление:

  • освещением, влажностью,отоплением

  • датчики движения

  • сетью, розетками

  • электронными дверьмии окнами

  • IOT-техника (умные пылесосы, колонки, телевизоры ит.п.)

Таким образом обслуживание зданием можно управлять из дома. Это ведет к снижению затрат на инфраструктуру.

Авторизация пользователейи гостевой портал

В последнее время стали популярны гостевые порталы. На гостевом портале пользователь может заказать еду в номер, подключить каналы на ТВ и забронировать время на лечебные процедуры.Пользователи заходятна портал повнутреннейсетигостиницы, без подключения к интернету.

Есть далеко не во всех отеляхЕсть далеко не во всех отелях

Пример использования:

Отель 5Season7-х этажноездание. В здание проведен10-гигабитный интернет, но ссамого начала модернизации, постояльцы жаловались на плохойWi-Fi.В конечном счете,руководство приняло решение модернизировать беспроводную сеть отеля.Тем более, что появились технологии умного управления отелем.Это внедрение повысит статус отеля среди конкурентов.

Кол-во номеров: 110шт.

Кол-воIOTустройств-2000 единиц

Решения кейса

На уровеньдоступаустанавливаются2коммутатора-Catalyst9400встэке.

На уровне доступана каждый этаж устанавливается коммутаторыCatalyst9300.Точки доступа-CiscoAironet9120сфункциейCleanAir.

Контроллер9000в отказоустойчивой конфигурации(может быть виртуальным).

Управление и контроль:CiscoISE

Безопасность периметра:Firepower2100.

Продукты:

Cisco:МСЭFirepower2100,контроллерКонтроллерWiFiC9800-40-K9,точкидоступаCatalyst9120,DNA(Опция),ISE,Duo(Опция).

Huawei:МСЭUSG6320,КонтроллерHuawei AC6508,точкидоступаAirEngine8760-X1

Aruba:КонтроллерMobility Conductor Hardware Appliance,точкидоступа550Series,управлениеAruba Central

Финансовый сектор

Под эту категорию попадают банки, компании-брокеры,финтехстартапы. Поотчетув IV квартале2020гогода совершено 29 преступлений в финансовом секторе. Главные объекты атаки- сетевое оборудование (26 из 29 атак).

Банковский залБанковский зал

Чтобы обезопасить компанию от хакеров, стоимость взлома должен бытьвысокой. Чем больше времени, денег, человеческих ресурсов потратит хакер, тем вероятнее, что взлом не случится.Без сомнения,это самый эффективным способ защиты.

В 95% банках установленwi-fi, но только 23% используютдополнительныесредства безопасности. Дополнительные средства безопасности это- песочницы, многофакторная аутентификация, анализ поведения пользователей, мониторинг сетевой активности. Каждый из перечисленных пунктов делает дорожеценувзлома.

Дизайн сети

Сетевая топология- тоже способ построить безопасность.Не будем заострять внимание на высоте монтажа точек.

Существуют требования к дизайну сети:

  • Выделение специальных зон для гостевого доступа

  • Разные права доступа гостевого и офисного доступа

  • Подавление сигнала за пределами зон

Для безопасности сети на каждом узле должна быть своя защита. На уровнекоммутатора- политика управления портами, на уровне контроллера- построение политики подключения, на уровне файрволла- аналитика поведения пользователей и аутентификация.

Так выглядит подключенные IT-продукты в банковской сфере 2019 годаТак выглядит подключенные IT-продукты в банковской сфере 2019 года

Более подробно о средствахзащиты

Песочницы

Термин не совсем правильный в рамкахWi-Fi, но раскрывающий суть. В сети создается промежуточная зона, сSSL(или другой) сертификацией.Любойвредоносповредит только виртуальную машину, на которой размещены ПО и данные.Оригиналы же будут не тронуты.

(Более подробныйответесть уKaspersky)

Шифрование потоков данных/Мониторингзашифрованного трафика злоумышленник может перехватить данные вwi-fi.Это может быть инсайдерская информация или имена доверенных лиц, которые он потом использует. Чтобы не допустить утечки, данные должны шифроваться.Шифрование происходит на уровне точек доступа и контроллера. Никакого дополнительного ПО не нужно.

Многофакторная аутентификацияИЛИ авторизация- распространенный способ защиты сетей. Простой принцип действия- любой, кто заходит в сеть, подтверждает личность генерируемым паролем, письмом илибиометрией. Способов идентификации много.

Аналитика поведения пользователей

Системы анализа пользователей в сети, пока чтоbest-practiceв мире сетевой безопасности. Сложность обмана такой системы стоит дорогов расчете денег и человеческих ресурсов.

Принцип действия систем поведенческой аналитики-

Создается образ посетителя сети, который наделяется определенными параметрами (их очень много).

  • Частота (ГГц)

  • Фреймы

  • Количество

  • Используемые приложения

  • Базовая скорость

  • Скачки триангуляции

  • И многое, многое другое (см. документацию)

Стандартный посетитель сети находится в допустимых пределах. Как только пределы нарушены, системаищет паттерны злоумышленникаили вредоносного ПО. В случае совпадения пользователь блокируется.

Продукты:

Cisco:МСЭFirepower2100,контроллерКонтроллерWiFiC9800-40-K9(может быть виртуальным),точкидоступаCatalyst9120,DNA,ISE(Опция),Duo,WirelessIPS(Fortigate)илиCyberThreatDefense,CiscoDNA(Опция),CiscoUmbrella(Опция),ESA/WSA(Опция),SecureX(Опция).

Huawei:МСЭUSG6320, КонтроллерHuaweiAC6508,точкидоступаAirEngine8760-X1

Aruba:КонтроллерMobility Conductor Hardware Appliance,точкидоступа550Series,управлениеAruba Central

Wi-Fi на складе

Типовой сценарий:

Высокие стеллажи спаллетамитовара, высокие потолки, высокое содержание пылии влажности делают распространения сигнала сложным и неравномерным. Зимой неотапливаемые склады страдают от влажности и низких температур.

К складскойWi-Fiсети подключаются терминалы сбора данных, сканеры штрихкодов и ноутбуки.Каждый терминал или ноутбук обращаются к базам данных и бизнес-приложениям.

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

Классическая картина на складеКлассическая картина на складе

Проблема решается комплексно

Защита от помех и высокоскоростные точки доступа.

У вендоров уже появились точки доступа с защитой от помех.Например,уCiscoэтоCleanAir.Технологиянаходит источник(и) помех и перенастраивает сеть для лучшего сигнала.

Управление политиками доступа.

У ТОП производителей точек доступа есть контроллеры с дополнительным ПО, для управления.Платформы управления могут автоматически управлять и балансировать точки доступа.

Правильное расположение точек доступа.

Даже6йстандарт не обойдет стеллаж толщиной в 3 метра. Только правильное расположение точек доступа покроет сигналом весь склад.

Чтобыузнатьгде сигнал ловит хуже, нуженпредиктивныйанализ. Есть несколько способов исполненияпредиктива.

Первыйспособ- без выхода на местность.

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

Второй способ-с выходом на местность.

На территории предприятия устанавливаются тестовые точки доступа. Далее инженер ходит сWi-Fiантеннойпо территории склада и проверяет уровень сигнала. Преимущество метода в высокой точности, так как покрытие проверяется на практике.

Так выглядит планпредиктиваТак выглядит планпредиктива

Пример использования:

Складское помещениенуждается в бесперебойномwi-fi.Работа на территорииведется в 3 смены. Стоимость простоя: 150k$/сутки.

Одноэтажное здание

Площадь: 25 000 м2

Кол-во ТСД: 25шт.

Кол-во ноутбуков 20 шт.

Решения кейса

На уровеньдоступаустанавливается коммутатор доступа-Catalyst9400.

На уровне доступа-Catalyst9200.Точки доступа-CiscoAironet9117с внешнимиантеннами.

КонтроллерWiFiC9800-40-K9(может быть виртуальным)в отказоустойчивой конфигурации.

Управление и контроль:CiscoISE(Опция)

Безопасность периметра:МСЭFirepower2100.

Так может выглядеть инфраструктура на складеТак может выглядеть инфраструктура на складе

Продукты:

Cisco:МСЭFirepower1100,контроллерКонтроллерWiFiC9800-40-K9,точкидоступаAironet1560,ISE,Duo,CiscoDNA.

Huawei:МСЭUSG6320, КонтроллерHuaweiAC6508,точкидоступаAirEngine6760-X1E

Aruba:КонтроллерMobility Conductor Hardware Appliance,точкидоступа513Series,управлениеAruba Central

Калькулятор есть в статье в блоге

В этомкалькуляторе подобраныминимальные позициипо которым, можно примерно понятьот какой цены начинается внедрение WI-Fi.

Заключение

В этих двух статьях я постарался широкими мазкамиописатькак и куда внедряетсяWi-Fi.

Статья не освещает каждую сферу глубокои не стоит читать ее как руководство.Чтобыподобратьрешения под конкретный случай пишите нам наzakaz@olly.ru

Подробнее..

Сам сломаю, сам и починю как я эпически нажал не туда на проде

14.04.2021 10:21:24 | Автор: admin
Привет, Хабр!

Про такие ошибки обычно говорить не принято, потому что во всех интеграторах работают только безгрешные небесноликие люди. У нас, как известно, на уровне ДНК отсутствует возможность ошибаться или быть неправыми.

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

Начинается история так: заказчик хочет перенести на эту группу коммутаторов ядро всей сети. Такое решение обусловлено тем, что архитектура ACI, в которую собрана эта группа коммутаторов очень отказоустойчивая. Хотя это не типично и в целом фабрика в любом ЦОД не используется как транзитная сеть для других сетей и служит только для подключения конечной нагрузки (stub network). Но такой подход вполне имеет место быть, поэтому заказчик хочет мы делаем.

Дальше произошло банальное я перепутал две кнопки: удаления политики и удаления конфига фрагмента сети:

image

Ну а дальше по классике нужно было собрать заново часть развалившейся сети.

По порядку


Запрос заказчика звучал так: нужно было построить отдельные порт-группы под перенос оборудования непосредственно на эту фабрику.
Коллеги, просьба перенести настройки портов Leaf 1-1 101 и leaf 1-2 102, порты 43 и 44, на Leaf 1-3 103 и leaf 1-4 104, порты 43 и 44. К портам 43 и 44 на Leaf 1-1 и 1-2 подключён стек 3650, он пока не введён в эксплуатацию, переносить настройки портов можно в любое время.

То есть они хотели перевести кластер серверов. Нужно было настроить новую виртуальную порт-группу под серверное окружение. По сути дела, это рутинная задача, простоя сервиса на такой задаче обычно нет. По сути своей порт-группа в терминологии APIC это VPC, который собирается из портов находящихся физически на разных коммутаторах.

Проблема в том, что на фабрике настройки этих порт-групп привязаны к отдельной сущности (которая возникает вследствие того, что фабрика управляется с контроллера). Этот объект называется port policy. То есть к группе портов, которые мы добавляем, нужно ещё сверху применить общую политику как сущность, которая будет управлять этими портами.
То есть нужно было сделать анализ, какие EPG используются на портах 43 и 44 на нодах 101 и 102 для того, чтобы собрать аналогичную конфигурацию на нодах 103-104. После анализа необходимых изменений я начал настраивать ноды 103-104. Для настройки нового VPC в существующей политике интерфейсов для нод 103 и 104 нужно было создать политику, в которую будут заведены интерфейсы 43 и 44.

И там есть в GUI один нюанс. Я создал эту политику и понял, что в процессе конфигурирования допустил незначительную ошибку, назвал её не так, как принято у заказчика. Это не критично потому что политика новая и ни на что не влияет. И мне эту политику нужно было удалить, поскольку изменения в неё уже внести нельзя (название не меняется) можно только удалить и заново политику создать.

Проблема в том, что в GUI есть иконки удаления, которые относятся к политикам интерфейса, а есть иконки, которые относятся к политикам коммутатора. Визуально они почти идентичны. И я вместо того, чтобы удалить политику, которую я создал, удалил всю конфигурацию для интерфейсов на коммутаторах 103-104:

image

Вместо удаления одной группы фактически удалил все VPC из настроек ноды, использовал delete вместо trashbin.

В этих каналах были VLAN, чувствительные для бизнеса. По сути дела, после удаления конфига я отключил часть сетки. Причём это было не сразу заметно, потому что фабрика управляется не через ядро, а у неё отдельный менеджмент-интерфейс. Меня не выкинуло сразу, не произошло какой-то ошибки на фабрике, поскольку действие было предпринято администратором. И интерфейс считает ну если вы сказали удалить, значит так надо. Никакой индикации ошибок не было. ПО решило, что идёт какая-то реконфигурация. Если админ удаляет профиль leaf, то для фабрики он перестаёт существовать и она не пишет ошибки о том, что он не работает. Он не работает потому что его целенаправленно удалили. Для ПО он и не должен работать.

В общем, ПО решило, что я Чак Норрис и точно знаю, что делаю. Всё под контролем. Админ не может ошибаться, и даже когда он стреляет себе в ногу это часть хитрого плана.

Но примерно через десять минут меня выкинуло из VPN, что я поначалу не связал с конфигурацией APIC. Но это как минимум подозрительно, и я связался с заказчиком, уточнить, что происходит. Причём следующие несколько минут я думал, что проблема в технических работах, внезапном экскаваторе или сбое питания, но никак не конфиге фабрики.

У заказчика сеть построена сложно. Мы по своим доступам видим только часть окружения. Восстанавливая события, всё похоже на то, что началась ребалансировка трафика, после чего через несколько секунд динамическая маршрутизация оставшихся систем просто не вывезла.
Тот VPN, на котором я сидел, это был админский VPN. Обычные сотрудники сидели с другого, у них всё продолжало работать.

В общем, ещё пара минут переговоров ушла на то, чтобы понять, что проблема всё же в моём конфиге. Первое действие в бою в такой ситуации сделать роллбек на прошлые конфиги, а только потом уже читать логи, потому что это прод.

Восстановление фабрики


На восстановление фабрики с учётом всех звонков и сбора всех причастных ушло 30 минут.

Нашли другой VPN, через который можно зайти (это потребовало согласования с безопасниками), и я откатил конфигурацию фабрики в Cisco ACI это делается в два клика. Ничего сложного нет. Просто выбирается точка восстановления. Занимает это 1015 секунд. То есть на само восстановление ушло 15 секунд. Всё остальное время было потрачено на то, чтобы понять, как получить удалённое управление.

image

После инцидента


Ещё день мы разбирали логи и восстанавливали цепочку событий. Потом собрали звонок с заказчиком, спокойно изложили суть и причины инцидента, предложили ряд мер, чтобы свести к минимуму риски подобных ситуаций и человеческого фактора.
Договорились, что конфиги фабрики мы трогаем только в нерабочие часы: ночное и вечернее время. Проводим работы обязательно с дублирующим удалённым подключением (есть рабочие VPN-каналы, есть резервные). Заказчик получает от нас предупреждение и в это время наблюдает за сервисами.

Инженер (то есть я) на проекте остался тот же. Могу сказать, что по ощущениям доверия ко мне стало даже больше, чем до инцидента думаю, как раз потому что мы быстро сработали в ситуации и не дали волне паники накрыть заказчика. Главное не пытались спрятать косяк. По практике я знаю, что в этой ситуации легче всего попытаться перевалить на вендора.
Похожие политики работы с сетью мы применили и к другим заказчикам на аутсорсе: это тяжелее для заказчиков (дополнительные VPN-каналы, дополнительные смены админов в нерабочие часы), но многие поняли, зачем это нужно.

Так же мы покопались глубже в ПО Cisco Network Assurance Engine (NAE), где нашли возможность сделать на фабрике ACI две простые, но очень важные вещи:

  • первое NAE позволяет сделать анализ планируемого изменения, еще до того, как мы его выкатили на фабрику и отстрелили себе все, спрогнозировав как позитивно или негативно изменение скажется на существующей конфигурации;
  • второе NAE уже после изменения позволяет измерить общую температуру фабрики и увидеть как это изменение в конечном счете повлияло на состояние ее здоровья.

Если интересно больше деталей у нас завтра вебинар про внутреннюю кухню техподдержки, будем рассказывать, как всё устроено у нас и у вендоров. Ошибки тоже будем разбирать)
Подробнее..

WI-FI 6 ЧТО ЭТО? КАКИЕ СЕРВИС ПОДКЛЮЧАТЬ? СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ (ЧАСТЬ 1)

15.04.2021 16:11:54 | Автор: admin

ЧТО ЖЕ ТАКОЕ WI-FI 6 И ЧЕМ ОН ЛУЧШЕ ПРОШЛХ ФОРМАТОВ

Резюме

Wi-Fi 6 (или802.11 ax) новый стандарт беспроводных сетей. Новый формат, который создавался с целью исправить баги прошлых стандартов. К 2021му году у WiFi накопилось достаточно нерешенных проблем.

  • Конфликт между точками Wi-Fi

  • Разрыв сигнала с точкой

  • Однопоточность сигнала. 1 сигнал 1 устройство

  • Энергопотребление

Wi-Fi 6 создавался для решения этих проблем.

ОТЛИЧИЯ WI-FI 6 ОТ СТАРХ ФОРМАТОВ

Новые технологии решают недостатки прошлых стандартов. Ниже подробный список.

MU-MIMO

Что решает:Проблема конфликта точек Wi-Fi

Как действует:у точки доступа/роутера может быть не одна антенна. Из-за большого количества антенн устройства могут конфликтовать друг с другом. Такие конфликты ведут к разрывам сигналов и сбоям обмена информации. MU-MIMO дает каждому устройству свою собственную антенну.

OFDMA

Что решает:Проблема однопоточности

Как действует:до выхода Wi-Fi 6 точки доступа отправляли пакеты данных по очереди. Если в сети было больше 5 устройств это могло нивелировать широкополосный интернет. OFDMA одновременно делит сигнал между всеми устройствами. Каждое устройство получает столько трафика, сколько требуется.

Пример:В конференц-залах возможны сотни устройств в одной сети. В прошлых стандартах трафика бы не хватало, потому что есть большая очередь из устройств. OFDMA разобьет трафик по всей очереди, тем самым решив проблему.

BSS COLORING

Что решает:Конфликт между точками / конечными устройствами

Как действует:Точка доступа окрашивает сеть. Устройства, которые подключаются к сети видят только свои точки доступа. Таким образом точка доступа отличает свои устройства от чужих, тем самым, решает проблему конфликта точек.

Пример:В торговом центре может быть настоящий зоопарк точек доступа и тем более конечных устройств (мобильных телефонов, планшетов, смарт-часов и т.п.) В сети регулярно пополняется список подключенных устройств. Устройства, которые подключались ранее могут конфликтовать с соседними точками. BSS coloring решает эту проблему.

TARGET WAKE TIME (TWT)

Что решает:Энергопотребление

Как действует:как только точка перестает использоваться, она сразу переходит в режим ожидания. Если у конечных устройств нет постоянных фоновых процессов, экономия электроэнергии может достигать 90%.

Пример:Wi-Fi на складе затратнее, чем может казаться. Чтобы избежать интерференции сигнала из-за преград (стеллажи, полки, грузы) приходится увеличивать количество точек доступа. Конечные устройства используются только в момент погрузки/разгрузки и изменения положения товара, все остальное время сеть простаивает. Это неминуемо ведет к пустому расходу энергии. Для таких сценариев и создавался (TWT)

BEAM FORMING

Что решает:Разрыв сигнала с точкой

Как действует:Точка доступа направляет сигнал в сторону конечного устройства. Из-за преград сигнал может ослабевать или теряться.

Пример:В офисе может быть большое количество кабинетов. Ставить в каждом Wi-Fi точку экономически невыгодно, но и оставлять людей без сети, тоже не имеет смысла. Пара точек Wi-Fi 6 точек доступа могут закрыть потребность всего офиса.

Чуть более сложно, зато наглядно, это описано в видео. Кликай.

ЧТО УСТАНОВИТЬ ПОВЕРХ WI-FI 6

Теперь поговорим о сценариях использовании Wi-Fi 6 и о внедряемых сервисах. Сейчас существует огромный выбор решений, которые упрощают жизнь бизнесу. Мы разобьем их на подкатегории

  • Маркетинг

  • Склад

  • Производство

  • Управление

  • Безопасность

В следующей статье мы будем собирать готовые решения под каждый тип бизнеса.

МАРКЕТИНГ

Большинство решений предназначено для отслеживания позиции потенциального заказчика. Инструменты, которые внедряются поверх Wi-Fi, помогают определить профиль заказчика.

Аналитика потребительских привычек

Такие решения внедряются в магазины и торговые центры. На территории размещения wi-fi, строится тепловая карта. Красные зоны показывают самые посещаемые места. Далее можно использовать эти данные для более точного размещения торговых точек.

Профилирование клиента

На основании посещаемости маркетинговых зон, системы аналитики могут профилировать заказчика. Т е предоставлять рекламные акции, интересные только определенному профилю заказчика.

К примеру: женщине 30-45 лет, которая большую часть времени была возле магазинов мебели, могут быть интересна реклама товаров для дома и ремонта квартиры.

Wi-Fi ловушки

После того, как профиль посетителя создан можно отправлять ему актуальную рекламу и опросы. Специальное ПО позволяет рассылать рекламные уведомления или показывать промо ролики, при аутентификации в сеть.

СКЛАД

Решения Wi-Fi для склада полностью раскрываются только в паре с IOT устройствами. Склад всегда считается Серой зоной любого бизнеса из-за регулярных потерь/недочёта товаров. Для получения контроля над складом существует WMS решения

WMS (Warehouse Management System)

Такие системы позволяют вести учет и мониторить склад.

Возможности WMS систем:

  • Интеграция с CRM

  • Рекомендации к позиционированию грузов в рабочем пространстве

  • Интеграция со службами логистики

  • Управление человеческими ресурсами

В данном случае Wi-Fi является фундаментом, на котором будут размещаться такие решения.

УПРАВЛЕНИЕ

Целый массив решений помогает компаниям управлять персоналом.

Системы RTLS (Real-time Locating Systems) на базе Wi-Fi

Системы предназначены для отслеживания людей или объектов на исследуемой территории. Данная технология может работать вместе с инфракрасными или ультразвуковыми датчиками.

Формирование корпоративных политик

Корпоративные политики могут мониторить трафик и регистрировать посещение сторонних сайтов и ресурсов. Если работник посещает сайт конкурента или биржи по поиску работы, система это зарегистрирует.

Еще можно предотвратить утечку корпоративных данных, отслеживать геопозицию и блокировать устройство, в случае потенциально-опасных действий.

БЕЗОПАСНОСТЬ

Защищенный доступ к корпоративным сетям

Корпоративная Wi-Fi сеть может стать точкой атаки злоумышленников. Одного пароля на вход может быть недостаточно. ИБ решения на базе двухфакторной аутентификации добавляют трудностей злоумышленникам. Увеличение стоимости взлома является самым эффективным средством защиты.

Предиктивная аналитика угроз

У каждой кибер- угрозы есть признаки и сигнатуры. Для того чтобы находить вредоносное ПО внутри Wi-Fi сети инженеры придумали приложения для анализа угроз. Эти приложения подключаются к потоку данных и, с помощью нейронных сетей, анализируют поведение пользователей.

В СЛЕДУЮЩЕЙ ЧАСТИ

В следующей части мы обсудим готовые решения на базе WI-FI 6 для разных сценариев и типов и размеров кампаний

Подробнее..

Перевод MPLS L3VPN поверх DMVPN

23.04.2021 18:05:42 | Автор: admin

Кросспостинг, оригинальная публикация

DMVPN является известным решением для построения топологий hub&spoke. В ряде случаев может понадобиться поддержка изолированной передачи трафика различных клиентов. Конечно, можно построить DMVPN туннель в каждом VRF; однако в реальной жизни такой подход не является достаточно масштабируемым. В такой ситуации на ум приходит MPLS, который зарекомендовал себя в корпоративных и провайдерских сетях.

GRE поддерживает инкапсуляцию различных PDU, в том числе и MPLS, поэтому, на первый взгляд, не должно возникнуть проблем на уровне передачи трафика. С управляющими протоколами, однако, ситуация обстоит несколько сложнее. LDP и RSVP должны установить соседство перед тем, как обменяться какими-либо данными. Масштабируемость этих протоколов обусловлена использованием мультикаста для обнаружения соседей и обмена с ними необходимыми параметрами протокола. Ручная настройка LDP/RSVP соседства в DMVPN сведёт на нет масштабируемость, поэтому такой сценарий статья не рассматривает. Использование же мультикаста ограничивает функциональность решения, поскольку spoke могут обмениваться такими сообщениями только с hub, что исключает наличие spoke-to-spoke связности с использованием MPLS.

Впрочем, существует третье решение, которое является достаточно масштабируемым, а также способно обеспечить MPLS-связность spoke-узлов между собой это BGP labeled unicast (BGP LU). Существует несколько способов превратить spoke-маршрутизатор в PE (например, первый вариант отправить пакет с VPN меткой напрямую другому spoke, аналог второй фазы DMVPN; второй вариант hub принимает непосредственное участие в передаче пакета внутри VRF, выполняя перенаправление пакета, как в третьей фазе DMVPN); однако в определённых случаях может возникнуть необходимость разместить PE за spoke.

Как обычно, соберём лабу и итеративно построим рабочее решение. Ниже приведена используемая топология в рамках рассмотрения 2547oDMVPN:

Схема стендаСхема стенда

Роли маршрутизаторов:

  • R1, R5, R7 (and R6 later) MPLS PE;

  • R3 провайдер для DMVPN;

  • R2 DMVPN hub;

  • R4, R6 DMVPN spokes.

Протоколы маршрутизации:

  • R1-R2, R4-R5, R6-R7 OSPF на площадке организации;

  • R3 OSPF провайдера, обеспечивающий связность между маршрутизаторами DMVPN;

  • R1, R5, R7 (R6) MP-BGP VPNv4 AF;

  • R2, R4, R6 MP-BGP IPv4 AF;

Loopback0 отвечает за идентификацию маршрутизатора в сети, например, за назначение OSPF RID. Loopback1 является интерфейсом, с которого маршрутизаторы устанавливают BGP LU сессии; причины такой настройки рассмотрены далее в статье. Loopback2 эмулирует клиентские сети внутри VRF.

Начнём с базовой конфигурации PE:

R1(config)# vrf definition AR1(config-vrf)# rd 1:1R1(config-vrf)# address-family ipv4R1(config-vrf-af)# route-target export 1:1R1(config-vrf-af)# route-target import 1:1R1(config-if)# interface Loopback0R1(config-if)# ip address 1.1.1.1 255.255.255.255R1(config)# interface Loopback2R1(config-if)# vrf forwarding AR1(config-if)# ip address 1.1.1.1 255.255.255.255R1(config)# interface FastEthernet0/0R1(config-if)# ip address 192.168.12.1 255.255.255.0R1(config-if)# mpls ldp router-id Loopback0R1(config)# router ospf 1R1(config-router)# mpls ldp autoconfigR1(config-router)# router-id 1.1.1.1R1(config-router)# network 0.0.0.0 255.255.255.255 area 0R1(config)# router bgp 1R1(config-router)# template peer-policy L3VPNR1(config-router-ptmp)# send-community bothR1(config-router-ptmp)# exit-peer-policyR1(config-router)# template peer-session SESSIONR1(config-router-stmp)# remote-as 1R1(config-router-stmp)# update-source Loopback0R1(config-router-stmp)# exit-peer-sessionR1(config-router)# bgp router-id 1.1.1.1R1(config-router)# no bgp default ipv4-unicastR1(config-router)# neighbor 5.5.5.5 inherit peer-session SESSIONR1(config-router)# neighbor 7.7.7.7 inherit peer-session SESSIONR1(config-router)# address-family vpnv4R1(config-router-af)# neighbor 5.5.5.5 activateR1(config-router-af)# neighbor 5.5.5.5 send-community extendedR1(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPNR1(config-router-af)# neighbor 7.7.7.7 activateR1(config-router-af)# neighbor 7.7.7.7 send-community extendedR1(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPNR1(config-router-af)# exit-address-familyR1(config-router)# address-family ipv4 vrf AR1(config-router-af)# redistribute connectedR1(config-router-af)# exit-address-family
R5(config)# vrf definition AR5(config-vrf)# rd 1:1R5(config-vrf)# address-family ipv4R5(config-vrf-af)# route-target export 1:1R5(config-vrf-af)# route-target import 1:1R5(config-vrf-af)# exit-address-familyR5(config-vrf)# interface Loopback0R5(config-if)# ip address 5.5.5.5 255.255.255.255R5(config-if)# interface Loopback2R5(config-if)# vrf forwarding AR5(config-if)# ip address 5.5.5.5 255.255.255.255R5(config-if)# interface FastEthernet0/0R5(config-if)# ip address 192.168.45.5 255.255.255.0R5(config-if)# mpls ldp router-id Loopback0R5(config)# router ospf 1R5(config-router)# mpls ldp autoconfigR5(config-router)# router-id 5.5.5.5R5(config-router)# network 0.0.0.0 255.255.255.255 area 0R5(config-router)# router bgp 1R5(config-router)# template peer-policy L3VPNR5(config-router-ptmp)# send-community bothR5(config-router-ptmp)# exit-peer-policyR5(config-router)# template peer-session SESSIONR5(config-router-stmp)# remote-as 1R5(config-router-stmp)# update-source Loopback0R5(config-router-stmp)# exit-peer-sessionR5(config-router)# bgp router-id 5.5.5.5R5(config-router)# no bgp default ipv4-unicastR5(config-router)# neighbor 1.1.1.1 inherit peer-session SESSIONR5(config-router)# neighbor 7.7.7.7 inherit peer-session SESSIONR5(config-router)# address-family vpnv4R5(config-router-af)# neighbor 1.1.1.1 activateR5(config-router-af)# neighbor 1.1.1.1 send-community extendedR5(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPNR5(config-router-af)# neighbor 7.7.7.7 activateR5(config-router-af)# neighbor 7.7.7.7 send-community extendedR5(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPNR5(config-router-af)# exit-address-familyR5(config-router)# address-family ipv4 vrf AR5(config-router-af)# redistribute connectedR5(config-router-af)# exit-address-family
R7(config)# vrf definition AR7(config-vrf)# rd 1:1R7(config-vrf)# address-family ipv4R7(config-vrf-af)# route-target export 1:1R7(config-vrf-af)# route-target import 1:1R7(config-vrf-af)# exit-address-familyR7(config-vrf)# interface Loopback0R7(config-if)# ip address 7.7.7.7 255.255.255.255R7(config-if)# interface Loopback2R7(config-if)# vrf forwarding AR7(config-if)# ip address 7.7.7.7 255.255.255.255R7(config-if)# interface FastEthernet0/0R7(config-if)# ip address 192.168.67.7 255.255.255.0R7(config-if)# mpls ldp router-id Loopback0R7(config)# router ospf 1R7(config-router)# mpls ldp autoconfigR7(config-router)# router-id 7.7.7.7R7(config-router)# network 0.0.0.0 255.255.255.255 area 0R7(config-router)# router bgp 1R7(config-router)# template peer-policy L3VPNR7(config-router-ptmp)# send-community bothR7(config-router-ptmp)# exit-peer-policyR7(config-router)# template peer-session SESSIONR7(config-router-stmp)# remote-as 1R7(config-router-stmp)# update-source Loopback0R7(config-router-stmp)# exit-peer-sessionR7(config-router)# bgp router-id 7.7.7.7R7(config-router)# bgp log-neighbor-changesR7(config-router)# no bgp default ipv4-unicastR7(config-router)# neighbor 1.1.1.1 inherit peer-session SESSIONR7(config-router)# neighbor 5.5.5.5 inherit peer-session SESSIONR7(config-router)# address-family ipv4R7(config-router-af)# exit-address-familyR7(config-router)# address-family vpnv4R7(config-router-af)# neighbor 1.1.1.1 activateR7(config-router-af)# neighbor 1.1.1.1 send-community extendedR7(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPNR7(config-router-af)# neighbor 5.5.5.5 activateR7(config-router-af)# neighbor 5.5.5.5 send-community extendedR7(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPNR7(config-router-af)# exit-address-familyR7(config-router)# address-family ipv4 vrf AR7(config-router-af)# redistribute connectedR7(config-router-af)# exit-address-family

Следующий шаг подключить DMVPN маршрутизаторы к локальным сегментам сети:

R2(config)# interface Loopback0R2(config-if)# ip address 2.2.2.2 255.255.255.255R2(config-if)# interface FastEthernet0/0R2(config-if)# ip address 192.168.12.2 255.255.255.0R2(config-if)# mpls ldp router-id Loopback0R2(config)# router ospf 1R2(config-router)# mpls ldp autoconfigR2(config-router)# router-id 2.2.2.2R2(config-router)# redistribute bgp 1 subnetsR2(config-router)# passive-interface defaultR2(config-router)# no passive-interface FastEthernet0/0R2(config-router)# no passive-interface Loopback0R2(config-router)# network 0.0.0.0 255.255.255.255 area 0
R4(config)# interface Loopback0R4(config-if)# ip address 4.4.4.4 255.255.255.255R4(config-if)# interface FastEthernet0/0R4(config-if)# ip address 192.168.45.4 255.255.255.0R4(config-if)# mpls ldp router-id Loopback0R4(config)#router ospf 1R4(config-router)# mpls ldp autoconfigR4(config-router)# router-id 4.4.4.4R4(config-router)# redistribute bgp 1 subnetsR4(config-router)# passive-interface defaultR4(config-router)# no passive-interface FastEthernet0/0R4(config-router)# no passive-interface Loopback0R4(config-router)# network 0.0.0.0 255.255.255.255 area 0
R6(config)# interface Loopback0R6(config-if)# ip address 6.6.6.6 255.255.255.255R6(config-if)# interface FastEthernet0/0R6(config-if)# ip address 192.168.67.6 255.255.255.0R6(config-if)# mpls ldp router-id Loopback0R6(config)# router ospf 1R6(config-router)# mpls ldp autoconfigR6(config-router)# redistribute bgp 1 subnetsR6(config-router)# passive-interface defaultR6(config-router)# no passive-interface FastEthernet0/0R6(config-router)# no passive-interface Loopback0R6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Наконец последний этап подготовки к рассмотрению BGP LU настройка DMVPN. В статье использован подход front-door VRF, чтобы уменьшить объём посторонней информации в глобальной таблице маршрутизации:

R3(config)# interface Loopback0R3(config-if)# ip address 3.3.3.3 255.255.255.255R3(config-if)# interface FastEthernet0/1R3(config-if)# ip address 192.168.34.3 255.255.255.0R3(config-if)# interface FastEthernet1/0R3(config-if)# ip address 192.168.23.3 255.255.255.0R3(config-if)# interface FastEthernet1/1R3(config-if)# ip address 192.168.36.3 255.255.255.0R3(config-if)# router ospf 1R3(config-router)# router-id 3.3.3.3R3(config-router)# network 0.0.0.0 255.255.255.255 area 0
R2(config)# vrf definition FVRFR2(config-vrf)# rd 1:1R2(config-vrf)# address-family ipv4R2(config-vrf-af)# exit-address-familyR2(config-vrf)# interface Tunnel0R2(config-if)# ip address 192.168.0.2 255.255.255.0R2(config-if)# no ip redirectsR2(config-if)# ip nhrp map multicast dynamicR2(config-if)# ip nhrp network-id 1R2(config-if)# ip nhrp redirectR2(config-if)# tunnel source FastEthernet1/0R2(config-if)# tunnel mode gre multipointR2(config-if)# tunnel vrf FVRFR2(config-if)# interface FastEthernet1/0R2(config-if)# vrf forwarding FVRFR2(config-if)# ip address 192.168.23.2 255.255.255.0R2(config-if)# router ospf 2 vrf FVRFR2(config-router)# router-id 192.168.23.2R2(config-router)# network 0.0.0.0 255.255.255.255 area 0
R4(config)# vrf definition FVRFR4(config-vrf)# rd 1:1R4(config-vrf)# address-family ipv4R4(config-vrf-af)# exit-address-familyR4(config-vrf)# interface Tunnel0R4(config-if)# ip address 192.168.0.4 255.255.255.0R4(config-if)# no ip redirectsR4(config-if)# ip nhrp network-id 1R4(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicastR4(config-if)# ip nhrp shortcutR4(config-if)# tunnel source FastEthernet0/1R4(config-if)# tunnel mode gre multipointR4(config-if)# tunnel vrf FVRFR4(config-if)# interface FastEthernet0/1R4(config-if)# vrf forwarding FVRFR4(config-if)# ip address 192.168.34.4 255.255.255.0R4(config-if)# router ospf 2 vrf FVRFR4(config-router)# router-id 192.168.34.4R4(config-router)# network 0.0.0.0 255.255.255.255 area 0
R6(config)# vrf definition FVRFR6(config-vrf)# rd 1:1R6(config-vrf)# address-family ipv4R6(config-vrf-af)# exit-address-familyR6(config-vrf)# interface Tunnel0R6(config-if)# ip address 192.168.0.6 255.255.255.0R6(config-if)# no ip redirectsR6(config-if)# ip nhrp network-id 1R6(config-if)# ip nhrp nhs 192.168.0.2 nbma 192.168.23.2 multicastR6(config-if)# ip nhrp shortcutR6(config-if)# tunnel source FastEthernet1/1R6(config-if)# tunnel mode gre multipointR6(config-if)# tunnel vrf FVRFR6(config-if)# interface FastEthernet1/1R6(config-if)# vrf forwarding FVRFR6(config-if)# ip address 192.168.36.6 255.255.255.0R6(config-if)# router ospf 2 vrf FVRFR6(config-router)# network 0.0.0.0 255.255.255.255 area 0

Время заняться делом. Необходимым условием для L3VPN является наличие рабочего LSP между PE. Поскольку ни LDP, ни RSVP в рамках DMVPN для этой задачи не подходят, используем MP-BGP для передачи следующей информации:

  • адреса loopback;

  • соответствующие им MPLS метки.

Звучит довольно просто. Что насчёт поддержки MPLS на интерфейсах?

R2# sho mpls interfacesInterface              IP            Tunnel   BGP Static OperationalFastEthernet0/0        Yes (ldp)     No       No  No     Yes  

На Tunnel0 MPLS пока не работает. Нам нужно разрешить только поддержку MPLS пакетов, не включая LDP, поэтому команда mpls ip не подходит. Впрочем, существует ещё одна менее известная команда, отвечающая нашей задаче:

R2(config)#interface Tunnel0R2(config-if)#mpls bgp forwardingR2#sho mpls interfacesInterface              IP            Tunnel   BGP Static OperationalFastEthernet0/0        Yes (ldp)     No       No  No     Yes        Tunnel0                No            No       Yes No     Yes

После выполнения этой команды на всех spoke можно приступать к настройке BGP. В этой статье мы используем iBGP между hub и spoke; hub выполняет роль route-reflector и принимает входящие BGP-соединения:

R2(config)# router bgp 1R2(config-router)# bgp router-id 2.2.2.2R2(config-router)# bgp listen range 192.168.0.0/24 peer-group DMVPNR2(config-router)# no bgp default ipv4-unicastR2(config-router)# neighbor DMVPN peer-groupR2(config-router)# neighbor DMVPN remote-as 1R2(config-router)# neighbor DMVPN update-source Tunnel0R2(config-router)# address-family ipv4R2(config-router-af)# network 1.1.1.1 mask 255.255.255.255R2(config-router-af)# neighbor DMVPN activateR2(config-router-af)# neighbor DMVPN route-reflector-clientR2(config-router-af)# neighbor DMVPN send-label
R4(config)# router bgp 1R4(config-router)# bgp router-id 4.4.4.4R4(config-router)# no bgp default ipv4-unicastR4(config-router)# neighbor 192.168.0.2 remote-as 1R4(config-router)# neighbor 192.168.0.2 update-source Tunnel0R4(config-router)# address-family ipv4R4(config-router-af)# network 5.5.5.5 mask 255.255.255.255R4(config-router-af)# neighbor 192.168.0.2 activateR4(config-router-af)# neighbor 192.168.0.2 send-label
R6(config)# router bgp 1R6(config-router)# bgp router-id 6.6.6.6R6(config-router)# no bgp default ipv4-unicastR6(config-router)# neighbor 192.168.0.2 remote-as 1R6(config-router)# neighbor 192.168.0.2 update-source Tunnel0R6(config-router)# address-family ipv4R6(config-router-af)# network 7.7.7.7 mask 255.255.255.255R6(config-router-af)# neighbor 192.168.0.2 activateR6(config-router-af)# neighbor 192.168.0.2 send-label

Проверим, есть ли IP-связность между PE:

R5#ping 1.1.1.1 so lo 0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 48/57/64 ms

Достаточно ли этого для связности внутри VRF?

R5#ping vrf A 1.1.1.1 so lo 0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5.....Success rate is 0 percent (0/5)

К сожалению, решение несколько сложнее, чем могло бы показаться на первый взгляд. Причина отсутствия связности нерабочий LSP между PE:

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5Sending 5, 100-byte MPLS Echos to 1.1.1.1/32,     timeout is 2 seconds, send interval is 0 msec:Codes: '!' - success, 'Q' - request not sent, '.' - timeout,  'L' - labeled output interface, 'B' - unlabeled output interface,  'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,  'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,  'P' - no rx intf label prot, 'p' - premature termination of LSP,  'R' - transit router, 'I' - unknown upstream index,  'X' - unknown return code, 'x' - return code 0Type escape sequence to abort.BBBBBSuccess rate is 0 percent (0/5)

Если быть точным, место отказа R4:

R4#sho mpls forwarding-table 1.1.1.1 32Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    Label      Label      or Tunnel Id     Switched      interface              19         No Label   1.1.1.1/32       1125          Tu0        192.168.0.2

Впрочем, является ли R4 местом возникновения проблемы? Разве R2 не должен был послать R4 префикс вместе с меткой?

R4#sho ip bgp labels   Network          Next Hop      In label/Out label   1.1.1.1/32       192.168.12.1   nolabel/nolabel   2.2.2.2/32       192.168.0.2    nolabel/imp-null   <output omitted>

Важное наблюдение: 1.1.1.1/32 не имеет сопутствующей MPLS метки, однако 2.2.2.2/32 ведёт себя так, как и было задумано. Также стоит обратить внимание на next-hop для 1.1.1.1/32 это адрес R1, а не R2. R2 импортировал маршрут в BGP, сохранив оригинальный next-hop из таблицы маршрутизации. Поскольку сессия между R2 и R4 iBGP, значение next-hop для 1.1.1.1/32 не меняется. Для 2.2.2.2/32 значение next-hop адрес R2. Это тонкое отличие, однако, является ключевым: BGP назначает префиксу MPLS метку только в том случае, когда BGP маршрутизатор является next-hopом для этого префикса, т.е. входит в LSP.

В нашем случае нужно назначать метку только префиксам, импортированным локально, и не менять информацию от spoke:

R2(config)#router bgp 1R2(config-router)#address-family ipv4R2(config-router-af)#neighbor PEER next-hop-self ?    all  Enable next-hop-self for both eBGP and iBGP received paths  <cr>R2(config-router-af)#neighbor PEER next-hop-self

Эта команда довольно хитрая. По умолчанию она заставляет R2 изменять next-hop для маршрутов, которые импортированы локально или получены через eBGP; если нужно изменить next-hop для всех префиксов, включая те, которые получены по iBGP, нужно добавить ключевое слово all. Появилась ли связность?

R5#ping mpls ipv4 1.1.1.1/32 source 5.5.5.5<output omitted>Type escape sequence to abort.!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 56/65/72 msR5#R5#ping vrf A 1.1.1.1 so lo 0              Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 52/80/108 msR5#R5#ping mpls ipv4 7.7.7.7/32 source 5.5.5.5<output omitted>Type escape sequence to abort.!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/64 msR5#R5#ping vrf A 7.7.7.7 so lo 2              Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:Packet sent with a source address of 5.5.5.5!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 48/79/104 msR5#R5#traceroute 7.7.7.7 so lo 0Type escape sequence to abort.Tracing the route to 7.7.7.7VRF info: (vrf in name/id, vrf out name/id)  1 192.168.45.4 [MPLS: Label 22 Exp 0] 88 msec 80 msec 80 msec  2 192.168.0.6 [MPLS: Label 16 Exp 0] 52 msec 64 msec 52 msec  3 192.168.67.7 40 msec 64 msec 64 msec

Мы добились работы L3VPN поверх DMVPN. Впрочем, внимательный читатель, который повторял описанные шаги в собственной лабе, мог заметить следующее предупреждение, возникающее при настройке BGP LU:

R4(config-router-af)#neighbor 192.168.0.2 send-label%BGP: For distributing MPLS labels to IBGP peers, the update source should be set to a loopback interface

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

В рамках этого примера R1 устанавливает BGP сессию со своего интерфейса f0/0 до loopback интерфейса на R3, повторяя схему DMVPN. Control plane в данном случае будет работать без ошибок, тогда как связность на data plane LSP будет нарушена. Причина PHP, penultimate hop popping. Интерфейс f0/0 лежит в directly connected сети для R2, который анонсирует её с меткой implicit-null. Рассмотрим, что происходит с пакетом, который R3 отправит на R1:

  1. R3 добавляет VPN метку (например, 16) к пакету;

  2. R3 добавляет транспортную метку (implicit-null) к полученному MPLS кадру;

  3. R3 отправляет полученный кадр в сторону R2, при этом VPN метка находится на вершине стека.

Далее возможны два исхода: R2 не знает, что делать с кадром (VPN метка отсутствует в LFIB), и отбрасывает его, или же R2 шлёт кадр в неверном направлении (случайное совпадение VPN метки в кадре и транспортной метки в LFIB). В любом случае шансы R1 на получение кадра ничтожно малы. Стоит отметить, что использование explicit-null не решит проблему, поскольку для передачи кадра всё так же будет использована нижележащая VPN метка.

Впрочем, какое это имеет отношение к нашей изначальной топологии? Описанная проблема относится к некорректно настроенным PE-маршрутизаторам. Однако эта проблема становится актуальной и в нашей топологии, если spoke превратить в PE, поскольку BGP использует Tunnel0 для установления сессии. Можно попробовать перенастроить BGP на использование loopback, хотя это ни к чему хорошему не приведёт: LSP будет разорван, т.к. некому анонсировать метки для самих loopback обычно это задача LSP/RSVP. Впрочем, решение довольно простое: можно использовать loopback только для VPNv4 AF сессий и анонсировать соответствующие метки с помощью BGP LU:

R6(config)# vrf definition AR6(config-vrf)# rd 2:2R6(config-vrf)# address-family ipv4R6(config-vrf-af)# route-target export 1:1R6(config-vrf-af)# route-target import 1:1R6(config-vrf-af)# exit-address-familyR6(config-vrf)# interface Loopback1R6(config-if)# ip address 100.0.0.6 255.255.255.255R6(config-if)# interface Loopback2R6(config-if)# vrf forwarding AR6(config-if)# ip address 6.6.6.6 255.255.255.255R6(config-if)# router bgp 1R6(config-router)# template peer-policy L3VPNR6(config-router-ptmp)# send-community bothR6(config-router-ptmp)# exit-peer-policyR6(config-router)# template peer-session SESSIONR6(config-router-stmp)# remote-as 1R6(config-router-stmp)# update-source Loopback1R6(config-router-stmp)# exit-peer-sessionR6(config-router)# neighbor 1.1.1.1 inherit peer-session SESSIONR6(config-router)# neighbor 5.5.5.5 inherit peer-session SESSIONR6(config-router)# neighbor 7.7.7.7 inherit peer-session SESSIONR6(config-router)# address-family ipv4R6(config-router-af)# network 100.0.0.6 mask 255.255.255.255R6(config-router-af)# exit-address-familyR6(config-router)# address-family vpnv4R6(config-router-af)# neighbor 1.1.1.1 activateR6(config-router-af)# neighbor 1.1.1.1 send-community extendedR6(config-router-af)# neighbor 1.1.1.1 inherit peer-policy L3VPNR6(config-router-af)# neighbor 5.5.5.5 activateR6(config-router-af)# neighbor 5.5.5.5 send-community extendedR6(config-router-af)# neighbor 5.5.5.5 inherit peer-policy L3VPNR6(config-router-af)# neighbor 7.7.7.7 activateR6(config-router-af)# neighbor 7.7.7.7 send-community extendedR6(config-router-af)# neighbor 7.7.7.7 inherit peer-policy L3VPNR6(config-router-af)# exit-address-familyR6(config-router)# address-family ipv4 vrf AR6(config-router-af)# redistribute connectedR6(config-router-af)# exit-address-family

Теперь R6 участвует в L3VPN, и можно проверить наличие связности внутри VRF:

R6#tclsh                                                      R6(tcl)#foreach x {1.1.1.1 5.5.5.5 7.7.7.7} {ping vrf A $x so lo 2}Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 6.6.6.6!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 28/59/84 msType escape sequence to abort.Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:Packet sent with a source address of 6.6.6.6!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/32/44 msType escape sequence to abort.Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:Packet sent with a source address of 6.6.6.6!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms

Наконец-то L3VPN поверх DMVPN работает так, как мы ожидали. Мне кажется, сложности описанной конструкции заключаются в следующем:

  • обладание тайным знанием о существовании BGP LU;

  • назначение MPLS метки только в том случае, если маршрутизатор является next-hopом для префикса;

  • понимание, в каких случаях PHP способен сломать LSP.

В этой статье мы обсудили настройку MPLS L3VPN поверх DMVPN (2547oDMVPN) с использованием iBGP LU для распространения MPLS меток в рамках опорной сети. Отличие от документированных способов это возможность разместить PE-маршрутизатор за hub/spokes без нарушения spoke-to-spoke связности поверх DMVPN. Что касается настройки с помощью eBGP, я бы хотел оставить её как домашнее задание для любознательных читателей.

Спасибо за рецензию: Анастасии Куралевой, Максиму Климанову

Подробнее..

Сброс пароля и базовая настройка Cisco 1941

25.04.2021 10:05:42 | Автор: admin

Бывает так, что приходится сталкиваться с задачами, к решению которых ты вроде бы и не готов, а получить результат надо здесь и сейчас. Знакомо, да? Добро пожаловать в мир восточноевропейского менеджмента с соответствующей культурой управления.

Итак, допустим, ты представитель местечкового провайдера, уже знающий, как настроить какой-нибудь ASUS, но волею судьбы ещё не получивший сертификат CCNA. Рядом с тобой стоит местный админ, тоже без сертификата, глазами молящий ничего не "сбрасывать в ноль", ибо "всё работает, я просто не знаю пароль, только вы никому не говорите".

Подобные ситуации не редкость в наше ковидном мире, когда отделы со своей инфраструктурой тасуюся ежеквартально, директора направлений таинственно исчезают, а очередной управленец, дабы продемонстрировать собственную эффективность, ссорится с единственным цискарём в округе и заключает договора обслуживания при помощи сайта объявлений.

Проведём же вместе сеанс чёрной айтишной магии с последующим её разоблачением. А именно : сбросим пароль, настроим интерфейсы (локальный и внешний), соединим эти сети маршрутами и трансляцией адресов и прикроем(нет) фаерволом. Кирпич с фирменным шильдиком волшебным образом превратится в полезное сетевое устройство.

Устройство и нужные нам интерфейсы

Вот она, наша девочка. Как опытные ребята, подходим с правильной стороны:

Нас интересует её правая часть, где все порты. Голубым помечены консольные, жёлтым -- EthernetНас интересует её правая часть, где все порты. Голубым помечены консольные, жёлтым -- Ethernet

Если подключаться в Ethernet порты, которые жёлтые, то нужно знать IP адреса на этих интерфейсах и пароли на вход -- основной и "повышенный" (под которым, собственно и надо всё настраивать). Если чего-то из этого нет, то добро пожаловать в консоль. Её порты помечены нежно-голубым цветом. Такой же цвет у фирменного консольного кабеля Cisco, который обычно к этому времени потерялся.

Кабель "специальный" Cisco. Распайки есть везде.Кабель "специальный" Cisco. Распайки есть везде.

По нынешним временам COM-порт есть далеко не в каждом ноуте, поэтому придётся к этому шнурку брать стандартный COM-USB переходник. Но можно присмотреться и увидеть, что рядом со "старым" консольным портом есть mini-usb порт с тем же назначением. Переходник в данном случае встроен в циску, и, да, на него нужны драйвера. Устанавливаем их, ребутимся и подключаемся снова. После подключения Cisco через кабель miniusb в списке оборудования в разделе Порты (COM и LPT) появился Cisco Serial (COM14) (не обязательно именно 14, ну что поделать). Для дальнейшей работы рекомендую терминальную программку Putty, ибо в ней есть всё, что необходимо, и она проста, как полено. На сегодня нам от неё нужно будет подключение по интерфейсу Serial (Com14) и впоследствии Telnet (TCP23).

Сбрасываем пароли

Включаем циску и подключаемся в Putty к порту Serial (название COM14, Baud Rate 9600). Убеждаемся, что коннект есть. Далее надо перезагрузить маршрутизатор в ROMMON начальный загрузчик совсем урезанную версию операционной системы, которая загружается до cisco IOS и используется для сервисных целей (обновление IOS, восстановление пароля). Чтобы перезагрузить маршрутизатор в ROMMON, нужно прервать обычный процесс загрузки в IOS для этого в самом начале загрузки надо отправить сигнал прерывания.

Выключаем, и не разрывая консольный сеанс, Включаем Cisco 1941 и нажимаем клавишу Break (она же клавиша Pause) или комбинацию Ctrl+Break на клавиатуре (если в ноуте этого нет, в Putty по правой кнопке мыши можно вызвать special command break). Полная таблица с сигналами прерывания для разных терминалов находится здесь.

Видим приглашение в режим rommon (ROM monitor) :

rommon 1 >

Вводим команду изменения конфигурации регистра командой confreg и после перезапускаем роутер командой reset

rommon 1 > confreg 0x2142

rommon 2 > reset

Повышаем привилегии командой enable или просто en И пароль она тут не просит :)

Router1>en

Копируем запароленный конфиг в память роутера:

Router1#copy startup-config running-config

После этого применится старый конфиг, который был запаролен, но при этом мы уже находимся в привилегированном режиме, откуда можем выставить новые пароли для привилегированного режима, telnet и консоли.

Router1#conf terminal

Router1(config)#enable secret $$$NewPassword

Router1(config)#enable password $$$NewPassword

Router1(config)#line vty 0 4

Router1(config-line)#password $$$NewPassword

Router1(config-line)#login

Router1(config-line)#exit

Router1(config)#line console 0

Router1(config-line)#password $$$NewPassword

Router1(config-line)#login

Router1(config-line)#exit

Главное, в конце не забыть вернуть значения регистров по умолчанию. Если этого не сделать, то наш новый конфиг снова будет проигнорирован после перезагрузки роутера.

Router1(config)# config-register 0x2102

Router1(config)#exit

Копируем загруженный конфиг в стартовый и перезагружаемся:

Router1# copy running-config startup-config

Router1# reload

Роутер теперь с новым паролем для консоли, телнета и привилегированного режима. Ура. Можно отдать циску просиявшему админу вместе с настройками "нового интернета" (мы же от провайдера приехали, помните?). Если во взгляде местного системного администратора затаились нерешительность и страх, то поможем бедолаге.

Настройка интерфейсов

Чтоб два раза не приезжать, пробежимся по всем нужным настройкам "чтоб взлетело". У циски два "жёлтых" интерфейса: GigabitEthernet0/0 и GigabitEthernet0/1. Обычно они должны смотреть в сторону WAN и LAN соответственно, да будет так.

Адресация в WAN, допустим 100.200.100.202/30 со шлюзом провайдера 100.200.100.201

Адресация в LAN, как водится, 192.168.1.1/24 с локальным интерфейсом циски 192.168.1.1

Всё делаем из под рута:

>en

#

Для конфигурации используем команду configure terminal, для выхода - exit:

#conf t

#exit

Настраиваем локальный интерфейс:

#conf t

#interface GigabitEthernet0/1

#description LAN

#ip address 192.168.1.1 255.255.255.0

#no shutdown

#exit

Настраиваем DHCP (на всю подсеть кроме .1-.50 и .200-.254).

Исключения:

#ip dhcp excluded-address 192.168.1.200 192.168.1.254

#ip dhcp excluded-address 192.168.1.1 192.168.1.50

#ip dhcp ping packets 4

Сам пул:

#ip dhcp pool MY_DHCP_POOL_1

#import all

#network 192.168.1.0 255.255.255.0

#default-router 192.168.1.1

#dns-server 77.88.8.8

#lease 3

#exit

Всё, после этой настройки можно подключаться телнетом из локалки при желании (удобно для проверок)

При подключении должен примениться адрес из DHCP пула и пинговаться циска. Советую запустить ping -t чтоб мониторить на всякий случай.

Настраиваем внешний интерфейс:

#conf t

#interface GigabitEthernet0/0

#ip address 100.200.100.202 255.255.255.252

#no shutdown

#exit

Тут должен начать пинговаться шлюз прова - 100.200.100.201 - но только от самой циски, не с ноута (между сетями-то пакеты пока не ходят)

#ip forward-protocol nd

#ip route 0.0.0.0 0.0.0.0 100.200.100.201

Тут от самой циски должен начать пинговаться 8.8.8.8

#ip domain timeout 2

#ip name-server 8.8.8.8

#ip name-server 77.88.8.8

#ip cef

Тут от самой циски должен начать пинговаться ya.ru

#copy running-config startup-config (или просто #wr)

В итоге мы настроили на циске две сети, в которых она будет жить и трудиться. Далее надо будет их соединить.

Его величество межсетевой экран

Собственно, его величество фаер. В ипостасях NAT и списков доступа (ACL)

Тут много построено на этих самых списках, ссылки на них вбиваются как в правила интерфейсов (access-group), так и в правилах NAT, поэтому заносить надо аккуратно. Списки работают строго сверху вниз. Поэтому правила для any обычно последние (и они не нужны -- по дефолту для any всё запрещено). Список доступа может быть стандантным (access-list standard) , либо расширенным (access-list extended). Отличаются детализацией -- у стандартного только действие и источник пакетов, например.

Настройка NAT

Собираем локальную область для маскарадинга (да, я знаю, что это термин для iptables, но суть та же):

#ip access-list standard 10

#permit 192.168.1.0 0.0.0.255

#deny any

#exit

Назначаем стороны маскарадинга (интерфейсы):

#interface gigabitethernet0/1

#ip nat inside

#exit

#interface gigabitethernet0/0

#ip nat outside

#exit

Cамое важное: включаем собственно правило (одной строкой):

#ip nat inside source list 10 interface gigabitethernet0/0 overload

Закрываемся от атаки по TCPSYN:

#ip tcp synwait-time 30

Настраиваем список доступа для внешнего интерфейса (если настроить для внутреннего, то нужны разрешения для dhcp трафика). Первым делом закроем единственный сетевой доступ -- телнет (tcp 23). Если подняты http(s) или ssh тоже закрыть

Пишем список (особое внимание протоколу icmp)

#ip access-list extended 101

#deny tcp any any eq 23

#permit tcp any any

#permit udp any any

#permit icmp any any echo-reply

#permit icmp any any time-exceeded

#permit icmp any any unreachable

#deny ip any any

#exit

Вешаем список на вход во внешний интерфейс:

#int gigabitethernet0/0

#ip access-group 101 in

#exit

#copy running-config startup-config (или просто #wr)

Так то список только базовую "защиту" обеспечивает, но это головная боль админа уже. После поднятия всех сервисов и их проверки, можно написать построже и применить.

У нас пингуется всё изнутри и циска снаружи. Интернет работает, почта ходит. Все счастливы, танцуют, обнимаются, деньги в карманы засовывают. Твой социальный рейтинг растёт на глазах.

P.S. Полезные команды

Почти весь мониторинг -- это команда show. У неё есть короткая форма sh, которую я не рекомендую, ибо такая же короткая форма есть у команды shutdown

Собственно, включение чего-либо, например, интерфейса выглядит вот так:

#no shutdown

Выведем на почитать/скопировать весь конфиг:

#show running-config

Можно посмотреть возможности команды show:

#show ?

Да и любой:

#ip ?

Просмотр сводной информации по интерфейсам:

#show ip interface brief

Просмотр информации по интерфейсам L2:

#show interface summary

Просмотр адресов, выданных по DHCP:

#show ip dhcp bind

Удаление строк конфига:

#no [строка конфига]

Например, удалим шлюз по умолчанию:

#no ip default-gateway

Удаляем ВЕСЬ список доступа:

#no ip access-list extended 101

Удаление статического маршрута:

#no ip route [маршрут]

Что-ж для первого визита вполне достаточно. При помощи этой нехитрой магии ты заведёшь себе много друзей, юный падаван :) И не забудь предупредить местного админа о том, что если он как следует не настроит ACL, их сетку могут в скором времени ждать крупные неприятности. Но это уже совсем другая история.


У нас быстрые серверы для любых экспериментов.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Подробнее..

Перевод BGP redistribute-internal ещё один рецепт петли маршрутизации

14.05.2021 18:17:37 | Автор: admin

Иногда можно наткнуться на такое поведение по умолчанию, обнаружение и понимание которого требует определённой медитации. Для меня одной из таких особенностей была команда bgp redistribute-internal. Первоначально назначение этой функции не вызывало у меня каких-либо вопросов, как и то, что её использование может привести к петлям маршрутизации; раз знающие люди написали, что может, значит, так оно и есть. Однако спустя неопределённое время в голове начало скрестись желание получить наглядный пример такой петли. Беглый поиск, впрочем, не дал ничего конкретного, только упоминание в документации:

Note: By default, only eBGP-learned information is candidate to be redistributed into IGP when the redistribute bgp command is issued. The iBGP routes is not redistributed into IGP until the bgp redistribute-internal command is configured under the router bgp command. But precautions must be taken in order to avoid loops within the Autonomous System when iBGP routes are redistributed into IGP.

(Вольный перевод: по умолчанию только внешние BGP маршруты можно рассматривать как кандидаты для импорта в IGP при использовании команды redistribute bgp. Внутренние BGP маршруты не являются такими кандидатами, пока не выполнена команда bgp redistribute-internal в режиме router bgp. Однако стоит соблюдать осторожность при использовании последней команды, чтобы избежать возникновения петель маршрутизации внутри автономной системы, когда внутренние BGP маршруты могут быть импортированы в IGP)

Попробуем изобрести нужный нам пример петли. Рассмотрим следующую схему:

R1 объявляет 1.1.1.1/32 как внутренний маршрут; в то же время R2 суммаризует его до 1.1.1.0/24 и добавляет 1.1.1.1/32 в BGP:

R2#sho ip ro 1.1.1.1 longer-prefixes<output omitted>      1.0.0.0/32 is subnetted, 1 subnetsO        1.1.1.1 [110/2] via 192.168.12.1, 00:03:09, FastEthernet0/0R2(config)#router ospf 1R2(config-router)#area 0 range 1.1.1.0 255.255.255.0R2(config-router)#router bgp 1R2(config-router)#network 1.1.1.1 mask 255.255.255.255

Импортируем 1.1.1.1/32 из BGP в OSPF в зоне 1:

R4(config)#router ospf 1R4(config-router)#redistribute bgp 1 subnets

Впрочем, ничего плохого не происходит:

R4#ping 1.1.1.1 source lo0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 4.4.4.4!!!!!

1.1.1.1/32 есть в таблице маршрутизации R4, однако OSPF не импортирует маршрут из BGP, несмотря на настройки. Изменим это поведение и понаблюдаем за происходящим:

R4(config-router)#router bgp 1                  R4(config-router)#bgp redistribute-internal  R4#ping 1.1.1.1 source lo0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:Packet sent with a source address of 4.4.4.4.....Success rate is 0 percent (0/5)

Связность между R4 и R1 пропала. R3 теперь считает, что маршрут до 1.1.1.1/32 лежит через R4, который в свою очередь шлёт пакеты обратно в сторону R2, что приводит к петле:

R4#traceroute 1.1.1.1 source lo0Type escape sequence to abort.Tracing the route to 1.1.1.1VRF info: (vrf in name/id, vrf out name/id)  1 192.168.34.3 28 msec 36 msec 16 msec  2 192.168.34.4 24 msec 20 msec 16 msec  3 192.168.34.3 32 msec 40 msec 44 msec  4 192.168.34.4 44 msec 36 msec 40 msec<output omitted>

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

Спасибо за рецензию: Анастасии Куралёвой

Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 2 Profile 1)

22.11.2020 14:12:21 | Автор: admin

В прошлой статье мы познакомились с Вами с исторически первым способом организации построения multicast VPN с помощью технологий PIM и mGRE (Часть 1, Profile 0).


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


  • LDP пиры находят друг друга посредством рассылки Hello сообщений на адрес 224.0.0.2. В рамках Hello передается параметр transport address (который, по-умолчанию в Cisco IOS совпадает с IP адресом LDP router-id)
  • Маршрутизаторы устанавливают ТСР сессию и в рамках неё обмениваются метками для FEC (читай IP префиксов из таблицы маршрутизации)
  • Результат обмена однонаправленный LSP типа Point-to-Point.


  • Помимо этого, пиры в рамках ТСР сессии обмениваются сообщениями типа Initialization, внутри которых передается информация о поддерживаемых возможностях (Capabilities). За обмен информацией отвечают Capabilities TLV.
    • Т.е. обмениваться можно не только информацией об P2P LSP, но и ещё чем-то ...

Вся соль mLDP в том, что для этого протокола FEC представляет собой не какой-то один конкретный префикс, а скорее некую комбинацию из четырёх элементов:


  • Тип дерева
  • Адресное семейство (IPv4/IPv6)
  • IP адрес корневого устройства
  • Корневое устройство заранее определенный коммутатор, в котором начинается mLDP LSP
  • Некое дополнительно значение, в оригиналье именуемое Opaque Value.
    • Используется для обозначения конкретного дерева (читай C-VRF) внутри MPLS инфраструктуры.

Всего для mLDP определено три различных FEC:


  • P2MP FEC (тип дерева = 0x06)
  • MP2MP Upstream FEC (тип дерева = 0x07)
  • MP2MP Downstream FEC (тип дерева = 0x08)

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



Дерево MP2MP характеризуется тем, что любой заинтересованный маршрутизатор может передавать трафик (равно, как и получать его). При этом трафик всегда бежит в одном из двух направлений: либо по направлению к корневому устройству, либо от него. LSP типа MP2MP визуально можно представить себе следующим образом:



Теперь попробуем разобраться с тем, как именно строится MP2MP LSP в mLDP (P2MP нам будет интересен в следующих статьях цикла).


Построение MP2MP LSP


Точно также как в обычном unicast LSP, направление сигнализации (распространение меток) противоположно направлению следованию трафика.


Весь процесс сигнализации можно разделить на два этапа (очень похожих на процесс построения многоадресного дерева в PIM ASM через точку рандеву):


  • Downstream сигнализация
    • РЕ распространяют метки в сторону корневого маршрутизатора
    • Согласно распространённым меткам, корневой маршрутизатор передаёт трафик в сторону РЕ
  • Upstream сигнализация
    • Корневой маршрутизатор распространяет метки в сторону РЕ
    • Согласно распространённым меткам, РЕ передаёт трафик в сторону корневого маршрутизатора


Как видно, корневой маршрутизатор является центральной точки сети, через который проходит как Downstream, так и Upstream трафик. Технически им может быть любое устройство сети (как Р, так и РЕ). При этом (насколько мне известно) не существует какого-либо динамического протокола выбора корневого маршрутизатора, поэтому требуется ручная конфигурация на всех РЕ (и только на них).


Рассмотрим вариант замены ранее рассмотренного метода построения Default MDT через BGP ipv4 MDT на mLDP на следующей топологии:



В качестве корневого маршрутизатора будем использовать R8.


Проведем базовую преднастройку (подразумевается, что сделаны все настройки из 1-ой части статьи):


  • Отключим на всех маршрутизаторах протокол PIM:
    interface Gi2.Xno ip pim sparse-mode
    
  • адресное семейство BGP MDT (на РЕ):
    router bgp 65001no address-family ipv4 mdt
    
  • и адрес рассылки MDT
    ip vrf C-ONEno mdt default 239.1.1.1
    

Для полной настройки FEC нам остается ввести IP адрес корневого маршрутизатора и Opaque Value. Начнём с РЕ1:


PE1(config)#mpls mldp logging notificationsPE1(config)#!PE1(config)#ip vrf C-ONEPE1(config-vrf)# vpn id 65001:1PE1(config-vrf)# mdt default mpls mldp 8.8.8.8PE1(config-vrf)#*Nov 21 22:41:03.703: %MLDP-5-ADD_BRANCH: [mdt 65001:1 0] Root: 8.8.8.8, Add MP2MP branch MDT(Lspvif0) remote label , local label no_label*Nov 21 22:41:03.742: MLDP: Reevaluating peers for nhop: 10.1.5.5PE1(config-vrf)#*Nov 21 22:41:04.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to upPE1(config-vrf)#*Nov 21 22:41:05.840: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0PE1(config-vrf)#

PE1 создаёт новый интерфейс Lspvif0 (LSP virtual interface, ничто иное как новый PMSI) для MDT с Opaque Value = [65001:1 0] и запускает на нём PIM в рамках C-VRF.


Прим. Opaque Value состоит из двух частей: vpn id и некоторого дополнительного индекса. Если индекс равен нулю, то это указание на использование Default MDT.


Проверим некоторые параметры вновь созданного интерфейса:


PE1#show ip interface Lspvif0Lspvif0 is up, line protocol is up  Interface is unnumbered. Using address of Loopback0 (1.1.1.1)  Multicast reserved groups joined: 224.0.0.1 224.0.0.2 224.0.0.22 224.0.0.13  VPN Routing/Forwarding "C-ONE"

PE1#show ip pim vrf C-ONE interface Address          Interface                Ver/   Nbr    Query  DR         DR                                          Mode   Count  Intvl  Prior172.1.11.1       GigabitEthernet2.111     v2/S   1      30     1          172.1.11.11172.1.15.1       GigabitEthernet2.115     v2/S   1      30     1          172.1.15.151.1.1.1          Lspvif0                  v2/S   0      30     1          1.1.1.1

Посмотрим базу данных по меткам:


PE1#show mpls mldp neighbors  MLDP peer ID    : 5.5.5.5:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 1  Upstream count : 1  Branch count   : 0  Path count     : 1  Path(s)        : 10.1.5.5          LDP GigabitEthernet2.15  Nhop count     : 1  Nhop list      : 10.1.5.5 

PE1#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 5 (RNR LSM ID: 6)   Type: MP2MP   Uptime : 00:07:53  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  RNR active LSP     : (this entry)  Upstream client(s) :    5.5.5.5:0    [Active]      Expires        : Never         Path Set ID  : 6      Out Label (U)  : 1013          Interface    : GigabitEthernet2.15*      Local Label (D): 10017         Next Hop     : 10.1.5.5  Replication client(s): >   MDT  (VRF C-ONE)      Uptime         : 00:07:53      Path Set ID  : 7      Interface      : Lspvif0       RPF-ID       : *

На РЕ1 присутствует Upstream сосед, которому была передана метка 10017. Трафик, который будет передавать от РЕ1 в сторону R8 получит метку 1013 от Р1.


На Р1 соседей гораздо больше (согласно топологии шестеро):


P1#show mpls mldp neighbors  MLDP peer ID    : 4.4.4.4:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 1  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.4.5.4          LDP GigabitEthernet2.45  Nhop count     : 0 MLDP peer ID    : 1.1.1.1:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 2  Upstream count : 0  Branch count   : 1  Path count     : 1  Path(s)        : 10.1.5.1          LDP GigabitEthernet2.15  Nhop count     : 0 MLDP peer ID    : 8.8.8.8:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 3  Upstream count : 1  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.8.8          LDP GigabitEthernet2.58  Nhop count     : 1  Nhop list      : 10.5.8.8  MLDP peer ID    : 6.6.6.6:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 4  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.6.6          LDP GigabitEthernet2.56  Nhop count     : 0 MLDP peer ID    : 7.7.7.7:0, uptime 2w0d Up,   Target Adj     : No  Session hndl   : 5  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.7.7          LDP GigabitEthernet2.57  Nhop count     : 0 MLDP peer ID    : 9.9.9.9:0, uptime 1w5d Up,   Target Adj     : No  Session hndl   : 6  Upstream count : 0  Branch count   : 0  Path count     : 1  Path(s)        : 10.5.9.9          LDP GigabitEthernet2.59  Nhop count     : 0

P1#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 3   Type: MP2MP   Uptime : 00:13:23  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    8.8.8.8:0    [Active]      Expires        : Never         Path Set ID  : 9      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*      Local Label (D): 1014          Next Hop     : 10.5.8.8  Replication client(s):     1.1.1.1:0       Uptime         : 00:13:23      Path Set ID  : A      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*      Local label (U): 1013          Next Hop     : 10.1.5.1

Обратите внимание на тот факт, что на Р1 C-VRF не настроен, однако маршрутизатор понимает MP2MP дерево согласно по-умолчанию включённому функционалу recursive fec.


На Р1 есть один Upstream сосед (тот, через которого можно добраться на корня дерева) и один Downstream сосед. Для передачи данных в сторону РЕ1, как и ожидалось, используется метка 10017. При получении mLDP метки 10017, Р1 генерирует метку 1014 и отправляет её в сторону Upstream соседа.



Здесь можно сформулировать правило: каждый раз, когда маршрутизатор получает Downstream MP2MP метку, он реагирует созданием Upstream MP2MP метки и отправлением её в сторону Upstream соседа.


Таким образом на текущий момент организуется дерево от РЕ до ROOT.


В ответ на получение метки 1014, ROOT генерирует метку 8017 которая для Р1 будет являться Upstream меткой. В ответ на получение 8017, Р1 генерирует Downstream метку 1013 и отправляет её в сторону PE1.



Добавим настройку на РЕ4:


PE4(config-subif)#ip vrf C-ONEPE4(config-vrf)# vpn id 65001:1PE4(config-vrf)# mdt default mpls mldp 8.8.8.8

*Nov 21 23:25:03.638: %PIM-5-NBRCHG: VRF C-ONE: neighbor 1.1.1.1 UP on interface Lspvif0

Обратите внимание, что mLDP метки на R8 (ROOT) никоим образом не меняются при появлении нового устройства. Это происходит из-за того, что Р1 не создаёт новую метку при получении сигнализации от РЕ4 в силу того, что сообщаемая метка от РЕ4 принадлежит тому же FEC, что полученная ранее от PE1.


Однако на Р1 появляются новые метки (и это ожидаемо, т.к. РЕ4 произвёл дополнительную сигнализацию):


P1#show mpls mldp database               * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 3   Type: MP2MP   Uptime : 00:46:10  FEC Root           : 8.8.8.8   Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    8.8.8.8:0    [Active]      Expires        : Never         Path Set ID  : 9      Out Label (U)  : 8017          Interface    : GigabitEthernet2.58*      Local Label (D): 1014          Next Hop     : 10.5.8.8  Replication client(s):     1.1.1.1:0       Uptime         : 00:46:10      Path Set ID  : A      Out label (D)  : 10017         Interface    : GigabitEthernet2.15*      Local label (U): 1013          Next Hop     : 10.1.5.1    4.4.4.4:0       Uptime         : 00:02:11      Path Set ID  : B      Out label (D)  : 40017         Interface    : GigabitEthernet2.45*      Local label (U): 1012          Next Hop     : 10.4.5.4


Стоит создать дополнительный VRF C-TWO на РЕ4, как сигнализируется дополнительное дерево с новыми метками.


PE4(config)#ip vrf C-TWOPE4(config-vrf)# rd 4.4.4.4:2PE4(config-vrf)# vpn id 65001:2PE4(config-vrf)# mdt default mpls mldp 8.8.8.8PE4(config-vrf)# route-target export 65001:2PE4(config-vrf)# route-target import 65001:2

RR#show mpls mldp database   * For interface indicates MLDP recursive forwarding is enabled  * For RPF-ID indicates wildcard value  > Indicates it is a Primary MLDP MDT BranchLSM ID : 1   Type: MP2MP   Uptime : 00:54:07  FEC Root           : 8.8.8.8 (we are the root)  Opaque decoded     : [mdt 65001:1 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000100000000  Upstream client(s) :    None      Expires        : N/A           Path Set ID  : 1  Replication client(s):     5.5.5.5:0       Uptime         : 00:54:06      Path Set ID  : 2      Out label (D)  : 1014          Interface    : GigabitEthernet2.58*      Local label (U): 8017          Next Hop     : 10.5.8.5LSM ID : 2   Type: MP2MP   Uptime : 00:00:48  FEC Root           : 8.8.8.8 (we are the root)  Opaque decoded     : [mdt 65001:2 0]   Opaque length      : 11 bytes  Opaque value       : 02 000B 0650010000000200000000  Upstream client(s) :    None      Expires        : N/A           Path Set ID  : 3  Replication client(s):     5.5.5.5:0       Uptime         : 00:00:48      Path Set ID  : 4      Out label (D)  : 1019          Interface    : GigabitEthernet2.58*      Local label (U): 8018          Next Hop     : 10.5.8.5

Проверим связность между сайтами, находящимися за РЕ1 и РЕ4.


CE1#ping 230.0.0.1 source Lo0Type escape sequence to abort.Sending 1, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11 Reply to request 0 from 14.14.14.14, 15 ms

Связность есть, что хорошо. Однако, давайте задумаемся над одним вопросом по каком пути ходит трафик? Доходит ли он до корневого маршрутизатора и потом возвращается обратно (так называемый U-turn) или же P1 может передавать пакеты напрямую в сторону РЕ4?


Чтобы ответить на этот вопрос, проанализируем таблицу меток на Р1 и ROOT и дополнительное воспользуемся Wireshark.


Мы уже знаем, что для передачи многоадресного трафика РЕ1 будет использовать метку 1013 (см пояснения выше) (для интерфейса 802.1Q vlan id = 15). Это подтверждается дампом трафика.



Что делает Р1 при получении данной метки?


P1#show mpls forwarding-table labels 1013Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    Label      Label      or Tunnel Id     Switched      interface              1013       8017       [mdt 65001:1 0]  198024        Gi2.58     10.5.8.8               40017      [mdt 65001:1 0]  184856        Gi2.45     10.4.5.4 

На что здесь необходимо обратить пристальное внимание. P1 знает об этой метке, т.к он сам её сгенерировал (смотри вывод show mpls mldp database ранее). Ранее мы с Вами говорили о том, что РЕ передаёт пакет в сторону ROOT, а уже ROOT должен вернуть пакет обратно на заинтересованные РЕ. Однако в данном примере видно, что при получении пакета на Р1, он раздваивается и отправляется в сторону РЕ4 и ROOT. Т.е U-turn не происходит из-за того, что Р1 видит


  • Downstream сигнализацию от РЕ4
  • Upstream передачу данных от РЕ1

В результате Р1 коммутирует MPLS пакеты напрямую, отправляя на ROOT копию трафика.


На ROOT на текущий момент пакет должен быть уничтожен:


RR#show mpls forwarding-table | i 80178017       No Label   [mdt 65001:1 0]  0

Активируем VRF на всех остальных РЕ. В результате можем ожидать создания интерфейсов типа Lspvif на каждом РЕ устройстве и установление PIM соседства между ними.


PE1#show ip pim vrf C-ONE neighbor | i Lsp3.3.3.3           Lspvif0                  00:01:02/00:01:41 v2    1 / S P G2.2.2.2           Lspvif0                  00:01:09/00:01:40 v2    1 / S P G4.4.4.4           Lspvif0                  10:49:57/00:01:40 v2    1 / DR S P G

Дополнительно, проверим таблицу коммутации на ROOT и убедимся, что теперь для метки 8017 (которая была получена от Р1) есть собственная локальная метка.


RR#show mpls forwarding-table | i 80178017       2013       [mdt 65001:1 0]  982           Gi2.68     10.6.8.6 


Рассмотренный выше вариант реализации multicast VPN известен под кодовым именем Profile 1. Его основные характеристики:


  • Нет необходимости в P-PIM для опорной сети
  • В качестве PMSTI используется интерфейс Lspvif
  • Нет необходимости в специализированном адресном семействе BGP
  • Для передачи трафика используется Default MDT
  • Построение Default MDT осуществляется с помощью протокола mLDP.
    • Проблема с тем, что многоадресный трафик коммутируется в сторону всех РЕ (в рамках VPN) также присутствует, как и в Profile 0.
  • В качестве протокола многоадресной маршрутизации внутри C-VRF на опорной сети используется протокол PIM (автоматически активируется на интерфейсе Lspvif)

Продолжение следует...

Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 3 BGP Auto-Discovery)

25.11.2020 02:13:20 | Автор: admin

В прошлых выпусках мы с Вами познакомились с понятиями Default MDT, типами корневых деревьев и разобрали два варианта реализации mVPN на основе mGRE и mLDP:
Profile 0
Profile 1


На сегодняшний день адресное семейство BGP MDT (которое уже рассматривали) является устаревшим. Ему на замену пришло новое SAFI = multicast VPN (mVPN). Что нового приносит данное адресное семейство? Какие случаи использования могут быть? Попробуем разобраться.


Заинтересованным добро пожаловать под кат.


Авторы идеи предложили разделить сообщение BGP update на две составляющие:


  • Непосредственно mvpn NLRI. Внутри передаётся следующая информация:
    • Типа маршрута (значение от 1 до 7). У каждого маршрута своя функция.
  • Аттрибуты туннеля PMSI (PMSI Tunnel Attribute, PTA). Отвечают за передачу информации о типе корневого дерева.

Типы BGP mVPN маршрутов


Тип маршрута Имя Предназначение
1 Intra-AS I-PMSI A-D объявление РЕ в качестве mVPN участника для конкретного VPN. Это BGP Auto-Discovery.
2 Inter-AS I-PMSI A-D объявление ASBR в качестве mVPN участника для конкретного VPN. Используется для построения Inter-AS mVPN.
3 S-PMSI A-D объявление РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группыПереключение на Data MDT (подробнее разберёмся позднее)
4 Leaf A-D ответ на Inter-AS PMSI A-D или S-PMSI A-D в случае выставленного бита Leaf Information (LI)
5 Source Active A-D сообщение Source Active
6 Shared Tree Join эквивалент сообщения PIM (*, G) Join (или Prune)
7 Source Tree Join эквивалент сообщения PIM (S, G) Join (или Prune)

PTA


Тип туннеля определяет используемое корневое дерево и может принимать одно из следующих значений:


0 информация не представлена
1 RSVP-TE P2MP LSP
2 mLDP P2MP LSP
3 PIM-SSM
4 PIM-SM
5 BIDIR-PIM
6 Ingress Replication
7 mLDP MP2MP LSP


Дополнительные community


В зависимости от того, используется ли BGP для сигнализации многоадресного трафика в рамках VRF, у маршрутов могут появляться дополнительные коммьюнити.


VRF Route Import (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Импортирование многоадресных маршрутов (подобную функцию в vpnv4 выполняет аттрибут Route-Target)


Route Target Constraint (RTC)
Предназначение:
В случае наличия RTC, Route-Reflector (или любой другой РЕ) отправляет только желаемый vpnv4/vpnv6 префикс к РЕ. Желаемый обозначает, что на принимаемом РЕ есть один или более VRF, в который указанный префикс может быть импортирован.


Прим. Более подробно про RTC написано в RFC4684


Source-AS Extended Community (Добавляется к vpnv4/vpnv6 маршрутам)
Предназначение:
Передача AS информации для организации Inter-AS mVPN сценариев


PE Distinguisher Label
Предназначение:
Построение PPMP дерева для участия в Partitioned MDT (на текущий момент я не планирую рассматривать данное дерево в рамках цикла статей).


Поскольку с появлением SAFI mVPN функционал BGP очень расширился, то и применять данное SAFI можно для разных сценариев, в частности:


  • проведение Auto-Discovery
  • замена PIM сигнализации на BGP

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


Сначала рассмотрим случай когда в наложенной сети сохраняется PIM, но поиск заинтересованных РЕ происходит посредством BGP. Передача данных между РЕ осуществляется посредством GRE. Данная реализация известна под кодовым именем Profile 3.


Как и раньше, будем использовать следующую лабораторную топологию:



Начальные условия:


  • В рамках опорной сети:
    • настроен OSPF
    • настроен P-PIM в режиме SSM
      access-list 99 permit 239.1.1.0 0.0.0.255ip pim ssm range 99
      
  • В рамках VRF:
    • настроен C-PIM
    • нет активных источников или получателей трафика
  • VRF приведена к виду
    ip vrf C-ONErd 1.1.1.1:1route-target export 65001:1route-target import 65001:1
    

В первую очередь рассмотрим ситуацию, когда в рамках vrf C-ONE работает C-PIM SSM.


Настройка СЕ Настройка РЕ
access-list 99 permit 230.1.1.0 0.0.0.255
ip pim ssm range 99

access-list 98 permit 230.1.1.0 0.0.0.255
ip pim vrf C-ONE ssm range 98

На всех РЕ:


ip vrf C-ONEmdt auto-discovery pimmdt default 239.1.1.1

На РЕ устройствах поднимается новый PMSTI:


*Nov 24 20:44:40.941: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

PE1#show int tu2Tunnel2 is up, line protocol is upInterface is unnumbered. Using address of Loopback0 (1.1.1.1)Tunnel source 1.1.1.1 (Loopback0)Tunnel protocol/transport multi-GRE/IP

Пока что нет PIM соседства (т.к. РЕ не знают друг о друге):


*Nov 24 20:44:42.872: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel2

Активируем адресное семейство ipv4 mvpn:


router bgp 65001!address-family ipv4 mvpnneighbor MPLS_PE send-community extendedneighbor MPLS_PE route-reflector-clientneighbor 1.1.1.1 activateneighbor 2.2.2.2 activateneighbor 3.3.3.3 activateneighbor 4.4.4.4 activateexit-address-family

На РЕ моментально появляются соседи в рамках C-VRF:


PE1#show ip pim vrf C-ONE neighbor172.1.11.11    GigabitEthernet2.111   2w3d/00:01:19   v2  1 / DR S P G172.1.15.15    GigabitEthernet2.115   2w3d/00:01:35   v2  1 / DR S P G4.4.4.4      Tunnel2         00:00:17/00:01:27 v2  1 / DR S P G3.3.3.3      Tunnel2         00:00:17/00:01:27 v2  1 / S P G2.2.2.2      Tunnel2         00:00:47/00:01:27 v2  1 / S P G

И соответствующие (S, G) деревья:


PE1#show ip mroute 239.1.1.1(1.1.1.1, 239.1.1.1), 00:00:45/00:02:44, flags: sTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.15, Forward/Sparse, 00:00:45/00:02:44(4.4.4.4, 239.1.1.1), 00:00:49/00:02:10, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:00:49/00:02:10(3.3.3.3, 239.1.1.1), 00:00:53/00:02:06, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:00:53/00:02:06(2.2.2.2, 239.1.1.1), 00:01:19/00:01:40, flags: sTIZIncoming interface: GigabitEthernet2.15, RPF nbr 10.1.5.5Outgoing interface list:MVRF C-ONE, Forward/Sparse, 00:01:19/00:01:40

Как РЕ смогли увидеть друг друга? Ответ на этот вопрос нам даст анализ BGP таблицы:


PE1#show bgp ipv4 mvpn allBGP table version is 258, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i  internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i  IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Как видим, каждый РЕ маршрутизатор создал BGP IPv4 mvpn маршрут первого типа, в котором описал себя


PE1#show bgp ipv4 mvpn all route-type 1 4.4.4.4BGP routing table entry for [1][1.1.1.1:1][4.4.4.4]/12, version 262Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Not advertised to any peerRefresh Epoch 1Local, imported path from [1][4.4.4.4:1][4.4.4.4]/12 (global)4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestCommunity: no-exportExtended Community: RT:65001:1Originator: 4.4.4.4, Cluster list: 8.8.8.8PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101rx pathid: 0, tx pathid: 0x0BGP routing table entry for [1][4.4.4.4:1][4.4.4.4]/12, version 265Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Not advertised to any peerRefresh Epoch 1Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestCommunity: no-exportExtended Community: RT:65001:1Originator: 4.4.4.4, Cluster list: 8.8.8.8PMSI Attribute: Flags: 0x0, Tunnel type: 3, length 8, label: exp-null, tunnel parameters: 0404 0404 EF01 0101rx pathid: 0, tx pathid: 0x0

Обратите внимание на PTA:


  • Tunnel type: 3 говорит нам о том, что в рамках vrf использует SSM PIM
  • tunnel parameters сообщает нам об адресе РЕ и группе многоадресной рассылки (EF01 0101 = 239.1.1.1)

Подключим клиента:


CE4(config-if)#ip igmp join-group 230.1.1.1 source 11.11.11.11

На РЕ этого сайта появляется многоадресный маршрут:


PE4#show ip mroute vrf C-ONE(11.11.11.11, 230.1.1.1), 00:00:11/00:03:18, flags: sTIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:11/00:03:18

В качестве RPF nbr указан адрес 1.1.1.1 как PE4 вычисляет его? На самом деле очень просто. Это адрес BGP next-hop для источника = 11.11.11.11


PE4#show ip route vrf C-ONE 11.11.11.11Routing Table: C-ONERouting entry for 11.11.11.11/32  Known via "bgp 65001", distance 200, metric 0  Tag 65011, type internal  Last update from 1.1.1.1 01:02:10 ago  Routing Descriptor Blocks:  * 1.1.1.1 (default), from 8.8.8.8, 01:02:10 ago      Route metric is 0, traffic share count is 1      AS Hops 1      Route tag 65011      MPLS label: 10018      MPLS Flags: MPLS Required

Соответственно, РЕ4 генерирует PIM Join и отправляет его в рамках Default MDT:



Данный PIM Join будет получен всеми РЕ, но обработан только на РЕ1 (т.к. только на нём Join пройдет RPF проверку)


PE1#show ip mroute vrf C-ONE | b \((11.11.11.11, 230.1.1.1), 00:01:16/00:03:11, flags: sTIncoming interface: GigabitEthernet2.111, RPF nbr 172.1.11.11Outgoing interface list:Tunnel2, Forward/Sparse, 00:01:16/00:03:11

PE2#show ip mroute vrf C-ONE | b \(PE2#

Проверим работоспособность сервиса:


CE1#pingTarget IP address: 230.1.1.1Repeat count [1]: 5Extended commands [n]: yInterface [All]: GigabitEthernet2.111Source address or interface: 11.11.11.11Sending 5, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 8 msReply to request 3 from 14.14.14.14, 8 msReply to request 4 from 14.14.14.14, 7 ms

Как видно, многоадресные пакеты корректно передаются через опорную сеть. При этом стоит отметить, что способ передачи пакетов ничем не отличается от того, что мы с Вами наблюдали в рамках Profile0. Т.е. пакеты долетают до всех РЕ в рамках Default MDT и уже там отбрасываются в случае отсутствия активных подписчиков.



В этом можно убедиться, сняв дамп трафика на сети как это показано на рисунке ниже (vlan id = 37 характеризует интерфейс между R3 и R7):



Выше мы рассмотрели случай использования PIM SSM внутри C-VRF. Изменится ли что-либо, если будет работать PIM ASM?


CE4(config-if)#interface Lo0CE4(config-if)#ip igmp version 2CE4(config-if)#no ip igmp join-group 230.1.1.1 source 11.11.11.11CE4(config-if)#ip igmp join-group 231.1.1.1!CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0!CE15(config)#access-list 1 permit 231.1.1.0 0.0.0.255CE15(config)#ip pim bsr-candidate Lo0CE15(config)#ip pim rp-candidate Lo0 group-list 1

На РЕ сайта появляется дополнительный туннельный интерфейс для PIM encap:


PE1#*Nov 24 21:39:32.938: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

Все маршрутизаторы внутри C-VRF корректно узнают о появившихся RP и BSR устройствах в сети:


CE1#show ip pim bsr-routerPIMv2 Bootstrap informationBSR address: 15.15.15.15 (?)Uptime:   00:01:54, BSR Priority: 0, Hash mask length: 0Expires:   00:01:16

До тех пор, пока нет активного источника трафика, внутри C-VRF будут наблюдаться только (*, G) маршруты согласно обычной логике работы PIM ASM:


PE4#show ip mroute vrf C-ONETimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 231.1.1.2), 00:00:46/00:02:43, RP 15.15.15.15, flags: SIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:46/00:02:43

При этом внутри BGP домена не появляется никаких дополнительных mvpn префиксов:


PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>i [1][1.1.1.1:1][1.1.1.1]/121.1.1.1         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1 (default for vrf C-ONE)*>i [1][4.4.4.4:1][1.1.1.1]/121.1.1.1         0  100   0 ?*>i [1][4.4.4.4:1][2.2.2.2]/12Network     Next Hop      Metric LocPrf Weight Path2.2.2.2         0  100   0 ?*>i [1][4.4.4.4:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>  [1][4.4.4.4:1][4.4.4.4]/12


Почему? спросите Вы? Потому что для сигнализации многоадресного трафика C-VRF используется протокол PIM.


О возможной замене сигнализации на BGP поговорим в следующий раз.

Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 4 BGP сигнализация)

27.11.2020 00:13:20 | Автор: admin
В предыдущих выпусках:

Profile 0
Profile 1
Profile 3

В этой части статьи мы рассмотрим с Вами вариант замены сигнализации в рамках наложенной сети с протокола PIM на BGP.

Как рассматривалось ранее (см статью про BGP Auto-Discovery), для того чтобы передавать аналоги PIM сообщений, в BGP было придумано несколько типов маршрутов, каждый из которых несёт в себе определённый функционал. При этом типов маршрутов больше, чем есть типов сообщений у PIM.



Зачем натягивать сову на глобус? можете спросить Вы, ведь всё прекрасно работает и с PIM. И, в общем-то, будете правы. Основной причиной эдакого ходя конём является масштабируемость. PIM, являясь по сути своей Soft Driven протоколом, требует для своей работы постоянной рассылки служебных сообщений, что при определённом размере внедрения (если количество узлов начинает переваливать за пару сотен или тысяч) привносит ограничения в связи с неизбежной загрузкой CPU. BGP же является Hard Driven протоколом т.е. если что-то было сказано однажды, то не повторяется; любые BGP обновления вызваны исключительно изменениями в сети.

Сегодня мы с Вами рассмотрим два сценария: использование PIM SSM и PIM ASM в рамках C-VRF.

C-PIM SSM


Для более простого понимания BGP сигнализации для построения многоадресных деревьев, начнём наш разговор с более простого PIM SSM.

Прежде всего, уберём текущие настройки точки рандеву и отключим получателей трафика:

CE4(config)#interface Loopback0CE4(config-if)#no ip igmp join-group 231.1.1.2CE4(config-if)#CE15(config)#no ip pim bsr-candidate Loopback0 0CE15(config)#no ip pim rp-candidate Loopback0 group-list 1

На всех РЕ укажем, что для сигнализации вместо PIM будет работать BGP. Это делается следующей командой:

ip vrf C-ONEmdt overlay use-bgp

Отправной точкой наблюдений будет ситуация без наличия источников и получателей многоадресного трафика. В BGP таблице должны присутствовать только type-1 маршруты:

PE1#show bgp ipv4 mvpn allBGP table version is 406, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Подключим получателя:

CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11

На ближайшем РЕ создаётся BGP маршрут 7-го типа это эквивалент сообщения PIM (S, G) Join:

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/220.0.0.0              32768 ?

По логике вещей, данный маршрут должен присутствовать только на РЕ4 и на РЕ1 (т.к именно через них должен проходить трафик) и отсутствовать на РЕ2 и РЕ3. Проверим:

PE1#show bgp ipv4 mvpn all | b \[7\]*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/224.4.4.4         0  100   0 ?PE2#show bgp ipv4 mvpn all | b \[7\]PE2#PE3#show bgp ipv4 mvpn all | b \[7\]PE3#

Как так получается, что маршрут, изначальной порождённый на РЕ4, импортируется только на РЕ1?

Посмотрим на запись в BGP-таблице чуть детальнее:

PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:7Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В записи префикса присутствует расширенное коммьюнити Route-target = 1.1.1.1:1, которое было добавлено в vpnv4 префикс маршрутизатором, который с точки РЕ4 является RPF соседом:

PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1     17Refresh Epoch 465011172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)Origin IGP, metric 0, localpref 100, valid, external, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1mpls labels in/out 10018/nolabelrx pathid: 0, tx pathid: 0x0PE1#PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 15265011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10018rx pathid: 0, tx pathid: 0x0

Проверим связность:

CE1#ping 230.1.1.1 so 11.11.11.11 rep 3Type escape sequence to abort.Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:Packet sent with a source address of 11.11.11.11Reply to request 0 from 14.14.14.14, 7 msReply to request 0 from 14.14.14.14, 8 msReply to request 1 from 14.14.14.14, 7 msReply to request 1 from 14.14.14.14, 9 msReply to request 2 from 14.14.14.14, 7 msReply to request 2 from 14.14.14.14, 7 ms

C-PIM ASM


В случае работы C-PIM в режиме SSM всё довольно просто. Для корректной работы mVPN достаточно создания двух дополнительных (типов) BGP маршрутов.

А как обстоят дела, если внутри C-VRF используется более комплексный ASM PIM?

Прежде всего мы видим, что на всех СЕ известна информация о точке рандеву:

CE2#show ip pim rp mappCE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 231.1.1.0/24RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 1d04h, expires: 00:02:09CE2#

Как? Если мы посмотрим BGP таблицу, то не найдём там никакого намёка на эту точку:

PE1#show bgp ipv4 mvpn allBGP table version is 682, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?

Не надо забывать о том, что у нас есть PMSTI, на котором активирован PIM:

PE1#show ip pim vrf C-ONE interfaceAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Tunnel2         v2/S  0   30   1     1.1.1.1



Отсюда можно сделать важный вывод некоторые сообщения PIM (даже при BGP сигнализации) передаются поверх опорной сети в рамках Default MDT.


Представим, что в сети появился источник (за маршрутизатором СЕ2). Поскольку на СЕ2 на данный момент нет записей в mRIB, то PIM Designated Router (в нашем случае это сам СЕ2) отправляет сообщение Register на точку рандеву, тем самым сигнализируя о наличии активного источника в сети.


На точке рандеву создаётся дерево (12.12.12.12, 231.1.1.1):

CE5#show ip mroute | b \((*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SPIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list: Null(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: PIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

И, поскольку, в сети нет активных получателей трафика (отсутствует дерево (*, 231.1.1.1)), то со стороны CE5 создаётся сообщение Register-Stop



В ответ на получение Register-Stop, CE2 приостанавливает передачу данных (нет интерфейсов в OIL):

CE2#show ip mroute 231.1.1.1(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFTIncoming interface: Loopback0, RPF nbr 0.0.0.0Outgoing interface list: Null

Теперь представим, что в сети появился получатель, заинтересованный в трафике для группы 231.1.1.1. На РЕ4 появляется маршрут внутри C-VRF:

PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \((*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45

И создаётся BGP маршрут 6-го типа, который является эквивалентом PIM Join (*, 231.1.1.1):

PE4#show bgp ipv4 mvpn allRoute Distinguisher: 1.1.1.1:1*>  [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/220.0.0.0              32768 ?PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (4.4.4.4)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

В приведённом выше выводе необходимо обратить внимание на расширенное коммьюнити Route-target = 1.1.1.1:1. Что это и откуда взялось?

Проверим наличие данного префикса на других РЕ:

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1% Network not in tablePE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698Paths: (1 available, best #1, table MVPNv4-BGP-Table)Not advertised to any peerRefresh Epoch 2Local4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)Origin incomplete, metric 0, localpref 100, valid, internal, bestExtended Community: RT:1.1.1.1:1Originator: 4.4.4.4, Cluster list: 8.8.8.8rx pathid: 0, tx pathid: 0x0

Т.е. префикс существует только на РЕ1. Что интересно, так это тот факт, что точка рандеву (15.15.15.15) находится именно на сайте за РЕ1.

Зная назначение Route-target (импорт маршрутов внутрь определённой VRF) напрашивается вывод RT = 1.1.1.1:1 известен РЕ1 и неизвестен РЕ2/PE3. Т.е очевиден факт, что РЕ4 сгенерировал BGP маршрут, описывающий PIM Shared Tree Join таким образом, чтобы он был обработан только на том РЕ, за которым в действительности находится точка рандеву (по факту, это аналог передачи PIM Join через RPF интерфейс). Но каким образом РЕ1 и РЕ4 согласуют между собой значения Route-target?

PE4 проводит RPF для адреса точки рандеву:

PE4#show ip rpf vrf C-ONE 15.15.15.15RPF information for ? (15.15.15.15)RPF interface: Tunnel0RPF neighbor: ? (1.1.1.1)RPF route/mask: 15.15.15.15/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 1.1.1.1RPF topology: ipv4 multicast base, originated from ipv4 unicast base

В качестве RPF соседа виден РЕ1. Значит, РЕ4 должен поместить внутрь маршрута 6-го типа такой Route-target, который будет импортирован только РЕ1. Чтобы ответить на вопрос откуда РЕ4 его знает? посмотрим, для начала, на vpn маршрут:

PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 165015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1Originator: 1.1.1.1, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 1.1.1.1:1:1.1.1.1mpls labels in/out nolabel/10013rx pathid: 0, tx pathid: 0x0

Обратите внимание на дополнительное коммьюнити MVPN VRF:1.1.1.1:1. Это ничто иное, как коммьюнити Route Import, сгенерированное РЕ1. Именно это значение копируется как Route-target внутрь многоадресного маршрута, что позволяет РЕ1 импортировать полученный апдейт от РЕ4.

Результатом обработки BGP маршрут 6-го типа на РЕ4 является создание записи в многоадресной таблице маршрутизации:

PE4#show ip mroute vrf C-ONE(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: SgIncoming interface: Tunnel0, RPF nbr 1.1.1.1Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33

Прим обратите внимание, что входным интерфейсом указан Tunnel0 (PMSTI).

На точке рандеву завершается создание общего дерева:

CE5#show ip mroute | b \((*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22



Теперь, если в сети опять появится активный источник трафика, точка рандеву будет знать как совместить (*, 231.1.1.1) и (12.12.12.12, 231.1.1.1) деревья.

CE5#show ip mroute | b \((*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: SIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PTIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1Outgoing interface list: Null

Точка рандеву создаёт PIM Join (12.12.12.12, 231.1.1.1), отправляя его в сторону CE2. PE1 получает указанный PIM Join и создаёт BGP маршрут 7-го типа:

PE1#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1*>  [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/220.0.0.0              32768 ?PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:2.2.2.2:1rx pathid: 1, tx pathid: 0x0

Обратите внимание, что в качестве Remote VPN RD выставляется значение 2.2.2.2:1, т.к. именно через РЕ2 завершается RPF проверка маршрута:

PE1#show ip rpf vrf C-ONE 12.12.12.12RPF information for ? (12.12.12.12)RPF interface: Tunnel2RPF neighbor: ? (2.2.2.2)RPF route/mask: 12.12.12.12/32RPF type: unicast (bgp 65001)Doing distance-preferred lookups across tablesBGP originator: 2.2.2.2RPF topology: ipv4 multicast base, originated from ipv4 unicast base

И RT 2.2.2.2:1 был добавлен в VPNv4 префикс со стороны РЕ2:

PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706Paths: (1 available, best #1, table C-ONE)Advertised to update-groups:1Refresh Epoch 265012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)Origin IGP, metric 0, localpref 100, valid, internal, bestExtended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1Originator: 2.2.2.2, Cluster list: 8.8.8.8Connector Attribute: count=1type 1 len 12 value 2.2.2.2:1:2.2.2.2mpls labels in/out nolabel/31rx pathid: 0, tx pathid: 0x0

На этом шаге, по сути, завершается построение дерева (12.12.12.12, 231.1.1.1) на участке между источником и точкой рандеву:


После получения маршрута 7-го типа, РЕ2 генерирует маршрут 5-го типа, сигнализируя о наличии активного источника трафика в сети. Маршрут импортируется всеми РЕ устройствами.

PE2#show bgp ipv4 mvpn allRoute Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)*>  [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/180.0.0.0              32768 ?PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:8Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1rx pathid: 0, tx pathid: 0x0

При получении маршрута 5-го типа, на РЕ4 (где находится получатель) завершается создание многоадресного дерева:

PE4#show ip mroute vrf C-ONE(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQIncoming interface: Tunnel0, RPF nbr 2.2.2.2Outgoing interface list:GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19

Прим обратите внимание на флаг Q, который говорит о том, что запись была создана благодаря сообщению BGP Source-Active


Рассмотренный вариант организации mVPN носит кодовое имя Profile 11. Его основные характеристики:

  • для передачи многоадресного трафика наложенной сети используется Default MDT
  • в качестве метода организации транспорта выступает протокол mGRE
  • для сигнализации многоадресного дерева в рамках наложенной сети используется протокол BGP
Подробнее..

Внедрение Multicast VPN на Cisco IOS (часть 5 знакомство с DataPartitioned MDT)

05.12.2020 22:10:10 | Автор: admin
В предыдущих выпусках:

Profile 0
Profile 1
Profile 3
Profile 11

Как мы узнали из прошлых записей, в опорной сети при реализации mVPN всегда присутствует конструкция Default MDT, к которой подключены все РЕ маршрутизаторы. В рамках данного MDT передаются служебные сообщения PIM (например Bootstrap, Auto-RP), а также пользовательский многоадресный трафик. В результате получается, что какие-то РЕ устройства получают даже тот трафик, на который они не подписывались.

Если хотите узнать как с этим бороться добро пожаловать под кат!



Для того чтобы повысить эффективность передачи данных используется дополнительная конструкция, которая именуется как Data MDT. Идея, которая лежит в её основе, заключается в следующем:
  • В рамках дерева распространяется только C-(S, G) трафик
  • Участниками дерева становятся только те Egress PE, у которых есть заинтересованные получатели
  • Корневым устройством Data MDT является Ingress PE (маршрутизатор, за которым находится источник)


Визуально это выглядит следующим образом:



Если представить ситуацию, в которой источник начинает вещать на вторую многоадресную группу (230.1.1.2), получатели для которой находятся только за РЕ2 и РЕ3, то создаётся дополнительное Data MDT и общая картинка приобретает вид (Default MDT опущено):



Сигнализация по переключению трафика от Default MDT к Data MDT осуществляется исключительно по-требованию при превышении заданного порога со стороны Ingress PE либо средствами PIM, либо средствами BGP.



Data MDT с помощью PIM


Если для сигнализации используется PIM, то ingress PE генерирует специальное сообщение PIM Data-MDT TLV и отправляет его в рамках Default MDT чтобы быть уверенным в том, что все РЕ смогут получить данное сообщение. Одновременно с отправкой Data MDT TLV, Ingress PE запускает таймер, равный трём секундам. По истечении таймера, все пакеты будут передаваться в рамках Data MDT.

Также необходимо отметить тот факт, что информация, содержащаяся в Data-MDT TLV кешируется на всех РЕ. Причина тому довольно банальна даже если в текущий момент на конкретном РЕ нет заинтересованных получателей трафика, они могут появиться там спустя некоторое время. Соответственно, при получении PIM Join (внутри C-VRF) PE может моментально подключиться к уже существующему на сети Data MDT.

Прим. Data-MDT TLV передаются раз в минуту.

Каждое Data MDT устанавливается для отдельного (S, G) маршрута в рамках VPN/VRF. Администратору необходимо явно указать максимальное количество Data MDT, которое может быть создано на устройстве. Если в какой-то момент количество вновь устанавливаемых деревьев достигает заданного предела, то следующие деревья будут переиспользовать уже установленные.

Прим. На момент написания статьи, Cisco IOS не поддерживает PIM сигнализацию поверх Data MDT. Все профили с данной сигнализацией доступны только на операционной системе IOS XR.

Data MDT с помощью BGP


При использовании BGP в наложенной сети для сигнализации Data MDT, основные принципы остаются неизменными (по сравнению с PIM):
  • ingress PE сигнализирует всем РЕ о том, что трафик для C-(S,G) будет передаваться в рамках Data MDT
  • egress PE при получении BGP апдейта присоединяется к указанному дереву
  • для сигнализации используется адресное семейство mVPN (sAFI 129).


Получается, что Ingress PE должен сформировать специальное BGP Update сообщение и отправить его всем РЕ в рамках mVPN. Для этого используется маршрут третьего типа.

Profile 14


Рассмотрим описанный переход на примере нашей лаборатории. В частности, применим конфигурацию, известную как Profile 14. Данный профиль характеризуется использованием BGP mVPN A-D для построения P2MP MLDP LSP.

На РЕ будем использовать следующий шаблон конфигурации:

ip vrf C-ONE
mdt auto-discovery mldp
mdt partitioned mldp p2mp
mdt overlay use-bgp
mdt strict-rpf interface
!
router bgp 1
address-family ipv4 mvpn
neighbor 8.8.8.8 activate
neighbor 8.8.8.8 send-community extended
exit-address-family


Прим. о предназначении команды mdt strict-rpf interface поговорим в следующем выпуске.

Auto-Discovery


Посмотрим, что происходит на РЕ1:

На каждом РЕ создаётся интерфейс Lspvif0, на котором активируется C-PIM.

*Dec 3 10:04:54.450: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up

Никаких соседей на данный момент нет:

PE1#show ip pim vrf C-ONE intAddress     Interface        Ver/  Nbr  Query DR     DRMode  Count Intvl Prior172.1.11.1    GigabitEthernet2.111   v2/S  1   30   1     172.1.11.11172.1.15.1    GigabitEthernet2.115   v2/S  1   30   1     172.1.15.151.1.1.1     Lspvif0         v2/S  0   30   1     1.1.1.1


Посмотрим BGP таблицу:

PE1#show bgp ipv4 mvpn allBGP table version is 39, local router ID is 1.1.1.1Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,x best-external, a additional-path, c RIB-compressed,t secondary path,Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not foundNetwork     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [1][1.1.1.1:1][1.1.1.1]/120.0.0.0              32768 ?*>i [1][1.1.1.1:1][2.2.2.2]/122.2.2.2         0  100   0 ?*>i [1][1.1.1.1:1][3.3.3.3]/123.3.3.3         0  100   0 ?*>i [1][1.1.1.1:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 2.2.2.2:1*>i [1][2.2.2.2:1][2.2.2.2]/122.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1Network     Next Hop      Metric LocPrf Weight Path*>i [1][3.3.3.3:1][3.3.3.3]/123.3.3.3         0  100   0 ?Route Distinguisher: 4.4.4.4:1*>i [1][4.4.4.4:1][4.4.4.4]/124.4.4.4         0  100   0 ?Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)*>  [3][1.1.1.1:1][*][*][1.1.1.1]/140.0.0.0              32768 ?*>i [3][1.1.1.1:1][*][*][2.2.2.2]/142.2.2.2         0  100   0 ?*>i [3][1.1.1.1:1][*][*][3.3.3.3]/143.3.3.3         0  100   0 ?*>i [3][1.1.1.1:1][*][*][4.4.4.4]/144.4.4.4         0  100   0 ?*>  [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/180.0.0.0              32768 ?Route Distinguisher: 2.2.2.2:1*>i [3][2.2.2.2:1][*][*][2.2.2.2]/142.2.2.2         0  100   0 ?Route Distinguisher: 3.3.3.3:1*>i [3][3.3.3.3:1][*][*][3.3.3.3]/143.3.3.3         0  100   0 ?Network     Next Hop      Metric LocPrf Weight PathRoute Distinguisher: 4.4.4.4:1*>i [3][4.4.4.4:1][*][*][4.4.4.4]/144.4.4.4         0  100   0 ?


Как видно, в дополнение к уже рассмотренным ранее маршрутам первого типа, добавляются маршруты третьего типа S-PMSI A-D, которые используются для объявления РЕ в качестве Ingress маршрутизатора для конкретной C-(S,G) группы. На текущий момент группа равна (*, *). Это говорит о желании РЕ участвовать в построении Partitioned MDT.

Очевидно, чтобы заработала передача данных, в рамках VRF должна быть известна информация о точке рандеву. В нашем случае в качестве RP и BSR выступает CE15.

C-RP#sh run | i pimip pim bsr-candidate Loopback0 0ip pim rp-candidate Loopback0

Поскольку у C-RP построено PIM соседство с PE1, то на этом РЕ1 информация об RP также известна:

PE1#show ip pim vrf C-ONE rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 224.0.0.0/4RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 01:25:50, expires: 00:01:26

Необходимо доставить эту информацию до всех остальных PE/CE. Как это сделать? Чтобы лучше понять принцип, предлагаю пойти от обратного и начать просмотра уже известной информации на СЕ2:

CE2#show ip pim rp mappingAuto-RP is not enabledPIM Group-to-RP MappingsGroup(s) 224.0.0.0/4RP 15.15.15.15 (?), v2Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150Uptime: 01:27:54, expires: 00:02:26

Как видим, сообщения PIM BSR распространилось по mVPN инфраструктуре. Посмотрим дамп трафика на РЕ1:


Как видим PE1 инкапсулирует сообщение PIM BSR внутрь MPLS и помечает его меткой 28. Откуда она берётся? Можем предположить, что поскольку этот пакет достиг СЕ2 (а значит и РЕ2), то есть некий LSP до РЕ2.

PE2#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 1  Type: P2MP  Uptime : 04:17:40FEC Root      : 2.2.2.2 (we are the root)Opaque decoded   : [gid 65536 (0x00010000)]Opaque length   : 4 bytesOpaque value    : 01 0004 00010000Upstream client(s) :NoneExpires    : N/A      Path Set ID : 1Replication client(s):>  MDT (VRF C-ONE)Uptime     : 04:17:40   Path Set ID : NoneInterface   : Lspvif0    RPF-ID    : *LSM ID : 3  Type: P2MP  Uptime : 01:30:06FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :6.6.6.6:0  [Active]Expires    : Never     Path Set ID : 3Out Label (U) : None     Interface  : GigabitEthernet2.26*Local Label (D): 34      Next Hop   : 10.2.6.6Replication client(s):MDT (VRF C-ONE)Uptime     : 01:30:06   Path Set ID : NoneInterface   : Lspvif0    RPF-ID    : *

Из анализа базы mLDP видно, что на РЕ2 есть некое дерево (LSM ID: 3), корнем которого является PE1 (IP = 1.1.1.1), Opaque = 01 0004 0001FFFF и для этого дерева сгенерирована локальная метка 34, которая отправлена соседу R6 (P2).

Откуда РЕ2 узнал о дереве, корнем которого является PE1 да ещё и получил Opaque для него? Ответ прост с помощью BGP маршрута третьего типа.

Когда РЕ1 получил PIM BSR, то сгенерировал дополнительный BGP маршрут, который описывает группу (*, 224.0.0.13) (напоминаю, что это зарезервированный адрес для рассылки всех служебных PIM сообщений). Этот маршрут служит для объявления нового многоадресного mLDP дерева. Внутри РТА указано Opaque значение, которое необходимо использовать для сигнализации посредством mLDP.

PE1#show bgp ipv4 mvpn all route-type 3 * 224.0.0.13 1.1.1.1BGP routing table entry for [3][1.1.1.1:1][*][224.0.0.13][1.1.1.1]/18, version 116Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)Advertised to update-groups:1Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (1.1.1.1)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestCommunity: no-exportExtended Community: RT:65001:1PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 17, label: exp-null, tunnel parameters: 0600 0104 0101 0101 0007 0100 0400 01FF FFrx pathid: 0, tx pathid: 0x0

Таким образом, РЕ2 импортируя этот маршрут, может начать mLDP сигнализацию в сторону РЕ1 для дерева (*, 224.0.0.13). Для полученной от РЕ2 метки, Р2 (R6) генерирует свой собственную локальную (29) и отправляет её в сторону P1 (R5):

P2#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 2  Type: P2MP  Uptime : 01:40:24FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :5.5.5.5:0  [Active]Expires    : Never     Path Set ID : 2Out Label (U) : None     Interface  : GigabitEthernet2.56*Local Label (D): 29      Next Hop   : 10.5.6.5Replication client(s):2.2.2.2:0Uptime     : 01:40:24   Path Set ID : NoneOut label (D) : 34      Interface  : GigabitEthernet2.26*Local label (U): None     Next Hop   : 10.2.6.2

Аналогичным образом поступает и Р1 (R5), генерируя свою локальную метку для дерева и отправляя её к РЕ1:

P1#show mpls mldp database* For interface indicates MLDP recursive forwarding is enabled* For RPF-ID indicates wildcard value> Indicates it is a Primary MLDP MDT BranchLSM ID : 2  Type: P2MP  Uptime : 01:41:24FEC Root      : 1.1.1.1Opaque decoded   : [gid 131071 (0x0001FFFF)]Opaque length   : 4 bytesOpaque value    : 01 0004 0001FFFFUpstream client(s) :1.1.1.1:0  [Active]Expires    : Never     Path Set ID : 2Out Label (U) : None     Interface  : GigabitEthernet2.15*Local Label (D): 28      Next Hop   : 10.1.5.1Replication client(s):4.4.4.4:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 34      Interface  : GigabitEthernet2.45*Local label (U): None     Next Hop   : 10.4.5.47.7.7.7:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 30      Interface  : GigabitEthernet2.57*Local label (U): None     Next Hop   : 10.5.7.76.6.6.6:0Uptime     : 01:41:24   Path Set ID : NoneOut label (D) : 29      Interface  : GigabitEthernet2.56*Local label (U): None     Next Hop   : 10.5.6.6

Визуально весь процесс представлен на рисунке ниже:


Присоединение к Shared Tree и построение корневого P2MP дерева (ROOT = RP-PE)


Шаг 2. В сети появляется получатель трафика. После того как Egress PE (РЕ2) получает PIM Join от CE для C-(*, G), PE2 производит RPF проверку чтобы найти BGP Next-Hop в сторону C-RP. Найденный Next-Hop (1.1.1.1) будет использоваться как Partitioned MDT ROOT для mLDP.

Дополнительно РЕ2 создаёт интерфейс Lspvif внутри C-VRF:

PE2#*Dec 3 14:46:21.606: %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to upPE2#*Dec 3 14:46:22.310: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1

Шаг 3. Egress PE (PE2) генерирует сообщение mLDP mapping в сторону RP-PE (ROOT P2MP MDT) используя Opaque значение из BGP апдейта.

PE2#show mpls mldp database summaryLSM ID   Type  Root       Decoded Opaque Value     Client Cnt.4     P2MP  1.1.1.1      [gid 65536 (0x00010000)]   11     P2MP  2.2.2.2      [gid 65536 (0x00010000)]   13     P2MP  1.1.1.1      [gid 131071 (0x0001FFFF)]   1PE2#PE2#show mvpn ipv4 vrf C-ONE auto-discovery s-pmsi * * detailI-PMSI - Intra-AS Inclusive-PMSI, S-PMSI - Selective-PMSI* - Indicates Wildcard source or group address[S-PMSI][1.1.1.1:1][*][*][1.1.1.1], JoinedOrig: Remote Uptime: 04:44:27 Type: MLDP P2MPRoot: 1.1.1.1 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][3.3.3.3:1][*][*][3.3.3.3],Orig: Remote Uptime: 04:44:22 Type: MLDP P2MPRoot: 3.3.3.3 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][4.4.4.4:1][*][*][4.4.4.4],Orig: Remote Uptime: 04:44:20 Type: MLDP P2MPRoot: 4.4.4.4 Fec-Opq: 1 Global-Id: 65536 (0x10000)[S-PMSI][2.2.2.2:1][*][*][2.2.2.2], JoinedOrig: Local Uptime: 04:44:24 Type: MLDP P2MPRoot: 2.2.2.2 Fec-Opq: 1 Global-Id: 65536 (0x10000)PE2#show mpls mldp database opaque_type gid 65536LSM ID : 4  Type: P2MP  Uptime : 00:03:43FEC Root      : 1.1.1.1Opaque decoded   : [gid 65536 (0x00010000)]Opaque length   : 4 bytesOpaque value    : 01 0004 00010000Upstream client(s) :6.6.6.6:0  [Active]Expires    : Never     Path Set ID : 4Out Label (U) : None     Interface  : GigabitEthernet2.26*Local Label (D): 35      Next Hop   : 10.2.6.6Replication client(s):MDT (VRF C-ONE)Uptime     : 00:03:43   Path Set ID : NoneInterface   : Lspvif1    RPF-ID    : 0x1

Шаг 4. Egress PE генерирует BGP маршрут шестого типа (присоединение к Shared Tree в сторону RP-PE). Данный маршрут импортируется только на RP-PE.

PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 230.1.1.1BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][230.1.1.1/32]/22, version 130Paths: (1 available, best #1, table MVPNv4-BGP-Table)Advertised to update-groups:1Refresh Epoch 1Local0.0.0.0 from 0.0.0.0 (2.2.2.2)Origin incomplete, localpref 100, weight 32768, valid, sourced, local, bestExtended Community: RT:1.1.1.1:1rx pathid: 1, tx pathid: 0x0

Шаг 5. RP-PE транслирует полученный BGP маршрут шестого типа в PIM Join в сторону RP. На этот момент RP готово к отправке многоадресного трафика в сторону Egress PE. Необходимо доставить трафик от источника до RP.

PE1#show ip mroute vrf C-ONE | b \((*, 230.1.1.1), 00:07:08/stopped, RP 15.15.15.15, flags: SGIncoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.15Outgoing interface list:Lspvif0, Forward/Sparse, 00:07:08/stopped



Шаг 6. Когда S-PE (PE4) получает первый многоадресный пакет от источника (CE4), трафик инкапсулируется внутрь сообщения PIM Register и отправляется как одноадресный пакет в сторону C-RP (используя обычные правила MPLS L3 VPN).

Шаг 7. После получения PIM Register, C-RP начинает процесс построения дерева С-(14.14.14.14, 230.1.1.1). RP-PE получает PIM Join для C-(14.14.14.14, 230.1.1.1) от C-RP. Данное сообщение транслируется в BGP маршрут седьмого типа. Однако, перед отправкой в сторону источника, необходимо построить новое дерево Partitioned MDT с РЕ в качестве ROOT.


Шаг 8. RP-PE производит RPF проверку чтобы найти BGP Next-Hop в сторону источника. Данный адрес будет использоваться как Partitioned MDT ROOT для mLDP.

Шаг 9. Используя полученный BGP Next-Hop и BGP маршрут третьего типа от Ingress PE, RP-PR генерирует сообщение mLDP mapping в сторону IP адреса Ingress PE, тем самым строя корневое P2MP дерево до Ingress PE.

Шаг 10. RP-PE отправляет BGP маршрут седьмого типа (Join от RP) в сторону Ingress PE.

Шаг 11. Ingress PE преобразует полученный BGP маршрут седьмого типа в PIM Join и отправляет его в сторону источника трафика.


Присоединение к Source Tree и построение P2MP (ROOT = S-PE)


Шаг 12. Ingress PE также отправляет BGP маршрут пятого типа ко всем mVPN PE, тем самым информируя их о наличии активного источника в сети. Данный маршрут является триггером для переключения к SPT дереву.

Шаг 13. Egress PE использует полученный BGP маршрут пятого типа для генерации сообщения mLDP mapping в сторону Ingress PE (информация о MDT берётся из BGP маршрута третьего типа).


Таким образом теперь трафик может быть перенаправлен оптимальным путём от источника к получателю, используя mpls (mLDP) метки.

Подробнее..

Тонкость определения EIGRP Feasible Distance

08.03.2021 18:14:03 | Автор: admin

EIGRP это дистанционно-векторный протокол маршрутизации, изначально разработанный Cisco. Одним из ключевых отличий от предшественника, IGRP, является использование DUAL алгоритма, который позволяет исключить появление постоянных петель маршрутизации в топологии. Однако найти корректное определение одного из основных параметров DUAL, feasible distance (FD), оказывается подчас непростой задачей. Обратимся к определению на официальном сайте:

Feasible distance is the best metric along a path to a destination network, including the metric to the neighbor advertising that path.

Перевод: feasible distance это наилучшее значение метрики до сети назначения, включающее значение метрики до соседа, который анонсирует соответствующий маршрут.

Такое определение справедливо для большинства случаев, но, к сожалению, далеко не для всех. Несмотря на то, что корректное определение можно найти на просторах интернета, попробуем выяснить, что именно не так с определением выше. Ниже лабораторная схема:

На каждом из маршрутизаторов настроен соответствующий loopback (например, на R1 с адресом 1.1.1.1/32). В сети, очевидно, используется EIGRP в качестве протокола маршрутизации без каких-либо изысков в настройке:

R3#sho run | section router eigrprouter eigrp 1 network 0.0.0.0

В рамках данной статьи основной интерес представляет маршрут до 3.3.3.3/32 с точки зрения R1:

R1#deb eigrp fsmEIGRP Finite State Machine debugging is onR1#sho ip eigrp topology 3.3.3.3/32EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 3.3.3.3/32  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720  Descriptor Blocks:  192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0      Composite metric is (158720/156160), route is Internal      Vector metric:        Minimum bandwidth is 100000 Kbit        Total delay is 5200 microseconds        Reliability is 255/255        Load is 1/255        Minimum MTU is 1500        Hop count is 2        Originating router is 3.3.3.3

По умолчанию существуют 2 способа повлиять на значение метрики EIGRP: изменить пропускную способность канала или же его задержку. В нашем случае изменение пропускной способности позволяет получить более предсказуемые результаты. Изменим метрику соединения между R2 и R3:

R2(config-if)#delay 100

Как и следовало ожидать, R1 теряет единственный маршрут до 3.3.3.3/32 и переводит префикс в состояние Active:

R1#*Mar  2 20:17:07.655: EIGRP-IPv4(1): rcvupdate: 3.3.3.3/32 via 192.168.12.2 metric 181760/179200 on tid 0*Mar  2 20:17:07.659: EIGRP-IPv4(1): Find FS for dest 3.3.3.3/32. FD is 158720, RD is 158720 on tid 0*Mar  2 20:17:07.659: EIGRP-IPv4(1): 192.168.12.2 metric 181760/179200 not found Dmin is 181760*Mar  2 20:17:07.659: DUAL: AS(1) Peer total 1 stub 0 template 1 for tid 0*Mar  2 20:17:07.659: DUAL: AS(1) Dest 3.3.3.3/32 entering active state for tid 0.*Mar  2 20:17:07.659: EIGRP-IPv4(1): Set reply-status table. Count is 1.*Mar  2 20:17:07.659: EIGRP-IPv4(1): Not doing split horizon*Mar  2 20:17:07.759: EIGRP-IPv4(1): rcvreply: 3.3.3.3/32 via 192.168.12.2 metric 181760/179200 for tid 0*Mar  2 20:17:07.759: EIGRP-IPv4(1): reply count is 1*Mar  2 20:17:07.759: DUAL: AS(1) Clearing handle 0, count now 0*Mar  2 20:17:07.759: DUAL: AS(1) Freeing reply status table*Mar  2 20:17:07.759: EIGRP-IPv4(1): Find FS for dest 3.3.3.3/32. FD is 72057594037927935, RD is 181760 on tid 0 found*Mar  2 20:17:07.759: DUAL: AS(1) RT installed 3.3.3.3/32 via 192.168.12.2

Значение FD также изменилось теперь оно соответствует значению метрики до 3.3.3.3/32:

R1#sho ip eigrp topology 3.3.3.3/32EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 3.3.3.3/32  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 181760  Descriptor Blocks:  192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0      Composite metric is (181760/179200), route is Internal      Vector metric:        Minimum bandwidth is 100000 Kbit        Total delay is 6100 microseconds        Reliability is 255/255        Load is 1/255        Minimum MTU is 1500        Hop count is 2        Originating router is 3.3.3.3

Попробуем теперь другое значение, предварительно сбросив предыдущие изменения. Задержка для интерфейса f0/1 на R2:

R2#sho int f0/1FastEthernet0/1 is up, line protocol is up   Hardware is i82543 (Livengood), address is ca02.0ebd.0006 (bia ca02.0ebd.0006)  Internet address is 192.168.23.2/24  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,<output omitted>

В прошлый раз мы назначили задержку, равную 1000 мкс (значение указывает в десятках микросекунд), что значительно больше значения по умолчанию. Теперь используем минимально настраиваемое значение в 110 мкс:

R2(config-if)#delay ?       <1-16777215>  Throughput delay (tens of microseconds)R2(config-if)#delay 11

Известен небольшой трюк, позволяющий не ошибиться с единицами измерения значений в командах: перед вводом значения символ ? вызывает контекстную подсказку, которая среди прочего указывает и ожидаемые единицы измерения; такая привычка подчас экономит массу времени, исключая ошибки по невнимательности (в конце концов десятки микросекунд не самая очевидная единица измерения на мой взгляд). Проверим, что происходит в этот момент на R1:

R1#*Mar  2 20:25:40.227: EIGRP-IPv4(1): rcvupdate: 3.3.3.3/32 via 192.168.12.2 metric 158976/156416 on tid 0*Mar  2 20:25:40.231: EIGRP-IPv4(1): Find FS for dest 3.3.3.3/32. FD is 158720, RD is 158720 on tid 0*Mar  2 20:25:40.231: EIGRP-IPv4(1): 192.168.12.2 metric 158976/156416 found Dmin is 158976*Mar  2 20:25:40.239: DUAL: AS(1) RT installed 3.3.3.3/32 via 192.168.12.2

Отладочный вывод в этот раз существенно меньше. Что насчёт значения FD?

R1#sho ip eigrp topology 3.3.3.3/32EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 3.3.3.3/32  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720  Descriptor Blocks:  192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0      Composite metric is (158976/156416), route is Internal      Vector metric:        Minimum bandwidth is 100000 Kbit        Total delay is 5210 microseconds        Reliability is 255/255        Load is 1/255        Minimum MTU is 1500        Hop count is 2        Originating router is 3.3.3.3

FD не совпадает с метрикой! В чём же соль? Внимательный читатель мог заметить разницу между рассматриваемыми случаями помимо разных значений задержек. Рассмотрим, что происходило после изменения метрики щаг за шагом:

Delay 1100

Delay 110

Шаг 1

R1 получает обновление о 3.3.3.3/32

Шаг 2

R1 ищет feasible successor for 3.3.3.3/32

Шаг 3

R1 не удалось найти FS, что приводит к запуску DUAL

R1 находит FS и устанавливает маршрут в таблицу маршрутизации

Шаг 4

По завершении DUAL R1 выбирает наилучший маршрут и устанавливает его в таблицу маршрутизации

Ключевое отличие заключается в запуске R1 процесса DUAL. Большая задержка на R2 (100) изменяет метрику таким образом, что результирующий маршрут не удовлетворяет условию feasibility condition, что, в свою очередь, вынуждает R1 инициировать DUAL. Малое же изменение задержки позволяет префиксу соответствовать feasibility condition (изменение задержки меньше задержки канала R1-R2), что даёт возможность избежать времязатратного DUAL. Отладочный вывод включает в себя значение FD, используемое для поиска feasible successor в определённый момент; значение FD после окончания DUAL равно бесконечности. Получается, что FD исторически минимальное значение метрики; оно сбрасывается, как только маршрут переходит в состояние Active.

В обсуждениях Cisco Community можно найти точное определение FD:

Feasible Distance is the lowest distance to the destination experienced since the last time the route went from Active to Passive state

Перевод: FD это минимальное значение метрики до сети назначения с момента последнего перехода префикса из состояния Active в Passive.

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

Помогали редактировать статью: Анастасия Куралёва, Максим Климанов.

Подробнее..

Краткое пособие по созданию петель маршрутизации в OSPF в домашних условиях

13.03.2021 00:17:44 | Автор: admin

Кросспостинг, оригинальная публикация

OSFP, будучи link-state протоколом, исключает петли в топологии за счёт построения дерева кратчайшего пути в рамках одной зоны с помощью алгоритма Дейкстры. Однако поведение OSPF между зонами напоминает скорее поведение distance-vector протоколов, которые обмениваются всего лишь префиксами и соответствующими метриками без каких-либо данных о фактической топологии; по этой причине некоторые авторы могут называть OSPF гибридным протоколом маршрутизации. Механизм защиты от петель маршрутизации между зонами, однако, довольно прост: все зоны должны обмениваться маршрутной информацией через backbone зону, зону 0, прямой обмен маршрутами между зонами невозможен.

Впрочем, тёмный гений изобрёл инструмент разрушения стройной идеи OSPF речь о функции OSPF Virtual Link (VL). Даже маленькие инженеры знают, что использовать VL плохая затея; все согласны с тем, что VL оправдан только в крайних случаях для временного и быстрого исправления критичной ситуации. Однако обнаружить подробное объяснение, чем же именно VL так плох помимо дополнительного уровня сложности, оказалось не так-то просто. Сложность инженерам не помеха, поэтому давайте поищем более весомые аргументы против VL.

Нет ничего лучше чашки кофе с утра, рабочей лабы и широкополосного доступа к google.com. Для эмуляции топологии в GNS3 были использованы образы Cisco 7200:

На каждом маршрутизаторе в соответствующей зоне настроен виртуальный интерфейс (loopback0) для назначения OSPF RID и других инфраструктурных задач; loopback на ABR находятся в зоне 0. Схема адресации: 192.168.xy.x|y/24 для соединения Rx и Ry (например, 192.168.12.1 на интерфейсе f0/1 R1). Помимо штатной настройки OSPF, между R1 и R3 создан VL.

Если у читателя много свободного времени, можно убедиться в доступности всех префиксов из любой точки сети; я же сконцентрируюсь на связности R1 и R5:

R1#ping 5.5.5.5 so lo 0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:Packet sent with a source address of 1.1.1.1 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 20/30/40 msR1#traceroute 5.5.5.5 so lo 0 numericType escape sequence to abort.Tracing the route to 5.5.5.5VRF info: (vrf in name/id, vrf out name/id) 1 192.168.14.4 16 msec 24 msec 20 msec 2 192.168.45.5 48 msec 16 msec 24 msec

Трафик следует по кратчайшему маршруту, как и задумывалось. Перейдем к гвоздю сегодняшней программы:

R1(config)#router os 1R1(config-router)#no capability transit

Transit area capability это способность OSPFv2 выбрать более оптимальный маршрут для трафика, следующего по VL. Идея довольно проста: необходимо взять префикс, доступный через VL, и сравнить его с имеющимися LSA3; если найдено полное совпадение и маршрут через LSA3 оптимальнее, то следует использовать оптимальный маршрут. OSPFv1 не обладал такой функцией, и весь трафик следовал по тому же пути, что и VL. Если читатель хочет глубже погрузиться в данную тему, могу порекомендовать статью Петра Лапухова. А мы продолжаем:

R1#traceroute 5.5.5.5 so lo 0 nType escape sequence to abort.Tracing the route to 5.5.5.5VRF info: (vrf in name/id, vrf out name/id) 1 192.168.12.2 44 msec 16 msec 20 msec 2 192.168.23.3 20 msec 40 msec 40 msec 3 192.168.35.5 76 msec 44 msec 44 msec

Изменения есть, но они некритичны: теперь R1 выбирает путь вдоль VL в полном соответствии с поведением OSPFv1 без transit capability. Где же обещанная петля? Добавим нашей топологии некоторой пикантности:

R2(config)#int f1/0R2(config-if)#ip os cost 100
R3(config)#int f1/0R3(config-if)#ip os cost 100

Ухудшили плохой маршрут, и что с того?

R1#traceroute 5.5.5.5 so lo 0 nType escape sequence to abort.Tracing the route to 5.5.5.5VRF info: (vrf in name/id, vrf out name/id) 1 192.168.12.2 20 msec 16 msec 16 msec 2 192.168.12.1 24 msec 16 msec 16 msec 3 192.168.12.2 36 msec 32 msec 44 msec 4 192.168.12.1 28 msec 36 msec 40 msec 5 192.168.12.2 44 msec 48 msec 64 msec 6 192.168.12.1 60 msec 60 msec 60 msec 7 192.168.12.2 80 msec 80 msec 80 msec 8 192.168.12.1 84 msec 76 msec 76 msec

Дамы и господа, это петля. Теперь взглянем на проделанную работу:

  • VL между R1-R3;

  • Transit capability отключена;

  • Метрика R2-R3 увеличена.

Последний пункт стоит отметить особо: в результате изменения метрики R1 является next-hop для 5.5.5.5/32 с точки зрения R2:

R2#sho ip ro 5.5.5.5 255.255.255.255 longer-prefixes  5.0.0.0/32 is subnetted, 1 subnetsO IA 5.5.5.5 [110/4] via 192.168.12.1, 00:06:21, FastEthernet0/1

Выбор маршрута R2 выглядит довольно естественно; выбор R1 же может показаться странным на первый взгляд:

R1#sho ip ro 5.5.5.5 255.255.255.255 longer-prefixes  5.0.0.0/32 is subnetted, 1 subnetsO 5.5.5.5 [110/103] via 192.168.12.2, 00:08:07, FastEthernet0/1

Однако такое поведение вполне соответствует правилам выбора маршрута в OSPFv1:

  • 5.5.5.5/32 доступен через VL в зоне 0;

  • трафик следует по тому же пути, что и VL.

R2 ничего не знает ни про VL, ни про transit area; он всего ли маршрутизирует пакеты согласно таблице маршрутизации, построенной на основе LSA3.

На данном этапе может показаться, что причина всех бед transit capability, а не VL. Впрочем, разрешается этот вопрос довольно просто: подобная проблема была обнаружена в OSPFv1 и решена в OSPFv2 посредством transit area. Читатель может заметить, что описанное поведение родственно по природе микропетлям, возникающим в ходе перестроения дерева, и с ним трудно не согласиться. Впрочем, разница есть и существенная: микропетли представляют собой переходное состояние, тогда как петли из-за VL в OSPFv1 носили постоянный характер.

Немного английского оригинала из OSPFv2 RFC про отличия от OSPFv1:

When summarizing information into a virtual link's transit area, version 2 of the OSPF specification prohibits the collapsing of multiple backbone IP networks/subnets into a single summary link.

Section F.2.3, RFC 1247

Проблема, завуалированная авторами RFC в этой фразе, очень похожа по характеру на рассматриваемую в статье. Если бы маршруты зоны 0 можно было бы суммаризовать на ABR, то полученный префикс в LSA3 не смог бы быть использован маршрутизатором с VL. Передача трафика была бы нарушена вследствие разного представления о топологии маршрутизаторами зоны:

  1. Маршрутизатор с VL выбрал бы маршрут из зоны 0; из-за отсутствия точно совпадающего LSA3 был бы выбран путь вдоль VL;

  2. Остальные же маршрутизаторы использовали бы суммарный маршрут из LSA3.

В нашем случае, если бы R3 суммаризовал маршрут до 5.5.5.0/24, то R2 выбрал бы более точный маршрут 5.5.5.0/25 через R4, что привело бы к петле маршрутизации. Решение? Нужно обеспечить всем маршрутизаторам зоны равный доступ к маршрутной информации из зоны 0, запретив изменение последней, т.е. суммаризацию. Стоит отметить, что это не относится к маршрутам из других зон, поскольку эти суммарные маршруты будут одинаковы как в зоне 0, так и других зонах; только ABR зоны-источника могут суммаризовать информацию о топологии из LSA1/2 в простой LSA3. Более того, запрещена только суммаризация префиксов из зоны 0, фильтрация же не ограничена. Последняя не изменяет сам префикс; в результате у маршрутизаторов зоны будет меньше пар LSA1-LSA3 для выбора более оптимального маршрута, что не может привести к описанной в статье проблеме.

Вывод: некоторые малоизвестные настройки по умолчанию лучше не трогать.

P.S. Существует не менее интересный способ выстрелить себе в ногу.

Помогали редактировать статью: Анастасия Куралёва, Максим Климанов.

Подробнее..

Spoke to spoke мультикаст в сетях DMVPN

26.03.2021 12:06:50 | Автор: admin

Кросспостинг, оригинальная публикация

Про настройку и диагностику технологии DMVPN в интернете написано немало статей. Однако про использование мультикаста поверх DMVPN лучшее, что мне удалось найти это маленькая заметка в Configuration Guide.

In DMVPN, it is recommended to configure a Rendezvous Point (RP) at or behind the hub. If there is an IP multicast source behind a spoke, the ip pim spt-threshold infinity command must be configured on spokes to avoid multicast traffic going through spoke-to-spoke tunnels.

Давайте выясним, в чем на самом деле заключается необходимость этой команды. Тестовая схема выглядит следующим образом.

Как можно заметить, это самый обыкновенный DMVPN Phase 2, собранный в GNS3. Интерфейсы Loopback на каждом маршрутизаторе позволяют смоделировать клиентские подсети; также логично разместить RP на Hub-маршрутизаторе как центральной точке логической топологии. Для удобства адресации примем Hub = R1, Spoke1 = R2, Spoke2 = R3, Internet = R4.

Настроим PIM и RP внутри DMVPN облака:

Hub(config)#interface Loopback0Hub(config-if)#ip address 1.1.1.1 255.255.255.255Hub(config-if)#ip pim sparse-modeHub(config)#interface Tunnel0Hub(config-if)#ip address 192.168.0.1 255.255.255.0Hub(config-if)#no ip redirectsHub(config-if)#no ip split-horizon eigrp 1Hub(config-if)#ip pim sparse-modeHub(config-if)#ip nhrp map multicast dynamicHub(config-if)#ip nhrp network-id 1Hub(config-if)#tunnel source FastEthernet0/0Hub(config-if)#tunnel mode gre multipointHub(config-if)#tunnel vrf AHub(config)#ip pim rp-address 1.1.1.1
Spoke1(config)#interface Loopback0Spoke1(config-if)#ip address 2.2.2.2 255.255.255.255Spoke1(config-if)#ip pim sparse-modeSpoke1(config)#interface Tunnel0Spoke1(config-if)#ip address 192.168.0.2 255.255.255.0Spoke1(config-if)#no ip redirectsSpoke1(config-if)#ip pim sparse-modeSpoke1(config-if)#ip nhrp network-id 1Spoke1(config-if)#ip nhrp nhs 192.168.0.1 nbma 192.168.14.1 multicastSpoke1(config-if)#tunnel source FastEthernet0/1Spoke1(config-if)#tunnel mode gre multipointSpoke1(config-if)#tunnel vrf ASpoke1(config)#ip pim rp-address 1.1.1.1
Spoke2(config)#interface Loopback0Spoke2(config-if)#ip address 3.3.3.3 255.255.255.255Spoke2(config-if)#ip pim sparse-modeSpoke2(config)#interface Tunnel0Spoke2(config-if)#ip address 192.168.0.3 255.255.255.0Spoke2(config-if)#no ip redirectsSpoke2(config-if)#ip pim sparse-modeSpoke2(config-if)#ip nhrp network-id 1Spoke2(config-if)#ip nhrp nhs 192.168.0.1 nbma 192.168.14.1 multicastSpoke2(config-if)#tunnel source FastEthernet1/0Spoke2(config-if)#tunnel mode gre multipointSpoke2(config-if)#tunnel vrf ASpoke2(config)#ip pim rp-address 1.1.1.1

На данном этапе есть связность между Spoke, а также необходимые протоколы управления групповым вещанием. Самое время подписаться на мультикаст поток на Spoke1:

Spoke1(config)#int lo 0Spoke1(config-if)#ip igmp join-group 224.1.1.1Spoke1#sho ip mroute(*, 224.1.1.1), 00:00:37/00:02:22, RP 1.1.1.1, flags: SJCL  Incoming interface: Tunnel0, RPF nbr 192.168.0.1  Outgoing interface list:   Loopback0, Forward/Sparse, 00:00:37/00:02:22

Запустим сам поток в виде ICMP echo request сообщений, отправляемых на multicast адрес, на Spoke2:

Spoke2#ping 224.1.1.1 source lo0 rep 1000 Type escape sequence to abort.Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:Packet sent with a source address of 3.3.3.3Reply to request 0 from 2.2.2.2, 156 ms....

Не работает, причём довольно хитрым образом: первый пакет проходит (мы получаем на него ответ), однако последующие почему-то пропадают. Взглянем на то, что происходит в данный момент, на уровне пакетов.

Spoke1:

Hub:

Итак, это Hub не шлёт пакеты потока после обработки самого первого пакета. С чего бы вдруг?

Hub#sho ip mroute<output omitted>(*, 224.1.1.1), 00:03:31/00:02:55, RP 1.1.1.1, flags: SP  Incoming interface: Null, RPF nbr 0.0.0.0  Outgoing interface list: Null(3.3.3.3, 224.1.1.1), 00:03:08/00:02:46, flags: PJT  Incoming interface: Tunnel0, RPF nbr 192.168.0.3  Outgoing interface list: Null

Список OIL (outgoing interface list) пуст, что и является причиной потери потока. Или не является? Почему же тогда прошёл самый первый пакет? Давайте взглянем на Hub за пару секунд до того:

Hub#sho ip mroute<output omitted>(*, 224.1.1.1), 00:00:13/00:03:16, RP 1.1.1.1, flags: S  Incoming interface: Null, RPF nbr 0.0.0.0  Outgoing interface list:   Tunnel0, Forward/Sparse, 00:00:13/00:03:16

(*,G) содержит Tunnel0, что ожидаемо; RPF сосед также пока неизвестен, поскольку ни один пакет из потока ещё не прошёл через Hub. А дальше следите за руками:

  1. Spoke2 шлёт самый первый мультикаст пакет внутри unicast сообщения RP-Register;

  2. Hub, он же RP, получает RP-Register и выполняет следующие два действия: отправляет пакет согласно OIL (Tunnel0); кроме того, отправляет PIM Join в сторону источника потока (Tunnel0);

  3. В режиме PIM-SM входящий интерфейс (IIF, incoming interface) не может присутствовать в OIL (RPF check), поскольку это может породить петлю; следовательно, Tunnel0 необходимо исключить из OIL в этот момент Spoke2 теряет поток.

Суть проблемы кроется в NBMA (non-broadcast multiple access) поведении DMVPN: Spoke2 логически находится в одном широковещательном сегменте со Spoke1, хотя физически это совсем не так (а Вы думали, Frame-Relay жил, Frame-Relay жив, Frame-Relay будет жить; надеюсь, это шутка). Впрочем, решение задачи довольно простое надо явно указать Hub, что Tunnel0 следует рассматривать не как один интерфейс, а как набор нескольких:

Hub(config)#interface Tunnel0Hub(config-if)#ip pim nbma-mode

Теперь таблица маршрутизации мультикаста правильная:

Hub#sho ip mroute(*, 224.1.1.1), 00:03:51/00:03:27, RP 1.1.1.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:  Tunnel0, 192.168.0.2, Forward/Sparse, 00:00:02/00:03:27(3.3.3.3, 224.1.1.1), 00:03:29/00:02:25, flags: JT  Incoming interface: Tunnel0, RPF nbr 192.168.0.3 Outgoing interface list:   Tunnel0, 192.168.0.2, Forward/Sparse, 00:00:02/00:03:27

Поскольку Tunnel0 теперь работает как несколько интерфейсов, таблица маршрутизации мультикаста содержит не только сам интерфейс, но и адреса как получателя (192.168.0.2), так и отправителя (192.168.0.3) потока. Стоит отметить ещё одну любопытную особенность поведения DMVPN, когда поток мультикаста идёт со стороны Hub в сторону Spoke. По умолчанию, DMVPN отправляет мультикаст каждому Spoke (ip nhrp map multicast dynamic), что успешно используют протоколы маршрутизации, отправляя служебную информацию или обновления мультикастом. Однако если сеть является географически распределённой (например, несколько регионов), такое поведение может быть нежелательным: мультикаст, отправленный во все регионы, в том числе туда, где нет PIM подписки, занимает полосу, после чего его отбрасывают все Spoke, кроме того, кому поток был действительно нужен. Такое поведение можно исправить использованием PIM NBMA режима для DMVPN, что позволяет различать Spoke по адресам на уровне мультикаста и отправлять поток только тем регионам, где на него есть подписка.

Настало время ещё раз проверить связность между Spoke для мультикаста:

Spoke2#ping 224.1.1.1 so lo 0 rep 1000 Type escape sequence to abort.Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:Packet sent with a source address of 3.3.3.3 Reply to request 0 from 2.2.2.2, 176 ms....

Ничего не поменялось, но мы упорные. Начнём проверять по порядку, начиная с Hub:

Hub#sho ip mroute(*, 224.1.1.1), 00:52:32/00:02:58, RP 1.1.1.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:  Tunnel0, 192.168.0.2, Forward/Sparse, 00:02:12/00:02:58(3.3.3.3, 224.1.1.1), 00:01:30/00:01:31, flags: PT Incoming interface: Tunnel0, RPF nbr 192.168.0.3  Outgoing interface list: Null

(S,G) запись неактивна (флаг P) на Hub, соответственно, OIL пуст. Очевидно, что это дело рук Spoke1, больше некому:

Spoke1#sho ip mroute<output omitted>(*, 224.1.1.1), 00:52:44/stopped, RP 1.1.1.1, flags: SJCL Incoming interface: Tunnel0, RPF nbr 192.168.0.1 Outgoing interface list:  Loopback0, Forward/Sparse, 00:09:18/00:02:26(3.3.3.3, 224.1.1.1), 00:01:39/00:01:20, flags: LJT Incoming interface: Tunnel0, RPF nbr 192.168.0.3 Outgoing interface list:   Loopback0, Forward/Sparse, 00:01:39/00:02:26

Вроде бы таблица правильная Но нет: RPF сосед Spoke 2, а должен быть Hub. Посмотрим внимательно на весь процесс ещё раз.

  1. Spoke2 отправляет первый пакет потока внутри RP-Register;

  2. Hub пересылает пакет Spoke1 и начинает построение SPT дерева в сторону Spoke2;

  3. Spoke1 получает первый пакет, создаёт новое состояние для потока в таблице маршрутизации, высылает ответ.

  4. Spoke1 осознаёт, что RPF сосед для источника мультикаста это Spoke2, поэтому он отправляет SPT-Join в сторону Spoke2. Однако в силу NBMA поведения DMVPN, физически SPT-Join идёт в сторону Hub. Последний его с радостью отбрасывает, поскольку внутри пакета в качестве RPF соседа указан Spoke2.

  5. IIF для RPT и SPT один и тот же, Tunnel0, поэтому Spoke1 отправляет сообщение (*,G) Prune в сторону Hub, где он и обрабатывается.

В результате, Hub отключает у себя (*,G) запись, а Spoke1 не может завершить создание (S,G) записи в таблице маршрутизации, что приводит к нарушению связности между Spoke.Корень зла в этом случае SPT-switchover: между Spoke нет прямой связности для мультикаста, единственный доступный путь через Hub. В конце концов, мы пришли к команде, которая упоминается в Configuration Guide ip pim spt-threshold infinity. Неужели теперь связность появится?

Spoke2#ping 224.1.1.1 so lo 0 rep 1000 Type escape sequence to abort.Sending 1000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:Packet sent with a source address of 3.3.3.3 Reply to request 0 from 2.2.2.2, 112 msReply to request 1 from 2.2.2.2, 84 msReply to request 2 from 2.2.2.2, 76 msReply to request 3 from 2.2.2.2, 80 msReply to request 4 from 2.2.2.2, 52 msReply to request 5 from 2.2.2.2, 48 ms

На данном этапе мультикаст работает, как и ожидалось вначале. Поток может быть передан в любом направлении (hub-spoke, spoke-spoke, spoke-hub), причём только в сторону тех Spoke, которые на него подписались. Стоит отметить, однако, что передача мультикаста напрямую между Spoke чревата повышением нагрузки на канал вследствие рассылки мультикаста внутри направленных пакетов; канал до Spoke на такую нагрузку, как правило, не рассчитан, что может привести как к проблемам с масштабированием решения, так и к ухудшению связности для существующих приложений.

В статье мы рассмотрели, что необходимо добавить к обычному DMVPN Phase 2, чтобы успешно запустить поверх него мультикаст. К тонким моментам можно отнести, пожалуй, только режим PIM NBMA и SPT-switchover это единственное отличие от общеизвестных настроек DMVPN Phase 2.

Подробнее..

VxLAN фабрика часть 5. Multisite

12.04.2021 14:15:58 | Автор: admin

Привет, Хабр! Наконец заканчиваю цикл статей,посвященных запуску курса"Дизайнер сетей ЦОД"от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений различных ЦОД или сайтов.

Предыдущие части цикла можно найти по ссылкам:

1 часть цикла - L2 связанность между серверами
2 часть цикла - Маршрутизация между VNI
2.5 часть цикла - Теоретическое отступление
3 часть цикла - Подключение внешнего маршрутизатора/firewall
4 часть цикла - Multipod



Сегодня рассмотрим второй способ подключение различных ЦОД - Multisite.

Для начала вспомним как строится Underlay при построении фабрики с помощью Multipod. И снова получаем несколько вариантов построения такой сети. То есть:

  1. Underlay сеть может быть единой и, например, использовать OSPF для IP связанности между всеми устройствами в фабрике.

  2. Underlay повторяет логику BGP для настройки EVPN и каждый POD находится в своей AS, как показано на рисунке ниже

Однако, вспоминая предыдущую часть, приходим к тому, что во всех случаях возникают свои проблемы. Так в 1 случае, при едином OSPF процессе, может появиться слишком большое количество устройств (например более 100-150 устройств) и динамическая маршрутизация станет работать заметно медленнее и больше нагружать сетевые устройства. Во 2-м случае возникает еще больше проблем (ниже указаны не все проблемы, а только основные):

  1. Смена Next-Hop. С использованием eBGP, при выходе update из AS, Next-hop меняется. То есть не забываем делать соответствующие настройки;

  2. Общая проблема для обоих случаев - значение Route-target в автоматическом режиме работать не будет. То есть необходимо использовать статическую настройку, однако это решается автоматизацией таких настроек и сети в целом;

  3. С увеличением количества клиентов, увеличивается и количество MAC/IP адресов и BUM трафик соответственно.

Исходя из перечисленных выше недостатков приходим к тому, что необходимо сегментировать сеть и реализуется это через технологию Multisite.

Для начала обсудим какие преимущества дает сегментация сети:

  1. Уменьшение домена рассылки Broadcast для поиска какого-либо клиента сети;

  2. Упрощается объединение различных подов через сеть интернет;

  3. Проблемы в одном сайте никак не влияют на другой сайт;

  4. Так как теперь каждый сайт независим от другого, то возможно использовать на одном сайте ingress replication, а на другом Multicast. То есть ЦОДы с различными технологиями объединяются без каких-либо проблем миграции.

Осталось разобраться как работает данная технология. Для начала рассмотрим теоретическую часть.

При реализации Multisite в сети появляется еще одна роль устройства - BGW(Border Gateway), которая может быть присвоена Spine, а может стать отдельным устройством в сети. В логической схеме дополнительное устройство встраивается выше Spine, как показано на рисунке ниже:

Но на самом деле, поставить BGW возможно в любое место в сети, главное обеспечить IP связанность

Осталось разобраться как же это все работает. Однако, для начала вернемся к предыдущим частям и вспомним как все работает в рамках одного POD. В одном POD тоннель устанавливается напрямую между VTEP, как показано ниже и LEAF коммутаторы напрямую обмениваются информацией о MAC/IP адресах.

То есть каждый LEAF должен знать о всех VTEP находящихся в его сети.
Теперь, когда вспомнили как работает сеть в рамках одно пода или нескольких, можем перейти к логике Multisite. Для начала приведу общую схему с логикой работы сети. Объяснение происходящего приведу ниже.

Получается что в Multisite тоннель от Leaf строится до BGW, далее BGW строит совершенно другой тоннель до второго BGW, находящего на другом сайте, и далее строится еще один тоннель уже в рамках другого сайта. Именно такая логика работы, когда между сайтами строится отдельный тоннель, позволяет сегментировать сеть, упростить поиск и устранение неисправностей, так как удаленный сайт полностью скрывается за 1 устройством(но рекомендуется использовать как минимум 2 BGW на каждом сайте для отказоустойчивости). Далее перейдем к настройке BGW, так как все остальные устройства не меняют свою настройку и никакие изменения на них не совершаются. Для начала на BGW необходимо включить следующие feature:

feature ospf - для организации Underlay в своем сайте

Настройка самой Underlay сети в данном разделе рассматриваться не будет, так как ничем не отличается от обычной реализации пода. При этом для IP связанности так же можно использовать IP unnumbered или адреса на point-to-point линках с маской /30 или /31.

После настройки Uderlay сети на BGW необходимо указать интерфейс, который смотрит в локальный сайт:

Interface Ethernet1/50description SITE-INTERNALevpn multisite fabric-tracking - указываем где находится локальный сайт

Далее готовим настройки для Overlay сети. Выглядят они практически аналогично настройкам на Leaf коммутаторах. В целом это логично, так как BGW так же имеет роль VTEP.

feature bgpfeature nv overlaynv overlay evpn

После включения необходимых фич, определяем коммутаторов как BGW и привязываем его к номеру сайта. Каждый BGW в одном сайте должен иметь одинаковый идентификатор.

evpn multisite border-gateway <site-id> номер сайта одинаковый у всех BGW в одном сайте

Продолжаем настройку BGW и создаем интерфейс NVE

interface nve1  host-reachability protocol bgp  source-interface loopback1 - как и на LEAF, интерфейс используется для построения тоннеля в рамках своего сайта  multisite border-gateway interface loopback100 - новая настройка, используется для построения тоннеля между сайтами

Если у вас есть несколько BGW(а их должно быть хотя бы 2), то loopback100 должен иметь одинаковый адрес на всех устройствах с этой ролью - anycast адрес для сайта

Далее настраиваем протокол BGP для работы в локальном сайте. Настройка ничем не отличается от настройки на других устройствах в сетевой фабрике:

router bgp 65501  neighbor 10.100.100.201    remote-as 65501    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended   neighbor 10.100.100.202    remote-as 65501    update-source loopback0    address-family l2vpn evpn      send-community      send-community extended

На данном этапе мы произвели настройки необходимые для первого тоннеля между LEAF и BGW

Переходим ко второй части настройки - тоннель между сайтами. Сразу уточню, что этот тоннель всегда должен работать только в режиме ingress replication.

interface Ethernet1/1  evpn multisite dci-tracking - команда указания, что интерфейс является внешним локального сайта и смотрит в сторону второго сайта

Последнее, что осталось настроить - BGP соседство со вторым сайтом:

router bgp 65501  neighbor 10.52.52.52 - удаленный сосед    remote-as 65036    update-source loopback0 - устанавливаем так же с loopback    ebgp-multihop 5    peer-type fabric-external - указываем, что удаленный пир, относится к фабрике в другом сайте    address-family l2vpn evpn      send-community      send-community extended      rewrite-evpn-rt-asn - Так как можем использоваться автоматическая настройки RT, то его необходимо изменить на новое значение

Напомню, что RT - это route-target и в автоматическом режиме формируется из двух значений AS:VNI

Аналогично необходимо завести всех остальных соседей в других сайтах. При этом необходимо настроить Full-Mesh между всеми маршрутизаторами с ролью BGW во всех сайтах. Либо возможно использовать Route-reflector в eBGP. Настройка RR выглядит следующим образом:

router bgp 65036  address-family l2vpn evpn    retain route-target all - принимаем все анонсы с любом RT  template peer OVERLAY-PEERING    update-source loopback0    ebgp-multihop 5    address-family l2vpn evpn      send-community both      route-map UNCHANGED out - запрещаем менять значение атрибута Next-Hop neighbor 10.100.100.21 remote-as 65501    inherit peer OVERLAY-PEERING    address-family l2vpn evpn      rewrite-evpn-rt-asn - так же переписываем значение RT, при автоматическом режиме установки RTroute-map UNCHANGED permit 10 - route-map в котором указываем запрет смены NH  set ip next-hop unchanged 

Этап выше настраивает тоннель между сайтами, как показано на рисунке ниже:

Настройка Multisite, закончена, однако предлагаю рассмотреть варианты работы нескольких BGW в одном сайте. На сегодняшний день доступно 3 вида подключения BGW:

  1. Вариант, что рассмотрели выше, без каких-либо настроек;

  2. VPC BGW - до 2-х устройств;

  3. Anycast BGW - до 4-х устройств.

Первый подход подробно рассматривать не будет, но, замечу, что для его реализации необходимо иметь линк между BGW в рамках одного сайта, как показано ниже.

Далее рассмотрим оставшиеся 2 подхода к реализации BGW и начнем с VPC BGW:

  • только 2 устройства с физическим Peer-link и keepalive link(возможно использовать виртуальный, однако с точки зрения надежности я бы рекомендовал использовать прямой физический канал), что добавляет еще больше линков, нежели в 1 варианте подключения;

  • Используется для небольших внедрений

Настройка VPC ничем не отличается от настройки VPC на Leaf коммутаторах. Так же требуется на интерфейсе Loopback создать secondary адрес, до которого будет строится VxLAN тоннель.

Anycast BGW и тут может возникнуть вопрос, чем же Anycast лучше. Разберемся по порядку. :

  • до 6 устройств BGW в одном сайте;

  • простой сценарий отработки проблем в сети, то есть все устройства независимы друг от друга, в отличии от VPC(да-да, там тоже разный Controle-Plane, однако это не спасает от багов);

  • сеть любой сложности;

  • простое развертывание с нуля устройств BGW, не влияя на сеть в целом.

То есть все устройства BGW Anycast прячутся за одним виртуальным адресом, как показано на рисунке ниже

Настройка мало чем отличается от реализации рассмотренной в начале данного материала:

 interface loopback100 - интерфейс указанный как multisite border-gateway description MULTI-SITE INTERFACE  ip address 10.10.10.10/32 - одинаковый адрес на всех BGW  ip router ospf UNDERLAY area 0.0.0.0 - IP связанность в рамках локального сайта

На этом настройка связанности между сайтами закончена. На момент написания данного материала не получается реализовать mulisite в виртуальной среде. На железе все запускается без особых проблем. Возможно в новых виртуальных образах ситуация исправлена.

Ниже предлагаю пройти опрос, на какой стадии использования VxLAN EVPN вы сейчас находитесь.

Подробнее про работу технологии можно посмотреть в RFC-7432 и в draft-ietf-bess-evpn-overlay, draft-ietf-bess-evpn-prefix-advertisement, draft-ietf-bess-evpn-inter-subnet-forwarding


Современная IT инфраструктура все больше виртуализируется, уплывая в Облака. Модели "все как сервис"- SaaS, PaaS, IaaS используются повсеместно, но все эти решения, по-прежнему используют сети передачи данных и машинные ресурсы для их обработки. За последние 20 лет, сети ЦОД, претерпели множество изменений, с которыми попробуем познакомиться ближе и разобрать основные технологические этапы этой эволюции с присущими им технологиями и архитектурными решениями в рамках бесплатного демо-урока по теме: "Эволюция сетевых технологий в ЦОД".

Записаться на демо-урок

Подробнее..

Как я Wi-Fi сеть переводил с Cisco 5508 на Cisco 9800-CL

26.05.2021 16:17:30 | Автор: admin

На волне проходящего марафона Cisco "Новая классика WLAN", хотелось бы рассказать, как я переходил с Cisco 5508 на Cisco 9800-CL в далеком 2019 году.

Предисловие

Меня иногда посещает идея, что когда у Cisco получается уже продукт, в котором почти нет багов, интерфейс удобен и богатый функционал, этот продукт начинают хоронить. Так вышло с Firepower который пришёл на замену ASA (но пока не смог вытеснить), так же случилось и с AirOS, который заменили на IOS-XE. Конечно, это мнение обывателя, и на самом деле в новых линейках появился новый функционал, быстродействие и т.д. и т.п. Но мне, как человеку проработавшему много лет с одной серией оборудования, когда ты уже знаешь основные баги, "подводные камни", можешь уже с закрытыми глазами найти в интерфейсе нужное меню или помнишь наизусть все команды, очень трудно взять и перейти абсолютно на новую линейку.

Отрицание

Обычно шок и отрицание возникают у пациентов, которым сообщили смертельный диагноз в самом начале развития болезни.

В 2019 году в нашей компании в качестве Wi-Fi контроллера использовалась пара AIR-CT5508-500-K9 в HA. Это был уже давно зарекомендовавший себя контроллер, с которым я был знаком с 2015 года. Но, количество точек в компании росло и по расчётам к 2020му году, мы должны были выйти за 500 точек доступа (а это уже физический лимит контроллера 5508). В начале я не особо раздумывал и просто начал согласовывать спецификацию на Wi-Fi контроллер 5520. Но во время консультации с Cisco, у меня спросили: "А почему Вы не хотите перейти на 9800 серию". Я если честно, про неё в то время даже не слышал. Начав гуглить этот вопрос, я нашёл описание, красивые слайды, даже кое-какие гайды. Потом у меня был ВКС от Софьей Струнской и Анной Комшой по 9800 серии. И начались у меня бессонные ночи в размышлениях, что же всё таки выбрать.

С одной стороны 9800 - это новое ПО, с новым интерфейсом, с новыми багами. C другой стороны, старый добрый AirOS, где уже все понятно, в интернете тонны инструкций. Но с третьей стороны, если вы видите, что появился новый продукт с таким же функционалом, как и текущий, готовьтесь к тому, что текущий уйдет в EoS. А с четвёртой, мне всегда интересно всё новое и "замутить" какой-нибудь новый проект.

Выбирать мне пришлось между парой 5520+лицензии и парой 9800-CL+DNA Essentials (по цене, даже 9800 дешевле выходил. Правда, стоит отметить, если бы ещё наш менеджер, рассказал бы про Промо, было бы ещё дешевле). В итоге, когда я должен был прислать руководству спецификацию на 5520, я прислал спецификацию на 9800-CL и лицензии DNA Essentials. И вот спецификация ушла дальше, а я стал запрашивать демо.

Гнев

Когда пациент не в силах отрицать очевидное, его переполняют ярость, раздражение, зависть и негодование. Он задает вопрос: Почему именно я?

После того, как мне дали ссылку на образ, я его развернул. И тут в общем-то все и началось....

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

Начинал я с версии 16.11. Первым всплыло, что просто так подружить контроллеры 9800-CL и 5508 нельзя. После написания в TAC, оказалось, что есть "допиленная" версия для 5508, где реализовали возможность создания мобильной группы между ними. Затем, следом всплыл баг, который я на 5508 решал пол года. Когда ни с того ни с сего, у меня прекращалось вещание потокового видео (при чем до точки мультикаст-поток шёл, а вот точка его уже не передавала CSCvp33020). И конечно же, интерфейс...После модного интерфейса из 8.5, где уже было почти всё, что надо для мониторинга, в 9800-CL всё не на столько гладко.

Например самый главный минус, это скорость подключения, эту проблему не решили даже в 17.5.5.

Все помнят как перевести это в скорость подключения?Все помнят как перевести это в скорость подключения?

Так что при покупке 9800 не забудьте распечатать и заламинировать себе вот такую табличку.

Из других багов (тут стоит отметить, что речь идёт о версии 16.12) это проблемы фильтрации, когда он показывает, что нашёл 200 точек доступа, а показывает только 20. Или если одна из точек доступа находится в режиме загрузки, то список точек доступа, у вас не загрузится, а так и будет висеть.

Или когда вы набиваете ACL, а он начинает дублировать строчки, а потом в конце говорит, что не может сохранить, то что сам насоздавал.

Но это цветочки, самым веселым был случай, когда после локального тестирования (нашего кабинета), я решил перевести один кампус на Wi-Fi контроллер 9800-CL. В один из выходных, мне звонит техподдержка и говорит, что у них отвалился Wi-Fi. Я полез разбираться и меня ждал сюрприз. По какой-то неведомой причине сменилась роль, но сменилась криво и часть конфига исчезала, AAA, что не сильно критично, и настройки uplink. Интерфейс из L2 превратился в L3.

После разбирательств с TAC выяснился баг, решением которого было подправить таймеры (CSCvq88794).

Торг

Этот этап довольно непродолжительный. Пациент пытается договориться с болезнью.

Так как спецификация ушла в закупку, надо было продолжать. Я методично изучал новый интерфейс попутно открывая кейсы. Получал обещания, что в следующих версиях все исправят, устранят все баги и приведут в порядок интерфейс. Отчасти это происходило и часть проблем решалась. Например, был неприятный сюрприз, когда при настройке порядка 30 точек доступа 1815W с использованием RLAN, оказалось что контроллер не запоминает админ-статус Ethernet портов и после перезапуска их отключает (CSCvs08564). Хорошо, что я окончил курс у Наташи Самойленко. И повозившись несколько часов написал скрипт, который опрашивал статусы портов на точках и если они были отключены, то включал их.

Так как торговаться особо было не с кем, то этот этап прошёл быстро.

Депрессия

Оцепенение, раздражительность и обиды вскоре сменяются ощущением огромной потери. Наступаетдепрессия.

Ещё одной проблемой стало то, что текущий веб интерфейс не предназначен для мобильных устройств (я уже молчу за приложение для Android, 9800-CL увы с ним не дружил). Поэтому, если в дороге нужно было что-то настроить или посмотреть, приходилось цепляться к компьютеру, а уже с него заходить на контроллер.

Для того чтобы посмотреть серийные номера списком, нужно было лезть и запрашивать через CLI (сейчас это исправили).

Смирение

К этому этапу больной уже выплеснул все прежние чувства. Теперь он начинает размышлять о грядущей смерти, но испытывая при этом спокойствие.

Спустя пол года после начала разворачивания контроллера, я в целом освоился и контроллер мне начал нравиться. Проблему отсутствия информации в интерфейсе решилась связкой telegraf+influxdb+grafana, так как 9800-CL построен на IOS-XE и он уже поддерживает потоковую телеметрию и netconf. Получилось что-то такое, где информацию можно собирать каждую секунду

Или вот мой телефон и и RSSI с SNR. Пустые места, это я ушел туда где не ловит или где ещё работал старый контроллер

Так же к плюсам серии Catalist 9800 можно отнести:

  • Возможность увидеть диффы

  • Очень гибкая система конфигурации сети. Если раньше у нас был только AP Groups теперь мы можем очень гибко производить настройки и применять их на точки доступа.

    Получаются группы разных пазлов, из которых вы получается готовый набор тегов, которые уже накидываются на точку доступа.Получаются группы разных пазлов, из которых вы получается готовый набор тегов, которые уже накидываются на точку доступа.

Конечно возникает вопрос, и как этим всем управлять. Тут конечно кому-то может понравиться, кому-то нет. Тут появилась такая вещь как REXEP, правда только по названию точки доступа, где вы можете написать правило, что точке доступа с таким именем нужно присвоить такие теги. Хотя можно и по старинке, выбрать список нужных точек и всем назначить определенные теги.

  • Точки доступа теперь при применении настроек не перезагружаются, конечно дисконект есть, но не полная перезагрузка (ориентировочно секунд 30).

  • Обновление. Если у вас HA, то считайте простоя почти не будет. У 9800-CL своеобразный интерфейс обновления, но в целом процедура проходит безболезненно. В начале контроллеры обновляются по очереди, далее начинают обновляться точки доступа (можно даже указать процент точек доступа которые будут обновляться за раз). Единственное, я так и не понял, как это сделать в назначенное время.

  • Лицензирование. Здесь главный плюс, что теперь лицензируются не контроллеры, а точки доступа. Так что если у вас есть виртуальная среда, вы вполне можете использовать пару в "бою" и допустим один для обкатки новых версий или каких-то проектов и вам это будет стоить только ресурсов в вашей виртуальной среде. Ну и конечно же можно пользоваться "триалом", но не долго. Дальше уже решает по своей совести.

  • Дебаг, он же Radioactive Trace. Хотя у меня есть претензии к нему, так как бывало что вместо полезной информации я получал какую-то непонятную информацию (TAC тоже из того вывода ничего не смог понять). Но в целом иметь возможность собирать дебаг в реальном времени и больше не говорить "А вот сейчас переподключись, я посмотрю", а можно сразу скачать дебаг, при чем за нужное время. Хотя увлекаться тоже не стоит, так как это все создает нагрузку.

Включаем Conditional Debug Global State. И дальше добавляем адреса по которым нам нужно выгрузить дебагВключаем Conditional Debug Global State. И дальше добавляем адреса по которым нам нужно выгрузить дебаг
  • Новые фишки, текущие и будущие. Возможно конечно в AirOS это все то же будет появляться, но насколько я понял сейчас приоритет уже у 9800. Тут и поддержка WPA3 и WiFi6 ну и некоторые другие функции. Скажем так, если сравнивать версию с которой я начинал 16.11 и последнюю 17.5.1, мне уже нужно заново изучать этот контроллер. Он "допиливается" и очень интенсивно.

Советы:

  1. Если вы считаете, что виртуальный контроллер это что-то глючное и неработающее, спросите у себя, а все ли вы выполнили пункты из инструкции. Включили ли promiscuity mode или отключили Vmotion (у меня был случай, когда я не мог понять, почему у меня веб интерфейс периодически виснет, как раз в это время был открыт VCenter, где я и заметил что контроллер куда-то начал мигрировать). И если за виртуальную инфраструктуру отвечаете не вы, то лучше постойте сзади у того кто будет вам разворачивать контроллеры.

  2. Не забывайте, что когда у вас HA и несколько хостов ESXi, тогда VLAN под Redundant port должен быть прописан не только внутри виртуальной инфраструктуры.

  3. А если вы мигрируете виртуальную машину, перед включением убедитесь что сетевой интерфейс Redundant port включён.

  4. Если вы все время вместо интерфейса контроллера, видите wizard, значит у вас не прописан wireless management interface и не сгенерен под него сертификат.

  5. Management интерфейс должен быть один, при чем тот, к которому подключаются точки доступа. Да, все будет работать и на другом интерфейсе, но последний аргумент когда TAC не хочет разбираться это то, что они не поддерживают конфигурацию с несколькими интерфейсами. Это касается и всякой динамической маршрутизации, VRF. Она вроде бы есть, но использовать её нельзя. Ну или тогда на помощь TAC можете не надеяться.

  6. Так как тут используется IOS-XE у нас есть замечательная возможность использовать Automate Tester для проверки доступности RADIUS сервера. (сейчас это уже добавили в веб интерфейс)

  7. Если вы настраиваете 802.1X, не забудьте настроить accounting. Да в статье от Cisco его нет, но если вы хотите видеть ваших клиентов на Firepower (если конечно у вас есть ISE и стык с Firepower), то его обязательно нужно прописывать.

  8. Не забывайте, что все новые точки доступа (хотя 28ю тяжело назвать уже новой) поддерживают Dual-Band Radios, соответственно и Flexible Radio Assignment там так же будет работать. Следите, чтобы клиенты с 2.4 не остались без Wi-Fi (хотя может так им и надо, быстрее мы попадем в эпоху высоких скоростей).

  9. Я бы советовал использовать по максимуму Filter для назначения тегов, а не статическую привязку. Я очень надеюсь что REGEX доведут до ума и он будет работать не только вида AP* или *-IT. Очень удобно, когда нужно поменять теги и у вас сразу все применится на точки которые попадают под это правило. Я у себя настроил что точки доступа у которых имя по умолчанию, они падают в default группу, где висит rf-profile где отключено вещание.

Эпилог

Данная статья была написана, не для того чтобы отпугнуть от новой линейки. А просто показать как развивался продукт. На текущий момент, лично у меня, больших проблем уже не замечено. HA работает, клиенты не жалуются, интерфейс постепенно допиливают. AirOS уже доживает свое, можно конечно до последнего держаться за него, но есть ли в этом большой смысл..

P.S.

В заключение я хотел бы поблагодарить Софью Струнскую и Виктора Платова, за их помощь в процессе осваивания Catalyst 9800 и за их советы по беспроводным сетям.

Подробнее..

Обзор точки доступа Cisco Aironet 1815W или последний довод сетевика

27.05.2021 22:07:59 | Автор: admin

Так как Catalyst 9105AXW достать не получилось, то я решил опубликовать обзор на Cisco Aironet 1815W.

Жить одним днем

Мне кажется, одной из главных проблем в жизни сетевика, это наличие СКС. А точнее отсутствие.

Я неоднократно встречал ситуацию, когда в помещения, где вообще не планировалось размещать сотрудников, появляется кабинет с 5 сотрудниками или кто-то решил что СКС это дорого, поэтому давайте только по одной розетке ставить, но при этом мы покупаем оборудование Cisco. И конечно же всем нужен Wi-Fi (который изначально не планировался), несколько принтеров, IP-телефоны, телевизор и компьютеры, а у вас в лучшем случае одна розетка RJ-45. И вот тут нас спасёт Cisco Aironet 1815W, где есть и Wi-Fi и порты Ethernet, и даже PoE out.

Внешний вид

Ну что тут сказать. Это конечно не 9ХХХ серия, где похоже Cisco решили назад позвать дизайнера (вспоминая 27ХХ) и точка доступа выглядит не просто как кирпич (28ХХ и 38ХХ), а довольно симпатично и её можно даже поставить на стол (увы нет).

У меня массовое применение её пришлось для гостиничных номеров, где была только одна розетка СКС под телевизор, а Wi-Fi точка была в коридоре и в номерах лучше было пользоваться 4G чем Wi-Fi, побыстрее будет. И так как никто не смог согласовать размещение этой точки доступа пришлось прятать её за телевизор. С такими размерами, точка доступа отлично прячется за телевизор (к слову скажу, что экран из телевизора довольно хороший, но лучше хоть так).

А ещё лучше всего, она становится, прям вместо блока розеток СКС.

Возможности

Конечно в этой точке доступа не 3х3 или 4х4 как в старших моделях, а всего 2х2, но для условий комнаты или небольшого помещения, где будут находиться 3-5 человек это вообще не принципиально.

RLAN

Помимо размера главное достоинство, это 3 Ethernet-порта и даже один с PoE.

Для того чтобы воспользоваться этими портами, существует технология RLAN. Кстати хорошо расписано тут Configure RLAN on 9800 WLC.

В настройках портов так же много всего и dot1x и веб авторизация, но этим функционалом пока не пользовался ничего сказать не могу.

Когда мы тестировали эту точку доступа на 5508 весь трафик с портов туннелировался и выходил через контроллер, что меня расстраивало (возможно я не нашел как в 8.5 это отключить без изменения типа точки доступа на FlexConnect). В 9800-CL мы можем сами определять, что будет уходить в туннель CAPWAP, а что будет выходить локально.

Потребляемая мощность

8.5 Вт!!!!! На фоне 1562i, для которой надо UPOE это просто праздник какой-то

А теперь задачка

У нас уже есть VLAN, который используется для планшетов и этот же VLAN используется для Телевизоров. В нем транслируется IPTV через multicast. Как думаете, что будет если включить телевизор через 1815W и настроить выход этого vlan локально, через коммутатор? Правильно, ничего хорошего. Ситуация такая: При включении канала, у нас работает IPTV. Но!! при этом, на Uplink Wi-Fi контроллера начинается широковещательный шторм.

Если трафик выпускать через контроллер, то проблем нет. Кстати, об этом нигде в мануалах не написано, что не стоит использовать vlan которые уже есть на SSID-ах и выпускать трафик локально через коммутатор.

Проблему решил просто создав для планшетов отдельный vlan. Интересная вещь, если вы переключите политику с центральной маршрутизации на локальную, то настройка применится на лету, а вот DHCP нет. Только перезагрузка точки доступа (минут 30 потратили на это, пытаясь понять что происходит).

Так как данный пост не проплачен Cisco, поговорим о минусах.

Минусы

Как вы видели выше, эта точка доступа может монтироваться как вместо сетевой розетки, так и просто горизонтально. НО! Для реализации этого в точке доступ очень хитро сделано подключение. А именно, основное подключение идет сзади

Как вы думаете, что это за PoE и Pass-Thru. Задумка, наверно была такая. Приходит два сетевых линка, вы убираете розетку. Устанавливаете точку доступа в подрозетник, один линк идет в PoE и питает точку доступа, второй уходит насквозь и снизу забираем чистый линк. Да, при таком монтаже все отлично.

А если у нас горизонтальный монтаж? А тогда купите дополнительно еще коробочку:

Иначе увидите это:

Ну а что, стильно, молодёжно. Кстати перемычки пришлось обжимать самим, так как заказывать какие-то специальные уж совсем не хочется. Так что на стол просто так эту точку положить не получится.

Если вам интересно, что же делает эта перемычка, расскажу. Она, соединяет вход PoE точки доступа, с портом который прокинут внутри точки доступа вниз, куда вы подаете сигнал от коммутатора.

Спрашивается, почему нельзя было это сделать джамперами.

А теперь еще интересная вещь.

Вдруг вам захотелось подключиться к точке доступа консолью, и..

Конечно, у всех завалялась парочка таких консолей, от других коммутаторов, точек доступа (нет). Для того чтобы подключиться нужно купить переходник

Конечно, можно сказать, что мало места, где тут RJ-45 вставить, но простите. Все давно уже придумано

Mini-USB. Уже давно используется, хотя конечно не везде заменяет на 100% обычную консоль.Mini-USB. Уже давно используется, хотя конечно не везде заменяет на 100% обычную консоль.

А теперь как вы думаете, что будет если точку доступа с настройками RLAN перезапустить?

те кто читал предыдущую статью, думаю догадались. Подсказка CSCvs08564

И да, баг уже починили.

А все просто, порты которые нужно отдельно активировать на КАЖДОЙ точке доступа (Где тут логика, вообще не понятно), после перезапуска опять становятся выключенными. А теперь как вы думаете, что делают люди, когда у них что-то не работает и оно под рукой? Правильно, перезагружают. В итоге замкнутый круг, разомкнуть который можно только пригрозив карой небесной, чтобы в руки не брали даже.

В итоге, посидев пару дней, повспоминав всё что забыто, я написал таки скрипт, прикрутил к Zabbix (кстати, а ваша система мониторинга хорошо интегрируется с самописными скрпитами?) и у меня появилась своя автоматизация, которая лезет на контроллер, ищет все точки доступа с политикой RLAN, далее отдаем Zabbix, он формирует этот список и далее идет второй скрипт, который по каждой точке смотрит состояние порта, если он отключен, он его включает но при этом уведомляет Zabbix, что там было отключено.

Послесловие или не все точки доступа одинаковые

Если вам очень понравился функционал 1815w, а у вас такой нет и вам очень грустно. Не расстраиваетесь, тем же функционалом обладает 2802i и 3802i. Но, так как там второй порт (он же AUX) создавался изначально под другие цели (в виде Etherchannel c 3850), то то что работает на 1815W, на 2802i может не заработать. У нас был кейс, когда телевизор не захотел работать через 2802i (точнее, он пинговался, но вот HTTP точка дропала) и закончилось это...

After discussing the issue in depth with our escalation and development team we came to the conclusion that RLAN with local switching has never been tested on Barbados AP platform i.e. 2800 AP models. I have raised an enhancement bug for this feature to be added in future controller releases. The bug is still internal so cant share much details. Some portions of code related to RLAN config is copied from 1815 AP model to 2800 APs which might be helping the desktop/laptop clients to pass traffic in RLAN local switching mode. But this is yet to be properly tested in our labs and to be added in the feature matrix of the 2800 APs. Current Controller/AP codes does not support RLAN local switching.

Возможно уже починили, проблема была на 17.2. На 17.5 не проверяли. На этой позитивной ноте разрешите откланяться.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru