Мониторинг коммутируемых сетей

Интерфейсы для Enterprise Tech Companies требуют от проектировщика хороших знаний не только из сферы дизайна, но и из смежных сфер. Так, при проектировании инструментов для проектировщиков сети, требуется понимать аппаратное устройство коммутаторов, tcam, fib vs rib, cef. И многое другое. В данной статье разберем основы подходов к проектированию сети и правила визуализации информации с сетевых устройств.

Коммутация сети.

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

Итак, есть физическая коробочка с портами — коммутатор (network switch). Пакет прибывает в интерфейс, коробочка анализирует его заголовки, считает контрольную сумму. Коммутаторы очень распространены в SOHO (домашние и маленькие офисы). Работает на втором уровне модели OSI (Data Link Layer). Современные устройства условно можно разделить на две группы по методам обработки фреймов:

Первый метод это Store and Forward. Коробочка целиком принимает фрейм, смотрит на заголовки и отправляет дальше из интерфейса. Это называется Store and Forward. Если устройству больше 10 лет, то почти наверняка используется Store and Forward. Недостаток: долго, нужно принять сразу целый фрейм. Для некоторых компаний критично время отклика, например, в High Frequency Trading важны миллисекунды. Иногда речь даже о наносекундах.

Второй вариант, самый популярный в современной мире, называется Cut-Through. Такой switching более тяжелый в реализации, например, если с одной стороны 10 Gigabit Ethernet, а с другой 1 Gigabit Ethernet, мы не можем делать Cut-Through Switching. Если все интерфейсы с одинаковой скоростью, без проблем используем Cut-Through Switching.

Store and Forward и Cut-Through меняются автоматически, в зависимости от скорости. Если входящий порт 10GbE и исходящий 1GbE, мы не можем делать Cut-Through switching. Вам важно смотреть спецификацию к конкретной модели устройства, как работает переключение. Большинство коммутаторов дата-центров и больших офисов используют Cut-Through switching, и руками его переключать не приходится. 

Режим Store and Forward. Красное = ошибки показывают, на каком кабеле проблемы.

Ключевое отличие Cut-Through Switching от Store and Forward: решение принимается на основе первых 64 байт, тогда как весь пакетик длиной 1500 байт. Первые 14 байт это Ethernet, 20 байт IP address, 20 байт TCP (если мы говорим про IPv4). Коммутатор начинает анализировать фрейм в момент, когда принял первые 64 байта. Пока пакет доходит полностью, система уже приняла решение, куда его отправить. И перенаправляет пакетик в другой интерфейс.

У такого подхода есть проблемы: нет проверки контрольной суммы, значит, пакетик не отбросится, и мы не можем проверить CRC drop (Cyclic Redundancy Check). И второй минус: не можем проверить MTU check. В книгах пишут, что MTU check делается аппаратно, но так как мы не знаем размер фрейма, то принимаем решение до получения всего фрейма. Получаем гораздо более быструю коммутацию и маршрутизацию, клиенты из High Frequency Trading довольны. 

В книгах все просто: есть связка компьютер -> коммутатор -> коммутатор -> компьютер. Если возникают CRC-ошибки, то мы точно понимаем, что кабель между коммутаторами поврежден. Но в реальной жизни CRC-ошибки могут оказаться не там, где мы думаем. И юный сетевой инженер начинает менять кабеля не там, где следует. Правило: видим входящие CRC-ошибки, нужно прийти в коммутатор и посмотреть статистику пакетов, из какого интерфейса они пришли, и проанализировать ситуацию.

Реальная ошибка (красная) и фэйковая (оранжевая)

Вторая большая интересная история: есть некое количество интерфейсов на коммутаторе, например, все интерфейсы имеют скорость 10GbE в секунду. Это скорость прибытия пакетов, пакеты не могут двигаться быстрее или медленнее. Медленность достигается только за счет интервала времени и физических нюансов. Те, кто держал реальные устройства в руках, могли видеть счетчик на интерфейсе под названием Input Drop или Fifo Drop. Такой счетчик говорит, сколько пакетиков было отброшено. Но как это возможно? Ведь задача устройства попросту переслать пакеты в другой интерфейс. И если 10GbE с одной стороны, 10GbE с другой, как может быть потеря? Давайте рассмотрим.

Итак, пакет прилетает в интерфейс №0, а уходит из интерфейса №3. И в потоке данных могут быть пакеты, предназначенные для перенаправления в интерфейс №2. 

Другими словами, прилетело в 3 разных порта по 100% данных = 300%, а улететь должно из одного порта №2, у которого емкость 100%.

Интерфейс №2 забит на 100%. В какой то момент, один пакет попадает в очередь и она копится за одним пакетом данных. Приходится ждать свободной слот для того, чтобы закинуть пакетик, а другие пакетики в это время ждут в буфере. Буфер не бесконечный, он переполняется и пакеты отбрасываются. 

