Бабич А.В. Оргранизация информационных сетей: Учебное пособие

Подождите немного. Документ загружается.

111

CLI Router(config)interface serial0

Router(config-if)encapsulation frame-relay [ietf]

Router(config-if)no ip address

Router(config-if)interface serial0.1 point-to-point

Router(config-subif)frame-relay interface-dlci DLCI

Router(config-fr-dlci)exit

Router(config-subif)ip address адрес маска

Router(config-subif)interface serial0.2 point-to-point

Router(config-subif)frame-relay interface-dlci DLCI

Router(config-fr-dlci)exit

Router(config-subif)ip address адрес маска

... и так далее для всех подинтерфейсов

В данном примере в качестве основного интерфейса использовал-

ся serial0. Подинтерфейс идентифицируется числом, добавляемым к

номеру основного интерфейса через точку (например, serial0.1); числа

могут быть произвольными и не обязаны следовать по порядку.

Смешанный дизайн

На рисунке 24 изображен смешанный дизайн сети, где два PVC

терминируются в одном IP-интерфейсе, а третий PVC терминируется

в своем собственном IP-интерфейсе. Соответствующий граф IP-сетей

показан на том же рисунке справа.

Рис. 24. Смешанный дизайн

В этом случае для IP-сети маршрутизатора В создается подин-

терфейс типа point-to-point, а для сетей маршрутизаторов C и D —

подинтерфейс point-to-multipoint.

Подинтерфейс point-to-multipoint ведет себя так же, как основ-

ной интерфейс, в плане использования протокола InARP или запол-

112

нения карты. Однако если на основном интерфейсе мы могли не

перечилять PVC, подключенные к интерфейсу, так как этот список

сообщал нам коммутатор, то в случае с подинтерфейсом point-to-

multipoint мы должны указать подключенные к подинтерфейсу DLCI,

иначе маршрутизатор не сможет определить, какие именно из PVC,

подключенных к основному интерфейсу, необходимо сгруппировать

в подинтерфейс. Конфигурация подинтерфейса point-to-multipoint:

CLI Router(config)interface serial0.1 multipoint

Router(config-subif)frame-relay interface-dlci DLCI

Router(config-fr-dlci)exit

... повторить для всех DLCI, подключенных к подинтерфейсу

Router(config-subif)ip address адрес маска

... при необходимости составить frame-relay map вручную

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

выше способы организации работы протокола IP на каналах Frame

Relay имеют значение только для абонентов сети (устройств DTE).

Более того, все эти способы применялись физически к одной и той

же FR-сети. Для оператора связи (DCE) вся эта деятельность не име-

ет никакого значения: оператор работает только на уровне коммута-

ции кадров на основании номеров DLCI и все три рассмотренных

дизайна с его точки зрения совершенно идентичны, равно как и пе-

реход от одного дизайна к другому для оператора связи невидим и

не имеет значения.

§7. Проверка настроек

Следующие команды полезны для получения информации и от-

ладки Frame Relay.

CLI Routershow interface serial номер[.номер]

Команда, в частности, выводит следующие сведения:

состояние интерфейса, x

используемый протокол 2-го уровня (Frame Relay), x

тип инкапсуляции данных в кадры FR (если не указан, то Cisco), x

тип LMI (если не указан, то Cisco), x

DLCI, используемый для LMI, x

число отправленных и полученных статусных LMI-сообщений x

(эти числа должны быть близки),

период посылки статусных сообщений (keepalive). x

113

CLI Routershow frame-relay pvc [DLCI] [interface интерфейс]

Команда выводит статус указанного PVC и различные сведения

о нем. Если DLCI не указан, но выводятся сведения о всех PVC, под-

ключенных ко всем интерфейсам FR. Если указан интерфейс, то

выводятся сведения о PVC, подключенным к данному интерфейсу.

Статус PVC выражается двумя категориями: собственно PVC

STATUS и DLCI USAGE.

PVC STATUS информирует о состоянии виртуального канала

между данным маршрутизатором и удаленным DTE. Возможные

значения:

Active — канал установлен. x

Inactive — канал не функционирует (причиной этого могут быть x

отсутствие или неверная конфигурация удаленного DTE).

