Групповая адресация IP Multicast

На Рисунок 6 показан формат адреса IP Multicast Class D.

IP Multicasting

Организация IETF (Internet Engineering Task Force) разработала ряд стандартов, соответствующих пунктам, перечисленным в предыдущем разделе.

Адресация ? Адресное пространство IP разделяется на четыре части: Class A, Class B, Class C и Class D. Для трафика Unicast отводятся Class А, В и С. Class D резервируется для трафика Multicast. Адреса из диапазона Class D распределяются динамически. Динамическая регистрация ? Документ RFC-1112 определяет протокол IGMP (Internet Group Management Protocol), который обеспечивает возможность конечного узла сети информировать всю сеть о подключении этого узла к определенной группе рассылки.

Маршрутизация Multicast ? Для обеспечения маршрутизации Multicast был разработан целый ряд стандартов: RFC-1075, определяющий протокол DVMPR (Distance Vector Multicast Routing Protocol) RFC-1584, определяющий протокол MOSPF (Multicast OSPF) ? расширение протокола OSPF (Open Shortest Path First), поддерживающее IP Multicast Два предварительных описания стандартов, представленных Cisco Systems, определяющих протокол PIM (Protocol Independent Multicast) ? протокол, который может использоваться совместно с любым стандартным протоколом маршрутизации IP Unicast.

Маршрутизация Multicast

Одним из необходимых требований для передачи трафика Multicast через маршрутизируемые сети является наличие маршрутного протокола Multicast. В настоящее время известны 3 таких протокола ? DVMRP, MOSPF и PIM. Назначение каждого из них заключается в нахождении внутри сети маршрута для следования трафика Multicast и обеспечение доставки этого трафика каждому заинтересованному участнику сети.

Пакеты Broadcast

Пакеты Broadcast

Пакеты Multicast

Пакеты Multicast

Пакеты Unicast

с коммутацией уровня

Пример сети с коммутацией уровня 2

Протокол CGMP

Очевидно, что благодаря адресной схеме Class D, протоколам IGMP и PIM есть возможность создания хорошего механизма распределения трафика IP Multicast в маршрутизируемых сетях на основе оборудования Cisco Systems, однако, этот механизм основывается на распределенных адресах уровня 3, что создает определенные проблемы при использовании коммутации уровня 2. Дело в том, что в коммутационных таблицах коммутаторов для этого типа трафика не создается никаких записей, что приводит к тому, что поток Multicast плотностью 1,5 Мбит/с просто передается на все порты коммутатора. Такая ситуация не лучшим образом сказывается на эффективности работы всей сети.

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

Однако с другой стороны, прохождение трафика IP Multicast через коммутаторы уровня 2 неизбежно, особенно в условиях кампусной сети (см. Рисунок 13).

Протокол DVMRP (RFC1075)

Протокол DVMRP (RFC-1075)

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

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

Для определения того, какой интерфейс является источником потока данных Multicast, и предотвращения распространения трафика в обратном направлении, протокол DVMRP использует свой собственный маршрутный протокол типа Unicast. Этот протокол в достаточно большой степени похож на протокол RIP; он основывается на числе промежуточных узлов при определении метрики маршрута. В результате трафик Multicast не всегда следует тем же маршрутом, что и трафик Unicast.

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

Протокол DVMRP применяется для организации MBONE (Multicast backbone across the public Internet), обеспечивая реализацию туннелей между устройствами, работающими с этим протоколом. Такие вещи, как MBONE, повсеместно используются для обеспечения настольной конференц-связи между компьютерами и их группами, установленными на значительном расстоянии друг от друга и соединенными публичными каналами связи. В недалеком будущем планируется отход MBONE от применения DVMRP; вместо него планируется использование протокола PIM в связи с тем, что PIM имеет лучшие параметры эффективности. Преимуществам протокола PIM перед DVMRP посвящена часть раздела с описанием PIM.

Протокол MOSPF(Multicast Extensions to OSPF RFC1584)

Протокол MOSPF(Multicast Extensions to OSPF, RFC-1584)

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

Работа протокола MOSPF основана на том, что к маршрутным обновлениям OSPF добавляется информация Multicast. Маршрутизатор MOSPF в процессе работы накапливает информацию о группах Multicast, которые в настоящий момент активны в сети.

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

Естественно, что протокол MOSPF работает только в тех сетях, которые используют протокол OSPF.

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

Протокол PIM

В отличие от MOSPF, работающего только с протоколом OSPF, протокол PIM работает с любым из известных маршрутных протоколов. Также, в отличие от DVMRP, имеющего по определению проблемы с масштабируемостью, протокол PIM предоставляет два различных типа схем распределения многоадресного трафика, обеспечивающих масштабирование маршрутизации Multicast: режимы Dense Mode и Sparse Mode.

Режим Dense Mode PIM чаще всего используется в следующих случаях:

Отправители и получатели информации находятся в непосредственной близости друг от друга

Имеется небольшое количество отправителей и большое количество получателей рассылки

Имеется большой объем трафика Multicast

Плотность потоков данных Multicast находится постоянно примерно на одном уровне.

Режим Dense Mode использует, так же как и DVMRP, механизм Reverse Path Forwarding. Основным отличием между DVMRP и Dense Mode PIM является тот факт, что PIM работает независимо от того, какой маршрутный протокол Unicast используется на данном соединении. Другими словами, протокол PIM не требует наличия в сети какого-либо определенного протокола Unicast.

Рисунки с 14 по 16 показывают

Рисунки с 14 по 16 показывают работу протокола CGMP между маршрутизатором Cisco 7505 и коммутатором Catalyst 5000. Преимущества протокола CGMP рассматриваются на примере видеопотока плотностью 1,5 Мбит/с.

Адрес узла назначения

Табл. 1. Таблица коммутации уровня 2

MAC-адрес узла назначения	Порт назначения
00-00-0с-06-41-7с	3/3
00-00-0с-02-b9-01	3/3
00-80-24-07-8c-60	3/2

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

Когда посланный фрейм содержит в поле адреса назначения широковещательный или многоцелевой адрес, то коммутатор уровня 2 распространяет его по всем интерфейсам. На Рисунок 2 показан процесс, происходящий тогда, когда коммутатор уровня 2 получает трафик multicast.

Процесс обработки фреймов

Пример сети Multicast

Технологии Multicast используются в современных сетях в разных целях. Такие протоколы, как, например EIGRP (Enhanced Interior Gateway Routing Protocol) и OSPF (Open Shortest Path First), используют пакеты multicast для рассылки маршрутных обновлений между соседними маршрутизаторами. Более важной сферой применения технологий Multicast является организация групповой обработки данных прикладными программами. Одним из наилучших примеров такой обработки является использование рассылки данных мультимедиа, когда видео и аудиоданные распространяются по мере подключения пользователей к группам рассылки.

Для применения технологий Multicast необходимо понимание трех основных типов пакетов, служащих для передачи данных по сети: Unicast (одноцелевые), Multicast (групповые) и Broadcast (широковещательные) пакеты.

Передача пакетов Unicast

Рисунок 3. Передача пакетов Unicast

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

Передача пакетов Broadcast

Рисунок 4. Передача пакетов Broadcast

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

На практике рассылка таких пакетов по всем подсетям является малоэффективной, так как лишь небольшая группа клиентов нуждается в подобной рассылке (см. Рисунок 4).

Передача пакетов Multicast

Рисунок 5. Передача пакетов Multicast

При таком дизайне приложения рассылают по одной копии каждого пакета на групповой адрес, причем именно клиент определяет, надо ли ему обрабатывать пакеты с таким адресом. Использование технологий Multicast обеспечивает возможность контролирования объема передаваемого трафика, а также ограничивать объем вычислений, производимых активным сетевым оборудованием и конечными узлами сети, что позволяет исключить избыточность трафика (см. Рисунок 5).

Для понимания преимуществ использования технологий Multicast рассмотрим работу видео-сервера, использующего данные в формате MPEG. Воспроизведение одного видеопотока MPEG требует полосы пропускания примерно в 1,5 Мбит/с. В условиях сети Unicast видео-сервер рассылает трафик со скоростью, определяемой по формуле 1,5 Мбит/с * n, где n ? это общее число клиентов рассылки. Таким образом получаем, что при использовании сети с пропускной способностью 10 Мбит/с рассылка 6 или 7 потоков одновременно полностью исчерпывает пропускную способность сети. При использовании же технологий Multicast серверу достаточно рассылать всего 1 копию видеопотока на 1 адрес Multicast, причем независимо от числа активных клиентов, принимающих этот поток. Получается, что при использовании Multicast серверу достаточно свободной полосы пропускания в 1,5 Мбит/с, что обеспечивает возможность утилизации оставшейся пропускной способности для иных целей.

Технологии передачи Multicast могут применяться как на уровне 2, так и на уровне 3. Например, сети Ethernet и FDDI (Fiber Distributed Data Interface) поддерживают все 3 типа пакетов. Индивидуальный компьютер может получать пакеты на адрес Unicast, несколько адресов Multicast и на адрес Broadcast. Сети Token Ring также поддерживают концепции Multicast, правда, они используют для этого несколько иные механизмы. Сети Token Ring имеют функциональные адреса, которые можно использовать для идентификации групп рассылки.

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

При внедрении приложения Multicast в кампусную сеть, содержащую несколько типов сред и систем передачи данных, таких как Ethernet, Token Ring, FDDI, ATM (Asynchronous Transfer Mode), Frame Relay, SMDS (Switched Multimegabit Data Service) и других сетевых технологий, наилучшим вариантом применения Multicast является его внедрение на уровне 3, если, конечно, трафик такого типа не предназначен только для одного сетевого сегмента.

Для поддержки Multicast на сетевом уровне необходимо определить несколько параметров:

Адресация ? Необходимо иметь адрес сетевого уровня, отвечающий за соединения между серверами и группами рассылки, причем группы рассылки могут состоять как из одного, так и из большого числа пользователей. Кроме того, необходимо обеспечить механизм установления соответствия между этим адресом и адресами уровня 2, которые используются при работе Multicast на канальном уровне. Динамическая регистрация ? Необходимо обеспечить механизм регистрации компьютера, подключенного к сети, в определенных группах рассылки. Без такого механизма невозможно определить, по каким именно подсетям необходимо передавать трафик для каждой группы рассылки. Маршрутизация Multicast ? Сеть должна обеспечивать построение деревьев распределения пакетов, которые позволят источникам рассылки отправлять пакеты всем узлам-приемникам. Основной задачей деревьев распределения пакетов является обеспечение нахождения каждого пакета в определенной подсети только один раз (например, если внутри офисной сети имеется несколько получателей пакетов Multicast, то на всю офисную сеть должна приходить только одна копия каждого пакета).

