double arrow

Перекрытие адресных пространств

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

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

Пусть на некотором предприятии было принято решение обратиться к постав­щику услуг для получения пула адресов, достаточного для создания сети, струк­тура которой показана на рис. 18.14. Сеть клиента включает три подсети. Две из них — это внутренние сети отделов: сеть Ethernet на 600 пользователей и сеть Token Ring на 200 пользователей. Предприятие также предусматривает отдель­ную сеть на 10 узлов, главное назначение которой — предоставление информа­ции в режиме открытого доступа для потенциальных клиентов. Такого рода уча­стки корпоративной сети, в которых располагаются веб-серверы, FTP-серверы и другие источники публичной информации, называют демилитаризованной зо­ной (DeMilitarized Zone, DMZ). Еще одна сеть на два узла потребуется для связи с поставщиком услуг, общее число адресов, требуемых для адресации сетевых интерфейсов, составляет 812. Кроме того, необходимо, чтобы пул доступных ад­ресов включал для каждой из сетей широковещательные адреса, состоящие толь­ко из единиц, а также адреса, состоящие только из нулей. Учитывая также, что в любой сети адреса всех узлов должны иметь одинаковые префиксы, становится очевидным, что минимальное количество адресов, необходимое клиенту для по­строения задуманной сети, может значительно отличаться от значения 812, по­лученного простым суммированием.

В данном примере поставщик услуг решает выделить клиенту непрерывный пул из 1024 адресов. Значение 1024 выбрано как наиболее близкое к требуемому ко­личеству адресов, равному степени двойки (210 = 1024). Поставщик услуг выпол­няет поиск области такого размера в имеющемся у него адресном пространст­ве — 131.57.0.0/16, часть которого, как показано на рис. 18.15, уже распределена. Обозначим распределенные участки и владеющих ими клиентов — SI, S2 и S3. Поставщик услуг находит среди нераспределенных еще адресов непрерывный участок размером 1024 адреса, начальный адрес которого кратен размеру данно­го участка. Таким образом, наш клиент получает пул адресов 131.57.8.0/22, обо­значенный на рисунке через S.

Далее начинается самый сложный этап — распределение полученного от постав­щика услуг адресного пула S между четырьмя сетями клиента. Прежде всего, ад­министратор решил назначить для самой большой сети (Ethernet на 600 узлов) весь пул адресов 131.57.8.0/22, полученный от поставщика услуг (рис. 18.16).

Рис. 18.14. Сети поставщика услуг и клиента


Адресный пулS нового клиента 131.57.8.0/22 на 1024 узла
256 узлов (S1 -131.57.0.0/24) 256 узлов 256 узлов (S2 -131.57.2.0/24) 256 узлов 256 узлов 256 узлов 512 узлов (S3 -131.57.6.0/23)
Частично ^ распределенное адресное пространство

 


Рис. 18.15. Адресное пространство поставщика услуг

Token Ring (256-16-4 адресов)
Ethernet (1024-256 адресов)
>

Л

  шшшшшшш.   '00 I I 0000 0000
  f : 000010 I !оо 1111 1111
.131   000010 Ш 0000 0000
\ ■   000010 501 0001 0000 0001 1111
    000010;р1
    [ 000010 0010 00  
    ooooto;oi 0010 00  
    '"ллллал....... 1111 1111
    "VW tw  
ШИШ       0000 0000
        1111 1111
        0000 0000
        1111 1111
DMZ (16 адресов)

Соединительная сеть (4 адреса)

У


 


Рис. 18.16. Планирование адресного пространства для сетей клиента

Номер, назначенный для этой сети, совпадает с номером сети, полученным от поставщика услуг. А как же быть с оставшимися тремя сетями? Администратор учел, что для сети Ethernet требуется только 600 адресов, а из оставшихся 624 «выкроил» сеть Token Ring 131.57.9.0/24 на 250 адресов. Воспользовавшись тем, что для Token Ring требуется только 200 адресов, он «вырезал» из нее два участка: для DMZ-сети 131.57.9.16/28 на 16 адресов и для связывающей сети 131.57.9.32/30 на 4 адреса. В результате все сети клиента получили достаточное (а иногда и с избытком) количество адресов.

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

После конфигурирования сетевых интерфейсов должны быть созданы таблицы маршрутизации маршрутизаторов R1 и R2 клиента. Они могут быть сгенериро­ваны автоматически или с участием администратора. Ниже приведена таблица маршрутизатора R2 (табл. 18.11).

Таблица 18.11. Таблица маршрутизатора R2
Адрес назначения Маска Адрес следующего маршрутизатора Адрес выходно­го интерфейса Расстояние
131.57.8.0 255.255.252.0 131.57.8.2 131.57.8.2 Подключена
131.57.9.0 255.255.255.0 131.57.9.1 131.57.9.1 Подключена
131.57.9.16 255.255.255.240 131.57.8.1 131.57.8.2  
131.57.9.32 255.255.255.252 131.57.8.1 131.57.8.2  

131.57.8.1/22 600 узлов 10 узлов Сеть клиента - S Рис. 18.17. Сконфигурированная сеть клиента

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

Пусть, например, на маршрутизатор R2 поступает пакет с адресом назначения 131.57.9.29. В результате просмотра таблицы получаем следующие результаты для каждой строки:

□ (131.57.9.29) AND (255.255.252.0) = 131.57.8.0 - совпадение;

□ (131.57.9.29) AND (255.255.255.0) = 131.57.9.0 - совпадение;

□ (131.57.9.29) AND (255.255.255.240) - 131.57.9.16 - совпадение;

□ (131.57.9.29) AND (255.255.255.252) - 131.57.9.28 - нет совпадения.

Поскольку при наличии нескольких совпадений выбирается маршрут из той стро­ки, в которой совпадение адреса назначения с адресом из пакета имеет наиболь­шую длину, — определено, что пакет с адресом 131.57.9.29 направлен в DMZ-сеть.

CIDR

За последние несколько лет в Интернете многое изменилось: резко возросло число узлов и сетей, повысилась интенсивность трафика, изменился характер передавае­мых данных. Из-за несовершенства протоколов маршрутизации обмен сообщения­ми об обновлении таблиц стал приводить к сбоям магистральных маршрутизато­ров, происходящим из-за перегрузок при обработке большого объема служебной информации. Так, сегодня таблицы магистральных маршрутизаторов в Интернете могут содержать до нескольких сотен и даже тысяч маршрутов.

На решение этой проблемы направлена, в частности, и технология бесклассовой междоменной маршрутизации (Classless Inter-Domain Routing, CIDR).

Суть технологии СЮЯ заключается в следующем. Каждому поставщику услуг Интермета на­значается непрерывный диапазон IP-адресов. При таком подходе все адреса каждого по­ставщика. услуг имеют • общую стартуя* часть ~~ префикс, поэтому ^ршрутизация на магистралях Интернета можетосуществляться на основе префиксов, а не полных адресов сетей* А это значит, вместо множества запи$ей по: числу сетей будет достаточно поместить: одну запись сразу для всехсетей, имеющих общий префикс;! акое агрегирование адресов; позволит уменьшить объем таблиц в маршрутизаторах всех уровней, а следовательно, Уско­рить работу маршрутизаторов й повцсить пропускную способность Интернета.

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

Вместе с тем в процессе использования масок для разделения на подсети прояв­лялся и обратный эффект их применения — эффект объединения подсетей. Уп­рощенно говоря, для того чтобы направить весь суммарный трафик, адресован­ный из внешнего окружения в корпоративную сеть, разделенную на подсети, до­статочно, чтобы во всех внешних маршрутизаторах наличествовала одна строка. В этой строке на месте адреса назначения должен быть указан общий префикс для всех этих сетей. Здесь мы имеем дело с операцией, обратной разделению на подсети, — операцией агрегирования несколько сетей в одну более крупную (super- netting).

Вернемся к рис. 18.15, на котором показано адресное пространство поставщика услуг с участками SI, S2, S3 и S, переданными в пользование четырем клиентам. Этот пример также иллюстрирует рис. 18.18. В результате агрегирования сетей клиентов в табл. 18.12 маршрутизатора RISP поставщика услуг для каждого кли­ента будет выделено по одной строке независимо от количества подсетей, орга­низованных ими в своих сетях. Так, вместо четырех маршрутов к четырем сетям клиента S в таблице задан только один общий для всех них маршрут (выделен­ный жирным шрифтом).

Таблица 18.12. Таблица маршрутизатора RISP поставщика услуг
Адрес назначения Маска Следующиймаршрутизатор Номер выход­ного интерфейса Расстояние
131.57.0.0 (S1) 255.255.255.0 -   Подключена
131.57.2.0 (S2) 255.255.255.0 R3    
131.57.6.0 (S3) 255.255.254.0 R3    
131.57.8.0 (S) 255.255.252.0 -    
Маршрут по умолчанию 0.0.0.0 Rexternal   -

'Сеть S1 ; 131.57.0.0/24 • Ч II у',
2 узла I
/Сеть клиента S2 131.57.2.0/24
R1

■ w

DMZ
; Сеть клиента S3! \ 131.57.6.0/23
-вш
10 узлов

"600'узлов"

цщщщщщ

Etherne

WWW

200 узлов Token Ring

Сеть S нового клиента (131.57.8.0/22)


 


Рис. 18.18. Объединение подсетей

Итак, внедрение технологии CIDR позволяет решить две основные задачи.

□ Более экономное расходование адресного пространства. Благодаря технологии CIDR поставщики услуг получают возможность «нарезать» блоки из выде­ленного им адресного пространства в точном соответствии с требованиями каждого клиента, при этом у клиента остается пространство для маневра на случай будущего роста.

□ Уменьшение числа записей в таблицах маршрутизации за счет объединения маршрутов — одна запись в таблице маршрутизации может представлять большое количество сетей. Если все поставщики услуг Интернета будут при­держиваться стратегии CIDR, то особенно заметный выигрыш будет дости­гаться в магистральных маршрутизаторах.

Необходимы использования технологии CIDR является докали?

: зздия адо адресов, имеющих ceTmjpac-

полагаю^ по соседству«Только а таком случае трафик может быть :

. агрегирован^; ч.,.: ' ;v/y • •. '■■;Л!. ■. •

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

Технология CIDR уже успешно используется в текущей версии протокола IP (IPv4) и поддерживается такими протоколами маршрутизации, как OSPF, RIP-2, BGP4 (в основном магистральными маршрутизаторами Интернета). Особенно­сти применения технологии CIDR в новой версии протокола IP (IPv6) будут рассмотрены далее.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



Сейчас читают про: