Минимальная конфигурация интерфейса маршрутизатора выглядит следующим образом:
router(config-if)#encapsulation frame-relay [ietf] router(config-if)#ip address адрес маска
По умолчанию используется инкапсуляция данных в кадрах FR по стандарту Cisco, альтернативный вариант - инкапсуляция согласно RFC 2427 (ему соответствует параметр ietf).
Тип LMI маршрутизатор определяет автоматически, анализируя сообщения, поступающие от утройства DCE (FR-коммутатора). При необходимости жестко задать тип LMI используется команда
router(config-if)#frame-relay lmi-type cisco
Поскольку в рассматриваемой конфигурации интрефейса не указаны DLCI и соответствующие им IP-адреса, то маршрутизатор автоматически a) получает номера DLCI от утройства DCE по протоколу LMI и таким образом определяет подключенные к интерфейсу PVC;
б) использует протокол InARP для опроса удаленных концов подключенных PVC на предмет их IP-адресов.
Поскольку InARP определяет IP-адреса на дальних концах только тех PVC, которые непосредственно подключены к маршрутизатору, то маршрутизаторы, например, В и С не смогут связаться друг с другом, поскольку между ними нет PVC.
Другой способ указания номеров DLCI и IP-адресов, доступных через указанные DLCI, состоит в ручном конфигурировании этих параметров:
router(config-if)#frame-relay map ip IP-адрес DLCI
При ручном указании frame-relay map, протокол InARP на соответствующем PVC автоматически отключается. Таким образом, либо используется InARP, либо вручную указываются все IP-адреса, доступные через данный DLCI. На PVC, чей DLCI не упомянут в командах frame-relay map, InARP продолжает работу.
Необходимо понимать, что под "всеми IP-адресами" понимаются адреса IP- сети, состоящей из PVC, подключенных к данному интерфейсу. Достижимость других IP-адресов определяется по таблице маршрутов.
Рассмотрим пример. Пусть адрес сети FR на рисунке 1 - 1.0.0.0/24. Интерфейсы маршрутизаторов А и В имеют адреса 1.0.0.1 и 1.0.0.2. Маршрутизатор В получает дейтаграмму, адресованную в 2.2.2.2. По своей таблице маршрутов он определяет, что подобные дейтаграммы следует отправлять через узел 1.0.0.1. Далее маршрутизатор В замечает, что он имеет IP-интерфейс (предположим, serial0), подключенный в ту же IP-сеть, что и узел 1.0.0.1, следовательно, поиск по таблице маршрутов закончен и следующий маршрутизатор найден.
На втором этапе процесса обслуживания дейтаграммы маршрутизатор В должен определить, по какому из нескольких подключенных к интерфейсу serial0 виртуальных каналов PVC эта дейтаграмма должна быть отправлена. Если бы на месте FR был Ethernet, то маршрутизатор обратился бы к ARP- таблице и нашел бы MAC-адрес узла 1.0.0.1. В случае FR аналогичную роль играет карта (map), которая ставит в соответствие IP-адреса сети 1.0.0.0/24 и PVC (DLCI), подключенные к интерфейсу serial0. Карта заполняется протоколом InARP и/или вручную командами frame-relay map.
Продолжим пример. Маршрутизатор С в сети FR имеет адрес 1.0.0.3. Маршрутизатор В получает дейтаграмму, адресованную в 3.3.3.3. По своей таблице маршрутов он определяет, что подобные дейтаграммы следует отправлять через узел 1.0.0.3. Маршрутизатор В замечает, что он имеет IP- интерфейс serial0, подключенный в ту же IP-сеть, что и узел 1.0.0.3, следовательно, поиск по таблице маршрутов закончен и следующий маршрутизатор найден.
Далее маршрутизатор В обращается к карте FR для определения PVC, через который он должен отправить дейтаграмму. Если карта строится протоколом InARP, то, поскольку между В и С нет PVC, карта не содержит информации об IP-адресе 1.0.0.3 и дейтаграмма уничтожается. Для того, чтобы сделать возможной доставку дейтаграммы, нужно реализовать один из следующих вариантов:
. (решение на уровне 3) в таблице маршрутов В направить маршрут к
3.3.3.3 через 1.0.0.1, а в таблице маршрутов А направить маршрут к
3.3.3.3 через 1.0.0.3;
. (решение на уровне 2) указать в карте маршрутизатора В, что адрес
1.0.0.3 доступен через PVC A-B (после этого протокол InARP на этом PVC отключится, следовательно, необходимо также указать, что через тот же
PVC доступен и адрес 1.0.0.1).
IP-интерфейсы, подключенные к сетям FR, делятся на 2 типа: точка-точка (point-to-point) и точка-много точек (point-to-multipoint). Интерфейс point- to-point позволяет обмениваться пакетами только с одним узлом, а point-to- multipoint - с несколькими. Очевидно, что основной интерфейс (на примере маршрутизатора А) имеет тип point-to-multipoint.
На рисунке 4.2.2, слева, изображена организация сетевого уровня на FR- интерфейсе с использованием подынтерфейсов типа point-to-point.
[pic]
Рисунок 4.2.2 - Протокол IP на подынтерфейсах "точка-точка"
В этом случае каждый PVC терминируется на собственном IP-интерфейсе. Эти логические IP-интерфейсы называются подынтерфейсами основного интерфейса. На подынтерфейсах типа point-to-point может терминироваться, очевидно, только один PVC. Такой подынтерфейс с точки зрения протокола IP ничем не отличается от обычного последовательного интерфейса; каждому из подынтерфейсов присваивается собственный IP-адрес. Поэтому (рис. 4.2.2, справа) граф IP-сетей представлен тремя разными IP-сетями.
В данном случае нет смысла задействовать InARP или вручную создавать карту, поскольку все IP-адреса, достижимые через данный IP-интерфейс, должны находиться на другом конце единственного PVC, подключенного к подынтерфейсу. Но так как к основному интерфейсу могут быть подключены несколько PVC, то в конфигурации каждого подынтерфейса типа "точка-точка" необходимо указать, какой именно PVC подключен к данному подынтерфейсу (путем спецификации номера DLCI).
Следующая последовательность команд решает задачи конфигурации, показанной на рис. 4.2.2. 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); числа могут быть произвольными и не обязаны следовать по порядку.
На рисунке 3 изображен смешанный дизайн сети, где два PVC терминируются в одном IP-интерфейсе, а третий PVC терминируется в своем собственном IP-интерфейсе. Соответствующий граф IP-сетей показан на том же рисунке справа.
Рис. 4.2.3 Смешанный дизайн
В этом случае для синей IP-сети создается подынтерфейс типа point-to- point, а для коричневой - подынтерфейс point-to-multipoint.
Подынтерфейс point-to-multipoint ведет себя также, как основной интерфейс, в плане использования протокола InARP или заполнения карты. Однако, если на основном интерфейсе мы могли не перечилять PVC, подключенные к интерфейсу, так как этот список сообщал нам коммутатор, то в случае с подынтерфейсом point-to-multipoint мы должны указать подключенные к подынтерфейсу DLCI, иначе маршрутизатор не сможет определить, какие именно из PVC, подключенных к основному интерфейсу, необходимо сгруппировать в подынтерфейс. Конфигурация подынтерфейса point-to-multipoint: 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 и все три рассмотренных дизайна с его точки зрения совершенно идентичны, равно как и переход от одного дизайна к другому для оператора связи невидим и не имеет значения.
4.3 Show & Debug
Следующие команды полезны для получения информации и отладки Frame Relay.
router#show interface serial номер[.номер]
Команда, в частности, выводит следующие сведения:
. состояние интерфейса,
. используемый протокол 2-го уровня (Frame Relay),
. тип инкапсуляции данных в кадры FR (если не указан, то Cisco),
. тип LMI (если не указан, то Cisco),
. DLCI, используемый для LMI,
. число отправленных и полученных статусных LMI-сообщений (эти числа должны быть близки),
. период посылки статусных сообщений (keepalive).
router#show frame-relay pvc [DLCI] [interface интерфейс]
Команда выводит статус указанного PVC и различные сведения о нем. Если DLCI не указан, но выводятся сведения о всех PVC, подключенных ко всем интерфейсам FR. Если указан интерфейс, то выводятся сведения о PVC, подключенным к данному интерфейсу.
Статус PVC выражается двумя категориями: собственно, PVC STATUS, и DLCI USAGE.
PVC STATUS информирует о состоянии виртуального канала между данным маршрутизатором и удаленным DTE. Возможные значения:
. Active - канал установлен.
. Inactive - канал не функционирует (причиной этого могут быть отсутствие или неверная конфигурация удаленного DTE).
. Deleted - данный PVC сконфигурирован на DTE (командой frame-relay interface-dlci или frame-relay map), но не сконфигурирован на DCE
(отсутствует или ошибочна команда connect).
. Static - данный PVC сконфигурирован на DTE, но LMI отключен, поэтому получить информацию от DCE о статусе данного PVC невозможно. Эта ситуация может возникнуть при установлении FR-соединений DTE-DTE (back- to-back) без участия коммутатора - чтобы такие соединения работали,
LMI отключается командой no keepalive. DLCI USAGE показывает, как данный PVC используется маршрутизатором. Значения:
. Local - данный PVC терминируется на одном из (под)интерфейсов.
. Switched - маршрутизатор является FR-коммутатором и данный PVC является транзитным.
. Unused - данный PVC не терминируется никаким интерфейсом и не является транзитным (причиной этого является неверная или незаконченная конфигурация DTE или DCE).
router#show frame-relay map
Команда выводит список DLCI и соответствующих им IP-адресов. Наполнение карты производится протоколом InARP или командами frame-relay map. PVC типа "точка-точка" для полноты картины тоже вносятся в карту. Таким образом, движение IP-трафика возможно только по тем PVC, DLCI которых указаны в карте.
router#show frame-relay lmi [интерфейс]
Команда выводит сведения о работе LMI для указанного FR-интерфейса (или для всех интерфейсов, если интерфейс не указан). В частности, можно определить тип LMI, тип интерфейса (FR DTE/DCE) и число отправленных/полученных через этот интерфейс статусных запросов ("Status Enq.") и ответов ("Status msgs"). В нормально функционирующей сети число отправленных сообщений одного типа и число полученных сообщений противоположного типа должны быть очень близки.
router#show connect all
Команда выводит таблицу коммутации PVC на FR-коммутаторе. Команды вывода отладочной информации, позволяющие следить за обменом FR- сообщениями, приведены ниже: router#debug frame-relay packet [interface интерфейс [dlci DLCI]] router#debug frame-relay lmi
5. Заключение
Frame Relay - высокоскоростная технология передачи данных, основанная на коммутации пакетов. При использовании этой технологии данные разделяются на кадры (пакеты) разной длины, причем каждый кадр содержит заголовок с адресом получателя.
Метод Frame Relay характеризуется высоким быстродействием и низкой задержкой. Frame Relay имеет характеристики, которые делают его идеальным решением для передачи "импульсного" трафика. Такой трафик, например, имеет место при организации информационного обмена между локальной и глобальной сетями.
Достоинства Frame Relay заключаются не только в высокой скорости передачи данных, но и в методах статистического уплотнения информации, позволяющих в несколько раз повысить эффективность использования каналов связи.
Frame Relay обеспечивает оптимальное распределение ресурсов и высокую эффективность при:
. передаче графических изображений с высоким разрешением;
. передаче файлов при больших объемах данных;
. объединении низкоскоростных потоков данных в один высокоскоростной канал;
. передаче трафика типа редактирования текста, требующего коротких кадров, малых задержек и невысокой пропускной способности.
.
Наиболее эффективно применение Frame Relay в ситуации, когда Клиенту необходимо объединить несколько офисов. Особенно это актуально в ситуации, когда обмен данными между офисами имеет импульсный характер. Затраты на установку и арендная плата при использовании в такой ситуации Frame Relay будут ниже, чем при организации аналогичной схемы связи с использованием выделенных каналов, что достигается за счет оптимизации использования канальных ресурсов. Причем, чем больше офисов необходимо объединить, тем значительнее экономия.
Также применение технологии Frame Relay позволяет оптимально использовать ресурсы при организации доступа в Интернет.
6. Список источников
1. http://athena.vvsu.ru/net/labs/lab03_fr.html
2. www.cisco.com
3. www.lanck.ru
4. http://www.nsi-com.ru/index.htm
5. http://www.feedback.ru/yurix/networking/cisco/
6. http://ccna.boom.ru/ccna-rssg/ccna10cd-r.htm
7. http://www.telmos.ru/services/adsl.aspx
8. http://www.delmar.edu/Courses/ITSC1391/Sem4/
9. http://book.itep.ru
Страницы: 1, 2, 3, 4