Формат адреса Class D

Рисунок 6. Формат адреса Class D

В отличие от адресов Class A, B и С младшие 28 бит адреса Class D не имеют определенной структуры. Адрес группы Multicast является двоичной комбинацией значения 1110 в старших 4 битах адреса и идентификатора группы, обычно обозначаемого в десятичной форме в диапазоне от 224.0.0.0 до 239.255.255.255.

В связи с тем, что значение старшего октета начинается с двоичной комбинации 1110, то значение 224 является базовым адресом.
Конечные узлы, обеспечивающие прием пакетов, имеющих определенный адрес IP Multicast, называются группой узлов. Группа узлов может охватывать несколько подсетей. Участие узлов в группе определяется динамически ? узлы могут подключаться к группе и отключаться от нее. Более подробно о процессе регистрации в сети IP Multicast рассказывается в разделе, посвященном протоколу IGMP.

Некоторые адреса групп соответствуют определенному типу узлов. Это определено в соответствующем документе IANA (Internet Assigned Numbers Authority). Эти группы называются постоянными группами узлов, аналогично тому, как распределяются номера портов TCP и UDP. В таблице 2 показаны некоторые такие группы.

Соответствие адресов

Протокол IGMP

Как и любая другая часть уровня IP, протокол IGMP использует для передачи данных дейтаграммы протокола IP. В отличие от других протоколов этого семейства, IGMP имеет фиксированный размер поля данных внутри дейтаграммы IP (см. Рисунок 8).

Дейтаграмма IP с сообщением

Рисунок 8. Дейтаграмма IP с сообщением

протокола IGMP

Сообщения протокола IGMP обозначаются в поле идентификатора протокола дейтаграммы IP значением 2. Формат сообщения IGMP внутри дейтаграммы IP показан на Рисунок 9.

Протокол IGMP реализован в двух версиях ? Type 1 и Type 2. Сообщения Type 1 являются запросами, рассылаемыми маршрутизаторами Multicast, а сообщения Type 2 являются ответами на эти запросы,посылаемыми конечными узлами сети. Групповой адрес ? это ничто иное, как адрес IP Class D. При запросах групповой адрес имеет значение 0, а при ответах это поле содержит адрес группы рассылки.

Формат сообщения IGMP

Рисунок 9. Формат сообщения IGMP

Фундаментальной функцией технологий Multicast является концепция обеспечения подключения некоего данного порта (интерфейса) на некотором конечном узле сети к группе рассылки. Участие данного интерфейса в группе рассылки является динамическим (таким образом, с течением времени имеют место процессы подключения и отключения клиентов от групп рассылки). Благодаря этому конечные узлы сети могут динамически подключаться к группам рассылки по мере загрузки на этих узлах определенных прикладных программ.

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

Конечный узел сети посылает пакет IGMP типа report для обеспечения запуска процесса подключения к группе рассылки. Если на данном конечном узле выполняются сразу несколько процессов подключения к одной и той же группе, то посылается только один пакет IGMP. Причем этот пакет посылается только на тот интерфейс, который имеет соединение с сервером рассылки. Узел не посылает никаких дополнительных пакетов при отключении от группы рассылки, даже если последним покидает группу. Каждый конечный узел ?знает? о том, что в данной группе нет ни одного участника, поэтому при получении следующего запроса ему не за чем информировать группу. Маршрутизатор Multicast через определенные временные интервалы посылает в сеть запросы IGMP. Эти запросы позволяют определить текущее состояние групп рассылки. Маршрутизатор должен отправить по одному запросу на каждый интерфейс. Адрес группы в запросе равен 0 до тех пор, пока маршрутизатор не обнаружит хотя бы одного работающего клиента из любой активной группы рассылки. Узел посылает ответный пакет IGMP для каждой группы рассылки до тех пор, пока имеется хотя бы один клиент данной группы.

Использование системы запросов и ответов позволяет маршрутизатору Multicast обеспечивать актуальное состояние таблицы, содержащей информацию о том, на каком из интерфейсов находятся один или более узлов сети, принадлежащих данной группе рассылки. Если маршрутизатор получает дейтаграмму Multicast (использующую адрес Multicast уровня 2), предназначенную для дальнейшей пересылки, то он пересылает эту дейтаграмму только на те интерфейсы, к которым подключены подсети, содержащие клиентов данной группы рассылки. На Рисунок 10 показано простое взаимодействие устройств по протоколу IGMP.

Запросы и ответы IGMP

Рисунок 10. Запросы и ответы IGMP

Как видно из рисунка, значение поля TTL (Time to Live) запросов и ответов устанавливается в 1, в отличие от нормального значения TTL в заголовке обычного пакета IP. Дейтаграмма Multicast с начальным значением TTL равным 0 ограничена по распространению в пределах того же узла. По умолчанию дейтаграммы Multicast имеют в поле TTL значение 1, что ограничивает их распространение в

пределах одной подсети. Дейтаграммы с большим значением TTL могут обрабатываться и передаваться маршрутизаторами Multicast.
Увеличивая значение TTL, приложения могут расширять круг поиска определенных серверов. Первая дейтаграмма Multicast в потоке всегда имеет значение TTL равное 1. Если на эту дейтаграмму не приходит ответа от сервера, то посылается следующая дейтаграмма с полем TTL равным 2. Затем 3 и т.д. Таким образом, приложение обнаруживает далеко стоящий сервер, причем попутно определяется количество промежуточных маршрутизаторов на пути от клиента до сервера (Number of Hops).

Специальный диапазон адресов от 224.0.0.0 до 224.0.0.255 предназначен для тех приложений, трафик которых никогда не выходит за пределы одного промежуточного маршрутизатора. Маршрутизатор Multicast никогда не обрабатывает пакеты с такими адресами, несмотря на значение поля TTL.

Работа протокола Dense Mode PIM

Рисунок 11. Работа протокола Dense Mode PIM

В режиме Dense Mode протокол PIM распространяет запросы и ответы на подключение или отключение от групп рассылки сразу обо всей подсети, основываясь на информации о составе групп Multicast. В частности, при использовании телевизионного вещания в условиях локальной сети этот режим достаточно эффективен в связи с тем, что он обеспечивает быстрое распространение информации о подключениях и отключениях клиентов от групп рассылки во всех подсетях. Распространение информации о подсетях также эффективно благодаря тому, что требуется небольшое количество трафика для рассылки такого объема информации. Программное обеспечение Cisco IOS (Cisco Internetwork Operating System) обеспечивает поддержку протокола Dense Mode PIM.

Работа протокола Sparse Mode PIM

Рисунок 12. Работа протокола Sparse Mode PIM

Режим Sparse Mode PIM обычно применяется в следующих случаях:

При наличии небольшого количества получателей рассылки в каждой группе

Источники и получатели рассылки соединены между собой каналами WAN

Трафик характеризуется непостоянной плотностью

На Рисунок 12 показано функционирование Sparse Mode PIM. Этот режим оптимизирован для таких ситуаций, при которых большое количество многонаправленных потоков данных и каждый поток Multicast связаны с небольшим количеством локальных сетевых сегментов внутри общей сети. При таком типе групп рассылки механизм Reverse Path Forwarding неэффективно использует полосу пропускания сети. Механизм, используемый Sparse Mode PIM, называется Rendezvous Point (точка встречи). Когда источник отправляет данные, то сперва он отправляет их на точку встречи, и если получатель подключается к группе рассылки, то ему необходимо зарегистрироваться в этой точке. При передаче трафика по маршруту ?Источник ? точка встречи ? получатель? маршрутизаторы автоматически оптимизируют путь следования трафика, исключая тем самым лишние промежуточные узлы. Режим Sparse Mode PIM предполагает, что ни один узел не начинает рассылку пакетов Multicast без предварительного запроса клиента. Программное обеспечение Cisco IOS осуществляет поддержку этого режима протокола PIM.

Информация о том, как конфигурировать маршрутизацию IP Multicast на устройствах Cisco Systems содержится на CD-ROM Cisco Connection Documentation.

Рисунок 13. Прохождение трафика IP

Рисунок 13. Прохождение трафика IP Multicast через коммутаторы уровня 2

Как мы рассматривали ранее, трафик IP Multicast ставится в соответствие адресам Multicast уровня 2, что приводит к тому, что он передается на все порты коммутатора.

Рассмотрим на Рисунок 13 видеосервер A и видеоклиента B. Видеоклиент требует просмотра видеопрограммы, транслируемой видеосервером с использованием 1,5 Мбит/с потока. Процесс подключения клиента к группе рассылки начинается с посылки запроса видеосерверу на подключение по протоколу IGMP. Ближайший к клиенту маршрутизатор получает этот запрос и, используя протокол PIM, добавляет клиентский сегмент в дерево распределения PIM. На этом этапе трафик IP Multicast начинает передаваться клиенту. Коммутатор получает входящий трафик и просматривает MAC-адрес узла назначения. В связи с тем, что этот MAC-адрес соответствует адресу Multicast, и в таблице коммутации, естественно, такого адреса нет, то весь 1,5 Мбит/с поток передается всем портам коммутатора.

Cisco Systems представляет решение, позволяющее устранить возникающую неэффективность. Это решение заключается в том, что в программное обеспечение Cisco IOS, под управлением которого работают коммутаторы, добавляются ?интеллектуальные? функции, позволяющие управлять трафиком Multicast уровня 2. Эти функции осуществляются протоколом CGMP (Cisco Group Management Protocol).

Как видно из названия протокола, CGMP является разработкой Cisco Systems и позволяет коммутаторам Cisco Catalyst получать информацию о составе групп рассылки от маршрутизаторов Cisco. Это обеспечивает возможность управления трафиком Multicast на уровне 2. В результате сеть, построенная на основе такого оборудования и использующая CGMP, обеспечивает доставку трафика Multicast только на те порты коммутаторов Catalyst, к которым подключены участники рассылки. На остальные порты данная рассылка не распространяется до тех пор, пока от них не придет запрос клиента на подключение к группе рассылки.

Самым важным преимуществом использования CGMP является то, что этот протокол позволяет максимально использовать производительность уровня 2. В отличие от других решений этот подход позволяет передавать информацию уровня 3 на уровень конечных портов, т.е. CGMP может управлять коммутацией уровня 2. И как результат такого использования протокола можно отметить, например, тот факт, что коммутатор Catalyst 5000 может обрабатывать пакеты Multicast со скоростью в 1 миллион пакетов в секунду.

Трафик IP Multicast

Рисунок 16. Трафик IP Multicast в сети с протоколом CGMP: распространение трафика после подключения по CGMP

Несмотря на то, что данный пример иллюстрирует работу всего одного коммутатора, протокол CGMP обеспечивает аналогичную работу при каскадировании коммутаторов. На Рисунок 17 показан как раз такой случай, когда несколько коммутаторов Catalyst 5000 подключены последовательно к одному интерфейсу маршрутизатора.

Сеть с каскадированием коммутаторов

Рисунок 17. Сеть с каскадированием коммутаторов

Без применения протокола CGMP трафик Multicast распространяется на всю коммутирующую матрицу уровня 2. Исходящий маршрутизатор предотвращает попадание трафика Multicast в ядро кампусной сети, однако он не в состоянии управлять коммутирующими матрицами на уровне 2. При использовании CGMP трафик Multicast является полностью управляемым, причем не только на уровне непосредственно подключенного коммутатора, но и на всех нижестоящих коммутаторах. Выполнение этих функций возможно благодаря тому, что протокол CGMP использует известный адрес Multicast уровня 2, который обрабатывается всеми коммутаторами Catalyst. На Рисунок 18 показана работа протокола CGMP в сети с каскадированием коммутаторов уровня 2.

Рисунок 18. Протокол CGMP

Рисунок 18. Протокол CGMP в сети с каскадированием коммутаторов уровня 2

CISCO по русски. Набор статей

Содержание

Пример сети с коммутацией уровня 2

Пример сети Multicast

Групповая адресация IP Multicast

Протокол IGMP

Маршрутизация Multicast

Протокол DVMRP (RFC-1075)

Протокол MOSPF(Multicast Extensions to OSPF, RFC-1584)

Протокол PIM

Протокол CGMP

Заключение

Табл 2 Зарегистрированные адреса Class D

Табл. 2. Зарегистрированные адреса Class D

Адрес Class D	Назначение
224.0.0.1	Все узлы в данной подсети
224.0.0.2	Все маршрутизаторы в данной подсети
224.0.0.4	Все маршрутизаторы DVMRP
224.0.0.5	Все маршрутизаторы MOSPF
224.0.0.9	Протокол RIPv2 (Routing Information Protocol Version 2)
224.0.1.1	Протокол NTP (Network Time Protocol)
224.0.1.2	SGI Dogfight
224.0.1.7	Audio news
224.0.1.11	IETF audio
224.0.1.12	IETF video

Кроме резервирования адресов Class D IANA владеет блоком адресов Ethernet, начинающихся с шестнадцатеричной комбинации 00:00:5e. Эта комбинация представляет собой старшие 24 бита адреса Ethernet, что означает, что весь блок адресов включает в себя диапазон с 00:00:5e:00:00:00 по 00:00:5e:ff:ff:ff. Половина адресов этого блока резервируется для передачи пакетов Multicast. Первый байт каждого адреса Ethernet должен содержать комбинацию 01, которая и определяет данный пакет, как пакет Multicast. Таким образом, для передачи IP Multicast используются адреса в диапазоне от 01:00:5e:00:00:00 до 01:00:5e:7f:ff:ff.

Такое резервирование адресов позволяет использовать 23 бита адреса Ethernet для идентификации группы рассылки IP Multicast. Таким образом, младшие 23 бита адреса IP Multicast полностью соответствуют 23 битам адреса Ethernet (см. Рисунок 7).

Как стало понятно при рассмотрении

Заключение

Как стало понятно при рассмотрении в настоящей статье, технологии IP Multicasting и коммутация уровня 2 являются перспективными технологиями, предоставляющими масштабируемую коммутируемую среду, обеспечивающую взаимодействие клиентов и серверов. Слабым местом коммутации уровня 2 является поддержка трафика Multicast. Без применения специальных дополнительных механизмов, повышающих эффективность передачи трафика Multicast, коммутатор уровня 2 доставляет этот трафик всем своим портам. Cisco Systems решает эту проблему, предлагая использование в корпоративных сетях протокола CGMP, являющимся одним из наиболее передовых решений, которое уже достаточно широко и успешно применяется в корпоративных сетях с целью повышения производительности коммутации уровня 2 и поддержки трафика IP Multicast. Именно это решение позволяет этим технологиям сосуществовать в рамках одной сети, удовлетворяя при этом все требования пользователей этих сетей.

Действие Команда Очистить все

Действие	Команда
Очистить все записи динамической трансляции адресов из таблицы NAT	clear ip nat translation *
Очистить простую запись динамической трансляции, содержащей информацию либо о внутренней трансляции, либо о внутренней и внешней трансляции	clear ip nat translation inside <глобальный адрес> <локальный адрес> [outside <локальный адрес> <глобальный адрес>]
Очистить простую запись динамической трансляции, содержащую информацию о внешней трансляции	clear ip nat translation outside <локальный адрес> <глобальный адрес>
Очистить расширенную запись динамической трансляции	clear ip nat translation <протокол> inside <глобальный адрес> <глобальный порт> <локальный адрес> <локальный порт> [outside <локальный адрес> <локальный порт> <глобальный адрес> <глобальный порт>]

Просмотреть текущее состояние NAT можно при помощи следующих команд:

Действие	Команда
Показать активные трансляции	show ip nat translations [verbose]
Показать статистику трансляций	show ip nat statistics

Действия выполняемые при настройке NAT

Действия, выполняемые при настройке NAT

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

Использование одного внутреннего глобального адреса

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

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

Изменение таймаутов трансляции

Изменение тайм-аутов трансляции

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

Действие	Команда
Изменить значение тайм-аута для динамической трансляции адресов. Режим overloading не используется.	ip nat translation timeout <значение в секундах>

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

Действие	Команда
Изменение значения тайм-аута UDP (по умолчанию 5 минут)	ip nat translation udp-timeout <значение в секундах>
Изменение значения тайм-аута DNS (по умолчанию 1 минута)	ip nat translation dns-timeout <значение в секундах>
Изменение значения тайм-аута TCP (по умолчанию 24 часа)	ip nat translation tcp-timeout <значение в секундах>
Изменение значения тайм-аута Finish и Reset (по умолчанию 1 минута)	ip nat translation finrst-timeout <значение в секундах>

Конфигурация динамической трансляции

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

Действие	Команда
Определить пул глобальных адресов	ip nat pool <имя> <первый адрес> <последний адрес> [netmask <маска подсети> или prefix-length <длина префикса>]
Определить стандартный список доступа, регламентирующий адреса, подлежащие трансляции	access-list <номер> permit <адрес или блок адресов>
Установить динамическую трансляцию на основе списка доступа, определенного на предыдущем шаге	ip nat inside source list <номер списка доступа> pool <имя>
Указать внутренний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внутренней сети	ip nat inside
Указать внешний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внешней сети	ip nat outside

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

Представленный ниже пример транслирует все адреса узлов-источников, определенных списком доступа 1 (разрешены адреса от 192.168.1.0/24), в пул адресов, названный net-208. Этот пул содержит адреса с 171.69.233.208 по 171.69.233.233.

ip nat pool net-208 171.69.233.208 171.69.233.233 netmask 255.255.255.240

ip nat inside source list 1 pool net-208

interface serial 0

ip address 171.69.232.182 255.255.255.240

ip nat outside

interface ethernet 0

ip address 192.168.1.94 255.255.255.0

ip nat inside

access-list 1 permit 192.168.1.0 0.0.0.255

Конфигурация статической трансляции

Конфигурация статической трансляции

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

Конфигурирование динамической трансляции

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

Действие	Команда
Определить пул локальных адресов	ip nat pool <имя> <начальный адрес> <конечный адрес> [netmask <маска подсети> или prefix-length <длина префикса>]
Определить стандартный список доступа	access-list <номер> permit <локальный адрес или блок адресов>
Установить динамическую трансляцию внешних адресов узлов-отправителей, основанную на списке доступа, определенном на предыдущем шаге	ip nat outside source list <номер списка доступа> pool <имя>
Указать внутренний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внутренней сети	ip nat inside
Указать внешний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внешней сети	ip nat outside

Замечание
Замечание

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

В приведенном ниже примере адреса в локальной сети используются кем-то еще в качестве легальных адресов Интернет. Во внешней сети необходимо производить дополнительную трансляцию. Пул net-10 является пулом внешних локальных адресов IP. Выражение ip nat outside source list 1 pool net-10 транслирует адреса узлов из внешней перекрывающейся сети в адреса данного пула.

ip nat pool net-208 171.69.233.208 171.69.233.223 prefix-length 28

ip nat pool net-10 10.0.1.0 10.0.1.255 prefix-length 24

ip nat inside source list 1 pool net-208

ip nat outside source list 1 pool net-10

interface serial 0

ip address 171.69.232.192 255.255.255.240

ip nat outside

interface ethernet0

ip address 192.168.1.94 255.255.255.0

ip nat inside

access-list 1 permit 192.168.1.0 0.0.0.255

Конфигурирование статической трансляции

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

Действие	Команда
Установить статическую трансляцию между внешним локальным адресом и внешним глобальным адресом	ip nat outside source static <глобальный адрес> <локальный адрес>
Указать внутренний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внутренней сети	ip nat inside
Указать внешний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внешней сети	ip nat outside

Мониторинг и сопровождение NAT

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

Обеспечение распределения нагрузки TCP

Другая сфера применения NAT не относится к использованию адресов Интернет. Допустим, что организация имеет множество узлов, которые должны подключаться к одному узлу, характеризующемуся высокой степенью загрузки запросами пользователей. Используя NAT можно организовать виртуальный узел во внутренней сети, который будет координировать разделение нагрузки между реальными узлами сети. Адреса узлов назначения, совпадающие с условиями списка доступа, заменяются на адреса из постоянно перебираемого пула. Выбор адреса осуществляется по механизму round-robin, причем такой выбор производится только при установлении нового соединения из внешней сети во внутреннюю. Трафик ?не-ТСР? передается без изменений. Эта функция показана на Рисунок 4.

Преимущества NAT

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

Маршрутизатор, выполняющий функции NAT, должен иметь, по крайней мере, один внутренний и один внешний интерфейсы. При обычном использовании NAT конфигурируется на выходном маршрутизаторе, разделяющем локальный домен и сеть общего пользования. Когда пакет покидает пределы локального домена, функции NAT транслируют содержимое поля Source (локальный адрес отправителя пакета) в значение уникального внешнего адреса. Когда же пакет входит в локальный домен, производится трансляция уникального внешнего адреса в локальный адрес. Если локальный домен имеет более одного выхода во внешнюю сеть, то все маршрутизаторы NAT должны иметь одинаковые таблицы соответствия внутренних и внешних адресов. Если программное обеспечение не в состоянии занять адрес для текущего пакета, то такой пакет будет уничтожен. Одновременно в обратном направлении будет отправлен пакет ICMP, содержащий извещение об уничтожении этого пакета (Host Unreachable).

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

Применение NAT в современных бизнессетях

Применение NAT в современных бизнес-сетях

Функции NAT для решения следующих проблем и задач:

При необходимости подключения к Интернет, когда количество внутренних узлов сети превышает выданное поставщиком услуг Интернет количество реальных адресов IP. NAT позволяет частным сетям IP, использующим незарегистрированные адреса, получать доступ к ресурсам Интернет. Функции NAT конфигурируются на пограничном маршрутизаторе, разграничивающем частную (внутреннюю) сеть и сеть общего пользования (например, Интернет). Далее сеть общего пользования мы будем называть внешней сетью, а частную сеть ? внутренней сетью. Функции NAT перед отправкой пакетов во внешнюю сеть осуществляют трансляцию внутренних локальных адресов в уникальные внешние адреса IP. При необходимости изменения внутренней системы адресов. Вместо того, чтобы производить полное изменение всех адресов всех узлов внутренней сети, что представляет собой достаточно трудоемкую процедуру, функции NAT позволят производить их трансляцию в соответствии с новым адресным планом. При необходимости организации простого разделения трафика на основе портов TCP. Функции NAT предоставляют возможность установления соответствия (mapping) множества локальных адресов одному внешнему адресу, используя функции распределения нагрузки TCP.

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

Трансляция внутренних адресов Source

Рисунок 1. Трансляция внутренних адресов Source

Приведенный ниже процесс описывает трансляцию локальных адресов Source, показанную на Рисунок 1:

Пользователь узла 1.1.1.1 открывает соединение с узлом В. Первый пакет, полученный маршрутизатором от узла 1.1.1.1 приводит к тому, что маршрутизатор начинает проверять таблицу NAT. Если имеется статическая запись в таблице трансляции, то маршрутизатор переходит к пункту 3. Если статической записи в таблице трансляции нет, то маршрутизатор определяет, что адрес узла-источника пакета (SA, Source Address) 1.1.1.1 должен транслироваться динамически. Далее маршрутизатор выбирает свободный глобальный адрес из пула адресов и создает в таблице запись о трансляции. Тип такой записи называется простая запись (Simple Entry). Маршрутизатор заменяет внутренний локальный адрес узла 1.1.1.1 на указанный в таблице трансляции глобальный адрес (2.2.2.2), а затем передает пакет во внешнюю сеть. Узел В получает пакет и отвечает узлу 1.1.1.1 используя внутренний глобальный адрес назначения (DA, Destination Address) 2.2.2.2. Когда маршрутизатор получает пакет с внутренним глобальным адресом, он сверяется с таблицей NAT, используя внутренний глобальный адрес в качестве ключа поиска. Далее происходит трансляция внутреннего глобального адреса во внутренний локальный адрес узла 1.1.1.1, и пакет передается узлу 1.1.1.1. Узел 1.1.1.1 получает этот пакет и продолжает взаимодействие с узлом В. Маршрутизатор осуществляет действия, описанные в пунктах 2 ? 5, по отношению к каждому пакету.

Использование одного внутреннего глобального адреса

Рисунок 2. Использование одного внутреннего глобального адреса

Ниже показан процесс, выполняемый маршрутизатором в сети на Рисунок 2. Узлы В и С обращаются к одному узлу 2.2.2.2. На самом же деле они общаются с разными узлами во внутренней сети. Разделителем адресов этих узлов служит номер порта TCP. Фактически получается, что довольно большое количество внутренних узлов могут разделять один внутренний глобальный адрес IP, используя для этого разные порты TCP.

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

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

Маршрутизатор заменяет внутренний локальный адрес 1.1.1.1 выбранным глобальным адресом и осуществляет передачу пакета во внешнюю сеть. Узел В получается этот пакет и отвечает узлу 1.1.1.1, используя внутренний глобальный адрес 2.2.2.2. При получении из внешней сети пакета с внутренним глобальным адресом 2.2.2.2 маршрутизатор производит просмотр таблицы NAT, используя тип протокола, внутренний глобальный адрес и порт, а также внешний адрес и порт в качестве ключа поиска. После этого производится обратная трансляция адреса в локальный адрес 1.1.1.1, и пакет передается узлу 1.1.1.1. Узел 1.1.1.1 получает этот пакет и продолжает взаимодействие. Маршрутизатор производит действия, описанные в пунктах 2 ? 5 для каждого проходящего пакета.

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

Действие	Команда
Определить пул глобальных адресов	ip nat pool <имя> <первый адрес> <последний адрес> [netmask <маска подсети> или prefix-length <длина префикса>]
Определить стандартный список доступа	access-list <номер> permit <внутренний адрес или блок адресов>
Установить режим динамической трансляции адресов, разрешенных в списке доступа, определенном на предыдущем шаге	ip nat inside source list <номер списка доступа> pool <имя> overload
Указать внутренний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внутренней сети	ip nat inside
Указать внешний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внешней сети	ip nat outside

Приведенный ниже пример создает пул адресов, названный net-208. Данный пул содержит адреса с 171.69.233.208 по 171.69.233.233. Список доступа 1 разрешает пакеты, имеющие адрес отправителя с 192.168.1.0 по 192.168.1.255. Если в данный момент не производится процедур трансляции, то адреса в пакетах, соответствующих условиям списка доступа 1, транслируются в адрес из указанного пула. Маршрутизатор позволяет нескольким внутренним адресам (с 192.168.1.0 по 192.168.1.255) использовать один глобальный адрес. Для определения того или иного соединения маршрутизатор использует номера портов.

