(). Мы понимаем, что для новичков «OSI» и «TCP/IP» - это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.

Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак, у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование, и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Следует несколько конкретизировать ситуацию:

1. В данный момент у компании есть два офиса: 200 квадратов на Арбате под рабочие места и серверную. Там представлены несколько провайдеров. Другой на Рублёвке.
2. Есть четыре группы пользователей: бухгалтерия (Б), финансово-экономический отдел (ФЭО), производственно-технический отдел (ПТО), другие пользователи (Д). А так же есть сервера ©, которые вынесены в отдельную группу. Все группы разграничены и не имеют прямого доступа друг к другу.
3. Пользователи групп С, Б и ФЭО будут только в офисе на Арбате, ПТО и Д будут в обоих офисах.

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

При проектировании сети следует стараться придерживаться иерархической модели сети , которая имеет много достоинств по сравнению с “плоской сетью”:

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

Согласно этой модели, сеть разбивается на три логических уровня: ядро сети (Core layer: высокопроизводительные устройства, главное назначение - быстрый транспорт), уровень распространения (Distribution layer: обеспечивает применение политик безопасности, QoS, агрегацию и маршрутизацию в VLAN, определяет широковещательные домены), и уровень доступа (Access-layer: как правило, L2 свичи, назначение: подключение конечных устройств, маркирование трафика для QoS, защита от колец в сети (STP) и широковещательных штормов, обеспечение питания для PoE устройств).

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

На представленной схеме ядром (Core) будет маршрутизатор 2811, коммутатор 2960 отнесём к уровню распространения (Distribution), поскольку на нём агрегируются все VLAN в общий транк. Коммутаторы 2950 будут устройствами доступа (Access). К ним будут подключаться конечные пользователи, офисная техника, сервера.

Именовать устройства будем следующим образом: сокращённое название города (msk ) - географическое расположение (улица, здание) (arbat ) - роль устройства в сети + порядковый номер.
Соответственно их ролям и месту расположения выбираем hostname :
Маршрутизатор 2811: msk-arbat-gw1 (gw=GateWay=шлюз)
Коммутатор 2960: msk-arbat-dsw1 (dsw=Distribution switch)
Коммутаторы 2950: msk-arbat-aswN, msk-rubl-asw1 (asw=Access switch)

Документация сети

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

• Схемы сети L1, L2, L3 в соответствии с уровнями модели OSI (Физический, канальный, сетевой)
• План IP-адресации = IP-план
• Список VLAN
• Подписи (description ) интерфейсов
• Список устройств (для каждого следует указать: модель железки, установленная версия IOS, объем RAM\NVRAM, список интерфейсов)
• Метки на кабелях (откуда и куда идёт), в том числе на кабелях питания и заземления и устройствах
• Единый регламент, определяющий все вышеприведённые параметры и другие

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

Говоря о метках/наклейках на кабели, мы имеем ввиду это:

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

Подготовим нужные нам документы:

Список VLAN

Каждая группа будет выделена в отдельный влан. Таким образом мы ограничим широковещательные домены. Также введём специальный VLAN для управления устройствами.
Номера VLAN c 4 по 100 зарезервированы для будущих нужд.

IP-план

IP-адрес	Примечание	VLAN
172.16.0.0/16
172.16.0.0/24	Серверная ферма	3
172.16.0.1	Шлюз
172.16.0.2	Web
172.16.0.3	File
172.16.0.4	Mail
172.16.0.5 - 172.16.0.254	Зарезервировано
172.16.1.0/24	Управление	2
172.16.1.1	Шлюз
172.16.1.2	msk-arbat-dsw1
172.16.1.3	msk-arbat-asw1
172.16.1.4	msk-arbat-asw2
172.16.1.5	msk-arbat-asw3
172.16.1.6	msk-rubl-aswl
172.16.1.6 - 172.16.1.254	Зарезервировано
172.16.2.0/24	Сеть Point-to-Point
172.16.2.1	Шлюз
172.16.2.2 - 172.16.2.254	Зарезервировано
172.16.3.0/24	ПТО	101
172.16.3.1	Шлюз
172.16.3.2 - 172.16.3.254	Пул для пользователей
172.16.4.0/24	ФЭО	102
172.16.4.1	Шлюз
172.16.4.2 - 172.16.4.254	Пул для пользователей
172.16.5.0/24	Бухгалтерия	103
172.16.5.1	Шлюз
172.16.5.2 - 172.16.5.254	Пул для пользователей
172.16.6.0/24	Другие пользователи	104
172.16.6.1	Шлюз
172.16.6.2 - 172.16.6.254	Пул для пользователей

Выделение подсетей в общем-то произвольное, соответствующее только числу узлов в этой локальной сети с учётом возможного роста. В данном примере все подсети имеют стандартную маску /24 (/24=255.255.255.0) - зачастую такие и используются в локальных сетях, но далеко не всегда. Советуем почитать о классах сетей . В дальнейшем мы обратимся и к бесклассовой адресации (cisco). Мы понимаем, что ссылки на технические статьи в википедии - это моветон, однако они дают хорошее определение, а мы попробуем в свою очередь перенести это на картину реального мира.
Под сетью Point-to-Point подразумеваем подключение одного маршрутизатора к другому в режиме точка-точка. Обычно берутся адреса с маской 30 (возвращаясь к теме бесклассовых сетей), то есть содержащие два адреса узла. Позже станет понятно, о чём идёт речь.

План подключения оборудования по портам

Разумеется, сейчас есть коммутаторы с кучей портов 1Gb Ethernet, есть коммутаторы с 10G, на продвинутых операторских железках, стоящих немалые тысячи долларов есть 40Gb, в разработке находится 100Gb (а по слухам уже даже есть такие платы, вышедшие в промышленное производство). Соответственно, вы можете выбирать в реальном мире коммутаторы и маршрутизаторы согласно вашим потребностям, не забывая про бюджет. В частности гигабитный свич сейчас можно купить незадорого (20-30 тысяч) и это с запасом на будущее (если вы не провайдер, конечно). Маршрутизатор с гигабитными портами стоит уже ощутимо дороже, чем со 100Mbps портами, однако оно того стоит, потому что FE-модели (100Mbps FastEthernet), устарели и их пропускная способность очень невысока.
Но в программах эмуляторах/симуляторах, которые мы будем использовать, к сожалению, есть только простенькие модели оборудования, поэтому при моделировании сети будем отталкиваться от того, что имеем: маршрутизатор cisco2811, коммутаторы cisco2960 и 2950.

Имя устройства	Порт	Название	VLAN
Access	Trunk
msk-arbat-gw1	FE0/1	UpLink
	FE0/0	msk-arbat-dsw1		2,3,101,102,103,104
msk-arbat-dsw1	FE0/24	msk-arbat-gw1		2,3,101,102,103,104
	GE1/1	msk-arbat-asw1		2,3
	GE1/2	msk-arbat-asw3		2,101,102,103,104
	FE0/1	msk-rubl-asw1	2,101,104
msk-arbat-asw1	GE1/1	msk-arbat-dsw1		2,3
	GE1/2	msk-arbat-asw2		2,3
	FE0/1	Web-server	3
	FE0/2	File-server	3
msk-arbat-asw2	GE1/1	msk-arbat-asw1		2,3
	FE0/1	Mail-Server	3
msk-arbat-asw3	GE1/1	msk-arbat-dsw1		2,101,102,103,104
	FE0/1-FE0/5	PTO	101
	FE0/6-FE0/10	FEO	102
	FE0/11-FE0/15	Accounting	103
	FE0/16-FE0/24	Other	104
msk-rubl-asw1	FE0/24	msk-arbat-dsw1	2,101,104
	FE0/1-FE0/15	PTO	101
	FE0/20	administrator	104

Почему именно так распределены VLAN"ы, мы объясним в следующих частях.

Схемы сети

На основании этих данных можно составить все три схемы сети на этом этапе. Для этого можно воспользоваться Microsoft Visio, каким-либо бесплатным приложением, но с привязкой к своему формату, или редакторами графики (можно и от руки, но это будет сложно держать в актуальном состоянии:)).

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

L1

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

L2

На схеме L2 мы указываем наши VLAN’ы

L3

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

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

К этой первой статье мы не раз ещё вернёмся в будущем, равно как и вам придётся всегда возвращаться к тому, что вы изначально напланировали.
Собственно задание для тех, кто пока только начинает учиться и готов приложить для этого усилия: много читать про вланы, ip-адресацию, найти программы Packet Tracer и GNS3.
Что касается фундаментальных теоретических знаний, то советуем начать читать Cisco press. Это то, что вам совершенно точно понадобится знать.
В следующей части всё будет уже по-взрослому, с видео, мы будем учиться подключаться к оборудованию, разбираться с интерфейсом и расскажем, что делать нерадивому админу, забывшему пароль.
P.S. Спасибо соавтору статьи - Максиму aka gluck.
P.P.S Тем, кто имеет, что спросить, но не имеет возможности свой вопрос здесь задать, милости просим в

Наш умозрительный провайдер linkmeup взрослеет и обрастает по-тихоньку всеми услугами обычных операторов связи. Теперь мы доросли до IPTV.
Отсюда вытекает необходимость настройки мультикастовой маршрутизации и в первую очередь понимание того, что вообще такое мультикаст.
Это первое отклонение от привычных нам принципов работы IP-сетей. Всё-таки парадигма многоадресной рассылки в корне отличается от тёплого лампового юникаста.
Можно даже сказать, это в некоторой степени бросает вызов гибкости вашего разума в понимании новых подходов.

В этой статье сосредоточимся на следующем:

Традиционный видеоурок:

На заре моего становления, как инженера, тема мультикаста меня неимоверно пугала, и я связываю это с психотравмой моего первого опыта с ним.
«Так, Марат, срочно, до полудня нужно пробросить видеопоток до нашего нового здания в центре города — провайдер отдаст его нам тут на втором этаже » — услышал я одним чудесным утром. Всё, что я тогда знал о мультикасте, так это то, что отправитель один, получателей много, ну и, кажется, протокол IGMP там как-то задействован.

В итоге до полудня мы пытались всё это дело запустить — я пробросил самый обычный VLAN от точки входа до точки выхода. Но сигнал был нестабильным — картинка замерзала, разваливалась, прерывалась. Я в панике пытался разобраться, что вообще можно сделать с IGMP, тыркался, тыркался, включал мультикаст роутинг, IGMP-snooping, проверял по тысяче раз задержки и потери — ничего не помогало. А потом вдруг всё заработало. Само собой, стабильно, безотказно.

Это послужило мне прививкой против мультикаста, и долгое время я не проявлял к нему никакого интереса.

Уже гораздо позже я пришёл в к следующему правилу:

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

Сохраняйте спокойствие и доверьтесь мне. После этой статьи такие вещи вас пугать не будут.

Общее понимание Multicast

Как известно, существуют следующие типы трафика:
Unicast — одноадресная рассылка — один отправитель, один получатель. (Пример: запрос HTTP-странички у WEB-сервера ).
Broadcast — широковещательная рассылка — один отправитель, получатели — все устройства в широковещательном сегменте. (Пример: ARP-запрос ).
— многоадресная рассылка — один отправитель, много получателей. (Пример: IPTV ).
Anycast — одноадресная рассылка ближайшему узлу — один отправитель, вообще получателей много, но фактически данные отправляются только одному. (Пример: Anycast DNS ).

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

Первое, что приходит на ум, — это телевидение (IPTV) — один сервер-источник отправляет трафик, который хочет получать сразу много клиентов. Это и определяет сам термин — — многоадресное вещание. То есть, если уже известный вам Broadcast означает вещание всем, мультикаст означает вещание определённой группе.

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

Возможные сценарии: аудио и видеоконференции (один говорит — все слушают), электронная коммерция, аукционы, биржи. Но это в теории, а на практике редко тут всё-таки используется мультикаст.

Ещё одно применение — это служебные сообщения протоколов. Например, OSPF в своём широковещательном домене рассылает свои сообщения на адреса 224.0.0.5 и 224.0.0.6. И обрабатывать их будут только те узлы, на которых запущен OSPF.

Сформулируем два основных принципа мультикастовой рассылки:

1. Отправитель посылает только одну копию трафика, независимо от количества получателей.
2. Трафик получают только те, кто действительно заинтересован в нём.

В данной статье для практики мы возьмём IPTV, как наиболее наглядный пример.

Пример I

Начнём с самого простого случая:

На сервере-источнике настроено вещание в группу 224.2.2.4 — это означает, что сервер отправляет трафик на IP-адрес 224.2.2.4. На клиенте видеоплеер настроен принимать поток группы 224.2.2.4.

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

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

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

Мультикаст не привязан к какому-то конкретному протоколу. По сути, всё, что его определяет — адреса. Однако, если говорить о его применении, то в абсолютном большинстве случаев используется именно UDP. Это легко объясняется тем, что обычно с помощью многоадресной рассылки передаются данные, которые нужны здесь и сейчас. Например, видео. Если кусочек кадра потеряется, и отправитель будет пытаться его послать повторно, как это происходит в TCP, то, скорее всего, этот кусочек опоздает, и где его тогда показывать? Поезд ушёл. Ровно то же самое со звуком.
Соответственно не нужно и устанавливать соединение, поэтому TCP здесь ни к чему.

Чем же так разительно отличается мультикаст от юникаста? Думаю, у вас есть уже предположение. И вы, наверняка, правы.

В обычной ситуации у нас 1 получатель и 1 отправитель — у каждого из них один уникальный IP-адрес. Отправитель точно знает, куда надо слать пакет и ставит этот адрес в заголовок IP. Каждый промежуточный узел благодаря своей таблице маршрутизации точно знает, куда переслать пакет. Юникастовый трафик между двумя узлами беспрепятственно проходит сквозь сеть. Но проблема в том, что в обычном пакете указывается только один IP-адрес получателя.
Что делать, если у одного и того же трафика несколько получателей? В принципе можно расширить одноадресный подход и на такую ситуацию — отправлять каждому клиенту свой экземпляр пакета. Клиенты не заметят разницы — хоть он один, хоть их тысяча, но разница будет отчётливо различима на ваших каналах передачи данных.


