69573

Работа с IP-адресами

Практическая работа

Информатика, кибернетика и программирование

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

Русский

2014-10-07

1.45 MB

4 чел.

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

  •  Структура таблиц маршрутизации
  •  Причины появления записей в таблице маршрутизации
  •  Логика обработки пакетов маршрутизатором, использующим технику классов
  •  Логика обработки пакетов маршрутизатором, поддерживающим маски подсети равной и переменной длины
  •  Методы базового конфигурирования маршрутизатора Windows 2000 Server
  •  Приемы базового конфигурирования маршрутизаторов Cisco Systems

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

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

Рассмотрим первую, не самую главную проблему – нехватку адресного пространства. Половина всего адресного пространства разделена всего на 126 сетей класса А, т.е. всего 126 компаний могут израсходовать половину адресного пространства, притом, что в сети класса А около 16 миллионов узлов, что является ОЧЕНЬ избыточным даже для самого, что ни на есть крупнейшего провайдера. Так как владельцы этих адресов не расходуют в полном объеме предоставленное им адресное пространство, то, следовательно, часть адресного пространства теряется, при общем дефиците адресов, связанных с недостаточностью длины IP адреса. Разбивать же эти сети на части и раздавать их разным компаниям невозможно по двум причинам:

  •  Те, кто получил идентификаторы класса А ранее, не согласятся с тем, чтобы у них отобрали их адреса.
  •  Маршрутизаторы на магистрали обрабатывают пакеты в соответствии с техникой классов и не могут понять, как ЧАСТЬ сети класса А может быть доступна через некоторый маршрут, а другая ЧАСТЬ той же сети класса А – через другой маршрут.

Что касается адресов класса В, то их размер (около 64 тысяч узлов) вполне пригоден для очень крупных провайдеров, хотя и все же велик. Но при этом адреса класса В предлагались тем, кому мало было адреса класса С, а не очень большим провайдерам, что привело, в конечном счете, к нерациональному использованию и адресов класса В. Наконец, адреса класса С выдавались всем, даже тем компаниям, коме необходимо было организовать сеть из нескольких десятков компьютеров. В итоге оказалось, что распределение адресов весьма неэффективно и приводит к излишнему расходованию и без того не богатого адресного пространства. Пока Интернет был не слишком велик (начало 90-х), дефицита адресов не ощущалось, однако в связи с ростом Интернета дальнейшее предоставление адресов классовым способом привело бы к очень быстрому исчерпанию адресного пространства.

Рассмотренная проблема была, безусловно, очень важна, но была еще более серьезная проблема, связанная с предоставлением адресов на основании техники классов. Рассмотрим эту проблему подробно.

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

Когда количество записей в таблицах маршрутизации на магистрали стало составлять несколько десятков тысяч, а адресное пространство стало стремительно истощаться, был полностью пересмотрен подход к предоставлению клиентам адресного пространства и маршрутизации на магистрали – появилась технология Бесклассовой Междоменной Маршрутизации (Classless InterDomain Routing, CIDR), которую мы и рассмотрим.

Итак, существует ли способ найти компромисс между тем, что в составной сети должно быть МНОГО сетей и тем, что в таблицах маршрутизации магистральных (да и вообще говоря, всех) маршрутизаторов должно быть МАЛО записей? Очевидно, для этого магистральные маршрутизаторы должны иметь маршруты не в сети, а в какие то более крупные образования! Вспомним, что мы говорили, когда вводили идею о третьем уровне: коммутаторы имеют записи в таблице коммутации о каждом узле, на третьем уровне необходимы записи о маршрутах к более крупным объектам – сетям. Эта идея исчерпала себя, оказалась не достаточно масштабируемой: нужны маршруты к еще более крупным объектам, нежели сети.

Примером подобного рода системы могут служить публичные телефонные сети. Рассмотрим номер телефона – адрес абонента в гигантской телефонной сети, некоторый аналог IP адреса в компьютерной сети. Возьмем номер телефона: 380487311314. В этом номере телефона 38 – код Украины, 048 – код Одессы, 731 – код АТС некоторого оператора (провайдера услуг), 1314 – номер абонента. Положим АТС в Америке необходимо маршрутизировать звонок в Украину. Нужно ли этой АТС иметь индивидуальные маршруты ко всем операторам Украины? Конечно, нет, необходимо обратить внимание на первые два знака в адресе «38», и маршрутизировать звонок не на основании полного адреса абонента в сети, а лишь на основании некоторого префикса номера – его нескольких первых знаков. После анализа этих двух цифр ясно, что звонок поступает в Украину, и его нужно маршрутизировать соответственно. Если звонок поступит в другой город Украины, мобильному оператору Украины – не важно, все звонки в Украину маршрутизируются одинаково. Мы привыкли в IP сети к тому, что маршрутизаторы имеют маршруты не к каждому узлу составной сети, а маршрутизируют пакеты по первым битам (в зависимости от класса адреса на 8, 16 или 24), здесь же все еще проще – маршрутизация в Украину осуществляется по первым двум цифрам. Разумеется, в рамках страны действует подобная схема. В чем преимущество такой схемы перед классовой маршрутизацией в IP сети? В том, что таких крупных образований как страны всего несколько сотен, а не 2 миллиона, и маршрутов в соответствующих таблицах АТС оказывается немного. В рамках же страны идет дальнейшее деление адресного пространства по городам, операторам, АТС и, наконец, вводятся номера конечных абонентов.

При этом в телефонной адресации учитывается, что количество номеров, необходимо разным странам различно, некоторые страны имеют префикс страны из одной цифры (США), следовательно, из 12-значного номера телефона 11 знаков остаются для адресации внутри страны, некоторые страны имеют префикс страны из двух цифр, тогда для использования внутри страны останется еще 10 цифр,  некоторые станы имеют префикс страны из трех цифр и т.д. Об адресации внутри страны: в Украине крупные города получают префиксы города из трех цифр, тогда это позволяет адресовать в городе до 10 миллионов абонентов (остается 12-2-3=7 знаков, 107=10 миллионов), более мелкие города получают префиксы из 4 знаков (1 миллион абонентов) или 5 знаков (до 100 тысяч абонентов).

Можно ли перенести подобную схему на IP адресацию? Рассмотрим следующий модельный пример. Предложенный пример, НЕ ЕМЕЕТ воплощения в действительности, а представляет собой лишь МОДЕЛЬ, которая поможет понять, как же должна быть в идеале устроена маршрутизация на магистрали.

Предположим, что никакого уже работающего Интернета еще нет, и нам необходимо спроектировать методику раздачи адресов из пространства IP для получения эффективной схемы маршрутизации. Поступим следующим образом: разделим все адресное пространство на условные шесть частей – Северная  Америка, Южная Америка, Азия, Африка, Европа и Австралия. Так как адресное пространство нельзя поделить на число частей отличное от натуральной степени двойки, то поделим на адресное пространство на 8 частей, еще две зарезервируем. Для деления адресного пространства на части мы можем применить маски, какой должна быть маска, чтобы разделить все адресное пространство на 8 частей? Очевидно, это маска /3  (23=8) – первые три бита адреса будут нумеровать континент/часть света, которой принадлежит данный блок адресов. Присвоим, например, адресные пространства континентам/частям света следующим образом:

Северная Америка: 001

Южная Америка: 010

Азия:   011

Африка:   100

Европа:   101

Австралия:   110

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

Возьмем европейский диапазон адресов, начинающийся с 101. В Европе менее 64 стран, значит, для нумерации страны необходимо еще 6 бит. Положим, что Украина получила адрес 011100, тогда все адреса в Украине начинались бы с 101|011100. В каждой стране можно установить «самый главный» маршрутизатор, тогда в его таблице маршрутизации будет записи о маршрутах во все страны своего континента (в Европе – до 64 маршрутов и маршрут по умолчанию на маршрутизатор континента). В самой Украине 26 областей, можно присвоить этим областям свои части адресного пространства, выдели на номер области еще 5 бит. Например, одесская область получила бы номер 00010, тогда все IP адреса в Одессе начинались бы с 101|011100|00010, где первая часть адреса – номер континента, вторая – номер страны, третья – номер области.

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

  •  провайдерам будут предоставляться блоки той длины, которые им нужны;
  •  клиентам можно предоставлять адреса не блоками по 256 узлов (как это было в случае с классами) а такими порциями, которые необходимы клиенту (конечно в виде 2N-1, где N – натуральное число), что приведет к более разумному расходованию свободных, пока еще, адресов и в конечном счете будет являться эффективным механизмом борьбы с истощением адресного пространства IP.

Тогда, можно записать полученный диапазон IP адресов, предоставленный провайдерам Одесской области в сети с маршрутизацией по географическому признаку в точечно-десятичной записи: 174.8.0.0/14.  В этом диапазоне 18 бит отведено на предоставление провайдерам данного региона, что позволяет адресовать 256 тысяч узлов.

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