Что еще менее логично, коммутатор может быть загружен на 7%, но пакеты будут теряться по описанной выше причине. Это называется Head-of-line blocking (HOL). Решение есть: параллельные очереди. Если коммутатор это умеет, то он дороже, например DES-1026G. Чем аппаратно сложнее наша конструкция, тем дороже устройство. Самый дешевый сетевой адаптер, e1000, умеет всего одну очередь. Сетевой адаптер или коммутатор подороже обладают 8 очередями, и вы не столкнетесь с проблемой блокировки всего обмена данных. RB1100AHx4 это аж 25 простых очередей. Это происходит аппаратно и не сказывается на скорости. Существуют разные модели, для сервис-провайдеров, для дата-центров и так далее. Они сделаны аппаратно под разные условия и задачи. 

Частные сети используют следующие диапазоны:

  • 10.0.0.0/8 IP addresses: 10.0.0.0 – 10.255.255.255
  • 172.16.0.0/12 IP addresses: 172.16.0.0 – 172.31.255.255
  • 192.168.0.0/16 IP addresses: 192.168.0.0 – 192.168.255.25

Идем далее. Как же работают устройства.

У устройства есть сторона Receive и сторона Transmit. Receive сначала отрабатывает как физический интерфейс, получая электрический ток, потом формируется входящая очередь. На устройстве есть набор таблиц, такие как L2 forwarding (CAM) для перенаправления пакетов в определенную сторону, или Access List (ACL). Средний коммутатор обрабатывает 5-6 terabit трафика в секунду, и это много. Это миллиарды пакетов, и каждый надо проверить по таблицам. Появляются TCAM, в котором сравнение возможно по трем параметрам. Классические 1,0, и x, где x — решение не важно. После этого пакетики попадают в очередь на выход, и трафик улетает из устройства.

Мы очень активно использует таблицы на устройстве. Но таблицы не бесконечны, есть лимит по кол-ву записей. Значит, Access List имеет некие ограничения, как и кол-во маршрутов, зависимость прямая от набора микросхем. Это физическое ограничение, какие обновления не накатывай, больший объем данных на микросхему не влезет. Поэтому есть устройства разной цены, какое-то сможет выучить 8 000 мак-адресов, а другое 200 000 мак-адресов. Бесконечно большими таблицы не делают.

Итак, таблица форвардинга для L2 — CAM, форвардинг для L3 — FIB. Кроме перекидывания пакетов из интерфейса в интерфейс, есть логика, которая за пределами этих двух таблиц. Эта логика живет в таблице TCAM, в котором описываются дополнительные функции. 

CAM-таблица обязательна на любом устройстве. В CAM находится три значения: MAC, исходящий порт Ingress, VLAN. В некоторых коммутаторах TCAM не обязательна, в ней нет очередей, нет классификатора, и без TCAM обычно речь о дешевых устройствах. Например, мы хотим запретить трафик между определенными хостами в сети. Пишем ACL на коммутаторе, что host 1.1.1.1 не может отправлять трафик на host 1.1.1.2, и таких правил у нас тысячи. Придется каждый входящий/исходящий фрейм проверять на соответствие условиям всех правил, что замедляет работу. TCAM же позволяет проверку соответствия правилам за один проход, и мы можем спокойно использовать ACL.

Если в таблице есть Destination mac-адрес, то совпадение находится аппаратно. Система говорит, из какого порта и в каком VLAN надо отправить пакет. VLAN это всего лишь изоляция на канальном уровне.

Аналогично работает на маршрутизаторе. Но у маршрутизатора, кроме переотправки пакетов, есть и другие задачи. Как и на коммутаторе, есть сторона RX для прибывающих пакетов. Все уходит в очередь, разве что очереди могут быть по разному организованы. Из очереди мы попадаем в наборы табличек TCAM, и появляется таблица L3 forwarding (fib) в дополнение к L2 forwarding (CAM). Помимо этого, маршрутизатор меняет значение L3 заголовка (так как пересчитывается хэш), коммутатор же ничего не переписывает. Роутер/маршрутизатор попадает в L3 rewrite, переписывает заголовок и отправляет в Egress Q и далее, TX. Это меняет сложность работы устройства, особенно это было трудно реализовать на ранних этапах развития технологий. Что сильно повышало стоимость роутера в разы. 

Как это работает на практике. У нас есть набор маршрутов:

  • 10.0.0.0/8 via 192.168.0.7
  • 10.0.0.0/16 via 10.0.9.7
  • 10.0.0.0/24 via 192.168.1.95
  • 10.0.0.0/27 via 192.168.9.3
  • 10.0.0.0/32 via 172.16.0.7

Прилетает 10.0.0.4, он соответствует первым 4-ем записям. Будет выбран 10.0.0.0/27 via 192.168.9.3, потому что он наиболее специфичный (у него меньшее кол-во адресов внутри себя). Это не самая простая логика, нужно выбирать, маршрутизация идет по IP и по специфическому префиксу.  

Пример FIB-таблицы:

IP AddressТext-Hop IP Address Mac-address for Next-HopEgress port
10.0.0.0/27192.168.0.700:1B:44:11:3A:B7Gigabit Ethernet 0/0

Пример CAM-таблицы:

Mac-addressEgress portVLAN
0000.0000.000A134

Аппаратно делать выбор довольно сложно, да и отдел закупок попросит выбрать устройства подешевле. На выручку приходит технология route-cache. У маршрутизатора есть центральный процессор, и в сети бегает TCP или UDP поток. Когда первый трафик прибывает в интерфейс маршрутизатора, первый пакетик отправляется на центральный процессор. Процессор принимает решение, в какой интерфейс его отправлять. Пакет уходит в выбранный интерфейс, процессор создает кеш, и все последующие пакетики в рамках сессии уходят в аналогичный порт. Это ускоряет взаимодействие. Маршрутизатор попросту запоминает, куда были отправлены пакеты. Встретил похожие из одного соединения? Отправляет по уже знакомому маршруту, без проверки в FIB. Кеш маршрутов периодически очищается, примерно раз в 10 минут. Звучит здорово, но такой подход уже не используется, разве что на очень старых устройствах. Много сессий = много работы для CPU.

Современный подход называется topology-based или CEF. В основе лежит заранее созданный кеш. Да. его можно создать заранее, Cisco придумало как именно, маршруты уже есть в таблице маршрутизации. Если вдруг CEF не может обработать пакет, лишь в таком случае пакет уходит на CPU. В остальное время все ресурсы процессора уходят на пересылку пакетов.

Forwarding Information Base (FIB) создается из двух типов табличек: таблица маршрутизации + таблица сходства (ARP-таблицы с небольшой натяжкой). Без участия центрального процессора, чего мы и хотим. Если же центральный процессор задействован, так как трафик не может быть обработан аппаратно, то это называется CEF PUNT. Есть счетчик, который показывает, сколько записей отправляется на центральный процессор.

На примере: маршрут к 10.1.0.0/16 находится в FIB вместе с маршрутами к 10.1.1.0/24 и 10.1.1.128/25. Маска подсети становится все более длинной. Адреса в FIB отсортированы по наиболее специфичным маскам (Longest-Prefix Match или LPM). Пакет прилетает в коммутатор, устройство проверяет адрес назначения и быстро находит информацию о маршруте назначения с самым длинным совпадением в FIB.

Мы поговорили про девайсы, которые удобны в эксплуатации. Достаточно посмотреть в буфер, найти исходящие интерфейсы и перенаправить трафик в нужный порт. Существуют и более сложные устройства. Pit-box коробочки, высота 1RU. Всегда кол-во портов напрямую зависит от микросхем, эффективности их охлаждения, расстояния друг от друга и потребления электричества. Поэтому количество портов для одного девайса ограничено. Нужно увеличить кол-во портов? Встречаем модульные устройства, такие как Nexus 9500, где много портов.

Такие устройства покупаются, чтобы получить нужную плотность портов внутри одной коробки. Это дорогое устройство, 600 портов = 600 серверов, а это очень большая инфраструктура, мало компаний в РФ содержат парк устройств более 600. Если такая коробка выйдет из строя, то это потеря всей инфраструктуры. Что чревато смертью бизнеса.

Поэтому добавлена избыточность в плане управления, так, модуль управление устройством называется супервизор (control plane). Ранее мы говорили о CPU для управления набором микросхем. Супервизоров в устройстве два: один активный, второй ждет смерти первого. 

Линейная карта это модуль (line card), в мире серверов также встречается название blade (лезвия). Технически это коммутатор в форме микро-схемы. Можно брать разные линейные карты, но супервизор будет один. И возникает проблема, что трафик может прилететь в одно физическое устройство, и вылететь из другого. И это разные микросхемы, приходится их учить обмениваться данными о таблицах.

Типичная жизнь пакета в описанном выше модульном устройстве: есть входящая и исходящая линейные карты. Чтобы сигнал перешел из точки А в точку Б, карты должны быть физически соединены. Появляется прослойка в виде Networking Switch Fabric, отвечающая за связанность всех линейных карт. В зависимости от устройства, линейные карты имплементированы по разному, например: есть отдельные network processor (NPU) и группа портов, которая обслуживается одним network processor. И разные группы портов обслуживаются разными network processor.