Deleted — данный PVC сконфигурирован на DTE (командой x

frame-relay interface-dlci или frame-relay map), но не сконфигу-

рирован на DCE (отсутствует или ошибочна команда connect).

Static — данный PVC сконфигурирован на DTE, но LMI отклю- x

чен, поэтому получить информацию от DCE о статусе данного

PVC невозможно. Эта ситуация может возникнуть при установ-

лении FR-соединений DTE-DTE (back-to-back) без участия ком-

мутатора — чтобы такие соединения работали, LMI отключается

командой no keepalive.

DLCI USAGE показывает, как данный PVC используется марш-

рутизатором. Значения:

Local — данный PVC терминируется на одном из (под)интерфей- x

сов.

Switched — маршрутизатор является FR-коммутатором и дан- x

ный PVC является транзитным.

Unused — данный PVC не терминируется никаким интерфейсом x

и не является транзитным (причиной этого является неверная

или незаконченная конфигурация DTE или DCE).

CLI Routershow frame-relay map

Команда выводит список DLCI и соответствующих им IP-адресов.

Наполнение карты производится протоколом InARP или командами

frame-relay map. PVC типа «точка-точка» для полноты картины тоже

вносятся в карту. Таким образом, движение IP-трафика возможно

только по тем PVC, DLCI которых указаны в карте.

114

CLI Routershow frame-relay lmi [интерфейс]

Команда выводит сведения о работе LMI для указанного FR-

интерфейса (или для всех интерфейсов, если интерфейс не указан).

В частности, можно определить тип LMI, тип интерфейса (FR DTE/

DCE) и число отправленных/полученных через этот интерфейс ста-

тусных запросов («Status Enq.») и ответов («Status msgs»). В нор-

мально функционирующей сети число отправленных сообщений

одного типа и число полученных сообщений противоположного типа

должны быть очень близки.

Команды вывода отладочной информации, позволяющие следить

за обменом FR-сообщениями, приведены ниже:

CLI Routerdebug frame-relay packet [interface интерфейс

[dlci DLCI]]

Routerdebug frame-relay lmi

Резюме

Frame relay — протокол канального уровня сетевой модели OSI.

Служба коммутации пакетов Frame Relay в настоящее время широко

распространена во всем мире. Максимальная скорость, допускаемая

протоколом FR, — 34.368 мегабит/с. (каналы E3). Коммутация:

точка-точка.

Frame Relay был создан в начале 1990-х в качестве замены прото-

колу X.25 для быстрых надежных каналов связи, технология FR архи-

тектурно основывалась на X.25 и во многом сходна с этим протоколом,

однако в отличие от X.25, рассчитанного на линии с достаточно высо-

кой частотой ошибок, FR изначально ориентировался на физические

линии с низкой частотой ошибок, и поэтому большая часть механизмов

коррекции ошибок X.25 в состав стандарта FR не вошла.

Frame relay обеспечивает множество независимых виртуальных

каналов (Virtual Circuits, VC) в одной линии связи, идентифицируе-

мых в FR-сети по идентификаторам подключения к соединению

(Data Link Connection Identifier, DLCI). Вместо средств управления

потоком включает функции извещения о перегрузках в сети. Воз-

можно назначение минимальной гарантированной скорости (CIR)

для каждого виртуального канала.

В основном применяется при построении территориально рас-

пределенных корпоративных сетей, а также в составе решений, свя-

115

занных с обеспечением гарантированной пропускной способности

канала передачи данных (VoIP, видеоконференции и т. п.).

Вопросы и тестовые задания для контроля

1. В случае возникновения затора в сети Frame Relay для оповеще-

ния конечных устройств о заторе используется:

бит DE;a)

бит FECN;b)

бит BECN;c)

поле FCS;d)

специальные служебные пакеты notification.e)

2. В случае если скорость отправки фреймов конечным устройством

превышает скорость CIR:

фреймы отбрасываются коммутатором Frame Relay;a)

фреймы маркируются битом DE;b)

фреймы маркируются битами FECN и BECN.c)

3. Виртуальные (VC) каналы в Frame Relay бывают:

постоянные виртуальные каналы (PVC);a)

коммутируемые виртуальные каналы (SVC);b)

стандартные виртуальные каналы (SVC);c)

быстрые виртуальные каналы (FVC).d)

4. Для автоматического определения текущего статуса PVC исполь-

зуется:

коммутируемые виртуальные каналы (SVC);a)

LMI;b)

ARP;c)

бит DE.d)

5. Размер поля DLCI во фрейме Frame Relay равен:

2 бита;a)

5 бит;b)

10 бит;c)

128 бит;d)

32 бита.e)

116

глаВа 8. ПРотокол PPP

Детально рассмотрены протокол PPP, основные принципы рабо-

ты протокола, его ключевые функциональные блоки, а также прото-

колы аутентификации PAP и CHAP.

Ключевые слова: LCP, NCP, CHAP, PAP, HDLC, аутентификация.

§1. обзор протокола PPP

PPP (Point-to-Point Protocol) — это набор стандартных протоко-

лов, позволяющих программам удаленного доступа различных раз-

работчиков взаимодействовать друг с другом. Подключение PPP

обеспечивает связь с удаленными сетями через стандартный PPP-

сервер. Протокол PPP также позволяет серверу удаленного доступа

принимать входящие вызовы от программ удаленного доступа дру-

гих разработчиков, поддерживающих PPP, и обеспечивать сетевой

доступ к таким программам.

Как правило, в сеансе протокола РРР имеется четыре фазы:

Установление соединения. x

Проверка подлинности пользователя (необязательная фаза). x

Фаза переговоров. x

Завершение соединения. x

Во время этих четырех фаз в протоколе РРР используется еще

несколько различных протоколов. Ядром протокола РРР является

протокол передачи кадров, в который включаются кадры РРР для их

дальнейшей передачи через обычное модемное соединение. Имеется

в виду протокол высокого уровня управления каналом передачи

данных (High-Level Data Link Control Protocol — HDLC).

Прежде чем данные будут переданы по телефонной линии, меж-

ду двумя устройствами на концах линии должно быть установлено

соединение. При установке соединения в РРР используется специ-

альный протокол — протокол управления соединением (Link Control

Protocol — LCP). Главная задача протокола LCP — установить опти-

мальные параметры связи между двумя устройствами на линии, что-

бы качество связи позволяло вести передачу пакетов между ними.

Например, нужно согласовать с приемной и передающей сторонами

длину пакета, который будет передаваться между ними без искаже-

ний. После того как фаза установления соединения закончена, РРР

переходит к следующей фазе.

117

Фаза проверки подлинности официально оговорена в RFC как

необязательная, однако в наши дни требования к сетевой безопас-

ности достаточно высоки, и практически ни одно соединение не об-

ходится без этой фазы. В настоящее время в РРР поддерживаются

два типа проверки подлинности пользователя — протокол аутентифи-

кации запрос-ответ (Challenge-Handshake Authentication Protocol —

CHAP) — и протокол установления подлинности пароля (Password

Authentication Protocol — PAP). Протокол CHAP более безопасный,

но PAP легче реализовать, поэтому он получил более широкое рас-

пространение. После того как удаленный хост прошел аутентифика-

цию соединения, в сеансе РРР начинается следующая фаза.

Фаза переговоров во время РРР-соединения делает протокол

РРР уникальным среди других сетевых протоколов. После проверки

подлинности соединения клиентское устройство РРР должно опре-

делить, какие протоколы оно будет передавать по этому соединению.

Далее удаленный хост РРР обязан принять или отвергнуть протоко-

лы, которые им не поддерживаются. Для переговоров о возможности

передачи тех или иных протоколов через РРР-соединение использу-

ется протокол управления сетью (Network Control Protocol — NCP).

В течение переговоров хост и клиент должны согласовать параметры

для передачи каждого протокола. Например, в течение переговоров

о передаче протокола IP-хост снабжает клиента информацией об IP-

адресе и сервере DNS, чтобы клиент мог нормально обращаться к

сети хоста РРР. После того как переговоры о протоколе успешно за-

вершены, между хостом и клиентом начинается передача пакетов

данных.

Когда клиент желает завершить сеанс РРР, то организуется еще

один сеанс по протоколу LCP с целью завершения соединения. Сер-

вер РРР должен правильно опознать этот запрос и закрыть модем-

ное соединение с клиентом РРР.

§2. Протокол HDLC

На протяжении многих лет HDLC применялся для связи мэйн-

фрэймов. Он показал свою надежность при передаче данных между

двумя устройствами, соединенными с помощью модемов. В RFC

1662 описан метод инкапсуляции протокола РРР в кадр HDLC. На

рисунке 25 представлен формат кадра HDLC.

118

Рис. 25. Формат кадра HDLC

Формат кадра HDLC состоит из пяти отдельных полей, в которые

инкапсулируются данные протокола РРР, посылаемые по модемной

линии.

Поле Флаг используется для идентификации начала кадра HDLC.

Определено, что в него заносится двоичное значение 01111110 или, в

шестнадцатеричном выражении, 0x7e. При этом программное обе-

спечение HDLC должно обнаружить это поле и опознать значение

как начало нового кадра.

В поле Адрес всегда установлена двоичная величина 11111111

или 0xff в шестнадцатеричном выражении. Это широковещательный

адрес. Все станции должны уметь опознавать данные, которые на-

правлены на этот адрес. Так как в «сети» HDLC обычно всего два

устройства, то очевидно, какому устройству предназначены данные

с широковещательным адресом.

Для РРР-пакетов в поле Управление в HDLC всегда установлено

двоичное значение 00000011 (шестнадцатеричное 0x03). Приемной

стороной должны отвергаться кадры с другими значениями в этом

поле.

119

Так как поля управления и адреса всегда содержат одни и те же

значения, то с целью экономии полосы пропускания они часто опу-

скаются. Таким образом, первое значение после поля флага может

восприниматься либо как начало пакета РРР, либо как поле Прото-

кол. Именно поэтому в поле Протокол кадра РРР не могут исполь-

зоваться величины 0xff и 0x03, так как это может ввести в заблуж-

дение принимающую сторону, которая может «решить», что

получает поля адреса и управления HDLC. Сокращение полей HDLC

при передаче называется сжатием кадра.

Поле проверочной последовательности кадра FCS (Frame Check

Sequence) используется для обнаружения ошибок во время передачи

кадра. Значение FCS вычисляется с помощью полей Адрес, Управ-

ление и данных из пакета HDLC. При вычислении проверочной по-

следовательности кадра не учитывается поле Флаг.

Поле Флаг в конце кадра обозначает конец кадра. Если за дан-

ным кадром следуют другие, то это поле должно опускаться. Одно

поле флага обозначает конец одного кадра и начало другого, пока в

конце не задано поле флага, которое сигнализирует о конце пере-

дачи.

Иногда данные РРР имеют те же значения, что и поле флага в

HDLC. Это может привести к путанице, так как приемник понимает

появление такой последовательности как конец передачи. Чтобы ис-

ключить такую возможность, используется так называемая про-

зрачная передача кадров. После вычисления FCS передатчик

проверяет поля между двумя полями флага и вставляет специаль-

ный контрольный октет (Control-Escape octet) 01111101 или шестнад-

цатеричное 0x7d перед каждым значением данных, которое соответ-

ствует значению флага. Затем передатчик выполняет логическую

операцию «Исключающее ИЛИ» над данными с величиной 0x20,

чтобы полученная величина не равнялась значению в поле Флаг.

Конечно, если значение данных равно значению контрольного окте-

та, то перед ним также должен быть помещен еще один контрольный

октет с последующим выполнением операции «Исключающее ИЛИ»

с величиной 0x20. Когда приемник принимает контрольный октет,

он уже «знает», что необходимо провести обратное преобразование

данных к их нормальному значению.

120

§3. кадры протокола PPP

Кадры РРР помещаются в поля данных кадра HDLC. Формат

кадра РРР представлен на рисунке 26.

Рис. 26. Формат кадра РРР

Поле Протокол может иметь длину в один или два октета; оно

идентифицирует протокол, который используется в поле Информа-

ция. В таблице 6 приведены некоторые значения поля Протокол,

которые поддерживаются протоколом РРР.

Таблица 6

Значения поля Протокол в кадре РРР

Значение Описание

1 2

0001 Заполнение пропусками

0021 Протокол IP (Internet Protocol)

002b Протокол Novell IPX

002d Протокол сжатия TCP/IP Van Jacobson

002f Протокол TCP без компрессии

8021 Протокол управления IP (IP Control Protocol — IPCP)