На что похоже подобное, жестко структурированное по географическому признаку, деление адресного пространства? Конечно на все ту же адресацию в телефонной сети, рассмотренную выше. Однако наш пример с географической маршрутизацией имеет еще один уровень иерархии, которого нет в телефонной адресации, кроме того, мы в своей схеме делили все «поровну», хотя разным континентам, разным странам в рамках континента, разным областям в рамках страны стоило бы дать блоки адресов неравной длины, однако мы не стали этого рассматривать дабы не усложнять понимание главной идеи – идеи о префиксной маршрутизации. При необходимости можно было бы провести деление на блоки неравной длины, но пока зададимся вопросом: можно ли внедрить в Интернет такую схему?

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

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

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

Предоставление клиентам адресов класса С (как, впрочем и других классов) запрещено. Вместо этого провайдеры обращаются к RIR (RIPE в нашем регионе)

Напоминание

Мировым адресным пространством Интернета распоряжаются организации IANA/ICANN; очередные резервы выделяются согласно базе IANA, а координация всей деятельности по распределению IP-адресов и доменных имён осуществляется ICANN.
Региональная регистратура (Regional Internet Registry или RIR) распоряжается блоками размера /8 (это 216 блоков по 256 сетей класса С), полученными от IANA.
В настоящее время существуют три RIR - это RIPE,ARIN,APNIC, каждая из которых обслуживает определённые территории:
RIPE - страны Европы, часть Африки и Азии
ARIN - страны Северной Америки и через отдельные подразделения страны Латинской Америки
APNIC - Австралию, страны Азии и Океании и через отдельные подразделения Японию, Китай, Тайвань, Ю.Корею

и получают в свое распоряжение блок адресов из числа тех, которые еще не успели распределить ранее (в соответствии с техникой классов), но теперь эти адреса предоставляют провайдерам без учета техники классов, например: предположим, что набор адресов класса С 198.9.11.0 – 198.9.55.0 не успели распределить ранее с помощью техники классов. Теперь этот набор адресов рассматривается не как 45 сетей класса С, а просто как набор идущих подряд адресов, из которых с помощью маски можно выделить некоторое требуемое количество адресов подряд.

Положим провайдеру нужно 4 тысячи адресов. В старом стиле предоставления адресов провайдеру было бы предоставлено 16 адресов сетей класса С, например 198.9.11.0 – 198.9.26.0, что привело бы к появлению 16 записей в таблицах маршрутизации магистральных маршрутизаторов. Теперь же поступают иначе: из числа свободных адресов выделяют такой блок адресов, который можно записать одной агрегированной записью, например: 198.9.16.0 – 198.9.31.0 можно описать одной строкой в таблице маршрутизации 198.9.16.0/20. В этом случае в таблицах маршрутизации магистральных маршрутизаторов на данного провайдера будет записан только один маршрут – в сеть 198.9.16.0/20. Но ведь на самом деле это не сеть, а просто набор адресов подряд, которые провайдер будет раздавать своим клиентам, разделяя на множество мелких сетей. Это значит, что магистральные маршрутизаторы не знают маршрутов в СЕТИ (те сети, которые будут образованы из данного блока адресов), магистральные маршрутизаторы маршрутизируют пакеты по нескольким первым битам группы адресов, принадлежащих данному провайдеру, в данном случае маршрутизация на магистрали ведется на основании первых 20 битов адреса, а не на основании знания полных номеров сетей, которые впоследствии будут образованы клиентами данного провайдера. В таком случае говорят, что магистральные маршрутизаторы имеют маршруты не в сети, а маршрутизируют пакеты на основании префиксов (нескольких первых бит) в адресах и такая маршрутизация называется префиксной маршрутизацией.

Что дает применение префиксной маршрутизации? Начиная с некоторого времени, все адреса в Интернет распределяют именно таким образом, а это значит, что рост количества записей в таблицах маршрутизации магистральных маршрутизаторов происходит значительно медленнее, нежели он происходил бы, продолжай бы координационный центр Интернета распределять адреса в соответствии с техникой классов (в нашем примере одна запись вместо 16). Темп роста записей в таблицах маршрутизации на магистрали удалось значительно замедлить и это позволяет магистральным маршрутизаторам иметь в своих таблицах по прежнему, как и в 1993-ем десятки тысяч записей вместо сотен тысяч или миллиона!

С помощью данной техники можно уменьшить темпы роста таблиц маршрутизации магистрали, но можно ли уменьшить количество записей в таблицах? Те адреса, которые были распределены в Интернет в соответствии со старой классовой техникой, по-прежнему принадлежат их владельцам, и поэтому агрегировать такие записи обычно не удается. Для того, чтобы уменьшить количество записей на магистрали Интернета необходимо изменять те адреса, которые были выданы  ранее в соответствии с техникой классов, т.е. для этого необходимо отобрать у прежних владельцев их адреса класса С идущие подряд (например, отобрать 32 адреса класса С), убрать из таблиц маршрутизации магистрали 32 записи, отдать все эти 32 записи одному провайдеру, записать в таблицы маршрутизации магистрали одну строку, описывающую префиксный маршрут с маской /19, а затем этот провайдер будет раздавать адреса своим клиентам (да хоть бы и разбив диапазон на 32 сети по 254 узла!), но на магистрали маршрутизаторы будут обрабатывать пакеты в эту совокупность бывших сетей класса С не зная полных номеров сетей, а на основании 19-и битного префикса, что позволит уменьшить количество записей на магистрали с 32 до 1 в данном примере.

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

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

Из вышеизложенного следует, что CIDR – это набор административных правил и договоренностей. Применение CIDR в маршрутизаторах с точки зрения алгоритмов обработки пакетов ничем не отличается от рассмотренного выше применения масок. Просто с появлением CIDR магистральные маршрутизаторы обязаны поддерживать обработку масок, хотя раньше могли обойтись без их поддержки.

Подведем итоги:

  •  Те части адресного пространства, которые не успели раздать клиентам пользуясь техникой классов, распределяют теперь, не взирая на классы.
  •  Адреса в стиле CIDR распределяют крупным провайдерам, записывая в магистральные маршрутизаторы лишь один маршрут для относительно больших блоков адресов.
  •  Магистральные маршрутизаторы маршрутизируют поступающие на них пакеты не зная полных адресов сетей получателей, а на основании префиксов (первых бит адреса) тем провайдерам, которые получили соответствующий CIDR блок
  •  Провайдеры, получившие CIDR блоки распределяют их своим клиентам и более мелким провайдерам
  •  Те части адресного пространства, которые успели распределить в соответствии с техникой классов могут постепенно перераспределяться, тем самым можно уменьшить (а не просто остановить рост) адресные таблицы магистральных маршрутизаторов. Пока эти адреса не перераспределены полностью, маршрутизация на магистрали Интернета базируется как на относительно большом количестве старых записях в маршрутных таблицах (классовых), так и на небольшом количестве новых, префиксных записей.
  •  CIDR дает два основных преимущества Интернету: уменьшение таблиц маршрутизации магистральных маршрутизаторов и более экономное расходование адресного пространства.

Теперь рассмотрим практический пример, демонстрирующих принципы распределения адресов в соответствии с техникой CIDR.

Пусть в распоряжении координационного центра Интернет есть диапазон нераспределенных адресов вида 200.1.55.0 – 200.1.99.0. Распределение этих адресов в старом, классовом стиле очевидно – эти адреса были бы распределены как 45 адреса класса С и привели бы к появлению 45 записей в таблицах маршрутизации и вероятно к не рациональному расходованию каждой сети класса С. Распределение адресов в стиле CIDR предполагает выдачу относительно больших блоков адресов крупным провайдерам, которые в свою очередь будут делить этот блок на части для своих нужд и нужд своих клиентов. Для начала выясним, какие крупные блоки можно выделить из данного адресного диапазона. Очевидно, что не все адреса, идущие подряд можно агрегировать. Так как для того, того, чтобы адреса можно было агрегировать, они все должны иметь общую часть (раньше это называлось номер сети, но так это при использовании CIDR уже не сеть, а просто агрегированный блок адресов, то общую часть принято называть префикс), а все остальные биты должны принимать все значения от 00…00 до 11...11 во всех  прочих битах, не являющихся префиксом. Запишем эти адреса в двоичной форме:

  1.    200.1.00110111.0
    1.    200.1.01100011.0

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

Попытаемся выделить самый большой агрегируемый блок адресов из этого диапазона. Соблюдаем правило о том, что агрегируемым может быть блок адресов идущих подряд, при чем у всего блока адресов должна быть общая часть, а все что не является общей частью должно принимать все значения: от всех «0» до всех «1».

Итак, анализируем: первые два байта являются общей частью, но, очевидно, остальные 16 бит не смогут принять всех значений, так как самый большой адрес имеет в 17 бите «0».

Могут ли первые 17 бит быть общей частью? Да, видно, что и самый больший и самый меньший адрес имеют в 17 бите «0», но все остальные биты не смогут принять всех значений, так как младший адрес имеет в оставшихся битах не все «0», а старший – не все «1».

Могут ли первые два бита третьего байта быть общей частью для некоторых адресов из данного диапазона? Если их положить равными 00, то тогда минимальный из адресов не содержит в остальных битах всех нулей, в то время как адрес с третьим байтом 00111111 входит в данное адресное пространство. Но, тем не менее, не все условия агрегирования удовлетворены. Если же первые биты будут равны 01, то очевидно адрес с третьим байтом 01000000 попадает в диапазон имеющихся адресов, но не адрес с третьим байтом 01111111.

Могут ли первые три бита третьего байта быть общей частью для некоторых адресов из данного диапазона? Если их положить равными 000, то, очевидно, это не возможно – ни один адрес из нашего диапазона не имеет такого значения первых трех бит третьего байта. Положим их равными 010. Младший адрес 010|00000 принадлежит нашему диапазону, старший адрес 010|11111 так же принадлежит нашему диапазону, следовательно, можно разбить все исходное предоставленное нам адресное пространство на 3 части:

200.1.00110111.0 – 200.1.00111111.0 (200.1.55.0 – 200.1.63.0)

200.1.01000000.0 – 200.1.01011111.0 (200.1.64.0 – 200.1.95.0)

200.1.01100000.0 - 200.1.01100011.0 (200.1.96.0 – 200.1.99.0)

Вторую строчку можно представить в виде 200.1.64.0/19 и это очевидно самый крупный из рассматриваемых диапазонов. Подвергнем такому же анализу два оставшихся диапазона.

Начнем со второго:

200.1.01100000.0 - 200.1.01100011.0

Очевидно, что этот диапазон сразу можно записать агрегировать следующей строкой:

200.1.96.0/22

Переходим к первому диапазону:

200.1.00110111.0 – 200.1.00111111.0

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

200.1.00110111.0

200.1.00111000.0 – 200.1.00111111.0 (200.1.56.0 – 200.1.63.0)

Каждую из этих строк можно агрегировать:

200.1.00110111.0 =

200.1.00111000.0 – 200.1.00111111.0 = 

Итого, мы получаем следующие CIDR блоки из данного свободного диапазона адресов:

200.1.64.0/19 – около 8 тысяч адресов

200.1.56.0/21 – около 2 тысяч адресов

200.1.96.0/22 – около 1 тысячи адресов

200.1.55.0/24 – 256 адресов

Следовательно, координационный центр Интернета может предоставить эти адреса следующим образом:

200.1.64.0/19 – достаточно крупному провайдеру

200.1.56.0/21 – среднему провайдеру

200.1.96.0/22 – небольшому провайдеру

200.1.55.0/24 – размером в сеть класса С, предоставлять не выгодно, стоит подождать, пока освободятся адреса рядом с целью дальнейшего агрегирования.

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

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

0         32      48       64        96     128     192  

Из этой диаграммы теперь легко видеть, части какого размера можно выделить из данного диапазона адресов.

Видно, например, что диапазон адресов от 200.1.1.64 до 200.1.1.95 можно агрегировать в виде 200.1.64.0/19 (красный блок)

Помимо этого самого  большого блока можно агрегировать блок от 200.1.56.0 до 200.1.63.0 в виде 200.1.56.0/21 (синий блок)

Так же можно агрегировать блок от 200.1.96.0 до 200.1.1.99.0 в виде 200.1.96.0/22

И кроме этого остается ни с кем не агрегируемый блок, равный размеру сети класса С 200.1.55.0/24 (желтый)

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

Рассмотрим еще один пример.

Имеется блок адресов 195.6.72.0 – 195.6.140.0

Необходимо разделить его на минимальное количество CIDR блоков.

Можно ли из этого диапазона предоставить набор адресов провайдеру размеров в 8 тысяч узлов?

Представим таблично все возможные варианты деления данного диапазона, по возрастанию значений 3-го байта с 72 до 140. Затем выберем общие признаки и сгруппируем в агрегации по сочетанию Общее начало третьего байта + длина сетевого префикса. Полученные группировки выделим для удобства цветом.

Общая часть
3-го байта

195

6

72

0

 

Значение
3-го байта

Длина
префикса

Номер сети

01001

195

6

01001000

0-255

 

72

16+5=21

195.6.72.0/21

01001

195

6

01001001

0-255

 

73

21

01001

195

6

01001010

0-255

 

74

21

01001

195

6

01001011

0-255

 

75

21

01001

195

6

01001100

0-255

 

76

21

01001

195

6

01001101

0-255

 

77

21

01001

195

6

01001110

0-255

 

78

21

01001

195

6

01001111

0-255

 

79

21

0101

195

6

01010000

0-255

 

80

16+4=20

195.6.80.0/20

0101

195

6

01010001

0-255

 

81

20

0101

195

6

01010010

0-255

 

82

20

0101

195

6

01010011

0-255

 

83

20

0101

195

6

01010100

0-255

 

84

20

0101

195

6

01010101

0-255

 

85

20

0101

195

6

01010110

0-255

 

86

20

0101

195

6

01010111

0-255

 

87

20

0101

195

6

01011000

0-255

 

88

20

0101

195

6

01011001

0-255

 

89

20

0101

195

6

01011010

0-255

 

90

20

0101

195

6

01011011

0-255

 

91

20

0101

195

6

01011100

0-255

 

92

20

0101

195

6

01011101

0-255

 

93

20

0101

195

6

01011110

0-255

 

94

20

0101

195

6

01011111

0-255

 

95

20

011

195

6

01100000

0-255

 

96

16+3=19

195.6.96.0/19

011

195

6

01100001

0-255

 

97

19

011

195

6

01100010

0-255

 

98

19

011

195

6

01100011

0-255

 

99

19

011

195

6

01100100

0-255

 

100

19

011

195

6

01100101

0-255

 

101

19

011

195

6

01100110

0-255

 

102

19

011

195

6

01100111

0-255

 

103

19

011

195

6

01101000

0-255

 

104

19

011

195

6

01101001

0-255

 

105

19

011

195

6

01101010

0-255

 

106

19

011

195

6

01101011

0-255

 

107

19

011

195

6

01101100

0-255

 

108

19

011

195

6

01101101

0-255

 

109

19

011

195

6

01101110

0-255

 

110

19

011

195

6

01101111

0-255

 

111

19

011

195

6

01110000

0-255

 

112

19

011

195

6

01110001

0-255

 

113

19

011

195

6

01110010

0-255

 

114

19

011

195

6

01110011

0-255

 

115

19

011

195

6

01110100

0-255

 

116

19

011

195

6

01110101

0-255

 

117

19

011

195

6

01110110

0-255

 

118

19

011

195

6

01110111

0-255

 

119

19

011

195

6

01111000

0-255

 

120

19

011

195

6

01111001

0-255

 

121

19

011

195

6

01111010

0-255

 

122

19

011

195

6

01111011

0-255

 

123

19

011

195

6

01111100

0-255

 

124

19

011

195

6

01111101

0-255

 

125

19

011

195

6

01111110

0-255

 

126

19

011

195

6

01111111

0-255

 

127

19

10000

195

6

10000000

0-255

 

128

16+5=21

195.6.128.0/21

10000

195

6

10000001

0-255

 

129

21

10000

195

6

10000010

0-255

 

130

21

10000

195

6

10000011

0-255

 

131

21

10000

195

6

10000100

0-255

 

132

21

10000

195

6

10000101

0-255

 

133

21

10000

195

6

10000110

0-255

 

134

21

10000

195

6

10000111

0-255

 

135

21

100010

195

6

10001000

0-255

 

136

16+6=18

195.6.132.0/18

100010

195

6

10001001

0-255

 

137

18

100010

195

6

10001010

0-255

 

138

18

100010

195

6

10001011

0-255

 

139

18

10001100

195

6

10001100

0-255

 

140

16+8=24

195.6.140.0/24

Таким образом, получены следующие агрегации

1) 195.6.72.0/21  Количество узлов 232-21 – 2 = 2046

2) 195.6.80.0/20  Количество узлов 4094

3) 195.6.96.0/19  Количество узлов 8190

4) 195.6.128.0/21  Количество узлов 2046

5) 195.6.132.0/18  Количество узлов 16384

6) 195.6.140.0/24  Количество узлов 254

Т.к. в условии задачи требовалось разделить на минимальное количество CIDR блоков, на этом деление завершается. Обратите внимание, что для полного ответа необходимо перечислить все возможные варианты организации деления по значениям 3-го байта, так – что бы не осталось зависших (не указанных или не учтенных)) диапазонов.

Предположим, что одному из провайдеров выдали блок № 3. Пусть провайдер выдает из этого блока набор адресов, размером 1 тысячу узлов вторичному (мелкому) провайдеру. Вторичный провайдер использует этот блок адресов следующим образом:

- двум крупным клиентам блоки по 64 адреса,

- 5 клиентам блоки по 32 адреса,

- блок 256 адресов для своих dial-up клиентов.

Выполним все соответствующие разделения.

Итак, исходный блок 195.6.96.0/19 - количество узлов 8190.

a)

011

195

6

01100000

0-255

 

96

16+3=19

195.6.96.0/19

a)

011

195

6

01100001

0-255

 

97

19

a)

011

195

6

01100010

0-255

 

98

19

a)

011

195

6

01100011

0-255

 

99

19

011

195

6

01100100

0-255

 

100

19

011

195

6

01100101

0-255

 

101

19

011

195

6

01100110

0-255

 

102

19

011

195

6

01100111

0-255

 

103

19

011

195

6

01101000

0-255

 

104

19

011

195

6

01101001

0-255

 

105

19

011

195

6

01101010

0-255

 

106

19

011

195

6

01101011

0-255

 

107

19

011

195

6

01101100

0-255

 

108

19

011

195

6

01101101

0-255

 

109

19

011

195

6

01101110

0-255

 

110

19

011

195

6

01101111

0-255

 

111

19

011

195

6

01110000

0-255

 

112

19

011

195

6

01110001

0-255

 

113

19

011

195

6

01110010

0-255

 

114

19

011

195

6

01110011

0-255

 

115

19

011

195

6

01110100

0-255

 

116

19

011

195

6

01110101

0-255

 

117

19

011

195

6

01110110

0-255

 

118

19

011

195

6

01110111

0-255

 

119

19

011

195

6

01111000

0-255

 

120

19

011

195

6

01111001

0-255

 

121

19

011

195

6

01111010

0-255

 

122

19

011

195

6

01111011

0-255

 

123

19

011

195

6

01111100

0-255

 

124

19

011

195

6

01111101

0-255

 

125

19

011

195

6

01111110

0-255

 

126

19

011

195

6

01111111

0-255

 

127

19

Вторичному провайдеру выдадим диапазон в 1000 адресов (в 1024 т.к. 210)

- используем строчку а) для реализации этого условия. Для 1000 адресов необходимо 10 бит, т.к 210 ≥ 1000, длина сетевого префикса 32-10 = 22.

Получим диапазон 195.6.96.0/22, состоящий из

a)

011000

195

6

01100000

0-255

a)

011000

195

6

01100001

0-255

a)

011000

195

6

01100010

0-255

a)

011000

195

6

01100011

0-255

Вторичный провайдер делит полученный диапазон следующим образом.

- двум клиентам по 64 адреса. Для выдачи 64 адресов необходимо 6 бит, т.к.

26 ≥ 64. Т.е. длина сетевого префикса 32-6=26, получим сети

 195.6.01100000.00000000 /26  195.6.96.0 /26

 195.6.01100000.01000000 /26  195.6.96.64/26

Остаются неиспользованные адреса сетей

 195.6.01100000.10000000 /26  195.6.96.128/26

 195.6.01100000.11000000 /26  195.6.96.192/26

- 5 клиентам блоки по 32 адреса. Для выдачи 32 адресов необходимо 5 бит, т.к.

25 ≥ 32. Т.е. длина сетевого префикса 32-5=27. В начале используем остаток от предыдущего деления

 195.6.01100000.10000000 /27  195.6.96.128/27

 195.6.01100000.10100000 /27  195.6.96.160/27

 195.6.01100000.11000000 /27  195.6.96.192/27

 195.6.01100000.11100000 /27  195.6.96.224/27

и один адрес из следующего диапазона

 195.6.01100001.00000000 /27  195.6.97.0/27

Остаются неиспользованные адреса сетей диапазона

 195.6.01100001.00000000 /24, кроме 195.6.97.0/27  

 

- блок 256 адресов для своих dial-up клиентов. Блок в 256 адресов описывается 8 битами, т.к. 28 = 256. Т.е. длина сетевого префикса 32-8=24. Используем диапазон

195.6.01100010.00000000 /24  195.6.98.0/24

полностью.

После произведенных манипуляций у вторичного провайдера остается не использованный диапазон

195.6.01100011.00000000 /24  (195.6.99.0/24)  - полностью

и диапазон

195.6.01100001.00000000 /24  (195.6.97.0/24)  - кроме адреса  195.6.97.0/27

Подведем краткие итоги по изученному материалу:

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

Во второй части курса мы рассматривали IP адресацию: доклассовые методы, технику классов, технику масок и масок переменной длины.

Третья часть курса была посвящена принципам маршрутизации: мы рассматривали логику работы маршрутизатора в разных случаях, учились базовым настройкам маршрутизатора Windows и Cisco, рассматривали проблемы Интернета, связанные с повышением эффективности маршрутизации.

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

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

Начнем с определения понятия «Длина заголовка». Как известно, при передачи информации между уровнями модели OSI, данные помещаются в пакеты соответствующих протоколов, а каждый протокол имеет заголовок – часть пакета содержащая обязательную служебную информацию и опционально дополнительные служебные данные. Длина заголовка определяется документально (RFC) для каждого протокола, при этом длина может быть постоянной – не изменяется не при каких условиях, и переменной – обычно в случае если заголовок может содержать дополнительные необязательные поля.

Заголовок IP пакета имеет переменную длину. Заголовок состоит из 20 байтовой стационарной части (присутствующей в каждом IP заголовке) и необязательного поля опций переменной длины. Следовательно, минимальная длина IP заголовка составляет 5 четырехбайтовых слов (1 слово = 4 байта).

Рассмотрим обязательные поля заголовка IP пакета, их назначение и функции.

Первое четырехбайтовое слово IP заголовка, содержит первым  поле Version – Версия. Длина данного поля – 4 бита.

Version

 

 

 

 

 

 

 

<----------------------------------------- 32 бита ---------------------------------------> 

Данное поле показываем версию протокола IP. Мы изучаем не просто протокол IP, а вполне конкретную версию №4. Следовательно, первое поле IP пакета должно всегда принимать значение  0100 = 4:

Version

 

 

 

0

1

0

0

Для чего используется это поле? Дело в том, что разработчики IP полагали, что протокол IP будет развиваться,  будут появляться новые версии и будет узлы и маршрутизаторы, которые поддерживают несколько версий протокола IP. Тогда в заголовке канального уровня поле, показывающее, что внутри кадра лежит IP пакет, будет принимать одно и то же значение для всех версий протокола IP (например, поле Type в Ethernet 08 00), а конкретная версия IP будет выясняться из первого поля самого IP заголовка. Т.е. некий единый блок обработки IP пакетов будет получать IP пакеты всех версий от протокола канального уровня и на основании первого поля решать, как анализировать данный пакет. Однако на практике оказалось, что когда протокол IP версии 6 стали применять, за ним было закреплено новое значение поля Type (86 DD) и аналогичных полей в прочих канальных протоколах. Так что, по сути, функциональность поля Version фактически отсутствует сегодня. Но при этом, если на узел или маршрутизатор, поддерживающий только IPv4, поступит пакет с полем Version отличным от 4, такой пакет просто будет отброшен.

Следующее поле – IHL (Internet Header Length) – длина заголовка IP пакета, длина этого поля тоже 4 бита.

Version

IHL

 

 

0

1

0

0

 

 

 

 

Так как заголовок IP пакета имеет переменную длину, приемной стороне необходимо правильно отделить заголовок IP пакета от данных, которые за ним следуют. Это необходимо с одной стороны для правильной интерпретации самого заголовка, с другой стороны для правильного извлечения данных из пакета. Нам известно несколько способов указания окончания поля переменного размера: полем длина и управляющими символами. Самый простой и часто употребляемый способ указания окончания поля переменной длины – заранее указать в специальном поле длину поля переменной длины. Именно так и поступают в заголовке IP – поле IHL показывает длину всего заголовка пакета, притом, что этот заголовок, как уже было сказано, состоит из стационарной части, длиной 20 байт и переменной длины опций. Какое самое большее значение принимает четырехбитовое поле?  Очевидно, максимальное значение равно 15, т.к. максимальное значение 4-х бит это 1111 = 15. А мы сказали, что минимальная длина заголовка пакета без опций равна 20 байт, следовательно поле IHL не может выражать длину заголовка пакета в байтах – для этого данное поле слишком короткое. Поле IHL описывает длину IP заголовка в четырехбайтовых словах. Отсюда можно сделать следующие выводы:

  •  Минимальное значение поля IHL = 5, так как именно 5 четырехбайтовых слов и составляют 20 байт заголовка без опций.
  •  В случае применения опций в IP пакета их количество должно быть таковым, чтобы длина всех опций была кратна четырем байтам, так как указание окончания заголовка пакета делается с точность 4 байта.
  •  Максимальная длина IP пакета не может превысить 60 байт, так как самое большое значение, которое может принять поле IHL = 15, что означает, что длина заголовка пакета равна пятнадцати четырехбайтовым словам, т.е. 60 байт.
  •  Максимальная длина опций в IP пакета ограничена 40 байтами, так как из всего как максимум 60 байт IP заголовка, 20 байт занимает стационарная часть заголовка. 

Рассмотренные выше ограничения и зависимости не стоит заучивать наизусть. Главное понять идею рассуждения и суть рассмотренных взаимодействий. И тогда достаточно вспомнить битовую длину поля IHL для вывода последующих ограничений, максимальных и минимальных значений. Умение проводить подобные рассуждения являются необходимыми при изучении многих других протоколов.

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

Обычно опции в IP пакете не применяются, следовательно, подавляющее большинство IP пакетов имеет в поле IHL значение 0101 (5), хотя возможны и все остальные значения от 6 до 15.

Поле TOS (Type of Service)

Version

IHL

TOS

 

0

1

0

0

0

1

0

1

P

P

P

D

T

R

0

0

Type Of Service (тип обслуживания). В RFC791 сказано:

«The Type of Service provides an indication of the abstract parameters of the quality of service desired»