Модуль под названием PHY отвечает за обработку физического сигнала. Мы принимаем сигнал, PHY идет в Network Processor и происходит работа: классификация пакетов, очереди. Очереди смотрят в Fabric Interconnect -> буферизация, и далее Switch Fabric может склеить сетевые пакеты в супер-пакеты. Что позволяет делать меньше прерываний и обрабатывать больше пакетов. Внутри Switch Fabric есть арбитр, который отслеживает достаточность пропускной способности для пакетов. 

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

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

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

Зеленый цвет это Ingress Forwarding Controller, и прибывший пакет проходит через очередь (FIFO). Для планирования существует Scheduler с пакетным буфером, который связывает Ingress и Egress. И пакетики вылетают через нужный порт. Просто?

Для двух направлений две микросхемы. Ingress отвечает за L2 и L3 Lookup, Policer для ограничения трафика (не более 100 мбит/сек, даже если технически возможно 10GbE), туннель, классификатор для деления трафика, ACL, и много чего другого. Все это делается параллельно. 

Egress делает примерно аналогичные действия, но Lookup уже не нужен. Дополнительно, Out Policer, отправка копии трафика. Самое простое объяснение: трафик, поступающий из Интернета в локальную сеть, будет ingress, а трафик из локальной сети в Интернет — egress. Но эти понятия взаимозаменяемы, поэтому термины не особо употребимы практикующими специалистами.

На in FIFO пакетики дублируются: оригинал уходит в буфер, а копия в Ingress Controller. Считывание заголовков делается из копии. Просматривается таблица (CAM, TCAM, FIB), которые могут находиться в разных местах, и принимается решение, куда отправить трафик. Принятое решение записывается в Package Descriptor, он уходит в буфер (где хранится оригинал трафика), и далее процесс планировщик -> forwarding controller -> переписали заголовки -> пакетик улетел по месту назначения. По простоте не в пример любой модульной системе, такой как ASR 9922.

Native VLAN. Мало кто умеет им пользоваться. Умение им пользоваться это конкурентное преимущество. Мы уже знаем про два режима работы интерфейса: Ethernet Access и инкапсуляция dot1q в Trunk. А что, если понадобилось отправлять пакеты в Trunk с инкапсуляцией Ethernet. Вполне популярная задача для выявления проблем или для дата-центров.

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

Вы купили устройство, вставили в стойку, а в устройстве не установлена операционная система. Это ваша работа ее устанавливать. Если говорить про большие инфраструктуры, никто на сервера не ставит операционную систему с ноутбука. Можно использовать KVM, но при новых 4000 серверов за месяц лучше воспользоваться следующим способом: BIOS сервера отправляет DHCP Message на DHCP сервер, и получает ответ в виде операционной системы с конфигурацией.

Но есть нюанс: сервер из коробки. Сервер ничего не знает про VLAN. И проблема — со стороны сервера Access-интерфейс, а со стороны коммутатора — Trunk. Переделывать порты из Access в Trunk это долго и не технологично. А использовать параметр Native VLAN уже весьма технологично, где порт Trunk может обслуживать пакеты Ethernet: сервер загрузился, все его сообщения попадают в VLAN, операционка установлена, виртуалки стартанули. 

Далее избыточность. Обсудим наш первый протокол для борьбы с избыточностью, который работает поверх сети. Протокол для уничтожения избыточности называется Spanning Tree, хотя его уже трудно встретить в изначальном виде. Отключать протокол с не надо, а вот знать его надо как основу коммутируемых сетей. Не все любят этот протокол, так как он блокирует интерфейсы. Но нет ни одной причины отключать STP. Только если вы Lead-инженер, и подключаетесь в другую сеть, которой вы не управляете. Тогда допустимо отключать протокол на всего одном интерфейсе.

Сети не строятся без избыточности. Посмотрите на пример сетки из трех коммутаторов. Если с кабелем проблема, то теряется связность.

Но проблема в работе Ethernet, ведь пакеты могут начать ходить бесконечно, мы получим закольцовку, и все коммутаторы умрут в петле. Вывод: физически сеть должна быть избыточна, а логически — нет. Надо научить коммутаторы понимать топологию и вместе решать, какой порт лишний. Протокол Spanning Tree Protocol (STP) выключает все лишнее на логическом уровне. 

Если коммутатор за $100 и криворукие инженеры, то можно отключить STP и ждать последствиями. Однажды придет монтажник, обрежет пару кабелей и соединит скруточкой. Или уборщица воткнет проводок в порт списанного маршрутизатора, просто чтобы не мешал.

Loopback Detection (LBD) должен помочь, но он срабатывает далеко не всегда, и его часто не включают. Особенно, когда у вас дешевое оборудование. Есть много способов, чтобы все пошло не так: broadcast control создал broadcast storm и развалил всю сеть. Поэтому надо делать сразу надежно. Вот как это делается:

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

