4 PS Route2 7 0 0 1548753182

Программа курса
«Маршрутизация в IP сетях,
расширенный»
Маршрутизація в ІР мережах, розширений
IP Routing, Advanced
Для групп полустационара. Версия 7.0.0

Объем курса: 10 уроков.
Цель курса
Данный курс является развитием курса ROU2 версии 5.x.x, но содержит
целый ряд отличий от версии 5.х.х:
• использует новые материалы курса CCNA – CCNA R&S v5;
• содержит ранее отсутствовавшие модули, посвященные ipv6;
• содержит ранее отсутствовавшие модули, посвященные dhcp (теперь
подробно изучается в CCNA R&S) и dns (это важно для последующего
изучения материалов CCNP);
• содержит несколько дополнительных тем для лучшей интеграции
с материалами авторизованного курса.
Данный курс включает в себя рассмотрение модулей 8, 9, 10 и 11 авто-
ризованного курса CCNA R&S Introduction to Networks.
Данный курс включает в себя рассмотрение модулей 4, 6, 7, 8, 9, 10 и 11
авторизованного курса CCNA R&S Routing and Switching Essentials (CCNA2).
Данный курс включает в себя рассмотрение модулей 5, 6, 7, 8, 9 автори-
зованного курса CCNA R&S Scaling Networks (CCNA3).
Данный курс включает в себя рассмотрение модуля 7 авторизованного
курса CCNA R&S Connecting Networks (CCNA4).
Данный курс должен опираться на реализации cisco, использование
других платформ для изучения маршрутизации недопустимо. Пред-
почтительным инструментом для реализации демонстраций и лабо-
раторных работ должен быть dynamips/gns3, разумеется допускается
использование реального оборудования. Использование PacketTracer
важно с целью обучения работе с этим инструментом, но его
использование следует свести к минимуму везде, где это возможно.
В течение данного курса студенты должны сдать финальный экзамен
по курсу CCNA1.
По завершении данного курса проводятся экзамены по ROUTE1 и ROUTE2.
Программа курса «Маршрутизация в IP сетях, расширенный»
Для групп полустационара. Версия 7.0.0 стр. 2 из 59
Тематический план
Урок 1.
Адресация в IPv6
Протокол IPv6
Урок 2.
Протокол ICMPv6
Протокол DHCP
Урок 3.
Протокол DHCP (продолжение)
Урок 4.
Протокол DNS
Урок 5.
Введение в динамическую маршрутизацию
Протоколы маршрутизации RIPv1, RIPv2 и RIPng
Урок 6.
Протокол маршрутизации EIGRP
Урок 7.
Протокол маршрутизации OSPF
Урок 8.
Основы VPN
Образы IOS и лицензирование
Урок 9.
Протокол маршрутизации BGP
Урок 10.
Оптимизация маршрутизации
Экзамен
Урок 1
Адресация и продвижение пакетов в IPv6
Недостатки протокола IPv4. Главный недостаток – недостаточное адресное про-
странство, причина проблем – короткий адрес. Повторить известные студентам
методы борьбы с недостаточным количеством адресов: CIDR, использование при-
ватных адресов и NAT. Текущее положение дел со свободными IPv4 адресами,
необходимость полноценно решать проблему недостатка адресов. Краткий обзор
прочих недостатков IPv4: необходимость расчета контрольной суммы при пере-
направлении пакетов, поддержка фрагментации на маршрутизаторах.
Новый протокол третьего уровня на замену IPv4 как полноценное решение
проблем IPv4, краткие характеристики IPv6. Новый адрес, длиной 128 байт, упро-
щенный заголовок, не требующий изменения при маршрутизации пакета. Новая
стратегия присвоения публичных IPv6 адресов, позволяющая избегать трансля-
ции и использовать публичные адреса везде, где это необходимо без ограничений.
Важно подчеркнуть, что меняется только IP, протоколы tcp и udp не меняются,
хотя использование нового протокола на третьем уровне в любом случае должно
поддерживаться. Также ясно, что меняются протоколы, напрямую связанные с IP,
а именно icmp, протоколы маршрутизации и пр.
Подчеркиваем, что сегодня крайне важно изучать IPv6 не менее подробно, не-
жели IPv4, так как, с одной стороны, инфраструктура IPv4 еще будет существовать
значительное время, а с другой стороны активное использование IPv6 неизбежно.
Рассказать о том, как будет построено дальнейшее обучение: все технологии тре-
тьего уровня мы будем изучать одновременно и для IPv4 и для IPv6. Для этого нам
необходимо перед изучением протоколов маршрутизации изучить относительно
IPv6 весь круг вопросов, которые мы изучили ранее для IPv4, а именно: структура
адреса, номер узла и номер сети, продвижение пакетов в IPv6 сети, разрешение
IPv6 адресов в адреса канального уровня, заголовок протокола IPv6, протокол
ICMPv6, принципы назначения адресов, использование ACL, туннелирование.
После того, как эти темы будут изучены, мы приступим к изучению основ дина-
мической маршрутизации, при этом будем сразу изучать динамическую маршру-
тизацию как в IPv4, так и в IPv6 сетях.
Понятие об IPv6 адресе, адрес как 128-и разрядное число. Отказ от точечно-
десятичной формы записи адреса, запись адреса в 16-и разрядной форме в виде
пар байтов, разделенных двоеточием. Сокращенные формы записи IPv6 адреса:
удаление ведущих нулей в двухбайтовых блоках, использование символа :: для за-
мены одной или нескольких нескольких групп 0000. Использование префиксной
записи (/xy) для указания диапазона адресов. Самостоятельная работа, посвящен-
ная записи ipv6 адресов.
Типы IPv6 адресов: unicast, multicast, anycast. Отсутствие широковещания

в принципе, замена широковещания на групповую адресацию как на более управ-
ляемый инструмент. Очень кратко об anycast адресах, только идея.
Unicast адреса. Три вида unicast адресов: Global Unicast, Unique Local Unicast
и Link Local Unicast.
Начинаем с привычного Global Unicast адреса. Эти адреса подобны обычным
публичным IPv4 адресам, т. е. назначаются централизовано в цепочке IANA-RIR-
LIR-Customer и однозначно идентифицируют интерфейс в Интернет, при этом,
в отличие от публичных IPv4 адресов, недостатка в Global Unicast адресах нет.
Отмечаем, что для данных адресов не выделен специальный диапазон, ВСЕ адреса,
не выделенные для других целей являются Global Unicast адресами (а диапазоны,
выделенные для других целей мы изучим ниже). Также отмечаем, что в данный
момент IANA выделяет RIR-ам адреса из диапазона 001/3 (в двоичной форме),
поэтому применяемые в данный момент Global Unicast адреса принадлежат диа-
пазону 2000::/3, минимальный адрес 2000::, максимальный 3FFF:FFFF:FFFF:FFF
F:FFFF:FFFF:FFFF:FFFF (показываем это с помощью двоичной формы записи).
Особо подчеркнуть, что несмотря на то, что в данный момент выдаются только
адреса из диапазона 2000::/3, ВСЕ адреса, не выделенные для других нужд являются
Global Unicast адресами и могут быть использованы IANA в дальнейшем. Тут же
говорим о структуре адреса, говорим о том, что rfc4291 требуется, чтобы в Global
Unicast адресах, часть адреса, отвечающая за номер хоста имела длину 64 бита (за
исключением Global Unicast адресов, начинающихся с 000/3, в таких адресах часть
адреса, отвечающая за номер узла не определена стандартом на данный момент),
таким образом хосты должны получать адрес с префиксом /64 (в IPv6 не говорят
«маска»). Говорим о том, что рекомендуется генерировать Interface ID (часть, от-
вечающую за номер узла) с помощью стандарта EUI-64, о котором речь пойдет
ниже, однако возможно назначать Interface ID и другим способом. Приводим
примеры Global Unicast адресов. Структура Global Unicast адреса: Global Routing
Prefix, назначаемый провайдером, Subnet ID, Interface ID. Устаревший подход к на-
значению IPv6 адресов (rfc3177), в котором провайдерам рекомендовалось давать
клиентам типично /48, из которых клиент мог использовать 16 бит на номер под-
сети, при этом также разрешалось давать клиенту /64 если точно известно, что
у клиента одна и только одна сеть, также допускалось давать клиенту /128, если
точно известно, что у клиента только один узел. Новый подход (rfc6177): не вы-
давать клиенту /128, давать клиенту как минимум /64, при этом нет требования
выдавать всем без разбору /48, рекомендовано выдавать клиенту столько адресов,
сколько ему нужно с учетом потребности в росте. Распределение адресов для LIR
(ripe589). Каждый LIR может получить в свое распоряжение /32, при необходимо-
сти, без специальных подтверждений LIR может получить до /29, более крупные
блоки LIR может получить, только предоставив подтверждение необходимости
таких крупных блоков адресов.
Unique Local адреса, рассказываем, что они предназначены для организации

адресации в сети, которая не подключена к Интернет, данные адреса не должны
маршрутизироваться в Интернет и являются аналогом приватных IPv4 адресов
с соответствующей областью применения. Для данного типа адресов выделен диа-
пазон 1111110/7 (в двоичном виде), FC00::/7 в привычной IPv6 записи При этом
данный диапазон делится на две части 11111100/8 (FC00::/8), которая зарезервиро-
вана для будущего применения, и 11111101/8 (FD00::/8), которая предназначен для
локально назначенных адресов, т. е. по-сути именно диапазон FD00::/8 и должен
использоваться в IPv6 для приватной адресации. Отметить, что необходимость
в приватной адресации в IPv6 вследствие избыточности адресного пространства не
является столь востребованной, как в IPv4. Структура Unique Local адреса: Prefix,
бит L, 40 бит Global ID, 16 бит Subnet ID, 64 бита Interface ID. Требования к гене-
рации Global ID (случайное число, полезно если потом сети с такими адресами
будут объединены). Также отметить, что на ранних этапах развития IPv6 вместо
Unique Local адресов предлагались использовать Site Local адреса из диапазона
FEC0::/10, однако в данный момент эти адреса считаются устаревшими.
Последний тип, Link Local адреса. Сперва поясняем, что в отличие от IPv4,
где у интерфейса типично был только один unicast адрес (хотя возможны и ис-
ключения), в IPv6 у интерфейса может быть много адресов, в частности у любого
интерфейса обязательно должен быть один Link Local адрес. Поясняем, что дан-
ный адрес, как следует из названия, имеет смысл только в рамках одного линка,
и крайне активно используется, например узлы в качестве шлюза по-умолчанию
используют именно Link Local адрес, а не Global Unicast / Unique Local. Эти адреса
играют значительную роль в работе IPv6, практически все коммуникации, свя-
занные с обменом данными в одной сети, используют именно Link Local адре-
са. Поясняем, что аналогом Link Local адресов в IPv4 являются APIPA адреса
(169.254.0.0/16), однако в IPv4 такие адреса использовались крайне ограниченно,
при невозможности использовать другие методы адресации, а в IPv6 такие адре-
са используются постоянно, не не ВМЕСТО других типов адресов, а ВМЕСТЕ
с другими типами адресов. Подробно использование Link Local адресов мы будем
изучать далее в курсе, пока рассмотрим выделенный для этих адресов диапазон:
11111110 10/10 (FE80::/10). Струкрутра Link Local адреса: префикс, длиной 10 бит,
54 бита нулей и 64 бита Interface ID, принципы назначения Interface ID.
Описанный в RFC4291 метод генерации модифицированного EUI-64, реко-
мендованный для назначения Interface ID в том случае, если для у интерфейса
есть МАС адрес, способ, описанный в RFC4941 для генерации Interface ID для
интерфейсов прочих типов (Serial, Tunnel etc).
Мультикаст адреса. Подчеркнуть, что мы до сих пор не встречались с мульти-
каст адресами в IPv4, хотя при изучении динамической маршрутизации уже в этом
курсе с ними встретимся, до сих пор мы обходились broadcast/limited broadcast
адресами там, где было необходимо передавать данные неизвестному заранее
получателю. В IPv6 нет broadcast/limited broadcast адресов, поэтому любая пере-

дача данных узлу с неизвестным заранее адресом или нескольким/всем узлам
одновременно требует использования мультикаст. Поэтому нам необходимо на
данном этапе, прежде чем мы начнем изучать любое взаимодействие в IPv6, по-
знакомиться с мультикаст адресами. Для начала рассмотрим мультикаст адреса
в IPv4 (все равно скоро понадобится, при изучении динамической маршрутиза-
ции), а потом рассмотрим мультикаст адреса в IPv6.
Мультикаст адреса в IPv4. Напоминаем диапазон адресов (224.0.0.0/4), напоми-
наем, что в таком адресе нет номера сети и номера узла, такой адрес в целом пред-
ставляет собой номер группы. Классификация IPv4 мультикаст адресов (rfc5771):
Local Network Control Block (224.0.0.0/24), хорошо известные адреса, действующие
только в пределах линка, важные адреса из этого блока (224.0.0.1, 224.0.0.2, 224.0.0.5,
224.0.0.6, 224.0.0.9, 224.0.0.10); Internetwork Control Block, хорошо известные адреса,
которые могут маршрутизироваться, кратко о других блоках адресов. Передача
пакетов с мультикаст адресами на канальном уровне в локальных сетях, неэф-
фективность передачи таких пакетов в широковещательных кадрах канального
уровня, использование мультикаст МАС адресов. Вспомнить мультикаст МАС
адрес, задача о мэппинге IPv4 мультикаст адреса в мультикаст МАС адрес. Метод
мэппинга, коллизии при мэппинге, примеры адресов, вызывающих коллизии,
вероятность коллизий.
Мультикаст адреса в IPv6. Диапазон адресов 11111111/8 (FF00/8), выделен-
ный для мультикаст адресов. Общий формат IPv6 мультикаст адреса: префикс
11111111, поле flags, поле scope, 112 бит для номера группы. Отмечаем, что биты
R,P мы пока игнорируем. Понятие о скопе (области действия мультикас адреса),
используемые скопы: Interface-Local (не выходит в провод), Link-Local (не покидает
линка), Admin-Local (минимальный административно конфигурируемый скоп),
Site-Local (покрывает сайт), Organization-Local (покрывает сеть организации),
Global – охватывает Интернет. Типично используемые мультикаст адреса: FF02::1,
FF02::2. Передача IPv6 мультикаст на канальном уровне, мєппинг IPv6 адресов
в канальные мультикаст адреса, коллизии.
Anycast адреса. Общая идея таких адресов, примеры задач, когда пакет нужно
доставить любому из некоторой группы узлов (привести пример с сервером имен).
Отметить, что такие адреса есть и в IPv4, хотя это особо не декларируется. Отме-
тить, что в IPv6, (как, по-сути и в IPv4) такой адрес – это самый обычный Unicast
адреса (Global или Unique Local). Однако отметить, что в IPv6 при назначении
такого адреса интерфейсу сообщают, что данный адрес является anycast адресом.
Пример anycast адреса: Subnet-Router anycast адрес: Префикс сети + Interface ID
заполняется нулями, получается адрес всех маршрутизаторов в некоторой сети.
Отметить, что помимо первого адреса, последние 128 адресов в каждом сетевом
префиксе зарезервированы за anycast адресами.
Особые IPv6 адреса (rfc6890). Неопределенный адрес ::/128, адрес loopback

::1/128. Отметить, что в отличие от IPv4 адрес, составленный из номера сети и ну-
лей вместо Interface ID не является запрещенным для назначения, более того, ис-
пользуется в качестве Subnet-Router Anycast; адрес, составленный из номера сети
и единиц не является широковещательным, а, как было сказано выше, вместе
с другими 127 старшими адресами, является зарезервированным anycast адре-
сом. Отметить, что в IPv6 другие адреса (чаще всего из диапазона Global Unicast),
имеющие особый смысл, чаще всего эти адреса фиксировано используются для
реализации какой-то технологии, при знакомстве с соответствующими техноло-
гиями мы будем знакомится с этими адресами.
Общий итог по адресам в IPv6. Подчеркнуть, что каждый интерфейс обяза-
тельно должен иметь один Link-Local адрес, а также произвольное количество
(включая нуль) других типов unicast/anycast адресов, включая возможность на-
значения нескольких адресов из одного диапазона (при необходимости). Помимо
этого каждый интерфейс должен ассоциировать себя с группой FF02::1 (все хосты
линка), а также может ассоциировать себя с одним/несколькими другими груп-
повыми адресами. Еще раз подводим итог в вопросе назначения Global Unicast
адресов, назначение адресов LIR-ам, назначение адресов клиентам, назничение
адресов в сетях клиентов.
Назначение IPv6 адресов интерфейсам маршрутизатора Cisco. Важно отметить,
что в настоящее время в IOS по умолчанию отключена IPv6 маршрутизация и от-
ключен IPv6 на интерфейсах. Включение IPv6 на интерфейсе с помощью явного
задания IPv6 адреса. Ручное назначение Link Local адреса, ручное назначение
Global/Unique Local адреса, автоматическое назначение Link Local адереса при
настройке Global/Unique Local unicast адреса. Включение IPv6 на интерфейсе с по-
мощью команды ipv6 enable, автоматическая генерация Link Local адреса в этом
случае. Отсутствие необходимости в команде ipv6 enable при явном указании IPv6
адреса на интерфейсе. Примеры настройки адресов на интерфейсах.
Продвижение пакетов в IPv6. Начинаем с локальных коммуникаций, рас-
сматриваем передачу пакетов в одной сети Ethernet. Как узлы узнают, в одной ли
они сети с получателем пакета. Необходимость разрешения IPv6 адреса в MAC
адрес. Особо подчеркнуть, что такое разрешение необходимо, несмотря на то, что
Interface ID часто генерируется на основании MAC адреса. Необходимость в про-
токоле, эквивалентном ARP в IPv4. Отсутствие ARP в IPv6, замена его функций
протоколом ICMPv6. Введение в Neighbor Discovery, сообщения NS и NA. Общий
формат ICMPv6 сообщений, поля Type, Code, Checksum. Структура поля Type,
сообщения об ошибках и информационные сообщения.
Сообщение типа NS, (тип 135) выполняющее, по-смыслу, функции, анало-
гичные ARP запросу. Формат сообщения. С помощью какого обратного адреса
могут посылаться такие сообщения (:: и unicast), в каких случаях применяется
какой обратный адрес. На какой адрес могут посылаться сообщения на каналь-
ном и сетевом уровне. Неэффективность отправки таких сообщений с помощью

канального broadcast, использование multicast, связанного с искомым адресом так,
чтобы на канальном уровне фрейм получило минимальное количество получате-
лей, в идеальном случае – один. Невозможность отправить unicast IPv6 пакет во
multicast фрейме канального уровня, solicited-node multicast адрес и его мэппинг
в канальный адрес. Возможность оправки сообщений NS с помощью L2/L3 unicast
при необходимости. Опция Source Address, включаемая в пакет, запрет на исполь-
зование опции при отправке пакета с неопределенного адреса.
Пакет NA (тип 136), выполняющий по-смыслу, функции, аналогичные ARP
ответу. Формат пакета, флаги R/S/O, применение опции Target Address для пере-
дачи ответа на заданный вопрос.
Сценарии использования сообщений NS/NA: разрешение IPv6 адреса соседа
в канальный адрес (NS отправляется с unicast адреса мультикастом, свой Source
Address включается в запрос, ответ приходит unicast и содержит Target Address,
таким образом узлы обменялись сведениями о своих MAC адресах); проверка
дублирования адреса при старте, аналог gratuitous ARP (NS отправляется с ::,
свой Source НЕ включается), ответа типично не должно быть, если он есть, то
отправляется мультикастом); объявление своего МАС адреса с помощью NA без
предварительного NS после проверки адреса на отсутствие дубликатов. Команда
show ipb6 neighbor.
Как происходит старт интерфейса с включенным IPv6. Последовательная
проверка на дублирование ВСЕХ unicast адресов, объявление их с помощью NA,
объявление с помощью NA всех anycast адресов БЕЗ предварительной проверки.
Демонстрация работы сообщений типа NS/NA для разрешения адресов и для
проверки адреса на дубликаты. Отметить, что технолгия ND еще не изучена нами
полностью, мы лишь рассмотрели ее часть, без которой нельзя дальше рассматри-
вать передачу IPv6 пакетов, ниже мы вернемся к детальному изучению ND.
Продвижение IPv6 пакетов в маршрутизируемой среде, полная аналогия с про-
движением IPv4 пакетов за исключением использования ND вместо ARP.
Демонстрация: разрешение ipv6 адреса в МАС, проверка дубликатов адресов.
Статические маршруты в IPv6. Возможность использоваться в качестве адре-
са next-hop как Global/Unique Local адреса, так и Link-Local адреса. Предпочти-
тельное использование Link-Local адресов, примеры конфигурации статических
маршрутов.
Протокол IPv6
Повторяем, какие функции выполнял протокол IPv4 и какие поля в заголовке для
этого были предусмотрены. Анализ функций, которые являются лишними или
редко используемыми. Контрольная сумма как безусловно вредная функция заго-
ловка, фрагментацией как редко используемая функция. Ограничения, связанные
с недостаточной длиной поля «опции» в ряде случаев.
Изменения в IPv6 заголовке относительно IPv4. Полный отказ от контрольной

суммы заголовка. Отказ от опций, переход к концепции следующего заголовка
(вместо поля Protocol), который может быть как протоколом верхнего уровня, так
и расширителем функций IPv6.
Поля заголовка IPv6: version, traffic class, flow label, Payload Lenght, Next Header,
Hop Limit, Source address и Destination address. Сравнение заголовка IPv6 и IPv4,
удаленные из заголовка функции добавленные функции.
Демонстрация работы всех полей заголовка IPv6 в анализаторе протоколов.
Концепция IPv6 Extension Headers, способ формирования пакета с расширени-
ями, формирование цепочки расширений. Кто обрабатывает расширения: почти
всегда конечные получатели и в некоторых случаях промежуточные маршрутиза-
торы. Описываем возможные расширения: Routing (возможность осуществлять
маршрутизацию от источника), Fragment – возможность фрагментировать па-
кеты, это расширение обрабатывается только на конечном узле и не затрагивает
работу маршрутизаторов, Hop-by-hop options – возможность передать какую-то
информацию всем промежуточным маршрутизаторам, destination option – воз-
можность передать какую-то информацию узлу получателю, а также расширение
для аутентификации содержимого пакета и расширение, связанное с шифровани-
ем содержимого пакета. Отмечаем, что все вопросы, связанные с безопасностью
и шифрованием мы в этом курсе не затрагиваем, поэтому у нас остается 4 рас-
ширения.
Сперва рассматриваем Hop-by-hop и destination опции. Отмечаем, что формат
заголовка расширения идентичен, отличия только в том, кто будет анализировать
расширение: все маршрутизаторы и конечный получатель или только конечный
получатель. Поясняем, что данные расширения САМИ ПО СЕБЕ ничего не делают,
а лишь позволяют передать всем или только конечному получателю некоторую
дополнительную информацию с помощью опций, описываемых с помощью TLV
формата. Рассказываем о порядке анализа опций в расширениях, о способе об-
работки неизвестных опций в зависимости от значения первых двух бит в поле
Option Type. Описываем известные опции Pad1 и PadN, которые могут приме-
няться в обоих расширениях. Опция Jumbo Payload – возможность передавать
IPv6 пакеты размера, большего нежели 65535 байт. Применение опции только
в Hop-by-hop расширении. Формат опции, значение поля Payload Lenght в IPv6
заголовке при использовании этой опции в Hop-by-hop расширении.
Кратко о расширении Routing. Формат из rfc1883, поля заговка. Единственный
определенный тип маршрутизации 0, обеспечивающий мягкую, строгую и сме-
шанную маршрутизацию от источника (с помощью поля Strict/Loose Bit Map).
Новый формат расширения из rfc2460, удаление битовой карты, толко мягкая
маршрутизация. Полное удаление маршрутизации типа 0, описанное в rfc5095,
фактически расширение Routing все еще существует, но никакой маршрутиазции,
на которую оно могло бы указывать, не описано.
Расширение, предназначенное для фрагментации. Отметить, что фрагментация

выполняется ТОЛЬКО узлом отправителем, маршрутизатор не фрагментирует ни-
когда, вместо этого он уничтожает пакеты, которые не могут быть переданы из-за
mtu. Формат расширения, поля ID, Offset, M bit. Использование этих полей, ана-
логичное таковому в IPv4. Фрагментируемая и нефрагментируемая части пакета,
необходимость сохранаять расширения hop-by-hop и Routnig во всех фрагментах,
формирование фрагментированного пакета.
Порядок следования расширений, обратить внимание на расширения в случае
наличия расширения Routing и особо рассмотреть простой вариант, при котором
расширение Routing не используется (так бывает намного чаще и в этом случае
все намного проще и понятнее).
Демонстрация работы расширений на практике. Подведение итогов: сравнение
протоколов IPv4 и IPv6.
Лабораторная работа для закрепления ipv6 заголовка и расширений.
Урок 2
Протокол ICMPv6
Общие рассуждения о необходимости ICMPv6 на примере изученного ранее
ICMPv4. Анализ сообщений icmpv4, обсуждение того, какие возможности icmpv4
должны быть обязательно реализованы в ipcmv6. Повторение общего формата
ICMPv6 заголовка, сообщения об ошибках и информационные сообщения.
Сообщения об ошибках типа 1, недостижимость получателя. Подчеркнуть,
что аналогичное сообщение есть и в icmpv4. Формат сообщения, цитирование
всего пакета, вызвавшего ошибку, если это позволяет mtu. Коды, используемые
в сообщении о недостижимости. Код 0, указывающий на отсутствие маршрута
к получателю, аналог host unreachable в ICMPv4. Код 1, указывающий на админи-
стративный запрет на коммуникации, причина – фильтрация пакетов на тран-
зитном маршрутизаторе. Код 2, выход за рамки скопа адресов. Пример ситуации,
когда узел у которого есть только Link Local адрес может обмениваться пакетами
с Global Unicast адресом в том случае, если они находятся в одной канальной сетои.
Попытка обмена с Link Local к Global Unicast адресу, при которой пакет должен
пересечь маршрутизатор, генерация сообщения об ошибке. Код 3, недостижимость,
которая не может быть описана другими кодами, например невозможно разрешить
L3 адрес следующего маршрутизатора в L2 или иные специфические проблемы
линка. Отметить, что маршрутизаторы cisco не посылают таких сообщений. Код 4,
отсутствие слушателя транспортного протокола, которые не умеет сам сообщать
о таких ошибках (типично udp). Код 5, сообщающий более детальную информа-
цию, нежели код 1, а именно запрет коммуникаций с данным source адресом. Код
6, уведомляющий, что пакеты к данному получателю на маршрутизаторе отбра-
сываются. Отметить, что rfc говорит о том, что данный код уточняет сообщение
типа 1 (об административном запрете), однако в IOS этот код скорее уточняет
сообщение типа 0, данный код отправляет в случае, если маршрут к получателю
лежит через интерфейс null.
Отметить, почему нет сообщения, аналогичного Protocol Unreachable – эта
функциональность реализована в сообщении Parameter Problem, о котором речь
пойдет ниже. Отметить, почему нет сообщения о недостижимости вследствие
того, что пакет слишком велик.
Сообщение типа 2, слишком большой пакет. Подчеркнуть, что аналогичное
сообщение есть и в icmpv4. Подчеркнуть, что в IPv4 пакеты МОГЛИ не фрагмен-
тироваться маршрутизаторами при установке флага DF, и тогда соответствующее
icmp сообщение позволяло реализовать технологию path mtu discovery. В IPv6
маршрутизаторы никогда не фрагментируют пакет, поэтому данная технология
работает всегда для любых пакетов и обеспечивается рассматриваемым icmpv6
сообщением. Формат пакета, поле mtu, отметить, что такое сообщение нужно
посылать даже в ответ L2/L3 мультикаст.
Сообщение типа 3, Time Exceeded Message. Подчеркнуть, что аналогичное
сообщение есть и в icmpv4 и данное сообщение полностью повторяет его функ-
циональность. Формат сообщения. Два кода, сообщающие что время истекло при
транзите (Hop Limit достиг нуля) и при сборке (за заданное время из фрагментов
не удалось собрать пакет).
Сообщение типа 4, Parameter Problem. Подчеркнуть, что аналогичное со-
общение есть и в icmpv4. Формат сообщения, поле указатель. Сообщение с кодом
0, общая ошибка, без особой детализации, отправляется когда нельзя послать
сообщение с кодами 1 или 2. Например, если при сборке пакета из фрагментов,
фрагменты не имеют кратности 8 байт, то такой пакет должен быть уничтожен,
и отправителю послано icmpv6 сообщение типа 4 с кодом 0. Код 1, неизвестен
Next Header в IPv6 заголовке. Код 2, неизвестная опция в расширениях Hop-by-
hop/destination options. В зависимости от значения первых двух битов типа опции,
пакет может обрабатываться дальше (00), должен быть молча уничтожен (01),
должен быть уничтожен с отправкой рассматриваемого сообщения (10), должен
быть уничтожен с отправкой рассматриваемого сообщения только если пакет был
послан unicast (11).
Информационные сообщения эхо-запрос и эхо ответ, типы 128/129. Формат
сообщения, поля Identifier и Sequence Number, аналогичные таковым в ICMPv4.
Необходимость отвечать на unocast, multicast и anycast запросы, выбор адреса,
к которого посылается ответ в зависимости от того, на какой адрес был получен
запрос.
Демонстрация работы всех рассмотренных ранее сообщений. Следует начать
с сообщений типа 128/129, так как эти сообщения будут полезны для всех прочих
демонстраций.
Затем демонстрируем сообщения о недостижимости простой топологии: хост

отправляет пакет к маршрутизатору, у которого в таблице маршрутизации нет
соответствующего маршрута. После этого демонстрируем сообщение с кодом 1,
для этого кратко знакомим студентов с созданием и применением в качестве па-
кетного фильтра ipv6 ACL. Сразу после этого демонстрируем работу сообщения
с кодом 5, изменив ACL так, чтобы коммуникации были запрещены для данного
адреса источника, а затем демонстрируем работу сообщения с кодом 6, для этого
убираем ACL и создаем маршрут через интерфейс null0.
Демонстрируем сообщение с кодом 2, для этого убираем у интерфейса узла все
адреса, кроме link-local, после чего инициируем обмен пакетами с Global Unicast
адресом соседнего маршрутизатора (коммуникации возможны) и удаленным
Global Unicast адресом (коммуникации невозможны).
Демонстрируем, что маршрутизатор Cisco не возвращает сообщение с кодом 3
в том случае, если не может разрешить адрес следующего маршрутизатора, вместо
этого он просто уничтожает пакет.
Отметить, что на этом базовые типы, описанные в rfc4443 рассмотрены, однако
изучение icmpv6 еще не закончено, так как есть еще целый ряд icmpv6 сообщений,
объединенных общим названием ipv6 nd, некоторые из которых мы уже рассмо-
трели (NS и NA), а к изучению остальных переходим.
Напоминаем, что в IPv4 существовала технология irdp, которая опиралась на
два icmp сообщения с типа 9/10 и позволяла сообщить узлам адрес маршрутизато-
ра динамически. Это реализовано и в IPv6, только куда более строго. В IPv6 полу-
чение адреса маршрутизатора с помощью такого подхода является ОСНОВНЫМ
способом конфигурирования маршрутизатора по-умолчанию для узлов, более
того, что помощью указанных icmpv6 сообщений также можно сконфигурировать
и адрес узлу. Сперва поясняем как это работает принципиально, без формата со-
общений RS/RA. Каждый маршрутизатор через определенные интервалы времени
передает сообщения типа RA, в котором заявляет, что он – маршрутизаторы узлы
могут использовать его для отправки пакетов за пределы своей сети, при этом
пакет содержит указание на количество секунд, в течение которых узлы могут
считать маршрутизатор активным после получения такого сообщения. Ожидается,
что маршрутизатор за это время объявит о себе новым сообщением RA, таким об-
разом пока маршрутизатор работает, он будет постоянно обновлять информацию
о себе на узлах. Помимо этого маршрутизатор в сообщении RA объявляет ВСЕ
префиксы, которые настроены на данном интерфейсе (кроме Link Local, там пре-
фикс все равно один на всех и хорошо известен), таким образом узлы, не имеющие
IPv6 адреса могут провести автоконфигурирование IPv6 адреса, взяв указанный
префикс (префиксы) и сгенерировав Interface ID описанным ранее методом. Та-
ким образом сообщения типа RA не только позволяют сконфигурировать узлам
шлюз по-умолчанию, но и IPv6 адрес, чего не было в IPv4. Узел, стартуя, может
дождаться очередного RA от маршрутизатора, но, очевидно, разумнее попросить
маршрутизатор отправить внеочередной RA, для этого есть сообщение RS. По-
нятие о stateless/statefull автоконфигурировании.
Помимо основной функции (автоконфигурировать узлы) сообщения RS/RA
выполняют дополнительную задачу – разрешать IPv6 адреса в MAC адреса (раз-
умеется, в сетях, где это необходимо), так как и узлы и маршрутизаторы включают
в свои RS/RA сообщения свои канальные адреса.
Теперь рассматриваем полный формат пакетов, начинаем с RS. Тип 133, формат
заголовка. Применение опции в icmpv6 пакетах с помощью TLV блоков, един-
ственная разрешенная опция для RS сообщения – Source link-layer address, формат
опции. Отмечаем, что такие пакеты отправляются с неопределенного адреса (если
никакого адреса у интерфейса пока нет) или, типично, с Link Local адреса, а полу-
чатель таких пакетов – multicast адрес FF02::2 – все маршрутизаторы линка. Со-
общение RA, тип 134. Формат сообщения. Поле Cur Hop Limit – способ маршрути-
затору порекомендовать узлу поле Hop Limit для отправляемых в будущем пакетов
(0 – нет рекомендации). Флаги M/O. Поясняем, что несмотря на то, что в IPv6 есть
описываемое сейчас автоконфигурирование (Stateless, пояснить значение термина),
так же поддерживается и привычное в IPv4 конфигурирование с помощью dhcp.
Пояснить назначение флагов, отметить, что пока нас интересуют только нулевые
значения флагов (т. е. только автоконфигурирование, выполняемое с помощью
RA/RS), при изучении dhcpv6 мы рассмотрим использование других значений
флагов и взаимодействие описываемого автоконфигурирования и dhcpv6. Поле
Router Lifetime, возможное нулевое значение поля (отключение маршрутизатора
с объявлением об этом узлам). Про два остальных поля (Reachable/Retrans Time)
пока говорим, что они не связаны с рассматриваемой функциональностью RS/
RA и будут рассмотрены ниже, при изучении технологии Neghbor Unreachability
Detection). Допустимые опции в пакете RA: Source link-layer address (только если
имеет смысл), MTU (должна включаться на линках с переменным MTU, может
включаться и на других линках), Prefix Information – сведения обо всех префиксах,
которые есть на интерфейсе. Формат новых опций, флаги L/A, поля Valid/Preferred
Lifetime (rfc4862) в опции Prefix Information.
Процесс stateless автоконфигурирования узла, необходимо обобщить то, что
было сказано выше при рассмотрении сообщений RA/RS и NA/NS.
Технология Neighbor Unreachability Detection. Для чего нужно отслеживать со-
стояние соседей. Что является достоверной информацией о достижимости соседа,
важность контроля не только принятых пакетов, но двусторонней связи, т. е. сосед
достижим, если об этом говорит протокол верхнего уровня, либо получен NA в от-
вет на NS. Состояния соседа в кеше соседей: INCOMPLETE, REACHABLE, STALE,
DELAY, PROBE, значение каждого состояния, переходы между состояниями.
Сообщения о перенаправлении (тип 137), единственный код. Принцип ра-
боты эквивалентен аналогичному сообщению типа 5 в icmpv4. Формат пакет,
разрешенные опции: Target link-layer address (если известен) и Redirected Header.

Формат опций.
Демонстрация работы технологии nd. Работа сообщений RA/RS, автоконфи-
гурирование узла. Генерация сообщения RA маршрутизатором, анализ пакета.
Получение узлом адреса и маршрута по-умолчанию на основании RA. Настройка
статического адреса на узле, получение узлом маршрута по-умолчанию на осно-
вании RA. Особенности отправки RS в ios для различных настроек интерфейса.
Статическая настройка адреса и маршрута, взаимодействие статического марш-
рута и маршрута, полученного с помощью RA. Базовое понятие об AD, причина
выбора статического маршрута вместо маршрута, полученного с помощью RA.
Поведение интерфейса, на котором дана команда ipv6 enable. Получение сведений
о шлюзе из RA (без ipv6 адреса, исключая link-local). Отправка пакетов за пределы
своей сети в такой ситуации. Настройка флага other на интерфейсе маршутизатора,
поведение клиента, получившего в RA с таким флагом.
Демонстрация работы технологии автоконфигурирования при наличии не-
скольких маршрутизаторов. Выбор маршрутизатора по-умолчанию узлом, при-
оритеты, поведение при равенстве приоритетов. Настройка приоритетов на марш-
рутизаторах.
Демонстрация дополнительных настроек nd. Настройки dad. Настройка от-
правляемых маршрутизатором RA: частота отправки, hop limit, mtu, lifetime.
Демонстрация технологии nud, состояние соседей. Основы использования
debug как инструмента для отладки в ios. Применение debug для изучения работы
технологии nd. Стартовый обмен ns/na, внесение/не внесение записей в таблицу
соседей. Стартовый обмен rs/ra, записи в таблице соседей. Состояния соседей при
обычных коммуникациях, изменения состояний соседей по разлчным причинам,
переходы из отсутствия записи через INCOPMLETE в REACH, из REACH в STALE
по таймауту, из STALE в DELAY и REACH, из STALE в DELAY в PROBE в REACH.
Демонстрация работы технологии перенаправления. Демонстрация формата
пакета, изменений в таблице маршрутизации.
Лабораторная работа по теме icmpv6. Использование эхо-запросов и эхо-от-
ветов. Сообщения destination unreachable с кодами 0, 1, 2, 4, 5, 6.
Лабораторная работа по теме ipcmv6. Сообщение типа 2 в топологии с serial
интерфейсом и измененным mtu. Сообщение типа 3 в двух ситуациях: в топологии
кольцом и неправильной маршрутной таблицей, которая приводит к маршрутной
петле, и в топологии из нескольких последовательной включенных маршрутизато-
ров с помощью утилиты traceroute. Технология nd. Сконфигурировать одно устрой-
ство как маршрутизатор, а второе как хост с заданным адресом, проанализировать
обмен RA/RS. Технология nud. Два хоста, переходы между всеми состояниями:
из DELETE в REACH, из REACH в STALE, переходы STALE->DELAY->REACH
и STALE->DELAY->PROBE->REACH. Изучение реакции на unsolicitated NA и на
unsolicitated RA. Задание на redirect, простая топология, в которой маршрутиза-
торы применяют редиректы, анализ трафика, анализ поведения узлов.
Прежде чем двигаться дальше, вспоминаем, что при изучении IPv4 мы из-
учили некоторое количество дополнительных технологий, помимо адресации,
маршрутизации, заголовка и icmp. Проводим краткое рассмотрение аналогичных
тем для IPv6.
Назначение нескольких адресов на интерфейсе, локальная маршрутизация.
Отметить, что данная функциональность в IPv6, а отличие от IPv4 применяется
типично, возможность использования link-local адреса шлюза по-умолчанию, во-
обще не привязанного к применяемым схемам адресации.
Подключение узла несколькими интерфейсами к одной сети – никаких от-
личий от IPv4, очень кратко, только напомнить выводы.
Настройка адресов интерфейсов из различных IPv6 сетей в одной канальной
сети с указанием себя как шлюха по-умолчанию, полная аналогия с IPv4, только
выводы.
Адресация в сетях точка-точка: подчеркиваем, что для таких линков есть осо-
бенности в настройках, которые будут продемонстрированы в следующей демон-
страции.
Провести демонстрацию: два соединенных маршрутизатора, к каждому под-
ключено по одной сети, в каждой по одному узлу. Сконфигурировать сеть в стиле
IPv4: на каждом интерфейсе маршрутизатора указан Global Unicast IPv6 адрес, на
узлах настроены статические IPv6 Global Unicast адреса и статически же настрое-
ны Global Unicast адреса шлюзов по-умолчанию. На маршрутизаторах настроены
статические маршруты к удаленным сетям через Global Unicast адрес соседних
маршрутизаторов. На этой топологии необходимо показать, какие новые возмож-
ности дает IPv6 для конфигурирования сети.
Сперва настраиваем на маршрутизаторах маршруты, проходящие через соседей
с помощью link-local адресов, это дает возможность сделать настройку маршрутов
независимой от адресации на линке между маршрутизаторам, более того, это дает
возможность вообще не использовать между маршрутизаторами, соединенными
точка-точка линком, никаких Global Unicast адресов. Удаляем с соответствующих
интерфейсов маршрутизаторов Global Unicast адреса (не забываем про ipv6 enable
на соответствующем интерфейсе, в противном случае интерфейс не сможет рабо-
тать с IPv6). Продемонстрировать, что коннективность между узлами сохранилась,
после чего обсуждаем, как теперь маршрутизатор сможет отправить destination
unreachable с интерфейса, на котором нет никакого Global Unicast адреса, перена-
страиваем соответствующие интерфейсы в качестве unnumbered, демонстрируем
коннективность и работоспособность traceroute.
Убираем маршруты по-умолчанию с хостов, соответствующие маршруты бу-
дут получены с помощью ipv6 nd, демонстрируем коннективность между узлами.
Убираем явно настроенные адреса с узлов, эти адреса тоже могут быть полу-
чены автоматически, обращаем внимание, что новые адреса будут отличаться от
ранее использованных, снова демонстрируем сохранение коннективности.
Задаемся вопросом: а зачем маршрутизаторам Global Unicast адреса на ин-