TOS является некоторым абстрактным параметром, с помощью которого отправитель пакета может попросить маршрутизаторы некоторых особых подходов к обработке пакета. Например: мы отправляем с помощью обычной бумажной почты письмо, и пишем на конверте «ОЧЕНЬ ВАЖНО! СРОЧНО!» Что это значит для работников почтовой службы? Да ровным счетом ничего!!! Скорее всего, эту надпись на конверте вообще никто не прочитает, так как почтовым работникам недосуг читать всякие посторонние надписи на конвертах, им работать надо, у них есть чем заниматься. Но представим себе, что какой-то сотрудник почты прочитал данную надпись на конверте, и положил данное письмо в груз, отправляемый сегодняшним самолетом, в то время как это письмо по правилам следовало (можно было бы) отправить завтра. Письмо достигнет адресата раньше потому, что отправитель написал на конверте «СРОЧНО».

Примерно так же и работает поле TOS – отправитель просит специального подхода к передаче данного пакета у маршрутизаторов, которые пакет пересекает, но будут ли маршрутизаторы анализировать поле TOS или они его вообще игнорируют в общем случае неизвестно. Единственное отличие работы маршрутизаторов с полем TOS от работы почтальона с письмом из примера состоит в том, что на конверте, вообще говоря, по стандарту почты не положено писать «СРОЧНО» и тот факт, что почтальон заметил эту надпись – чистая случайность, в то время как в заголовке IP пакета поле TOS есть по стандарту (RFC791), однако маршрутизаторы, тем не менее, не обязаны его анализировать и использовать полученные из него данные для обработки пакета.

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

 Первые три бита, РРР, называются Precedence - предпочтительность. С помощью заполнения данного трехбитового подполя поля TOS отправитель может попросить маршрутизатор обработать данный пакет «вне очереди», раньше других пакетов, возможно поступивших в маршрутизатор раньше данного и попавших вместе с ним в очередь. Так поле Precedence  имеет длину три бита, то соответственно в IP пакете поддерживается указание одного из восьми значений предпочтительности обслуживания. RFC791 описывает названия этих уровней предпочтительности:

111 - Network Control (сетевое управление)

110 - Internetwork Control (межсетевое управление)

101 - CRITIC/ECP (критический)

100 - Flash Override (быстрее чем молниеносный)

011 – Flash (молниеносный)

010 – Immediate (немедленный)

001 – Priority (приоритетный)

000 – Routine (обычный)

 Для поддержки Precedence маршрутизатор должен поддерживать несколько очередей обработки пакетов, в идеале таких очередей должно быть 8. Однако многие маршрутизаторы игнорируют значение поля Precedence, так как имеют только одну очередь, работающую по принципу FIFO (First inputfirst output или Первым вошел – первым вышел) и просто не могут обеспечить различным пакетам различный уровень обслуживания. Иногда маршрутизатор поддерживает поле Precedence, но ограничено, то есть имеет не восемь, а, например, три очереди обслуживания пакетов, одна для значений поля Precedence 000, вторая для значений 001, 010, 011, 100, и третья – для значений 101, 110, 111. Разумеется,  возможны и другие реализации.

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

Следующие три бита, D, T, R расшифровываются как:

  •  D:  Delay.
  •  T: Throughput.
  •  R: ReliabilityRFC791 – грамматическая ошибка, написано «Relibility»).

Установка этих битов в «0» означает отсутствие специальных требований по обработке пакета, установка каждого бита в «1» означает соответственно:

  •  D  – передать пакет по маршруту, характеризующемуся минимальной задержкой передачи
  •  T  – передать пакет по маршруту, характеризующемуся максимальной пропускной способностью
  •  R:   – передать пакет по маршруту, характеризующемуся максимальной достоверностью передачи, чтобы уменьшить вероятности искажения или потери пакета.

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

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

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

Следующие два бита поля TOS в RFC791 являются зарезервированными, однако есть еще два RFC, дополняющие правила использования поля TOS.

В RFC1349 предлагается использование седьмого бита поля TOS как бита С (Cost, Monetary Cost). Предлагается устанавливать этот бит в том случае, если передача данных по разным маршрутам может иметь различную денежную стоимость. В таком случае установка бита C означает просьбу узла маршрутизатору передать пакет с минимальной денежной стоимостью.

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

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

Поле  Total Length.

Version

IHL

TOS

Total Length

0

1

0

0

0

1

0

1

P

P

P

D

T

R

0

0

Данное поле показывает длину IP пакета в байтах, включая полный заголовок IP пакета и поле данных пакета, следующее за заголовком. Из длины поля Total Length (2 байта), следует, что максимальная длина IP пакета может составить не более 65535 байт. Однако, применение таких пакетов затруднено тем, что MTU большинства сетей канального уровня гораздо меньше, нежели 65535 байт. RFC791 рекомендует отправлять IP пакеты не длиннее 576 байт, если только отправитель не уверен, что получатель может принять более длинные пакеты.

 

 «Total Length is the length of the datagram, measured in octets, including internet header and data.  This field allows the length of a datagram to be up to 65,535 octets.  Such long datagrams are impractical for most hosts and networks.  All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments).  It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams.»

 

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

Переходим ко второму четырехбайтовому слову IP заголовка.

Рассмотрим следующий пример:

Пусть станция А передает IP пакет станции B. Так как станция А имеет интерфейс Ethernet, то на основании вышесказанного стек TCP/IP (точнее, TCP) станции А сформирует такого размера IP пакет, чтобы он помещался в кадр канального уровня Ethernet,  то есть поле Total Length IP пакета будет скорее всего равно 1500, и, соответственно, получится кадр канального уровня максимально возможного в Ethernet размера. Этот кадр поступит на маршрутизатор, маршрутизатор в первую очередь отбросит заголовок канального уровня и извлечет из кадра IP пакет. После этого маршрутизатор извлечет из заголовка IP пакета адрес получателя и с помощью таблицы маршрутизации найдет, что делать с пакетом. Положим, что пакет нужно передать узлу В, тогда маршрутизатор поймет это исходя из анализа таблицы маршрутизации должен будет снабдить данный IP пакет заголовком канального уровня Token Ring.

Можно ли это сделать? Да, так как размер IP пакета не превысит 1500 байт (ведь его послала станция Ethernet), а сеть Token Ring может переносить порции данных более 4 килобайт в одном кадре. Другое дело, что использование сети Token Ring в таком случае будет не эффективным, так как в сети Token Ring могут применяться кадры размером больше, нежели 1500 байт, но, тем не менее, это ничуть не помешает взаимодействию.

 Теперь рассмотрим обратную ситуацию: пусть станция В послала IP пакет станции А. Станция В сформирует IP пакет размером около 4 килобайт (напоминаем, что IP пакет может достигать 65535 байт) и передаст его маршрутизатору в кадре канального уровня Token Ring. Маршрутизатор отбросит заголовок Token Ring, проанализирует IP заголовок и примет решение о перенаправлении пакета в сеть, в которой находится узел А. После принятия решения о перенаправлении пакета в сеть, в которой находится узел А необходимо узнать его МАС адрес, а после этого сформировать кадр Ethernet, положив в него IP пакет. Вот тут то и получится загвоздка: нельзя положить в кадр Ethernet 4 килобайта – MTU сети Ethernet составляет 1500 байт. Так как пакет не может быть передан, возникает вопрос, что же с ним делать? Или уничтожить или разрезать на части. Многие сетевые протоколы в таком случае уничтожают пакет, протокол IP вместо этого фрагментирует пакет, разрезает его на кусочки и передает в нескольких кадрах канального уровня. Для того, чтобы взаимодействие могло быть осуществлено, недостаточно просто разрезать пакет на части и передать, необходимо обеспечить во-первых возможность частям пакета пересекать составную сеть (ведь фрагментировать может не только оконечный но и транзитный маршрутизатор), а во-вторых обеспечить приемной стороне возможность однозначно собрать полученный фрагментарно пакет. Первая проблема решается просто: фрагментируется не весь пакет целиком, включая заголовок, как показано на рисунке

Заголовок

Данные

Заголовок

Данные

 

 

Данные

 

Данные

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

Фрагментация происходит так, что КАЖДЫЙ фрагмент сохраняет исходный заголовок и после проведения фрагментации может перемещаться по составной сети как совершенно самостоятельный пакет. Пример:

Заголовок

Данные

Заголовок

Данные

 

Заголовок

Данные

 

Заголовок

Данные

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

