Загрузка...



  • 5.1 Введение
  • 5.2 Примеры имен Интернета
  • 5.3 Иерархическая структура имен
  • 5.4 Администрирование имен
  • 5.5 Формальная структура имен
  • 5.6 Всемирное дерево имен
  • 5.7 Конфигурирование имен систем
  • 5.8 Адреса
  • 5.9 Форматы адресов
  • 5.10 Классы адресов
  • 5.11 Адреса не подключенных к Интернету систем
  • 5.12 Примеры адресации
  • 5.12.1 Присваивание сети адресов класса A
  • 5.12.2 Присваивание сети адресов класса В
  • 5.12.3 Присваивание сетям адресов класса С
  • 5.13 Трансляция имен в адреса
  • 5.14 Псевдонимы имен
  • 5.15 Неэффективность классов адресов
  • 5.16 Сети и подсети TCP/IP
  • 5.17 Маска подсети
  • 5.18 Специальные зарезервированные адреса
  • 5.18.1 Идентификация сети и подсети
  • 5.18.2 Широковещательная рассылка в локальной подсети
  • 5.18.3 Широковещательные рассылки к подсети
  • 5.18.4 Широковещательные рассылки в сети
  • 5.18.5 Ограничения на IP-адрес
  • 5.18.6 Кольцевой адрес
  • 5.18.7 Заключение о зарезервированных специальных адресах
  • 5.19 Суперсети и CIDR
  • 5.20 Необходимость следующего поколения протокола IP
  • 5.21 IP-адреса, интерфейсы и множественное пребывание
  • 5.22 Конфигурирование адресов и масок подсети
  • 5.23 Взаимосвязь имен и адресов
  • 5.24 Протокол ARP
  • 5.24.1 Содержимое сообщения ARP
  • 5.24.2 Таблица ARP
  • 5.24.3 Обратные запросы ARP
  • 5.25 Множество адресов для одного интерфейса
  • 5.26 Прокси ARP
  • 5.27 Многоадресные рассылки
  • 5.27.1 Группы многоадресной рассылки
  • 5.27.2 Трансляция многоадресных рассылок в адреса Ethernet и FDDI
  • 5.27.3 Трансляция адресов многоадресных рассылок в адреса Token-Ring
  • 5.28 Дополнительная литература
  • Глава 5

    Именование и адресация

    5.1 Введение

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

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

    Схема имен и адресов Интернета TCP/IP позволяет:

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

    ■ Позволить именам отражать логическую структуру организации

    ■ Присваивать адреса, отражающие топологию физической сети в организации

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

    5.2 Примеры имен Интернета

    Некоторые имена Интернета достаточно эксцентричны. Например, группа хостов Медицинской школы Йельского университета имеет следующие названия:

    blintz.med.yale.edu

    couscous.med.yale.edu

    gazpacho.med.yale.edu

    lazagne.med.yale.edu

    paella.med.yale.edu

    sukiyaki.med.yale.edu

    strudel.med.yale.edu

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

    www.whitehouse.gov (Белый дом — резиденция президента США. — Прим. пер.)

    ftp.microsoft.com (ftp-сайт компании Microsoft. — Прим. пер.)

    gopher.jvnc.net (служба Gopher. — Прим. пер.)

    Имена сайтов (узлов) Интернета не зависят от регистра символов. Например, www.whitehouse.gov можно записать как WWW.WHITEHOUSE.GOV или WWW.Whitehouse.Gov. В книге мы будем использовать имена из строчных, прописных или из комбинации строчных и прописных символов.

    5.3 Иерархическая структура имен

    Иерархическая структура имен достаточно проста. Каждая организация имеет содержательное имя верхнего уровня, подобное yale.edu, whitehouse.gov или microsoft.com. Схему именования внутри этих имен организация выбирает самостоятельно. Например, в Йельском и во многих других университетах именование делегировано факультетам и подразделениям. Следовательно, появляются имена, заканчивающиеся на:

    cs.yale.edu

    math.yale.edu

    geology.yale.edu

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

    lion.zoo.cs.yale.edu

    leopard.zoo.cs.yale.edu

    tiger.zoo.cs.yale.edu

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

    hickory.theory.cs.yale.edu

    pecan.theory.cs.yale.edu

    olive.theory.cs.yale.edu

    walnut.theory.cs.yale.edu

    5.4 Администрирование имен

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

    lion Администрируется в пределах вычислительного центра зоопарка, что позволяет иметь для каждого компьютера уникальное имя (lion, tiger и т.д.).
    lion.zoo Администрируется в пределах всего вычислительного центра. Для каждой подгруппы используется уникальное имя (zoo, theory и т.д.).
    lion.zoo.cs Администратор всей компьютерной сети Йельского университета присваивает каждому факультету и подразделению уникальное имя (cs, math, geology), что обеспечивает уникальность имен компьютеров во всем университете.
    lion.zoo.cs.yale.edu Обслуживается официальным комитетом по регистрации, что обеспечивает уникальность имен для всех организаций (yale.edu, microsoft.com). Следовательно, компьютеры во всем мире могут иметь уникальные имена.

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

    Первоначально сеть Интернет спонсировалась Министерством обороны США, создавшим собственный информационный центр сетей (Department of Defence Network Information Center — DDN NIC), который и занимался администрированием и регистрацией всех имен и адресов.

    В 1993 г. ответственность за гражданские имена и адреса принял на себя Национальной научный фонд (National Science Foundation — NFS), а обслуживанием военных систем продолжал заниматься DDN NIC.NFS организовал службу регистрации InterNIC Registration Service (InterNIC) — главную организацию по именованию и адресации во всемирном масштабе. Однако такая централизация привела к ненужным задержкам в работе этой службы. Поэтому InterNIC делегировала авторизацию имен в два главных центра региональной регистрации:

    ■ Азиатско-Тихоокеанский сетевой информационный центр (The Asia Pacific Network Information Center)

    ■ Европейский координационный сетевой центр RIPE (The RIPE Network Coordination Center). RIPE означает Европейский исследовательский центр по IP — Reseaux IP Européens.

    InterNIC и два этих региональных центра делегируют полномочия по именованию и адресации национальным и локальным регистрационным центрам, несущим ответственность за свои регионы.

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

    5.5 Формальная структура имен

    Имя состоит из последовательности меток, разделенных символами точки. Очень часто в имени присутствует две, три, четыре или пять меток. Ниже представлены допустимые имена для компьютеров:

    bellcore.com

    www.apple.com

    ftp.ncsa.uiuc.edu

    lion.zoo.cs.yale.edu

    Более длинные имена сложны для запоминания и ввода пользователями. Однако стандарт Интернета допускает для каждого маркера длину до 63 символов, а общую длину всего имени — до 255 символов.

    5.6 Всемирное дерево имен

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

    Рис. 5.1. Всемирное дерево имен

    Кроме того, доменом называется часть дерева имен, содержащая один из узлов и все нижестоящие узлы. Другими словами, домен создается из всех имен с одинаковыми окончаниями. Примеры доменов:

    edu и все имена ниже этого узла (заканчиваются на edu)

    yale.edu и все имена ниже этого узла (заканчиваются на yale.edu)

    cs.yale.edu и все имена ниже этого узла (заканчиваются на cs.yale.edu)

    Доменами верхнего уровня (top-level domain) являются (см. рис. 5.1):

    ■ edu — учебные заведения с четырехгодичным обучением

    ■ gov — учреждения федерального правительства США

    ■ com — коммерческие организации

    ■ net — организации сетевых служб Интернета

    ■ org — некоммерческие организации (96olympics.org, npr.org)

    ■ int — международные организации (gopher.nato.int). Редко используются и не видны в сети.

    ■ mil — военные организации (army.mil, navy.mil)

    ■ us — организации штатов США и региональных правительств, школы, двухгодичные колледжи, библиотеки и музеи

    ■ Countries — двухсимвольный код ISO, идентифицирующий десятки других доменов высокого уровня: fr — Франция, uk — Великобритания, de — Германия и т.д. (Для России: su — старый код и ru — новый. — Прим. пер.) Структура дерева внутри кода страны администрируется в пределах данной страны.

    Домены yale.edu, whitehouse.gov и ibm.com называются доменами второго уровня (second-level domain) — (см. рис. 5.2).

    Рис. 5.2. Домены второго уровня

    Есть еще одно ограничение. Меткой для корня (root) дерева имен служит символ точки. Именно поэтому именем системы lion вычислительного центра Йельского университета реально является:

    lion.zoo.cs.yale.edu.

    Однако большинство пользователей (в том числе и автор этой книги) опускают последнюю точку при вводе имен.

    5.7 Конфигурирование имен систем

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

    Для имени tiger в системе Unix от SunOS команда hostname позволяет указать или просмотреть имя хоста:

    > hostname

    tiger.jvnc.net

    Некоторые системы разделяют имя на две части — начальную метку и остаток от имени домена. Это делается с целью применения автоматического использования коротких имен для систем одного узла домена. Например, если пользователь работает на компьютере домена pnc.net и вводит mickey, то автоматически будет использовано имя mickey.jvnc.net.

    Пользователи программного продукта Chameleon для Windows вводят имя своего компьютера в двух раскрывающихся меню (см. рис. 5.3).

    Рис. 5.3. Конфигурирование имени системы

    5.8 Адреса

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

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

    Был выбран резонный для того времени метод. В соответствии с 32-разрядным регистром компьютера IP-адрес имеет длину в 32 бита (4 октета): результирующее адресное пространство (address space) — множество всех возможных адресов — составляет 2³², т.е. 4 294 967 269 номеров.

    Нотация с символом точки упрощает чтение и запись IP-адресов. Каждый октет (8 бит) адреса преобразуется в десятичное число и точкой отделяется от других. Например, адрес для blitz.med.yale.edu имеет в двоичной записи и нотации с точками следующие значения:

    10000010 10000100 00010011 00011111

    130 . 132 . 19 . 31

    Отметим, что наибольшим числом в записи с точками может быть 255, что соответствует 11111111.

    5.9 Форматы адресов

    Как показано на рис. 5.4, IP-адрес состоит из двух частей: адреса сети (network address) и локального адреса (local address). Адрес сети идентифицирует сеть, к которой подключен узел, а локальный адрес определяет отдельный узел внутри сети организации.

    Рис. 5.4. Формат IP-адреса

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

    5.10 Классы адресов

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

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

    Многие годы существовало только три размера блоков адресов — большой, средний и малый. Соответственно, было три различных формата сетевого адреса:

    ■ Класса А для очень больших сетей

    ■ Класса В для средних сетей

    ■ Класса С для небольших сетей

    Форматы для классов А, В и С показаны на рис. 5.5. Характеристики для адресов каждого класса представлены в таблице 5.1.

    Рис. 5.5. Традиционные классы адресов

    В первые дни существования Интернета все адреса класса А получили организации с очень большими сетями, например Военно-морской флот США или корпорация DEC. Сетевая часть таких адресов имеет длину в 1 октет, а оставшиеся 3 октета могут использоваться как локальная часть адреса и присваиваться как номера для узлов сетей.

    Существует очень мало адресов класса А, и даже большим организациям часто вполне достаточно адресов класса B. Сетевая часть адреса класса В имеет длину в 2 октета, а 2 оставшихся октета служат для нумерации узлов.

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

    Это простейший способ распределения IP-адресов. Нужно просто проанализировать первое число в нотации с точками. Диапазоны чисел для каждого класса показаны в таблице 5.1 и на рис. 5.5.


    Таблица 5.1 Характеристики классов адресов

    Класс Длина сетевого адреса (в октетах) Первое число Количество локальных адресов
    A 1 0-127 16777216
    В 2 128-191 65536
    С 3 192-223 256

    Кроме классов А, В и С, существуют специальные адресные форматы: классы E и D. Адреса класса D применяются для многоадресных рассылок в IP, когда одно сообщение распространяется среди группы разбросанных по сети компьютеров. Многоадресная рассылка необходима для приложений проведения конференций, которые мы рассмотрим ниже.

    Адреса класса E используются в экспериментальных целях.

    ■ Адреса класса D начинаются с номеров между 224 и 239.

    ■ Адреса класса E начинаются с номеров между 240 и 255.

    5.11 Адреса не подключенных к Интернету систем

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

    10.0.0.0–10.255.255.255

    172.16.0.0–172.31.255.255

    192.168.0.0–192.168.255.255

    Многие организации используют эти адреса. Но если такая компания впоследствии сольется с другой компанией или решит организовать соединения со своими клиентами или поставщиками через TCP/IP, произойдет конфликт адресов. Однако можно зарегистрировать адреса класса С и использовать их для внешних коммуникаций. Можно купить программное обеспечение агентов-прокси (proxy) для преобразования информации между внутренними адресами компьютеров и внешним миром через зарегистрированные адреса класса С. (Локальные сети, которые никогда не предполагается соединять с Интернетом, могут иметь произвольные IP-адреса. — Прим. пер.)

    Все "за" и "против" использования зарезервированных адресов можно узнать из RFC 1918 Address Allocation for Private Internet (Присваивание адресов в частных сетях Интернета),

    5.12 Примеры адресации

    В этом разделе мы познакомимся с несколькими примерами глобально уникальных адресов классов А, В и С. Позднее мы рассмотрим новый бесклассовый (classless) метод присваивания сетевых адресов.

    5.12.1 Присваивание сети адресов класса A

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

    15.255.152.2 relay.hp.com

    15.254.48.2 hpfcla.fc.hp.com

    Компания Hewlett-Packard владеет номерами от 15.0.0.0 до 15.255.255.255. Эти номера создают адресное пространство данной организации.

    5.12.2 Присваивание сети адресов класса В

    Зарегистрированное авторство на адреса позволяет присвоить фиксированное значение первым двум октетам в адресе класса B. Последние два октета администрируются в пределах самой организации. Например, следующие адреса и имена хостов предназначены для провайдера Global Enterprise Systems Service Provider, которому был присвоен адрес класса В со значением 128.121.

    128.121.50.145 tigger.jvnc.net

    128.121.50.143 mickey.jvnc.net

    128.121.51.51 camel-gateway.jvnc.net

    Системы Global Enterprise владеют адресами от 128.121.0.0 до 128.121.255.255.

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

    5.12.3 Присваивание сетям адресов класса С

    Организациям с небольшими сетями, которым требуются глобально уникальные адреса, предоставляются адреса класса С. Это означает, что регистрационное авторство присваивается на три первых октета полного адреса организации. Сама организация управляет только последним октетом. Например, компании WAIS, Inc. был присвоен адрес класса С 192.216.46. Некоторыми из ее адресов и имен хостов могут быть:

    192.216.46.4 ns.wais.com

    192.216.46.5 webworld.wais.com

    192.216.46.98 wais.wais.com

    WAIS, Inc. владеет номерами от 192.216.46.0 до 192.216.46.255.

    5.13 Трансляция имен в адреса

    Конечному пользователю проще вводить легко запоминаемые имена, когда требуется указать IP-адрес для системы назначения. Многие компьютеры сконфигурированы с созданием небольшого файла hosts, в котором перечислены имена и адреса всех локальных систем. Часть такого файла, хранимого на хосте компании Global Enterprise Systems с именем tigger.jvnc.net, может выглядеть как:

    128.121.50.2   r2d2.jvnc.net   r2d2

    128.121.50.7   nisc.jvnc.net   nisc

    128.121.50.141 minnie.jvnc.net minnie

    128.141.50.141 mickey.jvnc.net mickey

    128.141.50.143 donald.jvnc.net donald

    128.141.50.145 tigger.jvnc.net tigger

    128.141.50.148 chip.jvnc.net   chip

    128.141.50.149 bambi.jvnc.net  bambi

    128.121.50.152 sleepy.jvnc.net sleepy

    Все остальные примеры этой главы получены на tigger.jvnc.net.

    Запрос к распределенной базе данных системы именования доменов (Domain Name System — DNS) применяется при глобальном преобразовании имен в адреса. Предположим, приложение nslookup посылает запрос на трансляцию имени в Domain Name Server, называемую r2d2.jvnc.net. Мы решили выяснить адрес WWW сервера Белого дома (White House) и сервера пересылки файлов компании Novell, Inc.:

    > nslookup

    Default Server: r2d2.jvnc.net

    Address: 128.121.50.2


    > www.whitehouse.gov.

    Server: r2d2.jvnc.net

    Address: 128.121.50.2


    Name: www.whitehouse.gov.

    Address: 128.102.252.1


    > ftp.novell.com.

    Server: r2d2.jvnc.net

    Address: 128.121.50.2


    Name: bantu.Provo.Novell.COM

    Address: 137.65.1.3

    Aliases: ftp.novell.com

    Ответ на второй запрос показывает, что имя ftp.novell.com в действительности является псевдонимом (alias) для компьютера bantu.Provo.Novell.COM.

    5.14 Псевдонимы имен

    Часто по соглашению можно присвоить компьютеру дополнительно к его реальному имени некоторый псевдоним (или краткое имя — nickname). Например, хост nicol.jvnc.net обеспечивает пересылку файлов, службу gopher и службу World Wide Web (WWW). По соглашению, ему дополнительно присвоены следующие краткие имена:

    ftp.jvnc.net

    gopher.jvnc.net

    www.jvnc.net


    > ftp.jvnc.net.

    Server: r2d2.jvnc.net

    Address: 128.121.50.2


    Name: nicol.jvnc.net

    Address: 128.121.50.10

    Aliases: ftp.jvnc.net


    gopher.jvnc.net.

    Server: r2d2.jvnc.net

    Address: 128.121.50.2


    Name: nicol.jvnc.net

    Address: 128.121.50.10

    Aliases: gopher.jvnc.net


    > www.jvnc.net.

    Server: r2d2.jvnc.net Address: 128.121.50.2


    Name: nicol.jvnc.net

    Address: 128.121.50.10

    Aliases: www.jvnc.net

    >

    Когда нагрузка на nicol становится слишком большой, одну из его служб (и краткое имя этой службы) можно перенаправить на другой хост. Такой способ дает пользователю возможность достичь службы по неизменному имени, даже если ее домашний сайт будет изменен. Реальное имя хоста называется каноническим именем (canonical name).

    5.15 Неэффективность классов адресов

    Сеть класса А охватывает 16 777 216 адресов, класса В — 65 536, а сеть класса С содержит только 256 номеров. Огромная разница между этими значениями делает неэффективным выделение адресных блоков и приводит к истощению адресного пространства IP.

    Более эффективный бесклассовый метод выделения адресов для организации рассмотрен в разд. 5.19.

    5.16 Сети и подсети TCP/IP

    Организации с адресами сетей класса А или В, как правило, имеют очень большие сети, состоящие из множества локальных и нескольких региональных сетей. В этом случае имеет смысл разделить адресное пространство так, чтобы оно отражало структуру сети в виде нескольких подсетей. Для этого локальная часть адреса разделяется на часть для подсети (subnet part) и системную часть (system part) любым выбранным организацией способом (см. рис. 5.6).

    Рис. 5.6. Деление локального адреса на подсеть и системную часть

    Определение размера части адреса для подсети и присваивание номеров подсетям производится организацией, владеющей данной частью адресного пространства.

    Адреса подсети часто создаются в соответствии с байтовой границей. Организация с адресом класса В, например 128.21, может использовать для идентификации подсети третий байт:

    128.121.1

    128.121.2

    128.121.3

    Четвертый байт будет использоваться для идентификации отдельных хостов в подсети.

    Организация с адресом класса С имеет только однобайтовое адресное пространство. Она может вообще не проводить деления на подсети или использовать первые 4 бита для адреса подсети и 4 бита для адресов хостов (см. рис. 5.7). На рисунке видно, что локальный адрес (61) имеет двоичное представление 0011 1101. Первые 4 бита идентифицируют подсеть, а последние 4 бита определяют системы.

    Рис. 5.7. Четырехбитовая часть для подсети в адресе класса С

    5.17 Маска подсети

    Маршрутизация трафика на хост выполняется посредством анализа сетевой части и части для подсети IP-адреса. Сетевые части адресов классов А, В и С имеют фиксированный размер. Однако организация может указать собственный размер для поля подсети, и тут возникает вопрос о распознавании этой части в хостах и маршрутизаторах. На рис. 5.8 показано меню программы Chameleon для ввода размера поля подсети.

    Рис. 5.8. Конфигурирование маски подсети

    Размер поля подсети реально хранится в конфигурационном параметре, называемом маской подсети (subnet mask). Маска подсети имеет длину в 32 бита. Эти биты отражают для заданной сети длину поля подсети в адресе: для поля подсети в маске располагаются единицы, а для системного поля — нули.

    Например, если для идентификации подсети используется третий байт, а сеть имеет адрес 128.121, то маска подсети будет:

    11111111 11111111 11111111 00000000

    Часто маска подсети записывается десятичной нотацией с точками: 255.255.255.0

    Иногда применяется шестнадцатеричный формат:

    X'FF-FF-FF-00

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

    Например, если сеть содержит большое количество линий "точка-точка", то номера подсети будут использованы очень неэкономно, поскольку в коммуникации участвуют только две системы в каждой из подсетей "точка-точка". Организация может решить использовать 14-битовую маску (255.255.255.252) для соединений "точка-точка".


    Таблица 5.2 Подсети в сети класса В

    Биты подсети Количество подсетей Биты для хостов Количество хостов Маска подсети
    0 0 16 65534 255.255.0.0
    1 - 15 - Недопустимая комбинация
    2 2 14 16382 255.255.192.0
    3 6 13 8190 255.255.224.0
    4 14 12 4094 255.255.240.0
    5 30 11 2046 255.255.248.0
    6 62 10 1022 255.255.252.0
    7 126 9 510 255.255.254.0
    8 254 8 254 255.255.255.0
    9 510 7 126 255.255.255.128
    10 1022 6 62 255.255.255.192
    11 2046 5 30 255.255.255.224
    12 4096 4 14 255.255.255.240
    13 8190 3 6 255.255.255.248
    14 16382 2 2 255.255.255.252
    15 - 1 - Недопустимая комбинация

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

    11111111 11111111 11111100 00000000,

    что можно записать как 255.255.252.0. Далее мы рассмотрим, почему нельзя использовать комбинации 1/15 (1 бит для подсети и 15 бит для адресов хостов) и 15/1.

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

    5.18 Специальные зарезервированные адреса

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

    5.18.1 Идентификация сети и подсети

    Для указания сети удобно использовать формат адреса с точками. По соглашению, это делается при заполнении локальной части адреса нулями. Например, 5.0.0.0 указывает на сеть класса А, 131.18.0.0 — на сеть класса В, а 201.49.16.0 — на сеть класса С.

    Аналогичным образом указываются подсети. Например, если сеть 131.18.0.0 использует 8-битовую маску подсети, то 131.18.5.0 и 131.18.6.0 будут определять подсети. Эта же нотация применяется для записи сети или подсети назначения в таблице маршрутизации IP. Данное соглашение приводит к тому, что такие адреса нельзя присваивать хостам и маршрутизаторам. Кроме того, использование нуля как номера подсети делает некоторые адреса неоднозначными, например 130.15.0.0. По этой причине применение нулей в поле подсети запрещено в стандарте (см. RFC 1122). Сайты, использующие ноль как маску подсети, тем самым нарушают соглашение.

    5.18.2 Широковещательная рассылка в локальной подсети

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

    IP-адрес 255.255.255.255 (т.е. адрес, содержащий 32 единицы) рассылает датаграмму всем системам локальной связи. (Некоторые продукты, и в частности BSD 2.4 TCP/IP, используют для широковещательных рассылок нули вместо единиц. Это нестандартизованный способ, и с течением времени такие операционные системы должны быть заменены на правильные.) Такие широковещательные рассылки применяются, например, в протоколах BOOTP и DHCP, когда при загрузке система запрашивает для себя IP-адрес и инициализационные данные у загрузочного сервера. Клиент посылает boot-запрос по адресу 255.255.255.255 и использует зарезервированный адрес 0.0.0.0 как IP-адрес источника.

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

    5.18.3 Широковещательные рассылки к подсети

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

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

    Отметим, что при этом подразумевается отсутствие у систем зарезервированного IP-адреса 130.18.7.255.

    5.18.4 Широковещательные рассылки в сети

    Допустимо посылать датаграмму IP на каждый хост заданной удаленной сети. Это выполняется при установке всей локальной части адреса в единицы. Например, если администратору нужно послать объявление на все узлы сети 201.49.16.0 класса С с топологией Ethernet, то для такой широковещательной рассылки подойдет IP-адрес:

    201.49.16.255

    Однако этот адрес не должен быть присвоен ни одному из хостов.

    Адрес 131.18.255.255 должен применяться для отправки сообщения на все узлы сети класса С. Отметим, что, хотя и допустимо присваивать номер 255 одной из подсетей, это приведет к проблемам: неясно, предназначена ли широковещательная рассылка 130.15.255.255 для подсети или для всей сети. Чтобы исключить такие ситуации, никогда не следует присваивать номера из всех единиц (например, 255) для подсетей.

    5.18.5 Ограничения на IP-адрес

    Набор доступных IP-адресов существенно сокращается из-за применения специальных форматов для широковещательных рассылок и таблиц маршрутизации. Стандарт RFC 1122 Requirements for Internet Hosts — Communication Layers (Требования к хостам Интернета — уровни взаимодействия) гласит:

    ■ Поля сети, подсети или хоста не должны содержать одни нули.

    ■ Поля сети, подсети или хоста не должны содержать одни единицы. Следовательно, на практике поле должно быть длиной не менее 2 бит.

    5.18.6 Кольцевой адрес

    Полной противоположностью широковещательной рассылке является метод, когда сообщение вообще не покидает хоста. Существует множество хостов, совмещающих функции клиента и сервера. Локальные сервер и хост взаимодействуют друг с другом через IP внутри данного компьютера. Для этого служит специальный адрес, называемый кольцевым (loopback). По соглашению, для этого используется любой адрес, начинающийся на 127. На практике обычно применяют только адрес 127.0.0.1. Отметим, что для такого адреса резервируется адресное пространство целой сети класса С.

    Работу кольцевого адреса легко увидеть. Например, клиент и сервер FTP программы Chameleon могут одновременно соединяться в среде Microsoft Windows. После запуска сервера выводится экран, показанный на рис. 5.9.

    Рис. 5.9. Сервер FTP в среде Windows

    Клиент соединяется с сервером посредством кольцевого адреса 127.0.0.1 (см. рис. 5.10). Любые выполняемые клиентом пересылки файлов просто копируют файлы из одного каталога персонального компьютера в другой каталог того же компьютера. Журнал регистрации сервера позволяет записать выполняемые при этом операции с адресом 127.0.0.1 (см. рис. 5.11).

    Рис. 5.10. Клиент FTP соединяется с локальным сервером

    Рис. 5.11. Операции клиента с сервером FTP

    5.18.7 Заключение о зарезервированных специальных адресах

    Различные типы специальных адресов представлены в таблице 5.3.


    Таблица 5.3 Специальные адреса

    Адреса Описание
    0.0.0.0 Используется как адрес источника в конфигурационном запросе при загрузке. Также отмечает маршрутизатор по умолчанию в таблице маршрутизации.
    127.0.0.0 Зарезервирован
    127.0.0.1 Кольцевой адрес. Клиентом и сервером является один и тот же хост.
    127.0.0.2-127.255.255.255 Зарезервированы
    128.0.0.0 Зарезервирован
    191.255.0.0 Зарезервирован
    192.0.0.0 Зарезервирован
    255.255.255.0 Зарезервирован
    240.0.0.0-255.255.255.254 Зарезервированы
    255.255.255.255 Широковещательная рассылка на локально подключенные локальные сети.

    5.19 Суперсети и CIDR

    Методы присваивания адресов с использованием классов А, В и С крайне неэффективны. Адрес класса С предоставляет не более 254 доступных вариантов (0 и 255 нельзя использовать как адреса узлов). С другой стороны, если организации требуется несколько сотен или тысяч адресов, то ей нужно присвоить адрес класса В, и многие адреса такого пространства не будут задействованы.

    Больший смысл имеет побитовое выделение адресного пространства в соответствии с реальными потребностями организации. Это сделать очень просто. Например, если организации нужно 4000 адресов, то ей предоставляется 12 бит для применения в локальной части ее адресного пространства. Оставшиеся 20 бит образуют фиксированный префикс, используемый как адрес новой суперсети или префиксной части адреса. Общепринятым способом указания размера такой бесклассовой части адреса является /20.

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


    Таблица 5.4 Блоки CIDR из адресного пространства класса С

    Размер сетевой части Количество бит в локальной части Эквивалентное число сетей класса С Количество адресов для организации
    /24 8 1 256
    /23 9 2 512
    /22 10 4 1 024
    /21 11 8 2 048
    /20 12 16 4 096
    /19 13 32 8 192
    /18 14 64 16 384
    /17 15 128 32 768

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

    ■ Количество бит в сетевом префиксе

    ■ Реальный битовый шаблон, присвоенный как сетевой префикс для организации

    После этого маршрутизатор может направлять трафик в организацию, используя единственную строку из своей таблицы маршрутизации. Такой механизм называется маршрутизацией бесклассовых доменов Интернета (Classless Internet-Domain Routing — CIDR).

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

    Маршрутизация Интернета является более эффективной благодаря делегированию больших адресных блоков провайдерам. Далее провайдер присваивает подблоки адресов своим клиентам. Трафик маршрутизируется к провайдеру с помощью выделенного тому префикса блока. Затем провайдер использует более длинный префикс для маршрутизации трафика к своим клиентам.

    Например, провайдеру может быть выделен блок, начинающийся с 10-битового префикса 11000001 11, а одному из клиентов можно присвоить блок, начинающийся с 16-битового префикса 11000001 11011111.

    5.20 Необходимость следующего поколения протокола IP

    Внедрение бесклассовых адресов суперсетей и бесклассовой маршрутизации стало последней точкой в совершенствовании и использовании текущей схемы адресации протокола IP.

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

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

    Для решения данных проблем был разработан протокол IP версии 6 (Next Generation), обеспечивающий новые пути в использовании компьютеров и сетей (эта версия рассматривается в главах 22 и 23).

    5.21 IP-адреса, интерфейсы и множественное пребывание

    Идентификация сетей и подсетей в IP-адресе имеет много достоинств:

    ■ Упрощается работа по присваиванию адресов. Блок адресов можно делегировать для администрирования в отдельной сети или подсети.

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

    ■ Упрощается маршрутизация. Просмотр номеров сетей и подсетей выполняется быстрее и эффективнее.

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

    Рис. 5.12. Присвоение IP-адресов интерфейсом

    Маршрутизатор соединен с внутренними сетями 128.36.2 и 128.36.18, а также с внешней сетью 193.92.45. Так каков же будет IP-адрес этого маршрутизатора?

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

    Хост также может подключаться более чем к одной сети или подсети. На рис. 5.12 хост имеет интерфейсы для двух сетей Ethernet и два IP-адреса: 128.36.2.51 и 128.36.5.17.

    Системы, подключенные более чем к одной подсети, называются многоадресными (multihomed). (Отметим, что в WWW этот же термин означает размещение на одном сервере нескольких сайтов и обычно переводится как "множественное присутствие". — Прим. пер.) Многоадресный хост вносит определенные сложности в маршрутизацию IP. Данные к такому хосту направляются по разным путям, в зависимости от выбранного для коммуникации IP-адреса. Было бы более приемлемо связать с таким хостом несколько имен, соответствующих различным интерфейсам. Например, пользователи локальной сети 128.36.2 могут взаимодействовать с иным именем хоста, чем пользователи локальной сети 128.36.5 (см. рис. 5.12).

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

    5.22 Конфигурирование адресов и масок подсети

    Как мы уже знаем, пользовательский интерфейс конфигурирования TCP/IP различается на разных хостах. В системе tigger команда ifconfig используется для установки или просмотра связанных с интерфейсом параметров. Ниже показаны параметры Ethernet интерфейса 0 (le0):

    > ifconfig lе0

    le0: flags = 63 <UP,BROADCAST,NOTRAILERS,RUNNING>

         inet 128.121.50.145 netmask ffffff00 broadcast 128.121.50.255

    IP-адрес интерфейса — 128.121.50.145. Маска подсети выведена в шестнадцатеричном формате (ffffff00). Адресом широковещательной рассылки в этой подсети является 128.121.50.255.

    Эта же сведения были введены через меню Chameleon. Например, раскрывающееся меню служит для конфигурирования IP-адреса (см. рис. 5.13).

    Рис. 5.13. Конфигурирование IP-адреса через меню

    5.23 Взаимосвязь имен и адресов

    Посмотрев на имя системы (fermat.math.yale.edu) и ее IP-адрес в нотации с точками (128.36.23.3), можно подумать, что части имени соответствуют номерам в нотации с точками. Однако на самом деле между ними нет никакой связи.

    Действительно, иногда системам локальной сети присваивают имена, которые выглядят как соответствующие иерархии адресов. Однако:

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

    ■ Хосты со сходной структурой имен могут располагаться в различных локальных сетях или различных сетях других типов.

    Для примера рассмотрим следующие имена и адреса:

    macoun.cs.yale.edu 128.36.2.5

    bulldog.cs.yale.edu 130.132.1.2

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

    Организации могут расширять свои домены именами, подобными chicago.sales.abc.com или newyork.sales.abc.com. Соответствующие компьютеры могут располагаться в указанных городах (Чикаго или Нью-Йорке).

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

    5.24 Протокол ARP

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

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

    Хорошо, что существует процедура автоматического определения физических адресов. Протокол разрешения адресов (Address Resolution Protocol — ARP) обеспечивает метод динамической трансляции между IP-адресом и соответствующим физическим адресом на основе широковещательных рассылок.

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

    Рис. 5.14. Поиск физического адреса системы

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

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

    5.24.1 Содержимое сообщения ARP

    Запросы ARP первоначально использовались в локальных сетях Ethernet, но структура таких запросов имеет более общую природу, поэтому их можно применять и в Token-Ring, локальных сетях Fiber Distributed Data Interface (FDDI) или в глобальных сетях Switched Multimegabit Data Service (SMDS). Один из вариантов ARP был разработан для региональных сетей с виртуальными цепями (подобных Frame Relay).

    Сообщение ARP помещается в поле данных кадра вслед за заголовком (заголовками) нижних уровней. Например, для Ethernet с кадрами DIX сообщение ARP следует за MAC-заголовком, а для сетей типа 802.3 или 802.5 — за MAC-заголовком, заголовком Logic Link Control (LLC) и подзаголовком Sub-Network Access Protocol (SNAP). Тип протокола для таких кадров (ARP через Ethernet) определяется кодом X'0806. В таблице 5.5 показаны поля сообщения ARP.


    Таблица 5.5 Формат сообщения ARP

    Количество октетов Поле
    2 Тип аппаратного адреса
    2 Протокол адресации высокого уровня
    1 Длина аппаратного адреса
    1 Длина адреса высокого уровня
    2 Тип сообщения: 00 01 = запрос, 00 02 = ответ
    * Аппаратный адрес источника
    * Адрес высокого уровня (IP) источника
    * Аппаратный адрес приемника
    * Адрес высокого уровня (IP) приемника

    Длина последних четырех полей зависит от используемой технологии и применяемого протокола. Аппаратный адрес локальной сети 802.X содержит 6 октетов, а IP-адрес — 4 октета. В таблице 5.6 показаны примеры форматов сообщений, запрашивающих трансляцию IP-адресов в адреса Ethernet.


    Таблица 5.6 Примеры сообщений для запросов ARP

    Количество октетов Поле Описание
    2 00 01 Ethernet
    2 08 00 IP
    1 06 Длина физического адреса в 6 октетов для Ethernet
    1 04 Длина физического адреса IP
    2 00 01 Запрос
    6 02 07 01 00 53 23 Аппаратный адрес источника
    4 80 24 04 12 Адрес высокого уровня источника
    6 00 00 00 00 00 00 Аппаратный адрес назначения
    4 80 24 04 0B Адрес высокого уровня назначения

    При ответе меняются роли источника и приемника. Например, адресом высокого уровня источника в ответе на запрос станет X'80-24-04-0B.

    Применение ARP не ограничивается только TCP/IP: во втором поле также можно указать протокол, использующий ARP.

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

    5.24.2 Таблица ARP

    Большинство систем обеспечивает для администратора следующие команды:

    ■ Просмотр локальной таблицы ARP

    ■ Ручное удаление или добавление элементов таблицы

    ■ Загрузку в таблицу информации из конфигурационного файла

    Диалог пользователя в процессе выполнения команды arp -a показывает как изменяется содержимое таблицы ARP системы tigger при соединении по telnet с хостом mickey, сведений о котором ранее не было в таблице. Отметим, что в выводе из команды указываются имена каждой системы, их IP-адреса и 6 октетов физического адреса (шестнадцатеричные числа, разделенные двоеточием).

    > arp -a

    nomad-eth0.jvnc.net (128.121.50.50) at 0:0:с:2:85:11

    r2d2.jvnc.net (128.121.50.2) at 8:0:20:а:2с:3f

    jim-mac.jvnc.net (128.121.50.162) at 8:0:7:6f:а6:65

    tom-mac.jvnc.net (128.121.50.163) at 8:0:7:ff:96:9е

    chip.jvnc.net (128.121.50.148) at 0:0:3b:86:6:4c

    nisc.jvnc.net (128.121.50.7) at 8:0:20:11:d2:b7

    nicol.jvnc.net (128.121.50.10) at 0:0:3b:30:32:34

    minnie.jvnc.net (128.121.50.141) at 8:0:20:7:b5:da

    >


    > telnet mickey.3vnc.net

    Trying 128.121.50.143 …

    Connected to mickey.jvnc.net.

    Escape character is '^]'

    SunOS UNIX (mickey.jvnc.net)


    login:

    . . .

    logout


    > arp -a

    nomad-eth0.jvnc.net (128.121.50.50) at 0:0:c:2:85:11

    r2d2.jvnc.net (128.121.50.2) at 8:0:20:a:2c:3f

    jim-mac.jvnc.net (128.121.50.162) at 8:0:7:6f:a6:65

    tom-mac.jvnc.net (128.121.50.163) at 8:0:7:ff:96:9e

    chip.jvnc.net (128.121.50.148). at 0:0:3b:86:6:4c

    nisc.jvnc.net (128.121.50.7) at 8:0:20:11:d2:b7

    nicol.jvnc.net (128.121.50.10) at 0:0:3b:80:32:34

    minnie.jvnc.net (128.121.50.141) at 8:0:20:7:b5:da

    mickey.jvnc.net (128.121.50.143) at 8:0:20:7:53:8f

    >

    5.24.3 Обратные запросы ARP

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

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

    Обратные запросы ARP были вытеснены протоколом BOOTP и его улучшенной версией, названной протоколом динамического конфигурирования хоста (Dynamic Host Configuration Protocol — DHCP). Этот протокол гораздо мощнее и предоставляет больший набор конфигурационных параметров для систем TCP/IP (BOOTP и DHCP будут рассмотрены в главе 11).

    5.25 Множество адресов для одного интерфейса

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

    Рис. 5.15. Интерфейс маршрутизатора с двумя IP-адресами

    На рис. 5.15 показана локальная сеть с двумя логическими подсетями — 128.36.4.0 и 128.36.5.0. Интерфейсу локальной сети маршрутизатора присвоено два IP-адреса: 128.36.4.1 и 128.36.5.1. В такой сети трафик будет успешно маршрутизироваться, однако потребуется дополнительная работа по правильной маршрутизации датаграмм, направленных на хосты этой сети.

    Предположим, что система А имеет 8-битовую маску подсети. Когда А захочет послать датаграмму в В, она пошлет ее маршрутизатору. Чтобы этого избежать, хост локальной сети нужно сконфигурировать с 7-битовой маской подсети, при этом 4 будет соответствовать 0000 0100, а 5 — 0000 0101.

    5.26 Прокси ARP

    Предположим, что в сети нельзя использовать смежные номера. Например, 128.36.4.0 и 128.36.20.0 совместно используют носитель. В этом случае хосты локальной сети можно конфигурировать с маской 255.255.0.0, т.е. без выделения подсетей. Затем хосты смогут использовать ARP для всех точек назначения сети 128.36. Этот метод прекрасно подходит для сетей с совместным использованием носителя, но что делать с трафиком в подсеть сети 128.36, которая не принадлежит общей локальной сети?

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

    5.27 Многоадресные рассылки

    Широковещательные рассылки в IP позволяют доставить датаграмму на все системы сети или подсети. Вариант с большей избирательностью называется многоадресной (multicasting) рассылкой. В этом случае датаграммы пересылаются группе систем (см. рис. 5.16).

    Рис. 5.16. Распространение датаграммы в многоадресной рассылке

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

    Для многоадресной рассылки используются IP-адреса класса D, формат которых представлен на рис. 5.17. Определен протокол для стандартной многоадресной рассылки, однако число поддерживающих этот протокол хостов и маршрутизаторов в настоящее время ограничено. Возможно, через несколько лет это положение изменится.

    Рис 5.17. Адрес класса D для многоадресной рассылки в IP

    5.27.1 Группы многоадресной рассылки

    Группа многоадресной рассылки (multicast group) — это набор систем, которым присвоен IP-адрес многоадресной рассылки. Члены группы продолжают использовать собственные IP-адреса, однако они имеют возможность принимать данные, посланные в многоадресной рассылке. Любая система может принадлежать нескольким группам многоадресной рассылки или ни одной из них.

    Адреса класса D для многоадресных рассылок находятся в диапазоне номеров от 224 до 239. Некоторые IP-адреса многоадресных рассылок являются постоянными (они перечислены в RFC о присвоенных номерах Интернета). К таким адресам относятся:

    224.0.0.1 Все хосты локальной подсети

    224.0.0.2 Все маршрутизаторы локальной подсети

    224.0.0.5 Все маршрутизаторы, поддерживающие протокол Open Shortest Path First (OSPF)

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

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

    ■ Реализацию команды для объединения с многоадресной группой и идентификации интерфейса, который будет отслеживать соответствующие адреса

    ■ Распознавание на уровне IP многоадресной рассылки для входящих и исходящих датаграмм

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

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

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

    Хосты используют протокол обслуживания групп Интернета (Internet Group Management Protocol — IGMP) для отчета о своем членстве в группе перед ближайшим маршрутизатором, поддерживающим многоадресные рассылки. Такой отчет посылается по IP-адресу многоадресной рассылки, присвоенному данной группе. Маршрутизатор не транслирует такой отчет вне пределов локальной сети, поэтому он будет услышан только маршрутизаторами и другими членами локальной группы.

    Так как протокол IGMP предполагает полноту информации о членстве в группе, то он разрешает маршрутизаторам периодически опрашивать хосты о членстве в различных текущих группах. Опрос проводится по IP-адресу многоадресной рассылки 224.0.0.1 на все хосты.

    5.27.2 Трансляция многоадресных рассылок в адреса Ethernet и FDDI

    Физическим интерфейсам локальных сетей Ethernet и FDDI могут присваиваться один или несколько адресов для многоадресных рассылок. Это логическое присваивание предполагает выбор из нескольких подходящих для этого значений, что существенно упрощает трансляцию IP-адресов многоадресных рассылок в физические адреса таких рассылок. Отметим, что для этого не нужен протокол ARP.

    Для локальных сетей Ethernet и FDDI применяются следующие правила:

    ■ Первые 3 октета физического адреса для многоадресной рассылки имеют значение 01-00-5E.

    ■ Следующий далее бит должен быть установлен в 0, а последние 23 бита должны иметь значение младших 23-х битов IP-адреса многоадресной рассылки.

    Такое отображение показано на рис. 5.18:

    ■ Последние 23 бита IP-адреса многоадресной рассылки отмечены как "х". Эти биты копируются в младшие биты физического адреса многоадресной рассылки.

    ■ Отмеченные символами "?" позиции IP-адреса многоадресной рассылки могут быть заполнены произвольными битами. Они не копируются в физический адрес многоадресной рассылки.

    Рис. 5.18. Отображение части IP-адреса на физический адрес

    Таким образом, три IP-адреса многоадресной рассылки

    11100000 00010001 00010001 00010001

    11100000 10010001 00010001 00010001

    11100001 10010001 00010001 00010001

    будут отображаться на один и тот же физический адрес многоадресной рассылки:

    00000001 00000000 01011110 00010001 00010001 00010001

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

    Хорошим способом исключения дополнительной обработки является выбор адресов многоадресных рассылок, в которых в позициях "?" стоят нули. При этом все равно остается 2²³ (примерно 9 млн.) адресов для многоадресных рассылок.

    5.27.3 Трансляция адресов многоадресных рассылок в адреса Token-Ring

    К сожалению, рассмотренную выше схему для Ethernet и FDDI почти никогда нельзя применить в Token-Ring (по крайней мере, на момент написания этой книги), поскольку многие аппаратные интерфейсы Token-Ring не могут быть сконфигурированы на произвольные адреса многоадресных рассылок. Следовательно, остается применить один из трех методов трансляции (в зависимости от оборудования):

    ■ Вставить 23 бита IP-адреса многоадресных рассылок (этот метод рассмотрен выше)

    ■ Выбрать и использовать один из функциональных (functional) адресов Token-Ring

    ■ Применить широковещательную рассылку по всему кольцу Token-Ring

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

    03-00-00-20-00-00

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

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

    5.28 Дополнительная литература

    Классы адресов определены в стандарте IP RFC 791. Выделение подсетей описывается в RFC 950, а формирование суперсетей — в RFC 1519. Широковещательные рассылки рассмотрены в RFC 919 и RFC 922.

    Протокол Address Resolution Protocol специфицирован для Ethernet в RFC 826. Обратные ARP обсуждаются в RFC 903.

    RFC 1112 посвящен многоадресным рассылкам в IP. RFC 1390 определяет трансляцию между IP-адресами многоадресных рассылок и адресами FDDI. RFC 1469 специфицирует трансляцию между IP-адресами многоадресных рассылок и адресами Token-Ring.

    RFC 1178 содержит как серьезные, так и не совсем серьезные советы по выбору имени для компьютера. RFC 1034 и 1101 подробно обсуждают именование доменов. RFC 1035 описывает протоколы для создания Domain Name System и реализацию этой системы.

    Стандарт Hosts Requirements (Требования к хостам), RFC 1122, предоставляет дополнительные сведения об именовании и адресации, равно как и корректирует неточности в некоторых стандартах.








    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх