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

Материалы для подготовки

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

Чтобы не скакать от главы к главе и при этом двигаться от простого к сложному, я буду привязывать части (Part) и главы (Chapter) в учебнике к названиям глав статей. Подобный подход так же поможет вам удобнее ориентироваться в статьях в связке с OCG.

Важно! Несколько моментов для экономии времени и повышения качества вашей жизни:

  • В первом и втором разделе будет много реверансов во вчерашний день, поэтому настоятельно рекомендую начинать с оглавления, которое будет присутствовать в каждой статье. Сэкономите время, если та или иная тема для вас не актуальна.
  • В ENCOR про L2 уровень информации мало, скорей всего по причине малой актуальности. Если ваша цель - темы ENCOR, смело пропускайте этот раздел, он больше для пробы пера и вспоминания основ с более глубоким погружением.
  • Из ближайших тем ENCOR:
    • TCAM (о ней во втором разделе);
    • CEF, RIB/FIB - о них будет либо во втором разделе, либо в третьем;

Организационные моменты

Я не являюсь инструктором или опытным CCNP/CCIE, все изыскания продиктованы только моим интересом к сетям. Рассматривайте мои статьи/посты с призмы критического мышления и обязательно зовите на дискуссию, если я где-то дурак и вообще не прав.

О сути статей: Я не буду просто переводить главы из OCG.
Основной целью является обобщение информации в книге + мои изыскания по теме и подача в виде структурированного материала с сылками (по возможности) на стандарты.

О количестве статей: Я решил писать статьи по номерным частям (Part) OCG ENCOR и делить их на кусочки по следующему принципу:

  • если в большой части есть несколько глав (Chapter), то это будет отдельная подстатья большой темы, обозначенной в части.
  • подстатью выпускать разделами, если статья будет неприлично разрастаться. Части постараюсь дробить на самостоятельные блоки, без сильных разрывов в темах. Нумерация будет следующая: Часть 1.* - где "1" - номер части, а "*" номер раздела.

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

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

Exam topics:

  • 1.7 Differentiate hardware and software switching mechanisms
    • 1.7.a Process and CEF
    • 1.7.b MAC address table and TCAM
    • 1.7.c FIB vs. RIB

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

Совет: Если желаете +- то же самое впитывать в видео-формате, вам на networkeducation.ru за подпиской на мультики Иннокентия Солнцева по старому CCNP. Крайне рекомендую. В моем материале будет много пересечений с материалом Иннокентия т.к я их так же потихоньку впитываю, но стараюсь не пересказывать. Само собой, в видео Иннокентия все будет нагляднее и подробнее.

В дополнение к основной программе, я хочу окунуться в RFC/ISO и OCG старого CCNP. В отличии от CCNA, я буду копать глубже, ибо за неделю изучения темы, я уже столкнулся с кучей противоречий. Как я готовился к CCNA и как я представлял себе новый CCNP, а как оно на самом деле оказалось.

Как это будет выглядеть? Изначально, цикл статей все же по новому CCNP (ENCOR+ENARSI), а не о сравнениях полноты передачи материала в разные годы существования экзамена и не о неточностях в трактовках сетевых протоколов и концепций. Поэтому то, чего нет в OCG ENCOR (ENARSI) я буду помечать подписью [non-key topic], как, например, вся эта статья (кроме домена коллизий).

Тому есть несколько причин:

  • удобнее готовиться к экзамену, статья будет не такая “распухшая”
  • дать читателю возможность решить самому, копать дальше или нет
  • побудить в читателе желание изучить больше, чем просто закрыть экзамен и думать, что все в шоколаде.

Как работать с RFC/ISO

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

RFC и стандарты содержат исходную информацию, которая поможет понять происходящие на уровнях модели OSI, в протоколах и сетевых железках.

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

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

Полезным источником информации могут быть презентации от рабочих групп разработчиков. Самый простой способ их найти, это в запросе гугла начать поиск с filetype: и после двоеточия (через пробел) указать формат, например: filetype: pdf 802.1q.
Много полезного можно обнаружить.

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

Источник: ietf.org/blog/how-read-rfc/

L2 Relaying and Filtering

OSI. Cама модель выглядит так, уверен, все ее хорошо помнят:

OSI

Трафик генерируется приложением на верхнем уровне и двигается вниз до нижнего уровня, проходя процесс инкапсуляции в новые заголовки и модификацию (если нужно). И обратный процесс - деинкапсуляцию.

В статье пройдемся по первым трем (физический, канальный, сетевой).

Домен коллизий [key topic]

Во времена оригинального Ethernet, когда сеть, в большинстве своем, состояла из хостов и общего кабеля (несущей), к нему относился Ethernet: 10Base2 (“толстый”, толщина кабеля = 10мм) и 10Base5 (“тонкий”, толщина кабеля = 5 мм), роль несущей выполнял (в основном) коаксиальный кабель (coaxial cable).

На канальном уровне Ethernet работает с MAC-адресами.

Короткая справка: MAC состоит из 6 октетов, представленных в 16-й системе. Первая половина - OUI (organizationally unique identifier), присваивается определенному производителю, вторая половина назначается самим производителем и так же уникальна. Широковещательный - FF:FF:FF:FF:FF:FF. За пределы текущей подсети не передается. Мультикаст MAC-адреса: ipv4 - 01xx.xxxx.xxxx; ipv6 - 3333.xxxx.xxxx

Хабы (habs) - устройства, которые работают на физическом уровне и выступают в роли ретранслятора сигнала по всем направлениям. Все устройства, подключенные в хаб, существуют в общем проводе (канальной среде) и конкурируют за возможность передачи, т.е работают в half-duplex. Это называется доменом коллизий. В такой среде используя технологию CSMA/CD, для предотвращения коллизий (нивелирование негативных последствий от коллизий).

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

Как работает CSMA/CD

Схема CSMA/CD (carrier sense multiple access collision detect) подразумевала под собой механизм обнаружения коллизий.

При попытке начала передачи, Transmit Media Access Management (4.2.3.2 IEEE 802.3) пытается избежать конфликта с другим трафиком на несущей, путем мониторинга сигнала определения несущей, предоставляемого компонентом Physical Layer Signaling (PLS), и откладывая передачу трафика. Когда носущая свободна, инициируется передача кадра (после короткой межкадровой задержки, чтобы обеспечить время восстановления для других подуровней CSMA/CD MAC и для несущей). Затем подуровень MAC предоставляет последовательный поток битов на Физический уровень для передачи.

В современном Ethernet при полудуплексном режиме и рабочей скорости 1000 Мбит/с, минимальный размер кадра (4.2.3.3 IEEE 802.3) недостаточен для обеспечения правильной работы протокола CSMA/CD для требуемых сетевых топологий. Чтобы обойти эту проблему, подуровень MAC добавит последовательность "добивочных" битов (4.2.3.4 IEEE 802.3) к кадрам, длина которых меньше битов времени ожидания, чтобы продолжительность результирующей передачи была достаточной для обеспечения правильной работы протокола. Работу CSMA/CD можно разделить на два шага:

Шаг 1:

  • узел готовит кадр к отправке
  • если в несущей "спокойно", узел ждет некоторое время, равное периоду межкадрового расстояния (ineterframe spacing), чтобы наверняка не попасть в локальную коллизию, затем кадр отправляется в сеть, после чего узел мониторит возможный факт коллизии
  • если случается коллизия, узел переходит к процедуре обнаружения коллизии (см. Шаг 2)
  • если коллизии не случается, происходит сброс счетчика повторной передачи и завершение передачи Шаг 2:
  • Передача немедленно прекращается
  • вместе с преамбулой в сеть отправляется jam signal равный 32 битам, уведомляющий все узлы в сети о наличии коллизии
  • увеличивается счетчик повторной передачи
  • если достигнут максимальный уровень повторной передачи, происходит отмена передачи
  • узел определяется случайное время backoff таймера, в зависимости от количества коллизий
  • повторяется процедура шага 1

Глубже в Ethernet [non-key topic]

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

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

Работа Ethernet жестко зависела от времени. Основные тайминги:

  • Slot time - минимальный отрезок времени продолжительности передачи кадра
  • Interpacket gap - время между передающимися кадрами. (иногда Interframe spacing)
  • Backoff-таймер - рандомно выбранное время, которое обязан выждать узел, прежде чем возобновить передачу

Если с interpacket gap и с backoff-таймером все понятно, то slot time - это основная вещь, которая была непонятна лично мне, поэтому остановимся на нем подробнее.

Предположим, что узел передает кадр, и где-то в сети, ближе к узлу-получателю, происходит коллизия. Узел-отправитель сможет обнаружить эту коллизию только после того, как электрический импульс распространится обратно. Это требует времени. Если узел-отправитель закончит передачу до того, как коллизия дойдет до него, то он не поймет, что произошла коллизия.

Slot time гарантирует, что узел-отправитель передает сигнал в течение достаточно длительного периода времени, чтобы он мог обнаружить любую коллизию. В сетях Ethernet, работающих со скоростью 10 и 100 Мбит/с, slot time = 512 bit time.

Чтобы понять откуда взялось bit time, посмотрим на заголовок Ethernet. Чтобы удовлетворить требованию slot time, сколько байт должен передать узел?

Ethernet-frame

512 бит = 64 байт, в эту цифру включается преамбула, MAC источника/назначения, тип/длина и чек-сумма. Если не брать в расчет преамбулу, то получается 18 байт служебных данных и остается еще 46 байт минимального размера для полезных данных (payload data). Отсюда и минимальная длина Payload data = 46 байт.

Откуда 64 байта? Минимальный размер пакета Ethernet составляет 64 байта на 10/100 м, 512 байт на 1000 м.

Минимальный размер кадра выбирается на основании, что в случае half-duplex отправитель должен иметь возможность обнаруживать столкновение до того, как он заканчивает отправку кадра. Существует так называемый принцип “4 хабов” с размером сегмента кабеля между каждой из точек = 100м, при этом общий размер сети не должен превышать 500м т.к свыше этого расстояния появляется являение, называемое поздней коллизией (late collision), которая считается неблагоприятным явлением т.к узел не успеет распознать позднюю коллизию и бремя повторной отправки ляжет на протоколы уровнем выше, в отличии от локальной коллизии, которая происходит в пределах 512 bit time.

Замеры и вычисление 512 bit time можно найти в стандарте 802.3-2018 п. B.1.5.2, выполненные на топологии с 4 хабами, с приведенными табличными значениями задержек на каждом из отрезков.

За несколько десятилетий существования стандарта 802.3, мы имеем целый ворох технологий Ethernet, как для меди, так и для оптоволокна:

  • Оригинальный Etrhernet - 10 Мбит/с
  • FastEthernet - 100 Мбит/с
  • GigabitEthernet - 1000 Мбит/с
  • 10GigabitEthernet - 10000 Мбит/с и т.д.

Уже одобрен стандрат 800GigabitEthernet - IEEE 802.3ck.

Один из не очень важных вопросов, но который меня интересовал. Что происходит с преамбулой и SFD в современных стандартах? То, что удалось найти, говорит о том, что с ней все в порядке и она никуда не делась.

Преамбула/SFD передается на физическом уровне и ее нельзя заметить, например, с помощью wireshark.

Вот, например, можно посмотреть как выглядят кадры (преамбула так же присутствует) FastEthernet и GigabitEthernet, по ссылке галерея инфографики.

Касаемо 40/100GigabitEthernet, можно обратиться к стандарту IEEE 802.3-2018, пункт 81.2 (структура пакета) и 82.3.1.2 (короткое описание работы преамбулы). А в пунктах 117.2 и 117.3 указано, что 200/400GigabitEthernet функционально идентичны 100GigabitEthernet.

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

Далее пройдемся по менее обязательным в экзамене, но интересным вещам.

Auto-MDI/MDIX [non-key topic]

В современном мире подключение витой пары не вызывает трудностей, воткнул “RJ45” и работает. Но не так давно, необходимо было учитывать, что и к чему вы подключаете.

Путаница с RJ45

Всем известный коннектор RJ45 вовсе не RJ45, а 8P8C, согласно IEEE 802.3u. Настоящий "RJ45" имел название RJ45S (8p4c), обозначал конкретную конфигурацию и использовался в телефонных сетях (подключение модема). Модульный коннектор для Ethernet же имеет название 8p8c (8 position, 8 contact)

8p8c

"1.4.238 eight-pin modular: An eight-wire connector. (From IEC 60603-7.)" Cтандарты IEC платные, поэтому можем обратиться только к названию:

IEC 60603-7:2020: Connectors for electronic equipment - Part 7: Detail specification for 8-way, unshielded, free and fixed connectors

Существует две схемы подключения: T-568A и B, с помощью которых можно организовать прямое или кроссовое подключение.