Поле ID, длина 2 байта. Данное поле IP пакета должно заполняться отправителем следующим образом: каждый новый IP пакет должен иметь значение поля ID отличающее его от предыдущих пакетов, обычно первый посланный станцией пакет имеет ID=0, все следующие пакеты, посылаемые станцией, независимо от того, кому они посылаются, имеют ID на единицу больше предыдущего. Важно понимать, что поле ID не используется для нумерации пакетов с целью обеспечения гарантий доставки, так как IP – чисто дейтаграммный протокол. Это поле преследует только одну цель – позволить приемнику отличать фрагменты одного пакета от фрагментов другого. Это возможно благодаря тому, что маршрутизаторы при фрагментации пакетов присваивают всем фрагментам некоторого рассеченного на части пакета тот ID который был у исходного пакета. Следовательно, когда узлу получателю приходят IP пакеты с одинаковыми ID, получатель знает, что это – фрагменты одного и того же пакета и пытается собрать исходный пакет из этих фрагментов. Если же получены пакеты с различными ID, это значит, что они не принадлежат одному пакету. Так как поле ID двухбайтовое, то после достижения значения 65535 поле ID снова принимает значение 0 и начинает снова инкрементироваться. Это в свою очередь значит, что формально возможна ситуация, когда станция получает фрагменты с одинаковыми ID, но они не принадлежат одному пакету, так как эти ID были присвоены и интервалом 65535 пакетов, но такая ситуация слишком маловероятна, чтобы принимать ее во внимание. Итак, станция получатель «складывает» в памяти все пришедшие пакеты с одинаковыми ID и пытается собрать из них исходный пакет. Достаточно ли у получателя сведений, чтобы правильно собрать пакет из фрагментов? Разумеется - нет, так как не ясно, какой их фрагментов первый, в каком порядке их собирать, не ли пропущенных фрагментов и какой фрагмент является последним. Для ответов на эти вопросы применяются остальные поля второго четырехбайтового слова IP заголовка.

 Следующее поле заголовка – флаги, длина 3 бита. Пока рассмотрим лишь флаг MF. Эта аббревиатура расшифровывается как «More Fragments». Данный флаг применяется следующим образом: у всех фрагментов, кроме последнего он равен 1 (т.е. показывает, что будет еще фрагменты), у последнего фрагмента он равен 0, показывая, что это – последний фрагмент. Отсюда следует, что если пакет не фрагментирован, то он имеет MF=0, если же фрагментирован, то все фрагменты кроме последнего имеют MF=1, а последний фрагмент имеет MF=0. Если среди принятых фрагментов нет фрагмента с MF=0, это означает, что, по крайней мере, один фрагмент (последний) потерялся и сборка исходного пакета из фрагментов не возможна. Зачем показывать, какой из фрагментов последний? Для понимания этого для начала рассмотрим еще одно поле. Ясно, что только лишь ID и MF не достаточно для правильной сборки: с помощью ID можно отделить фрагменты одного пакета от других пакетов, с помощью MF найти последний фрагмент, но выстроить все предыдущие пакеты в правильном порядке и убедиться в отсутствии пропущенных фрагментов с помощью этих двух полей не возможно.

Пока опустим рассмотрение флага DF, первый флаг не используется и зарезервирован, рассмотрим последнее поле второго четырехбайтового слова заголовка: Fragment Offset, длина 13 бит. Это поле позволяет понять, какое место занимает данный фрагмент в исходном пакете. Смысл этого поля очень прост: оно показывает, начиная с какого байта исходного пакета начинается данный фрагмент. Это означает, что фрагмент со значением поля Fragment Offset = 0 – первый фрагмент исходного пакета, так байты этого фрагмента занимают в исходном пакете позицию начиная с нулевой. Мы уже научились находить первый и последний фрагменты, как разобраться с промежуточными фрагментами, например, как найти второй фрагмент? Очень просто: первый фрагмент найти легко – его поле Offset=0. Если его MF=0, то сборка завершена – пакет не был фрагментирован. Если же MF=1 фрагмента с Offset=0, то далее из поля Total Length первого фрагмента можно узнать сколько байт данных принес получателю первый фрагмент. Следовательно, далее необходимо найти пакет с таким значением поля Offset, которое как раз и будет соответствовать количеству байт первого фрагмента, например, если первый фрагмент принес 1000 байт (с номерами от 0 до 999), то фрагмент, который должен идти вслед за этим фрагментов должен иметь Offset=1000. Если такого фрагмента нет (или фрагмента с меньшим Offset), то сборка не возможна, если такой фрагмент есть, то его поле данных дописывается к полю данных первого фрагмента и проводиться проверка флага MF второго фрагмента. Если он равен 0, то сборка завершена, так как второй фрагмент был последним, если же MF второго фрагмента равен 1, то значит нужно найти такой фрагмент, у которого Offset будет равен (или менее) суммарной длине первых двух фрагментов. Далее этот алгоритм повторяется, пока не будет достигнут конец пакета или сборка окажется невозможной.

Рассмотрим простой пример: какими будут комбинации полей MF и Fragment Offset у различных пакетов и фрагментов.

Не фрагментированный пакет: MF=0, Offset=0

Первый фрагмент: MF=1, Offset=0

Промежуточный фрагмент: MF=1, Offset=ХХХ

Последний фрагмент: MF=0, Offset=YYY

Рассмотрим четыре примера:

  1.  Запишем несколько «фрагментов» одного пакета (т.е. поля ID, MF, Offset) таким образом, чтобы пакет «собрался»:

Длина исходного пакета 4440, т.е. 1480+1480+1480

1

2

3

ID = A0 B1

MF = 1

Offset= 0

ID = A0 B1

MF = 1

Offset= 1480

ID = A0 B1

MF = 0

Offset= 2960

  1.  Запишем несколько «фрагментов» одного пакета (т.е. поля ID, MF, Offset) таким образом, чтобы пакет не мог быть «собран» из-за отсутствия первого фрагмента:

Длина исходного пакета 4440, т.е. 1480+1480+1480

1

2

3

ID = A0 B1

MF = 1

Offset= 100

ID = A0 B1

MF = 1

Offset= 1480

ID = A0 B1

MF = 0

Offset= 2960

  1.  Запишем несколько «фрагментов» одного пакета (т.е. поля ID, MF, Offset) таким образом, чтобы пакет не мог быть «собран» из-за отсутствия последнего фрагмента:

Длина исходного пакета 4440, т.е. 1480+1480+1480

1

2

3

ID = A0 B1

MF = 1

Offset= 0

ID = A0 B1

MF = 1

Offset= 1480

ID = A0 B1

MF = 1

Offset= 2960

  1.  Запишем несколько «фрагментов» одного пакета (т.е. поля ID, MF, Offset) таким образом, чтобы пакет не мог быть «собран» из-за отсутствия промежуточного фрагмента:

Длина исходного пакета 4440, т.е. 1480+1480+1480

1

2

3

ID = A0 B1

MF = 1

Offset= 0

ID = A0 B1

MF = 0

Offset= 1480

ID = A0 B1

MF = 0

Offset= 2960

Итого: с помощью ID идентифицируются все фрагменты одного пакета, но полю Offset разыскивается первый фрагмент, по сравнению длин фрагментов с Offset находятся следующие фрагменты, сигналом к окончанию сборки является фрагмент с MF=0. Однако в рассмотренном нами механизме есть еще несколько тонкостей.

Каково максимальное значение, которое принимает поле Fragment Offset? Так как длина этого поля равна 13 бит, то очевидно, максимальное значение, которое может принять данное поле равно 8191. Следовательно, если поле Offset описывало бы смещение в БАЙТАХ, то самое большое возможное смещение было бы равно 8191, и это при потенциально возможной длине пакета 65535! Это значило бы, что фрагментация по сути возможна только до байта номер 8191, а следующий фрагмент должен простираться до конца пакета, так как дальнейшее указание смещения не возможно. Для того, чтобы этого избежать и сделать механизм фрагментации полнофункциональным, поле значение Fragment Offset измеряется не в байтах, а в восьмибайтовых словах, тогда самое большое возможное смещение равно 8191*8=65528, что очень близко к максимальной длине пакета 65535.

Тогда, рассмотренный ранее пример имеет вид

Длина исходного пакета 4440, т.е. 1480+1480+1480

1

2

3

ID = A0 B1

MF = 1

Offset= 0

ID = A0 B1

MF = 1

Offset= 185

ID = A0 B1

MF = 0

Offset= 370

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

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

Что происходит, если один фрагмент пакета потеряется? Будет ли повторен только он или повторять придется весь пакет? Так как IP не занимается гарантированием доставки пакетов (так как является дейтаграммным протоколом), то гарантированием доставки должен заниматься протокол, уровнем выше. В стеке TCP/IP это протокол TCP (обычно). TCP формирует блок данных для отправки и ожидает подтверждения от TCP приемника. Так как IP пакет при невозможности сборки уничтожается, то TCP получателя не получает своего блока данных, и следовательно не уведомляет TCP отправителя о получении, а это значит, что TCP отправителя должен будет этот блок данных повторить. Сам TCP понятия не имеет о фрагментации – он или получает свой блок данных или нет, а сам IP не имеет никаких инструментов (это будет видно после полного изучения формата заголовка IP пакета) для затребования повторной передачи как отдельно взятого фрагмента так и всего пакета в целом. Поэтому при утере хотя бы одного фрагмента протоколы ВЕРХНИХ уровни модели будут повторять свои данные заново, нельзя даже говорить, что IP пакет будут повторен – повторены будут сами данные в НОВОМ IP пакете – повторных передач IP пакетов вообще не бывает.

 Теперь рассмотрим второй флаг – DF. Этот флаг расшифровывается как Dont Fragment. Если такой флаг установлен в заголовке IP пакета, то это является запретом для маршрутизаторов фрагментировать пакет. Так как передать пакет не фрагментируя нельзя, а фрагментировать запрещено, то маршрутизатор просто уничтожает пакет. Зачем это может быть необходимо? Для начала рассмотрим вопрос: хорошо ли, что маршрутизаторы вынуждены фрагментировать пакеты? Конечно же НЕТ, так как на маршрутизаторы ложится серьезная вычислительная нагрузка и дополнительные действия, которые вынужден совершать маршрутизатор не являются желательными. Поэтому узлам рекомендуется перед передачей пакетов выяснять, какой минимальный MTU присутствует в сетях, через которые передается пакет данному получателю, а уже затем использовать именно такой размер пакета. Технологии Path MTU Discovery в полном объеме будет рассмотрена позднее, а пока рассмотрим простейший механизм выяснения MTU в пути следующим образом: станция передает все свои пакеты с флагом DF, и если пакеты ответы на запросы прикладных служб не приходят, станция уменьшает размер пакетов пока ответы не станут приходить. Это позволит разгрузить все маршрутизаторы сети от выполнения лишней работы, но приводит к дополнительным задержкам перед началом обмена пакетами с любы узлом. Работать ли в таком стиле в составной сети (т.е. отправлять ли все пакеты с флагом DF, заботясь о маршрутизаторах в ущерб собственной производительности) или не делать этого зависит от реализации стека TCP/IP и от его настройки.

