Что Ethernet-инженеру нужно знать о Frame Relay

Итак, я уже затрагивал тему xDSL и PDH/SDH. Но все никак не успокоится моя душа, пока я не напишу про Frame Relay. В этом посте попробую устранить это моё душевное неспокойствие.

Как обычно, посмотрим, что такое Frame Relay как технология, как работает и какие интересные особенности в себе имеет. Погнали.

Для начала немного лирики. Уж не знаю почему, но к Frame Relay я всегда имел какие-то теплые чувства (если их вообще можно иметь к протоколу передачи данных... коллеги меня поймут, надеюсь). Впервые я узнал о нем давным давно, когда ещё готовился к CCNA. Тогда Frame Relay произвел на меня достаточно большое впечатление, хотя бы потому что это был не Ethernet. Это было что-то новое, что я не знал тогда. С тех пор, я почти не видел его имплементаций в жизни. Зато в цисковских экзаменах его до недавнего времени было просто завались... Давайте попробуем разобраться, что же в нем такого...

Причины возникновения

После лирики самое время перейти к истории. Frame Relay появился в эру ISDN. Возникла надобность как-то организовать передачу данных по сети, для этого изначально была и разработана технология Frame Relay. Довольно редко встречающаяся в наши дни технология, однако не так уж редкая, как многие думают. Основным применением технологии был, так называемый, корпоративный сектор. В то время, для обеспечения канала связи между двумя офисами, применялись point-to-point serial линки. Штука простая и удобная, но не масштабируемая. Если нам нужно соединить 3 устройства через ISDN сеть, от каждого устройства понадобится прокладывать два serial линка. А если устройств 100?.. Эту проблему был призван решить Frame Relay. Он способен объединить все эти офисы чуть более эффективным методом. Понадобится всего один линк для соединения каждого устройства с Frame Relay облаком. Картина ниже иллюстрирует подход.

Frame Relay - это NBMA (non-broadcast multiple access) сеть. Это означает, что одно устройство в сети может взаимодействовать с множеством других, но делается это не средствами посылки broadrcast сообщений. В этом основной прикол Frame Relay, который накладывает отпечаток на многие аспекты связанные с этим протоколом. Например, работа протоколов маршрутизации через такую сеть имеет некоторые особенности.

Frame Relay - работает на втором уровне OSI, поверх которого можно передавать множество L3 технологий. Конечно же, основная из них - IP. Именно про IP over Frame Relay и пойдет речь дальше. 

Frame Relay вводит пару терминов, которые особой сложности не несут, но иногда могут завести в заблуждение.

• DTE (data terminal equipment) - оборудование, которое использует сервис Frame Relay. По сути это CPE.

• DCE (data circuit-terminating equipment) - оборудование, которое предоставляет сервис Frame Relay. Это Frame Relay Switch, который стоит на стороне провайдера.

Базовый принцип

Итак, теперь когда мы более или менее определились что такое Frame Relay, пора глянуть на то как он работает. Если говорить в терминах Frame Relay, то на схеме ниже у нас три устройства, которые подключены к Frame Relay облаку. Это DTE1, DTE2 и DTE3. Каждое их этих устройств подключено к провайдерскому устройству (DCE), которых на схеме тоже три. 

Так же на схеме можно заметить некие VC. Их тут три и это основополагающий концепт во Frame Relay. Устройства в сети Frame Relay соединенны средствами Virtual Circuit, которые прокладываются поверх физических линков. Так, к примеру, DTE1 подключено к DTE2 и DTE3 двумя такими секитами, VC12 и VC31 соответственно.
Строго говоря, VC бывают двух типов:

• SVC (Switched Virtual Circuit) - такой канал сигнализируется DTE каждый раз, когда нужно передать данные.

• PVC (Permanent Virtual Circuit) - этот тип секита всегда присутствует в сети и настроен на узлах. DTE к нему всего лишь подключаются, но не сигнализируют.

В любом случае, каждый такой секит определяется с помощью DLCI (Data-link connection identifier). DLCI в сетях Frame Relay это что-то вроде MAC адреса в Ethernet, но не совсем. Это некий L2 идентификатор в сети. Но, в отличие от MAC, DLCI это локальное значение, которое должно быть уникально только в пределах линка. Если посмотреть на картинку выше, то вполне нормально использовать один DLCI на все устройства. Но обычно используется другой подход, который называется Global Addressing. В таком случае, DLCI уникален в пределах сети. Так привычней и проще.

Перейдем к тому как кадры передаются через такую сеть. Допустим, устройство DTE1 (192.168.0.1/24) хочет отправить какие-то данные устройству DTE2 с адресом 192.168.0.2/24.

