Frame Relay

Схема настройки протокола Преобразование адресов

• Статически
• Динамически с использованием inverse-ARP

1. Использование физического интерфейса
Сообщения состояния интерфейса LMI информируют устройство о виртуальных каналах, связанных с ними идентификатора LMI и об их состоянии(активное). encapsulation frame-relay
ip address <ip> <mask>
1.1. Полносвязная сеть с одной IP-подсетью

2. Использование подынтерфейсов.
Идентификаторы DLCI должны быть связаны с каждым подынтерфейсом один из двух способов: frame-relay interface-dlci или frame-relay map (отключается inverse ARP протокол)
2.1. Использование подынтерфейса типа точка-точка
2.2 Использование мультиточечного интерфейса.

Команда frame-relay interface-dlci dlci [ieft | cisco] назначает идентификатор DLCI указанному подынтерфейсу Frame Relay на интерфейсе или подынтерфейсе.

Подынтерфейсы представляют собой логические интерфейсы, связанные с физическим интерфейсом. Использование рассматриваемой команды обязательно для всех подынтерфейсов типа "точка-точка"; она также необходима для всех многоточечных интерфейсов, для которых установлено динамическое преобразование адресов. Для многоточечных подынтерфейсов, на которых установлено статическое связывание адресов, эту команду применять не требуется. Перед применением такой команды для назначения всех идентификаторов DLCI и параметров инкапсуляции или широковещания должны быть указаны интерфейс и подынтерфейс.

Команда frame-relay interface-dlci на подынтерфейсах активизирует протоколы маршрутизациии на интерфейсах, использующих инверсный протокол ARP. Данная команда также полезна для назначения конкретного класса каналу PVC, для которого желательна установка особых характеристик. Использование команды на интерфейсе (в отличие от подынтерфейса) позволяет избежать перенаправления данным устройством пакетов, предназначенных для конкретного канала с номером DLC1.

Соединение через сеть Frame Relay между двумя устройствами DTE называется виртуальный канал. Есть два типа виртуальных каналов: SVC - коммутируемые виртуальные каналы, создаются динамически при необходимости передачи данных. Состоит из этапов: настройка соединения, передача данных, ожидание, завершение соединения. PVC - постоянные виртуальные каналы, которые предварительно настраиваются провайдером услуги и после того, как они создаются, работают только в режиме передачи данных или ожидания.

DLCI
Каждый виртуальный канал в сети Frame Relay характеризуется идентификаторм DLCI. Этот идентификатор уникален только на одном соединении. Например, клиент подключается к коммутатору А провайдера Frame Relay с DLCI 102. Номер DLCI указывается во всех фреймах, отправляемых с маршрутизатора на коммутатор. Коммутатор А видит во входящих фреймах этот номер, сопоставляет его со своей таблицей маршрутизации. Там написано, что если на конкретный порт приходит фрейм с конкретным номером DLCI, такой фрейм надо отправить на другой порт с другим номером DLCI. Так фреймы и путешествуют, пока не достигнут получателя. Также между маршрутизатором и коммутатором могут быть установлены несколько виртуальных каналов. Каждый канал будет представлен своим номером DLCI.

Для того, чтобы маршрутизатор мог передавать данные через сеть Frame Relay, он должен знать соответствие адреса протокола 3-го уровня номеру DLCI. Эта таблица может заполняться двумя способами: динамически и статически. Динамически таблица заполняется благодаря Inverse Address Resolution Protocol - обратному ARP. Маршрутизатор посылает запросы на виртуальный канал с номером DLCI, чтобы определить адрес протокола третьего уровня на другой стороне. Отправляться запрос будет только для протоколов третьего уровня, которые активированы на маршрутизаторе. Оттуда приходит ответ, который заносится в таблицу. По умолчанию на маршрутизаторах Cisco включен именно этот способ. Статически - администратор может сам указать соответствие номера DLCI адресу третьего уровня. Но сначала он должен отключить динамическое определение, т.к. одновременно они работать не могут. Пример настройки:

R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#no frame-relay inverse-arp
R1(config-if)#frame-relay map ip protocol-address dlci broadcast cisco - broadcast означает, что на этот адрес разрешено отправлять широковещательные пакеты.

Проверить настройку можно командой:

R1#show frame-relay map

