1) На основе группировки портов.
 |
Стандарт 802.1q - добавили кадру (фреймов) Ethernet (16 бит - из низ 12-отведено под номер виртуальной сети (4096 может быть сетей),3- отдается под стандарт 820.1p позволяющий приоритетность кадров (фреймов), 1 – зарезервирован для другие сети). Приняли решение сократить на 16 бит размер полезной информации кадра.
|
|
|
|
|
|
|
1. Трафик входящего порта - раздает tag (vlan1,vlan2…)(Ingress Port)
2. Внутрисетевой трафик – коммутируется так же как и входящий, решение о принадлежности к той или иной виртуальной сети только на границах нашей сети. Progress traffic.
3. Egress traffic - трафик выходного порта. Смотрится tag которые были присвоены в самом начале.
Применение:
1)Псевдо-физическое отделение одного сегмента сети от другого.
Работа серверов
ервер создает детей, которые занимаются работой. После обработки дети удаляются после работы (через заданное количество установленных соединений оно самоуничтожается). Главный сервер следит за рождение новых детей. Если их становиться слишком много то он их удаляет. И поддерживает определенный диапазон детей.
Протокол ICMP (межсетевой прокол управляющих сообщений). Основные типы пакетов.
ICMP (Internet control message protocol) - межсетевой прокол управляющих сообщений. Протокол транспортного уровня, служит для передачи управляющей и диагностической информации для поддержания соединения на транспортном уровне.
0 тип | 7код | 15контрольная сумма 31 |
0-Ответ на запрос эха.
3- Адресат недоступен.
4- Подавление источника
5- перенаправление
8- запрос эха.
11- исчерпано время жизни
12- ошибка в параметре.
13- запрос временной метки.
14- ответ на запрос временной метке
Основные типы ICMP пакета:
Код - однобайтовой поле.
Контрольная сумма - посчитана для всего пакета, для проверки целостности информации.
В теле пакета содержаться заголовок IP сегмента который породил этот пакет и первые 8 байт порожденного сегмента.
|
|
|
|
|
 |