ip nat pool net-208 171.69.233.208 171.69.233.233 netmask 255.255.255.240

ip nat inside source list 1 pool net-208 overload

interface serial0

ip address 171.69.232.182 255.255.255.240

ip nat outside

interface ethernet0

ip address 192.168.1.94 255.255.255.0

ip nat inside

access-list 1 permit 192.168.1.0 0.0.0.255

Трансляция перекрывающихся адресов

Рисунок 3. Трансляция перекрывающихся адресов

При таком режиме маршрутизатор выполняет действия, показанные ниже:

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

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

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

Распределение нагрузки ТСР

Рисунок 4. Распределение нагрузки ТСР

Маршрутизатор выполняет следующие действия при переборе адресов:

Пользователь узла В (9.6.7.3) открывает соединение с виртуальным узлом 1.1.1.127. Маршрутизатор получает пакет с запросом на подключение и создает новую запись трансляции, выбирая для нее новый реальный узел (1.1.1.1) в качестве внутреннего локального адреса IP. Маршрутизатор заменяет адрес назначения выбранным адресом реального узла и передает пакет. Узел 1.1.1.1 получает пакет и формирует ответ на него. Маршрутизатор получает ответный пакет и просматривает таблицу NAT, используя в качестве ключа поиска внутренний локальный адрес и номер порта. Маршрутизатор транслирует адрес источника в адрес виртуального узла и передает пакет по сети.

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

Для конфигурирования этого режима использования функций NAT необходимо произвести приведенные ниже шаги. Эта функция NAT позволяет устанавливать соответствие между одним виртуальным узлом и множеством реальных узлов сети. Каждая новая сессия ТСР открывает новый виртуальный узел. Эта сессия будет транслироваться как сессия с другим реальным узлом.

Действие	Команда
Определить пул адресов, состоящий из адресов реальных узлов	ip nat pool <имя> <начальный адрес> <конечный адрес> [netmask <маска подсети> или prefix-length <длина префикса>]
Определить список доступа, разрешающий адрес виртуального узла	access-list <номер> permit <адрес назначения или группа адресов>
Установить динамическую внутреннюю трансляцию адресов назначения на основе вписка доступа, определенного на предыдущем шаге	ip nat inside destination list <номер списка доступа> pool <имя>
Указать внутренний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внутренней сети	ip nat inside
Указать внешний интерфейс	interface <тип> <номер>
Пометить данный интерфейс, как принадлежащий внешней сети	ip nat outside

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

ip nat pool real-hosts 192.168.15.2 192.168.15.15 prefix-length 28 type rotary

ip nat inside destination list 2 pool real-hosts

interface serial 0

ip address 192.168.15.129 255.255.255.240

ip nat outside

interface ethernet 0

ip address 192.168.15.17 255.255.255.240

ip nat inside

access-list 2 permit 192.168.15.1

Терминология NAT

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

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

Приведем список определений и терминов, используемых функциями NAT:

Внутренний локальный адрес (Inside local address). Это адреса IP, присвоенные узлам внутренней сети. Как правило, эти адреса не являются зарегистрированными NIC (Network Information Center) или поставщиком услуг. Внутренний глобальный адрес (Inside global address). Этот адрес выдается организации центром NIC или поставщиком услуг Интернет. Он представляет один или более внутренних узлов во внешней сети. Внешний локальный адрес (Outside local address). Это адрес IP, присвоенный внешнему узлу и означающий, что внешний узел принадлежит внутренней сети. Этот адрес не нуждается в регистрации. Этот адрес должен принадлежать такому адресному пространству, которое имеет возможность маршрутизироваться во внутреннюю сеть. Внешний глобальный адрес (Outside global address). Это адрес IP, присвоенный узлу внешней сети владельцем данного узла. Этот адрес принадлежит глобальному адресному или сетевому пространству.

Трансляция перекрывающихся адресов

В описании NAT говориться, что данные функции используются для трансляции адресов IP, которые не являются официально зарегистрированными или закрепленными за определенными узлами или подсетями. Однако, может сложиться такая ситуация, при которой внутри корпоративной сети будет использоваться пространство адресов, официально закрепленное за другой сетью. Ситуация, при которой один и тот же адрес используется как легальный и как нелегальный одновременно, называют перекрыванием (Overlapping). Функции NAT можно использовать с целью трансляции внутренних адресов, перекрывающихся с внешними адресами. Этот режим NAT используется в случаях, когда одна сеть использует адресное пространство другой, и в то же время необходимо организовать взаимодействие этих двух сетей.

На Рисунок 3 показана работа NAT в режиме трансляции перекрывающихся адресов.

Трансляция внутренних адресов Source

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

Статическая трансляция устанавливает соответствие адресов по типу ?один к одному?, т.е. один глобальный внутренний адрес соответствует одному локальному внутреннему адресу. Статическая трансляция применяется в тех случаях, когда некий внутренний узел должен быть доступен извне по постоянному адресу (например, сервер WWW). Динамическая трансляция устанавливает соответствие между внутренним локальным адресом и пулом глобальных адресов.

На Рисунок 1 показан маршрутизатор, транслирующий адреса узлов, содержащихся в поле Source заголовков пакетов IP из внутренних во внешние.