На этом рассмотрение второго четырехбайтового слова IP заголовка завершено.

Рассмотрим первое поле третьего слова TTL.

TTL - длина 1 байт.

Рассмотрим пример сети:

Предположим, что у маршрутизатора R3 маршрут в сеть D пролегает через маршрутизатор R2 по некоторым причинам, например, связанным с низкой скорость связи R3 – R1. У маршрутизатора R2 маршрут в сеть D пролегает через маршрутизатор R1, а в настройках маршрутизатора R1 есть ошибка, и маршрут в сеть D пролегает для этого маршрутизатора через маршрутизатор R3. Что произойдет с пакетом направленным в сеть D, если он попадет на любой из маршрутизаторов R1, R2, R3? Маршрутизатор R1 передаст пакет маршрутизатору R3, тот передаст его R2, а R2 в свою очередь передаст его R3 и таким образом, вследствие ошибки администратора или протокола маршрутизации пакет направленный в сеть D никогда не достигнет этой сети, а будет бесконечно двигаться между маршрутизаторами R1, R2, R3. Такая ситуация называется «маршрутная петля» и приводит к серьезным проблемам. С одной стороны коммуникации с сетью D нарушены – пакеты в нее попасть не могут, но это только полбеды. Есть еще одна проблема: линии связи между маршрутизаторами R1, R2, R3 перегружены передачей зацикленных пакетов и эта перегруженность сетей, соединяющих маршрутизаторы приводит к уменьшению эффективной пропускной способности каналов связи, что приводит к нарушению и других сетевых коммуникаций, а не только коммуникаций с сеть D. Маршрутная петля может появиться и между соседними маршрутизаторами.

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

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

 Этот механизм называется «Время жизни пакета», TTL (Time To Live) и работает следующим образом: каждый пакет при формировании получает некоторое значение однобайтового поля TTL, на усмотрение приложения, пославшего пакет или стека TCP/IP. При прохождении маршрутизатора он должен уменьшить это значение при перенаправлении пакета. Изначально полагалось, что маршрутизатор уменьшит значение поля TTL на то количество секунд, которые пакет провел в буфере маршрутизатора ожидая обработки, однако с одной стороны это дополнительно нагружает маршрутизатор необходимостью считать время нахождения в буфере каждого пакета (дополнительная нагрузка на процессор и память маршрутизатора), а с другой стороны с некоторых пор маршрутизаторы обрабатывают пакеты не «секунды», а скорее «миллисекунды», так что сегодня маршрутизаторы просто уменьшают поле TTL на единицу при обработке пакета. Когда значение поля TTL достигает нуля, маршрутизатор вместо того, чтобы маршрутизировать пакет, просто уничтожает его, таким образом, если пакет попал в маршрутную петлю, то через некоторое количество прыжков между маршрутизаторами он будет уничтожен. Возникает несколько вопросов:

  •  Достаточна ли длина поля TTL, не получится ли, что пакет даже с максимально возможным стартовым TTL=255 будет уничтожен, просто не успев достигнуть цели в ходе нормальной маршрутизации без петель?
  •  Каким ставить TTL у отправляемых пакетов: 255 или меньше?

Может показаться, что в огромной сети 255 возможных прыжков – не так уж и много и могут возникать ситуации, когда нормально двигающийся по сети пакет уничтожается. Однако это не так, вспомним модель географической маршрутизации: сколько прыжков необходимо было бы, если бы Интернет был построен в соответствии с этой моделью? Очевидно, количество переходов не превысило бы десятка. На самом деле Интернет устроен не так, как предлагается в этой модели, но тем не менее маршруты в Интернет не являются хаотичными, а все же имеют четкую структуру (хотя и иную, нежели в рассмотренной модели) и поэтому для передачи пакета в рамках составной сети обычно достаточно гораздо меньшего числа переходов, нежели 255. практика показывает, что подавляющее большинство узлов в Интернет достижимы с произвольного узла за число переходов меньшее 30. В этом можно убедиться, применяя утилиту tracert.exe для проверки тех маршрутизаторов, которые пересекают пакеты, направленные к некоторому узлу. Следовательно, ограничение числа переходов, которые может совершить пакет связанные с ограниченностью длины поля TTL не является проблемой.

Каким стоит устанавливать поле TTL у отправляемых пакетов? Можно, конечно устанавливать его равным 255, в таком случае пакет будет максимально вероятно доставлен получателю. Даже если такой пакет попадет в маршрутную петлю, он будет «путешествовать» по ней максимально долго, и если петлю успеют исправить (администратор или протокол маршрутизации), то пакет сможет быть доставлен получателю максимально вероятно. Однако такая забота о доставке собственного пакета провоцирует дополнительные сетевые проблемы, так как если маршрут попадет в маршрутную петлю, он будет «вредить» сети максимально долго. При этом шанс, что петля исправится даже за само большое возможное время жизни пакета невелик. Получается, что установка TTL=255 это очень «эгоистично» - повышая шанс передачи пакета в случае возникновения проблем в сети, отправитель таким образом провоцирует дополнительные проблемы, при этом имея минимальный шанс, что большой TTL все же приведет к доставке пакета. Получается, что шанс доставить пакет в случае возникновения петли крошечный от большого TTL, а проблемы будут созданы ВСЕГДА в случае наличия петли. Поэтому более правильно было бы устанавливать меньший TTL в отправляемых пакета, впрочем, это определяется программистами стека (по умолчанию стек отправляет пакеты с тем TTL, который определил автор стека) или администратором, который может настроить TTL в отправляемых стеком пакетах. Например, в Windows для этого нужно изменить ключ строковый реестра HKEY_LOCAL_MACHINE/System/ CurrentControlSet/Services/Tcpip/Parameters/DefaultTTL.

Различные операционные системы устанавливают TTL по умолчанию различным: Windows 2000 использует значение 128, Windows 95 – 32, Windows NT 4.0 – 64, многие Unix системы – 255.

Важно понимать, что из перехваченного в проводе пакета нельзя однозначно определить, сколько маршрутизаторов прошел пакет, можно лишь выяснить, сколько маршрутизаторов он еще МОЖЕТ пройти, впрочем, так как обычно ОС устанавливают TTL из некоторого типичного набора: 32, 64, 128, 255, то обычно с большой вероятностью все же выводы о количестве пройденных маршрутизаторов можно сделать.

Таким образом,  поле TTL – важнейший инструмент преодоления ошибок в настройке маршрутов (точнее – в уменьшении вреда от неправильной настройки маршрутов) и является важно функцией IP, направленной на устойчивую работу сети.

Переходим к рассмотрению следующего поля – Protocol.

Данное поле указывает какой протокол инкапсулирован в поле данных пакета IP. Так как длина поля Protocol всего 1 байт, то он может переносить данные всего лишь 256 разных протоколов. Отсюда следует, что приложения не должны передавать свои данные непосредственно в IP пакетах, так как число приложений, которые должны пользоваться сетью гораздо больше 256. Что же делать? Для передачи данных конкретных приложений в стеке TCP/IP используются протоколы TCP и UDP, которые передаются непосредственно поверх IP пакетов, за ними зарезервированы значения пол Protocol, а сами эти протоколы имеют специальные двухбайтовые поля для указания приложения, передающего свои данные поверх этих двух протоколов, а двухбайтовое поле может адресовать уже 65536 разных приложений. Значения поля протокол зарезервированные за различными протоколами (TCP и UDP в том числе) являются справочными данными и их можно найти все в том же RFC1700.

 

Переходим к следующему полю заголовка – Контрольная сумма заголовка (Header Checksum) .