Предусмотрено использование других маршрутов. Или отправляет пакета типа 3.
Тип 4. Подавление источника. Если есть буфер для передачи на дальнейшую обработку. Если буфер переполнен то тот у кого заполнился буфер то отсылает обратно отправители и заглушает его.
5.Перенаправление. посылаеться источнику данных когда узел или шлюз когда источник может отправлять свои данные непосредственно через нужный шлюз.
8тип запрос эха - в тексте пакета содержаться текстовые данные произвольной длинны при получении от отсылает пакет типа 0 с данными полученные от исходного.
11тип-исчерпано время жизни. Посылается сообщение о том что время исчерпано, или исчерпано время на фрагментирование пакета.
Понятие IP-телефонии. Общий принцип действия телефонных серверов IP-телефонии.
Общий принцип действия телефонных серверов IP-телефонии таков: с одной стороны, сервер связан с телефонными линиями и может соединиться с любым телефоном мира. С другой стороны, сервер связан с Интернетом и может связаться с любым компьютером в мире. Сервер принимает стандартный телефонный сигнал, оцифровывает его (если он исходно не цифровой), значительно сжимает, разбивает на пакеты и отправляет через Интернет по назначению с использованием протокола Интернет (TCP/IP). Для пакетов, приходящих из Сети на телефонный сервер и уходящих в телефонную линию, операция происходит в обратном порядке. Обе составляющие операции (вход сигнала в телефонную сеть и его выход из телефонной сети) происходят практически одновременно, что позволяет обеспечить полнодуплексный разговор. На основе этих базовых операций можно построить много различных конфигураций. Допустим, звонок телефон-компьютер или компьютер-телефон может обеспечивать один телефонный сервер. Для организации связи телефон (факс)-телефон (факс) нужно два сервера.
Междугородняя (международная) связь осуществляется с помощью телефонных серверов, организация или оператор услуги должны иметь по серверу в тех местах, куда и откуда планируются звонки. Стоимость такой связи на порядок меньше стоимости телефонного звонка по обычным телефонным линиям. Особенно велика эта разница для международных переговоров.
Для организации телефонной связи по IP-сетям используется специальное оборудование - шлюзы IP-телефонии. Каждый шлюз должен быть соединен с телефонным аппаратом или абонентской линией АТС, пользователи которых будут являться абонентами IP-шлюза. Два абонента разных IP-шлюзов, разделенные расстоянием в тысячи километров, могут общаться в режиме реального времени, оплачивая только время подключения к IP-сети. С равным успехом IP-шлюз может использоваться и в корпоративной ЛВС.
Общий принцип действия телефонных шлюзов IP-телефонии таков: шлюз принимает телефонный сигнал, оцифровывает его, значительно сжимает, разбивает на пакеты и отправляет через IP-сеть по назначению. Определение и соединение с нужным шлюзом происходит по таблице маршрутизации, заполняемой через Web-интерфейс или telnet. Изменение/добавление/удаление IP-адреса возможно в любое время.
Наиболее экономичный способ организации выноса емкости УАТС в филиалы (например, связь центрального офиса с магазинами) - использование IP-шлюзов. Такое решение позволяет отказаться от оплаты абонентских линий ГТС и ограничиться лишь подключением филиала к сети передачи данных. В случае если филиалы расположены в разных городах, существенно снижаются и расходы на междугородную связь.
Еще одним способом применения IP-шлюзов является подключение к сети оператора IP-телефонии. В этом случае можно совершать вызовы на любые телефонные номера ТфОП. Стоимость звонка будет существенно дешевле, так как междугородние/международные тарифы операторов IP-телефонии существенно ниже тарифов операторов телефонной связи.
Кодеки G.711 фактически занимает поток 64.8 Кбит/с.
Менее распространенный G.723.1 ulawalow - у него сжатие 6,9 Кбит/с но реальная пропускная способность 17,1
Ulawalow - 5.9 а занимает 16
G..7-42.7
G.-18.7
Для передачи данных не требуется широкий канал. Эти цифры для одного потока, то есть если говорят двое, то умножается на 2.
Понятие IP-шлюза. Основные протоколы IP-телефонии.
Для связи IP - телефонии и обычной существуют гейты или шлюзы. Это аппаратная часть.
Шлюз отвечает за кодирование сигнала например с аналогового телефона (FXS) для разговора по IP-телефонии.
FXO - имеет же индикацию состояние трубки, и эмулирует состояние подключение к телефонной станции.
Asterisk - программный продукт который обладает преимущества - бесплатный, открытый код.
1720 TCP
1719 TCP используется для регистрации на гейткипере своей зоны. Занимается трансляцией адресов (телефонных номеров).
Основной протокол по которому сейчас по протокол SIP (работает по UDP по порту 5060).
RTP протокол- транспортного уровня, это протокол передает данные аудио и видео в режиме реального времени.
IAX2- протокол более навороченный чем SIP. Используется для связи нескольких Asterisk между собой.
DID Routes - маршруты прямого вызова. С помощью данной функции можно напрямую позвонить внутреннему абоненту/агенту/группе вызова с использованием механизма DID (при этом DID также должен поддерживаться городской телефонной станцией).
Протокол IPv6. Назначение. Особенности и преимущества. Коды приоритета.
IPv6 (Internet Protocol version 6) — это новая версия протокола IP, призванная решить проблемы, с которыми столкнулась предыдущая версия (IPv4) при её использовании в Internet, за счёт использования длины адреса 128 бит вместо 32. В настоящее время протокол IPv6 уже используется в нескольких сотнях сетей по всему миру, но пока ещё не получил столь широкого распространения в Интернете, как IPv4. По прогнозам, после того, как адресное пространство в IPv4 закончится (предположительно г.), произойдёт ситуация, когда два стека протоколов — IPv6 и IPv4 будут использоваться параллельно (dual stack), с постепенным увеличением доли трафика IPv6 по сравнению с IPv4. Такая ситуация станет возможной из-за наличия огромного количества устройств, в том числе устаревших, не поддерживающих IPv6 и требующих специального преобразования для работы с устройствами, использующими только IPv6.
Развитие IPv6
Протокол IPv4 в настоящее время столкнулся с рядом проблем, таких как проблема масштабируемости сети, неприспособленность протокола к передаче мультисервисной информации с поддержкой различных классов обслуживания, включая обеспечение информационной безопасности. Указанные проблемы обусловили развитие классической версии протокола IPv4 в направлении разработки версии IPv6. При этом к проблемам масштабируемости протокола IPv4 следует отнести следующие:
· недостаточность объёма 32-битного адресного пространства;
· сложность агрегирования маршрутов, разрастание таблиц маршрутизации;
· сложность массового изменения IP-адресов;
· относительная сложность обработки заголовков пакетов IPv4.
Инновации IPv6 в отличие от IPv4 состоят в следующем:
· упрощен стандартный заголовок IP-пакета;
· изменено представление необязательных полей заголовка;
· расширено адресное пространство;
· улучшена поддержка иерархической адресации, агрегирования маршрутов и автоматического конфигурирования адресов;
· введены механизмы аутентификации и шифрования на уровне IP-пакетов;
· введены метки потоков данных.
При этом в IPv6 все изменения планировались таким образом, чтобы минимизировать изменения на других уровнях протокольного стека TCP/IP. В результате размер IP-адреса увеличен до 128 бит. Обеспечена возможность простого и гибкого автоматического конфигурирования адресов для сетей произвольного масштаба и сложности. IPv6 остался расширяемым протоколом, причём поля расширений (дополнительные заголовки) могут добавляться без снижения эффективности маршрутизации.
Метки потоков
Введение в протоколе IPv6 поля «Метка потока» позволяет значительно упростить процедуру маршрутизации однородного потока пакетов. Поток - это последовательность пакетов, посылаемых отправителем определённому адресату. При этом предполагается, что все пакеты данного потока должны быть подвергнуты определённой обработке. Характер данной обработки задаётся дополнительными заголовками.
Допускается существование нескольких потоков между отправителем и получателем. Метка потока присваивается узлом-отправителем путём генерации псевдослучайного 24-битного числа. Все пакеты одного потока должны иметь одинаковые заголовки, обрабатываемые маршрутизатором.
При получении первого пакета с меткой потока маршрутизатор анализирует дополнительные заголовки, выполняет предписанные этими заголовками функции и запоминает результаты обработки (адрес следующего узла, опции заголовка переходов, перемещение адресов в заголовке маршрутизации и т. д.) в локальном кэше. Ключом для такой записи является комбинация адреса источника и метки потока. Последующие пакеты с той же комбинацией адреса источника и метки потока обрабатываются с учётом информации кэша без детального анализа всех полей заголовка.
Время жизни записи в кэше составляет не более 6 секунд, даже если пакеты этого потока продолжают поступать. При обнулении записи в кэше и получении следующего пакета потока, пакет обрабатывается в обычном режиме и для него происходит новое формирование записи в кэше. Следует отметить, что указанное время жизни потока может быть явно определено узлом отправителем с помощью протокола управления или опций заголовка переходов, и может превышать 6 секунд.
Приоритезация пакетов обеспечивается маршрутизаторами на основе поля приоритета. Данное 4-битное поле содержит код требуемого приоритета.
Множество значений этого поля разделено на два подмножества:
· от 0 до 7 — трафик с контролем перегрузки (например, протокол TCP снижает трафик при получении сигнала перегрузки);
· от 8 до 15 — трафик без контроля перегрузки (приложения реального времени с постоянной скоростью).
Разработчики IPv6 рекомендуют использовать для определённых категорий приложений, управляющих сигналами перегрузки, следующие коды приоритета:
Код приоритета Назначение
0 Нехарактеризованный трафик
1 Заполняющий трафик (сетевые новости)
2 Несущественный информационный трафик (электронная почта)
3 Резерв
4 Существенный трафик (FTP, HTTP, NFS)
5 Резерв
6 Интерактивный трафик (Telnet, X-terminal, SSH)
7 Управляющий трафик (Маршрутная информация, SNMP)
Для приложений, скоростью передачи которых невозможно управлять, разработчики определяют, что большему значению кода соответствует более высокий приоритет. Для кода 8 установлено низшее значение приоритета, и он применяется для трафика, часть данных которого можно отбросить, например, потоковое видео высокого качества. Значение 15 следует применять для трафика с фиксированной скоростью, чувствительного к задержкам и потерям, например, трафик речевых кодеков с минимальной избыточностью.
Следует отметить, что трафик с возможностью управления перегрузками (0—7) и без неё (8—15) обрабатываются маршрутизаторами независимо, то есть не существует взаимного соответствия между приоритетами данных видов трафика. Обеспечение безопасности в протоколе IPv6 осуществляется с использованием протокола IPSec, поддержка которого является обязательной для данной версии протокола.
Организация адресации с использованием протокола IPv6.
Существуют различные типы адресов IPv6: одноадресные (Unicast), групповые (Anycast) и многоадресные (Multicast).
Адреса типа Unicast хорошо всем известны. Пакет, посланный на такой адрес, достигает в точности интерфейса, который этому адресу соответствует.
Адреса типа Anycast синтаксически неотличимы от адресов Unicast, но они адресуют группу интерфейсов. Пакет, направленный такому адресу, попадёт в ближайший (согласно метрике маршрутизатора) интерфейс. Адреса Anycast могут использоваться только маршрутизаторами.
Адреса типа Multicast идентифицируют группу интерфейсов. Пакет, посланный на такой адрес, достигнет всех интерфейсов, привязанных к группе многоадресного вещания.
Широковещательные адреса IPv4 (обычно xxx. xxx. xxx.255) выражаются адресами многоадресного вещания IPv6.
Зарезервированные адреса IPv6
Адреса IPv6 отображаются как 8 групп шестнадцатеричных цифр, разделенных двоеточием. Например, 7628:0d18:11a3:09d7:1f34:8a2e:07a0:765d.
Если одна или более групп подряд равны 0000, то они могут быть опущены и заменены на двойное двоеточие (::).
Например, 7628:0000:0000:0000:0000:0000:ae21:ad12
может быть сокращен до7628::ae21:ad12, или
0000:0000:0000:0000:0000:0000:ae21:ad12
может быть сокращен до::ae21:ad12.
Сокращению не могут быть подвергнуты 2 разделенные нулевые группы из-за возникновения неоднозначности.
Протокол DHCP. Назначение, структура, принципы архитектуры и формат сообщений.
Протокол DHCP был предложен в 1993 г., его развитием занимается специальная рабочая группа (DHC WG), входящая в состав IETF. Наиболее полное современное описание DHCP содержится в документе RFC 2131 (март 1997 г.), который пришел на смену более ранним редакциям RFC 1531 и 1541. В настоящее время DHCP имеет статус предварительного стандарта.
DHCP появился не на пустом месте - различные схемы управления IP-адресами в сетевой среде предлагались и раньше. Однако эти схемы имеют по крайней мере один из двух недостатков - не допускают динамического назначения IP-адресов либо позволяют передавать от сервера на станцию-клиент лишь небольшое число параметров конфигурации.
При разработке протокола DHCP преследовалась цель устранить оба ограничения. Требовался механизм, который позволил бы ликвидировать стадию ручного конфигурирования компьютеров, поддерживал многосегментные сети, не требуя наличия DHCP-сервера в каждой подсети, не конфликтовал с существующими сетевыми протоколами и компьютерами, имеющими статичную конфигурацию, был способен взаимодействовать с ретранслирующими агентами протокола BOOTP и обслуживать BOOTP-клиентов, наконец, допускал управление передаваемыми параметрами конфигурации. Что касается более узких задач, то DHCP должен был обеспечивать уникальность сетевых адресов, используемых разными компьютерами сети в данный момент, сохранение прежней конфигурации клиентской станции после перезагрузки клиента или сервера, автоматическое присвоение параметров конфигурации вновь подключенным машинам.
Поле | Описание |
op | Тип сообщения (1 = BOOTREQUEST, 2 = BOOTREPLY) |
htype | Тип адреса оборудования |
hlen | Длина адреса оборудования |
hops | Используется ретранслирующим агентом |
xid | Идентификатор транзакции между сервером и клиентом |
secs | Время с момента выдачи DHCPREQUEST или начала обновления конфигурации |
flags | Флаги (первый бит маркирует широковещательные сообщения) |
ciaddr | IP-адрес клиента |
yiaddr | <Ваш> (клиентский) IP-адрес |
siaddr | IP-адрес следующего сервера, участвующего в загрузке |
giaddr | IP-адрес ретранслирующего агента |
chaddr | <Аппаратный> адрес клиента |
sname | Хост-имя сервера (опция) |
file | Имя загрузочного файла |
options | Поле дополнительных параметров |
Принципы архитектуры и формат сообщений
Работа протокола DHCP базируется на классической схеме клиент-сервер. В роли клиентов выступают компьютеры сети, стремящиеся получить IP-адреса в так называемую аренду (lease), а DHCP-серверы выполняют функции диспетчеров, которые выдают адреса, контролируют их использование и сообщают клиентам требуемые параметры конфигурации. Сервер поддерживает пул свободных адресов и, кроме того, ведет собственную регистрационную базу данных. Взаимодействие DHCP-серверов со станциями-клиентами осуществляется путем обмена сообщениями.
Рис. 1. Формат сообщения DHCP (в скобках - размер поля в байтах)
Упомянутое выше требование поддержки базовых элементов протокола BOOTP возникло не случайно. DHCP разрабатывался как непосредственное расширение BOOTP и именно в таком качестве воспринимается BOOTP-клиентами. Этому обстоятельству в первую очередь способствует формат сообщений DHCP, во многом совпадающий с форматом, который применяется протоколом-предшественником и определен в документе RFC 951 (рис. 1).
Сравнивая протоколы BOOTP и DHCP, нельзя не отметить появления в DHCP новых услуг. Во-первых, в этом протоколе предусмотрен механизм автоматической выдачи IP-адресов во временное пользование с возможностью их последующего присвоения новым клиентам. Во-вторых, клиент может получить от сервера все параметры конфигурации, которые ему необходимы для успешного функционирования в IP-сети.
Указанные отличия потребовали частичного расширения формата сообщений. Так, в нем появилось отдельное поле идентификатора клиента, сделана более прозрачной интерпретация адреса сервера (поле siaddr), переменный размер получило поле options, используемое, в частности, для передачи параметров конфигурации (его длина обычно находится в диапазоне 312-576 байт, хотя возможно и дополнительное расширение этого поля за счет полей sname и file).
В роли транспортного протокола для обмена DHCP-сообщениями выступает UDP. При отправке сообщения с клиента на сервер используется 67-й порт DHCP-сервера, при передаче в обратном направлении - 68-й. Эти номера портов, как и схожая структура сообщений, обеспечивают обратную совместимость DHCP с BOOTP. Конкретные процедуры взаимодействия клиентов и серверов BOOTP и DHCP регламентирует документ RFC 1542.
Механизмы выделения адресов в протоколе DHCP. Последовательность событий при выделении IP-адреса.
Протокол DHCP поддерживает три механизма выделения адресов: автоматический, динамический и ручной. В первом случае клиент получает постоянный IP-адрес, в последнем DHCP используется только для уведомления клиента об адресе, который администратор присвоил ему вручную. Оба эти варианта не таят в себе чего-либо принципиально нового, а вот динамический механизм заслуживает детального рассмотрения.
Выдача адреса в аренду производится по запросу клиента. DHCP-сервер (или группа серверов) гарантирует, что выделенный адрес до истечения срока его аренды не будет выдан другому клиенту; при повторных обращениях сервер старается предложить клиенту адрес, которым тот пользовался ранее. Со своей стороны, клиент может запросить пролонгацию срока аренды адреса либо, наоборот, досрочно отказаться от него. Протоколом предусмотрена также выдача IP-адреса в неограниченное пользование. При острой нехватке адресов сервер может сократить срок аренды адреса по сравнению с запрошенным.
Рис. 2. Последовательность событий при выделении IP-адреса
Выдача нового адреса. Последовательность событий в этом случае такова (рис. 2).
1. Клиент посылает в собственную физическую подсеть широковещательное сообщение DHCPDISCOVER, в котором могут указываться устраивающие клиента IP-адрес и срок его аренды. Если в данной подсети DHCP-сервер отсутствует, сообщение будет передано в другие подсети ретранслирующими агентами протокола BOOTP (они же вернут клиенту ответные сообщения сервера).
2. Любой из DHCP-серверов может ответить на поступившее сообщение DHCPDISCOVER сообщением DHCPOFFER, включив в него доступный IP-адрес (yiaddr) и, если требуется, параметры конфигурации клиента. На этой стадии сервер не обязан резервировать указанный адрес. В принципе, он имеет право предложить его другому клиенту, также отправившему запрос DHCPDISCOVER. Тем не менее спецификации RFC 2131 рекомендуют серверу без необходимости не применять подобную тактику, а кроме того, убедиться (например, выдав эхо-запрос ICMP) в том, что предложенный адрес в текущий момент не используется каким-либо из компьютеров сети.
3. Клиент не обязан реагировать на первое же поступившее предложение. Допускается, чтобы он дождался откликов от нескольких серверов и, остановившись на одном из предложений, отправил в сеть широковещательное сообщение DHCPREQUEST. В нем содержатся идентификатор выбранного сервера и, возможно, желательные значения запрашиваемых параметров конфигурации.
Не исключено, что клиента не устроит ни одно из серверных предложений. Тогда вместо DHCPREQUEST он снова выдаст в сеть запрос DHCPDISCOVER, а серверы так и не узнают, что их предложения отклонены. Именно по этой причине сервер не обязан резервировать помещенный в DHCPOFFER адрес.
Если в процессе ожидания серверных откликов на DHCPDISCOVER достигнут тайм-аут, клиент выдает данное сообщение повторно.
4. Присутствующий в сообщении DHCPREQUEST идентификатор позволяет соответствующему DHCP-серверу убедиться в том, что клиент принял именно его предложение. В ответ сервер отправляет подтверждение DHCPACK, содержащее значения требуемых параметров конфигурации, и производит соответствующую запись в базу данных.
Если к моменту поступления сообщения DHCPREQUEST предложенный адрес уже <ушел> к другому клиенту (например, первая станция слишком долго <размышляла> над поступившими предложениями), сервер отвечает сообщением DHCPNACK.
5. Получив сообщение DHCPACK, клиент обязан убедиться в уникальности IP-адреса (средствами протокола ARP) и зафиксировать суммарный срок его аренды. Последний рассчитывается как время, прошедшее между отправкой сообщения DHCPREQUEST и приемом ответного сообщения DHCPACK, плюс срок аренды, указанный в DHCPACK.
Обнаружив, что адрес уже используется другой станцией, клиент обязан отправить серверу сообщение DHCPDECLINE и не ранее чем через 10 с начать всю процедуру снова. Процесс конфигурирования возобновляется и при получении серверного сообщения DHCPNACK.
При достижении тайм-аута в процессе ожидания серверных откликов на сообщение DHCPREQUEST клиент выдает его повторно.
6. Для досрочного прекращения аренды адреса клиент отправляет серверу сообщение DHCPRELEASE.
Приведенная последовательность действий заметно упрощается, если станция-клиент желает повторно работать с IP-адресом, который когда-то уже был ей выделен. В этом случае первым отправляемым сообщением является DHCPREQUEST, в котором клиент указывает прежде использовавшийся адрес. В ответ он может получить сообщение DHCPACK или DHCPNACK (если адрес занят либо клиентский запрос является некорректным, например из-за перемещения клиента в другую подсеть). Обязанность проверить уникальность IP-адреса опять-таки возлагается на клиента
Выбор адреса DHCP-сервером. Если на момент получения запроса DHCPDISCOVER сервер не располагает свободными IP-адресами, он может направить уведомление о возникшей проблеме администратору. В противном случае при выборе адреса обычно применяется следующий алгоритм. Клиенту выделяется адрес, записанный за ним в данный момент. Если это невозможно, сервер предложит адрес, которым пользовался клиент до окончания срока последней аренды (при условии, что данный адрес свободен), либо адрес, запрошенный самим клиентом при помощи соответствующей опции (опять же, если адрес не занят). Наконец, в том случае, когда все предыдущие варианты не проходят, новый адрес выбирается из пула доступных адресов с учетом подсети, из которой поступил клиентский запрос.
Исходя из определенной сетевым администратором политики сервер может выдать клиенту адрес, отличающийся от запрошенного (даже при доступности последнего), вообще отказать в предоставлении адреса или предложить адрес, относящийся к другой подсети. Более того, DHCP-сервер вообще не обязан реагировать на каждый поступивший запрос DHCPDISCOVER. Это предоставляет администратору возможность контролировать доступ к сети, например разрешив серверу отвечать только тем клиентам, которые предварительно зарегистрировались с помощью специальной процедуры.
Истечение срока аренды. По мере того как срок аренды подходит к концу, клиент может завершить работу с данным адресом, отправив на DHCP-сервер сообщение DHCPRELEASE, либо заблаговременно запросить продление срока аренды. В первом случае возвращение в сеть потребует выполнения всей процедуры инициализации заново. Во втором - станция продолжит функционировать в сети без видимого замедления работы пользовательских приложений.
При пролонгировании аренды клиент проходит два состояния - обновления адреса (RENEWING) и обновления конфигурации (REBINDING). Первое наступает примерно на половине срока аренды адреса (так называемый момент T1), второе - по истечении приблизительно 7/8 полного времени аренды (момент T2); для рассинхронизации процессов реконфигурирования разных клиентов значения этих временных меток рандомизируются с помощью случайной добавки.
В момент T1 клиент оправляет DHCP-серверу, выдавшему адрес, сообщение DHCPREQUEST с просьбой продлить срок аренды. Получив положительный ответ (DHCPACK), клиент пересчитывает срок аренды и продолжает работу в обычном режиме. Клиент ожидает прихода ответа от сервера в течение (T2 - t)/2 с (при условии, что это значение не меньше 60 с), где t - время отсылки последнего сообщения DHCPREQUEST, после чего отправляет данное сообщение повторно.
Если ответ от сервера не поступил к моменту T2, клиент переходит в состояние REBINDING и передает уже широковещательное сообщение DHCPREQUEST со своим текущим сетевым адресом. В этом случае моменты повторных выдач запросов DHCPREQUEST рассчитываются аналогично предыдущему случаю, только вместо T2 фигурирует время окончания срока аренды.
Не исключено, однако, что ответ DHCPACK не придет до окончания срока аренды. Тогда клиент обязан немедленно прекратить выполнение любых сетевых операций и заново начать процесс инициализации. Если запоздавший ответ DHCPACK все-таки поступит, клиенту рекомендуется сразу же возобновить работу под прежним адресом.
Параметры сетевой конфигурации. Особенности работы. Недостатки протокола DHCP.
Хранение параметров сетевой конфигурации станций-клиентов является второй услугой, предоставляемой DHCP-сервером. В создаваемой базе данных на каждого клиента заводится отдельная запись с уникальным ключом-идентификатором и строкой конфигурационных параметров.
Роль идентификатора может играть пара <номер подсети IP, аппаратный адрес>, которая позволит использовать аппаратный адрес сразу в нескольких подсетях, либо пара <номер подсети IP, имя хост-компьютера>, позволяющая серверу взаимодействовать с клиентом, перемещенным в другую подсеть.
Что касается собственно параметров конфигурации, то их набор, поддерживаемый протоколом DHCP, определен в спецификациях RFC 1122, 1123, 1196 и 1256. В него входят выданный адрес, срок его аренды, назначавшиеся ранее адреса, а также максимальный размер реассемблируемого пакета, перечень фильтров для нелокальной маршрутизации от источника, адрес, используемый в широковещательных пакетах, параметры статических маршрутов и т. д. Впрочем, из всей совокупности допустимых параметров (а их более 30) в процессе инициализации могут передаваться только те, которые действительно необходимы для работы клиента либо определяются спецификой конкретной подсети.
Редукция объема передаваемых сведений о конфигурации достигается двумя способами. Во-первых, для большей части параметров в упомянутых выше документах RFC определены значения, принимаемые по умолчанию. Клиент будет использовать их, если в сообщении, поступившем от сервера, какие-то параметры опущены. Во-вторых, отправляя сообщение DHCPDISCOVER или DHCPREQUEST, клиентская станция может явно указать в нем параметры, значения которых она хотела бы получить.
Очевидно, что в обоих случаях передача параметров конфигурации осуществляется в ходе основной процедуры выделения IP-адреса. Возможен, однако, случай, когда клиент уже имеет IP-адрес (например, он был задан вручную). Тогда он может выдать сообщение DHCPINFORM*, содержащее уже имеющийся адрес и запрос об отдельных параметрах конфигурации. Получив это сообщение, DHCP-сервер проверяет правильность адреса клиента (но не наличие аренды) и направляет ему сообщение DHCPACK с требуемыми параметрами конфигурации.
Отметим одно логическое противоречие, с которым связано применение протокола DHCP. Алгоритм выделения IP-адреса компьютеру сети предполагает, что установленное на нем программное обеспечение TCP/IP в состоянии воспринимать адресованные ему посредством <аппаратного> адреса IP-пакеты и транслировать их на IP-уровень еще до того, как станция получит свой IP-адрес, а сами средства TCP/IP будут полностью сконфигурированы. Такая возможность, очевидно, существует не всегда. Для работы с клиентами, не способными корректно обрабатывать одноадресные IP-дейтаграммы, используется поле flags. Такие клиенты должны установить первый бит данного поля в единичное значение, тем самым указав серверу на необходимость отправки в соответствующую подсеть только широковещательных сообщений.
Недостатки DHCP
Освобождая сетевых администраторов от множества рутинных операций, DHCP оставляет нерешенными ряд проблем, которые рано или поздно могут возникнуть в реальной сетевой среде.
К недостаткам этого протокола прежде всего следует отнести крайне низкий уровень информационной безопасности, что обусловлено непосредственным использованием протоколов UDP и IP. В настоящее время не существует практически никакой защиты от появления в сети несанкционированных DHCP-серверов, способных рассылать клиентам ошибочную или потенциально опасную информацию - некорректные или уже задействованные IP-адреса, неверные сведения о маршрутизации и т. д. И наоборот, клиенты, запущенные с неблаговидными целями, могут извлекать конфигурационные сведения, предназначенные для <законных> компьютеров сети, и тем самым оттягивать на себя значительную часть имеющихся ресурсов. Понятно, что возможности административного ограничения доступа, о которых говорилось выше, не способны закрыть эту брешь в системе информационной безопасности.
По мнению некоторых экспертов, в настоящее время DHCP недостаточно отказоустойчив. Протоколу явно недостает механизма активного уведомления клиентов об экстремальных ситуациях (например, о систематической нехватке адресов) и серверного подтверждения об освобождении адреса, иногда в сети наблюдаются всплески числа запросов на повторное использование адресов и т. д. Впрочем, работа над протоколом еще не завершена, и не исключено, что некоторые недостатки будут устранены в последующих редакциях.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 |