Предположим у нас идёт передача одного SD-канала с мультикаст-сервера. Пусть, он использует 2 Мб/с. Всего таких каналов 30, а смотрит каждый канал по 20 человек одновременно. Итого получается 2 Мб/с * 30 каналов * 20 человек = 1200 Мб/с или 1,2 Гб/с только на телевидение в случае одноадресной рассылки. А есть ведь ещё HD каналы, где можно смело умножать эту цифру на 2. И где тут место для торрентов?

Вот почему в IPv4 был заложен блок адресов класса D: 224.0.0.0/4 (224.0.0.0-239.255.255.255). Адреса этого диапазона определяют мультикастовую группу. Один адрес — это одна группа, обычно она обозначается буквой «G ».
То есть, говоря, что клиент подключен к группе 224.2.2.4, мы имеем ввиду, что он получает мультикастовый трафик с адресом назначения 224.2.2.4.

Пример II

Добавим в схему коммутатор и ещё несколько клиентов:

Мультикастовый сервер по-прежнему вещает для группы 224.2.2.4. На коммутаторе все 4 порта должны быть в одном VLAN. Трафик приходит на коммутатор и по умолчанию рассылается во все порты одного VLAN"а. Значит все клиенты получают этот трафик. На них на всех в видеопроигрывателе так же указан групповой адрес 224.2.2.4.
Собственно, все эти устройства становятся членами данной мультикастовой группы. Членство в ней динамическое: кто угодно, в любой момент может войти и выйти из неё.

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

Обратите внимание, что в данном случае от сервера-источника приходит только одна копия трафика на коммутатор, а не по отдельной копии на каждого клиента. И в нашем примере с SD каналами загрузка порта между источником и коммутатором будет не 1,2 Гб/с, а всего 60 Мб/с (2Мб/с * 30 каналов).

Собственно говоря, весь этот огромный диапазон (224.0.0.0-239.255.255.255) можно использовать.
Ну, почти весь — первые адреса (диапазон 224.0.0.0/23) всё-таки зарезервированы под известные протоколы.

Список зарезервированных IP-адресов

Адрес	Значение
224.0.0.0	Не используется
224.0.0.1	Все узлы данного сегмента
224.0.0.2	Все мультикастовые узлы данного сегмента
224.0.0.4	Данный адрес выделялся для покойного протокола DVMRP
224.0.0.5	Все OSPF-маршрутизаторы сегмента
224.0.0.6	Все DR маршрутизаторы сегмента
224.0.0.9	Все RIPv2-маршрутизаторы сегмента
224.0.0.10	Все EIGRP-маршрутизаторы сегмента
224.0.0.13	Все PIM-маршрутизаторы сегмента
224.0.0.18	Все VRRP-маршрутизаторы сегмента
224.0.0.19-21	Все IS-IS-маршрутизаторы сегмента
224.0.0.22	Все IGMP-маршрутизаторы сегмента (v2 и v3)
224.0.0.102	Все HSRPv2/GLBP-маршрутизаторы сегмента
224.0.0.107	PTPv2 — Precision Time Protocol
224.0.0.251	mDNS
224.0.0.252	LLMNR
224.0.0.253	Teredo
224.0.1.1	NTP
224.0.1.39	Cisco Auto-RP-Announce
224.0.1.40	Cisco Auto-RP-Discovery
224.0.1.41	H.323 Gatekeeper
224.0.1.129-132	PTPv1/PTPv2
239.255.255.250	SSDP

Диапазон 224.0.0.0/24 зарезервирован под link-local коммуникации. Мультикастовые пакеты с такими адресами назначения не могут выходить за пределы одного широковещательного сегмента.
Диапазон 224.0.1.0/24 зарезервирован под протоколы, которым необходимо передавать мультикаст по всей сети, то есть проходить через маршрутизаторы.

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

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

Вообще, чтобы доставить мультикаст от источника до получателя на данный момент существует много протоколов — IGMP/MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
Мы остановимся на двух из них, которые используются в настоящее время: PIM и IGMP.
С помощью IGMP конечные получатели-клиенты сообщают ближайшим маршрутизаторам о том, что хотят получать трафик. А PIM строит путь движения мультикастового трафика от источника до получателей через маршрутизаторы.

IGMP

Снова вернёмся к дампу. Видите вот этот верхний пакет, после которого полился мультикастовый поток?

Это сообщение протокола IGMP, которое отправил клиент, когда мы на нём нажали Play. Именно так он сообщает о том, что хочет получать трафик для группы 224.2.2.4.
IGMP — Internet Group Management Protocol — это сетевой протокол взаимодействия клиентов мультикастового трафика и ближайшего к ним маршрутизатора.

В IPv6 используется MLD (Multicast Listener Discovery) вместо IGMP. Принцип работы у них абсолютно одинаковый, поэтому далее везде вы смело можете менять IGMP на MLD, а IP на IPv6.

Как же именно работает IGMP?
Пожалуй, начать нужно с того, что версий у протокола сейчас три: IGMPv1, IGMPv2, IGMPv3. Наиболее используемая — вторая, первая уже практически забыта, поэтому про неё говорить не будем, третья очень похожа на вторую.

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

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

Для того, чтобы понять, как всё происходит, возьмём такую сеть:

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

1. Как только мы запустили приложение на клиенте и задали группу 224.2.2.4, в сеть будет отправлен пакет — узел «рапортует» о том, что хочет получать трафик этой группы.

В IGMPv2 Report отправляется на адрес желаемой группы, и параллельно он же указывается в самом пакете. Данные сообщения должны жить только в пределах своего сегмента и не пересылаться никуда маршрутизаторами, поэтому и TTL у них 1.

Часто в литературе вы можете встретить упоминание о IGMP Join . Не пугайтесь — это альтернативное название для IGMP Membership Report.

2. Маршрутизатор получает IGMP-Report и, понимая, что за данным интерфейсом теперь есть клиенты, заносит информацию в свои таблицы

Это вывод информации по IGMP. Первая группа запрошена клиентом. Третья и четвёртая — это служебные группы протокола SSDP , встроенного в Windows. Вторая — специальная группа, которая всегда присутствует на маршрутизаторах Cisco — она используется для протокола Auto-RP , который по умолчанию активирован на маршрутизаторах.
Интерфейс FE0/0 становится нисходящим для трафика группы 224.2.2.4 — в него нужно будет отправлять полученный трафик.

Наряду с обычной юникастовой таблицей маршрутизации существует ещё и мультикастовая:

О наличии клиентов говорит первая запись (*, 224.2.2.4) . А запись (172.16.0.5, 224.2.2.4) означает, что маршрутизатор знает об источнике мультикастового потока для этой группы.
Из вывода видно, что трафик для группы 224.2.2.4 приходит через FE0/1, а передавать его надо на порт FE0/0.
Интерфейсы, в которые нужно передавать трафик, входят в список нисходящих интерфейсов — OIL — Outbound Interface List .
Более подробно вывод команды мы разберём позже.

Выше на дампе вы видите, что как только клиент отправил IGMP-Report, сразу после него полетели UDP — это видеопоток.

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

*Дамп отфильтрован по IGMP* .

По умолчанию это происходит каждые 60 секунд. TTL таких пакетов тоже равен 1. Они отправляются на адрес 224.0.0.1 — все узлы в этом сегменте — без указания конкретной группы. Такие сообщений Query называются General Query — общие. Таким образом маршрутизатор спрашивает: «Ребят, а кто и что ещё хочет получать?».

Получив IGMP General Query, любой хост, который слушает любую группу, должен отправить IGMP Report, как он это делал при подключении. В Report, естественно, должен быть указан адрес интересующей его группы.

*Дамп отфильтрован по IGMP* .

Если в ответ на Query на маршрутизатор пришёл хотя бы один Report для группы, значит есть ещё клиенты, он продолжает вещать в тот интерфейс, откуда пришёл этот Report, трафик этой самой группы.
Если на 3 подряд Query не было с интерфейса ответа для какой-то группы, маршрутизатор удаляет этот интерфейс из своей таблицы мультикастовой маршрутизации для данной группы — перестаёт туда посылать трафик.

По своей инициативе клиент обычно посылает Report только при подключении, потом — просто отвечает на Query от маршрутизатора.

Интересная деталь в поведении клиента: получив Query, он не торопится сразу же ответить Report"ом. Узел берёт тайм-аут длиной от 0 до , который указан в пришедшем Query:

При отладке или в дампе, кстати, можно видеть, что между получением различных Report может пройти несколько секунд.
Сделано это для того, чтобы сотни клиентов все скопом не наводнили сеть своими пакетам Report, получив General Query. Более того, только один клиент обычно отправляет Report.
Дело в том, что Report отсылается на адрес группы, а следовательно доходит и до всех клиентов. Получив Report от другого клиента для этой же группы, узел не будет отправлять свой. Логика простая: маршрутизатор и так уже получил этот самый Report и знает, что клиенты есть, больше ему не надо.
Этот механизм называется Report Suppression .

4. Так продолжается веками, пока клиент не захочет выйти из группы (например, выключит плеер/телевизор). В этом случае он отправляет на адрес группы.

Маршрутизатор получает его и по идее должен отключить. Но он ведь не может отключить одного конкретного клиента — маршрутизатор их не различает — у него просто есть нисходящий интерфейс. А за интерфейсом может быть несколько клиентов. То есть, если маршрутизатор удалит этот интерфейс из своего списка OIL (Outgoing Interface List) для этой группы, видео выключится у всех.
Но и не удалять его совсем тоже нельзя — вдруг это был последний клиент — зачем тогда впустую вещать?

Если вы посмотрите в дамп, то увидите, что после получения Leave маршрутизатор ещё некоторое время продолжает слать поток. Дело в том, что маршрутизатор в ответ на Leave высылает IGMP Query на адрес группы, для которой этот Leave пришёл в тот интерфейс, откуда он пришёл. Такой пакет называется Group Specific Query . На него отвечают только те клиенты, которые подключены к данной конкретной группе.

Если маршрутизатор получил ответный Report для группы, он продолжает вещать в интерфейс, если не получил — удаляет по истечении таймера.

Всего после получения Leave отправляется два Group Specific Query — один обязательный, второй контрольный.

*Дамп отфильтрован по IGMP* .

Querier

Рассмотрим чуть более сложный случай:

В клиентский сегмент подключено два (или больше) маршрутизатора, которые могут вещать трафик. Если ничего не сделать, мультикастовый трафик будет дублироваться — оба маршрутизатора ведь будут получать Report от клиентов. Во избежание этого существует механизм выбора Querier — опрашивателя. Тот кто победит, будет посылать Query, мониторить Report и реагировать на Leave, ну и, соответственно, он будет отправлять и трафик в сегмент. Проигравший же будет только слушать Report и держать руку на пульсе.

Выборы происходят довольно просто и интуитивно понятно.
Рассмотрим ситуацию с момента включения маршрутизаторов R1 и R2.
1) Активировали IGMP на интерфейсах.
2) Сначала по умолчанию каждый из них считает себя Querier.
3) Каждый отправляет IGMP General Query в сеть. Главная цель — узнать, есть ли клиенты, а параллельно — заявить другим маршрутизаторам в сегменте, если они есть, о своём желании участвовать в выборах.
4) General Query получают все устройства в сегменте, в том числе и другие IGMP-маршрутизаторы.
5) Получив такое сообщение от соседа, каждый маршрутизатор оценивает, кто достойнее.
6) Побеждает маршрутизатор с меньшим IP (указан в поле Source IP пакета IGMP Query). Он становится Querier, все другие — Non-Querier.
7) Non-Querier запускает таймер, который обнуляется каждый раз, как приходит Query с меньшим IP-адресом. Если до истечения таймера (больше 100 секунд: 105-107) маршрутизатор не получит Query с меньшим адресом, он объявляет себя Querier и берёт на себя все соответствующие функции.
8) Если Querier получает Query с меньшим адресом, он складывает с себя эти обязанности. Querier"ом становится другой маршрутизатор, у которого IP меньше.

Тот редкий случай, когда меряются, у кого меньше.

Выборы Querier очень важная процедура в мультикасте, но некоторые коварные производители, не придерживающиеся RFC, могут вставить крепкую палку в колёса. Я сейчас говорю о IGMP Query с адресом источника 0.0.0.0, которые могут генерироваться коммутатором. Такие сообщения не должны участвовать в выборе Querier, но надо быть готовыми ко всему. Вот пример весьма сложной долгоиграющей проблемы.

Ещё пара слов о других версиях IGMP

Версия 1 отличается по сути только тем, что в ней нет сообщения Leave . Если клиент не хочет больше получать трафик данной группы, он просто перестаёт посылать Report в ответ на Query. Когда не останется ни одного клиента, маршрутизатор по таймауту перестанет слать трафик.
Кроме того, не поддерживаются выборы Querier . За избежание дублирования трафика отвечает вышестоящий протокол, например, PIM, о котором мы будем говорить .

Версия 3 поддерживает всё то, что поддерживает IGMPv2, но есть и ряд изменений. Во-первых, Report отправляется уже не на адрес группы, а на мультикастовый служебный адрес 224.0.0.22 . А адрес запрашиваемой группы указан только внутри пакета. Делается это для упрощения работы IGMP Snooping, о котором мы поговорим .

Во-вторых, что более важно, IGMPv3 стал поддерживать SSM в чистом виде. Это так называемый . В этом случае клиент может не просто запросить группу, но также указать список источников, от которых он хотел бы получать трафик или наоборот не хотел бы. В IGMPv2 клиент просто запрашивает и получает трафик группы, не заботясь об источнике.

Итак, IGMP предназначен для взаимодействия клиентов и маршрутизатора. Поэтому, возвращаясь к Примеру II , где нет маршрутизатора, мы можем авторитетно заявить — IGMP там — не более, чем формальность. Маршрутизатора нет, и клиенту не у кого запрашивать мультикастовый поток. А заработает видео по той простой причине, что поток и так льётся от коммутатора — надо только подхватить его.

Напомним, что IGMP не работает для IPv6. Там существует протокол MLD .

Повторим ещё раз

*Дамп отфильтрован по IGMP* .


1. Первым делом маршрутизатор отправил свой IGMP General Query после включения IGMP на его интерфейсе, чтобы узнать, есть ли получатели и заявить о своём желании быть Querier. На тот момент никого не было в этой группе.
2. Далее появился клиент, который захотел получать трафик группы 224.2.2.4 и он отправил свой IGMP Report. После этого пошёл трафик на него, но он отфильтрован из дампа.
3. Потом маршрутизатор решил зачем-то проверить — а нет ли ещё клиентов и отправил IGMP General Query ещё раз, на который клиент вынужден ответить (4 ).
5. Периодически (раз в минуту) маршрутизатор проверяет, что получатели по-прежнему есть, с помощью IGMP General Query, а узел подтверждает это с помощью IGMP Report.
6. Потом он передумал и отказался от группы, отправив IGMP Leave.
7. Маршрутизатор получил Leave и, желая убедиться, что больше никаких других получателей нет, посылает IGMP Group Specific Query… дважды. И по истечении таймера перестаёт передавать трафик сюда.
8. Однако передавать IGMP Query в сеть он по-прежнему продолжает. Например, на тот случай, если вы плеер не отключали, а просто где-то со связью проблемы. Потом связь восстанавливается, но клиент-то Report не посылает сам по себе. А вот на Query отвечает. Таким образом поток может восстановиться без участия человека.

И ещё раз

IGMP — протокол, с помощью которого маршрутизатор узнаёт о наличии получателей мультикастового трафика и об их отключении.
— посылается клиентом при подключении и в ответ на IGMP Query. Означает, что клиент хочет получать трафик конкретной группы.
— посылается маршрутизатором периодически, чтобы проверить какие группы сейчас нужны. В качестве адреса получателя указывается 224.0.0.1.
IGMP Group Sepcific Query — посылается маршрутизатором в ответ на сообщение Leave, чтобы узнать есть ли другие получатели в этой группе. В качестве адреса получателя указывается адрес мультикастовой группы.
— посылается клиентом, когда тот хочет покинуть группу.
Querier — если в одном широковещательном сегменте несколько маршрутизаторов, который могут вещать, среди них выбирается один главный — Querier. Он и будет периодически рассылать Query и передавать трафик.

Подробное описание всех терминов IGMP .

PIM

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

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

Существует несколько протоколов маршрутизации мультикастового трафика: DVMRP , MOSPF , CBT — все они по-разному решают такую задачу. Но стандартом де факто стал PIM — Protocol Independent Multicast .
Другие подходы настолько нежизнеспособны, что порой даже их разработчики практически признают это. Вот, например, выдержка из RFC по протоколу CBT:
CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.

PIM имеет две версии, которые можно даже назвать двумя различными протоколами в принципе, уж сильно они разные:

• PIM Dense Mode (DM)
• PIM Sparse Mode (SM)

Independent он потому, что не привязан к какому-то конкретному протоколу маршрутизации юникастового трафика, и позже вы увидите почему.

PIM Dense Mode

пытается решить проблему доставки мультиакста в лоб. Он заведомо предполагает, что получатели есть везде, во всех уголках сети. Поэтому изначально он наводняет всю сеть мультикастовым трафиком, то есть рассылает его во все порты, кроме того, откуда он пришёл. Если потом оказывается, что где-то он не нужен, то эта ветка «отрезается» с помощью специального сообщения PIM Prune — трафик туда больше не отправляется.

Но через некоторое время в эту же ветку маршрутизатор снова пытается отправить мультикаст — вдруг там появились получатели. Если не появились, ветка снова отрезается на определённый период. Если клиент на маршрутизаторе появился в промежутке между этими двумя событиями, отправляется сообщение Graft — маршрутизатор запрашивает отрезанную ветку обратно, чтобы не ждать, пока ему что-то перепадёт.
Как видите, здесь не стоит вопрос определения пути к получателям — трафик достигнет их просто потому, что он везде.
После «обрезания» ненужных ветвей остаётся дерево, вдоль которого передаётся мультикастовый трафик. Это дерево называется SPT — Shortest Path Tree .

Оно лишено петель и использует кратчайший путь от получателя до источника. По сути оно очень похоже на Spanning Tree в STP , где корнем является источник.

SPT — это конкретный вид дерева — дерево кратчайшего пути. А вообще любое мультикастовое дерево называется .

Предполагается, что PIM DM должен использоваться в сетях с высокой плотностью мультикастовых клиентов, что и объясняет его название (Dense). Но реальность такова, что эта ситуация — скорее, исключение, и зачастую PIM DM нецелесообразен.

Что нам действительно важно сейчас — это механизм избежания петель.
Представим такую сеть:

Один источник, один получатель и простейшая IP-сеть между ними. На всех маршрутизаторах запущен PIM DM.

Что произошло бы, если бы не было специального механизма избежания петель?
Источник отправляет мультикастовый трафик. R1 его получает и в соответствии с принципами PIM DM отправляет во все интерфейсы, кроме того, откуда он пришёл — то есть на R2 и R3.

R2 поступает точно так же, то есть отправляет трафик в сторону R3. R3 не может определить, что это тот же самый трафик, который он уже получил от R1, поэтому пересылает его во все свои интерфейсы. R1 получит копию трафика от R3 и так далее. Вот она — петля.

Что же предлагает PIM в такой ситуации? RPF — Reverse Path Forwarding . Это главный принцип передачи мультикастового трафика в PIM (любого вида: и DM и SM) — трафик от источника должен приходить по кратчайшему пути.
То есть для каждого полученного мультикастового пакета производится проверка на основе таблицы маршрутизации, оттуда ли он пришёл.

1) Маршрутизатор смотрит на адрес источника мультикастового пакета.
2) Проверяет таблицу маршрутизации, через какой интерфейс доступен адрес источника.
3) Проверяет интерфейс, через который пришёл мультикастовый пакет.
4) Если интерфейсы совпадают — всё отлично, мультикастовый пакет пропускается, если же данные приходят с другого интерфейса — они будут отброшены.
В нашем примере R3 знает, что кратчайший путь до источника лежит через R1 (статический или динамический маршрут). Поэтому мультикастовые пакеты, пришедшие от R1, проходят проверку и принимаются R3, а те, что пришли от R2, отбрасываются.

Такая проверка называется RPF-Check и благодаря ей даже в более сложных сетях петли в MDT не возникнут.
Этот механизм важен нам, потому что он актуален и в PIM-SM и работает там точно также.
Как видите, PIM опирается на таблицу юникастовой маршрутизации, но, во-первых, сам не маршрутизирует трафик, во-вторых, ему не важно, кто и как наполнял таблицу.

Останавливаться здесь и подробно рассматривать работу PIM DM мы не будем — это устаревший протокол с массой недостатков (ну, как RIP).

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

PIM Sparse Mode

Совершенно другой подход применяет PIM SM . Несмотря на название (разреженный режим), он с успехом может применяться в любой сети с эффективностью как минимум не хуже, чем у PIM DM.
Здесь отказались от идеи безусловного наводнения мультикастом сети. Заинтересованные узлы самостоятельно запрашивают подключение к дереву с помощью сообщений PIM Join .
Если маршрутизатор не посылал Join, то и трафик ему отправляться не будет.

Для того, чтобы понять, как работает PIM, начнём с уже знакомой нам простой сети с одним PIM-маршрутизатором:


Из настроек на R1 надо включить возможность маршрутизации мультикаста, PIM SM на двух интерфейсах (в сторону источника и в сторону клиента) и IGMP в сторону клиента. Помимо прочих базовых настроек, конечно (IP, IGP).

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

R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim sparse-mode

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

Плюс, возможно, потребуется настроить адрес RP (ip pim rp-address 172.16.0.1 , например). Об этом позже, пока примите как данность и смиритесь.

Проверим текущее состояние таблицы мультикастовой маршрутизации для группы 224.2.2.4:

После того, как на источнике вы запустите вещание, надо проверить таблицу ещё раз.

Давайте разберём этот немногословный вывод.

Запись вида (*, 225.0.1.1) называется , /читается старкомаджи / и сообщает нам о получателях. Причём не обязательно речь об одном клиенте-компьютере, вообще это может быть и, например, другой PIM-маршрутизатор. Важно то, в какие интерфейсы надо передавать трафик.
Если список нисходящих интерфейсов (OIL) пуст — Null , значит нет получателей — а мы их пока не запускали.

Запись (172.16.0.5, 225.0.1.1) называется , /читается эскомаджи / и говорит о том, что известен источник. В нашем случае источник с адресом 172.16.0.5 вещает трафик для группы 224.2.2.4. Мультикастовый трафик приходит на интерфейс FE0/1 — это восходящий (Upstream ) интерфейс.

Итак, нет клиентов. Трафик от источника доходит до маршрутизатора и на этом его жизнь кончается. Давайте добавим теперь получателя — настроим приём мультикаста на ПК.
ПК отсылает IGMP Report, маршрутизатор понимает, что появились клиенты и обновляет таблицу мультикастовой маршрутизации.
Теперь она выглядит так:

Появился и нисходящий интерфейс: FE0/0, что вполне ожидаемо. Причём он появился как в (*, G), так и в (S, G). Список нисходящих интерфейсов называется OIL — Outgoing Interface List .

Добавим ещё одного клиента на интерфейс FE1/0:

(S, G): Когда мультикастовый трафик с адресом назначения 224.2.2.4 от источника 172.16.0.5 приходит на интерфейс FE0/1, его копии нужно отправить в FE0/0 и FE1/0.

Но это был очень простой пример — один маршрутизатор сразу знает и адрес источника и где находятся получатели. Фактически даже деревьев тут никаких нет — разве что вырожденное. Но это помогло нам разобраться с тем, как взаимодействуют PIM и IGMP.

Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной

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

Но пока не запущен PIM, IGMP, клиенты не запрашивают каналы.

Итак, момент времени 0.

Включаем мультикастовую маршрутизацию на всех пяти маршрутизаторах:

RX(config)#ip multicast-routing
PIM включается непосредственно на всех интерфейсах всех маршрутизаторов (в том числе на интерфейсе в сторону Сервера-источника и клиентов):

RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode

IGMP, по идее должен включаться на интерфейсах в сторону клиентов, но, как мы уже отметили выше, на оборудовании Cisco он включается автоматически вместе с PIM.

Первое, что делает PIM — устанавливает соседство. Для этого используются сообщения . При активации PIM на интерфейсе с него отправляется PIM Hello на адрес 224.0.0.13 с TTL равным 1. Это означает, что соседями могут быть только маршрутизаторы, находящиеся в одном широковещательном домене.

Как только соседи получили приветствия друг от друга:

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

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

Неплохо было бы если бы информация об источнике и о клиентах группы была собрана где-то в одном месте. Но в каком?

Такая точка встречи называется Rendezvous Point — RP . Это центральное понятие PIM SM. Без неё ничего бы не работало. Здесь встречаются источник и получатели.
Все PIM-маршрутизаторы должны знать, кто является RP в домене, то есть знать её IP-адрес.

Чтобы построить дерево MDT, в сети выбирается в качестве RP некая центральная точка, которая,

1. отвечает за изучение источника,
2. является точкой притяжения сообщений Join от всех заинтересованных.

Существует два способа задания RP: статический и динамический. Мы рассмотрим оба в этой статье, но начнём со статического, поскольку чего уж проще статики?

Пусть пока R2 будет выполнять роль RP.
Чтобы увеличить надёжность, обычно выбирается адрес Loopback-интерфейса. Поэтому на всех маршрутизаторах выполняется команда:
RX(config)#ip pim rp-address 2.2.2.2
Естественно, этот адрес должен быть доступен по таблице маршрутизации со всех точек.
Ну и поскольку адрес 2.2.2.2 является RP, на интерфейсе Loopback 0 на R2 желательно тоже активировать PIM.

R2(config)#interface Loopback 0 RX(config-if)#ip pim sparse-mode

Сразу после этого R4 узнает об источнике трафика для группы 224.2.2.4:

И даже передаёт трафик:

На интерфейс FE0/1 приходит 362000 б/с, и через интерфейс FE0/0 они передаются.

Всё, что мы сделали:
Включили возможность маршрутизации мультикастового трафика (ip multicast-routing )
Активировали PIM на интерфейсах (ip pim sparse-mode )
Указали адрес RP (ip pim rp-adress X.X.X.X )

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

Разбор полётов

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

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

1) Клиент 1 отправляет IGMP Report для группы 224.2.2.4

2) R4 получает этот запрос, понимает, что есть клиент за интерфейсом FE0/0, добавляет этот интерфейс в OIL и формирует запись (*, G).

Здесь видно восходящий интерфейс FE0/1, но это не значит, что R4 получает трафик для группы 224.2.2.4. Это говорит лишь о том, что единственное место, откуда сейчас он может получать — FE0/1, потому что именно там находится RP. Кстати, здесь же указан и сосед, который прошёл RPF-Check — R2: 10.0.2.24. Ожидаемо.

R4 называется — LHR (Last Hop Router) — последний маршрутизатор на пути мультикастового трафика, если считать от источника. Иными словами — это маршрутизатор, ближайший к получателю. Для Клиента1 — это R4, для Клиента2 — это R5.