Выбор главного коммутатора. У каждого коммутатора есть уникальный mac-адрес. Чем меньше значение mac-адреса, тем главнее коммутатор. Но проблема: mac-адреса назначаются на коммутаторы по порядку, и самый старый девайс будет самым приоритетным. Хочется указать более новый девайс как главный, и это возможно благодаря параметру priority, который мы можем задать. Чем ниже приоритет — тем устройство более приоритетно. В итоге выбранный коммутатор становится Root Bridge (Switch) и от него считается топология L2.

Настало время блокировать ненужные интерфейсы. У интерфейсов разные скорости, и если заблокировать быстрые порты, то мы теряем в скорости. Нужно уметь блокировать избыточный и медленный порт, а не просто избыточный. За скорость отвечает параметр Cost, который формируется из времени доставки пакетика до Root-коммутатора. 

Если Cost совпала по всем направлениям, то смотрим на последнюю инстанцию: Sender Bridge ID. Маршрутизатор, у которого Bridge ID самый маленький, создает BPDU-сообщения. Они прибывают в другие коммутаторы и уходят далее. Каждый коммутатор добавляет Root и Sender Bridge, и добавляет значение Cost. И тот, у которого Sender Bridge ID больше — тот и блокирует порты. 

И казалось бы, все решено… но если воткнули кабель из одного порта в другой в рамках одного устройства? Тогда Port-Priority. У каждого порта есть свое Priority, чем меньше значение, тем порт более приоритетен.

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

  • правильно настроить priority;
  • определить избыточные линки;
  • фильтрация BPDU на интерфейсах, которые не должны участвовать в построении дерева;

STP очень древний протокол, и работает на таймерах. Общий принцип уже понятен: коммутатор получает сообщение, смотрит таблицы и передает сообщение далее. Но центральный процессор тоже умеет создавать и отправлять BPDU-сообщения. Как только появился root-коммутатор, только он отправляет BPDU-сообщения. 

Пытливые юные хакеры могли представить, как они вместо компьютера вставляют в сеть свой коммутатор и указывают ему priority = 0. Так он станет root-коммутатором и весь трафик будет ходить через ваш роутер. И это может сработать. Коммутатор может быть софтверный, в Windows это Network Connections -> Bridge Connections. Как сетевые инженеры, мы можем захотеть указать конкретный коммутатор как root, чтобы коммутатор доступа не смог стать вершиной топологии. Только коммутатор ядра или дистрибьюции. Сам по себе протокол STP нам с этим уже не поможет.

Но решения есть. Первое решение это BPDU Guard на портах доступа. BPDU Guard позволяет отправлять BDPU сообщения из порта, но если в порт придет внешнее BPDU-сообщение, то интерфейс погаснет и первый уровень модели OSI перестанет работать. Инженер однажды придет и увидит, что был инцидент err-disabled, и начнет разбираться. В итоге, включит порт ручками. BPDU Guard для конечных устройств — отличная штука. 

Второй вариант Root Guard. Боремся с получением BPDU-сообщения с высокими значениями ID. Порт не станет root-портом. Используем, если мы точно уверены, кто должен быть root-коммутатором. 

Третий вариант — PortFast или EdgePort. Применяется на конечном устройстве, когда порт начинает участвовать в STP. В процессе Listening -> Learning — Forwarding, где 30 секунд пакетики не ходят при старте устройства, интернет недоступен. Что кажется диким для современного мира. Так как речь о конечном устройстве, а не об коммутаторе, интернет нужен моментально. Благодаря PortFast, как только порт включается в работу с сетью, система переключается на forwarding без лишней возни с состояниями listening и learning, так как на конечном устройстве не может быть петли.

И BPDU фильтр — используется очень аккуратно! Он выключает STP на порту. Из порта не будут вылетать сообщения, и все входящие будут игнорироваться, а это опасно с точки зрения петли в сети. Но если вы хотите вставить коммутатор в сеть интернет-провайдера, а у них там тоже коммутатор, то BPDU фильтр это ваш выбор.

Мы рассмотрели ситуацию, когда уборщица вставила кабель в порт и все сломалось. Рассмотрим обратную ситуацию: кабель вытащили и все сломалось. Устройствам нужно оперативно переключить один Root Port на другой, а на это потребуется почти минута доступа в интернета. Представьте современного человека без доступа в Интернет на целую минуту. STP хорош для поиска избыточности, но работает на таймерах. Все, что работает на таймерах — довольно глупое по логике.