1. Роутер DTE1 инкапсулирует IP пакет в Frame Relay кадр, вставляет DLCI=102 в заголовок и отправляет получившийся сверток в сторону DTE2. 
2. В нашем случае, кадр попадает на DCE1. Внутри Frame Relay облака, перво наперво, проверяется заголовок Frame Relay, там находится идентификатор DLCI=102, это это часть секита VC12, DLCI в кадре меняется на 101 и отправляется в сторону DTE2. 
3. DTE2 так же смотрит заголовок Frame Relay, находит там DLCI 101 по которому он понимает, что данные пришли от DTE1. Далее заголовок отбрасывается и начинается работа с IP пакетом.

 

 

LMI (Local Management Interface)

Для взаимодействия между DTE и DCE существует специальный протокол LMI, который в сетях Frame Relay выполняет две важные функции.

1. Keepalive. Если от соседа не приходит никаких сообщений, то такой линк считается умершим. Обычно это 3 не пришедших сообщения, интервал между которыми равен 10 секунд.
2. Сигнализация состояния. Как только роутер (DTE) появляется в сети, он шлет сообщение LMI Status Enquiry в сторону DCE. Тот отвечает ему сообщением LMI Status, в котором рассказывает какие DLCI сейчас настроены на этом VC и в каком они статусе. 

Таким образом, после настройки линка наш DTE автоматически узнает о том, какие DLCI используются. Проблема только в том, что мы не знаем какой IP какому DLCI соответсвует. "ARP" - воскликнет читатель. "Почти" - отвечу я.

Inverse ARP

После того, как мы подключили устройство к сети Frame Relay, ближайший свитч расскажет нам какие DLCI настроены в канале. Для того, чтобы узнать какие L3 адреса (IP, короче говоря) за ними сидят нам нужно что-то вроде ARP в Ethernet, но наоборот. В Ethernet мы знаем L3, но не знаем какой MAC, т.е. L2 адрес, ему соответствует. Тут же мы знаем L2 адрес (DLCI), а вот IP нет.

Как только наш роутер DTE получит сообщение LMI Status с перечислением DLCI, он сразу же отправит Inverse ARP сообщение в сеть, в котором расскажет свой DLCI и свой L3 адрес. Таким образом, другие участники сети узнают, с каким DLCI нужно слать кадры для достижения этого роутера.

Конечно, Inverse ARP можно отключить, отключив LMI, кстати говоря. В таком случае, всю настройку вы берете на себя. Нужно статически настроить DLCI на интерфейсах и записать каким DLCI на удаленных сторонах сети какие адреса соответсвуют.

Топологии

Стоит пару слов сказать про L3. Вы вольны как угодно строить дизайн L3 поверх Frame Relay облака. Можно одну подсеть "размазать" по всей сети, что я и сделал в своем примере (картинка ниже слева). Можно использовать логику точка-точка и на каждый VC выделить свою подсеть (справа).

Тип интерфейса

От типа интерфейса зависит то, как себя будет вести Frame Relay, и как будут вести себя протоколы динамической маршрутизации поверх него, кстати говоря. Сейчас рассмотрим немного исковерканную топологию из моего примера, у которой по какой-то причине убрали один линк между DTE1 и DTE3. 

Для примера возьмем Cisco, где нам предлагаетя возможность настроить Frame Relay на:

• Физическом интерфейсе. Хороший вариант, но не очень масштабируемый. В нашем примере выше, всю топологию можно настроить на физических интерфейсах. Прописываем инкапсуляцию frame-relay и IP адрес, всю остальную работу за нас сделают LMI и InARP. А вот если бы мы выбрали для реализации подход с предыдущего рисунка, когда для каждого VC нам понадобилась бы своя подсеть, настроить Frame Relay на физическом уровне уже не получится. Нужно было бы прописать две подсети на один физический интерфейс.
• Сабинтерфейсе. Можно сказать, что это Best Practises. Но в таком случае, нам нужно выбрать тип интерфейса, коих у нас два:
• Point-to-Point. В таком случае, InverseARP нам не нужен, потому как сама логика PtP предполагает, что на другом конце только одно устройство. Роутер просто считает, что вся подсеть, которая прописана на локалном интерфейсе доступна через DLCI соседа. Например, если настроить VC12 как PtP сабинтерфейс на DTE1, то роутер просто решит, что вся подсеть 192.168.0.0/24 доступна через VC12 и слать трафик в неё нужно с DLCI 102. Такой DLCI рассказал нам DTE2 на другом конце средствами LMI. Напомню, InverseARP для маппинга L2 в L3  не используется в таком случае. Для нашего примера, линк на DTE3 тоже можно настроить как PtP.
• Multipoint. А вот на DTE2 такая логика неприменима, ведь через один линк должно ходить несколько VC. В нашем случае, здесь потребуется настроить multipoint сабинтерфейс.

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

1. Первым делом отправится LMI Status Enquiry в сторону свичей в облаке.
2. Свичи ответят нашим DTE сообщением LMI Status какие DLCI настроены в VC. А именно, DTE1 и DTE3 узнают про DLCI 102, который принадлежит DTE2. DTE2 узнает про DLCI 101 и 102, которые принадлежат DTE1 и DTE2 соотвествнно.
3. Как только придет LMI Status на наши DTE, они отправят InARP сообщения. DTE1 расскажет, что его IP 192.168.0.1/24 и DLCI 101. DTE2 расскажет соседям, что его аддрес 192.168.0.2/24 и DLCI 102. DTE3 тоже всё всем расскажет.
4. Когда на DTE1 появится интерсующий нас трафик для отправки в сторону DTE3, он просто возьмет IP пакет, завернет его в Frame Relay кадр, запишет в него DLCI 102. Смотреть на InARP он не будет, он просто знает, что все из сети 192.168.0.0/24 нужно отправлять с DLCI 102. Почему? Потому что у нас натсроен point-to-point интерфейс.
5. Пройдя через Frame Relay облако, наш заголовок трансформируется и уже будет иметь DLCI 101.
6. Такой вот кадр с DLCI 101 и придет на DTE2. DTE2 поймет, что трафик этот не предназначается ему, потому что у него нет нужного IP на интерфейсах. Он взглянет на свой маппинг, который он составил по результатам LMI и InARP и поймет, что трафик этот предназначается DTE3  и должен быть отправлен в его сторону с DLCI 103.
7. DTE2 инкапсулирует трафик в новый FR заголовок и ставит в него DLCI 103.
8. По пути DLCI в заголовоке опять магическим образом поменяется с 103 на 102. 
9. Наконец-то DTE3 получил трафик, отбросил заголовок второго уровня (Frame relay), глянул в L3 заголовок (IP) и понял, что это для него. Далее трафик будет каким-либо образом обработан.
10. В случае, если DTE3 сформирует какой-то ответный трафик в сторону DTE1, ситуация повторится с пункта 1, но в обратном направлении.

Для наглядности я накидал UML диаграммку, зря я что ли писал как это делать в своем посте про UML?..

FECN,  BECN, DE

Следующее о чем стоит поговорить, это то, как Frame Relay сеть реагирует на перегрузку канала (congestion). А реагирует она, стоит сказать, довольно изящно. В заголовке Frame Relay кадра есть следующие интересущие нас биты:

• FECN (Forward Explicit Congestion Notification) - служит для нотификации перегрузки канала в сторону назначения

• BECN (Backward Explicit Congestion Notification) - служит для обратной нотификации о перегрузке канала

• DE (Discard Eligibility) - маркер трафика, который должен быть отброшен в первую очередь при возникновении переполнения на канале

Зачем они нужны, мы рассмотрим на паре примеров. Уберем все лишнее, чтобы не отвлекало.

На картинке выше изображен первый случай. 

• DTE1 отправляет некий трафик обернутый заголовком Frame Relay, в котором помимо DLCI находятся два бита - FECN и BECN. Роутер DTE1 отправляет их равными нулю, потому что он ни про какие перегрузки в канале не знает (ещё пока).

• DCE1 получает трафик и обрабатывает его, все как обычно. Однако он замечает, что в линке до DCE2 есть заторчик. Он запоминает VC, в котором к нему пришли данные и ставит бит FECN равным 1 в заголовке кадра в сторону соседа DCE2. Что означает, что в канале произошла перегрузка. Делает он это, по сути, в надежде, что кто-то на него-таки взглянет. Спойлер - не в этот раз...

• Кадр приходит на DCE2. Для него это самый обычный трафик, который он отправляет на DTE2.

• DTE2, получив трафик, начинает его как-то обрабатывать и, скорее всего, шлет некий обратный трафик. Он в этом примере про перегрузку канала ничего не знает, поэтому в его обратном кадре FECN и BECN тоже нулевые.

• Когда DCE1 получит такой трафик, он узнает VC и поставит бит BECN равный 1, для того, чтобы сказать источнику трафика (DTE1), что на канале есть проблемы и ему надо немного охладить свой пыл.

Втором примере на картинке выше.

В этом случае, DTE2 настроен на реакцию на бит FECN и сам проставит BECN = 1, для того чтобы уведомить DTE1 о перегрузке. DCE1 в этом случае ничего менять не будет. В этот раз, DCE1 не зря ставил FECN = 1, все таки хоть кому-то он пригодился и DTE2 взглянул на него.

FECN бит в нормальном сети меняют только DCE, а вот BECN могут менять как DCE, так и DTE.

Зачем же нужен бит DE? Когда обнаружиться перегрузка, на DCE, рано или поздно, переполнится очередь на отправку и он будет вынужден начать процесс сбрасывания кадров с её конца. Он понятия не имеет какой трафик важный, а какой нет. Но ему можно попытаться рассказать об этом... Есть возможность помечать некий "неважный" трафик при отправке с DTE битом DE. В этом случае, наши свитчи в ядре (DCE) смогут понять какой трафик стоит отбрасывать в первую очередь, инспектируя значение этого бита в заголовке Frame Relay.

Наверное, пока хватит. Наконец-то я описал Frame Relay в своем блоге. Теперь я буду спать спокойно.

...как бы "залабить" все это?..