|
глава 10 динамические протоколы маршрутизации все о чем мы говорили в предыдущей главе, имело отношение к статической маршрутизации. записи в таблице маршрутизации создавались при конфигурации интерфейса (для интерфейсов подключенных напрямую), добавлялись командой route (обычно из системных загрузочных файлов) или создавались с помощью icmp перенаправления (при использовании неверных маршрутов). все это просто замечательно, если сеть маленькая. а именно, если существует только одна точка подключенияния к другим сетям и не существует запасных маршрутов (запасные маршруты могут быть использованы в случае выхода из строя основных). если хотя бы одно из трех приведенных выше условий неверно, используется динамическая маршрутизация. в этой главе рассматриваются протоколы динамической маршрутизации, которыми пользуются маршрутизаторы для общения друг с другом. мы подробно рассмотрим rip, протокол обмена информацией о маршрутизации (routing information protocol), широко используемый протокол, который присутствует практически во всех версиях tcp/ip. затем мы рассмотрим еще два протокола маршрутизации, ospf и bgp. в конце главы мы познакомимся с новой техникой маршрутизации, которая называтеся безклассовой маршрутизацией между доменами, и которая начинает применяться в internet для экономии адресов класса b. динамическая маршрутизация используется для общения маршрутизаторов друг с другом. маршрутизаторы передают друг другу информацию о том, какие сети в настоящее время подключены к каждому из них. маршрутизаторы общаются, используя протоколы маршрутизации. пользовательский процесс, посредством которого маршрутизаторы могут общаться с соседними маршрутизаторами, называется демоном маршрутизации (routing daemon). как видно из рисунка 9.1, демон маршрутизации обновляет таблицу маршрутизации в ядре в соответствии с информацией, которую он получает от соседних маршрутизаторов. динамическая маршрутизация не меняет способы, с помощью которых ядро осуществляет маршрутизацию на ip уровне, как описано в разделе "принципы маршрутизации" главы 9. мы назвали это механизмом маршрутизации (routing mechanism). ядро точно так же просматривает свою таблицу маршрутизации, отыскивая маршруты к хостам, маршруты к сетям и маршруты по умолчанию. меняется только способ помещения информации в таблицу маршрутизации - вместо запуска команды route или использования загрузочных файлов маршруты добавляются и удаляются динамически демоном маршрутизации, который работает постоянно. как было отмечено ранее, демон маршрутизации отвечает за политику маршрутизации (routing policy) , выбирая, какие маршруты необходимо поместить в таблицу маршрутизации. если демон обнаружил несколько маршрутов к пункту назначения, он выбирает (каким-либо образом), какой маршрут лучше, и именно этот маршрут (единственный) добавляет в таблицу маршрутизации. если демон определил, что канал изчез (возможно по причине выхода из строя маршрутизатора или телефонной линии), он может удалить соответствующие маршруты или добавить альтернативные маршруты, чтобы обойти возникшую неисправность. в internet, на сегодняшний день, используется множество различных протоколов маршрутизации. internet организован как сообщество автономных систем (as - autonomous systems), каждая из которых обычно администрируется независимо от остальных. например, сеть, построенная в университетском городке, обычно считается автономной системой. магистраль (backbone) nsfnet с точки зрения internet это автономная система, потому что все маршрутизаторы на магистрали находятся под единым административным контролем. для каждой автономной системы выбирается собственный протокол маршрутизации, с помощью которого осуществляется взаимодействие между маршрутизаторами в этой автономной системе. такой протокол называется протоколом внутренних маршрутизаторов (igp - interior gateway protocol) или протоколом внутридоменной маршрутизации (intradomain routing protocol). наиболее популярный igp - это протокол обмена информацией о маршрутизации (rip - routing information protocol). более новый igp это протокол open shortest path first (ospf). он был разработан как замена для rip. устаревший igp, который в настоящее время не используется, hello - это igp, который первоначально использовался на магистрали nsfnet вплоть до 1986 года. новые требования к маршрутизаторам router requirements rfc [almquist 1993] определяют, что маршрутизатор, который реализует любые динамические протоколы маршрутизации, должен поддерживать ospf и rip, а также может поддерживать другие igp.
существуют протоколы маршрутизации, которые называются протоколами внешних маршрутизаторов (egp - exterior gateway protocols) или протоколами междоменной маршрутизации (interdomain routing protocols). они предназначены для общения между маршрутизаторами, находящихимися в разных автономных системах. исторически (и к большому сожалению) предшественником всех egp был протокол с тем же самым именем: egp. более новый egp - протокол пограничных маршрутизаторов (bgp - border gateway protocol) в настоящее время используется между магистралью nsfnet и некоторыми региональными сетями, которые подключены к магистрали. планируется, что bgp заменит собой egp. в unix системах обычно запускается демон маршрутизации, называемый routed. он присутствует практически в каждой версии tcp/ip. этот демон понимает только протокол rip. (мы опишем routed в следующем разделе.) routed предназначен для сетей малого или среднего размеров. альтернативная программа - gated. этот демон поддерживает как igp, так и egp. [fedor 1988] описывает раннюю реализацию gated. на рисунке 10.1 приведены протоколы маршрутизации, поддерживаемые демоном routed и двуми версиями демона gated. большинство систем, которые используют демоны маршрутизации, запускают routed, однако если возникает необходимость поддерживать разные протоколы маршрутизации, используется gated.
рисунок 10.1 протоколы маршрутизации, поддерживаемые routed и gated.
мы опишем rip version 1 в следующем разделе, а отличия rip version 2, ospf и bgp соответственно в разделах "rip version 2", "ospf: открыть первым наикратчайший маршрут" и "bgp: протокол граничных маршрутизаторов" этой главы. rip: протокол обмена информацией о маршрутизации в этом разделе приводится обзор rip, так как это наиболее широко используемый протокол маршрутизации. официальная спецификация протокола rip находится в rfc 1058 [hedrick 1988a], однако этот rfc был написан через несколько лет после того, как протокол получил широкое распространение. rip сообщения передаются в udp датаграммах, как показано на рисунке 10.2. (мы рассмотрим udp в главе 11.)
рисунок 10.2 инкапсуляция rip сообщения в udp датаграмму.
на рисунке 10.3 показан формат rip сообщения, вместе с ip адресами. если поле команда равно 1 - это запрос, если 2 - отклик. существуют еще две значения поля команды (3 и 4), а также два недокументированных значения: опрос (5) и пункт опроса (6). в запросе находится требование к другой системе послать всю или часть ее таблицы маршрутизации. в отклике содержится вся или часть таблицы маршрутизации отправителя. поле версия обычно установлено в 1, однако для rip version 2 (раздел "rip version 2") это значение устанавливается в 2. следующие 20 байт сдержат: семейство адресов (которое всегда равно 2 для ip адресов), ip адрес и соответствующий показатель. в следующих разделах мы увидим, что в роли показателя rip выступает счетчик пересылок. в rip сообщении может быть объявлено до 25 маршрутизаторов. ограничение в 25 определяется полным размером rip сообщения, 20х25+4=504, меньше чем 512 байт. из-за ограничения в 25 маршрутизаторов, на один запрос, как правило, требуется послать несколько откликов, чтобы передать всю таблицу маршрутизации.
рисунок 10.3 формат rip сообщения. обычное функционирование давайте посмотрим, как обычно работает routed с использованием rip. номер зарезервированного порта для rip - udp порт 520.
с каждым маршрутом связан тайм-аут. если система, использующая rip, определила, что маршрут не был обновлен в течение трех минут, показатель маршрута устанавливается в состояние "бесконечно" (16) и помечается для удаления. это означает, что было пропущено шесть 30-секундных обновлений от маршрутизатора, который объявил маршрут. однако, удаление маршрута из локальной таблицы маршрутизации откладывается еще на 60 секунд, чтобы убедиться что маршрут действительно исчез. в качестве показателя в rip используются счетчик пересылок. для всех непосредственно подключенных интерфейсов счетчик пересылок равен 1. рассмотрим маршрутизаторы и сети, показанные на рисунке 10.4. четыре пунктирные линии показывают широковещательные сообщения rip.
рисунок 10.4 пример маршрутизаторов и сетей.
маршрутизатор r1 объявляет маршрут к n2 со счетчиком пересылок равным 1, послав широковещательное сообщение на n1. (бессмысленно объявлять маршрут к n1 в широковещательном сообщении, посланном на n1.) он также объявляет маршрут к n1 со счетчиком пересылок равным 1, послав широковещательное сообщение на n2. точно так же, r2 объявляет маршрут к n2 с показателем 1 и маршрут к n3 с показателем 1. если смежный с нами маршрутизатор объявил маршрут к удаленной сети со счетчиком пересылок равным 1, то для нас показатель к этой сети будет равен 2, так пакет необходимо послать сначала на наш маршрутизатор, чтобы получить доступ к сети. в примере, приведенном выше, показатель к n1 для r2 равен 2, так же как и показатель к n3 для r1. так как каждый маршрутизатор посылает свои таблицы маршрутизации соседям, определяется каждая сеть в каждой автономной системе (as). если внутри as существует несколько путей от маршрутизатора к сети, маршрутизатор выбирает путь с наименьшим количеством пересылок и игнорирует другие пути. величина счетчика пересылок ограничена значением 15, что означает, что rip может быть использован только внутри as, где максимальное количество пересылок между хостами составляет 15. специальное значение показателя, равное 16, указывает на то, что на данный ip адрес не существует маршрута. как бы просто это ни звучало, все равно существуют проблемы. во-первых, rip не имеет представления о делении на подсети. если обычный 16-битный идентификатор хоста в адресе класса в ненулевой, rip не может определить, принадлежит ли ненулевая часть идентификатору подсети или ip адрес - это целиком адрес хоста. некоторые реализации используют маску подсети того интерфейса, через который пришла rip информация, однако такой способ не всегда корректен. во-вторых, для rip требуется очень много времени, чтобы восстановить функционирование сети, после того как вышел из строя маршрутизатор или канал. время обычно составляет несколько минут. в это время могут возникнуть петли маршрутизации. в современных реализациях rip существует множество рекомендаций, которые позволяют избавляться от петель маршрутизации и увеличить скорость сходимости сетей. в rfc 1058 [hedrick 1988a] подробно описано, как должен быть реализован rip. использование количества пересылок в качестве показателя маршрутизации не позволяет использовать другие переменные, которые также должны приниматься во внимание при выборе маршрута. и в заключение, максимальное значение - 15 пересылок ограничивает размер сетей, в которых может быть использован rip. мы воспользуемся программой ripquery, чтобы получить таблицы маршрутизации некоторых маршрутизаторов. ripquery отправляет один из недокументированных запросов (названный "опрос" (poll), при этом поле команда установливается в 5, рисунок 10.3) на маршрутизатор, требуя от него послать полную таблицу маршрутизации. если ответ не получен в течении 5 секунд, посылается стандартный rip запрос (поле команда установлено в 1). (ранее мы говорили, что запрос с полем семейства протоколов установленным в 0 и с показателем установленным в 16 запрашивает полную таблицу маршрутизации маршрутизатора.) на рисунке 10.5 показаны два маршрутизатора, у которых мы потребуем их таблицы маршрутизации на хосте sun. мы запустим ripquery с sun, и получим информацию о маршрутизации с маршрутизатора следующей пересылки, netb:
sun % ripquery -n netb
как мы и ожидали, netb объявляет нашу подсеть с показателем 1. верхний ethernet, к которому также подключен netb (140.252.1.0), имеет показатель равный 1. (флаг -n говорит о необходимости выводить ip адреса в цифровом представлении, вместо того чтобы печатать имена хостов.) в этом примере netb сконфигурирован таким образом, чтобы считать все хосты, находящиеся в подсети 140.252.13, подключенными к нему напрямую - таким образом, netb ничего не знает о тех хостах, которые действительно находятся в подсети 140.252.13. так как существует только одна точка подключения к подсети 140.252.13, объявление различных показателей для каждого хоста не имеет практического смысла.
рисунок 10.5 два маршрутизатора netb и gateway, на которые мы послали запрос об их таблицах маршрутизации.
на рисунке 10.6 показан обмен пакетами, который получен с помощью команды tcpdump. мы указали slip интерфейс с опцией -i sl0.
sun % tcpdump -s600 -i sl0
рисунок 10.6 вывод команды tcpdump при запуске программы ripquery.
первый отправляемый запрос - это команда опроса rip (poll) (строка 1). в этом месте отрабатывается тайм-аут в 5 секунд, после чего отправляется обычный rip запрос (строка 2). число 24 в конце строк 1 и 2 это размер пакетов запроса в байтах: 4 байта rip заголовок (с командой и версией), после чего следует один 20-байтовый адрес и показатель. в строке 3 показан первый отклик, причем число 25 в конце строки указывает, что в сообщении находится 25 пар адресов и показателей, что, как мы рассчитали ранее, составляют 504 байта. именно эту информацию выдает ripquery. мы указали опцию -s600 для tcpdump, сообщая о необходимости прочитать из сети 600 байт. это позволяет принять udp датаграмму целиком (вместо того чтобы принять только ее первую часть) и затем напечатать содержимое rip ответа. в строке 4 показано второе ответное сообщение от маршрутизатора, со следующими 12-ю парами адресов и показателей. мы можем рассчитать размер этого сообщения, который будет составлять 12х20+4=244, что как раз и печатала ripquery ранее. если мы обратимся к маршрутизатору, который находится позади netb, к gateway, то скорее всего получим, что показатель до нашей подсети 140.252.13.0 будет равен 2. давайте проверим это предположение:
sun % ripquery -n gateway
здесь показатель для верхнего ethernet на рисунке 10.5 (140.252.1.0) остался равным 1, так как этот ethernet непосредственно подключен и к gateway, и к netb, однако наша подсеть 140.252.13.0, как мы и ожидали, имеет показатель равный 2. еще один пример сейчас мы рассмотрим все обновления rip, которые происходят в сети ethernet без получения запросов, и посмотрим, что rip регулярно отправляет своим соседям. на рисунке 10.7 показаны сети в noao.edu. для простоты маршрутизаторы названы как rn, где n - номер подсети. каналы точка-точка показаны с помощью пунктирных линий с указанием ip адресов для каждого конца канала.
рисунок 10.7 сети noao.edu 140.252.
мы запустили на solaris 2.x программу snoop, напоминающую программу tcpdump, которую мы запускали на компьютере solaris. эту программу можно запустить без привилегии суперпользователя, однако только для того, чтобы перехватывать широковещательные пакеты, групповые пакеты или пакеты, посылаемые на хост. на рисунке 10.8 показаны пакеты, пойманные за 60 секунд. мы заменили большинство официальных имен хостов на наше представление в форме rn.
solaris % snoop -p -tr udp port 520
рисунок 10.8 rip широковещательные сообщения, пойманные на solaris за 60 секунд.
благодаря флагу -p пакеты ловятся не перемешиваясь, благодаря -tr печатаются соответствующие временные марки, а благодаря port 520 захватываются только udp датаграммы у которых в качестве порта источника или порта назначения указан порт 520. первые 6 пакетов приходят от r6, r4, r2, r7, r8 и r3, в каждом объявляется только одна сеть. если мы заглянем внутрь пакетов, то увидим, что r6 объявляет маршрут к сети 140.252.6.0 со счетчиком пересылок равным 1, r4 объявляет маршрут к 140.252.4.0 со счетчиком пересылок равным 1, и так далее. маршрутизатор gateway, однако, объявил 15 маршрутизаторов. мы можем запустить snoop с флагом -v и посмотреть содержимое rip сообщения. (этот флаг выдает полное содержимое входящего пакета: ethernet заголовок, ip заголовок, udp заголовок и rip сообщение. мы удалили всю информацию за исключением информации rip.) на рисунке 10.9 показан вывод. сравните объявленные счетчики пересылок для сети 140.252.1 с топологией, приведенной на рисунке 10.7. очень странный факт заключается в том, что в выводе на рисунке 10.8 r10 объявляет четыре сети, тогда как на рисунке 10.7 показано только три. если мы заглянем в rip пакет с помощью snoop, то мы увидим следующие объявленные маршруты:
rip: address metric
маршрут к сети класса в 140.251 фиктивный и не должен объявляться. он не принадлежит к noao.edu.
solaris % snoop -p -v -tr udp port 520 host gateway
рисунок 10.9 rip ответ от gateway.
выражение "broadcast" в выводе snoop на рисунке 10.8 для rip пакета, посланного r10, означает, что ip адрес назначения это ограниченный широковещательный адрес 255.255.255.255 (глава 12, раздел "широковещательные запросы"), а не широковещательный адрес, указывающий на подсеть (140.252.1.255), который используют другие маршрутизаторы. rfc 1388 [malkin 1993a] определяет новые расширения rip, которые в целом обычно называются rip-2. эти расширения не изменяют протокол, однако добавляют дополнительную информацию в поля, помеченные как "должны быть равны нулю" (must be zero) на рисунке 10.3. rip и rip-2 могут взаимодействовать в том случае, если rip игнорирует поля, которые должны быть установлены в ноль. на рисунке 10.10 показан формат сообщения rip-2. для rip-2 поле версии устанавливается в 2. домен маршрутизации - это идентификатор маршрутизирующего демона, которому принадлежит этот пакет. в реализациях unix это должен быть идентификатор процесса демона. это поле позволяет администратору запустить rip на одном и том же маршрутизаторе несколько раз, причем каждый будет функционировать с одним доменом маршрутизации. поле метки маршрута предназначено для того, чтобы поддерживать протоколы внешних маршрутизаторов. здесь хранится номер автономной системы для egp и bgp. маска подсети для каждого пункта соответствует своему ip адресу. ip адрес следующей пересылки - это ip адрес пункта назначения, куда должны посылаться пакеты. значение 0 в этом поле означает, что пакеты должны отправляться в систему, которая послала rip сообщение.
рисунок 10.10 формат сообщения rip2.
в rip-2 предоставляется простая схема аутентификации. первые 20 байт в rip сообщении содержащие семейство адресов, которое установлено в 0xffff, а поле route tag, установлено в значение 2. оставшиеся 16 байт содержат пароль в открытом виде. и в заключение, rip-2 поддерживает групповые запросы в дополнение к широковещательным (глава 12). при этом уменьшается загрузка хостов, которые не принимают rip-2 сообщения. ospf: "открыть первым наикратчайший маршрут" (open shortest path first) ospf это альтернативный rip протокол внутренних маршрутизаторов. в ospf сняты все ограничения, присущие для rip. ospf version 2 описывается в rfc 1247 [moy 1991]. ospf - протокол состояния канала (link-state) , тогда как rip - протокол вектора расстояний (distance-vector) . термин вектор расстояний означает, что сообщения, посылаемые rip, содержат вектор расстояний (счетчик пересылок). каждый маршрутизатор обновляет свою таблицу маршрутизации на основании векторов расстояний, который он получает от своих соседей. когда используется протокол состояния канала, маршрутизатор не обменивается информацией о расстояниях со своими соседями. вместо этого каждый маршрутизатор активно тестирует статус своих каналов к каждому соседнему маршрутизатору и посылает эту информацию другим своим соседям, которые могут направить поток данных в автономную систему. каждый маршрутизатор принимает информацию о состоянии канала и уже на ее основании строит полную таблицу маршрутизации. с практической точки зрения основное отличие заключается в том, что протокол состояния канала работает значительно быстрее, чем протокол вектора расстояний. нужно отметить, что в случае протокола состояния канала значительно быстрее осуществляется сходимость сети. под понятием сходимости (converge) мы подразумеваем стабилизацию сети после каких-либо изменений, как, например, поломки маршрутизатора или выхода из строя канала. в разделе 9.3 [perlman 1992] сравниваются между собой два типа протоколов маршрутизации. ospf также отличается от rip (как и многие другие протоколы маршрутизации) тем, что ospf использует непосредственно ip. это означает, что он не использует udp или tcp. ospf имеет собственную величину, которая устанавливается в поле протокола (protocol) в ip заголовке (рисунок 3.1). к тому же, так как ospf это протокол состояния канала, а не протокол вектора расстояний, он имеет и другие характеристики, которые делают его предпочтительным по отношению к rip.
так как большинство поставщиков маршрутизаторов поддерживают ospf, он начинает постепенно замещать собой rip в большинстве сетей. bgp: протокол граничных маршрутизаторов (border gateway protocol) bgp это протокол внешних маршрутизаторов, предназначенный для связи между маршрутизаторами в различных автономных системах. bgp заменяет собой старый egp, который использовался в arpanet. bgp version 3 определен в rfc 1267 [lougheed and rekhter 1991]. rfc 1268 [rekhter and gross 1991] описывает использование bgp в internet. практически все, что приведенного ниже, взято именно из этих двух rfc. в дополнение, необходимо отметить, что в 1993 году bgp version 4 разрабатывался таким образом (rfc 1467 [topolcic 1993]), чтобы поддерживать cidr, который мы опишем в разделе "cidr: бесклассовая маршрутизация между доменами" этой главы. системы, поддерживающие bgp, обмениваются информацией о доступности сети с другими bgp системами. эта информация включает в себя полный путь по автономным системам, по которым должен пройти траффик (поток данных), чтобы достичь этих сетей. эта информация адекватна построению графа соединений as (автономных систем). при этом возникает возможность легко обходить петли маршрутизации, а также упрощается процесс принятия решений о маршрутизации. во-первых, необходимо сказать, что ip датаграмма в as может принадлежать как к локальному траффику, так и к транзитному траффику. локальный - это траффик у которого источник и пункт назначения находятся в одной as. при этом ip адреса источника и назначения указывает на хосты, принадлежащие одной автономной системе. весь остальной траффик называется транзитным. основное преимущество использования bgp в internet заключается в уменьшении транзитного траффика. автономная система может принадлежать к следующим категориям:
общая топология internet состоит из транзитных, многоинтерфейсных и ограниченных автономных систем. ограниченные и многоинтерфейсные автономные системы не нуждаются в использовании bgp - они могут использовать egp, чтобы обмениваться информацией о доступности с транзитными автономными системами. bgp позволяет использовать маршрутизацию, основанную на политических решениях (policy-based routing). все правила определяются администратором автономной системы и указываются в конфигурационных файлах bgp. "политические решения" не являются частью протокола, однако позволяют делать выбор между маршрутами, когда существует несколько альтернативных, и позволяют управлять перераспределением информации. решения принимаются в соответствии с вопросами безопасности или экономической целесообразности. bgp отличается от rip или ospf тем, что bgp использует tcp в качестве транспортного протокола. две системы, использующие bgp, устанавливают tcp соединения между собой и затем обмениваются полными таблицами маршрутизации bgp. обновления представляются в виде изменений таблицы маршрутизации (таблица не передается целиком). bgp это протокол вектора расстояний, однако, в отличие от rip (который объявляет пересылки к пункту назначения), bgp перечисляет маршруты к каждому пункту назначения (последовательность номеров автономных систем к пункту назначения). при этом исчезают некоторые проблемы, связанные с использованием протоколов вектора расстояний. каждая автономная система идентифицируется 16-битным номером. bgp определяет выход из строя канала или хоста на другом конце tcp соединения путем регулярной отправки сообщения "оставайся в живых" (keepalive) своим соседям. рекомендуемое время между этими сообщениями составляет 30 секунд. сообщение "оставайся в живых", которое используется на уровне приложений, независимо от tcp опций "оставайся в живых" (глава 23). cidr: бесклассовая маршрутизация между доменами (classless interdomain routing) в главе 3 было сказано, что в настоящее время ощущается нехватка адресов класса в, поэтому узлам с несколькими сетями приходится присваивать несколько идентификаторов сетей класса с вместо одного идентификатора сети класса в. с одной стороны, появление адресов класса с решает одну проблему (переполнение количества адресов класса в). с другой стороны, появляется еще одна проблема: каждая сеть класса с требует записи в таблице маршрутизации. бесклассовая маршрутизация между доменами (cidr - classless interdomain routing) это способ, который позволяет свести к минимуму рост таблиц маршрутизации в internet. этот способ также называется supernetting и описывается в rfc 1518 [rekhter and li 1993] и в rfc 1519 [fuller et al. 1993], обзор можно найти в [ford, rekhter and braun 1993]. cidr одобрен internet architecture board [huitema 1993]. rfc 1467 [topolcic 1993] кратко описывает состояние и развитие cidr в internet. основная концепция, заложенная в cidr, заключается в том, что несколько ip адресов можно расположить определенным образом, что позволит уменьшить количество записей в таблице маршрутизации. например, если один узел состоит из 16 адресов класса с, все 16 могут быть расположены таким образом, что они будут суммироваться, поэтому ко всем 16-ти можно будет обратиться через одну запись в таблице маршрутизации. также, если 8 различных узлов подключены к одному и тому же internetовскому "поставщику сервиса" через одну и ту же точку подключения к internet, и если все 8 узлов имеют 8 различных ip адресов, они могут быть суммированы, после чего потребуется только одна запись в таблице маршрутизации, которая будет использоваться в internet для всех 8 узлов. для того чтобы использовать подобное суммирование, необходимо, чтобы выполнялось три условия.
в качестве примера скажем, что rfc 1466 [gerich 1993] рекомендует, чтобы новые адреса класса с в европе находились в диапазоне 194.0.0.0 - 195.255.255.255. в шестнадцатиричном представлении эти адреса лежат в диапазоне 0xc2000000 - 0xc3ffffff. это позволяет использовать 65536 различных идентификаторов сети класса с, однако все они имеют одинаковые 7 бит старшего порядка. в других (неевропейских) странах может быть использована единственная запись в таблице маршрутизации с ip адресом 0xc2000000 и 32-битной маской 0xfe000000 (254.0.0.0), чтобы организовать маршрут ко всем этим идентификаторам сетей класса с (в количестве 65536) через одну точку. последовательность битов в адресе класса с (это биты, следующие за 194 или 195) может быть расположена в иерархическом порядке, например, по странам или по поставщикам сервиса, чтобы тем самым позволить дополнительное сложение внутри европейских маршрутизаторов с использованием дополнительных битов, стоящих после 7 бит старшего порядка в 32-битной маске. cidr также использует технику, которая определяет, что "лучшее совпадение это всегда наиболее длинное совпадение (longest match)": то есть совпадение максимального количества битов в 32-битной маске. продолжая пример из предыдущего параграфа, нужно отметить следующее. предположим, что один поставщик сервиса в европе нуждается в использовании другого маршрутизатора для входа в internet, чем вся остальная европа. если этот поставщик сервиса находится в диапазоне адресов 194.0.16.0 - 194.0.31.255 (16 идентификаторов сетей класса с), записи в таблице маршрутизации для этих сетей должны иметь ip адрес 194.0.16.0 и маску 255.255.240.0 (0xfffff000). датаграмма, которая маршрутизируется на адрес 194.0.22.1, будет совпадать с этим пунктом таблицы маршрутизации и с одной из сетей класса с в остальной европе. однако, так как маска 255.255.240 "длиннее" чем маска 254.0.0.0, будет использован пункт в таблице маршрутизации, который имеет самую длинную маску. термин "бесклассовый" используется потому, что решения о маршрутизации принимаются на основе масок, накладываемых на полный 32-битный ip адрес. при этом не существует различия между адресами класса а, в или с. первоначально предполагается использовать cidr в адресах новых сетей класса с. благодаря внесению подобного изменения, значительно уменьшится рост таблиц маршрутизации в internet, при этом не потребуется вносить никаких изменений в существующие маршрутизаторы. хотя надо отметить, что подобное решение является кратковременной мерой. более значительное улучшение можно получить, если cidr будет использоваться для всех ip адресов, и существующие ip адреса будут переназначены (при этом все существующие хосты получат новые адреса!) в соответствии с ограничениями по странам, континентам и поставщикам сервисов [ford, rekhter and braun 1993]. выигрыш будет заключаться в следующем: современная таблица маршрутизации содержит до 10000 записей, тогда как после применения cidr количество записей уменьшится до 200. существуют два основных типа протоколов маршрутизации: протоколы внутренних маршрутизаторов (igp - interior gateway protocol), для маршрутизаторов, находящихся внутри автономной системы (autonomous system), и протоколы внешних маршрутизаторов (egp - exterior gateway protocol), для маршрутизаторов, которые общаются с маршрутизаторами в других автономных системах. наиболее популярный igp это routing information protocol (rip), однако постепенно новый igp - ospf становится более популярным, и все чаще и чаще начинает заменять собой rip. новый и популярный egp это border gateway protocol (bgp). в этой главе мы рассмотрели rip и типы сообщений, которые он использует. rip version 2 это современное расширение, которое поддерживает разбиение на подсети и другие важные улучшения. также мы описали ospf, bgp и бесклассовую маршрутизацию между доменами (cidr), новую технологию, которая призвана уменьшить размер таблиц маршрутизаций в internet. существует еще два osi протокола маршрутизации, на которые вам следует обратить внимание. протокол междоменной маршрутизации (idrp - interdomain routing protocol) появился как версия bgp, модифицированная для использования с osi адресами вместо ip. протокол промежуточная система - промежуточная система (is-is - intermediate system to intermediate system) это osi стандарт igp. он используется как протокол маршрутизации в сетях без соединения (clnp - connectionless network protocol), osi протокол, похожий на ip. is-is и ospf очень похожи. динамическая маршрутизация до сих пор остается плодотворной почвой для исследований в области межсетевого взаимодействия. поэтому выбрать, какой протокол маршрутизации необходимо использовать и какой демон маршрутизации необходимо запустить, довольно сложно. [perlman 1992] предоставляет множество подробностей.
| |||||||||||||||||||||||||||||