терфейсах, направленных в сети с узлами, если узлы используют link-local адреса
маршрутизаторов в качестве шлюзов по-умолчанию? Эти адреса нужны потому,
что они сообщают клиентам те префиксы, в рамках которых клиенты выбирают
себе автоматические адреса.
Положим, что у маршрутизаторов много интерфейсов, за которыми находятся
узлы. Почему в таком случае мы используем конкретный адрес физического ин-
терфейса в качестве указателя unnumbered при настройке интерфейса, смотрящего
на соседний маршрутизатор? Создаем loopback на маршрутизаторах, перекон-
фигурируем интерфейс, смотрящий на соседний маршрутизатор так, чтобы он
использовал адрес loopback в качестве источника собственных пакетов. Снова
демонстрируем коннективность.
Подводим итог: Global Unicast адреса, настроенные вручную сечас есть только
у интерфейсов маршрутизаторов, за которыми находятся узлы.
Теперь попробуем отказаться и от адресов на вышеупомянутых интерфейсах,
отмечаем, что это практической ценности уже не имеет, но полезно для понимания
того, как работает маршрутизация. Для этого придется снова конфигурировать
IPv6 адреса на узлах, но этого мало, нужно еще на маршрутизаторах создать ста-
тические маршруты, указывающие, за какими интерфейсам находятся соответ-
ствующие сети с узлами. Теперь покажем, как отказаться от ручной настройки
узлов в полученной топологии: настраиваем вручную анонс нужных префиксов
за интерфейсами маршрутизаторов, возвращаем автоконфигурирование, демон-
стрируем коннективность между узлами. Подводим итог: теперь у маршрутизато-
ров в топологии только один адрес – на loopback, но теперь каждая сеть с узлами,
которая есть у маршрутизатора должна сопровождаться ручным объявлением
префикса и ручным добавлением маршрута.
Несколько слов о NAT в IPv6, отсутствие NAT для IPv6, наличие NAT для
взаимодействия IPv6 и IPv4, переносим обсуждение этой технологии в профес-
сиональный курс.
ACL для IPv6, тема уже обсуждалась, просто повторяем и обощаем.
Туннели в IPv6. Сразу отметим, что мы только познакомимся с этой темой,
а более детально рассмотрим ее в профессиональном курсе. Круг задач, связан-
ных с IPv6 и туннелями: транспорт IPv6 трафика через IPv4 Интернет, транспорт
IPv4 трафика через IPv6 Интернет, транспорт приватного IPv6 трафика через пу-
бличную IPv6 сеть. Демонстрируем конфигурирование всех трех типов туннелей,
обращаем внимание на анализ трафика в каждом из трех случаев.
Подводим итоги по изученному материалу относительно ipv6. Отмечаем, что
на данном этапе мы изучили адресацию и принципы передачи пакетов в ipv6.
Протокол DHCP
Прикладные протоколы стека tcp/ip, связанные с построением сетей: dhcp и dns,
важность изучения этих протоколов на данном этапе. Повторение модели OSI,
краткое повторение функций физического, канального и сетевого уровней. Модель
tcp/ip, краткое повторение функций уровней, сопоставление уровней моделей.
Функции транспортного уровня модели, примеры реализации транспортного
уровня в реальном мире. Методы, которыми пользуется транспортный уровень –
нумерация передаваемых данных и квитирование. Реализация транспортного
уровня (в модели tcp/ip) двумя протоколами – tcp и udp, области применения
двух протоколов. Задачи, требующие гарантирования доставки и задачи, этого
не требующие. Функции протокола tcp: нумерация передаваемых данных, пред-
варительная установка соединений, передача квитанций и адресация протокола
верхнего уровня; функции udp: адресация протокола верхнего уровня, почему
нельзя передавать данные приложений непосредственно поверх ip. Отметить, что
с точки зрения модели OSI, tcp выполняет функции транспортного и сеансового
уровня, а udp – только одну функцию: адресация протокола верхнего уровня, что
скорее следует отнести к сеансовому уровню. Функции представительского уров-
ня, интеграция функций представительского уровня в приложения стека tcp/ip.
Обзор протоколов различных уровней модели tcp/ip. Уровень межсетевых
интерфейсов, описание способа передачи ipv4/ipv6 пакетов через различные ка-
нальные сети, протокол arp и ipv6 nd (частично) как протоколы уровня межсетевых
интерфейсов. Протоколы сетевого уровня: ipv4/ipv6, icmpv4/icmpv6, протоколы
динамической маршрутизации. Протоколы транспортного уровня, ключевые
протоколы прикладного уровня: ftp, tftp, http, почтовые протоколы. Прикладные
протоколы, решающие задачи, связанные с построением сети: dhcp, dns.
Протокол udp, формат заголовка, функции полей Source Port/Destination Port,
концепции «well known ports» и динамических портов, способ расчета контроль-
ной суммы.
Протокол dhcpv4. Автоматизация конфигурирования узлов на ранних этапах
развития ip сетей, протокол rarp, icmp mask request/reply, irdp. Протокол bootp как
предтеча dhcp – краткий обзор функций. DHCP как развитие bootp, совместимость
dhcp и bootp.
Как узел начинает коммуникации с сервером dhcp: использование адресов
0.0.0.0 и 255.255.255.255 для первичных коммуникаций от клиента к серверу, ис-
пользование транспорта udp. Как сервер отвечает клиенту: использование ши-
роковещания на канальном уровне (особо отметить почему) и ограниченного
широковещания на третьем уровне. Наличие на сервере специально сконфигу-
рированного пула адресов, из которого он предлагает клиентам адреса, дополни-
тельные параметры, выдаваемые клиенту с помощью опций.
Диалог между сервером и клиентом. Пакет Discovery, отправляемый клиентом,

пакет Offer, посылаемый серверами, почему транзакция не может быть закончена
после обмена двумя пакетами. Выбор сервера клиентом, пакет Request. Функции
Request: уведомление сервера, чье предложение принято, уведомление прочих
серверов о том, что их предложение не принято, как достигаются две цели – ши-
роковещание и 68 порт. Необходимость подтверждения запрошенного адреса,
пакет Ack. Поведение клиента после получения адреса: проверка на дубликаты,
уведомление сервера о выдаче недопустимого адреса, пакет Decline. Время аренды
адреса, необходимость для клиента подтверждать продолжение использования
адреса, использование пакета Release. Прочие типы пакетов: NACK и INFORM.
Примеры использование NACK. Классификация всех изученных типов пакетов,
подведение итогов по изученным типам dhcp транзакций.
Демонстрация базовых настроек dhcp сервера в ios, настройка пула, основных
опций пула, настройка клиента, демонстрация базовой транзакции.
Демонстрация изученных типовых транзакций. Сперва демонстрируем по-
лучение адреса без наличия dhcp сервера. Анализ трафика dhcp discovery и по-
ведения узла.
Демонстрируем старт клиента, у которого уже был ранее адрес из той-же сети:
опция, с помощью которой клиент просит себе прошлый адрес, выдача соответ-
ствующего адреса клиенту. Старт интерфейса без предварительно настроенного
прошлого адреса, получение нового адреса от сервера.
Пример транзакции, в которой клиент обновляет адрес с помощью unicast
пакета Request. Пример транзакции, направленной на получение адреса при ус-
ловии, что клиент ранее имел адрес, которая начинается с Request – укороченное
получение адреса клиентом.
Демонстрация транзакции, в которой клиент пытается получить адрес, кото-
рым пользовался ранее из той же сети, но сервер больше не может предоставить
клиенту такой адрес, отправка нескольких discovery, избыточно длительная за-
держка при получении адреса. Тот же пример, но у клиента был адрес из другой
сети, сравнение трафика и задержек.
Демонстрация освобождения используемого адреса с помощью пакета Release
в Windows и ios, отличия в поведении. Демонстрация ситуации, в которой от-
правляется NACK, команда renew deny unknown. Демонстрация ситуации, при
которой отправляется Decline, ведение базы конфликтных адресов в ios. Контроль
дубликатов на стороне сервера и на стороне клиента.
Урок 3
Протокол DHCP (продолжение)
Заголовок dhcp. Поле OPCode, два значения этого поля. Особо отметить, что это
поле наследовано из bootp, в котором было всего два типа пакетов, передача на-
стоящего типа пакета dhcp с помощью опции. Поле htype, hlen. Поле hops, кратко
отметить, что поле имеет смысл только если пакеты пересекают маршрутизаторы,
сейчас не рассматривать. Поле xid, значение этого поля в коммуникациях клиент-
сервер. Поле sec, кратко о назначении данного и коммуникациях, в которых есть
главный и резервный сервер. Поле flags, флаг broadcast, использование данного
флага. Поле ciaddr, применение поля клиентом, когда клиент имеет право запол-
нять данное поле. Поле yiaddr, использование данного поля сервером. Поле siaddr,
область применения данного поля, указание дополнительного сервера для даль-
нейшей загрузки, кратко о процессе загрузки бездисковой станции. Поле giaddr,
отложить рассмотрение этого поля до момента, когда будет изучаться relay. Поле
chaddr, формат поля и способ передать аппаратный адрес серверу от клиента.
Поля sname и file, назначение полей, формат полей. Обсудить, что можно сделать
с помощью заголовка: назначить адрес и параметры для бездисковой загрузки,
остальное делается опциями.
Общий формат опций dhcp, TLV, значения в поле длина. Опции, без длины
и данных: PAD и EOF. Опция Magic Cookie как способ отличить bootp и dhcp пакет.
Классификация опций dhpc: конфигурационные опции (для настройки па-
раметров узлов) и dhcp extension. Сперва рассматриваем dhcp extension. Опция
53 – тип dhcp пакета. Опция 50 – запрашиваемый ip адрес. Опция 51 – время
аренды адреса, недостатки выдачи адреса в бессрочное пользование. Опция 52 –
перегрузка sname/file из заголовка bootp/dhcp. Опция 54 – адрес сервера. Опция
55, Parameter Request List, способ оптимизации коммуникаций между клиентом
и сервером с целью уменьшения объема передаваемой информации. Опция 56,
сообщение, передаваемое в пакете dhcp decline. Опция 57, оговаривание макси-
мального размера пакета, который готов принимать клиент. Опции 58-59, обзор
коммуникаций при продлении срока аренды адреса, выполнение операций renew/
rebind, отличие между процессами renew и rebind. Опция 60, классы вендоров,
пока не рассматриваем. Опция 61, идентификатор клиента, роль опции в комму-
никациях.
Опции, которые предназначены для конфигурирования параметров на узлах.
Классификация конфигурационных опций: первичный набор опций – bootp vendor
extension, прочие опции, сгруппированные по областям применения: L3 пара-
метры для хоста, L3 параметры для интерфейса, L2 параметры для интерфейса,
параметры для tcp, параметры для прикладных протоколов. Рассмотрение всех
конфигурационных опций следует проводить, демонстрируя соответствующие
rfc на экране/проекторе, при этом следует пропускать незначимые опции, а рас-

сматривать только актуальные.
Демонстрация изученного заголовка и опций. Конфигурируем сервер без вся-
ких опций, демонстрируем в анализаторе протоколов обычную транзакцию по-
лучения адреса, в качестве клиента используем Windows, демонстрируем работу
всех полей заголовка и используемые опции во всех пакетах.
Настраиваем опцию, которую клиент готов принимать, демонстрируем пере-
дачу опции клиенту. Конфигурирование опций на dhcp сервере ios в сыром виде,
передача статического маршрута клиенту старым и новым способом.
Демонстрация поведения ios в качестве dhcp клиента. Особенности поведения
ios клиента. Демонстрация dhcp клиента в linux, отличия в поведении.
Демонстрация загрузки удаленной рабочей станции. Для этой демонстрации
необходимо заранее подготовить образ OS, ftp сервер и продемонстрировать на-
стройку dhcp сервера и анализ трафика процесса удаленной загрузки.
Коммуникации между клиентом и сервером через маршрутизаторы. Обзор
задач, в которых такие коммуникации востребованы (сети предприятий и сети
операторов связи). Способ маршрутизации dhcpv4 пакетов. Изменение заголовок
третьего уровня, изменения в заголовке dhcp, использование поля giaddr.
Демонстрация конфигурирования и работы релейного агента на ios. Пример,
в котором один dhcp сервер обслуживает клиентов из двух локальных и двух уда-
ленных подсетей. Анализ трафика между клиентом и релейным агентом, между
релейным агентом и dhcp сервером.
Классы вендоров, пример ситуации, в которой устройству нужно передать
опцию, которая не является стандартной опцией dhcp. Опция 60, опция 43, фор-
мат опции 43. Особо отметить, что опции, передаваемые в поле данных опции 43
не являются обычными dhcp опциями и понятны только тому, кто заявил под-
держку соответствующего класса вендоров с помощью опции 60. Пример опций,
определенных для класса «MSFT 5.0».
Классы пользователей. Конфигурирование различных клиентов с помощью
различных наборов опций. Опция 77, формат опции. Где конфигурируется при-
надлежность к классу пользователей.
Конфигурирование определенным узлам наперед заданных ip адресов. Про-
стой механизм: фиксация ip адреса для определенного МАС адреса, понятие о
резервировании. Неудобство такого подхода в сети оператора, где оконечное
оборудование может произвольно меняться. Опция 82, формат опции. Способ
обработки опции 82 на коммутаторах и dhcp серверах.
Особенности и ограничения настройки пулов адресов в ios с точки зрения
резервирования адресов для клиентов, классов вендоров и классов пользователей.
Отметить недостаточно эффективную структуру пулов в ios (стоит привести при-
мер, который иллюстрирует, как это можно делать ПРАВИЛЬНО), рекомендации
по настройке рассмотренных выше технологий с учетом описанных ограничений.
Демонстрация конфигурирования резервирования адреса для клиента с задан-

ным ClientID, одновременно нужно сконфигурировать пул для обычных клиентов,
без резервирования и продемонстрировать, что опции этого пула наследуются
пулом резервирования. Подчеркнуть, что «пул для абонента» не выглядит как
часть пула, в котором дана команда network в конфигурационном файле, однако
таковой частью является.
Демонстрация поддержки опций вендора в ios. Конфигурирование клиента
как члена класса вендоров, конфигурирование пула на сервере для обслуживания
класса вендоров, выделение поддиапазона адресов, передача произвольной опции
клиенту. Обратить внимание на то, что при наличии в пуле класса с опцией класса
вендоров, узлы, не идентифицирующие себя как члена класса, вообще не полу-
чают адресов, поэтому необходимо создавать дефолтный класс для таких узлов.
Лабораторная работа, посвященная dhcp: один маршрутизатор в качестве
сервера, один в качестве клиента и одна виртуальная машина под управлением
Windows. Выполнить обычную транзакцию, проанализировать трафик. Затем
даем рабочей станции адрес из произвольной сети, возвращаем dhcp, анализи-
руем поведение клиента и трафик. Затем даем рабочей станции адрес из той-же
сети, как и пул, возвращаем dhcp, анализируем поведение клиента и трафик. За-
тем даем рабочей станции адрес из той-же сети, как и пул, но исключенный из
пула, возвращаем dhcp, анализируем поведение клиента и трафик. Сравниваем
поведение клиента для трех последний примеров. Проанализировать транзак-
цию обновления адреса. Проанализировать транзакцию освобождения адреса,
сравнение поведения Windows клиента и ios клиента. Создать ситуацию, в кото-
рой отправляется decline. Сконфигурировать резервирование для конкретного
клиента. Сделать клиента под управлением ios членом класса вендоров, выдать
клиенту произвольную опцию. Смоделировать коммуникации между клиентом,
релейным агентом и сервером, проанализировать трафик. Подключить к серверу
и локальную подсеть, сконфигурировать сервер для обслуживания локальных
и удаленных клиентов.
Dhcpv6. Возможности автоматической настройки, существующие в ipv6, по-
чему тем не менее необходим dhcpv6. Повторяем, как в ipv6 узлы могут получать
адреса и маршрут по-умолчанию с помощью nd, необходимость dhcpv6 как ми-
нимум для того, чтобы получать дополнительные конфигурационные параметры.
Два режима работы dhcpv6: stateless и statefull, почему недостаточно только stateless
режима. Управление режимом, который выбирает узел, с помощью маршрути-
затора, флаги Other и Managed. Поведение узла в зависимости от комбинаций
значений флагов.
Как устроен заголовок dhcpv6 по сравнению с dhcpv4, почему dhcpv6 име-
ет абсолютно новый заголовок. Формат заголовка: тип пакета и идентификатор
транзакции, все остальное передается с помощью опций. Типы пакетов в dhcpv6,
сравнение пакетов dhcpv4 и dhcpv6. Пакет Solicit, задачи, которые выполняет па-
кет. Пакет Advertise как полная аналогия пакета Offer из dhcpv4. Пакет Request,
запрос клиента на получение адреса от конкретного сервера, отличия пакета
Request в dhcpv6 и dhcpv4: данный пакет не используется для операций renew/
rebind в dhcpv6. Пакет типа Reply, использование данного пакета для ответов на
Request, применимость данного пакета и для других целей, в частности для завер-
шения процедур renew/rebind (и не только, об этом ниже). Подытожить базовую
транзакцию из четырех пакетов. Пакет Release, процедура освобождения адреса,
отличия освобождения адреса в dhcpv4 и dhcpv6. Пакет Decline как полная анало-
гия такого-же пакета из dhcpv4, отличие процедуры Decline от dhcpv4, отправка
подтверждения от сервера. Пакет Information-Request как основа работы stateless
процедуры конфигурирования. Транзакция, которую проводят клиент и сервер
для получения дополнительных параметров. Важно пояснить, почему такая тран-
закция может безопасно проводиться в два пакета. Двухшаговая транзакция полу-
чения адреса в dhcpv6, возможность для сервера ответить пакетом Reply в ответ
на Solicit. Согласование такой транзакции между клиентом и сервером, почему
такая транзакция более безопасна, чем в dhcpv4.
Пакет типа Renew, выполнение процедуры renew, ответ сервера на такой пакет.
Пакет типа Rebind, выполнение процедуры rebind, ответ сервера на такой пакет.
Пакет типа Confirm, возможность для клиента проверить существующий адрес
с помощью запроса серверу, ответ на пакет Confirm. Пакет типа Reconfigure, воз-
можность для сервера уведомить клиентов об изменении настроек пула и, тем
самым, инициировать повторное получение параметров клиентами, ответ на пакет
Reconfigure. Кратко о пакетах типа Relay-Forward и Relay-Reply, более подробно о
работе релейного агента в dhcpv6 будет рассказано позже.
Как отправляются пакеты в dhcpv6, используемые серверами и клиентами
адреса и порты: использование link-local и multicast адресов.
Опции dhcpv6. Общий формат опций, структура TLV, использование поля
Lenght. Опции с кодами 1 и 2, идентификация клиента и сервера, формат опций,
способы формирования DUID для различных клиентов. Определение Identity
Assotiation, IAID. Опция 3, IA для постоянных адресов. Запрос адреса в рамках
IA, ответа в рамках IA, возможность для клиента запрашивать несколько адресов
в рамках нескольких IA. Формат опции, формат поля данных. Отметить, что в са-
мой опции нет места для непосредственно адресов, возможность включать опции
внутрь опций, передача адресов клиенту внутри опций, вложенных в опцию 3,
вложенные опции в dhcpv6. Опция 4, IA для временных адресов, отличия в фор-
мате опции. Опция 5, IA-Address, невозможность передать эту опцию в списке
опций dhcpv6 пакета, только внутри поля опций в других опциях (с кодами 3, 4
и др.). Формат опции 5. Возможность передать несколько опций 5 внутри опций
3/4. Возможность передавать опции внутри опции 5, которая сама вложена внутрь
опций 3/4. Опция 13, Status Code, механизм для уведомления клиента о результатах
проведения транзакции сервером. Формат опции. Применимость опции: в самом
dhcpv6 пакете (для общего ответа), внутри опции 5, которая внутри опций 3/4
(для уведомления об операции для данной IA). Опция 6, Request Option, запрос
опций клиентом, полная аналогия с подобной опцией в dhcpv4. Опция 7, Preference,
формат опции, возможность назначать серверам приоритеты и сообщать их кли-
ентам. Опция 8, Elapsed Time, формат опции, полная аналогия с соответствующим
полем в заголовке bootp/dhcpv4. Опции 9 и 11 пока не рассматриваем, поясняем
почему. Опция 12, Server Unicast Option, формат опции, применение опции. Опция
14, Rapid Commit, формат опции, процедура согласования быстрой транзакции
между между клиентом и сервером. Опция 15, User Class, формат опции, полная
аналогия соответствующей опции из dhcpv4. Опция 16, Vendor Class, формат
опции. Отличия в реализации от dhcpv4, поле enterprise number. Опция 17, пере-
дача опций вендора клиенту, формат опции. Опция 18, InterfaceID Option, формат
опции, сравнение с опцией 82 в dhcpv4. Опция 19, уведомление от сервера о том,
с помощью какого сообщения клиент должен получить обновления от сервера.
Опция 20, формат опции. Уведомление о возможности использования Reconfigure
сообщений.
Конфигурационные опции в dhcpv6. Почему в dhcpv6 нет опций для переда-
чи маски и шлюза. Опция 23, сведения о серверах dns, формат опции. Опция 24,
Domain search list. Опции 25/26 кратко, без формата, только понятие о делегиро-
вании префиксов клиенту, более детально об этой технологии потом. Опция 39,
передача клиенту его полного доменного имени. Опции 41/42, различные способы
передать клиенту информацию о временной зоне, опция 56, передача сведений о
сервере времени. Опции 59-62, информация, необходимая для удаленно загрузки,
кратко.
Демонстрация работы dhcpv6. Настройка dhcpv6 клиента на маршрутизаторе
Cisco, команда ipv6 enable, когда необходимо давать такую команду, анализ со-
общений Solicit, анализ используемых адресов и формата пакета. Демонстрация
конфигурирования пула dhcpv6: настройка пула, указание пула на интерфейсе
сервера. Анализ базовой транзакции, формат всех пакетов транзакции, включая
все используемые опции. Демонстрация укороченной транзакции между клиентом
и сервером при поддержке rapid-commit обоими участниками. Взаимодействие
автоконфигурации и dhcpv6. Включение на клиенте автоконфигурирования без
флагом у сервера, демонстрация поведения клиента. Включение на сервере флага
Other, демонстрация поведения клиента, анализ транзакции, опция lifetime. Вы-
ключение Other, включение Managed. Демонстрация поведения клиента из ios
в данной ситуации.
Работа dhcpv6 через маршрутизаторы, сообщения типа Relay-Forward и Relay-
Reply, формат пакетов, анализ коммуникаций. Как сервер понимает, из какого
пула выдавать адреса.
Демонстрация Relay Agent в dhcpv6. Настройка сервера, настройка релейного
агента, анализ трафика до и после релейного агента.
Технология Prefix-delegation. Почему в dhcpv6 необходима данная технология,

область применения технологии. IA for PD, концепция коммуникаций между кли-
ентом и сервером, выдающим клиенту pd, адресация внутренних интерфейсов
клиента с помощью pd адресов.
Демонстрация работы pd. Настройка сервера и клиента, адресация внутренних
интерфейсов маршуртизатора. Анализ трафика, демонстрация опции.
Лабораторная работа, посвященная dhcpv6. Необходимо сконфигурировать
сервер и клиента, в роли клиента тоже выступает маршрутизатор, который по-
лучает помимо адреса еще и pd, который использует для адресации внутренних
интерфейсов. При этом коммуникации между сервером и клиентом должны про-
ходить через релейный сервер.
Урок 4
Протокол DNS
Напоминаем, как происходит обращение к сетевым ресурсам, напоминаем, что
типично пользователь должен указать ip адрес узла, с которым начинает взаи-
модействие (напоминаем, что номера портов запоминать не нужно), отмечаем,
что пользователям неудобно запоминать ipv4 адреса, и совершенно невозможно
запоминать ipv6 адреса, вместо этого пользователям следует запоминать некие
удобные символьные имена. Первый подход к использованию имен – файл hosts.
Способ заполнения этого файла на заре развития ip сетей, способ распространения
этого файла. Подробная критика данного подхода: поддержка файла, сложности
с распространением файла, нагрузка на сервера. Способы применения файла hosts
сегодня, включая злоумышленное ПО.
Обсудить, какие качествами должно обладать актуальное решение: вся база
имен не должна копироваться на рабочие станции, необходимость хранения базы
на специальных серверах, которые с помощью специального протокола смогут
передавать ответы на конкретные запросы клиентам. Невозможность хранения
одной централизованной базы данных, необходимость использования распреде-
ленной базы данных, т. е. подход, при котором различные части базы данных хра-
нятся и поддерживаются на различных серверах. Невозможность использования
плоских имен, особо отметить, что поиск в распределенной базе данных, у которой
данные не структурированы не возможно, использование структурированных,
иерархических имен. Привести пример поиска файла по относительному имени
на диске с помощью перебора всех файлов и поиска файла по полному имени.
Система имен, принятая в DNS. Для примера рассматриваем именование фай-
лов в файловой системе. Относительное имя файла как удобный идентификатор
файла при работе, подчеркнуть, что данное имя не уникально на диске и не позво-
ляет его найти. Папки как контейнеры для хранения файлов, полное имя файла:
данное имя уникально, однозначно идентифицирует файл и позволяет его легко

найти. Структура папок на диске, единственная корневая папка. Сравнение фай-
ловой системы, которая присваивает имена совокупности кластеров, в которых
хранится набор байтов и сопоставляет этой совокупности структурированное имя
и системы имен, которая должна сопоставлять ip адресу структурированное имя,
поиск файла (совокупности его кластеров) в файловой системе начиная с корневой
папки. Теперь на основании рассмотренного примера рассказываем, как устроено
пространство имен DNS и как осуществляется поиск в DNS.
Плоское имя узла (аналог относительного имени файла), определенное в рам-
ках некоторого общего имени «домен имен», а «домен имен» – имя, общее для
группы имен. Полное имя узла как совокупность плоского имени узла и имени
домена. Особо отмечаем, что все доменные имена имеют, (как и имена в файловой
системе) общую часть, имя корневого домена, имя этого домена «.». Приводим при-
мер FQDN, показываем все его части, включая имя корневого домена. Сравнение
имени файла и имени узла, направление, в котором уточняется имя (у файла слева
направо, у FQDN – справа налево). Обратить внимание тот факт, что глядя на до-
менное имя заранее невозможно сказать, что это: FQDN или имя домена имен.
Краткий обзор распределенного хранения данных DNS, хранение имен, при-
надлежащих одному домену на одном сервера, хранение имен, принадлежащих
различным доменам на различных серверах (в нулевом приближении). Поиск
сервера, отвечающего за хранение базы данных определенного домена, поиск со-
ответствующего сервера от корня, аналогия с файловой системой. Роль корневых
серверов в системе имен DNS.
Обзор существующего пространства имен. Невозможность регистрировать
имена в корневом домене, причины. Понятие о доменах верхнего уровня, регистра-
ция имен только внутри доменов верхнего уровня. Обзор применяемых доменов
верхнего уровня, особенности получения имен в различных доменах верхнего
уровня. Принципы, которыми должен руководствоваться клиент, выбирая до-
менное имя. Примеры выбора имен доменов.
Присвоение имен узлов в доменах. Имена для внутреннего использования
(имена серверов, рабочих станций), имена для публичного использования. Обще-
принятые имена узлов (www, ftp etc), условность такого подхода. Использование
«пустого» имени для web серверов вместо «www».
Обзор структуры базы данных DNS. Понятие о типе записи в базе DNS. Обзор
базовых типов записей: A, NS. Особо подчеркнуть, что NS ставит в соответствие
домена ИМЯ сервера имен, а не его адрес. Понятие о glue записях. Типичные от-
веты, которые возвращают сервера верхнего уровня. Разрешение имен с помощью
корневых серверов. Почему клиенты не разрешают имена, обращаясь к корневым
серверам. Использование разрешающих серверов клиентами, преимущества такого
подхода: уменьшение трафика, задержек, возможность кеширования. Поведение
разрешающих серверов: поиск имен через корень или использование других раз-
решающих серверов. Обзор сценариев разрешения имен с использованием раз-

решающих серверов.
Протокол DNS. Транспортные протоколы, используемые для передачи данных
DNS, особенности применения UDP и TCP для передачи данных DNS.
Заголовок DNS. Поле ID, роль. Поле Flags. Флаг QR. Поле Op Code. Флаг AA,
что такое авторитетный ответ. Флаг TC, поведение в случае получения ответа
в флагом TC. Флаг RD. Понятие о рекурсивных и итерационных запросах. По-
ведение сервера, получившего рекурсивный запрос в зависимости от того, готов
ли сервер обслуживать клиента рекурсивно. Флаг RA. Зарезервированные биты,
поле RCODE. Используемые значения RCODE.
Данные DNS пакета как набор из четырех секций: вопросы, ответы, автори-
тетная информация и дополнительные данные, использование какждой секции.
Счетчики, показывающие количество секций в пакете, поля QD Count, AN Count,
NS Count, AR Count.
Секция QD Count. Поля QNAME, QTYPE, QCLASS, назначение полей QTYPE
и QCLASS. Способ передачи данных в QNAME. Разделение имени на labels, от-
деление labels друг от друга.
Формат данных в прочих секциях. Отметить, что формат этих секций оди-
наковый, так как все они, по сути, являются ответами и отличаются только тем,
какие «ответы» переносят. Поле NAME – место, где указывается имя, которое
разрешается. Содержимое поля NAME для каждой из трех секций. Поля TYPE
и CLASS. Поля TTL, RLENGHT и DATA. Назначение поля TTL, использование
данных из поля TTL получателем. Компрессия имен. Почему компрессия полезна,
способ передавать части имен по ссылкам.
Демонстрация, посвященная всему изученному на данный момент материалу.
Сперва рассматриваем пример, в котором клиент разрешает имя с помощью кеши-
рующего DNS сервера. Выбираем имя, которое разрешается просто, без CNAME
(например itstep.org). Анализируем формат пакета, включая изученные поля, ана-
лизируем компрессию данных. Разрешаем несуществующее имя в существующем
домене, анализируем ответ и RCODE. Разрешение имени в несуществующем до-
мене в домене верхнего уровня. Разрешение имени в несуществующем домене
в корне. Разрешение имени, которое является CNAME (например www.microsoft.
com), анализируеdomoм разрешение имени сквозь цепочку псевдонимов.
Демонстрация работы кеширующего сервера. Для проведения демонстрации
необходимо установить в сети DNS сервер, который обращался бы к корневым
серверам для разрешения имен. Для начала рассматриваем простой пример, ко-
торый демонстрирует разрешение имени без особенностей (например cnn.com).
Обратить внимание на записи о корневых серверах в секции авторитетной инфор-
мации и дополнительных записей. Необходимо проследить весь процесс разреше-
ния имени, который проводит кеширующий сервер, обслуживая клиента. Затем
демонстрируем более сложный пример, в котором кеширующий сервер вынужден
приостановить процесс разрешения искомого имени для того, чтобы разрешить

адреса промежуточных сервером имен из-за отсутствия glue записей (например,
itstep.org). После этого демонстрируем сложный пример, в котором разрешаемое
имя оказывается CNAME, например (www.microsoft.com).
Типы записей в базе dns. Общий формат RR в заголовке dns, значения полей
NAME и RDATA для каждого типа RR. Запись типа А, формат RDATA. Запись типа
NS, значения полей NAME/RDATA, особо обратить внимание, что запись ставит
в соответствие имени домена ИМЯ сервера имен, но не его ip адрес. Запись типа
CNAME, значения полей NAME/RDATA. Запись типа SOA, предназначение этой
записи. Формат поля NAME и поля RDATA, формат RDATA должен быть изучен
подробно, включая номер зоны и все временные парЗапись типа HINFO, краткое
описание и формат RDATA.аметры (пока детали трансфера зоны не обсуждаем, но
введение в концепцию трансфера проводим). Запись типа TXT, краткое описание
и формат RDATA. Запись типа MX, очень кратко о доставке почты, роли почтового
сервера и способе обнаружения почтового сервера, формат полей NAME и RDATA.
Обсудить, можно ли подобным способом обнаруживать различные иные службы,
обсудить, почему новый RR для каждого нового сервиса – плохое решение. За-
пись типа SRV, формат полей NAME и RDATA, особое внимание уделить весам
и приоритетам. Dns для ipv6. Подчеркнуть, что нет никакого нового протокола
dns для ipv6, достаточно лишь передавать dns пакет поверх ipv6 и ввести новый
RR, типа АААА, рассматриваем его формат. Обратить внимание студентов, что
все изученные записи КРОМЕ а никак не привязаны к ipv4, поэтому расширение
dns для ipv6 требует лишь новой записи АААА.
Утилита nslookup, демонстрация неинтерактивного режима. Интерактивный
режим nslookup, возможность выбирать тип записи для поиска в dns, возможно-
сти управлять отправляемыми dns запросами. Утилита dig, управление отправ-
ляемыми dns запросами.
Демонстрация поведения dns серверов, разрешающих имена через корневые
сервера с помощью утилит nslookup/dig.
Лабораторная работа. Разрешение имен с помощью nslookup в неинтерактив-
ном режиме, анализ трафика. Разрешение несуществующего имени в существую-
щем домене, в несуществующем домене, анализ трафика. Найти ip адреса серверов
имен нескольких доменов. Узнать email адрес администратора, ответственного за
некоторый домен. Разрешить несколько имен не пользуясь кеширующим сервером,
т. е. путем отправки запросов к корневому серверу и прочим серверам с учетом
получаемых итерационных ответов.
Принципы конфигурирования зон. Сперва рассматриваем пример конфигу-
рирования зоны для корпоративного применения, не связанную с Интернет. Вы-
бор доменного имени, создание ключевых записей зоны: SOA, NS, а записи для
сервера имен, настройки клиентов для обращения к созданному серверу/серверам.
Настройка данного сервера для обслуживания клиентов не только для разреше-
ния имен в настроенной зоне, но и в Интернет, включение рекурсии, возможное

включение форвардинга.
Создание поддоменов в созданном локальном домене. Создание имен в под-
доменах без создания отдельной зоны, создание отдельной зоны на том же или
другом сервере, делегирование, создание glue записей если это необходимо.
Принципы конфигурирования зоны, интегрированной в пространство имен
Интернет, настройки на сервере, отвечающем за зону верхнего уровня, в каких
случаях необходимы glue записи.
Демонстрация возможностей dns сервера в ios. Работа dns сервера в роли
сервера, обслуживающего клиентов, ограничения dns сервера в ios, связанные
с невозможностью разрешать имена через корневые сервера. Создание зоны, соз-
дание RR, настройки делегирования. Разрешение имен с помощью настроенного
сервера, анализ трафика.
Обратное разрешение имен. Задача об обратном разрешении имен, важно
продемонстрировать, что dns в том виде, в котором мы его изучили, полностью
не пригоден для обратного разрешения имен. Домен arpa, поддомены in-addr и ip6,
важно подчеркнуть, что домен arpa не является отдельным простарнством имен,
а находится в том же корне, что и ранее изученные домены. Обратные разреше-
ния ipv4 адресов. Структура поддоменов в домене in-addr, подробно, вложенная
структура поддоменов. Превращение ipv4 адреса в доменное имя в домене in-
addr.arpa и последующее разрешение этого имени в доменное имя узла. Способ
формирования доменного имени в домене in-addr.arpa. Записи типа PTR, формат
полей NAME/RDATA. Административное управление зонами обратного про-
смотра в классовом Интернет, примеры зон обратного просмотра для адресов из
различных классов. Управление зонами обратного просмотра для бесклассового
Интернет. Управление зонами для случаев, когда адресное пространство выде-
ляется бесклассово с масками, длиннее чем /24. Управление зонами для случаев,
когда адресное пространство выделяется бесклассово с масками, короче чем /24,
создание зон с масками в названии, использование CMAME на стороне оператора,
конфигурирование зоны на стороне абонента.
Демонстрация примеров обратного разрешения имен. Сперва разрешаем адрес
(класса А) в имя с помощью dig/nslookup, захватываем трафик, анализируем об-
мен между клиентом и кеширующим сервером. Затем демонстрируем, как рабо-
тает кеширующий сервер – разрешаем тоже имя, но только отправляем запрос
к корневому серверу и затем к соответствующим авторитетным серверам. Затем
показываем аналогичные примеры с адресами классов В и С, разрешаем имена
с помощью кеширующего сервера, а затем разрешаем эти же имя через корневой
сервер. Пример разрешения адреса в имя, в котором задействованы CNAME (пре-
подаватель должен предварительно подобрать подходящий адрес), разрешаем soa
зоны с «маской» в названии, демонстрируем, как сконфигурирована у клиента эта
зона.
Обратное разрешение ipv6 адресов в доменные имена. Поясняем, как это ра-
ботает, показываем, как формируется имя в домене ip6.arpa, подчеркиваем, как
формируются имена в случае сокращенной записи ipv6 адреса.
Демонстрация обратного разрешения имен в ipv6, анализ обмена в анализа-
торе протоколов.
Лабораторная работа на разрешение адресов ipv4/ipv6 в имена. Студенты долж-
ны разрешить предложенные адреса в имена, используя сперва кеширующий
сервер, а затем самостоятельно, начиная с корневого сервера и проанализировать
трафик.
Динамический dns. Обсудить, почему создание файла зоны только вручную
сильно ограничивает применение dns, важность автоматического обновления зон,
например, при использовании dhcp сервера или автоконфигурирования для на-
стройки узлов. Возможность простого автоматического обновления зоны в случае,
когда сервисы dns и dhcp реализованы в одном программном обеспечении, немас-
штабируемость такого подхода. Расширение dns для динамического обновления
зон, новое значение кода операции в заголовке dns. Заголовок dns для пакетов типа
update, новое значение полей: отказ от флагов, новый смысл значений RCODE (пока
значения не рассказываем, пока студенты не знают коммуникаций, они не могут
понять смысла ошибок). Новые секции в заголовке вместо секций, применяемых
в пакетах обычных запросов: секция зон, секция предварительных требований,
секция обновлений, секция дополнительных сведений.
Обсуждаем, что автоматическое обновление зоны могут делать как сервера,
на основании имеющихся у него данных, так и клиент. Важно обсудить необхо-
димость секции предварительных требований, приведя пример, в котором в зоне
уже есть соответствующая запись типа а или PTR из-за предыдущего обновления.
Подводим студентов к мысли от том, что динамический dns должен иметь возмож-
ность делать предварительные проверки перед тем, как обновлять зону, а также
не только добавлять записи в зону, но и удалять записи из зоны.
Формат записей в секции зон. Формат записей в секции предварительных
требований. Отсутствие прямой возможности указать, какой тип проверки нужно
выполнить, специальное использование полей CLASS/TYPE для указания ТИПА
(одного из пяти) предварительного требования. Понятие RRSet. Формат всех пяти
типов предварительных требований, соответствующие значения полей CLASS/
TYPE. RCODE, используемые в ddns.
Формат секции обновлений. Необходимость выполнять обновления различ-
ных типов (например, создание записи/удаление записи), отсутствие прямой
возможности указать, какой тип обновления выполняется, специальное исполь-
зование полей CLASS/TYPE для указания ТИПА (одного из четырех) обновления.
Один способ добавить запись и три способа удалить запись/записи. Формат всех
четырех типов обновлений, соответствующие значения полей CLASS/TYPE. Типо-
вые сценарии коммуникаций между dhcp сервером или клиентом и dns сервером.
Демонстрация работы ddns. Конфигуририруем dhcp сервер, dns сервер и кли-