Типичная схема подключения по T-568B:

T-568B схема

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

Для соединения двух коммутаторов или коммутатора и маршрутизатора требовались разные типы подключения кабеля Ethernet. Использование функции автоматического определения кабеля (auto-MDIX) решило проблему.

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

Согласно IEEE 802.3 п. 40.1.4, гигабитные и более скоростные каналы Ethernet по витой паре используют все четыре пары кабеля для одновременной передачи данных в обоих направлениях. По этой причине нет выделенных пар передачи и приема, и, следовательно, для связи 1000BASE-T никогда не требуются кроссировочные кабели.

Physical Medium Attachment (PMA, определен в IEEE 802.3 п.40.4) обеспечивает идентификацию каждой пары и обычно продолжает работать и по кроссировочным кабелям, даже если пары необычным образом поменяны местами, перекрещены или если полярность пары неожиданно инвертирована.

В Cisco это конфигурируется в субконтексте интерфейса, команда mdix auto.

Источник: sbprojects.net/knowledge/concab/utp/index.php

Auto-negotiation [non-key topic]

Механизм определен в стандарте 802.3 п.28 (для FastEthernet) и п.37 (для GigabitEthernet). Auto-negotiation (AN), работает на физическом уровне OSI. Используется семейством Ethernet в витой паре, с помощью которого два устройства выбирают общие параметры работы. (скорость, дюплекс и управление потоком). Сначала происходит обмен возможностями, а затем выбор самого производительного, который поддерживают оба.

Изначально он был необязательным компонентом стандарта Fast Ethernet. В FastEthernet использовались Fast Link Pulse (FLP), однако он обратно совместим с Normal Link Pulses (NLP), используемыми в 10BASE-T.

Позже протокол AN был расширен до спецификации гигабитного Ethernet и является обязательным для 1000BASE-T Gigabit Ethernet по витой паре. (а так же для 10GigabitEthernet и выше).

Важно помнить, AN необходимо проверять на обоих устройствах. Если AN включен на одном, узле но не включен на другом, AN работать не будет. Так же иногда следует вручную выставить нужную скорость и дуплекс, если устройствj некорректно работает с режимом speed/duplex auto.

Link Pulse - Механизм связи, используемый в сетях 10BASE-T и 100BASE-T для обозначения состояние соединения и (в устройствах с функцией AN) для передачи информации о способностях договариваться о методах общения. 10BASE-T использует Normal Link Pulses (NLP), которые показывают только состояние соединения.
Узлы 10BASE-T и 100BASE-T, оснащенные функцией AN, обмениваются информацией с помощью Fast Link Pulse (FLP), совместимый с NLP. (IEEE 802.3, п.1.4.307).

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

Источник: afrozahmad.com/blog/what-is-auto-negotiation-in-ethernet-interfaces

PFC [non-key topic]

Изначальный стандарт Flow Control (IEEE 802.3x) был разработан для решения проблем перегрузок сети. Когда, например, узел-отправитель отсылал трафик к узлу-получателю со скоростью в разы больше, чем тот может принять.

Работал он достаточно просто, в момент перегрузки одного из каналов, узел-получатель мог отправить PAUSE-бит, тем самым предотвратить переполнение буфера и потерю пакетов.

Следующим было расширение для 802.3x, описанное в IEEE 802.1Qbb.

Все тот же кадр PAUSE содержит 8-битную битовую маску приоритетов 802.1p (определяющую, какие классы трафика должны быть приостановлены) и таймер для каждого приоритета, определяющий, как долго трафик в этом классе приоритетов должен быть приостановлен.

Такой подход позволяет блокировать трафик определенного потока, а не всего канала целиком.

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

Источники:
ieeexplore.ieee.org/document/9622218 blog.ipspace.net/2010/09/introduction-to-8021qbb-priority-flow.html

Energy Efficient Ethernet [non-key topic]

Energy-Efficient Ethernet (IEEE P802.3az) - это метод, облегчающий переход к более низкому энергопотреблению и обратно в ответ на изменения в сети.

Суть технологии: линки остаются активными вне зависимости от наличия передачи данных. Если бы, во время отсутствия трафика, линк можно было бы перевести в “спящий” режим, это бы могло сэкономить энергию. Когда устройство решает, что данные больше отправлять не требуется, она может сделать запрос на режим ожидания low-power idle (LPI) на физический уровень (чип-PHY) контроллера Ethernet.