LMI
LMI - это процесс, который обеспечивает интерфейс информацией о состоянии канала между маршрутизатором (DTE устройством) и коммутатором Frame Relay (DCE устройством). Каждфе 10 секунд маршрутизатор отправляет запрос на 2-м уровне о состоянии канала. Коммутатор должен ответить о состоянии всех виртуальных каналов. Если ответа нет, маршрутизатор помечает состояние канала как нерабочее. Существуют следующие расширения LM, которые полезны для взаимодействия устройств: Сообщения о статусе виртуальных каналов - сообщения, которые помогают синхронизировать информацию между устройствами о работающий и неработающих виртуальных каналах. Эти сообщения предостеригают устройства оо отправки данных в неработающие виртуальные каналы. Многоадресная рассылка - позволяет один фрейм Frame Relay передать в несколько виртуальных каналов. Глобальная адресация - позволяет использовать не локальные, а глобальные идентификаторы Frame Relay, которые позволяют уникально идентифицировать интерфейс во всей сети Frame Relay. Простое управление потоком - механизм управления потоком, который применяется для всего интерфейса. Применяется на устройствах Frame Relay, которые на более высоких уровнях не могут управлять потоком и определять перегрузки каналов. Во фрейме Frame Relay поле DLCI содержит 10 бит, поэтому номер DLCI может быть от 0 до 1023. Некоторые номера DLCI зарезервированы менно для расширений сообщений LMI, передаваемых между DTE и DCE устройствами. Существуют три типа (стандарта) LMI, которые не совпадают друг с другом:

• Cisco
• Ansi
• q933a.

Поэтому тип LMI на противоположных сторонах должен совпадать. Начиная с рерсии IOS 11.2, у маршрутизаторов включена функция автоопределения типа LM, установленного на коммутаторах Frame Relay.

Настройка Frame Relay
Маршрутизатор R1

R1(config)#interface s0/0/0
R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#encapsulation frame-relay
R1(config-if)#no frame-relay inverse-arp
R1(config-if)#frame-relay map ip 10.1.1.2 16 broadcast cisco

Маршрутизатор R2

R2(config)#interface s0/0/0
R2(config-if)#ip address 10.1.1.2 255.255.255.0
R2(config-if)#encapsulation frame-relay
R2(config-if)#no frame-relay inverse-arp
R2(config-if)#frame-relay map ip 10.1.1.1 16 broadcast cisco

Проблема Split Horizon в Frame Relay
Как известно, для предотвращения петель маршрутизации при использовании протоколов динамической маршрутизации, используется функция Split Horizon, которая запрещает отправку обновлений маршрутизации на интерфейс, с которого это обновление было получено. Так вот, при использовании одного физического интерфейса маршрутизатора для организации нескольких виртуальных каналов, Split Horizon будет препятствовать распространению обновлений маршрутизации. Казалось бы, Split Horizon можно просто отключить. Но отключить его можно только при использовании IP. Другие протоколы третьего уровня не позволяют это сделать. Для решения этой проблемы лучше использовать разбиение физического интерфейса маршрутизатора на подинтерфейсы и назначать каждый виртуальный канал на отдельный подинтерфейс. Подинтерфейсы могут быть для двух видов связи: точка-точка и многоточка. Каждый подинтерфейс точка-точка требует для себя отдельную подсеть, а многоточечный - нет. Поэтому многоточечный подинтерфейс опять-таки не решит проблему Split Horizon. При организации подинтерфейса вид его надо указывать сразу. От этого будут зависить настройки.

Настройка подинтерфейса точка-точка:

R1(config)#interface s0/0/0
R1(config-if)#no ip address
R1(config-if)#no shutdown
R1(config)#interface s0/0/0 point-to-point
Router(config-subif)#ip address 10.1.1.1 255.255.255.0
Router(config-subif)#frame-relay interface-dlci 16 - указывается локальный номер DLCI.

Настройка многоточечного подинтерфейса:

R1(config)#interface s0/0/0
R1(config-if)#no ip address
R1(config-if)#no shutdown
R1(config)#interface s0/0/0 multipoint
Router(config-subif)#ip address 10.1.1.1 255.255.255.0
Router(config-subif)#frame-relay map ip 10.1.1.2 16 - указывается локальный номер DLCI и адрес противоположной стороны.

Характеристики Frame Relay
При формировании цены на услуги Frame Relay учитываются следующие характеристики:

• скорость подключенного порта
• тип канала - SVC или PVC
• гарантированная пропускная способность виртуального канала (CIR)

Иногда провайдеры продают услуг больше, чем есть у них реальной пропускной способности, рассчитывая на то, что не все абоненты будут работать одновременно. Это является причиной, что когда все начнут работать, у всех будут потери пакетов и задержка. Выходом из этой ситуации есть продажа дополнительной пропускной способности, которую можно использовать в периоды, когда она есть в наличии у провайдера. Цена ее намного меньше гарантированной скорости. Величина, на которую может быть увеличена пропускная способность, называется CBIR. А запас, на который еще может быть увеличена пропускная способность до достижения максимальной загрузки порта, называется ВЕ. Фреймы, которые передаются в полосе CBIR маркируются битом DE. Если он установлен, то эти фреймы могут быть удалены, если в сети будет перегрузка.

Материал взят с http://mcp1971.livejournal.com/3969.html

Настройка полноценного frame-relay свитча для GNS3.
Лабораторная работа CCNA GNS3 Подошло время для выполнения лабораторных работ по frame-relay. Регулярно слыша от инструктора CBT Nuggets Jeremy Cioara как хорошо быть самому себе Frame-Relay сервис провайдером, решил настроить маршрутизатор Cisco в качестве frame-relay switch. Не могу сказать, что я наткнулся на ограничения frame-relay switch доступного в GNS3 по умолчанию. Это просто интересно, и такой опыт не будет лишним. К тому же это даст дополнительную возможность еще лучше понять принципы работы Frame Relay.

За основу будет взят Cisco 3640 с модулем NM-4T. К нему будут подключены три Cisco 2691, которые в последствии и будут участвовать в сценариях лабораторных работ. Общий вид топологии будет следующим.

Лабораторная работа CCNA GNS3

Подключение маршрутизаторов к интерфейсам Frame-Relay Switch

R1 Serial0/0 -> fr_switch Serial0/1 
R2 Serial0/0 -> fr_switch Serial0/2
R3 Serial0/0 -> fr_switch Serial0/3

Используемые DLCI

R1->R2 102, R1->R3 103
R2->R1 201, R2->R3 203
R3->R1 301, R3->R2 302

Некое подобие логики в выборе интерфейсов и DLCI поможет не запутаться в дальнейшем. Для того чтобы Cisco 3640 стал frame-relay switch нужно в Global Configuartion Mode выполнить команду frame-relay switching

Далее необходимо настроить каждый интерфейс.

interface Serial0/1
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
clockrate 64000
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 102 interface Serial0/2 201
frame-relay route 103 interface Serial0/3 301
no shutdown

interface Serial0/2
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
clockrate 64000
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 201 interface Serial0/1 102
frame-relay route 203 interface Serial0/3 302
no shutdown

interface Serial0/3
encapsulation frame-relay
logging event subif-link-status
logging event dlci-status-change
clockrate 64000
no frame-relay inverse-arp
frame-relay intf-type dce
frame-relay route 301 interface Serial0/1 103
frame-relay route 302 interface Serial0/2 203
no shutdown

Для того чтобы проверить полученный результат

show frame-relay route

Input Intf      Input Dlci      Output Intf     Output Dlci     Status
Serial0/1       102             Serial0/2       201             inactive
Serial0/1       103             Serial0/3       301             inactive
Serial0/2       201             Serial0/1       102             inactive
Serial0/2       203             Serial0/3       302             inactive
Serial0/3       301             Serial0/1       103             inactive
Serial0/3       302             Serial0/2       203             inactive

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

UPD 20/08/2012

Арсений ( Jabbson ) рекомендовал более простой способ настройки frame-relay свитча. используя команду connect. Подробное описание использования данной команды можно прочесть на официльном сайте Cisco >>

interface Serial0/1
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
!
interface Serial0/2
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce
!
interface Serial0/3
no ip address
encapsulation frame-relay
clock rate 64000
frame-relay intf-type dce 
!
connect r1r2 Serial0/1 102 Serial0/2 201
connect r1r3 Serial0/1 103 Serial0/3 301
connect r2r3 Serial0/2 203 Serial0/3 302
!

Inverse-Arp Inverse-ARP Basics

Most of our modern day networks use the IP protocol for layer 3 addressing and routing. Because frame-relay operates strictly at layer 2 of the OSI model using DLCIs, frame-relay routers need a way to resolve IP addresses to DLCI numbers. That way, when a frame-relay router wants to send an IP packet to say 100.100.100.4 it can encapsulate the packet into a frame-relay frame and send it out the proper circuit tagged with the proper DLCI. In short, we need layer 3 to layer 2 address resolution.