ента. Сперва демонстрируем, как клиент обновляет свои данные в dns своими
силами, анализируем трафик и поведение ddns клиента с точки зрения проводи-
мых предварительных проверок. Включение обновления обратной зоны, анализ
трафика. Отключение обновлений dns на dhcp клиенте, включение обновления
на стороне dhcp сервера, демонстрация транзакции в анализаторе протоколов.
Утилита nsupdate, обновление зон удаленно вручную, возможность исполь-
зования данной утилиты в сценариях. Формирование обновлений, демонстрация
трафика.
Резервирование зон, резервные dns сервера. Балансирование нагрузки на dns
сервера и отказоустойчивость. Главный сервер, на котором делаются изменения,
резервные сервера. Изначальная реализация синхронизации зон: резервные сер-
вера запрашивают полную копию зоны в соответствии со значением таймеров,
указанных в soa. Недостатки такого подхода: полный трансфер зон, выполняемый
относительно часто, невозможность частичного трансфера зоны, невозможность
для мастер-сервера уведомить дополнительные сервера об изменениях. AXFR
обмен, формат запроса и ответа, использование транспорта tcp для выполнения
трансфера зоны.
Инкрементальный трансфер зон – возможность передать только изменения
в зоне вместо полного трансфера зоны. Технология dns notify – возможность для
главного сервера уведомить резервный сервер о необходимости выполнить транс-
фер обновленной зоны. Выполнение IXFR, роль серийного номера зоны. Способ
кодировать изменения (удаление и добавление) записей в зоне, последовательная
передача всех изменений от заявленного номера резервным сервером до текущего
номера зоны. Примеры инкрементального трансфера с удалением и добавлением
записей. Способ уведомления резервных серверов, новый типа dns пакета. Формат
пакета notify, возможность включения soa записи в авторитетной секции. Комму-
никации между клиентом и сервером, включая notify и последующий трансфер
зоны любого типа на выбор клиента.
Демонстрация трансфера зон. Так как ios не поддерживает трансфера зон,
преподаватель должен предварительно настроить сервер с зоной для данной де-
монстрации. Использование dig, анализ трафика, необходимо продемонстрировать
AXFR и IXFR.
Механизм расширений dns, формат записи типа opt, возможности, которые
дает данная запись: оговаривание размера upd пакетов, дополнительные RCODE,
возможность согласовывать будущие расширения.
Демонстрация записи типа opt в диалоге между клиентом и сервером.
Лабораторная работа. Создание зоны на сервере под управлением cisco ios,
динамические обновления с помощью dhcp сервера и dhcp клиента, анализ тра-
фика. Трансферы зон: на предварительно подготовленном преподавателем сервере
необходимо выполнить полный и несколько частичных трансферов зоны, анализ
трафика трансферов зоны.
Урок 5
Введение в динамическую маршрутизацию
Перед тем, как продолжить, необходимо создать студентам классы по CCNA2/3/4
и пояснить, что мы будем сперва изучать маршрутизацию, а затем коммутацию,
в то время как в материалах академии эти темы изучаются вперемешку. Поэтому
сперва мы в этом курсе изучим ряд глав CCNA2 и CCNA3, посвященных марш-
рутизации, а затем в следующем курсе изучим остальные главы этих же курсов,
посвященных коммутации. Также необходимо задать студентам сдачу ряда мо-
дульных экзаменов по тем темам, которые уже изучены, а именно: CCNA2, модули
4, 9, 10, 11.
Обзор недостатков статической маршрутизации, отсутствие реакции системы
на выход из строя линий связи, а также на изменение используемой топологии
связей. Задача об автоматическом построении оптимальных таблиц маршрутиза-
ции в рамках текущей топологии связей. Две основных причины использования
динамической маршрутизации: уменьшение ручного труда при конфигурировании
(и, заодно, уменьшение вероятности ошибки) и создание сети, которая сама могла
бы найти новые маршруты при выходе из строя некоторых связей или появлении
новых связей.
Общая идея, лежащая в основе динамической маршрутизации: все маршру-
тизаторы составной сети должны иметь маршруты во все сети составной сети,
однако изначально, если статические маршруты не настроены, каждый маршрут
в отдельности есть в таблице маршрутизации НЕКОТОРЫХ маршрутизаторов,
тех, к кому напрямую подключена соответствующая сеть. Таким образом вся со-
вокупность маршрутизаторов «в целом» знает маршруты во все сети, необходимо
сделать так, чтобы КАЖДЫЙ маршрутизатор составной сети знал маршруты
в КАЖДУЮ сеть, для этого маршрутизаторы составной сети должны обменяться
имеющейся у них информацией таким образом, чтобы прейти от состояния «для
каждой сети существуют один или несколько маршрутизаторов, которые знают
маршрут к этой сети» к состоянию «для каждой сети справедливо утверждение,
что каждый маршрутизатор составной сети имеет к ней маршрут». Протоколы
динамической маршрутизации как средство обмена данными о маршрутах или
о топологиях связей между маршрутизаторами с целью автоматизации постро-
ения маршрутных таблиц. Типичный способ достижения цели (про bgp сейчас
не говорим): каждый маршрутизатор имеет ограниченное количество соседей
в одной канальной сети с ним и может обмениваться с ними данными, после чего
информация каскадно распространяется по составной сети.
Невозможность организации обмена данными между всеми маршрутизато-
рами составной сети с целью построения маршрутных таблиц. Структурирова-
ние составной сети с точки зрения организации динамической маршрутизации.
Структура сложной составной сети. Понятие об автономных системах AS. Марш-
рутизация внутри автономной системы и маршрутизация между автономными

системами. Классификация протоколов динамической маршрутизации на внешние
и внутренние. Примеры внутренних и внешних протоколов маршрутизации.
Два основных вопроса, стоящих перед протоколами динамической маршрути-
зации: как эффективно обмениваться информацией и какой именно информацией
обмениваться. Детально обсуждаем каждый из двух вопросов.
Начинаем с того, как обмениваться информацией, какой бы она не была. Под-
черкнуть, что обмен информацией должен быть таким, чтобы маршрутизаторы
всегда обладали актуальной информацией от соседей, потери пакетов были бы
скомпенсированы и обмен не порождал слишком интенсивный трафик. Описы-
ваем первый способ: маршрутизаторы периодически (не слишком часто, чтобы
не создавать избыточный трафик и не слишком редко, чтобы данные всегда были
актуальны) передают своим соседям всю информацию, которой обладают, ни-
каких подтверждений не отправляется. Так как постоянно происходит передача
всей информации, можно не подтверждать полученные данные и не опасаться
потери пакетов: если что-то и потеряется, то при следующей передаче полной
информации это будет скомпенсировано, также легко гарантировать обновление
информации, это произойдет автоматически при следующем полном обмене. Оче-
видный недостаток такого подхода: потенциально слишком интенсивный трафик
и необходимость постоянно обрабатывать поступающую информацию чтобы
отразить изменения или убедиться, что изменений не произошло, при этом чем
чаще передаются данные, тем актуальнее маршруты, но тем сильнее нагрузка на
сеть. Альтернативный способ: маршрутизаторы однажды передают соседям все
данные, которыми располагают, получают подтверждение о получении, после чего
обмениваются с ними короткими пакетами (обычно называются hello), которые
призваны проверять, есть ли связь между маршрутизаторами, и если таковая
связь есть, то информация, которой располагают маршрутизаторы актуальна, а в
случае, если произойдут изменения, маршрутизаторы передают друг другу толь-
ко измененные данные (с подтверждением), после чего продолжают обмен hello.
Важно продемонстрировать, что такой подход имеет серьезное преимущество: по
сети передается гораздо меньший объем данных, при том нет потери в скорости
обновления информации, однако, такой подход требует несколько более сложной
реализации.
Переходим ко второму вопросу: чем могут обмениваться маршрутизаторы.
Подчеркиваем, что есть два основных подхода: с одной стороны маршрутизаторы
могут обмениваться с соседями маршрутами, которые имеют в таблице марш-
рутизации (маршрутами как в подключенные сети, так и маршрутами, которые
таким же способом узнали от соседей), а с другой стороны маршрутизаторы могут
обмениваться сведениями о топологии связей в сети (о том, какие есть маршру-
тизаторы, между какими из них есть линии связи, каковы параметры этих линий
связи). При таком подходе маршрутизаторы получают после окончания обмена
полную топологию связей в сети, после чего, зная топологию, могут самостоятель-
но рассчитать все необходимые маршруты. Ввести понятие о дистанционно-век-
торных алгоритмах (первого типа, DVA) и алгоритмах состояния связей (второго
типа, LSA). Важно особо обратить внимание студентов, что термин LSA означает
обмен сведениями о топологии! (Часто студенты ошибочно полагают, что термин
Link State означает, что маршрутизаторы время от времени проверяют состояния
связей с соседями, т. е. этот термин относится к тому, как маршрутизаторы обме-
ниваются информацией (см. выше), а не к тому, чем они обмениваются).
Понятие метрики, роль метрики в работе протоколов динамической марш-
рутизации. Различные типы метрики: простое количество переходов, учет про-
пускной способности линий связи, учет задержки в линиях связи, учет других
параметров). Возможность балансирования нагрузки между равными или близ-
кими по метрике маршрутами.
Принципы работы дистанционно-векторных алгоритмов (без привязки к ка-
кому бы то ни было протоколу маршрутизации). Начальные таблицы маршрути-
зации, содержащий сведения только о подключенных сетях. Рассылка векторов
расстояний, обновление маршрутных таблиц. Понятие метрики, роль метрики
в выборе маршрута. Проблемы дистанционно-векторных алгоритмов, связанные
с потенциальным образованием маршрутных петель. Образование маршрутных
петель между соседними маршрутизаторами, расщепление горизонта и poison
reverse как средство борьбы с маршрутными петлями, образующимися между со-
седними маршрутизаторами. Маршрутные петли между удаленными маршрутиза-
торами, триггерные обновления, почему триггерные обновления не гарантируют
отсутствие петель. Концепция замораживания изменений, преимущества (защита
от петель при использовании с указанными выше решениями) и недостатки (за-
медленная реакция сети на изменения). Примеры дистанционно-векторных про-
токолов, которые будут изучаться в дальнейшем (RIP, EIGRP), классификация про-
токолов по способу обмена информацией (постоянные рассылки или hello обмен).
Принцип работы алгоритма состояния связей (без привязки к конкретному
протоколу). Чем обмениваются маршрутизаторы, какой информацией о сети об-
ладают маршрутизаторы после окончания обмена данными о топологии. Сравнить
топологическую базу, которой обладает маршрутизатор с изображенной на листе
бумаги топологией, которой обладает администратор. Принцип нахождения оп-
тимальных маршрутов с помощью алгоритма Дейкстра, независимое нахождение
всех маршрутов каждым маршрутизатором в отдельности. Важно подчеркнуть,
что алгоритм не ищет кратчайший маршрут в наперед заданную сеть, вместо этого
алгоритм последовательно перебирает все маршруты, которые могут начинать-
ся от маршрутизатора, на котором он запущен, и смотрит, куда приводят такие
маршруты, последовательно находя все возможные маршруты, среди которых
найдется кратчайший маршрут в каждую сеть. Преимущества протоколов на базе
алгоритма состояния связей: наиболее точные и актуальные маршруты, невозмож-
ность образования маршрутных петель. Недостатки протоколов на базе алгоритма

состояния связей: высокая вычислительная нагрузка, задержка, связанная с не-
обходимостью вычисления маршрутов после обновления топологии. Примеры
протоколов, которые будут изучаться в дальнейшем (OSPF, ISIS).
Невозможность сравнивать метрики маршрутов, полученных с помощью раз-
личных протоколов маршрутизации. Понятие административной дистанции,
работа нескольких протоколов динамической маршрутизации на одном марш-
рутизаторе. Совместное использование маршрутов, полученных с помощью про-
токолов динамической маршрутизации, статических маршрутов и маршрутов
к подключенным сетям. Floating static route, пример.
Протоколы маршрутизации RIPv1, RIPv2 и RIPng

Классификация протокола RIP: внутренний протокол маршрутизации, основан-
ный на дистанционно-векторном алгоритме, обмен данными происходит путем
периодической отправки соседям (типично каждые 30 секунд) информации обо
всех маршрутах, имеющихся в таблице маршрутизации, в качестве метрики марш-
рута используется количество переходов (хопов). Какие маршруты включаются
в передаваемый вектор расстояний: маршруты в подключенные сети и маршруты,
полученные с помощью протокола RIP. Почему с помощью RIP не передается шлюз
в анонсируемую сеть, использование адреса отправителя апдейта в качестве адреса
шлюза в анонсируемую сеть. Метрика маршрута, увеличение метрики маршрута
маршрутизатором, принимающим апдейт (Важно отметить, как растет метрика
в реализации cisco: источник маршрута полагает, что сеть доступна ему с метрикой
нуль и анонсирует ее соседям с метрикой 1, соседи включают в свои таблицы эту
сеть с метрикой 1 и анонсируют соседям доступность сети с метрикой 2 и т. д., т. е.
наращивание метрики делает отправитель перед отправкой, а не получатель после
получения). Простой пример, иллюстрирующий работу RIP: два маршрутизатора,
у каждого из которых есть тупиковые сети, анонс этих сетей маршрутизаторами
друг другу, отказ от передачи сведений о сети через интерфейс в этой сети. Более
сложный пример: три маршрутизатора, подключенные последовательно, у каж-
дого есть тупиковые сети, обмен информацией о сетях между маршрутизаторами.
Включение нового маршрутизатора в сеть, ускорение получения новым маршру-
тизатором маршрутной информации, пакет типа request, пакет типа respond.
Заголовок RIP версии 1, отправка сообщений широковещательно, недостат-
ки такого подхода. Формат пакета. Фиксированный заголовок, поля command
и version. Формат записи о маршруте, номер сети и метрика, отсутствие маски
подсети. Особенности работы RIPv1 в сети с масками подсетей. Поведение марш-
рутизатора, при необходимости отправить маршрут о подсети: отправка маршрута
с номером подсети (хотя и без маски) в случае, если интерфейс, через который
передается апдейт имеет адрес в подсети той же классовой сети, отправка сумма-
ризированного маршрута в классовую сеть через интерфейсы, адреса которых не
принадлежат подсетям той же классовой сети. Проблемы при такой автоматиче-

ской суммаризации, невозможность использовать подсети с масками переменной
длины и подсети одной классовой сети в различных частях сети, разделенных
сетями с другими адресами. Возможность появления маршрутных петель из-за
некорректной автоматической суммаризации, анализ ситуации, в которой марш-
рутизатор имеет только некоторые подсети классовой сети, хотя и анонсирует
ее целиком соседнему маршрутизатору, которым пользуется как шлюзом по-
умолчанию, включение классового поведения (ip classless) для решения проблемы.
RIP версии 2, формат пакета, использование мультикаст. Неизменный заго-
ловок с новым значением поля Version, изменения в записях о маршрутах. Поле
Route Tag (кратко), добавление маски и возможность указания следующего марш-
рутизатора. Особо подчеркнуть, что типично получатель апдейта в качестве шлюза
в анонсируемую сеть по-прежнему использует адрес отправителя апдейта, пояс-
нить, в каких ситуациях поле Next Hop используется.
Как в сеть RIP добавляются маршруты, каскадное распространение информа-
ции о новой сети в домене RIP с учетом метрики, хранение информации только
о лучшем маршруте, невозможность использования резервных маршрутов: не
лучший маршрут может оказаться доступен в рамках маршрутной петли, потен-
циальная возможность использовать несколько маршрутов равной стоимости.
Что происходит, если метрика к некоторой сети уменьшается – каскадное распро-
странение новой информации по сети. Что происходит, если метрика к некоторой
сети увеличивается: маршрутизаторы, которые пользуются соседом как шлюзом
в некоторую сеть обязаны принимать во внимание апдейты от такого соседа даже
если метрика, которую сосед объявляет, хуже чем предыдущее значение (что, раз-
умеется, не мешает выбрать новый шлюз с лучшей метрикой в такой ситуации).
Как из RIP сети удаляются маршруты. Сперва рассматриваем ситуацию, в ко-
торой один из маршрутизаторов выходит из строя и не может никого уведомить
о недоступности сетей, доступных через него, invalid таймер, удаление маршрута
спустя invalid таймер, подчеркиваем, что удаление маршрутов только с помощью
invalid таймера – очень долгий процесс (пока не говоря о возможном петлеобра-
зовании), так как на каждом хопе задержка удаления маршрута составляет 180
секунд. Обсуждаем, что маршрутизаторы, утратившие маршрут, должны уведом-
лять об этом соседей активно, а не позволять им ждать 180 секунд, подчеркнуть,
что если у маршрутизатора отключился интерфейс, он должен явно уведомлять
соседей, а в случае отказа маршрутизатора целиком, его сосед, который подо-
ждал invalid таймер и убедился в отсутствии маршрута, также должен уведомлять
своих соседей явно. Способ уведомления соседей об отказе маршрута, отправка
апдейта с метрикой «недостижимо», значение метрики «недостижимо» (почему
недостижимая метрика так мала обсудим позже), напомнить, что маршрутиза-
торы должны верить ухудшенному значению метрики от того, через кого дости-
гают сети). Отметить, что отправить уведомление о недостижимости сети один
раз недостаточно (пакеты могут теряться), поэтому сведения о недостижимости

необходимо включать в апдейты в течение некоторого времени, таймаут garbage-
collection (flush в терминах cisco). Отметить, что в RFC рекомендуется значение
120 секунд, а у cisco по-умолчанию этот таймер равен 60 секунд, но, так как он
отсчитывается не от момента, когда сеть недоступна, а от момента получения по-
следнего актуального обновления об этой сети, то cisco использует значение 240
секунд (invalid + 60). Важно подчеркнуть: для того, чтобы в течение 60-120 секунд
маршрутизатор мог включать в свои апдейты сведения о недоступности сети, ин-
формация об этой сети должна храниться в таблице маршрутизации (с пометкой
«недостижимо») или где-то еще. Важно отметить: если маршрутизатор получает
сведения о доступности некоторой сети, которая находится в состоянии invalid,
он должен принять эту информацию во внимание, удалить недействительный
маршрут и установить в таблицу маршрутизации новый действительный маршрут,
привести пример.
Проблемы петлеобразования в RIP. Рассматриваем простейший пример, в ко-
тором соединены два маршрутизатора, к первому подключена некая сеть, второй
достигает этой сети через первого. Положим, что первый маршрутизатор утратил
маршрут к этой сети, однако еще не успел сообщить об этом второму, а в это время
второй маршрутизатор передал обновление первому о доступности сети (на самом
деле сеть доступна через первый, т. е. не доступна на самом деле). Продемонстри-
ровать образование маршрутной петли, продемонстрировать, как петля исчезает
путем счета до бесконечности, пояснить, почему в RIP «бесконечностью» названа
столь малая метрика. Привести более реальный пример, из RFC1058, показываю-
щий возникновение петли между соседними маршрутизаторами.
Отметить, что ограничения на метрику не достаточны (показать время сходи-
мости в указанных примерах), расщепление горизонта как эффективный метод
борьбы с маршрутными петлями. Правило простого расщепления горизонта,
иллюстрация того, почему использование расщепления горизонта помогает устра-
нить петли между соседними маршрутизаторами. Альтернативное поведение:
расщепление горизонта с «отравлением». Преимущества такого поведения перед
молчаливым исключением маршрутов из апдейтов, возможность немедленно
устранить петлю если она появится, недостатки «отправления» – избыточный
трафик.
Рассмотреть пример, в котором петля образуется не между двумя, а между
тремя маршрутизаторами, подчеркнуть, что расщепление горизонта не помогает
устранить такую петлю. Триггерные обновления как инструмент, который должен
минимизировать вероятность появления петли, поведение маршрутизаторов,
у которых произошли изменения. Необходимость дополнительной небольшой
случайной задержки перед отправкой триггерного обновления. Почему триггерные
обновления не гарантируют того, что петля между несколькими маршрутизатора-
ми не возникнет: отправка регулярных обновлений между триггерными, отметить,
что не смотря на то, что триггерные обновления существенно уменьшают риск

возникновения петель, они все еще могут возникать. Анализ скорости устранения
петли при использовании триггерных обновлений, почему счет до бесконечности
проходит быстро при триггерных обновлениях и не представляет такой опасности,
как без применения триггерных обновлений.
Замораживание изменений как способ окончательно устранить петли. Как
работает замораживание, почему замораживание помогает устранить петли, ко-
торые могут возникать при использовании расщепления горизонта и триггерных
обновлениях. Отметить, что holddown таймер не является частью RFC, описываю-
щих RIP, а является проприетарным расширением. Когда ios использует holddown:
только при срабатывании invalid таймера, т. е. в ситуации, когда сеть исчезает из-за
отсутствия апдейтов о ней, отказ от состояния holddown для сетей, о пропадании
которых объявлено явно. Анализ использования holddown на примере. Недостатки
замораживания изменений – замедленная сходимость протокола.
Конфигурирование маршрутизатора cisco для поддержки протокола RIP. Вклю-
чение RIP, включение RIP на интерфейсах. Способ включить поддержку маршру-
тизации на интерфейсе, команда network, формат команды network для RIP. Очень
важно подчеркнуть, что делает команда network: включает отправку апдейтов
на интерфейсах, которые попадают в диапазон аргумента, включает обработку
апдейтов на интерфейсах, которые попадают в диапазон аргумента, включение
сетей за интерфейсами, которые попадают в диапазон аргумента в процесс RIP.
Важно отметить, что одной командой network можно включить RIP на нескольких
интерфейсах. Рассматриваем ситуацию, в которой одна команда network включает
поддержку RIP на многих интерфейсах, в том числе и на тех, где это не нужно, по-
казываем команду passive-interface, а также passive-interface default.
Строим простую сеть из двух соединенных маршрутизаторов, добавляем по од-
ной тупиковой сети за каждым (все сети классовые, включаем RIP (все настройки
по-умолчанию), демонстрируем трафик между маршрутизаторами и содержимое
таблиц маршрутизации, обращаем внимание на все поля пакета, особо отмеча-
ем отсутствие маски. Обращаем внимание на работу расщепления горизонта.
Переадресуем сеть таким, чтобы все сети были подсетями одной классовой сети
с масками одинакового размера, демонстрируем результат работы протокола, уд-
линяем маску одной из тупиковых сетей, снова демонстрируем результат работы
протокола. Делаем тупиковые сети подсетями одной классовой сети, а сеть между
маршрутизаторами адресуем из другого диапазона, демонстрируем маршрутные
таблицы. Строим сеть из трех маршрутизаторов, крайние анонсируют центрально-
му разные подсети одной классовой сети, демонстрируем таблицы маршрутизации
в случае, когда сети между центром и краями принадлежат той же классовой сети,
что и анонсируемые тупиковые сети и когда не принадлежат, обращаем внимание
на полную неработоспособность данной схемы. Включаем RIPv2, демонстрируем
трафик в проводе, обращаем внимание на появление маски, демонстрируем пове-
дение маршрутизаторов из прошлого примера, обращаем внимание на автоматиче-

скую суммаризацию, отключаем автоматическую суммаризацию, демонстрируем
результат. Демонстрируем ручную суммаризацию на интерфейсе. Демонстрируем
точное управление версиями отправляемых и принимаемых пакетов. Демонстри-
руем show ip protocol для RIP и используемые версии пакетов протокола.
Демонстрируем добавление новой сети в цепочке из трех маршрутизаторов, об-
ращаем внимание на увеличение метрики на каждом хопе, обращаем внимание, что
у источника маршрута метрика равна нулю, хотя и этого не видно в маршрутной
таблице, и далее метрика растет. Демонстрируем удаление маршрута из составной
сети. Сперва на крайнем маршрутизаторе выключаем loopback и демонстрируем
трафик между маршрутизаторами, показываем, как маршрутизаторы явно делают
маршрут недостижимым. Обращаем внимание, что у маршрутизаторов, которые
удалили маршрут, он остается в базе данных RIP, так как в течение flush тайме-
ра (60 секунд, не 240), они должны отправлять сведения о недоступности этого
маршрута соседям, показываем show ip rip database. Затем демонстрируем отказ
маршрутизатора, отключаем маршрутизатор, который был источником маршрута
(так, чтобы у его соседа не пропал link test), демонстрируем переход маршрута
у соседа в состояние invalid через 180 секунд, после чего окончательное удаление
маршрута еще через 60 секунд. Демонстрируем значения таймеров по-умолчанию,
настройку таймеров.
Строим сеть, в которой между тремя маршрутизаторами может возникнуть
петля, если между триггерными обновлениями успеют пройти регулярные. Уста-
навливаем таймер обновлений в 1 секунду, выключаем loopback на одном из марш-
рутизаторов и демонстрируем возникновение петли (при таймере обновления в 1
секунду, петля возникает часто, как минимум по половине случаев). Демонстриру-
ем наличие петли анализируя трафик, поясняем, почему такая петля устраняется
быстро, так как счет до бесконечности происходит тоже триггерным способом.
Демонстрируем работу holddown таймера. Строим сеть, в которой два крайних
маршрутизатора анонсируют среднему одну и ту же есть с разными метриками
(преподаватель может использовать offset list или просто сделать одно плечо то-
пологии на один маршрутизатор длиннее). Отключаем соответствующий loopback
с этой сетью на том крайнем маршрутизаторе, которой дает среднему действую-
щий маршрут, показываем, как крайний маршрутизатор сообщает о недоступ-
ности сети и как средний маршрутизатор без всякого holddown принимает марш-
рут от другого крайнего маршрутизатора. Возвращаем все в исходное состояние,
и отключаем сам крайний маршрутизатор, которой дает среднему действующий
маршрут (но так, чтобы link test не исчез), демонстрируем переход маршрута на
среднем маршрутизаторе в состояние invalid через 180 секунд, после чего еще 60
секунд средний маршрутизатор не будет принимать маршрут от второго крайнего
маршрутизатора, так как работает holddown. Пояснить взаимодействие между
invalid и holddown таймерами, пояснить, почему эффективное состояние holddown
длится не holddown таймер, а min(holddown, flush-invalid).
Добавляем на один из крайних маршрутизаторов маршрут по-умолчанию ста-

тически, демонстрируем, что данный маршрут не включается в RIP. Демонстрируем
команду default-information originate, анализируем результат.
Аутентификация в RIP. Поясняем, что протокол маршрутизации должен быть
защищен от того, чтобы злоумышленник мог отправить ложные пакеты с маршру-
тами, тем самым получив возможность перенаправлять трафик или создавать со-
стояния «отказ в обслуживании», особо отметить, что речь не идет о шифровании
сообщений RIP, только о гарантировании аутентичности полученной маршрутной
информации. Ранний способ обеспечить подобие аутентификации – пароли в со-
общении RIP, передаваемые открытым текстом. Обсуждение недостатков такой
аутентификации. Отметить, что RIPv1 вообще не поддерживал аутентификацию,
в RIPv2 изначально появилась аутентификация открытым текстом, формат 20-ти
битного блока, который переносил сведения об аутентификации, необходимость
снабжать каждый RIP пакет таким блоком данных наряду с маршрутами. Крипто-
графическая аутентификация в RIPv2 (rfc4822). Кратко о концепции подписыва-
ния данных сторонами, разделяющими секретный ключ, понятие о хеш-функции.
Указания на каждом маршрутизаторе секретного ключа, снабжение передаваемого
по сети блока данных значением хеш-функции, вычисленной на основании содер-
жимого пакета и разделяемого ключа, способ проверки аутентичности полученных
данных получателем. Новый формат блока аутентификации в RIPv2. Отказ от ау-
тентификации в RIPng, перенос задачи об обеспечении аутентификации пакетов
RIPng на расширения ipv6, которые призваны обеспечивать аутентичность (и не
только) любых пакетов, отметить, что технологию ipsec мы будем изучать позже.
Конфигурирование аутентификации в ios для RIPv2. Настройка аутентифи-
кации открытым текстом, демонстрация работы, анализ пакетов. Концепция
key-chain в ios. Возможность указать несколько ключей с соответствующими id
и использовать их одновременно, удобство с точки зрения процесса смены ключей.
Настройка md5 аутентификации, настройка цепочки ключей.
Лабораторная работа на конфигурирование RIP. В первом задании студентам
необходимо построить сеть из трех маршрутизаторов, подключенных друг к другу
цепочкой, у каждого маршрутизатора должны быть тупиковые сети с помощью
loopback. В первой части следует использовать классовые адреса и RIPv1, студен-
там необходимо настроить работу сети, проверить ее работоспособность и про-
анализировать трафик RIP между маршрутизаторами. Во второй части задания
студентам необходимо использовать подсети одного размера одной классовой
сети, проанализировать полученные маршрутные таблицы и трафик RIP. В тре-
тьей части студенты должны изменить маски некоторых тупиковых подсетей так,
чтобы проанализировать поведение RIPv1 в случае использования масок подсетей
переменной длины. В четвертой части задания студенты должны использовать
для адресации сетей между крайними маршрутизаторами и центральным другой
сетевой диапазон, нежели в тупиковых сетях и проанализировать полученные
маршрутные таблицы и трафик RIPv1. В пятой части задания студенты должны

включить использование RIPv2 сперва не отключая суммаризацию, а затем от-
ключить ее, проанализировать маршрутные таблицы и трафик в сети.
Во втором задании студенты должны построить кольцо из трех маршрутиза-
торов, и, сконфигурировав соответствующим образом таймеры, смоделировать
возникновение маршрутной петли между маршрутизаторами. Для порождения
петли нужно воспользоваться маршрутом по-умолчанию, который включает в RIP
один из маршрутизаторов.
В третьем задании необходимо снова подключить три маршрутизатора по-
следовательно так, чтобы крайние анонсировали среднему один и тот же маршрут
(если без offset-list, то понадобиться еще один маршрутизатор для того, чтобы
маршруты в центре были разной стоимости), после чего сделать так, чтобы лучший
маршрут отказал, сперва отключив интерфейс, а затем отключив маршрутизатор.
Студентам необходимо проанализировать, в каком случае маршрут перейдет в со-
стояние holddown. При этом необходимо использовать аутентификацию на всех
маршрутизаторах.
Протокол RIPng. Общая идея протокола, практически полная идентичность
всех концепций RIP и RIPng: общий подход в передаче маршрутной информа-
ции, к расчету метрики, ограничения на максимальную метрику, расщепление
горизонта и poison reverse, holddown и таймеры. Важно подчеркнуть, что даль-
ше будет идти речь только об отличиях между RIP и RIPng (как в стандарте, так
и в реализации в ios).
Как передаются пакеты RIPng: отправка пакетов с помощью link-local адресов,
мультикаст адрес получателя, новый номер порта (521), использование к качестве
шлюза link-local адресов.
Как увеличивается метрика между маршрутизаторами: в RIP метрику перед
отправкой маршрута увеличивал отправитель, получатель маршрута устанав-
ливал в таблицу маршрутизации метрику, полученную от соседа, в RIPng в ios
метрику увеличивает получатель маршрута перед установкой записи в таблицу
маршрутизации. Отправка сведений о сети, соединяющие маршрутизаторы через
интерфейс в этой сети.
Формат пакета. Фиксированная часть заголовка, номер версии 1. Формат за-
писи о маршрутах той же длины, что и в RIP, поле префикса вместо маски, уко-
роченное поле для метрики. Отсутствие возможности указать next hop, способ
решения этой проблемы с помощью записи специального типа с метрикой 255
и нулевым префиксом, все маршруты, переданные после такой специальной за-
писи следует использовать с указанным в специальной записи next hop до тех пор,
пока не будет передана эквивалентная специальная запись, которая отменяет для
последующих маршрутов действие заданного next hop.
Таймеры по-умолчанию – полное соответствие RFC: таймер garbage-collection
= 120 секунд (и отсчитывается, как указано в RFC, от момента удаления сети), от-
ключенная технология holddown (таймер = 0). Отличия в работе holddown (при

включении): маршрут переходит в состояние holddown как в случае, когда сосед
сообщил о его недоступности явно, так и в случае, когда недоступность маршрута
стала результатом срабатывания invalid таймера.
Демонстрация конфигурирования и функционирования RIPng. Включение
процесса RIP, отсутствие команды network, включение RIP непосредственно на
интерфейсах. Команды show ipv6 protocols, sh ipv6 rip <name> и show ipv6 rip
<name> database. Настройки таймеров. Построение простой топологии из трех
маршрутизаторов, демонстрация трафика обмена между маршрутизаторами. Ге-
нерация маршрута по-умолчанию в RIPng, возможность отказаться от передачи
любых других маршрутов кроме маршрута по-умолчанию. Демонстрация перехода
в состояние holddown маршрутов, ставших недоступными как в случае отказа
тупикового интерфейса на работающем маршрутизаторе, так и в случае отказа
маршрутизатора, отличия в реализации holddown в RIPng и RIP.
Лабораторная работа по RIPng. Студентам необходимо выполнить задание на
конфигурирование RIPng в сети из трех последовательно подключенных марш-
рутизаторов и проанализировать маршрутные таблицы, способ наращивания
метрики и трафик протокола RIPng в сети. Второе задание посвящено holddown:
необходимо повторить третье задание из предыдущей лабораторной работы для
RIPng и проанализировать отличия в поведении RIPng и RIP, разумеется, после
того, как выясниться, что holddown выключен по-умолчанию, его необходимо
включить и повторить задание.
Урок 6
Протокол маршрутизации EIGRP
Анализ ключевых недостатков протокола RIP:
• большой объем передаваемой по сети маршрутной информации;
• опасность возникновения маршрутных петель;
• невозможность быстро найти альтернативный маршрут в случае недоступ-
ности маршрута в некую сеть.
EIGRP как способ устранения перечисленных недостатков простыми и вполне
эффективными средствами. Классификация протокола EIGRP по описанным ранее
признакам: обмен апдейтами с подтверждением, с последующим обменом только
короткими hello пакетами, передача только измененной информации в случае из-
менения в таблицах маршрутизации. Обмен векторами расстояний, но не обмен
полной топологической информацией. Обобщая классификацию, сперва описыва-
ем простую модель работы EIGRP (скорее это будет похоже на IGRP): почти тот же
общий принцип, что и у RIP, т. е. обмен маршрутами из маршрутной таблицы с их
метрикой, но вместо постоянного обмена полными векторами расстояний, обмен
маршрутными данными с гарантиями доставки (с подтверждением), после чего

только обмен короткими hellо, частичные обновления при изменениях. Отдельно
отмечаем, что расщепление горизонта и poison reverse, как и в RIP, применяются
для того, чтобы не передавать заведомо неверные маршруты, а триггерные об-
новления являются неотъемлемой частью EIGRP, так как регулярных обновлений
протокол не использует. Подчеркнуть, что описанный выше подход устраняет одну
из описанных выше проблем дистанционно-векторных проколов, а именно про-
блему интенсивного трафика обмена маршрутной информацией. Необходимость
вести учет соседей, с которыми производится обмен информацией с гарантиями
доставки, обнаружения соседей, построения таблицы соседей.
Сразу отмечаем, что работа EIGRP практически не зависит от того, для какого
протокола третьего уровня работает протокол, ipv4 или ipv6, не существует отдель-
ного EIGRP для ipv4 и для ipv6, вместо этого существует единственный протокол
EIGRP, который может использоваться как для ipv4, так и для ipv6 маршрутизации,
сравниваем с RIP и RIPng, которые, хотя и весьма похожи, все же разные про-
токолы (разные номера портов, например). Отмечаем, в EIGRP выделяют набор
компонентов, которые привязаны с тому протоколу, для которого выполняется
маршрутизация (PDM) и набор компонентов, которые абсолютно не зависят от
применяемого протокола, например, механизм гарантии доставки сведений о
маршрутах совершенно не зависит от того, о каких маршрутах идет речь) об этих
компонентах речь пойдет ниже, при изучении работы протокола. Описываем, как
EIGRP передается поверх ipv4/ipv6 пакетов непосредственно. Указываем, какие
адреса используются для коммуникаций: при работе поверх ipv4, при необходи-
мости передать мультикаст, используется адрес 224.0.0.10, а в ipv6 сети – ff02::a.
Отмечаем, что в дальнейшем мы будем изучать EIGRP сразу для ipv4 и для ipv6.
Классическая метрика, применяемая в EIGRP. Учет пропускной способности,
задержек, загруженности каналов и надежности каналов. Типичный отказ от
учета загруженности и надежности, по причине частого перестроения маршрут-
ных таблиц. Композитная метрика пути, рассчитываемая как сумма всех вкладов
задержки и вклада пропускной способности самого медленного канала. Невоз-
можность передавать по сети композитную метрику, передача всех компонентов
метрики независимо, расчет композитной метрики на каждом маршрутизаторе
для каждого пути. Метод расчета композитной метрики, коэффициенты k1-k5,
формулы для расчета в случае учета надежности и без учета надежности. Рефе-
ренсные значения пропускной способности и задержек, на которые нормируются
реальные значения. Способ вычисления метрики при распространении инфор-
мации о маршруте между маршрутизаторами: метрика сети для маршрутизатора,
к которому сеть подключена, передача компонентов метрики соседу, нахождение
минимальной пропускной способности из принятой от соседа и пропускной спо-
собности сети, через которую получен апдейт, нахождение суммарной задержки
путем сложения задержки, полученной от соседа и задержки сети, через которую
получен апдейт, вычисление собственной композитной метрики, передача далее

по сети компонентов композитной метрики. Откуда маршрутизаторы берут све-
дения о задержках и пропускных способностях сетей, команды bandwidth и delay
на интерфейсах маршрутизаторов.
Wide метрика, возможность учета дополнительных атрибутов при расчете
метрики, два дополнительных атрибута: jitter и energy, кратко о каждом атрибу-
те, возможность введения новых атрибутов, формула для расчета wide метрики,
коэффициент k6, совместимость классической и wide метрики.
Общий формат пакета eigrp. Поле Header Version. Поле Opcode. Типы пакетов
eigrp, пока говорим только о четырех типах пакетов hello, update, query и reply,
кратко говорим о функциях hello и update, отмечаем, что детально о роли пакета
каждого типа будет идти речь ниже. Поле Flags пока просто упоминаем, флаги
будут рассматриваться в дальнейшем при изучении различных взаимодействий.
Поля Sequence Number и Acknowledged Number, использование данных полей
для нумерации и подтверждения полученных данных. Использование значения
0 в поле Sequence Number, в поле Acknowledged Number, подтверждаемые и не
подтверждаемые пакеты. Поле VRID, без деталей, просто подчеркиваем, что для
обычной маршрутизации применяется значение 0. Номер автономной системы,
необходимость совпадения номеров автономных систем для коммуникаций между
маршрутизаторами. Отмечаем, что все остальные возможности протокола реа-
лизуются путем добавления после последнего поля TLV блоков, которые могут
присутствовать или не присутствовать в каждом отдельном пакете, отмечаем,
что эти TLV блоки мы будем изучать по мере того, как будем рассматривать раз-
личные взаимодействия и изучать пакеты различных типов. Общий формат TLV,
поля Type high и Type low, обзорно о двух версиях TLV: 1.2 и 2.0.
Ключевые отличия алгоритма, на который опирается eigrp от классического
алгоритма Беллмана-Форда, алгоритм DUAL. Возможность в EIGRP относительно
простыми средствами находить не только лучший next hop к некоторой сети дис-
танционно-векторным способом (в терминах eigrp: successor) но и резервный next
hop, с худшей нежели у successor метрикой (feasible successor), при этом маршрут
через feasible successor таков, что принципиально не может вызвать маршрут-
ной петли. Вводим понятия feasible distance (FD), reported distance (RD) и feasible
condition, поясняем максимально подробно, почему выполнение feasible condition
гарантирует, что найденный не лучший маршрут, тем не менее, гарантированно
не порождает маршрутной петли. Особо остановиться на том факте, что feasible
successor может быть найден не всегда, когда на самом деле резервный маршрут
есть, но если он найден, то гарантировано не вызывает маршрутных петель. Важно
отметить, что наличие резервных маршрутов, которые гарантировано не вызывают
петель позволяет, во-первых, быстро переключаться на резервный маршрут в слу-
чае выхода из строя основного, а во-вторых, балансировать нагрузку по маршру-
там не только равной (как в RIP), но и не равной стоимости. Приводим примеры
топологий, в которых есть резервный маршрут и он может быть найден алгорит-

мом DUAL, есть несколько резервных маршрутов и все они могут быть найдены,
есть несколько резервных маршрутов, но только некоторые из них могут быть най-
дены, есть резервный маршрут, но он не может быть найден с помощью алгоритма
DUAL. Поведение маршрутизатора в случае отказа successor при наличии feasible
successor – быстрый выбор нового маршрута. Необходимость ведения отдель-
ной таблицы (помимо таблицы маршрутизации) обо всех найденных маршрутах
(установленных и не установленных в таблицу маршрутизации) – топологической
таблицы, в которой будут храниться как сведения обо всех найденных маршрутах,
так и сведения о RD и FD о каждом маршруту. Особо отметить, что, несмотря на
название, в таблице хранятся не сведения о топологии, а расширенные сведения
о векторах расстояний. Состояния маршрутов в топологической таблице, пока
говорим только о пассивном и активном состоянии. Поведение маршрутизатора
в случае отказа successor и наличия feasible successor – быстрое восстановление
доступности маршрута. Поведение маршрутизатора в случае отказа successor и от-
сутствия feasible successor – перевод маршрута в активное состояние процедура
Query-Reply (очень поверхностно, детали ниже). Подводим промежуточные итоги,
сравниваем подходы RIP и EIGRP к решению подобных задач.
Ставим задачу о дальнейшем изучении EIGRP: необходимо изучить процесс
обнаружения соседей и поддержания состояния смежности с соседями, необходи-
мо изучить процесс инициирующего обмена маршрутной информацией и обмена
изменениями, необходимо изучить процесс обмена Query-Reply для поиска нового
маршрута к сети, доступ к которой утрачен.
Процесс обнаружения соседей. Отправка hello пакетов мультикастом в сеть,
hello таймер, формат hello пакетов, обнаружение соседей. Нулевые значения полей
Sequence Number (такие пакеты не нужно подтверждать) и Acknowledged Number
(посланный мультикастом пакет не может подтверждать получение информации
от конкретного соседа) в таких hello пакетах. TLV, типично включаемые в hello
пакеты: PARAMETER_TYPE, формат и значение полей и SOFTWARE_VERSION_
TYPE, формат полей. Согласование параметров k1-k5(k6) и номера автономной
системы для успешного установления отношений смежности. Формирование
таблицы соседей, поддержание таблицы соседей. Hello и hold интервалы для раз-
личных типов сетей.
Параллельно демонстрируем основы конфигурирования EIGRP для ipv4 и для
ipv6. Демонстрация включения EIGRP для для ipv4. Команда network, возможность
давать команду network с маской (обычно wildcard и сетевой в некоторых ios).
Демонстрация включения EIGRP для для ipv6, включение интерфейсов в процесс
EIGRP на интерфейсах. Демонстрация заголовка EIGRP, работающего поверх ipv4/
ipv6, анализ полей заголовка на примере hello пакетов, TLV, включаемые в hello.
Таблица соседей, просмотр таблицы соседей.
Процесс передачи маршрутной информации между соседями. Инициирующий

обмен между маршрутизаторами после обнаружения соседа, юникаст комму-
никации, отправка пустого пакета update с флагом Init (вспоминаем, что изучая
заголовок, мы пропустили флаги, это – первый флаг), цели, с которыми исполь-
зуется такой NULL Update, поведение маршрутизатора, получившего такой пакет.
Пакеты update, используемые для передачи маршрутной информации, юникаст
передача нумерованной информации конкретному соседу, подтверждение по-
лученной информации с помощью юникаст hello пакетов. Использование поля
Acknowledged Number для квитирования полученной информации. Особо отме-
тить, что в eigrp нет специального типа пакета для подтверждения полученной
маршрутной информации (хотя часто в литературе написано, что есть), вместо
этого применяются пакеты типа hello, отправляемые юникастом, у таких пакетов
поле Acknowledged Number не равно нулю и используется для квитирования, от-
метить, что такие hello пакеты отправляются наряду с мультикаст hello пакетами
и не заменяют их, кроме того такие hello пакеты не содержат никаких TLV – все,
для чего посылается такой пакет находится в поле Acknowledged Number.
Передача изменений (изменений метрики и новых маршрутов) в маршрут-
ной информации соседу, с которым уже установлена смежность: отправка update
пакетов при необходимости сообщить соседу об изменениях, так как весь обмен
данными происходит с гарантией, то достаточно передавать только изменения,
а не полный вектор расстояний. Особо отметить, что в отличие от инициирую-
щего обмена, передача изменений производиться мультикастом, однако каждый
сосед обязан послать подтверждение полученных сведений с помощью юникаст
hello пакета. Контроль отправителя апдейта за поступающими подтверждениями
от всех соседей независимо. Ситуация, при которой в ответ на мультикаст update
подтверждения поступают не от всех известных соседей, состояние Conditionally
Received, в которое маршрутизатор переводит всех соседей, которые должны про-
должать работать с мультикаст апдейтами, отправка дальнейших мультикаст ап-
дейтов с флагом CR (это второй флаг заголовка, мы его пропустили ранее), переход
на юникаст коммуникации с соседями, которые имеют не подтвержденные апдей-
ты. Способ уведомления о переходе в режим Conditionally Received, hello пакет
с TLV SEQUENCE_TYPE, использование TLV MULTICAST_SEQUENCE_TYPE.
Изучаем TLV, переносящие информацию о маршрутах. Сперва показываем, как
кодируется классическая метрика, поясняем, что передается в полях Scaled Delay
(обращаем внимание, как передается с помощью этого поля недоступность сети)
и Scaled Bandwidth, флаги пока пояснять рано. Затем показываем, как кодируется
сеть назначения, отмечаем компактность записи, после этого показываем TLV
типа 0102, который переносит информацию об ipv4 префиксе, включая метрику
и TLV типа 0402, который переносит информацию об ipv6 префиксе, включая
метрику. Отмечаем, что изученные TLV относятся к версии TLV 1.2, говорим о
том, что в новой версии TLV нет отдельных TLV для ipv4/ipv6 префиксов, вместо
этого есть один TLV, который переносит информацию о префиксе, включая и ин-
формацию о том, к какому протоколу она относится. Показываем, как кодируется
wide метрика, что передается в полях Delay (обращаем внимание, как передается
с помощью этого поля недоступность сети) и Bandwidth, оговариваем возможность
передавать дополнительные атрибуты, но детально об этом не рассказываем. По-
казываем, как кодируется сеть назначения, после чего показываем общий формат
TLV 0602, обращаем внимание на поле AFI, с помощью которого указывается
протокол третьего уровня, чей маршрут переносится в TLV, еще раз подчеркива-
ем, что в TLV версии 2.0 есть только один TLV (0602) для передачи как ipv4, так
и ipv6 префикса. Поведение систем, у которых есть соседи, поддерживающие TLV
1.2 и соседи, поддерживающие TLV 2.0, отправка сведений о префиксах дважды.
Демонстрация инициализирующего обмена маршрутами после установки
отношений смежности между маршрутизаторами в ipv4/ipv6. Особо отмечаем
использование флага Init и NULL Update, подтверждения с помощью hello. Де-
монстрируем подробно TLV, переносящие ipv4/ipv6 маршруты, как версии 1.2, так
и версии 2.0 (для версии 1.2 необходимо использовать старый ios). Демонстрация
передачи сведений о новом маршруте между маршрутизаторами, которые уже име-
ют отношения смежности, квитирование. Демонстрируем переход с мультикаст на
юникаст для отдельного маршрутизатора, который не присылает подтверждения
(его нужно предварительно отключить его от сети, а затем включить). Изменение
метрики маршрутов, команды delay и bandwidth, демонстрация передачи обнов-
ленных метрик. Просмотр и анализ топологической таблицы EIGRP.
Рассматриваем детальнее процедуру поиска маршрута в том случае, если
successor не доступен и для маршрута нет feasible succesor. Переход маршрута в со-
стояние Active, отправка Query мультикастом через все интерфейсы, задейство-
ванные в eigrp процессе. TLV, включаемые в Query, флаг Active в блоке с метрикой
в TLV. Особо отметить, что маршрутизатор не отправляет Update с указанием
недостижимой метрики при утрате маршрута в сеть (как это делает RIP), вместо
этого ту же самую информацию он передает соседям с помощью Query, это значит,
что даже источник маршрута, у которого отказал интерфейс в соответствующую
сеть тоже должен отправлять Query так, как описано. Поведение маршрутизатора,
получившего Query в случае, когда у него есть маршрут – отправка Reply с марш-
рутом, TLV, включаемые в пакет Reply. Поведение маршрутизатора, получившего
Query в случае, когда у него нет маршрута – перевод маршрута в состояние Active,
отправка собственных Query всем своим соседям. Каскадное распространение
Query по сети, нахождение маршрута в том случае, если это возможно, переход
сети в состояние Active на всех маршрутизаторах сети, распространение Reply
с информацией о недоступности сети если маршрут не может быть найден. Особое
внимание следует уделить тому, что Reply не может быть послан маршрутизатором
до тех пор, пока он не получил Reply в ответ на свой Query от всех своих соседей.
Гарантии доставки при отправке Query/Reply. Мультикаст для передачи Query,
квитирование полученных Query в помощью юникаст Hello. Отправка юникаст

Query в случае отсутствия квитанций от отдельных соседей. Юникастовые Reply
в ответ на мультикаст/юникаст Query, квитирование Reply с помощью юникаст
Hello. Пример успешного поиска маршрута с помощью процедуры Query-Reply,
пример удаления маршрута из таблиц маршрутизации всех маршрутизаторов
в случае, когда маршрут на самом деле полностью недоступен. О состоянии SIA
в этом курсе не говорим.
Демонстрируем работу EIGRP в ситуации, когда маршрут в некоторую сеть
пропадает. Сперва строим топологию, в которой у некоторого маршрутизатора
будет feasible successor в некоторую есть, делаем для successor для него доступным,
демонстрируем быстрый выбор feasible successor в качестве successor и отсутствие
обмена Query/Reply. Затем демонстрируем ситуацию, в которой feasible successor
отсутствует, но механизм Query/Reply позволит найти новый маршрут в недо-
ступную сеть. Наконец, демонстрируем работу протокола в ситуации, когда сеть
полностью недоступна и механизм Query/Reply приводит к полному удалению
маршрутов в сеть из таблиц всех маршрутизаторов.
Демонстрируем автоматическую суммаризацию в EIGRP для ipv4, отключение
автоматической суммаризации. Включение ручной суммаризации для ipv4 и ipv6.
Опасности суммаризации, возможность возникновения маршрутных петель (на-
помнить). Пропускная способность канала, которую может использовать EIGRP
для своих нужд, конфигурирование ограничения на пропускную способность
канала, особо отметить, что данные ограничения касаются только EIGRP трафика,
но не трафика, который маршрутизируется.
Демонстрация настройки таймеров hello и hold, оптимизация скорости сходи-
мости путем изменения таймеров. Балансировка нагрузки между каналами равной
стоимости в EIGRP, продемонстрировать пример, в котором в таблицу маршру-
тизации попадает два маршрута с одинаковой метрикой. Балансировка нагрузки
между каналами неравной стоимости, демонстрация включения unequal cost load
balancing, особо отметить, что для того, чтобы маршрутизация осуществлялась
по маршрутам с не лучшей стоимостью, эти маршруты должны удовлетворять
FC, демонстрация примера, в котором в таблице маршрутизации оказываются
маршруты разной стоимости.
Аутентификация в EIGRP. Напоминаем, почему сообщения протокола марш-
рутизации должны быть достоверными. Обращаем внимание, что как и в случае
с RIP, речь не идет шифровании сообщений, только об обеспечении их аутентич-
ности. Отсутствие аутентификации открытым текстом в EIGRP, поддержка только
аутентификации на основе алгоритмов md5 и sha1, поддержка только md5 боль-
шинством ios. TLV 0002, предназначенный для аутентификации, поле Auth Type
и его значения для md5/sha1. Конфигурирование аутентификации: напоминаем
про цепочки ключей, демонстрируем настройки аутентификации.
Включение маршрута по-умолчанию в EIGRP апдейты. Способ первый: при

наличии маршрута по-умолчанию в таблице маршрутизации можно дать команду
network 0.0.0.0 и такой маршрут будет включен в EIGRP, ясно, что такой способ не
подходит для ipv6, так как там нет команды network. Концепция default-network
в ios, безотносительно к eigrp. Таблица маршрутизации устройства, на котором
дана команда ip default-network. Передача маршрута, отмеченного как default-
network с помощью eigrp, использование флага CD при анонсе такого маршру-
та. Особо отметить, что при таком способе настройки маршрута по-умолчанию
в таблице маршрутизации не появляется маршрут к 0.0.0.0/0. Классовій характер
команды ip default-network, объявление подсети как default-network, появление
дополнительной статической маршрутной записи, дополнительная команда ip
default-network для классовой сети. Отметить, что и такой способ не подходит для
ipv6. Универсальный способ передать маршруты, полученные от одного источника
с помощью другого протокола маршрутизации, введение в редистрибьюцию, ко-
манда redistribute static, отметить, что подробно редистрибьюция будет изучаться
позже. Демонстрация описанных выше способов.
Лабораторная работа по всему изученному материалу. В первом задании сту-
денты должны изучить процесс установки смежности, инициирующего обмена
маршрутными данными и распространение информации о новом маршруте по
сети для ipv4 и ipv6, включая и анализ трафика. Второе задание должно быть по-
священо конфигурированию, в топологии необходимо предусмотреть наличие
резервных маршрутов к некоторым сетям на некоторых маршрутизаторах, также
заданию должно включать ручную суммаризацию, аутентификацию и передачу
маршрута по-умолчанию.
Урок 7
Протокол маршрутизации OSPF
Детальное описание данного модуля будет в обновленной версии программы.
Урок 8
Основы VPN
Образы IOS и лицензирование

Урок 9
Протокол маршрутизации BGP
Повторение концепции автономной системы, внутренних и внешних протоколов
маршрутизации. Обсуждение, почему может одновременно применяться несколь-
ко различных igp, но только один внешний протокол, роль bgpv4 в современном
Интернете. Роль bgp для обмена маршрутной информацией в Интернет. Важно
подчеркнуть, что использование bgp ограничено только маршрутизацией с дру-
гими автономными системами, совместное использование igp и bgp.
Классификация bgp с точки зрения способа достоверного обмена данными.
Использование tcp для установки надежного соединения между пирами, отсут-
ствие необходимости подтверждать полученные данные (это делает tcp). Обмен
keepalive сообщениями (аналог hello), пояснить, что tcp хорошо работает, только
когда происходит постоянный обмен данными, если же оба участника соединения
молчат, но контроль наличия соединения в tcp реализован весьма слабо, следова-
тельно механизм, аналогичный hello все равно необходим. Отсутствие автомати-
ческого обнаружения соседей, все смежности исключительно явно настроенные.
Классификация bgp с точки зрения способа обмена маршрутной информацией.
Остановиться на том, почему протокол, работающий между огромным числом
слабо связанных автономных систем не может опираться на построение полных
топологий (полных топологий чего?), подчеркнуть, что bgp является дистанцион-
но-векторным протоколом. Однако необходимо тут же обратить внимание студен-
тов на особенности, отличающие bgp от классических дистанционно-векторных
протоколов: в таких протоколах (rip, например), задача протокола маршрутизации
состоит в том, чтобы найти наилучший маршрут с точки зрения одного единствен-
но параметра – метрики, она может плохая, как в rip, или хорошая как в eigrp,
но лучший маршрут в таких протоколах это маршрут с минимальной метрикой.
Подчеркнуть, что отличие bgp в том, что в маршрутизации между автономными
системами большое внимание уделено административному влиянию на выбор
маршрутов, иными словами очень часто вместо автоматического поиска лучшего
маршрута важно предоставить администратору системы инструменты для управ-
ления выбором лучшего маршрута на основании многих факторов. Подчеркнуть,
что каждый маршрут вместо одной метрики снабжается целым рядом атрибутов,
которые могут приниматься во внимание при выборе лучшего маршрут, отметить,
что мы будем изучать целый ряд атрибутов, которые характеризуют маршрут
и могут приниматься во внимание при выборе лучшего маршрута.
Важно обратить внимание студентов на то, что bgp, как и любой другой дис-
танционно-векторный протокол сталкивается с проблемой маршрутных петель.
Не вдаваясь на данном этапе в отличия ebgp и ibgp, следует рассказать о том, как
обеспечивается защита от петель при обмене маршрутами между автономными
системами. Поясняем, что каждой автономной системе присваивается номер AS
(2 байта, возможна поддержка расширенного номера, длиной 4 байта, детали поз-

же), и каждый маршрут, который передается по bgp содержит в себе в качестве
одного из атрибутов список всех автономных систем, которые маршрут прошел
(AS-Path). Поясняем, как заполняется AS-Path и происходит защита от петель по
мере продвижения маршрута между автономными системами. Также отмечаем,
что AS-Path, помимо защиты от петель, имеет еще одну функцию – он может вы-
ступать в качестве инструмента выбора лучшего маршрута – у какого маршрута
короче AS-Path, тот маршрут и лучше. Особо отметить, что такая своеобразная
«метрика» является далеко не самым первым критерием выбора маршрута, более
подробно о выборе лучшего маршрута и роли AS-Path будет рассказано позже.
Типы пакетов bgp. Пакет open, которым обмениваются маршрутизаторы сразу
после установки tcp соединения для установки bgp смежности, оговаривание па-
раметров будущего взаимодействия. Пакет update, содержащий сведения о марш-
рутах, добавляемых или удаляемых, еще раз подчеркнуть, что подтверждение
получения update не требуется, так как гарантии доставки обеспечивает tcp. Пакет
keepalive, аналогичный hello в уже известных протоколах, пакет Notification для
уведомления об ошибках перед разрывом смежности и tcp соединения.
Формат заголовка bgp, назначения полей маркер, длина и тип. Пакет Open,
формат пакета, поля Version, My Autonomous System, Hold Time, BGP Identifier.
Особое внимание следует уделить полю My AS, подчеркнуть, что каждая сторона
соединения должна быть сконфигурирована таким образом, чтобы знать номер
автономной системы пира, несовпадение ожидаемого номера AS пира и его указан-
ного в Open номера ведет к отказу от установки соединения; важно пояснить, что
такое Hold Time и как стороны согласуют Hold Time, а также как стороны выби-
рают интервал для отправки keepalive. Поля Optional Parameters Length и Optional
Parameters, описание с помощью TLV дополнительных функций и возможностей,
без детализации. Формат сообщения keepalive, указание типа keepalive, отсутствие
других данных в пакете.
Формат сообщения Update. Назначение полей Withdrawn Routes Length,
Withdrawn Routes, Total Path Attribute Length, Path Attributes, Network Layer
Reachability Information, формат каждого из полей. Возможность указать на не-
доступность ранее анонсированных маршрутов, сообщить новые маршруты со
всеми их атрибутами, сделать и то и другое. Обратить внимание, что один ком-
плект атрибутов может быть сопоставлен не одному, а нескольким префиксам, под-
черкнуть, что для того, чтобы сообщить о маршрутах с различными атрибутами
нужно отправить несколько отдельных Update, возможность передать несколько
Update в одном bgp пакете. Общий формат сообщения Notification, без рассмотре-
ния конкретных ошибок.
Затем рассматриваем, как происходит установка смежности между пирами.
Установка tcp соединения между пирами, обмен пакетами Open, проверка соот-
ветствия номера AS пира. Отправка keepalive после успешной проверки Open,
отправка Notification после получения неожиданного номера AS. Состояния bgp

соединения, что означает зависание пира в определенном состоянии.
Базовые настройки bgp в ios. Включение процесса bgp, настройка router-id,
настройка пира (показываем пример с маршрутизаторами из разных автономных
систем), процесс установки соединения, обмен Open пакетами. Просмотр све-
дений о пирах, просмотр bgp таблицы, пока не обращая внимание на атрибуты.
Анонсирование маршрутов внешнему bgp пиру. Два способа включить маршру-
ты в bgp процесс: редистрибьюция из igp и явное указание с помощью network,
сравнительный анализ двух подходов. Синтаксис команды network, анонсирова-
ние маршрутов, присутствующих в таблице маршрутизации, автосуммаризация.
Примеры анонсирования маршрутов, процесс обмена update, удаление маршрутов.
Подводим итог: мы рассмотрели, как граничные маршрутизаторы AS передают
маршруты в другие AS и как получают маршруты из других AS, теперь переходим
к рассмотрению работы bgp внутри AS.
Рассматриваем пример транзитной автономной системы, в которой присут-
ствует несколько граничных маршрутизаторов, задаемся вопросом, как должны
быть связаны эти граничные маршрутизаторы в рамках bgp. Рассматриваем про-
стой пример, в котором между этими маршрутизаторами есть bgp пиринг, анали-
зируем, как маршрутизируются пакеты между граничными маршрутизаторами
в случае, когда между ними есть транзитные маршрутизаторы, на которых bgp не
запущен. Делаем вывод, что маршруты во внешние сети должны быть доступны на
всех транзитных маршрутизаторах, рассматриваем два решения: редистрибьюция
из bgp в igp (пояснить, почему сегодня это не разумно) и запуск bgp на всех тран-
зитных маршрутизаторах автономной системы. Проблема передачи маршрутов
внутри автономной системы, связанная с отсутствием механизма защиты от петель
внутри AS с помощью AS-Path, необходимость отдельного механизма защиты от
петель внутри автономной системы. Расщепление горизонта при взаимодействии
между маршрутизаторами внутри одной автономной системы, понятие о ibgp
и ebgp. Важно подчеркнуть, что протокол обмена bgp не изменяется, меняется
лишь поведение пиров в зависимости от того, в одной или разных автономных
системах находятся пиры. Запрет передавать по ibgp то, что получено по ibgp, как
следствие – необходимость попарного пиринга между всеми маршрутизаторами
автономной системы, на которых запущен bgp. Обратить внимание но то, что в от-
личие от ebgp пиринга, в котором пиры чаще всего находятся в одной канальной
сети, при ibgp пиринге пиры в общем случае не находятся в одной канальной сети,
ip адреса, используемые для пиринга, применение loopback адресов, необходимость
включать эти адреса в igp. Нахождение адреса следующего маршрутизатора для
маршрутов, полученных по bgp. Обратить внимание, что в дистанционно-век-
торных igp адрес следующего маршрутизатора обычно не передается в протоколе,
таковым полагается адрес того, что прислал маршрут. Атрибут next-hop в bgp,
указание себя в качестве next-hop в ebgp, сохранение next-hop, полученного по
ebgp при передаче маршрута по ibgp. Важно пояснить на примере причины такого
поведения в ibgp, отметить, что такое поведение ibgp можно отменить (next-hop-
self). Важные выводы из описанного поведения: внешние интерфейсы граничных
маршрутизаторов необходимо включать в процесс igp (например, как пассивные
интерфейсы) и маршрут, найденный с помощью bgp может потребовать допол-
нительного lookup в таблице маршрутизации, преимущества cef, позволяющие
сделать этот lookup заранее. Сравнение записей в таблице маршрутизации и cef
таблице о маршруте за пределы AS на внутреннем маршрутизаторе. Пример на-
стройки транзитной автономной системы с внутренними маршрутизаторами,
анализ обмена маршрутами.
Роль igp и bgp внутри автономной системы, маршруты, обслуживаемые про-
токолами. Передача по bgp только внешних маршрутов, обслуживание магистрали
с помощью igp, обеспечение доступности внутренних маршрутизаторов для ibgp
пиринга, обеспечение доступности next-hop для bgp. Что происходит, если неко-
торые маршруты обрабатываются и igp и bgp, административные дистанции bgp.
Альтернативное конфигурирование транзитной автономной системы: реди-
стрибьюция из bgp в igp, ограничения такого подхода, связанные с большим ко-
личеством маршрутов. Понятие о синхронизации bgp, поведение маршрутизато-
ра с синхронизацией/без синхронизации, отличия. Преимущества и недостатки
синхронизации, включение/выключение синхронизации. Области применения
редистрибьюции внешних маршрутов в igp.
Атрибуты bgp. Классификация атрибутов well known (mandatory, discretionary)
и optional (transitive, non transitive).
Well Known mandatory атрибуты. Атрибут AS-Path. Как генерируется AS-Path
в новом маршруте, как заполняется AS-Path при продвижении маршрута между
автономными системами. Роль AS-Path как инструмента защиты от петель в ebgp,
роль AS-Path как инструмента выбора лучшего маршрута (с более коротким AS-
Path) в том случае, если другие, более важные атрибуты не привели к выбору
лучшего маршрута. Подчеркнуть, что для «удаленных» сетей, для которых адми-
нистративное влияние администратора не применяется, AS-Path является атрибу-
том, который часто приводит к выбору того или иного маршрута в качестве наи-
лучшего. Фильтрация входящих маршрутов с помощью route-map на основании
AS-Path, регулярные выражения для анализа строки AS-Path, пример. Концепция
AS-Path Prepandig как инструмент управления входящим трафиком, выполнение
prepanding с помощью route-map. Атрибут Next-Hop, значение атрибута в ebgp/
ibgp, заполнение атрибута при генерации маршрута внутри AS. Манипуляции
Next-Hop, next-hop-self. Атрибут Origin, возможные значения. Использование
атрибута Origin как критерия для выбора лучшего маршрута.
Атрибут weight, подчеркиваем, что он локальный и проприетарный, в пакетах
не передается. Приводим примеры применения атрибута weight для выбора луч-
шего маршрута, подчеркиваем, что данный атрибут является первым критерием
для выбора лучшего маршрута, все прочие критерии принимаются во внимание