После этого PHY будет передавать символы LPI в течение определенного времени по каналу связи, а затем отключит свой передатчик. Периодически в канал посылаются сигналы обновления (refresh) для поддержания целостности канала. Когда есть данные для передачи, в течение заданного периода времени отправляется normal IDLE сигнал.

EEE

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

Чтобы порты оставались в режиме LPI, сигнал Keep Alive (refresh) должен непрерывно приниматься с обеих сторон.

Источники: ieee802.org/3/joint_sessions/jul_08/joint_bennett_1_0708.pdf ieee802.org/3/100GCU/public/mar11/bennett_01_0311.pdf grouper.ieee.org/groups/802/3/RTPGE/public/may12/bennett_diab_01_0512.pdf

Discovery connected devices [non-key topic]

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

CDP

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

CDP по умолчанию включен и посылает мультикаст-анонс (advertisement) на MAC-адрес 01-00-0c-cc-cc-cc каждые 60 сек.

Switch(config)# show cdp neighbors [ type member/module/number ] [ detail ]

Пример вывода из OCG Switch:

CDP show

Коммутатор получил пакеты CDP от трех устройств и с помощью команды show cdp neighbour мы можем посмотреть эту информацию в CDP-таблице. Короткий вид таблицы покажет что это за устройства (платформа), hostname, к какому порту подключены (текущего устройства) и с какого порта отправлен пакет (соседнее устройство).

Если добавить параметр detail к команде выше, то можно увидеть совсем неприлично много полезной информации…

Требования безопасности: отключать CDP/LLDP на портах, смотрящих в незащищенную сеть. Лучше их отключать совсем и включать только для конкретных задачт, но тут уж вам решать.

Выключить глобально:

Switch(config)# no cdp run

Выключить на конкретном порту:

Switch(config)# interface type member/module/number
Switch(config-if)# [ no ] cdp enable

Паример полезного использования CDP может быть отсутствие вменяемой схемы сети, тут CDP поможет как нельзя лучше (особенно, если вся сеть на Cisco).

LLDP

Link Layer Discovery Protocol (LLDP) - то же, что и CDP, но основанное на стандарте IEEE 802.1ab. Возможно использование в мультвендорной сети.
В некоторых протоколах используется как помощник, рассказывающий о возможностях устройства.

LLDP инкапслуируется в Ethernet и имеет значение Ethertype - 0x88CC.

Для LLDP так же зарезервирован отдельный мультикаст-MAC - 01:80:C2:00:00:0E. LLDP передает информацию в виже сообщения LLDPDU (IEEE 802.1AB, п.9.2), внутри которого содержится несколько TLV (Type, Value, Length) (п.9.4):

  • Type — описывает тип информации, которая передается этой частью сообщения (7 бит);
  • Length — размер поля Value (9 бит);
  • Value — описывает определенную характеристику устройства.

LLDPDU состоит как минимум из четырёх обязательных TLV полей: (п.9.2, Figure 9-1):

  • Chassis ID TLV (Type = 1);
  • Port ID TLV (Type = 2);
  • Time To Live TLV (Type = 3);
  • End of LLDPDU TLV (Type = 0).

После первых 3-х обязательных TLV и перед последним, может быть помещено некоторое количество опциональных TLV.

Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) — расширение стандарта LLDP, которое позволяет:

  • Автоматически обнаруживать сетевые политики (VLAN, 802.1p, DSCP),
  • Использовать более расширенное и автоматическое управление питанием на PoE хостах,
  • Отслеживать местоположения устройств и топологию, в том числе таких устройств как IP-телефоны,
  • Выполнять инвентаризацию устройств в сети и определение их характеристик
  • Отслеживать перемещения устройств и отправлять SNMP-сообщения на соответствующий управляющий хост.

Описан в стандарте ANSI/TIA-1057.

Каждое устройство хранит информацию о соседях в MIB.
Таким образом, эту информацию можно запросить с помощью SNMP, пробежавшись по каждому из устройств.

Далее: поговорим о коммутаторах, VLAN, о видах таблиц, с которыми работает коммутатор (CAM/TCAM в особенности).

Хочешь обсудить тему?

С вопросами, комментариями и/или замечаниями, приходи в чат или подписывайся на канал.