In frame-relay we can do this two ways — static or dynamic. The static method typically involves the frame-relay interface-dlci command or the frame-relay map command depending on exactly what is going on. The dynamic method is where inverse-ARP comes into play. Inverse-ARP is a way we can automate this layer 3 to layer 2 address resolution. Essentially what happens is that an inverse-ARP request is sent out a particular DLCI saying “I have IP address x”. Since the receiving router knows the incoming DLCI, it now knows that whoever sent the inverse-ARP request is reachable at IP address x out the DLCI the request was received on. The remote router than sends an inverse-ARP reply that contains his IP address. Now at the originating router we have a DLCI and an IP address pair. The inverse part of the term stems from the fact that in traditional ethernet ARP a host has a layer 3 IP address that it wants to resolve to a layer 2 MAC address. With inverse-ARP the opposite is true — a router has a layer 2 DLCI assigned to an interface and it needs to find which layer 3 IP addresses are reachable out that interface.

The biggest confusion with Inverse-ARP in the Cisco world has to do with the defaults on different interfaces. We will cover the rules of each type of interface as they relate to inverse-ARP now.

Physical Interfaces

Physical interfaces have inverse-arp enabled by default. Remember, every single DLCI the frame-relay router learns about via LMI from the frame-relay switch is going to be mapped to the physical frame-relay interface by default. You can see this with the show frame-relay pvc command.

   IF you have an IP address on the interface, the router will send an Inverse-ARP request out every single DLCI associated with the interface.  If you have no other sub-interfaces with DLCIs assigned via frame-relay interface-dlci or frame-relay map commands this means ALL of them!

   Adding the command frame-relay interface-dlci does nothing because all the DLCIs learned from the frame switch are already associated with the interface. Therefore adding this command on a physical interface does not disable inverse-ARP in any way

   Adding the command frame-relay map for a manual IP/DLCI mapping will disable inverse-ARP for that particular DLCI on the interface.  Note that inverse-ARP requests will still be sent on any other DLCIs associated with the physical interface

   You can disable inverse-ARP completely by issuing the no frame-relay inverse-arp interface command.  However, if your router receives an inverse-arp request from another router, it will always respond to the request. You can validate this by looking at debug frame-relay packet as well as debug frame-relay events. Disabling inverse-ARP is usually the preferred thing to do, especially in the CCIE study world as rumor has had it for years that it is not allowed in the lab.

   You can disable inverse-ARP on a per-DLCI basis with the no frame-relay inverse-arp ip command

Multipoint Subinterfaces

Multipoint sub-interfaces have inverse-arp enabled by default…sort of, given the right conditions : )

   By default no inverse-ARP requests will be sent UNLESS you utilize the frame-relay interface-dlci command, and you have an IP address on the interface.  If you put this command on your subinterface for one or more DLCIs, inverse ARPs will indeed be sent for those DLCIs.  The somewhat confusing thing for people here is that typically the frame-relay interface-dlci command is not used on multipoint subinterfaces for this purpose.  It’s only real purposes on this type of interface are for using inverse-ARP and for QoS (traffic shaping and such on a particular DLCI).

   frame-relay interface-dlci enables Inverse-ARP for that particular DLCI on the subinterface

   frame-relay interface-dlci mixed with frame-relay map will result in no inverse-ARP requests being sent on that DLCI.  You might see this in the case where you are doing your L3/L2 address resolution with frame-relay map but you are also applying a DLCI specific QoS policy via frame-relay interface-dlci

   You can disable inverse-ARP completely by issuing the no frame-relay inverse-arp interface command. Same rules apply for replying to requests as on the physical — you always reply.

   You can disable inverse-ARP on a per-DLCI basis with the no frame-relay inverse-arp ip command

Point-To-Point Subinterfaces

The rules here are generally pretty simple. The frame-relay map command is not allowed on a point-to-point subinterface so it narrows down the confusion. The reason is because the link is by definition point-to-point so there is no need for a mapping of any kind. The router basically says “anything that gets routed out this subinterface is going out the DLCI assigned to the subinterface via the frame-relay interface-dlci command” because there is only one possible place the frame can go — to the other side of the point-to-point connection.

   frame-relay map command not allowed or useful

   frame-relay interface-dlci used on the subinterface to assign a DLCI to the subinterface

   No inverse-ARP is sent out regardless if it is enabled on the physical interface.  Inverse-ARP requests are simply not sent on a point-to-point subinterface.

   Remember that inverse-ARP requests are ALWAYS answered.  If your point-to-point sub-interface receives a request it WILL reply

Summary

Inverse-ARP is a way to automate layer 3 to layer 2 address resolution in a frame-relay network. It is enabled by default on physical interfaces. It can be used on multipoint subinterfaces given that the frame-relay interface-dlci command is used to tell the router what DLCI to send the requests out of. Requests are not sent out point-to-point subinterfaces. Inverse-ARP replies are always sent on all interface types.

If you are struggling with or studying this topic the best advice I can possibly give you is to lab this up. That is the key to understanding most things like this in my experience.