|
маршрутизация - это одна из наиболее важных функций ip. на рисунке 9.1 показана упрощенная модель того, что реализуется на ip уровене. датаграммы, которые должны быть смаршрутизированы, могут генерироваться как локальным хостом, так и каким-либо удаленным хостом. в последнем случае наш хост должен быть сконфигурирован как маршрутизатор, иначе датаграммы, получаемые через сетевые интерфейсы и не предназначенные нашему хосту, будут молча удалены. на рисунке 9.1 также показан демон маршрутизации, который обычно является пользовательским процессом. наиболее часто в unix системах используются демоны routed и gated. термин демон (daemon) означает, что процесс работает "в фоновом режиме" и его функционирование не оказывает влияние на систему в целом. демоны обычно стартуют, когда система загружается, и живут все время, пока система работает. протоколы маршрутизации, используемые на конкретном хосте, определяют, как будет происходить обмен информацией о маршрутах с удаленными маршрутизаторами. (заинтересованные читатели могут обратиться к [perlman 1992] для получения более подробной информации.) мы вкратце рассмотрим динамическую маршрутизацию и протокол обмена информацией о маршрутизации (rip - routing information protocol) в главе 10. в этой главе мы рассмотрим, как ip уровень принимает решения о маршрутизации. ip уровень обращается к таблице маршрутизации, которая показана на рисунке 9.1 (на загруженных хостах подобное обращение может происходить несколько сот раз в секунду), однако демон маршрутизации обновляет таблицу значительно реже (примерно один раз каждые 30 секунд). таблица маршрутизации также может быть обновлена, когда принимается icmp сообщение о перенаправлении (icmp redirect), мы увидим это в разделе "icmp ошибки перенаправления", когда будем рассматривать команду route. эта команда обычно исполняется при загрузке системы и устанавливает некоторые исходные маршруты. также в этой главе мы будем использовать команду netstat, для просмотра таблиц маршрутизации.
рисунок 9.1 действия, выполняемые ip уровнем. прежде чем начать обсуждение ip маршрутизации, необходимо понять, что именно ядро обновляет в таблице маршрутизации. информация, содержащаяся в таблице маршрутизации, необходима ip уровню для принятия решения о маршрутизации. в разделе "ip маршрутизация" главы 3 мы показали, каким образом ip просматривает свою таблицу маршрутизации.
совпавший адрес хоста используется всегда перед совпавшим адресом сети. маршрутизация, осуществляемая ip - процесс поиска в таблице маршрутизации, определение интерфейса, куда будет послан пакет, называется механизмом маршрутизации. с другой стороны, политика маршрутизации устанавливает правила, по которым решается, какой маршрут будет внесен в таблицу маршрутизации. ip осуществляет механизм маршрутизации, тогда как маршрутизирующий демон обычно определяет политику маршрутизации. простая таблица маршрутизации давайте рассмотрим типичные таблицы маршрутизации. на хосте svr4 мы запустили команду netstat с опцией -r, чтобы просмотреть таблицу маршрутизации, и с опцией -n, которая печатает ip адреса в цифровом формате, а не в виде имен. (мы сделали это, потому что некоторые пункты таблицы маршрутизации это сети, а не хосты. без опции -n команда netstat просматривает файл /etc/networks, и берет оттуда имена сетей. при этом может получиться некоторая путаница, потому что в выводе команды помимо имен хостов появятся имена сетей.)
svr4 % netstat -rn
в первой строке говорится, что для пункта назначения 140.252.13.65 (хост slip) шлюз (маршрутизатор), на который будут посылаться пакеты, это 140.252.13.35 (bsdi). хост slip подсоединен к bsdi через slip канал, а bsdi находится в той же сети ethernet, что и данный хост. для конкретного маршрута может быть показано 5 различных флагов.
u g h d m
флаг g очень важен, потому что именно этот флаг определяет различие между непрямым маршрутом (indirect route) и прямым маршрутом (direct route). (флаг g не устанавливается для прямого маршрута.) отличие заключается в том, что у пакета, направляющегося по прямому маршруту, ip адрес и адрес канального уровня указывают на конечный пункт назначения (рисунок 3.3). когда пакет отправляется по непрямому маршруту, ip адрес указывает на конечный пункт назначения, а адрес канального уровня указывает на маршрутизатор следующей пересылки. мы видели подобный пример этого на рисунке 3.4. в этой таблице маршрутизации мы видим непрямой маршрут (флаг g установлен), при этом ip адрес пакета, который будет передаваться по этому маршруту, будет совпадать с ip адресом конечного пункта назначения (140.252.13.65), а адрес канального уровня будет указывать на соответствующий маршрутизатор, ip адрес которого 140.252.13.35. очень важно понимать разницу между флагами g и h. флаг g определяет различие между прямым и непрямым маршрутом, как описано выше. флаг h указывает на то, что адрес пункта назначения (первая колонка вывода команды netstat) это полный адрес хоста. отсутствие флага h означает, что адрес назначения это адрес сети (идентификатор хоста должен быть установлен в 0). при просмотре таблицы маршрутизации используются следующие правила: если маршрут указывает на хост он должен полностью совпадать с ip адресом пункта назначения, если маршрут указывает на сеть - сопасть должны идентификаторы сети и любого идентификатора подсети в адресе пункта назначения. большинство версий команды netstat сначала печатают все пункты, указывающие на хосты, после чего печатаются пункты, указывающие на сети. колонка счетчика обращений (reference count) сообщает о количестве использований каждого маршрута. протоколы, ориентированные на соединения, такие как tcp, занимают маршрут все время, пока соединение установлено. если установить telnet соединение между хостами svr4 и slip, то счетчик обращений будет установлен в 1. если установить еще одно telnet соединение, счетчик будет показывать 2, и так далее. следующая колонка (use) показывает количество пакетов, прошедших по этому маршруту. если запустить программу ping, которая отправит 5 пакетов, счетчик установится в значение 5 (естественно, при условии, что никто больше не использует этот маршрут). последняя колонка интерфейс (interface) сообщает нам имя локального интерфейса. вторая строка в выводе относится к loopback интерфейсу (глава 2, раздел "интерфейс loopback"), который всегда имеет имя lo0. флаг g не установлен, так как маршрут не ведет к маршрутизатору. флаг h указывает, что адрес назначения (127.0.0.1) это адрес хоста, а не адрес сети. когда флаг g не установлен, это указывает на прямой маршрут, в колонке gateway указывается ip адрес исходящего интерфейса. третья строка вывода описывает маршрут по умолчанию. каждый хост должен иметь один или несколько маршрутов по умолчанию. этот пункт указывает на то, что необходимо посылать пакеты на маршрутизатор 140.252.13.33 (sun), если не был найден конкретный маршрут. это означает, что хост svr4 может получить доступ к другим системам в internet через маршрутизатор sun (и его slip канал) воспользовавшись этим единственным пунктом таблицы маршрутизации. возможность установить маршрут по умолчанию это одна из наиболее мощных концепций ip маршрутизации. флаги для этого маршрута (ug) говорят о том, что маршрут указывает на маршрутизатор. здесь мы специально назвали sun маршрутизатором, а не хостом, потому что когда он работает как маршрутизатор по умолчанию, используются его функции ip перенаправления, при этом он не выступает в роли хоста. требования к хостам host requirements rfc указывает, что ip уровень должен поддерживать несколько маршрутов по умолчанию. большинство реализаций, однако, этого не позволяют. когда существует несколько маршрутов по умолчанию, общая техника выбора маршрута заключается в последовательном многократном переборе маршрутов. именно так поступает, например, solaris 2.2.
и последняя строка указывает на подключенный ethernet. флаг h не установлен, это указывает на то, что адрес назначения (140.252.13.32) это адрес сети, при этом идентификатор хоста установлен в 0. и действительно, 5 младших битов установлены в 0 (рисунок 3.11). это прямой маршрут (флаг g не установлен), поэтому в колонке gateway указывается ip адрес исходящего интерфейса. существует еще один немаловажный аспект, оказывающий влияние на маршрутизацию, однако он не отражен в выводе команды netstat. это маска подсети, связанная с адресом назначения (140.252.13.32). когда адрес пункта назначения сравнивается с ip адресом 140.252.13.33, адрес перед сравнением, логически суммируется с маской подсети, связанной с этим адресом назначения (0xffffffe0 из раздела "пример подсети" главы 3). так как ядро знает каждый интерфейс, связанный с каждым пунктом таблицы маршрутизации, и так как каждый интерфейс имеет маску подсети, каждый пункт таблицы маршрутизации имеет собственную маску подсети. сложность таблицы маршрутизации хоста зависит от топологии сетей, к которым хост имеет доступ.
давайте проследим за тем, что делает ip когда обращается к таблице маршрутизации, чтобы смаршрутизировать пакеты на хосте svr4.
ftp 140.252.13.34 ftp localhost ftp 127.0.0.1
в двух первых случаях второй поиск в таблице маршрутизации приведет к совпадению с сетью 140.252.13.32, и пакет посылается через ethernet драйвер. как мы показали на рисунке 2.4, пакет, предназначенный на собственный ip адрес хоста, посылается в loopback драйвер, который ставит пакет во входную очередь ip. в двух следующих случаях указано имя loopback интерфейса или его ip адрес, поэтому первый поиск в таблице маршрутизации приведет к совпадению адреса хоста, и пакет отсылается в loopback драйвер, который ставит его во входную очередь ip. во всех четырех случаях пакет отправляется в loopback драйвер, однако принимаются два разных решения о маршрутизации.
инициализация таблицы маршрутизации мы никогда не упоминали о том, как создаются пункты в таблице маршрутизации. когда инициализируется интерфейс (обычно, когда адрес интерфейса устанавливается командой ifconfig), автоматически создается прямой маршрут для этого интерфейса. для каналов точка-точка и loopback интерфейса устанавливается маршрут к хосту (то есть устанавливается флаг h). для широковещательных интерфейсов, таких как ethernet, маршрутом является сама эта сеть. маршруты к хостам или сетям, которые не подключены непосредственно, должны быть помещены в таблицу маршрутизации каким-либо иным образом. самый распространенный способ создания маршрутов - с помощью команды route, что обычно делается из загрузочных файлов при старте системы. на хосте svr4 были исполнены следующие команды, которые добавляют пункты, показанные ранее: route add default sun 1 route add slip bsdi 1
третий аргумент (default и slip) это пункты назначения, четвертый аргумент это маршрутизатор (gateway) и последний аргумент это показатель маршрутизации. команда route использует показатель маршрутизации следующим образом: она устанавливает флаг g, если показатель больше чем 0, и не устанавливает флаг g, если показатель равен 0. к сожалению, совсем немногие системы содержат команды route в своих стартовых файлах. в 4.4bsd и bsd/386 это /etc/netstat, в svr4 - /etc/inet/rc.inet, в solaris 2.x - /etc/rc2.d/s69inet, в sunos 4.1.x - /etc/rc.local и в aix 3.2.2 - /etc/rc.net.
в некоторых системах маршрутизатор по умолчанию содержится в файле, например, /etc/defaultrouter. этот пункт по умолчанию добавляется в таблицу маршрутизации при каждой перезагрузке. существует еще один способ заполнить таблицу маршрутизации с помощью запуска демона маршрутизации (см. главу 10) или с помощью нового протокола определения маршрутов (раздел "icmp сообщения поиска маршрутизатора"). более сложные таблицы маршрутизации хост sun является маршрутизатором по умолчанию для всех хостов в нашей подсети, так как он имеет slip канал с дозвоном, который подключен к internet (см. рисунок на внутренней стороне обложки).
sun % netstat -rn
первые два пункта таблицы маршрутизации sun идентичны первым двум пунктам для хоста svr4: маршрут, указывающий на хост slip, через маршрутизатор bsdi и loopback маршрут. третья строка отличается. это прямой маршрут (флаг g не установлен) на хост (флаг h установлен), соответствующий каналу точка-точка, интерфейс slip. если мы посмотрим на вывод команды ifconfig,
sun % ifconfig sl0
то увидим, что адрес назначения в таблице маршрутизации на другом конце канала точка-точка (маршрутизатор netb), а адрес маршрутизатора в действительности это локальный ip адрес исходящего интерфейса (140.252.1.29). (раньше мы говорили, что для прямых маршрутов адрес маршрутизатора печатается командой netstat как локальный ip адрес используемого интерфейса.) пункт по умолчанию это непрямой маршрут (флаг g), указывающий на сеть (нет флага h). адрес маршрутизатора - 140.252.1.183, (адрес на другом конце slip канала), а не локальный ip адрес slip интерфейса (140.252.1.29) (так как это непрямой маршрут). необходимо обратить внимание на то, что третья и четвертая строки в выводе команды netstat (интерфейс sl0) создаются программным обеспечением slip при установлении канала slip, они удаляются, когда канал slip отключается. нет маршрута к пункту назначения во всех наших примерах сделано предположение, что поиск в таблице маршрутизации заканчивается успешно и будет обнаружено соответствие, хотя бы с маршрутором по умолчанию. что произойдет, если маршрут по умолчанию отсутствует, и не будет найдено совпадение с указанным пунктом назначения? ответ зависит от того, какого рода ip датаграмма обрабатывается, то есть была ли она сгенерирована непосредственно этим хостом или она должна быть перенаправлена (в том случае, если хост выступает в роли маршрутизатора). если датаграмма была сгенерирована этим хостом, приложению, которое отправило датаграмму, возвращается ошибка "хост недоступен" (host unreachable) или "сеть недоступна" (network unreachable). если датаграмма должна быть перенаправлена, посылающему хосту возвращается icmp собщение о недоступности хоста. мы рассмотрим эту ошибку в следующем разделе. icmp ошибки о недоступности хоста и сети icmp ошибка о недоступности хоста (host unreachable) отправляется маршрутизатором, когда он получает ip датаграмму, которую невозможно перенаправить. (на рисунке 6.10 мы показали формат icmp сообщений о недоступности.) мы сможем пронаблюдать это в нашей сети, если выключим slip канал с дозвоном на маршрутизаторе sun и попробуем отправить пакет через slip канал с любого другого хоста, указав sun как маршрутизатор по умолчанию. ранние реализации tcp/ip в bsd генерировали и ошибки о недоступности хоста, и ошибки о недоступности сети, в зависимости от того, принадлежал ли пункт назначения локальной подсети или нет. 4.4bsd генерирует только ошибку о недоступности хоста.
обратимся снова к выводу команды netstat запущенной на маршрутизаторе sun, вывод показан в предыдущем разделе. мы видим, что пункт таблицы маршрутизации, который соответствует slip каналу, добавляется, когда slip канал включается, и удаляется, когда slip канал выключается. это означает, что когда slip канал отключен, маршрута по умолчанию на sun не существует. однако мы не будем пытаться изменить все таблицы маршрутизации у хостов в нашей маленькой сети, оставив им возможность самим удалить свои маршруты по умолчанию. вместо этого мы посчитаем icmp сообщения о недоступности хоста, сгенерированные sun для любых пакетов, которые он не может перенаправить. мы можем увидеть это, запустив ping с svr4 на хост, находящийся на другом конце slip канала (в настоящее время этот хост выключен):
svr4 % ping gemini
на рисунке 9.2 мы показали вывод команды tcpdump для этого примера. (команда запущена на хосте bsdi).
1 0.0
svr4 >
gemini: icmp: echo request
рисунок 9.2 сообщение icmp о недоступности хоста в ответ на ping.
когда маршрутизатор sun обнаруживает, что на хост gemini нет маршрута, он отвечает на эхо запрос сообщением о недоступности хоста. если мы включим slip канал, подключающий нас к internet, и попробуем послать ping на несуществующий в internet ip адрес, то рано или поздно получим сообщение об ошибке. интересно посмотреть, как далеко уйдет пакет по internet, перед тем как будет получена ошибка:
sun % ping 192.82.148.1
этот ip
адрес не подключен к internet
обратившись к рисунку 8.5, мы увидим, что пакет прошел через шесть маршрутизаторов, перед тем как было определено, что ip адрес не существует. только когда он дошел до пределов nsfnet магистрали, была выявлена ошибка. это произошло из-за того, что шесть маршрутизаторов, которые перенаправляли пакет, отправляли его на пункт назначения по умолчанию. и только когда пакет достиг nsfnet магистрали, маршрутизатор, имеющий полное представление о каждой сети, подключенной к internet, смог определить ошибку. это иллюстрирует тот факт, что большинство маршрутизаторов функционируют, не представляя себе полной топологии сетей. [ford, rekhter, and braun 1993] определяет домены маршрутизации верхнего уровня (top-level routing domain) как маршрутизаторы, поддерживающие и обрабатывающие информацию о большинстве узлов internet и не использующие маршрутов по умолчанию. в internet существует пять доменов маршрутизации верхнего уровня: nfsnet магистраль, commercial internet exchange (cix), nasa science internet (nsi), sprintlink и european ip backbone (ebone). перенаправлять или не перенаправлять мы уже несколько раз упоминали о том, что хост не сможет перенаправить ip датаграммы, если он специально не сконфигурирован, чтобы выступать в роли маршрутизатора. как осуществляется подобная конфигурация? большинство berkeley реализаций, имеют переменную ядра, названную ipforwarding (или похоже). (см. приложение е.) некоторые системы (bsd/386 и svr4, например) перенаправляют датаграммы, если эта переменная установлена в ненулевое значение. в sunos 4.1.x определено три значения для этой переменной: -1 обозначает, что перенаправление никогда не будет осуществляться и что никогда нельзя будет сменить значение этой переменной, 0 обозначает, что перенаправление не осуществляется, однако значение переменной устанавливается в 1, когда два или более интерфейсов активизированы, и 1 обозначает, что перенаправление осуществляется всегда. у solaris 2.x также существует три значения, а именно 0 (перенаправление не осуществляется), 1 (перенаправление осуществляется всегда) и 2 (перенаправление осуществляется только тогда, когда активизированы два или более интерфейсов). в более ранних реализациях 4.2bsd датаграммы перенаправляются по умолчанию. при этом, если система сконфигурирована неверно, возникает очень много проблем. именно поэтому данная опция ядра должна быть всегда по умолчанию установлена в значение "без перенаправления" (never forward), пока системный администратор специально не включит перенаправление. icmp ошибка перенаправления отправляется маршрутизатором на хост, пославший ip датаграмму, когда датаграмма должна быть послана на другой маршрутизатор. подобная концепция довольно проста. мы привели три составные части этой концепции на рисунке 9.3. увидеть icmp перенаправление можно только когда хост имеет выбор, на какой маршрутизатор послать пакет. (обратитесь к примерам, которые мы приводили на рисунке 7.6.)
рисунок 9.3 пример icmp перенаправления.
перенаправления используются для того, чтобы позволить хосту с минимальным знанием о маршрутах поддерживать и обновлять свою таблицу маршрутизации. как правило, формирование таблицы маршрутизации хоста начинается с создания маршрута по умолчанию (r1 или r2 из нашего примера на рисунке 9.3), при этом с использованием перенаправления хост может обновить свою таблицу маршрутизации. icmp перенаправление позволяет tcp/ip хостам полностью полагаться на интеллектуальность маршрутизаторов в вопросе выбора маршрутов. маршрутизаторы r1 и r2 в нашем примере должны точно представлять топологию подключенных сетей, тогда как хосты, подключенные к локальной сети, могут начинать свою маршрутизацию с маршрута по умолчанию, узнавая затем более подробно о новых маршрутах из принятых перенаправлений. пример посмотрим icmp перенаправления в действии на примере нашей сети (на внутренней стороне обложки). мы показали всего три хоста (aix, solaris и gemini) и два маршрутизатора (gateway и netb) в верхней части сети, в действительности там более 150 хостов и 10 маршрутизаторов. большинство хостов считают gateway маршрутизатором по умолчанию, так как он предоставляет доступ к internet. как можно получить доступ из подсети 140.252.1 к нижней подсети (4 нижние хоста на рисунке)? во-первых, вспомним, что если на конце slip канала находится единственный хост, используется уполномоченный агент arp (глава 4, раздел "уполномоченный агент arp"). это означает, что для хостов в верхней сети 140.252.1 не требуется специальных средств, для того чтобы получить доступ к хосту sun (140.252.1.29). доступ обеспечит программное обеспечение уполномоченного агента arp на netb. однако, если на удаленном конце slip канала присутствует сеть, то необходима маршрутизация. одно из возможных решений заключается в том, чтобы каждый хост и маршрутизатор знали о том, что маршрутизатор netb является шлюзом в сеть 140.252.13. этого можно добиться путем внесения статического маршрута в каждую таблицу маршрутизации на каждом хосте или запустив на каждом хосте маршрутизирующий демон. однако существует более простой способ (метод, который обычно используется) - использовать icmp перенаправление. запустим программу ping с хоста solaris в верхней сети на хост bsdi (140.252.13.35) в нижней сети. так как идентификаторы подсети различны, уполномоченный агент arp не может быть использован. предположим, что статический маршрут не установлен, поэтому при посылке первого пакета будет использован маршрут по умолчанию на маршрутизатор gateway. ниже мы приводим таблицу маршрутизации, перед тем как запустили ping:
solaris % netstat -rn
(пункт 224.0.0.0 используется для групповой адресации ip. мы опишем это в главе 12.) если указать опцию -v в командной строке ping, то будут видны все icmp сообщения принятые хостом. нам необходимо указать эту опцию, чтобы увидеть сообщения о перенаправлении, которые будут посланы.
solaris % ping -sv bsdi
перед тем как мы получим первый ответ на ping, хост примет icmp перенаправление от маршрутизатора по умолчанию gateway. если мы затем посмотрим таблицу маршрутизации, то увидим, что появился новый маршрут к хосту bsdi. (этот пункт выделен жирным шрифтом.)
solaris % netstat -rn
pltcmm мы впервые видиv флаг d, который означает, что маршрут был установлен с использованием icmp перенаправления. флаг g обозначает, что это непрямой маршрут к шлюзу (netb), а флаг h обозначает, что это маршрут к хосту (как мы и ожидали), а не маршрут к сети. так как это маршрут к хосту, добавленный путем перенаправления, он обслуживает только хост bsdi. если затем мы попробуем получить доступ к хосту svr4, будет сгенерировано еще одно перенаправление, и будет создан еще один маршрут к хосту. точно так же, попытка получить доступ к хосту slip создаст еще один маршрут. каждое перенаправление на конкретный хост приводит к созданию нового маршрута к хосту. все три хоста в подсети (bsdi, svr4 и slip) будут обслуживаться одним маршрутом к сети, указывающим на маршрутизатор sun. однако, icmp перенаправления создают маршруты к хостам, а не маршруты к сетям, так как маршрутизатор, генерирующий перенаправление в данном примере (gateway), не имеет представления о структуре подсетей в сети 140.252.13. более подробно на рисунке 9.4 показан формат сообщения icmp о перенаправлении.
рисунок 9.4 icmp сообщение о перенаправлении.
существуют четыре различных типа сообщений о перенаправлении, с различными значениями кода (code), как показано на рисунке 9.5.
рисунок 9.5 различные значения code для icmp перенаправления.
существуют три ip адреса, которые должен знать получатель icmp перенаправления: (1) ip адрес, который вызвал перенаправление (находится в ip заголовке, возвращенном как данные в icmp сообщении о перенаправлении), (2) ip адрес маршрутизатора, который послал перенаправление (является ip адресом источника ip датаграммы, содержащей перенаправление) и (3) ip адрес маршрутизатора, который должен быть использован (находится в байтах с 4-го по 7-ой в icmp сообщении). существует несколько правил, посвященных icmp перенаправлениям. во-первых, перенаправления генерируются только маршрутизаторами, ни в коем случае не хостами. однако, перенаправления могут быть использованы только хостами, не маршрутизаторами. считается, что маршрутизаторы используют протоколы маршрутизации и обмениваются таблицами с другими маршрутизаторами, поэтому они не нуждаются в перенаправлениях. (это означает, что на рисунке 9.1 таблица маршрутизации должна быть обновлена либо с использованием маршрутизирующего демона, либо с использованием перенаправления, однако не с использованием и того и другого.) когда 4.4bsd функционирует как маршрутизатор, осуществляются следующие проверки, причем каждая из них должна быть истиной, для того чтобы было сгенерировано icmp перенаправление.
переменная ядра с именем ip_sendredirects (или похожим). (см. приложение е.) большинство современных систем (4.4bsd, sunos 4.1.x, solaris 2.x и aix 3.2.2, например) включают эту переменную по умолчанию. другие системы, например, svr4, имеют эту переменную по умолчанию выключенной.
в дополнение, хост 4.4bsd, который принимает icmp перенаправления, осуществляет некоторые проверки перед модификацией своей таблицы маршрутизации. это предотвращает странное поведение маршрутизатора или хоста, вызванное некорректной модификацией таблицы маршрутизации системы.
и в заключение стоит повториться, что маршрутизаторы должны посылать только перенаправления к хостам (codes 1 или 3 на рисунке 9.5), а не перенаправления к сетям. из-за разделения на подсети не всегда можно однозначно указать, когда должно быть послано перенаправление к сети вместо перенаправления к хосту. некоторые хосты воспринимают принятое перенаправление к сети как перенаправление к хосту, в том случае если маршрутизатор послал неверный тип (type). icmp сообщения поиска маршрутизатора (icmp router discovery messages) ранее в этой главе мы говорили, что одним из способов инициализации таблицы маршрутизации является создание статических маршрутов, которые заносятся в конфигурационные файлы. подобный метод часто используется для установки маршрута по умолчанию. существует способ, заключающийся в использовании icmp объявлений маршрутизаторов. основной принцип заключается в том, что после загрузки хост рассылает широковещательные или групповые запросы с требованием сообщить ему о маршрутизаторе. один или несколько маршрутизаторов отвечают с использованием сообщения об объявлении маршрутизатора. в дополнение, маршрутизаторы периодически рассылают широковещательные или групповые сообщения с объявлением маршрутизатора, позволяя каждому хосту, который примет эти сообщения, обновить свои таблицы маршрутизации. rfc 1256 [deering 1991] содержит формат этих icmp сообщений. на рисунке 9.6 показан формат icmp сообщения запроса маршрутизатора. на рисунке 9.7 показан формат icmp сообщения объявления маршрутизатора, которое рассылается маршрутизаторами. в одном сообщении маршрутизатор может объявить несколько адресов. поле количества адресов. размер записи адреса - количество 32-битных слов для каждого адреса маршрутизатора, оно всегда установлено в 2. время жизни - количество секунд, в течение которого данное объявление адресов считается действительным.
рисунок 9.6 формат icmp сообщения запроса маршрутизатора.
рисунок 9.7 формат icmp сообщения объявления маршрутизатора.
затем следует одна или несколько пар ip адресов. ip адрес должен быть одним из адресов посылающего маршрутизатора. уровень предпочтительности - это 32-битное целое число со знаком, указывающее на предпочтительность этого адреса в качестве адреса маршрутизатора по умолчанию, по сравнению с другими адресами маршрутизаторов в той же подсети. большее значение указывает на большую предпочтительность адреса. уровень предпочтительности 0x80000000 указывает на то, что соответствующий адрес, несмотря на то что он объявлен, не должен быть использован получателем в качестве адреса маршрутизатора по умолчанию. обычное значение предпочтительности это 0. функционирование маршрутизатора когда маршрутизатор стартует, он начинает периодически рассылать объявления на все интерфейсы, которые поддерживают групповой и широковещательный тип адресации. в действительности эти объявления не периодические, они рассылаются случайным образом. это сделано для того, чтобы объявления не перемешивались и не синхронизировались с другими маршрутизаторами в той же подсети. обычный интервал между объявлениями составляет от 450 до 600 секунд. время жизни по умолчанию для каждого объявления составляет 30 минут. поле времени жизни также используется, когда интерфейс маршрутизатора выключается. в этом случае маршрутизатор может передать последнее объявление с временем жизни, установленным в 0. помимо периодических объявлений, маршрутизатор отвечает на запросы от хостов. он отвечает на запросы объявлением маршрутизатора. если в одной подсети существует несколько маршрутизаторов, задача системного администратора сконфигурировать уровень предпочтительности для каждого маршрутизатора. например, основной маршрутизатор по умолчанию должен иметь более высокий уровень предпочтительности по отношению к запасному маршрутизатору. функционирование хоста при старте хост обычно посылает три запроса о поиске маршрутизатора с интервалом в 3 секунды. после того как принято объявление от маршрутизатора, запросы прекращаются. хост также слушает объявления от маршрутизатора. эти объявления могут привести к смене маршрутизатора по умолчанию для данного хоста. если объявление не получено для текущего маршрута по умолчанию, он может быть удален по тайм-ауту. пока текущий маршрутизатор по умолчанию функционирует, он отправляет объявления каждые 10 минут с временем жизни в 30 минут. это означает, что маршрут по умолчанию в таблице маршрутизации хоста не будет удален по тайм-ауту, даже если одно или два объявления будут потеряны. реализация сообщения о поиске маршрутизатора обычно генерируются и обрабатываются пользовательскими процессами (демонами). поэтому добавляется еще один программный способ обновления таблицы маршрутизации к тем, что показаны на рисунке 9.1, несмотря на то, что он может добавить или удалить только пункт по умолчанию. демон должен быть сконфигурирован так, чтобы выступать либо в роли маршрутизатора, либо в роли хоста. эти два icmp сообщения достаточно новы и поддерживаются не всеми системами. в нашей сети их поддерживает только solaris 2.x (демон in.rdisc). несмотря на то, что rfc рекомендует использовать групповую адресацию ip, где это возможно, поиск маршрутизаторов может осуществляться с использованием широковещательных сообщений. краткие выводы ip маршрутизация это краеугольный камень, на котором держится функционирование систем, использующих tcp/ip, будь то хост или маршрутизатор. записи в таблице маршрутизации довольно просты: до 5 флаговых битов, ip адрес назначения (хост, сеть или по умолчанию), ip адрес маршрутизатора следующей пересылки (для непрямого маршрута) или ip адрес локального интерфейса (для прямого маршрута) и указатель на используемый локальный интерфейс. записи, соответствующие хостам, имеют более высокий приоритет, чем записи, соответствующие сетям, а оба типа записей имеют более высокий приоритет по сравнению с маршрутом по умолчанию. просмотр таблицы маршрутизации осуществляется для каждой ip датаграммы, которую система генерирует или пропускает через себя. таблица маршрутизации может быть обновлена с помощью демона маршрутизации или icmp перенаправления. по умолчанию система никогда не пропустит через себя датаграмму, если система не сконфигурирована как маршрутизатор. статические маршруты могут быть добавлены с помощью команды route, а icmp сообщения поиска маршрутизатора могут быть использованы для инициализации и динамического обновления маршрутов по умолчанию. хост может запуститься с очень простой таблицей маршрутизации, которая динамически обновляется с помощью icmp перенаправлений, приходящих с маршрутизатора по умолчанию. эта глава была посвящена тому, как отдельная система использует свою таблицу маршрутизации. в следующей главе мы рассмотрим, как маршрутизаторы обмениваются друг с другом маршрутной информацией. упражнения
|