Поэтому используется более современная версия, Rapid Spanning Tree Protocol (RSTP), который работает не на таймерах. И даже больше: в классическом STP все устройства получают BPDU-сообщение и лишь передают его дальше. Сами устройства не генерируют сообщение, только обогащают его. В RSTP каждое устройство может генерировать BDPU-сообщение. Это позволяет устройствам общаться в режиме Proposal/Agreement. Получив Proposal, коммутатор начинает общение с другими устройствами, для этого он блокирует порты и соглашается или не соглашается, что Proposal это лучшее значение параметра BPDU. Устройство выбирает лучшее BPDU-сообщение и отправляет дальше. Каждое изменение в сети приводит к изменению топологии.

RSTP и STP совместимы, и если уборщица вставила в порт старое устройство, то все отработает корректно на STP. Забавный факт: если порт отправил RSTP-сообщение и не получил ответа, он попробует отправить обычное STP-сообщение. И только потом последует изменение состояния порта. Это долго, поэтому всегда настраивается PortFast. И еще одна причина настроить PortFast это для уверенности, что L3-устройства не спровоцируют ненужные реакции сети. 

Теперь немного усложним себе жизнь. Multiple STP Instances: создаются инстансы, в каждом есть VLAN-ы. STP-дерево строится на каждый инстанс, оно становится MSTP Multi-Region, одна из зон Common and Internal Spanning Tree (CIST), и получается такая матрешка: внутри региона свои инстансы с разрешенными VLAN. Ваша профессиональная цель это чтобы у вас не было MSTP Multi-Region Spanning Tree Protocol. Вы никогда не сможете быстро и легко искать ошибки в такой матрешке на уровне L2. Поэтому всегда должны совпадать revision, instance и name. 

Как и Multicast. Если в Multicast теряются пакеты, то это сложно поправить. Основная проблема это RTF-check, правильно указать randevu-point, и дропы Multicast. Multicast должен помочь более эффективно передавать трафик, поэтому Multicast отрабатывает только на самом близком коммутаторе к конечным устройствам. Например, при трансляции IPTV это вполне рабочая история. 

Multicast может быть на L2 и на L3. В пакетике есть IP и Ethernet-заголовки, BPDU-сообщение это пример L2-сообщения. И у нас есть много коммутаторов, они не умеют маршрутизировать, работают на L2. 

На третьем уровне сетевой модели (IP), 224.0.0.0 — 239.255.255.255. Multicast это всегда Destination (получатель), а не отправитель. Сервер отправляет пакеты на адрес 225.0.0.1, Multicast с MAC-адресом у нас нет, но есть набор получателей в виде компьютеров. И начинается пуляние пакетами во все направления, как типичный Broadcast. 

Приходит на выручку IGMPv2 — этот протокол извещает устройства, что появился новый компьютер, желающий получать Multicast. Клиентский компьютер отправляет IGMP-сообщение, что хочет получать трафик в 225.7.9.100, это уходит через сеть коммутаторов на роутер. Роутер теперь знает, что есть Multicast-получатели в коммутируемой сети. Для доставки пакетов именно тому клиентскому устройству, которое делало запрос, используется IGMP Snooping. В результате, Multicast хоть как-то отличается от Broadcast для коммутируемой сети.

Существует и IGMPv3, который позволяет выбрать источник, благодаря чему нам не нужны Rendezvous Points. И SSM (Source Specific Multicast): есть маршрутизируемая сеть (роутеры), и есть сервер-источник. В такой ситуации RPF check помогает предотвратить закольцовку, просматривая в IP-адрес отправителя и в таблицу маршрутизацию. Принимает Multicast только из интерфейсов, из которых есть маршрут до отправителя.

Сервер вещает в Multicast-группу, а компьютер ничего не знает о сервере, он просто отправляет свои хотелки в коммутатор: IGMP-сообщение с просьбой прислать ему Multicast в 225.0.1.2. Но откуда роутер знать, кто является отправителем Multicast? Отправитель и получатель встретятся в так называемом randevu-point. О существовании randevu-point знают устройства, и строят Multicast дерево от отправителя до получателя. На втором уровне сетевой модели устройства отправляют IGMP-сообщение, выражая желание участвовать в получении данных. 

PIM Sparse Mode — самый популярный способ доставки multicast-трафика. Требует специально обученного роутера, который и будет randevu-point. Все устройства знают, куда передавать мультикаст. Существуют менее популярные Bidirectional PIM и PIM dense mode. Как всегда, мы за отказоустойчивость и хотим подстраховаться, размножив роль роутера randevu-point, решается это с помощью MSDP или Phantom RP.

Отказоустойчивость

На схемах выше роутеры напрямую соединены с другими роутерами. Но обычно роутер воткнут в коммутатор, в реальной жизни роутер соединяется с роутером через коммутатор. А если есть коммутатор, то есть и STP. И ситуация: провайдер присылает нам BPDU-сообщение с priority = 0, и для нашей сети коммутатор провайдера становится root. Решать это мы уже умеет: включаем BPDU-фильтр на интерфейсе, который подключен к провайдеру. А если к провайдеру идет два интерфейса, тогда BPDU-фильтр уже опасен. Что делать?

В сети отказоустойчивость и избыточность тесно связаны. Был коммутатор, который воткнут в сервер. Мы добавили второй коммутатор и протянули второй кабель, запасной. Добавилась избыточность, STP блокирует все избыточное. А если у нас большая сеть, любые изменения занимают время на перестройку STP. И не забывайте, что коммутатор это железка за 10 000$, трансиверы по $1500. Мы закупили все это оборудование, установили, часть портов не используются, и ждем когда что-нибудь сломается и купленное оборудование отработает. 

Port Channel: физические интерфейсы становятся одним интерфейсом на логическом уровне. А один интерфейс не может быть заблокирован STP. Есть нюансы: коммутатор должен перенаправлять трафик, но трафик вылетает из конкретного физического интерфейса. И надо выбрать, из какого интерфейса отправить пакетик, он не может разделиться на атомы и быть собран на клиенте. На самом деле, может, но если раскидывать пакеты на разные интерфейсы, то пакеты могут прилететь клиенту out-of-order, то есть в порядке 3-1-4-2 вместо 1-2-3-4. Поэтому на Port Channel всегда будет ограничение на одну сессию по скорости интерфейса. 

Так как из разных интерфейсов могут прилетать разные данные по объему, нужен Load Balancing Algorithms. У разных моделей коммутаторов разные подходы, дешевые коммутаторы ограничиваются балансировкой с помощью на Source и Destination MAC. Более дорогие это Source + Destination IP. 5-Tuple это признак современного устройства.

Как это работает: есть 4 интерфейса, они все участники одного Port Channel. Считается хеш по паре Source MAC + DST Link, и делится по модулю. Хеш 73 / 4 = 1. Именно через порт 1 и будет вылетать трафик. При 5-tuple трафик распределится равномерно, старые модели распределяют трафик неравномерно и с этим ничего не сделать. 

Есть опасность объединить интерфейсы в Port Channel на двух коммутаторах по разному, это приведет к петле в сети из-за STP, или к потере пакетов. Решение простое: Port Channel бывают статические и динамические. Статический Port Channel может привести к неправильной работе STP.  Динамический Port Channel это Control Plane. LACP PDU автоматически уберет неправильно настроенные порты. Но это про коммутаторы; LACP тянуть к серверу уже не так беззаботно, так как на сервера льется операционная система с помощью DHCP. А технология LACP подразумевает, что она есть на обеих сторона (коммутатор + сервер). Сервер из коробки идет без LACP, и блокируются порты. 

Еще одна технология отказоустойчивости это набор протоколов FHRP, включает в себя протоколы GLBP, HSRP, VRRP. Если у вас только Cisco, то используете HSRP. GLBP очень редко используется. Такие протоколы предоставляют избыточность первому хопу. Ранее мы затрагивали только коммутируемые сети, они работают на коммутаторах. Но дублировать коммутаторы не всегда хорошая идея, порой нужно дублировать маршрутизаторы L3. Если на два роутера назначить одинаковые IP-адреса, то все будет плохо. Но мы хотим дублировать функционал роутера. 

Мы можем назначить второму роутеру другой IP, но поле Gateway на клиентской машине одно. А IP-шников два. Мы не сможем прописать два шлюза через графический интерфейс. Сможем через консоль, но, тем не менее, трафик будет теряться при отказе одного из роутеров. Конечные устройства это обычно один шлюз. 

Решение: все таки назначаем разные IP-адреса, и создаем HSRP-группу на интерфейсах роутера. Назначаем Virtual IP (VIP), после чего роутеры отправляют L2-multicast в виде HSRP-пакетов. Один ротуер станет master, второй slave. Как только один роутер умер, второй роутер забирает себе VIP.

Конечное устройство не всегда компьютеры. Это может быть и сервер. Если вставить сервер в коммутатор, то при поломке все сломается. Было 50 виртуальных машин на сервере? Больше нету. Хочется перестраховаться и подключить сервер двумя интерфейсами. Каждый интерфейс это L3, то есть IP-адрес. С двух сторон по IPшнику. И как только мы создали Bridge, включается STP и один интерфейс наверняка заблокируется. Значит, иметь Bridge на сервере точно не хочется, а что остается? Сделать Port Channel. И докинуть еще один коммутатор. То есть, мы вставляем в сервер два коммутатора. И собираем кластер/стек: при помощи специальных коротких кабелей соединяем стек-кабелем два коммутатора, и одна операционная система управляет двумя коммутаторами. А может и 3мя, вплоть до 8. 

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

Лучше смотреть в сторону M-LAG или VPC. Есть два коммутатора, и между ними бегает keepAlive. Таким образом, у нас не кластер из устройств, а два отдельных устройства. Начинаются сложности с l3, но они case by case, vendor by vendor. Видите, какое хорошее решение? Одно предложение, и все понятно.

Еще один вариант: игнорировать L2. На сервере не должно быть L2, роутинг на хосте, маршрутизация на сервере. Это вариант для крупных компаний. Чем больше масштаб — тем проще нужны решения. 

Отправная точка мониторинг за устройствами это SNMP v2 и v3 (более безопасная). Сетевому инженеру постоянно нужно снимать статистику для обнаружения проблем. Проблема должна быть обнаружена до того, как стала заметна и заэффектила какие-то показатели компании. Протокол SNMP опрашивает устройства, для визуализации используются Cacti + Weathermap I, Solarwinds, Zabbix, PRTG. Но нужна настройка. 

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

Вторая проблема: в коммутаторе счетчиков очень много. И если собирать всю информацию с Control Plane, то это драматически скажется на производительности коммутатора/маршрутизатора. Это ограничения, которые мы должны учитывать.

Возможна обратная ситуация по подаче данных: коммутатор извещает SNMP о некой ситуации моментально. Это называется SNMP TRAP, умеет моментально отправлять уведомления на критичные события. Например, есть важный интерфейс коммутатора, и если он Down, надо красить дашборд в красный моментально. 

Логи нужно где-то хранить. SysLog принимает на себя события с устройства и отправляет куда-либо. Логи пишутся на физический носитель, и хранить их локально это нормально. Но обычно нужно передавать на Syslog Server и хранить за 3-4 месяца, обычно этого достаточно.

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

Визуализация

Отправная точка мониторинг за устройствами это SNMP v2 и v3 (более безопасная). Сетевому инженеру постоянно нужно снимать статистику для обнаружения проблем. Проблема должна быть обнаружена до того, как стала заметна и заэффектила какие-то показатели компании. Протокол SNMP опрашивает устройства, для визуализации используются Cacti + Weathermap i, Solarwings, Zabbix, PRTG. Но нужна настройка. 

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

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

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

Самая критичная статистика должна быть яркой и слева сверху. Тут участвует эффект Ресторфф, когда запоминается один объект, который выделяется из остальных. Название эффекта от имени Гедвига Фон Ресторфф, который обычно описывает красный цвет как самый запоминающийся. Но нужно быть осторожным, при неправильном дизайне может сработать эффект баннерной слепоты (Якоб Нильсен).

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

Какие компоненты используются:

Pie-Charts

Нужен для демонстрации долей. Например, доли инцидентов разного типа, распределение времени аналитика, бюджет на разные направления, соотношение использования функционала, наиболее часто атакуемые площадки. Основная проблема с Pie Chart — помнить цвета, какой цвет соответствует какому значению. Что не бьется с кратковременной памятью. По методу проверкуи проверки забывчивости является метод Брауна-Питерсона кратковременная память в районе 9 секунд. Поэтому постоянное переключение внимание между легендой и самим графиком.

Bar Graphs

Обычно бары могут быть расположены в любом порядке. Большинство столбчатых графиков располагаются по порядку, либо от самого низкого к самому высокому (т.е. восходящие значения), либо от самого высокого к самому низкому (т.е. нисходящие значения; также известен как Парето График). Однако, когда значения колеблются в течение определенного периода времени, как это происходит во многих приборных панелях, вы можете захотеть расположить столбики в алфавитном порядке или по какому-нибудь другому фактору.

Существует много других визуализаций, таких как Choropleth, Line Chart, Scatter Plot, Box Plots, stacked bar graph. Для проверки дашборда специалисты по UX используют следующие методы исследований:

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

Этнография — полевое исследование. Исследователь отправляется с респондентами на их рабочее место, где они используют продукт или решают свою проблему без продукта. Например, с помощью продуктов конкурентов.

Фокус-группы. Состоят из 3-12 участников, которые обсуждают заданную тему, выполняют определенные задания.

2 комментария

  1. 全驰 支

    При формировании архитектуры, учитывается ли то как работает сеть внутри организации?

    • Цветков Максим (Author)

      Учитывается аппаратное обеспечение:
      -телефония
      -рабочие станции
      -собственные серверы
      -арендованные серверы
      -сетевое оборудование
      -облачные мощности
      -кассы c подлючением к операторам фиксальных данных

      Программное обеспечение: CRM, CMS, ERP, серверы БД, веб-серверы, серверы с бизнес-логикой, оркестраторы, серверы очередей, системы аналитики (DWH, datalake) и многое другое.

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

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.