только если значения weight для двух и более маршрутов совпадают. Манипуляции
атрибутом weight с помощью route-map.
Атрибут Local Preference. Применение LP для управления трафиком, исходя-
щим из автономной системы, подчеркнуть, что LP при выборе лучшего маршру-
та принимается во внимание первым после weight, манипуляции LP с помощью
route-map, примеры.
Атрибут MED. Применение MED для управления входящим в автономную
систему трафиком. Особо подчеркнуть область распространения MED, обратить
внимание студентов, что MED не самый приоритетный атрибут при выборе лучше-
го маршрута, поэтому часто изменение MED не приводит к жулаемому результату.
Манипуляции LP с помощью route-map, примеры.
Критерии выбора лучшего маршрута в bgp, последовательное рассмотрение
всех инструментов выбора лучшего маршрута в порядке убывания приоритета.
Суммаризация в bgp, атрибуты Aggregator и Atomic Agregate. Конфигуриро-
вание суммаризации.
Атрибут Community, область применения атрибута, манипуляции атрибутом
с помощью route-map.
Использование четырехбайтого номера автономной системы.
Использование route-map для фильтрации отправляемых и принимаемых
маршрутов. Реконфигурация. Жесткая реконфигурация, сброс сессии, недостатки.
Мягкая outbound реконфигурация, особенности выполнения. Мягкая inbound
реконфигурация, сложности, связанные с тем, что принимающая сторона ранее
выполняла фильтрацию маршрутов, и в bgp таблице нет некоторых маршрутов,
а у пира нет информации о том, какие маршруты были отфильтрованы на входе,
команда neighbor <address> soft-reconfiguration inbound. Технология route refresh,
согласование поддержки route refresh при устновке соединения, выполнение route
refresh. Сравнение всех механизмов реконфигурации.
Технология ORF. Возможность применить нужный фильтр не на входе, а на
выходе пира, необходимость передать пиру правила фильтрации. Передача правил
фильтрации с помощью route refresh, конфигурирование ORF.
Кратко об оптимизации работы ibgp в больших системах, неудобство full mesh
пиринга, концепция route reflector, настройки сети с route ferlector.
Аутентификация в BGP. Методы аутентификации, конфигурирование аутен-
тифиакции.
Multiprotocol bgp, поддержка ipv6, настройки bgp для поддежки ipv6, особен-
ности, связанные с одновременной работой ipv4/ipv6.
Лабораторные работы для практического закрепления знаний по конфигури-
рованию BGP.
Самостоятельная проработка модуля 7 курса CCNP ROUTE.
Урок 10
Оптимизация маршрутизации
До сих пор мы много говорили о том, как строятся маршрутные таблицы, и отно-
сительно мало говорили о том, как происходит обработка пакетов при маршрути-
зации, по сути мы ограничились описанием двухуровневой иерархии маршрутов
(сети/суперсети/дефолт и подсети) и говорили только о программной маршрути-
зации. Теперь рассматриваем эти вопросы более детально. Разделение функций
построения маршрутных таблиц (всегда программно) и продвижения пакетов
(программно или аппаратно), вводим понятия control plane и data plane, функции.
Три механизма продвижения пакетов в маршрутизаторах. Process switching, про-
граммная обработка каждого пакета, поступившего на маршрутизатор, этапы
обработки пакета: поиск строки в таблице маршрутизации, поиск выходного ин-
терфейса, поиск адреса канального уровня, формирование заголовка канального
уровня, анализ такого подхода, недостатки. Оптимизация продвижения пакетов,
fast switching. Обработка первого пакета потока с помощью process switching, со-
хранение результатов в fast-switching cache, включая заголовок канального уровня
для продвижения пакетов, последующая аппаратная маршрутизация без участия
центрального процесса с помощью fast-switching cache, преимущества по сравне-
нию с process switching. Cisco Express Forwarding (CEF), предварительное создание
FIB в специальной памяти и аппаратное продвижение всех пакетов без участия
центрального процессора. Глобальное включение cef, отключение/включение cef
на интерфейсах, просмотр fib и adjacency table, структура записей в таблицах.
Использование нескольких проколов маршрутизации в иерархической сети.
Причины использования нескольких протоколов маршрутизации в сети, понятие
о редистрибьюции маршрутов между различными протоколами маршрутизации.
Напомнить, что маршруты включаются в протокол маршрутизации с помощью
команды network или активации протокола маршрутизации на интерфейсе, ре-
дистрибьюция как еще один инструмент включения маршрута в протокол марш-
рутизации. Особо подчеркнуть, что в процессе редистрибьюции не происходит
взаимодействия между процессами, реализующими протоколы маршрутизации,
вместо этого протокол, который хочет включить в свою работу маршруты, доступ-
ные с помощью другого протокола, берет соответствующие маршруты из таблицы
маршрутизации, иными словами редистрибьюция всегда pull (тянет), и никогда
push (толкает). Простой пример: маршрутизатор с двумя интерфейсами, с одной
стороны ospf, с другой eigrp, редистрибьюция между протоколами маршрутизации
для обеспечения всех маршрутизаторов сети всеми маршрутами. Особо подчер-
кнуть, что редистрибьюция всегда однонаправленная, любая двунаправленная
редистрибьюция – сумма двух однонаправленных. Усложняем пример, пусть из
каждого домена маршрутизации поступают сведения об одном и то же маршруте,
как выбрать оптимальный маршрут? Подчеркнуть, что граничный маршрутизатор,
получая маршруты из двух разных источников, не может сравнивать метрики раз-

личных протоколов для выбора лучшего маршрута, обсудить принципиальную
невозможность сравнивать численные значения метрик. Понятие об администра-
тивной дистанции, как степени доверия к протоколу маршрутизации, администра-
тивные дистанции изученных ранее источников маршрутов. Важно подчеркнуть,
что административная дистанция используется только для сравнения одинаковых
маршрутов, если у маршрутизатора есть маршруты с одинаковыми номерами сетей
но различными префиксами, полученные из различных источников, то в таблицу
маршрутизации инсталлируются все эти маршруты.
Метрика маршрута, полученного посредством редистрибьюции, невозмож-
ность наследовать метрику от протокола-источника, понятие seed метрики. Seed
метрики различных протоколов маршрутизации, подчеркнуть, что в rip/eigrp
нулевая seed метрика по-умолчанию указывает на недостижимость, поэтому при
редистрибьюции в эти протоколы необходимо указывать seed метрику явно, seed
метрики ospf/isis. Подчеркнуть, что при настройке редистрибьюции во все про-
токолы маршрутизации всегда можно сконфигурировать seed метрику и фильтр
для маршрутов в помощью route-map (изучаются далее), на при этом могут быть
и дополнительные параметры, связанные как с протоколом ИЗ которого выпол-
няется редистрибьюция, так и с протоколом В который выполняется редистри-
бьюция, в зависимости от протоколов источника и получателя маршрутов. По-
следовательно рассматриваем каждый протокол маршрутизации и показываем
его особенности как получателя маршрутов и как источника маршрутов.
Дальнейшее изучение необходимо проводить, демонстрируя настройки реди-
стрибьюции в IOS. Сперва показываем редистрибьюцию в rip, напоминаем, что
seed метрика равна нулю и недостижима, показываем настройку дефолтной seed
метрики для rip, настройку метрики для конкретной редистрибьюции, других
особенностей у rip как у получателя маршрутов и как источника маршрутов нет.
Редистрибьюция из/в eigrp, особенности. Seed метрика при редистрибьюции
в eigrp равна нулю и недостижима, поэтому либо настраивается ненулевая seed
метрика для процесса eigrp, либо указывается явная seed метрика при настройке
редистрибьюции, исключения: seed метрика для connected и static маршрутов
равны метрике соответствующего интерфейса, важно отметить, что eigrp разли-
чает внутренние и внешние маршруты, административная дистанция внешних
маршрутов по-умолчанию равна 170.
Редистрибьюция из/в ospf, особенности. Seed метрика при редистрибьюции
в ospf, типы маршрутов (E1/E2) при редистрибьюции в ospf. Важно отметить, что
в ospf по-умолчанию попадают только классовые+ сети, для включения подсетей
необходимо указывать subnet. Редистрибьюция из ospf, возможность указывать
типы маршрутов для редистрибьюции (внутренние, внешние, nssa).
Редистрибьюция из/в isis, особенности. Seed метрика при редистрибьюции
в isis, возможность ввести маршрут как level1, level2, level1-2, возможность ввести
маршрут как внутренний или как внешний. Редистрибьюция из isis, возможность

брать level1, level2, level1-2 маршруты.
Редистрибьюция статических и подключенных маршрутов, области примене-
ния. Редистрибьюция между classless и classfull протоколами, только общая идея,
без особой детализации. Примеры редистрибьюции между ripv1 и ospf. Пример,
в котором у rip маска короче, статический маршрут с маской равной маске rip через
null0 и его последующая редистрибьюция. Пример, в котором маска у rip длинее,
статические маршруты с маской, равной маске rip (через правильные интерфейсы,
не null0) и его редистрибьюция.
После рассмотрения базовых возможностей и настроек редистрибьюции пере-
ходим к рассмотрению проблемных вопросов, связанных с использованием не-
скольких граничных маршрутизаторов между доменами маршрутизации. Сперва
рассматриваем простейший пример, в котором есть два граничных маршрутиза-
тора, и только на одном из них выполняется однонаправленная редистрибьюция
из rip в ospf, демонстрируем, что даже в этом случае имеет место не оптималь-
ная маршрутизация на втором граничном маршрутизаторе. Подчеркиваем, что
если точек редистрибьюции две (или более), то проблем становится еще боль-
ше, рассматриваем пример (rip/ospf) в котором двунаправленная редистрибью-
ция выполняется в двух точках. Сперва демонстрируем проблему с AD: один из
пары граничных маршрутизаторов анонсирует rip маршрут в домен ospf, второй
граничный маршрутизатор получая такой маршрут, записывает его в таблицу
маршрутизации вместо rip маршрута, после чего, не имея rip маршрута, уже не
выполняет редистрибьюцию из rip в ospf по причине отсутствия rip маршрута,
после чего в маршрутизация из всего домена ospf в домен rip происходит только
через один граничный маршрутизатор. Анализ причин проблемы, вывод о том, что
административная дистанция внешних маршрутов для пары протоколов должны
быть больше, чем административная дистанция внутренних маршрутов другого
протокола. Анализ пар протоколов с точки зрения автоматического выполнения
этого правила. Подчеркнуть, что eigrp корректно работает с любым другим igp,
пояснить почему, проанализировать все пары протоколов, продемонстрировать
изменение административной дистанции для внешних маршрутов у eigrp/ospf
как способ решить описанную проблему. Анализ пары rip/isis, для которой такой
подход невозможен, изменение административной дистанции для конкретных
маршрутов как альтернативный способ решения проблемы. Оптимизация марш-
рутов с помощью изменения AD для конкретных маршрутов вместо изменения
AD для всех внешних маршрутов.
Рассматриваем вторую проблему: feedback маршруты. Приводим пример, в ко-
тором присутствует описанная ранее проблема с административными дистанци-
ями, демонстрируем что в этом случае возможна ситуация, когда маршруты, по-
рожденные в домене маршрутизации возвращаются в этот домен маршрутизации
из другого домена, в качестве примера приводим пару rip/ospf, обращаем внимание
студентов, что это не только не оптимально, но и может приводить к появлению

маршрутных петель. Защита от feedback маршрутов с помощью корректной на-
стройки административных дистанций на граничных маршрутизаторах как это
описано выше, защита от feedback маршрутов с помощью использования «плохих»
seed метрик. Борьба с feedback маршрутами путем ограничения редистрибьюции
таким образом, чтобы маршруты, полученные из некоторого домена маршрути-
зации в него никогда не могли быть отправлены, детали реализации таких огра-
ничений ниже. Подведение итогов по проблемам редистрибьюции в нескольких
точках.
Задача об ограничении распространения маршрутной информации с помощью
протоколов маршрутизации, примеры, демонстрирующие важность таких ограни-
чений. Использование суммаризации и маршрутов по-умолчанию для уменьшения
количества маршрутов. Использование тупиковых областей в ospf. Использование
пассивных интерфейсов как простейший способ ограничивать передачу маршрут-
ной информации. Отличия в реализации пассивных интерфейсов в различных
протоколах маршрутизации.
Задача об избирательной фильтрации маршрутов. Инструмент distribute-list.
Напомнить, что ACL это не пакетный фильтр, а инструмент, получающий на вход
некие объекты (пакеты, маршруты etc), и возвращающий permit/deny, а что делать
с permit или deny решает тот, кто вызвал ACL. Использование ACL для фильтрации
маршрутов, передаваемых/принимаемых протоколом маршрутизации. Почему для
такой фильтрации нельзя использовать ACL в качестве пакетного фильтра (т. е.
инструментов ip access-group/ipv6 traffic-filter), distribute-list как инструмент для
фильтрации не пакетов, а маршрутов. Применение distribute-list для фильтрации
входящих/исходящих маршрутов протокола маршрутизации на соответствующих
интерфейсах интерфейсах, использование ACL для описания правил фильтрации.
Ограничения ACL, связанные с обработкой маршрутов: необходимость ТОЧНОГО
соответствия маршрутов правилам, невозможность фильтровать, например, все
подсети сети 192.168.0.0/16, такое правило будет фильтровать лишь непосред-
ственно сеть 192.168.0.0.16. Использование prefix-list вместо ACL для фильтрации
маршрутов с помощью distribute-list. Особенности фильтрации маршрутов в ospf,
маршруты должны попадать в lsdb, но не в таблицу маршрутизации.
Использование distribute-list для фильтрации маршрутов при редистрибьюции.
Подчеркнуть, что нельзя контролировать маршруты с точки зрения протокола,
который отдает маршруты, можно лишь контролировать какие маршруты будут
взяты из маршрутной таблицы, примеры конфигурирования.
Подчеркнуть, что ACL позволяют выбрать подходящий под некоторые правила
пакеты, сети, маршруты, но не могут ничего изменить, например можно разрешить
с помощью ACL/Distribute-list редистрибьюцию некоторого маршрута, но нельзя
изменить для него метрику, тип маршруты и т. д. Инструмент route-map, позво-
ляющий не только выбрать пакеты/маршруты (в зависимости от того, кем и как
он вызывается), но и внести в пакет/маршрут некоторые изменения. Структура

route-map, выражения match, ключевые инструменты для match (ip address, match
ip route-source, tag etc) комбинирование выражений match, выражения set, воз-
можные действия с маршрутами (metric, metric-type), использование нескольких
set. Принципы обработки route-map.
Использование route-map для простой фильтрации маршрутов с помощью
distribute-list без set, использование set для установки метрики/типа метрики, при-
меры. Использование route-map для фильтрации маршрутов при редистрибьюции.
Использование тегов для пометки маршрутов при входе в домен маршрутизации,
использование тегов для ограничения дальнейшей редистрибьюции помеченных
маршрутов, протоколы маршрутизации, поддерживающие теги.
Policy-based маршрутизация. Возможность управления маршрутизацией не на
основании таблицы маршрутизации, а на основании предварительно настроенных
политик. Простой пример, иллюстрирующий полезность маршрутизации на осно-
вании политик: использование двух различных провайдеров для передачи трафика
различных подразделений. Реализация pbr с помощью route-map. Использование
set для указания выходного интерфейса, выбор трафика, который должен быть
маршрутизирован на основании политик с помощью match. Важно подчеркнуть,
что pbr делается до обычной маршрутизации пакетов с помощью таблицы марш-
рутизации, а попадание трафика под ключевое слово deny в route-map не означает,
что трафик отбрасывается, такой трафик маршрутизируется обычным образом
с помощью маршрутной таблицы. Пример конфигурирования pbr.
Технология ip sla. Концепция ip sla, возможность периодического тестирова-
ния коннективности различного рода для последующего анализа или для авто-
матического реконфигурирования маршрутизатора. Создание объекта ip sla, три
синтаксиса (ip rtr, ip sla monitor, ip sla), выбор в качестве типа ip sla теста отправку
icmp echo, настройка параметров, порога. Запуск объекта ip sla. Проверка текущего
статуса объекта, получение статистики по работе объекта, примеры статуса OK/
OT/Timeout. Тестирование tcp коннективности, тестирование реального серви-
са (в качестве примера использовать telnet/ssh). Тестирование несуществующе-
го сервиса, необходимость модуля, который обеспечивает необходимые ответы
с другой стороны, понятие об ip sla responder. Кратко о протоколе ipsla, с помощью
которого монитор и responder договариваются о будущем тестировании, пример
тестирования tcp коннективности с помощью responder. Другие типы тестов ip sla.
Трекинг в IOS как возможность проверять некоторое условие (например, на-
ходится ли интерфейс в up) для автоматического принятие решения о конфигу-
рации маршрутизатора. Трекинг трех типов объектов: интерфейсы, маршруты, ip
sla объекты. Результат работы объекта трекинга: состояния up/down. Создание
объекта трекинга для трекинга интерфейса, отличия трекинга line-protocol от
ip routing, условия перехода объекта трекинга в состояние up для обоих типов
трекинга интерфейса. Трекинг маршрутов, отличия между режимами reachability
и metric threshold, условия перехода объекта трекинга в состояние up для обоих

типов трекинга маршрута. Трекинг ip sla объектов, отличия между режимами
reachability и state, условия перехода объекта трекинга в состояние up для обоих
типов трекинга ip sla.
Применение трекинга для создания условных статических маршрутов, при-
менение трекинга для pbr, проверка объекта трекинга с помощью set ip next-hop
verify-availability track. Примеры, иллюстрирующие применение трекинга.
Лабораторные работы, включающие в себя сложные примеры редистрибьюции,
ограничение распространения маршрутов, ip sla и трекинг.
Самостоятельная проработка модулей 4 и 5 курса CCNP ROUTE.
Экзамен

4 PS Route2 7 0 0 1548753182

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

4 PS Route2 7 0 0 1548753182

Загружено:

Авторское право:

Доступные форматы

Программа курса

Для групп полустационара. Версия 7.0.0

Типы IPv6 адресов: unicast, multicast, anycast. Отсутствие широковещания

Unique Local адреса, рассказываем, что они предназначены для организации

получателю. В IPv6 нет broadcast/limited broadcast адресов, поэтому любая пере-

Особые IPv6 адреса (rfc6890). Неопределенный адрес ::/128, адрес loopback

ном и сетевом уровне. Неэффективность отправки таких сообщений с помощью

Изменения в IPv6 заголовке относительно IPv4. Полный отказ от контрольной

Расширение, предназначенное для фрагментации. Отметить, что фрагментация

Затем демонстрируем сообщения о недостижимости простой топологии: хост

разрешенные опции: Target link-layer address (если известен) и Redirected Header.

Задаемся вопросом: а зачем маршрутизаторам Global Unicast адреса на ин-

Диалог между сервером и клиентом. Пакет Discovery, отправляемый клиентом,

rfc на экране/проекторе, при этом следует пропускать незначимые опции, а рас-

Демонстрация конфигурирования резервирования адреса для клиента с задан-

Технология Prefix-delegation. Почему в dhcpv6 необходима данная технология,

данное имя уникально, однозначно идентифицирует файл и позволяет его легко

решающих серверов. Обзор сценариев разрешения имен с использованием раз-

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

ния имен в настроенной зоне, но и в Интернет, включение рекурсии, возможное

Демонстрация работы ddns. Конфигуририруем dhcp сервер, dns сервер и кли-

рутизация внутри автономной системы и маршрутизация между автономными

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

Протоколы маршрутизации RIPv1, RIPv2 и RIPng

принадлежат подсетям той же классовой сети. Проблемы при такой автоматиче-

раз недостаточно (пакеты могут теряться), поэтому сведения о недостижимости

что не смотря на то, что триггерные обновления существенно уменьшают риск

дение маршрутизаторов из прошлого примера, обращаем внимание на автоматиче-

Добавляем на один из крайних маршрутизаторов маршрут по-умолчанию ста-

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

ключенная технология holddown (таймер = 0). Отличия в работе holddown (при

маршрутными данными с гарантиями доставки (с подтверждением), после чего

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

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

Процесс передачи маршрутной информации между соседями. Инициирующий

квитирование полученных Query в помощью юникаст Hello. Отправка юникаст

Включение маршрута по-умолчанию в EIGRP апдейты. Способ первый: при

Образы IOS и лицензирование

(2 байта, возможна поддержка расширенного номера, длиной 4 байта, детали поз-

отправка Notification после получения неожиданного номера AS. Состояния bgp

для выбора лучшего маршрута, все прочие критерии принимаются во внимание

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

маршрут как внутренний или как внешний. Редистрибьюция из isis, возможность

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

он вызывается), но и внести в пакет/маршрут некоторые изменения. Структура

и metric threshold, условия перехода объекта трекинга в состояние up для обоих

Вам также может понравиться