3) Поскольку на R4 пока нет мультикастового потока (он его не запрашивал прежде), он формирует сообщение PIM Join и отправляет его в сторону RP (2.2.2.2).

PIM Join отправляется мультикастом на адрес 224.0.0.13. «В сторону RP» означает через интерфейс, который указан в таблице маршрутизации, как outbound для того адреса, который указан внутри пакета. В нашем случае это 2.2.2.2 — адрес RP. Такой Join обозначается ещё как Join (*,G) и говорит: «Не важно, кто источник, мне нужен трафик группы 224.2.2.4».
То есть каждый маршрутизатор на пути должен обработать такой Join и при необходимости отправить новый Join в сторону RP. (Важно понимать, что если на маршрутизаторе уже есть эта группа, он не будет отправлять выше Join — он просто добавит интерфейс, с которого пришёл Join, в OIL и начнёт передавать трафик).
В нашем случае Join ушёл в FE0/1:

4) R2, получив Join, формирует запись (*, G) и добавляет интерфейс FE0/0 в OIL. Но Join отсылать уже некуда — он сам уже RP, а про источник пока ничего не известно.

Таким образом RP узнаёт о том, где находятся клиенты.

Если Клиент 2 тоже захочет получать мультикастовый трафик для той же группы, R5 отправит PIM Join в FE0/1, потому что за ним находится RP, R3, получив его, формирует новый PIM Join и отправляет в FE1/1 — туда, где находится RP.
То есть Join путешествует так узел за узлом, пока не доберётся до RP или до другого маршрутизатора, где уже есть клиенты этой группы.

Итак, R2 — наш RP — сейчас знает о том, что за FE0/0 и FE1/0 у него есть получатели для группы 224.2.2.4.
Причём неважно, сколько их там — по одному за каждым интерфейсом или по сто — поток трафика всё равно будет один на интерфейс.

Если изобразить графически то, что мы получили, то это будет выглядеть так:

Отдалённо напоминает дерево, не так ли? Поэтому оно так и называется — RPT — Rendezvous Point Tree . Это дерево с корнем в RP, а ветви которого простираются до клиентов.
Более общий термин, как мы упоминали выше, — MDT — Multicast Distribution Tree — дерево, вдоль которого распространяется мультикастовый поток. Позже вы увидите разницу между MDT и RPT.

5) Теперь врубаем сервер. Как мы уже выше обсуждали, он не волнуется о PIM, RP, IGMP — он просто вещает. А R1 получает этот поток. Его задача — доставить мультикаст до RP.
В PIM есть специальный тип сообщений — Register . Он нужен для того, чтобы зарегистрировать источник мультикаста на RP.
Итак, R1 получает мультикастовый поток группы 224.2.2.4:

R1 является FHR (First Hop Router) — первый маршрутизатор на пути мультикастового трафика или ближайший к источнику.

Обратите внимание на стек протоколов. Поверх юникастового IP и заголовка PIM идёт изначальный мультикастовый IP, UDP и данные.
Теперь, в отличие от всех других, пока известных нам сообщений PIM, в адресе получателя указан 2.2.2.2, а не мультикастовый адрес.

Такой пакет доставляется до RP по стандартным правилам юникастовой маршрутизации и несёт в себе изначальный мультикастовый пакет, то есть это… это же туннелирование!

На сервере 172.16.0.5 работает приложение, которое может передавать пакеты только на широковещательный адрес 255.255.255.255, с портом получателя UDP 10999.

Этот трафик надо доставить к клиентам 1 и 2:
Клиенту 1 в виде мультикаст трафика с адресом группы 239.9.9.9.
А в сегмент клиента 2, в виде широковещательных пакетов на адрес 255.255.255.255.

Замечание к топологии : в этой задаче только маршрутизаторы R1, R2, R3 находятся под управлением администраторов нашей сети. То есть, конфигурацию изменять можно только на них.

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1 и 239.2.2.2.

Настроить сеть таким образом, чтобы трафик группы 239.1.1.1 не передавался в сегмент между R3 и R5, и во все сегменты ниже R5.
Но при этом, трафик группы 239.2.2.2 должен передаваться без проблем.

— то же, что Source DR, только для получателей мультикастового трафика — LHR (Last Hop Router) .
Пример топологии:

Receiver DR ответственен за отправку на RP PIM Join. В вышеприведённой топологии, если оба маршрутизатора отправят Join, то оба будут получать мультикастовый трафик, но в этом нет необходимости. Только DR отправляет Join. Второй просто мониторит доступность DR.
Поскольку DR отправляет Join, то он же и будет вещать трафик в LAN. Но тут возникает закономерный вопрос — а что, если PIM DR"ом стал один, а IGMP Querier"ом другой? А ситуация-то вполне возможна, ведь для Querier чем меньше IP, тем лучше, а для DR, наоборот.
В этом случае DR"ом выбирается тот маршрутизатор, который уже является Querier и такая проблема не возникает.

Правила выбора Receiver DR точно такие же, как и Source DR.

Проблема двух одновременно передающих маршрутизаторов может возникнуть и в середине сети, где нет ни конечных клиентов, ни источников — только маршрутизаторы.
Очень остро этот вопрос стоял в PIM DM, где это была совершенно рядовая ситуация из-за механизма Flood and Prune.
Но и в PIM SM она не исключена.
Рассмотрим такую сеть:

Здесь три маршрутизатора находятся в одном сегменте сети и, соответственно, являются соседями по PIM. R1 выступает в роли RP.
R4 отправляет PIM Join в сторону RP. Поскольку этот пакет мультикастовый он попадает и на R2 и на R3, и оба они обработав его, добавляют нисходящий интерфейс в OIL.
Тут бы должен сработать механизм выбора DR, но и на R2 и на R3 есть другие клиенты этой группы, и обоим маршрутизаторам так или иначе придётся отправлять PIM Join.
Когда мультикастовый трафик приходит от источника на R2 и R3, в сегмент он передаётся обоими маршрутизаторами и задваивается там. PIM не пытается предотвратить такую ситуацию — тут он действует по факту свершившегося преступления — как только в свой нисходящий интерфейс для определённой группы (из списка OIL) маршрутизатор получает мультикастовый трафик этой самой группы, он понимает: что-то не так — другой отправитель уже есть в этом сегменте.

Тогда маршрутизатор отправляет специальное сообщение .
Такое сообщение помогает выбрать PIM Forwarder — тот маршрутизатор, который вправе вещать в данном сегменте.

Не надо его путать с PIM DR. Во-первых, PIM DR отвечает за отправку сообщений PIM Join и Prune , а PIM Forwarder — за отправку трафика . Второе отличие — PIM DR выбирается всегда и в любых сетях при установлении соседства, А PIM Forwrder только при необходимости — когда получен мультикастовый трафик с интерфейса из списка OIL.

Выбор RP

Выше мы для простоты задавали RP вручную командой ip pim rp-address X.X.X.X .
И вот как выглядела команда :

Но представим совершенно невозможную в современных сетях ситуацию — R2 вышел из строя. Это всё — финиш. Клиент 2 ещё будет работать, поскольку произошёл SPT Switchover, а вот всё новое и всё, что шло через RP сломается, даже если есть альтернативный путь.
Ну и нагрузка на администратора домена. Представьте себе: на 50 маршрутизаторах перебить вручную как минимум одну команду (а для разных групп ведь могут быть разные RP).

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

В данный момент существует один общепризнанный протокол, позволяющий это сделать — . Циска в прежние времена продвигала несколько неуклюжий Auto-RP , но сейчас он почти не используется, хотя циска этого не признаёт, и в мы имеем раздражающий рудимент в виде группы 224.0.1.40.

Надо на самом деле отдать должное протоколу Auto-RP. Он был спасением в прежние времена. Но с появлением открытого и гибкого Bootstrap, он закономерно уступил свои позиции.

Итак, предположим, что в нашей сети мы хотим, чтобы R3 подхватывал функции RP в случае выхода из строя R2.
R2 и R3 определяются как кандидаты на роль RP — так они и называются C-RP . На этих маршрутизаторах настраиваем:
RX(config)interface Loopback 0 RX(config-if)ip pim sparse-mode RX(config-if)exit RX(config)#ip pim rp-candidate loopback 0

Но пока ничего не происходит — кандидаты пока не знают, как уведомить всех о себе.

Чтобы информировать все мультикастовые маршрутизаторы домена о существующих RP вводится механизм BSR — BootStrap Router . Претендентов может быть несколько, как и C-RP. Они называются соответственно C-BSR . Настраиваются они похожим образом.

Пусть BSR у нас будет один и для теста (исключительно) это будет R1.
R1(config)interface Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0
Сначала из всех C-BSR выбирается один главный BSR, который и будет всем заправлять. Для этого каждый C-BSR отправляет в сеть мультикастовый BootStrap Message (BSM) на адрес 224.0.0.13 — это тоже пакет протокола PIM. Его должны принять и обработать все мультикастовые маршрутизаторы и после разослать во все порты, где активирован PIM. BSM передаётся не в сторону чего-то (RP или источника), в отличии, от PIM Join, а во все стороны. Такая веерная рассылка помогает достигнуть BSM всех уголков сети, в том числе всех C-BSR и всех C-RP. Для того, чтобы BSM не блуждали по сети бесконечно, применяется всё тот же механизм RPF — если BSM пришёл не с того интерфейса, за которым находится сеть отправителя этого сообщения, такое сообщение отбрасывается.

С помощью этих BSM все мультикастовые маршрутизаторы определяют самого достойного кандидата на основе приоритетов. Как только C-BSR получает BSM от другого маршрутизатора с бОльшим приоритетом, он прекращает рассылать свои сообщения. В результате все обладают одинаковой информацией.

На этом этапе, когда выбран BSR, благодаря тому, что его BSM разошлись уже по всей сети, C-RP знают его адрес и юникастом отправляют на него сообщения Candidte-RP-Advertisement , в которых они несут список групп, которые они обслуживают — это называется group-to-RP mapping . BSR все эти сообщения агрегирует и создаёт RP-Set — информационную таблицу: какие RP каждую группу обслуживают.

Далее BSR в прежней веерной манере рассылает те же BootStrap Message, которые на этот раз содержат RP-Set. Эти сообщения успешно достигают всех мультикастовых маршрутизаторов, каждый из которых самостоятельно делает выбор, какую RP нужно использовать для каждой конкретной группы.

BSR периодически делает такие рассылки, чтобы с одной стороны все знали, что информация по RP ещё актуальна, а с другой C-BSR были в курсе, что сам главный BSR ещё жив.
RP, кстати, тоже периодически шлют на BSR свои анонсы Candidate-RP-Advertisement.

Фактически всё, что нужно сделать для настройки автоматического выбора RP — указать C-RP и указать C-BSR — не так уж много работы, всё остальное за вас сделает PIM.
Как всегда, в целях повышения надёжности рекомендуется указывать интерфейсы Loopback в качестве кандидатов.

Завершая главу PIM SM, давайте ещё раз отметим важнейшие моменты

1. Должна быть обеспечена обычная юникастовая связность с помощью IGP или статических маршрутов. Это лежит в основе алгоритма RPF.
2. Дерево строится только после появления клиента. Именно клиент инициирует построение дерева. Нет клиента — нет дерева.
3. RPF помогает избежать петель.
4. Все маршрутизаторы должны знать о том, кто является RP — только с её помощью можно построить дерево.
5. Точка RP может быть указана статически, а может выбираться автоматически с помощью протокола BootStrap.
6. В первой фазе строится RPT — дерево от клиентов до RP — и Source Tree — дерево от источника до RP. Во второй фазе происходит переключение с построенного RPT на SPT — кратчайший путь от получателя до источника.

Ещё перечислим все типы деревьев и сообщений, которые нам теперь известны.

MDT — Multicast Distribution Tree . Общий термин, описывающий любое дерево передачи мультикаста.
SPT — Shortest Path Tree . Дерево с кратчайшим путём от клиента или RP до источника. В PIM DM есть только SPT. В PIM SM SPT может быть от источника до RP или от источника до получателя после того, как произошёл SPT Switchover. Обозначается записью — известен источник для группы.
Source Tree — то же самое, что SPT.
RPT — Rendezvous Point Tree . Дерево от RP до получателей. Используется только в PIM SM. Обозначается записью .
Shared Tree — то же, что RPT. Называется так потому, что все клиенты подключены к одному общему дереву с корнем в RP.

Типы сообщений PIM Sparse Mode:
Hello — для установления соседства и поддержания этих отношений. Также необходимы для выбора DR.
— запрос на подключение к дереву группы G. Не важно кто источник. Отправляется в сторону RP. С их помощью строится дерево RPT.
— Source Specific Join. Это запрос на подключение к дереву группы G с определённым источником — S. Отправляется в сторону источника — S. С их помощью строится дерево SPT.
Prune (*, G) — запрос на отключение от дерева группы G, какие бы источники для неё не были. Отправляется в сторону RP. Так обрезается ветвь RPT.
Prune (S, G) — запрос на отключение от дерева группы G, корнем которого является источник S. Отправляется в сторону источника. Так обрезается ветвь SPT.
Register — специальное сообщение, внутри которого передаётся мультикаст на RP, пока не будет построено SPT от источника до RP. Передаётся юникастом от FHR на RP.
Register-Stop — отправляется юникастом с RP на FHR, приказывая прекратить посылать мультикастовый трафик, инкапсулированный в Register.
— пакеты механизма BSR, которые позволяют выбрать маршрутизатор на роль BSR, а также передают информацию о существующих RP и группах.
Assert — сообщение для выбора PIM Forwarder, чтобы в один сегмент не передавали трафик два маршрутизатора.
Candidate-RP-Advertisement — сообщение, в котором RP отсылает на BSR информацию о том, какие группы он обслуживает.
RP-Reachable — сообщение от RP, которым она уведомляет всех о своей доступности.
*Есть и другие типы сообщений в PIM, но это уже детали*

А давайте теперь попытаемся абстрагироваться от деталей протокола? И тогда становится очевидной его сложность.

1) Определение RP,
2) Регистрация источника на RP,
3) Переключение на дерево SPT.

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

На сегодняшний день существует два диаметрально противоположных подхода к упрощению PIM: SSM и BIDIR PIM.

SSM

Всё, что мы описывали до сих пор — это ASM — Any Source Multicast . Клиентам безразлично, кто является источником трафика для группы — главное, что они его получают. Как вы помните в сообщении IGMPv2 Report запрашивается просто подключение к группе.
SSM — Source Specific Multicast — альтернативный подход. В этом случае клиенты при подключении указывают группу и источник.
Что же это даёт? Ни много ни мало: возможность полностью избавиться от RP. LHR сразу знает адрес источника — нет необходимости слать Join на RP, маршрутизатор может сразу же отправить Join (S, G) в направлении источника и построить SPT.
Таким образом мы избавляемся от

• Поиска RP (протоколы Bootstrap и Auto-RP),
• Регистрации источника на мультикасте (а это лишнее время, двойное использование полосы пропускания и туннелирование)
• Переключения на SPT.

Поскольку нет RP, то нет и RPT, соответственно ни на одном маршрутизаторе уже не будет записей (*, G) — только (S, G).
Ещё одна проблема, которая решается с помощью SSM — наличие нескольких источников. В ASM рекомендуется, чтобы адрес мультикастовой группы был уникален и только один источник вещал на него, поскольку в дереве RPT несколько потоков сольются, а клиент, получая два потока от разных источников, вероятно, не сможет их разобрать.
В SSM трафик от различных источников распространяется независимо, каждый по своему дереву SPT, и это уже становится не проблемой, а преимуществом — несколько серверов могут вещать одновременно. Если вдруг клиент начал фиксировать потери от основного источника, он может переключиться на резервный, даже не перезапрашивая его — он и так получал два потока.

Кроме того, возможный вектор атаки в сети с активированной мультикастовой маршрутизацией — подключение злоумышленником своего источника и генерирование большого объёма мультикастового трафика, который перегрузит сеть. В SSM такое практически исключено.

Для SSM выделен специальный диапазон IP-адресов: 232.0.0.0/8.
На маршрутизаторах для поддержки SSM включается режим PIM SSM.

Router(config)# ip pim ssm

IGMPv3 и MLDv2 поддерживают SSM в чистом виде.
При их использовании клиент может

• Запрашивать подключение к просто группе, без указания источников. То есть работает как типичный ASM.
• Запрашивать подключение к группе с определённым источником. Источников можно указать несколько — до каждого из них будет построено дерево.
• Запрашивать подключение к группе и указать список источников, от которых клиент не хотел бы получать трафик

IGMPv1/v2, MLDv1 не поддерживают SSM, но имеет место такое понятие, как SSM Mapping . На ближайшем к клиенту маршрутизаторе (LHR) каждой группе ставится в соответствие адрес источника (или несколько). Поэтому если в сети есть клиенты, не поддерживающие IGMPv3/MLDv2, для них также будет построено SPT, а не RPT, благодаря тому, что адрес источника всё равно известен.
SSM Mapping может быть реализован как статической настройкой на LHR, так и посредством обращения к DNS-серверу.

Проблема SSM в том, что клиенты должны заранее знать адреса источников — никакой сигнализацией они им не сообщаются.
Поэтому SSM хорош в тех ситуациях, когда в сети определённый набор источников, их адреса заведомо известны и не будут меняться. А клиентские терминалы или приложения жёстко привязаны к ним.
Иными словами IPTV — весьма пригодная среда для внедрения SSM. Это хорошо описывает концепцию One-to-Many — один источник, много получателей.

А что если в сети источники могут появляться спонтанно то там, то тут, вещать на одинаковые группы, быстро прекращать передачу и исчезать?
Например, такая ситуация возможна в сетевых играх или в ЦОД, где происходит репликация данных между различными серверами. Это концепция Many-to-Many — много источников, много клиентов.
Как на это смотрит обычный PIM SM? Понятное дело, что инертный PIM SSM здесь совсем не подходит?
Вы только подумайте, какой хаос начнётся: бесконечные регистрации источников, перестроение деревьев, огромное количество записей (S, G) живущих по несколько минут из-за таймеров протокола.
На выручку идёт двунаправленный PIM (Bidirectional PIM, BIDIR PIM ). В отличие от SSM в нём напротив полностью отказываются от SPT и записей (S,G) — остаются только Shared Tree с корнем в RP.
И если в обычном PIM, дерево является односторонним — трафик всегда передаётся от источника вниз по SPT и от RP вниз по RPT — есть чёткое деление, где источник, где клиенты, то в двунаправленном от источника трафик к RP передаётся также вверх по Shared Tree — по тому же самому, по которому трафик течёт вниз к клиентам.

Это позволяет отказаться от регистрации источника на RP — трафик передаётся безусловно, без какой бы то ни было сигнализации и изменения состояний. Поскольку деревьев SPT нет вообще, то и SPT Switchover тоже не происходит.

Вот например:

Источник1 начал передавать в сеть трафик группы 224.2.2.4 одновременно с Источником2 . Потоки от них просто полились в сторону RP. Часть клиентов, которые находятся рядом начали получать трафик сразу, потому что на маршрутизаторах есть запись (*, G) (есть клиенты). Другая часть получает трафик по Shared Tree от RP. Причём получают они трафик от обоих источников одновременно.
То есть, если взять для примера умозрительную сетевую игру, Источник1 это первый игрок в стрелялке, который сделал выстрел, а Источник2 — это другой игрок, который сделал шаг в сторону. Информация об этих двух событиях распространилась по всей сети. И каждый другой игрок (Получатель ) должен узнать об обоих этих событиях.

Если помните, то мы объяснили, зачем нужен процесс регистрации источника на RP — чтобы трафик не занимал канал, когда нет клиентов, то есть RP просто отказывался от него. Почему над этой проблемой мы не задумываемся сейчас? Причина проста: BIDIR PIM для ситуаций, когда источников много, но они вещают не постоянно, а периодически, относительно небольшими кусками данных. То есть канал от источника до RP не будет утилизироваться понапрасну.

Обратите внимание, что на изображении выше между R5 и R7 есть прямая линия, гораздо более короткая, чем путь через RP, но она не была использована, потому что Join идут в сторону RP согласно таблице маршрутизации, в которой данный путь не является оптимальным.

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

Поэтому в BIDIR PIM вводится понятие DF — Designated Forwarder . В каждом сегменте сети, на каждой линии на эту роль выбирается тот маршрутизатор, чей маршрут до RP лучше.
В том числе это делается и на тех линиях, куда непосредственно подключены клиенты. В BIDIR PIM DF автоматически является DR.

Список OIL формируется только из тех интерфейсов, на которых маршрутизатор был выбран на роль DF.

Правила довольно прозрачны:

• Если запрос PIM Join/Leave приходит на тот интерфейс, который в данном сегменте является DF, он передаётся в сторону RP по стандартным правилам.
  Вот, например, R3. Если запросы пришли в DF интерфейсы, что помечены красным кругом, он их передаёт на RP (через R1 или R2, в зависимости от таблицы маршрутизации).
• Если запрос PIM Join/Leave пришёл на не DF интерфейс, он будет проигнорирован.
  Допустим, что клиент, находящийся между R1 и R3, решил подключиться и отправил IGMP Report. R1 получает его через интерфейс, где он выбран DF (помечен красным кругом), и мы возвращаемся к предыдущему сценарию. А R3 получает запрос на интерфейс, который не является DF. R3 видит, что тут он не лучший, и игнорирует запрос.
• Если мультикастовый трафик пришёл на DF интерфейс, он будет отправлен в интерфейсы из списка OIL и в сторону RP.
  Например, Источник1 начал передавать трафик. R4 получает его в свой DF интерфейс и передаёт его и в другой DF-интерфейс — в сторону клиента и в сторону RP, — это важно, потому что трафик должен попасть на RP и распространиться по всем получателям. Также поступает и R3 — одна копия в интерфейсы из списка OIL — то есть на R5, где он будет отброшен из-за проверки RPF, и другая — в сторону RP.
• Если мультикастовый трафик пришёл на не DF интерфейс, он должен быть отправлен в интерфейсы из списка OIL, но не будет отправлен в сторону RP.
  К примеру, Источник2 начал вещать, трафик дошёл до RP и начал распространяться вниз по RPT. R3 получает трафик от R1, и он не передаст его на R2 — только вниз на R4 и на R5.

Таким образом DF гарантирует, что на RP в итоге будет отправлена только одна копия мультикастового пакета и образование петель исключено. При этом то общее дерево, в котором находится источник, естественно, получит этот трафик ещё до попадания на RP. RP, согласно обычным правилам разошлёт трафик во все порты OIL, кроме того, откуда пришёл трафик.

Кстати, нет нужды более и в сообщениях Assert, ведь DF выбирается в каждом сегменте. В отличие от DR он отвечает не только за отправку Join к RP, но и за передачу трафика в сегмент, то есть ситуация, когда два маршрутизатора передают в одну подсеть трафик, исключена в BIDIR PIM.

Пожалуй, последнее, что нужно сказать о двунаправленном PIM, это особенности работы RP. Если в PIM SM RP выполнял вполне конкретную функцию — регистрация источника, то в BIDIR PIM RP — это некая весьма условная точка, к которой стремится трафик с одной стороны и Join от клиентов с другой. Никто не должен выполнять декапсуляцию, запрашивать построение дерева SPT. Просто на каком-то маршрутизаторе вдруг трафик от источников начинает передаваться в Shared Tree. Почему я говорю «на каком-то»? Дело в том, что в BIDIR PIM RP — абстрактная точка, а не конкретный маршрутизатор, в качестве адреса RP вообще может выступать несуществующий IP-адрес — главное, чтобы он был маршрутизируемый (такая RP называется Phantom RP).

Все термины, касающиеся PIM, можно найти в глоссарии .

Мультикаст на канальном уровне

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

Расчехлили SSH, проверили CPU, проверили утилизацию интерфейсов и волосы дыбом — загрузка почти под 100% на всех интерфейсах одного VLAN"а. Петля! Но откуда ей взяться, если никаких работ не проводилось? Минут 10 проверки и вы заметили, что на восходящем интерфейсе к ядру у вас много входящего трафика, а на всех нисходящих к клиентам — исходящего. Для петли это тоже характерно, но как-то подозрительно: внедрили мультикаст, никаких работ по переключению не делали и скачок только в одном направлении.
Проверили список мультикастовых групп на маршрутизаторе — а там подписка на все возможные каналы и все на один порт — естественно, тот, который ведёт в этот сегмент.
Дотошное расследование показало, что компьютер клиента заражён и рассылает IGMP Query на все мультикастовые адреса подряд.

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

Главный вопрос — почему трафик одного клиента начал копироваться во все порты?

Причина этого кроется в природе мультикастовых MAC-адресов. Дело в том, пространство мультикастовых IP-адресов специальным образом отображается в пространство мультикастовых MAC-адресов. И загвоздка в том, что они никогда не будут использоваться в качестве MAC-адреса источника, а следовательно, не будут изучены коммутатором и занесены в таблицу MAC-адресов. А как поступает коммутатор с кадрами, адрес назначения которых не изучен? Он их рассылает во все порты. Что и произошло.
Это действие по умолчанию.

Мультикастовые MAC-адреса

Так какие же MAC-адреса получателей подставляются в заголовок Ethernet таких пакетов? Широковещательные? Нет. Существует специальный диапазон MAC-адресов, в которые отображаются мультикастовые IP-адреса.
Эти специальные адреса начинаются так: 0x01005e и следующий 25-й бит должен быть 0 (попробуйте ответить, почему так ). Остальные 23 бита (напомню, всего их в МАС-адресе 48) переносятся из IP-адреса.

Здесь кроется некоторая не очень серьёзная, но проблема. Диапазон мультикастовых адресов определяется маской 224.0.0.0/4, это означает, что первые 4 бита зарезервированы: 1110, а оставшиеся 28 бит могут меняться. То есть у нас 2^28 мультикастовых IP-адресов и только 2^23 MAC-адресов — для отображения 1 в 1 не хватает 5 бит. Поэтому берутся просто последние 23 бита IP-адреса и один в один переносятся в MAC-адрес, остальные 5 отбрасываются.

Фактически это означает, что в один мультикастовый MAC-адрес будет отображаться 2^5=32 IP-адреса. Например, группы 224.0.0.1, 224.128.0.1, 225.0.0.1 и так до 239.128.0.1 все будут отображаться в один MAC-адрес 0100:5e00:0001.

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

IP адрес — 224.2.2.4, MAC-адрес: 01:00:5E:02:02:04.

Есть также другие мультикастовые MAC-адреса, которые никак не относятся к IPv4-мультикаст (клик). Все они, кстати, характеризуются тем, что последний бит первого октета равен 1.

Естественно, ни на одной сетевой карте, не может быть настроен такой MAC-адрес, поэтому он никогда не будет в поле Source MAC Ethernet-кадра и никогда не попадёт в таблицу MAC-адресов. Значит такие кадры должны рассылаться как любой Unknown Unicast во все порты VLAN"а.

Всего, что мы рассматривали прежде, вполне достаточно для полноценной передачи любого мультикастового трафика от потокового видео до биржевых котировок. Но неужели мы в своём почти совершенном мире будем мирится с таким безобразием, как широковещательная передача того, что можно было бы передать избранным?
Вовсе нет. Специально для перфекционистов придуман механизм IGMP-Snooping .

IGMP-Snooping

Идея очень простая — коммутатор «слушает» проходящие через него IGMP-пакеты.
Для каждой группы отдельно он ведёт таблицу восходящих и нисходящих портов.

Если с порта пришёл IGMP Report для группы, значит там клиент, коммутатор добавляет его в список нисходящих для этой группы.
Если с порта пришёл IGMP Query для группы, значит там маршрутизатор, коммутатор добавляет его в список восходящих.

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

Гениальность этой идеи заканчивается тогда, когда мы задумываемся о её природе. Механизм предполагает, что коммутатор должен прослушивать трафик на 3-м уровне.

Впрочем, IGMP-Snooping ни в какое сравнение не идёт с NAT по степени игнорирования принципов сетевого взаимодействия. Тем более, кроме экономии в ресурсах, он несёт в себе массу менее очевидных возможностей. Да и в общем-то в современном мире, коммутатор, который умеет заглядывать внутрь IP — явление не исключительное.

Сервер 172.16.0.5 передает мультикаст трафик на группы 239.1.1.1, 239.2.2.2 и 239.0.0.x.
Настроить сеть таким образом, чтобы:
— клиент 1 не мог присоединиться к группе 239.2.2.2. Но при этом мог присоединиться к группе 239.0.0.x.
— клиент 2 не мог присоединиться к группе 239.1.1.1. Но при этом мог присоединиться к группе 239.0.0.x.

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

Самая простая схема:

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

Адрес мультикастового потока вы можете устанавливать сами.

И соответственно, два вопроса:
1. Что нужно сделать, чтобы компьютер мог получать поток и при этом не прибегать к мультикастовой маршрутизации?
2. Допустим, вы вообще не знаете, что такое мультикаст и не можете его настраивать, как передать поток от сервера к компьютеру?

Задача легко ищется в поисковике, но попробуйте решить её сами.

За помощь в подготовке статьи спасибо JDima …
За техническую поддержку спасибо Наташе Самойленко .
КДПВ нарисована Ниной Долгополовой — замечательным художником и другом проекта.

В пуле статей СДСМ ещё много интересного до окончания, поэтому не нужно хоронить цикл из-за долгого отсутствия выпуска — с каждой новой статьёй сложность значительно возрастает. Впереди почти весь MPLS, IPv6, QoS и дизайн сетей.

Как вы уже, наверно, заметили, у linkmeup появился новый проект — Глоссарий lookmeup (да, недалеко у нас ушла фантазия). Мы надеемся, что этот глоссарий станет самым полным справочником терминов в области связи, поэтому мы будем рады любой помощи в его заполнении. Пишите нам на

.
======

Это первая статья из серии "Сети для самых маленьких". Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN"ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (). Мы понимаем, что для новичков "OSI" и "TCP/IP" - это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.

Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх и потому называется ООО "Лифт ми ап". Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера в сложной борьбе выдержали собеседование на должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Следует несколько конкретизировать ситуацию.

1. В данный момент у компании есть два офиса: 200 квадратов на Арбате под рабочие места и серверную. Там представлены несколько провайдеров. Другой на Рублёвке.


2. Есть четыре группы пользователей: бухгалтерия (Б), финансово-экономический отдел (ФЭО), производственно-технический отдел (ПТО), другие пользователи (Д). А так же есть сервера (С), которые вынесены в отдельную группу. Все группы разграничены и не имеют прямого доступа друг к другу.


3. Пользователи групп С, Б и ФЭО будут только в офисе на Арбате, ПТО и Д будут в обоих офисах.

Прикинув количество пользователей, необходимые интерфейсы, каналы связи, вы готовите схему сети и IP-план.
При проектировании сети следует стараться придерживаться иерархической модели сети , которая имеет много достоинств по сравнению с “плоской сетью”:

• упрощается понимание организации сети


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


• легче найти и изолировать проблему


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


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

Согласно этой модели, сеть разбивается на три логических уровня: ядро сети (Core layer: высокопроизводительные устройства, главное назначение - быстрый транспорт), уровень распространения (Distribution layer: обеспечивает применение политик безопасности, QoS, агрегацию и маршрутизацию в VLAN, определяет широковещательные домены), и уровень доступа (Access-layer: как правило, L2 свичи, назначение: подключение конечных устройств, маркирование трафика для QoS, защита от колец в сети (STP) и широковещательных штормов, обеспечение питания для PoE устройств).

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

На представленной схеме ядром (Core) будет маршрутизатор 2811, коммутатор 2960 отнесём к уровню распространения (Distribution), поскольку на нём агрегируются все VLAN в общий транк. Коммутаторы 2950 будут устройствами доступа (Access). К ним будут подключаться конечные пользователи, офисная техника, сервера.

Именовать устройства будем следующим образом: сокращённое название города (msk ) - географическое расположение (улица, здание) (arbat ) - роль устройства в сети + порядковый номер.
Соответственно их ролям и месту расположения выбираем hostname :
Маршрутизатор 2811: msk-arbat-gw1 (gw=GateWay=шлюз)
Коммутатор 2960: msk-arbat-dsw1 (dsw=Distribution switch)
Коммутаторы 2950: msk-arbat-aswN, msk-rubl-asw1 (asw=Access switch)

Документация сети

Вся сеть должна быть строго документирована: от принципиальной схемы, до имени интерфейса.
Прежде, чем приступить к настройке, я бы хотел привести список необходимых документов и действий:
Схемы сети L1, L2, L3 в соответствии с уровнями модели OSI (Физический, канальный, сетевой)
План IP-адресации = IP-план.
Список VLAN
Подписи (description ) интерфейсов
Список устройств (для каждого следует указать: модель железки, установленная версия IOS, объем RAM\NVRAM, список интерфейсов)
Метки на кабелях (откуда и куда идёт), в том числе на кабелях питания и заземления и устройствах
Единый регламент, определяющий все вышеприведённые параметры и другие.

Говоря о метках/наклейках на кабели, мы имеем ввиду это:

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

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

Подготовим нужные нам документы:

Список VLAN

Каждая группа будет выделена в отдельный влан. Таким образом мы ограничим их широковещательные домены. Также введём специальный VLAN для управления устройствами.
Номера VLAN по 100 зарезервированы для будущих нужд.

Выделение подсетей в общем-то произвольное, соответствующее только числу узлов в этой локальной сети с учётом возможного роста. В данном примере все подсети имеют маску /24 (/24=255.255.255.0) - это сеть класса C - зачастую такие и используются в локальных сетях. Советуем почитать о классах сетей . В дальнейшем мы обратимся и к бесклассовой адресации . Мы понимаем, что ссылки на технические статьи в википедии - это моветон, однако они дают хорошее определение, а мы попробуем в свою очередь перенести это на картину реального мира.
Под сетью Point-to-Point подразумеваем подключение одного маршрутизатора к другому в режиме точка-точка. Обычно берутся адреса с маской 30 (возвращаясь к тебе бесклассовых сетей), то есть содержащие два адреса узла. Позже станет понятно, о чём идёт речь.

План подключения оборудования по портам

Разумеется, сейчас есть коммутаторы с кучей портов 1Gb Ethernet, есть коммутаторы с 10G, на продвинутых операторских железках, стоящих немалые тысячи долларов есть 40Gb, в разработке находится 100Gb (а по слухам уже даже есть такие платы, вышедшие в промышленное производство). Соответственно, вы можете выбирать в реальном мире коммутаторы и маршрутизаторы согласно вашим потребностям, не забывая про бюджет. В частности гигабитный свич сейчас можно купить незадорого (20-30 тысяч) и это с запасом на будущее (если вы не провайдер, конечно). Маршрутизатор с гигабитными портами стоит уже ощутимо дороже, чем со 100Mbps портами, однако оно того стоит, потому что FE-модели (100Mbps FastEthernet), устарели и их пропускная способность очень невысока.
Но в программах эмуляторах/симуляторах,которые мы будем использовать, к сожалению, есть только простенькие модели оборудования, поэтому при моделировании сети будем отталкиваться от того, что имеем:

Почему именно так распределены VLAN"ы, мы объясним в следующих частях.

Схемы сети

На основании этих данных можно составить все три схемы сети на этом этапе. Для этого можно воспользоваться Microsoft Visio, каким-либо бесплатным приложением, но с привязкой к своему формату, или редакторами графики (можно и от руки, но это будет сложно держать в актуальном состоянии:)).

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

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

L2

На схеме L2 мы указываем наши VLAN’ы

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

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

К этой первой статье мы не раз ещё вернёмся в будущем, равно как и вам придётся всегда возвращаться к тому, что вы изначально напланировали.
Собственно задание для тех, кто пока только начинает учиться и готов приложить для этого усилия: много читать про вланы, найти программы Packet Tracer и GNS3.
В следующей части мы будем учиться подключаться к оборудованию, разбираться с интерфейсом и расскажем, что делать нерадивому админу, забывшему пароль.

Часть первая (которая после нулевой). Подключение к оборудованию cisco Сегодня мы обратимся к части немного скучной, но важной для начинающих: как подключиться, поставить или сбросить пароль, войти по telnet. Также рассмотрим существующие программы - эмуляторы ciscо и интерфейс оборудования.
Как и обещали, в этот раз всё по-взрослому: с видео.

» Кликните сюда для просмотра оффтоп текста.. «

Итак, вот они приехали - заветные коробки с надписью Cisco на борту.

Среда
Начнём с того, в какой среде будем работать.

В данный момент есть два известных пакета программ, позволяющих моделировать сеть, построенную на оборудовании Cisco:

А) Цисковский же продукт Packet Tracer, который по идее свободно не распространяется. Это эмулятор и имеет лишь некоторые функции Cisco IOS. Вообще говоря, он сильно ограничен и многие вещи в нём реализованы лишь отчасти. Никаких тонких настроек. С другой стороны к настоящему моменту версия 5.3.2 поддерживает создание GRE-туннелей, протоколов динамической маршрутизации (и в их числе даже BGP!). Притом он очень прост в освоении и имеет в своём арсенале сервера (FTP, TFTP, DHCP, DNS, HTTP, NTP, RADIUS, SMTP, POP3), рабочие станции и свичи. Сейчас уже есть под Linux, хотя в былые времени он прекрасно запускался и из-под Wine.

Б) Распространяемый по лицензии GNU GPL симулятор GNS3. В этом пакете необходимо загружать настоящие образы Cisco IOS. С одной стороны это плюс – вы работаете с настоящим интерфейсом cisco и ограничены лишь своей фантазией, существующими стандартами и производительностью рабочей станции, с другой, во-первых, эти IOS ещё нужно суметь достать, во-вторых, это более сложный продукт для понимания, и в-третьих, в нём есть только маршрутизаторы и «типа» коммутаторы.

Я считаю, что для знакомства с принципами лучше начать всё же с Packet Tracer"a, а потом переходить на тяжёлую артиллерию по мере надобности. Все мы не дети малые, где взять то, что нам нужно, рассказывать не будем.

Способы подключения

В Packet Tracer’e управлять оборудованием можно следующими способами:

• CLI в окне управления
• telnet

Интерфейс последних трёх идентичный – отличается лишь способ подключения. Разумеется, GUI – не наш метод.
В реальной же жизни доступны:

• Telnet/ssh
• Терминальное подключение с рабочей станции через консольный кабель
• Web-интерфейс (Cisco SDM).

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

Всегда выделен голубым цветом. С недавних пор стало возможным управление по USB.
А это консольный кабель cisco:

Раньше он поставлялся в каждой коробке, теперь зачастую стоит отдельных денег. В принципе подходит аналогичный кабель от HP.
Проблема в том, что современные ПК зачастую не имеют COM-порта. На выручку приходят часто используемые конвертеры USB-to-COM:

Либо редко используемые для этих целей конвертеры RS232-Ethernet

После того, как вы воткнули кабель, определили номер COM-порта, для подключения можно использовать Hyperterminal или Putty в Виндоус и Minicom в Линукс.

Управление через консоль доступно сразу, а вот для телнета нужно установить пароль. Как это сделать?
Обратимся к PT.
Начнём с создания маршрутизатора: выбираем его на панели внизу и переносим на рабочее пространство. Даём какое-нибудь название

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

Кликом по компьютеру вызываем окно настройки, в котором нас интересует вкладка Desktop. Далее выбираем Terminal, где нам даётся выбор параметров

Впрочем, все параметры по умолчанию нас устраивают, и менять их особо смысла нет.

Если в энергонезависимой памяти устройства отсутствует конфигурационный файл (startup-config), а так оно и будет при первом включении нового железа, нас встретит Initial Configuration Dialog prompt:

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

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

Грубо говоря, это режим для сетевого оператора, инженера первой линии техподдержки, чтобы он ничего там не повредил, не напортачил и лишнего не узнал.
Гораздо большие возможности предоставляет режим с говорящим названием привилегированный . Попасть в него можно, введя команду >enable . Теперь приглашение выглядит так:
Здесь список операций гораздо обширнее, например, можно выполнить одну из наиболее часто используемых команд, демонстрирующую текущие настройки устройства ака “конфиг” #show running-config . В привилегированном режиме вы можете просмотреть всю информацию об устройстве.

Прежде, чем приступать к настройке, упомянем несколько полезностей при работе с cisco CLI, которые могут сильно упростить жизнь:
- Все команды в консоли можно сокращать. Главное, чтобы сокращение однозначно указывало на команду. Например, show running-config сокращается до sh run . Почему не до s r ? Потому, что s (в пользовательском режиме) может означать как команду show , так и команду ssh , и мы получим сообщение об ошибке % Ambiguous command: «s r» (неоднозначная команда).

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

Используйте горячие клавиши в консоли:

Ctrl+A - Передвинуть курсор на начало строки
Ctrl+E - Передвинуть курсор на конец строки
Курсорные Up, Down - Перемещение по истории команд
Ctrl+W - Стереть предыдущее слово
Ctrl+U - Стереть всю линию
Ctrl+C - Выход из режима конфигурирования
Ctrl+Z - Применить текущую команду и выйти из режима конфигурирования
Ctrl+Shift+6 - Остановка длительных процессов (так называемый escape sequence)

Используйте фильтрацию вывода команды. Бывает, что команда выводит много информации, в которой нужно долго копаться, чтобы найти определённое слово, например.
Облегчаем работу с помощью фильтрации: после команды ставим | , пишем вид фильтрации и, собственно, искомое слово(или его часть). Виды фильтрации (ака модификаторы вывода):

begin - вывод всех строк, начиная с той, где нашлось слово,
section - вывод секций конфигурационного файла, в которых встречается слово,
include - вывод строк, где встречается слово,
exclude - вывод строк, где НЕ встречается слово.

Но вернемся к режимам. Третий главный режим, наряду с пользовательским и привилегированным: режим глобальной конфигурации . Как понятно из названия, он позволяет нам вносить изменения в настройки устройства. Активируется командой #configure terminal из привилегированного режима и демонстрирует такое приглашение:

В режиме глобальной конфигурации не выполняются довольно нужные порой команды других режимов (тот же show running-config, ping, etc.). Но есть такая полезная штука, как do . Благодаря ей мы можем, не выходя из режима конфигурирования, выполнять эти самые команды, просто добавляя перед ними do. Примерно так:

Router(config)#do show running-config

Настройка доступа по Telnet
Из этого-то режима мы и настроим интерфейс для подключения компьютера через telnet:
Команда для перехода в режим конфигурации интерфейса FastEthernet 0/0:

Router(config)# interface fa0/0

По умолчанию все интерфейсы отключены (состояние administratively down). Включаем интерфейс:

Router(config-if)#no shutdown

Настроим IP-адрес:

Router(config-if)#ip address 192.168.1.1 255.255.255.0

shutdown - означает “выключить интерфейс”. Соответственно, если вы хотите отменить действие команды, то используйте слово no перед ней. Это правило общее для CLI и применимо к большинству команд.

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

И пробуем подключиться, выбрав Command Prompt в панели Desktop:

Как и ожидалось, циска не пускает без пароля. В реальной жизни обычно выдаёт фразу “Password required, but none set”

Пароли
Подключение по telnet или ssh называется виртуальным терминалом (vt) и настраивается следующим образом:

Router(config)#line vty 0 4
cisco
Router(config-line)#login

0 4 - это 5 пользовательских виртуальных терминалов=telnet сессий.
Этого уже достаточно, чтобы попасть в пользовательский режим, но недостаточно для привилегированного:

Настроим пароль для enable-режима:

Router(config)#enable secret test

(IMG:http://img-fotki.yandex.ru/get/5/83739833.10/0_7c488_b5c8c887_XL.jpg)

Чем отличается secret от password ? Примерно тем же, чем ssh от telnet. При настройке secret пароль хранится в зашифрованном виде в конфигурационном файле, а password – в открытом. Поэтому рекомендуется использование secret .
Если вы всё-таки задаёте пароль командой password , то следует применить так же service password-encryption , тогда ваш пароль в конфигурационном файле будет зашифрован:

line vty 0 4
password 7 08255F4A0F0A0111

Один мой знакомый рассказал мне историю:
Стоял он как-то курил возле одного из своих узлов, находящемся в жилом доме. С сумкой для инструментов, ноутбук в руках. Вдруг подходит двое алкашей с пакетом и предлагают купить, раскрывая пакет и показывая какой-то свич. Просят 500 рублей. Ну он купил. По меткам и модели свича парень сделал вывод какому провайдеру он принадлежит. Пришёл домой, начал ковырять - телнет закрыт, консоль запаролена. Слил конфиг по snmp. Пароли в открытом виде хранятся, имя с головой выдаёт провайдера. С их админом он знаком лично, позвонил ему вместо “Здрасьти” выдал логин и пароль в трубку. Слышно было, как скрипел мозг первые секунд 20: везде аксес-листы, авторизация, привязка к мак-адресу. Как?! В общем, всё хорошо, что хорошо кончается.

Немного об этом можно почитать . Ну или чуть более по-русски, .

Хотим обратить ваше внимание:
сейчас принятно настраивать доступы не через виртуальные терминалы, а командами #username и #aaa new-model . В версии PT 5.3.2 они уже есть и вполне работают.
Для этого нужно выполнить:

Router(config)#aaa new-model
Router(config)#username admin password 1234

Первая команда служит для активации новой модели (IMG:http://ru.wikipedia.org/wiki/Протокол_AAA) ААА (Authentication, Authorization, Accounting). Это нужно для того, чтобы была возможность использовать для аунтетификации на устройстве RADIUS или TACACS сервер. Если отдельно это не настроено, то будет использоваться локальная база пользователей, задаваемая командой username .

Будьте внимательны : приоритет команды aaa new-model выше, чем команд виртуальных терминалов и поэтому даже несмотря на то, что у вас настроен password в режиме line vty, если у вас не будет пользователей в локальной базе, зайти на устройство удалённо уже не получится.

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

При более глубокой настройке line vty существует одна опасность.
Есть такой параметр: access-class . Его настройка позволяет ограничить IP-адреса, с которых возможно подключение. И вот однажды я, как умная маша, решил заняться безопасностью в сети и на всём почти оборудование понаставил эти аксес-листы, чтобы комар не пролетел. В один прекрасный момент пришлось выехать в поле и в тот день я проклял свою аккуратность – никуда не мог достучаться – малейшей лазейки не оставил. В общем будьте с этой командой внимательны или оставляйте для себя лазейки.
При работе с access-list"ами и прочими опасными вещами, неправильная настройка которых может лишить вас доступа к устройству, можно использовать замечательную команду reload in min , где min время в минутах. Эта команда перезагрузит устройство по истечении указанного времени, если ее не прервать командой reload cancel . Т.е. схема работы такова: вы удаленно копаете что-то, что может в теории (закон Мерфи не забываем) прервать ваш сеанс связи с устройством. Сохраняем текущий (рабочий) конфиг в startup-config (он используется при загрузке), ставим reload in 15, вводим ключевую команду, относительно которой у нас сомнения;-), и получаем обрыв связи, худшие опасения оправдались. Ждем 15 минут, устройство перегружается с рабочим конфигом, коннект - вуаля, связь есть. Либо (если связь не прервалась) проверяем, что все работает, и делаем reload cancel .

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

Router(config)#line console 0
Router(config-line)#login
Router(config-line)#password cisco

Privilege Level
Ещё один важный момент, которому в статьях уделяют мало внимания: privelege level.
Как понятно из латинского звучания - это уровень прав пользователя. Всего существует 16 уровней: 0-15.
privilege level 0 - это команды disable, enable, exit, help и logout, которые работают во всех режимах
privilege level 1 - Это команды пользовательского режима, то есть как только вы попадаете на циску и увидите приглашение Router> вы имеете уровень 1.
privilege level 15 - Это команды привилегированного режима, вроде, как root в Unix"ах

Пример1

Router(config)#line vty 0 4
Router(config-line)privilege level 15

После входа на маршрутизатор при такой настройке вы сразу увидите Router# со всеми вытекающими правами.

Все уровни со 2 по 14 настраиваются вручную. То есть, например, вы можете дать добро пользователю с privelege level 2 на выполнение команды show running-config

Пример2

Настроить права для конкретного пользователя поможет уже упомянутая прежде команда username

Router(config)#username pooruser privilege 2 secret poorpass
Router(config)#privilege exec level 2 show running-config
Router(config)#enable secret level 2 l2poorpass

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

После этого из пользовательского режима вы можете выполнить команду enable 2 и введя пароль l2poorpass попасть в привилегированный режим, в котором будут доступны все команды уровня 1 + команды уровня 2.

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

SSH
Нельзя не упомянуть о том, что telnet - протокол незащищённый и передаёт пароль и данные в открытом виде. С помощью любого анализатора пакетов можно вычислить пароль.
Поэтому крайне рекомендуем использовать ssh - любые устройства cisco с не самой урезанной прошивкой способны выступать ssh-сервером.
Следующий набор команд позволит вам включить ssh и отключить доступ по telnet:

Router(config)#hostname R0
Router(config)#ip domain-name cisco-dmn
Router(config)#crypto key generate rsa
Router(config)#line vty 0 4
Router(config-line)#transport input ssh

Имя хоста должно отличаться от Router, обязательно должно быть задано имя домена. Третьей строкой генерируется ключ и далее разрешается только ssh. Длина ключа должна быть более 768 бит, если вы желаете использовать ssh версии 2, а вы желаете этого. Всё.

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

Используя PT, мы будем настраивать оборудование не через терминал или телнет, а непосредственно через CLI устройства, которое вызывается кликом по иконке роутера - так удобнее:

Ну и на сладенькое: сброс пароля
Так, а что же делать, если на стол легла вам бушная циска с неизвестным паролем или вы очень невовремя забыли его? Вообще-то это многократно описано и легко гуглится, но повторить это необходимо.
Практически на любом сетевом устройстве есть возможность сбросить пароль, имея физический доступ. Если сделать это невозможно или это отдельная платная услуга, то скорее всего в ваших руках находится какая-то русская поделка (не в обиду, конечно, нашим производителям, но дважды я такие строки читал в документации:))
Итак, cisco:
1) Подключаетесь к устройству консольным кабелем,
2) Отправляете его в ребут (хоть по питанию, хоть командой #reload )
3) Когда на экране побежит такая строчка ########...###, означающая загрузку образа (40-60 секунд после включения), необходимо отправить сигнал Break . Как это сделать в разных программах читать . Вы попадаете в режим ROMMON.
4) В этом режиме введите команду: confreg 0x2142 , она заставит устройство игнорировать startup-config при загрузке.
5) Введите reset для перезагрузки
6) После загрузки running-config будет девственно чистым, а startup-config содержит по-прежнему последнюю сохранённую конфигурацию. Сейчас самое время поменять пароль или слить конфиг.
7) Самое важное: верните обратно регистры :

Router(config)#config-register 0x2102

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

В следующей статье мы обратимся к вланам и локальной сети. Обязательно к прочтению:
OSI .
VLAN

Хочу поблагодарить Максима aka gluck за помощь в написании этой статьи.

• Tutorial

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

Немного оффтопа: Приблизительно месяц назад сдал экзамен CCNA (на 980/1000 баллов) и осталось много материала за год моей подготовки и обучения. Учился я сначала в академии Cisco около 7 месяцев, а оставшееся время вел конспекты по всем темам, которые были мною изучены. Также консультировал многих ребят в области сетевых технологий и заметил, что многие наступают на одни и те же грабли, в виде пробелов по каким-то ключевым темам. На днях пару ребят попросили меня объяснить, что такое сети и как с ними работать. В связи с этим решил максимально подробно и простым языком описать самые ключевые и важные вещи. Статьи будут полезны новичкам, которые только встали на путь изучения. Но, возможно, и бывалые сисадмины подчеркнут из этого что-то полезное. Так как я буду идти по программе CCNA, это будет очень полезно тем людям, которые готовятся к сдаче. Можете держать статьи в виде шпаргалок и периодически их просматривать. Я во время обучения делал конспекты по книгам и периодически читал их, чтобы освежать знания.

Вообще хочу дать всем начинающим совет. Моей первой серьезной книгой, была книга Олиферов «Компьютерные сети». И мне было очень тяжело читать ее. Не скажу, что все было тяжело. Но моменты, где детально разбиралось, как работает MPLS или Ethernet операторского класса, вводило в ступор. Я читал одну главу по несколько часов и все равно многое оставалось загадкой. Если вы понимаете, что какие то термины никак не хотят лезть в голову, пропустите их и читайте дальше, но ни в коем случае не отбрасывайте книгу полностью. Это не роман или эпос, где важно читать по главам, чтобы понять сюжет. Пройдет время и то, что раньше было непонятным, в итоге станет ясно. Здесь прокачивается «книжный скилл». Каждая следующая книга, читается легче предыдущей книги. К примеру, после прочтения Олиферов «Компьютерные сети», читать Таненбаума «Компьютерные сети» легче в несколько раз и наоборот. Потому что новых понятий встречается меньше. Поэтому мой совет: не бойтесь читать книги. Ваши усилия в будущем принесут плоды. Заканчиваю разглагольствование и приступаю к написанию статьи.

Вот сами темы

1) Основные сетевые термины, сетевая модель OSI и стек протоколов TCP/IP.
2)
3)
4)
5)
6)
7)
8)
9) Маршрутизация: статическая и динамическая на примере RIP, OSPF и EIGRP.
10) Трансляция сетевых адресов: NAT и PAT.
11) Протоколы резервирования первого перехода: FHRP.
12) Безопасность компьютерных сетей и виртуальные частные сети: VPN.
13) Глобальные сети и используемые протоколы: PPP, HDLC, Frame Relay.
14) Введение в IPv6, конфигурация и маршрутизация.
15) Сетевое управление и мониторинг сети.

P.S. Возможно, со временем список дополнится.

Итак, начнем с основных сетевых терминов.

Что такое сеть? Это совокупность устройств и систем, которые подключены друг к другу (логически или физически) и общающихся между собой. Сюда можно отнести сервера, компьютеры, телефоны, маршрутизаторы и так далее. Размер этой сети может достигать размера Интернета, а может состоять всего из двух устройств, соединенных между собой кабелем. Чтобы не было каши, разделим компоненты сети на группы:

1) Оконечные узлы: Устройства, которые передают и/или принимают какие-либо данные. Это могут быть компьютеры, телефоны, сервера, какие-то терминалы или тонкие клиенты, телевизоры.