Если IP пакеты передаются по сетям с помощью современных протоколов канального уровня локальных и глобальных сетей, которые сами защищают переносимые данные контрольными суммами, то зачем в стеке реализовывать защиту? Вспоминаем, что изначально IP использовался для переноса по глобальным линиям связи с помощью протокола SLIP, которые не выполняет защиту переносимых данных. Далее возникает вопрос: если в заголовок IP пакета вставить поле контрольной суммы, которое бы рассчитывалось для всего пакета: и заголовка и данных, было бы хорошо или плохо? Разумеется, это было бы плохо, так как, по крайней мере, заголовок пакета меняется при прохождении маршрутизаторов, следовательно, контрольную сумму каждому маршрутизатору пришлось бы пересчитывать, что является дополнительной вычислительной нагрузкой на маршрутизатор, а если бы маршрутизатору пришлось бы при этом еще и пересчитывать контрольную сумму по ВСЕМУ пакету, было бы очень печально . Поэтому в стеке TCP/IP поступают так: всякий протокол, желающий положить свои данные в IP пакет САМ должен позаботится о защите передаваемых им данных и собственного заголовка контрольной суммой, т.е. IP получает уже защищенные данные. Т.е., если повредится содержимое IP пакета, ничего страшного не произойдет, ошибка будет обнаружена, но что будет, если повредится сам заголовок IP пакета? Для защиты заголовка IP пакета в этом самом заголовке присутствует поле «Контрольная сумма заголовка», таким образом, достигается разумный компромисс: маршрутизаторы все равно должны пересчитывать контрольную сумму для каждого обрабатываемого пакета, но она рассчитывается только для нескольких десятков байт заголовка, т.е. вычислительная нагрузка на маршрутизатор снижена.

О механизме расчета контрольной суммы: в IP не используется метод CRC, а применяется гораздо более примитивная защита – контрольная сумма заголовка рассчитывается как дополнение до единицы всех двухбайтовых слов заголовка. Следовательно, изменением пары подходящих бит заголовка можно добиться того, что заголовок поврежден, а контрольная сумма об этом не сигнализирует. Почему применен именно этот алгоритм? Вследствие его малой вычислительной сложности, в противовес высокой сложности алгоритма CRC. Авторы RFC791 декларировали, что впоследствии алгоритм вычисления контрольной суммы может быть изменен,

 

 This is a simple to compute checksum and experimental evidence indicates it is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience.

но как это сделать сейчас, когда огромное количество маршрутизаторов и узлов в Интернете используют именно старый алгоритм? Собственно никак .

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

 The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header.  For purposes of computing the checksum, the value of the checksum field is zero.

Переходим к рассмотрению двух последних слов заголовка:

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

 

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

  •  Маршрутизация
  •  Фрагментация

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

После рассмотренных 20 байт стационарный части заголовка могут следовать опции, их длина должна быть кратна 4-м байтам, т.к. длина заголовка описывается в 4-х байтовых словах, по той же причине их максимальное количество не может превысить 40 байт (60 -20 = 40).

Рассмотрим IP пакет:

Пле Type заголовка Ethernet принимает значение 08 00, указывая тем самым, что внутри данного кадра Ethernet находится IP пакет.

Пле Version = 4 и ничему другому не должно быть равно.

Поле IHL=5 и показывает, что дина заголовка составляет 5 четырехбайтовых слов, т.е. заголовок имеет длину 20 байт, следовательно, в данном пакете нет опций, как обычно и бывает в обычных IP пакетах. В«сыром» виде первый байт заголовка данного пакет равен 45 (что справедливо для большинства IP пакетов). Анализатор сам рассчитал длину заголовка в байтах исходя из значения IHL.

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

Поле Total Length. Длина пакета вместе с заголовком составляет 60 байт, из которых 20 байт – заголовок (IHL*4), следовательно в данном IP пакете 40 байт данных.

ID пакета – некое не имеющее самостоятельного смысла число, его анализ без учета других пакетов и фрагментов не имеет смысла.

Флаг DF не установлен – это значит лишь, что так захотело приложение (точнее, его автор). Флаг MF не установлен, следовательно, данный пакет – последний фрагмент (или единственный фрагмент).

Поле Offset=0, значит данный фрагмент – первый или единственный, по совокупности значений флага MF и поля Offset видно, что данный пакет является не фрагментированным, что в общем то и понятно из его очень малой длины.

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

Поле Protocol - анализатор сам показывает блок данных какого протокола находится внутри IP пакета, т.е. запоминать константы не имеет смысла.

Поле контрольной суммы - качественный анализатор сообщает нам, корректна ли контрольная сумма, так как пересчитывает ее.

Поле адресов явно воспроизводится анализатором.

Поле опций отсутствует, т.к. длина заголовка 20 байт.

Рассмотрим пакет, в котором присутствуют опции. Так как опции  в материале курса пока не изучались, рассмотрим пакет с полем опций что бы продемонстрировать как работает поле IHL. Для генерации пакета с опциями используется программа ping.exe и опцию RR. Пример:

Поле IHL=7, следовательно, длина заголовка пакета составляет 28 байт, а значение первого байта IP заголовка 47. Длина пакета 48 байт, из которых заголовок составляет 28 байт, следовательно, данных в пакете те же 40 байт, что и в прошлый раз. После стационарной части заголовка анализатор показывает, что дальше следуют опции.

Рассмотрим пакет, в котором поле опций имеет максимально возможную длину:

Поле IHL=F (15), следовательно, длина заголовка равна 60 байт, из которых 40 байт занимают опции. Поле Total Length = 100 байт, из которых 60 байт – заголовок IP пакета, следовательно данных снова таки 40 байт. Первый байт заголовка в этом случае 4F, и большего значения нежели F поле IHL принять не может, следовательно в этом пакета IP заголовок максимальной длины.

Следующее поле – TOS. Вообще то ping для Windows декларирует использование поля TOS, однако в Windows 2000 и Windows XP эта функция не работает – пакеты отправляются с полем TOS = 0. Можно отправить пакет любым средством, поддерживающим TOS или сгенерировать пакет с отличным от нуля полем TOS в анализаторе. Так же, пример пакета содержащего данное поле, присутствует в приложении к уроку (файл TOS_P.cap и TOS_T.cap).

Рассмотрим дамп, содержащий, пакет с TOS:

В данном случае значение TOS

010 – Immediate (немедленный)

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

Поле ID. 

 Значение поля 8565

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

Рассмотрим пример работы поля ID а также флагов и Offset при фрагментации пакетов.

Задания для самостоятельной работы.

Задание 1.

Разделить диапазон адресов 177.7.17.0 – 177.7.77.0 на CIDR блоки наиболее эффективно.

Разделить диапазон адресов 178.7.4.0 – 178.7.19.0 на CIDR блоки наиболее эффективно.

Разделить диапазон адресов 201.1.201.0 – 201.1.252.0 на CIDR блоки наиболее эффективно.

В последнем случае представить, что самый крупный из полученных блоков получил некоторый провайдер, и разделил эти адреса следующим образом:

  •  ¼ адресного пространства оставил для своих нужд
  •  ¼ адресного пространства выделил своему субпровайдеру
  •  1/8 адресного пространства зарезервировал
  •  1/8 часть выделил для dial-up клиентов
  •  1/8 часть отдал крупному клиенту
  •  1/8 часть использует для выделения небольшим клиентам, причем уже выделил сети размером 64, 64, 32 узла.

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

Задание 2. Проанализировать самостоятельно фрагментацию IP пакетов с помощью утилиты ping.exe и анализатора протоколов. Для этого необходимо послать с помощью утилиты ping.exe сильно фрагментированный пакет большой длинны и подвергнуть анализу поля ID, MF и Fragment Offset фрагментов с целью полностью понимать принципы фрагментации и сборки, не забывать, что поле Fragment Offset описывает смещение в 8-и байтовых словах.

 

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


 

А также другие работы, которые могут Вас заинтересовать

65090. Караунасы-никудерийцы и их роль в чагатайской истории 63.5 KB
  Никудерийцы и Дувахан Согласно завещанию Чингизхана улус его сына Чагатая распространялся от уйгурских земель на востоке до Амударьи на западе а на юге имел пределом индийские владения. После поражения Боракхана и подчинения ильханами дома...
65091. Клад серебряных монет первой четверти XV в. из Туркмении 88 KB
  Осенью 1997 г. в Москву были привезены для продажи коллекционерам 350 серебряных монет из большого клада, найденного незадолго до того в северной части Туркменистана. Владелец А.Алиев сообщил, что точное место находки ему неизвестно...
65093. ХУДОЖЕСТВЕННОЕ ОФОРМЛЕНИЕ МУСУЛЬМАНСКИХ МОНЕТ: НАРУШЕНИЕ ЗАПРЕТА? 137.5 KB
  Но если монеты античной Греции Рима эллинистического Востока обычно ассоциируются с прекрасными портретами конными экипажами образами богов и богинь то традиционно оформленные дирхемы и динары Арабского халифата а после его распада монеты многих его идеологических преемников...
65096. Клад из с. Новая Казанка Уральской области 159 KB
  Монетный состав клада, несмотря на его скромные размеры, довольно необычен и представляет научный интерес даже в таком составе. Монетные дворы, представленные в комплексе — Сарай ал-Махруса, Мохша, Сарай, Хорезм, Сарай ал-Джадид...
65097. «Железные псы» Батуидов (Шибан и его потомки в войнах XIII в.) 617 KB
  Согласно Рашид ад Дину и более поздним зависимым от него источникам Шибан 5 был пятым сыном Джучи Рашид ад Дин 1960 С. Старше Шибана по Рашид адДину были Орда Бату Берке и Беркечар. Несмотря на то что Рашид адДин в генеалогии Джучидов позиционирует Шибана пятым сыном...
65098. Буддизм в культуре Золотой Орды 288 KB
  Среди довольно обильных данных письменных источников, характеризующих конфессиональную ситуацию в Золотой Орде, сведения о буддизме единичны. По этой причине нередко даже специальные исследования религии и верований...