2) Промежуточные устройства: Это устройства, которые соединяют оконечные узлы между собой. Сюда можно отнести коммутаторы, концентраторы, модемы, маршрутизаторы, точки доступа Wi-Fi.

3) Сетевые среды: Это те среды, в которых происходит непосредственная передача данных. Сюда относятся кабели, сетевые карточки, различного рода коннекторы, воздушная среда передачи. Если это медный кабель, то передача данных осуществляется при помощи электрических сигналов. У оптоволоконных кабелей, при помощи световых импульсов. Ну и у беспроводных устройств, при помощи радиоволн.

Посмотрим все это на картинке:

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

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

1) Приложения: При помощи приложений отправляем разные данные между устройствами, открываем доступ к общим ресурсам. Это могут быть как консольные приложения, так и приложения с графическим интерфейсом.

2) Сетевые ресурсы: Это сетевые принтеры, которыми, к примеру, пользуются в офисе или сетевые камеры, которые просматривает охрана, находясь в удаленной местности.

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

4) Резервное копирование: Часто, в крупных компаниях, используют центральный сервер, куда все компьютеры копируют важные файлы для резервной копии. Это нужно для последующего восстановления данных, если оригинал удалился или повредился. Методов копирования огромное количество: с предварительным сжатием, кодированием и так далее.

5) VoIP: Телефония, работающая по протоколу IP. Применяется она сейчас повсеместно, так как проще, дешевле традиционной телефонии и с каждым годом вытесняет ее.

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

1) Загрузчики. Это файловые менеджеры, работающие по протоколу FTP, TFTP. Банальный пример - это скачивание фильма, музыки, картинок с файлообменников или иных источников. К этой категории еще можно отнести резервное копирование, которое автоматически делает сервер каждую ночь. То есть это встроенные или сторонние программы и утилиты, которые выполняют копирование и скачивание. Данный вид приложений не требует прямого человеческого вмешательства. Достаточно указать место, куда сохранить и скачивание само начнется и закончится.

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

FTP- это стандартный протокол передачи данных с установлением соединения. Работает по протоколу TCP (этот протокол в дальнейшем будет подробно рассмотрен). Стандартный номер порта 21. Чаще всего используется для загрузки сайта на веб-хостинг и выгрузки его. Самым популярным приложением, работающим по этому протоколу - это Filezilla. Вот так выглядит само приложение:

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

Интерактивные приложения. Приложения, позволяющие осуществить интерактивный обмен. Например, модель «человек-человек». Когда два человека, при помощи интерактивных приложений, общаются между собой или ведут общую работу. Сюда относится: ICQ, электронная почта, форум, на котором несколько экспертов помогают людям в решении вопросов. Или модель «человек-машина». Когда человек общается непосредственно с компьютером. Это может быть удаленная настройка базы, конфигурация сетевого устройства. Здесь, в отличие от загрузчиков, важно постоянное вмешательство человека. То есть, как минимум, один человек выступает инициатором. Пропускная способность уже более чувствительна к задержкам, чем приложения-загрузчики. Например, при удаленной конфигурации сетевого устройства, будет тяжело его настраивать, если отклик от команды будет в 30 секунд.

Приложения в реальном времени. Приложения, позволяющие передавать информацию в реальном времени. Как раз к этой группе относится IP-телефония, системы потокового вещания, видеоконференции. Самые чувствительные к задержкам и пропускной способности приложения. Представьте, что вы разговариваете по телефону и то, что вы говорите, собеседник услышит через 2 секунды и наоборот, вы от собеседника с таким же интервалом. Такое общение еще и приведет к тому, что голоса будут пропадать и разговор будет трудноразличимым, а в видеоконференция превратится в кашу. В среднем, задержка не должна превышать 300 мс. К данной категории можно отнести Skype, Lync, Viber (когда совершаем звонок).

Теперь поговорим о такой важной вещи, как топология. Она делится на 2 большие категории: физическая и логическая . Очень важно понимать их разницу. Итак, физическая топология - это как наша сеть выглядит. Где находятся узлы, какие сетевые промежуточные устройства используются и где они стоят, какие сетевые кабели используются, как они протянуты и в какой порт воткнуты. Логическая топология - это каким путем будут идти пакеты в нашей физической топологии. То есть физическая - это как мы расположили устройства, а логическая - это через какие устройства будут проходить пакеты.

Теперь посмотрим и разберем виды топологии:

1) Топология с общей шиной (англ. Bus Topology)

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

2) Кольцевая топология (англ. Ring Topology)

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

3) Топология звезда (англ. Star Topology)

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

4)Полносвязная топология (англ. Full-Mesh Topology)

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

5)Неполносвязная топология (англ. Partial-Mesh Topology)

Как правило, вариантов ее несколько. Она похожа по строению на полносвязную топологию. Однако соединение построено не с каждого на каждый, а через дополнительные узлы. То есть узел A, связан напрямую только с узлом B, а узел B связан и с узлом A, и с узлом C. Так вот, чтобы узлу A отправить сообщение узлу C, ему надо отправить сначала узлу B, а узел B в свою очередь отправит это сообщение узлу C. В принципе по этой топологии работают маршрутизаторы. Приведу пример из домашней сети. Когда вы из дома выходите в Интернет, у вас нет прямого кабеля до всех узлов, и вы отправляете данные своему провайдеру, а он уже знает куда эти данные нужно отправить.

6) Смешанная топология (англ. Hybrid Topology)

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

И последнее, что осталось разобрать - это сетевые модели. На этапе зарождения компьютеров, у сетей не было единых стандартов. Каждый вендор использовал свои проприетарные решения, которые не работали с технологиями других вендоров. Конечно, оставлять так было нельзя и нужно было придумывать общее решение. Эту задачу взвалила на себя международная организация по стандартизации (ISO - International Organization for Standartization). Они изучали многие, применяемые на то время, модели и в результате придумали модель OSI , релиз которой состоялся в 1984 году. Проблема ее была только в том, что ее разрабатывали около 7 лет. Пока специалисты спорили, как ее лучше сделать, другие модели модернизировались и набирали обороты. В настоящее время модель OSI не используют. Она применяется только в качестве обучения сетям. Мое личное мнение, что модель OSI должен знать каждый уважающий себя админ как таблицу умножения. Хоть ее и не применяют в том виде, в каком она есть, принципы работы у всех моделей схожи с ней.

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

1) Физический уровень (Physical Layer): определяет метод передачи данных, какая среда используется (передача электрических сигналов, световых импульсов или радиоэфир), уровень напряжения, метод кодирования двоичных сигналов.

2) Канальный уровень (Data Link Layer): он берет на себя задачу адресации в пределах локальной сети, обнаруживает ошибки, проверяет целостность данных. Если слышали про MAC-адреса и протокол «Ethernet», то они располагаются на этом уровне.

3) Сетевой уровень (Network Layer): этот уровень берет на себя объединения участков сети и выбор оптимального пути (т.е. маршрутизация). Каждое сетевое устройство должно иметь уникальный сетевой адрес в сети. Думаю, многие слышали про протоколы IPv4 и IPv6. Эти протоколы работают на данном уровне.

4) Транспортный уровень (Transport Layer): Этот уровень берет на себя функцию транспорта. К примеру, когда вы скачиваете файл с Интернета, файл в виде сегментов отправляется на Ваш компьютер. Также здесь вводятся понятия портов, которые нужны для указания назначения к конкретной службе. На этом уровне работают протоколы TCP (с установлением соединения) и UDP (без установления соединения).

5) Сеансовый уровень (Session Layer): Роль этого уровня в установлении, управлении и разрыве соединения между двумя хостами. К примеру, когда открываете страницу на веб-сервере, то Вы не единственный посетитель на нем. И вот для того, чтобы поддерживать сеансы со всеми пользователями, нужен сеансовый уровень.

6) Уровень представления (Presentation Layer): Он структурирует информацию в читабельный вид для прикладного уровня. Например, многие компьютеры используют таблицу кодировки ASCII для вывода текстовой информации или формат jpeg для вывода графического изображения.

7) Прикладной уровень (Application Layer): Наверное, это самый понятный для всех уровень. Как раз на этом уроне работают привычные для нас приложения - e-mail, браузеры по протоколу HTTP, FTP и остальное.

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

На прикладном, представления и сеансовым уровнях, передаваемая информация обозначается как PDU (Protocol Data Units). На русском еще называют блоки данных, хотя в моем круге их называют просто данные).

Информацию транспортного уровня называют сегментами. Хотя понятие сегменты, применимо только для протокола TCP. Для протокола UDP используется понятие - датаграмма. Но, как правило, на это различие закрывают глаза.
На сетевом уровне называют IP пакеты или просто пакеты.

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

1) Представим ситуацию, что вы сидите у себя дома за компьютером, а в соседней комнате у вас свой локальный веб-сервер. И вот вам понадобилось скачать файл с него. Вы набираете адрес страницы вашего сайта. Сейчас вы используете протокол HTTP, которые работает на прикладном уровне. Данные упаковываются и спускаются на уровень ниже.

2) Полученные данные прибегают на уровень представления. Здесь эти данные структурируются и приводятся в формат, который сможет быть прочитан на сервере. Запаковывается и спускается ниже.

3) На этом уровне создается сессия между компьютером и сервером.

4) Так как это веб сервер и требуется надежное установление соединения и контроль за принятыми данными, используется протокол TCP. Здесь мы указываем порт, на который будем стучаться и порт источника, чтобы сервер знал, куда отправлять ответ. Это нужно для того, чтобы сервер понял, что мы хотим попасть на веб-сервер (стандартно - это 80 порт), а не на почтовый сервер. Упаковываем и спускаем дальше.

5) Здесь мы должны указать, на какой адрес отправлять пакет. Соответственно, указываем адрес назначения (пусть адрес сервера будет 192.168.1.2) и адрес источника (адрес компьютера 192.168.1.1). Заворачиваем и спускаем дальше.

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

7) И уже физический уровень конвертирует полученное в биты и при помощи электрических сигналов (если это витая пара), отправляет на сервер.

Процесс деинкапсуляции аналогичен, но с обратной последовательностью:

1) На физическом уровне принимаются электрические сигналы и конвертируются в понятную битовую последовательность для канального уровня.

2) На канальном уровне проверяется MAC-адрес назначения (ему ли это адресовано). Если да, то проверяется кадр на целостность и отсутствие ошибок, если все прекрасно и данные целы, он передает их вышестоящему уровню.

3) На сетевом уровне проверяется IP адрес назначения. И если он верен, данные поднимаются выше. Не стоит сейчас вдаваться в подробности, почему у нас адресация на канальном и сетевом уровне. Это тема требует особого внимания, и я подробно объясню их различие позже. Главное сейчас понять, как данные упаковываются и распаковываются.

4) На транспортном уровне проверяется порт назначения (не адрес). И по номеру порта, выясняется какому приложению или сервису адресованы данные. У нас это веб-сервер и номер порта - 80.

5) На этом уровне происходит установление сеанса между компьютером и сервером.

6) Уровень представления видит, как все должно быть структурировано и приводит информацию в читабельный вид.

7) И на этом уровне приложения или сервисы понимают, что надо выполнить.

Много было написано про модель OSI. Хотя я постарался быть максимально краток и осветить самое важное. На самом деле про эту модель в Интернете и в книгах написано очень много и подробно, но для новичков и готовящихся к CCNA, этого достаточно. Из вопросов на экзамене по данной модели может быть 2 вопроса. Это правильно расположить уровни и на каком уровне работает определенный протокол.

Как было написано выше, модель OSI в наше время не используется. Пока разрабатывалась эта модель, все большую популярность получал стек протоколов TCP/IP. Он был значительно проще и завоевал быструю популярность.
Вот так этот стек выглядит:

Как видно, он отличается от OSI и даже сменил название некоторых уровней. По сути, принцип у него тот же, что и у OSI. Но только три верхних уровня OSI: прикладной, представления и сеансовый объединены у TCP/IP в один, под названием прикладной. Сетевой уровень сменил название и называется - Интернет. Транспортный остался таким же и с тем же названием. А два нижних уровня OSI: канальный и физический объединены у TCP/IP в один с названием - уровень сетевого доступа. Стек TCP/IP в некоторых источниках обозначают еще как модель DoD (Department of Defence). Как говорит википедия, была разработана Министерством обороны США. Этот вопрос встретился мне на экзамене и до этого я про нее ничего не слышал. Соответственно вопрос: «Как называется сетевой уровень в модели DoD?», ввел меня в ступор. Поэтому знать это полезно.

Было еще несколько сетевых моделей, которые, какое то время держались. Это был стек протоколов IPX/SPX. Использовался с середины 80-х годов и продержался до конца 90-х, где его вытеснила TCP/IP. Был реализован компанией Novell и являлся модернизированной версией стека протоколов Xerox Network Services компании Xerox. Использовался в локальных сетях долгое время. Впервые IPX/SPX я увидел в игре «Казаки». При выборе сетевой игры, там предлагалось несколько стеков на выбор. И хоть выпуск этой игры был, где то в 2001 году, это говорило о том, что IPX/SPX еще встречался в локальных сетях.

Еще один стек, который стоит упомянуть - это AppleTalk. Как ясно из названия, был придуман компанией Apple. Создан был в том же году, в котором состоялся релиз модели OSI, то есть в 1984 году. Продержался он совсем недолго и Apple решила использовать вместо него TCP/IP.

Также хочу подчеркнуть одну важную вещь. Token Ring и FDDI - не сетевые модели! Token Ring - это протокол канального уровня, а FDDI это стандарт передачи данных, который как раз основывается на протоколе Token Ring. Это не самая важная информация, так как эти понятия сейчас не встретишь. Но главное помнить о том, что это не сетевые модели.

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

топология сети

Добавить метки