Ethernet lmi ce что это
Frame Relay первоначально замышлялся как протокол для использования в интерфейсах ISDN, и исходные предложения, представленные в CCITT в 1984 г., преследовали эту цель. Была также предпринята работа над Frame Relay в аккредитованном ANSI комитете по стандартам T1S1 в США.
Крупное событие в истории Frame Relay произошло в 1990 г., когда Cisco Systems, StrataCom, Northern Telecom и Digital Equipment Corporation образовали консорциум, чтобы сосредоточить усилия на разработке технологии Frame Relay и ускорить появление изделий Frame Relay, обеспечивающих взаимодействие сетей. Консорциум разработал спецификацию, отвечающую требованиям базового протокола Frame Relay, рассмотренного в T1S1 и CCITT; однако он расширил ее, включив характеристики, обеспечивающие дополнительные возможности для комплексных окружений межсетевого об'единения. Эти дополнения к Frame Relay называют обобщенно local management interface (LMI) (интерфейс управления локальной сетью).
Основы технологии
Frame Relay обеспечивает возможность передачи данных с коммутацией пакетов через интерфейс между устройствами пользователя (например, маршрутизаторами, мостами, главными вычислительными машинами) и оборудованием сети (например, переключающими узлами). Устройства пользователя часто называют терминальным оборудованием (DTE), в то время как сетевое оборудование, которое обеспечивает согласование с DTE, часто называют устройством завершения работы информационной цепи (DCE). Сеть, обеспечивающая интерфейс Frame Relay, может быть либо общедоступная сеть передачи данных и использованием несущей, либо сеть с оборудованием, находящимся в частном владении, которая обслуживает отдельное предприятие.
В роли сетевого интерфейса, Frame Relay является таким же типом протокола, что и Х.25 (смотри Главу 13 "Х.25"). Однако Frame Relay значительно отличается от Х.25 по своим функциональным возможностям и по формату. В частности, Frame Relay является протоколом для линии с большим потоком информации, обеспечивая более высокую производительность и эффективность.
В роли интерфейса между оборудованием пользователя и сети, Frame Relay обеспечивает средства для мультиплексирования большого числа логических информационных диалогов (называемых виртуальными цепями) через один физический канал передачи, которое выполняется с помощью статистики. Это отличает его от систем, использующих только технику временного мультиплексирования (TDM) для поддержания множества информационных потоков. Статистическое мультиплексирование Frame Relay обеспечивает более гибкое и эффективное использование доступной полосы пропускания. Оно может использоваться без применения техники TDM или как дополнительное средство для каналов, уже снабженных системами TDM.
Другой важной характеристикой Frame Relay является то, что она использует новейшие достижения технологии передачи глобальных сетей. Более ранние протоколы WAN, такие как Х.25, были разработаны в то время, когда преобладали аналоговые системы передачи данных и медные носители. Эти каналы передачи данных значительно менее надежны, чем доступные сегодня каналы с волоконно-оптическим носителем и цифровой передачей данных. В таких каналах передачи данных протоколы канального уровня могут предшествовать требующим значительных временных затрат алгоритмам исправления ошибок, оставляя это для выполнения на более высоких уровнях протокола. Следовательно, возможны большие производительность и эффективность без ущерба для целостности информации. Именно эта цель преследовалась при разработке Frame Relay. Он включает в себя алгоритм проверки при помощи циклического избыточного кода (CRC) для обнаружения испорченных битов (из-за чего данные могут быть отвергнуты), но в нем отсутствуют какие-либо механизмы для корректирования испорченных данных средствами протокола (например, путем повторной их передачи на данном уровне протокола).
Другим различием между Frame Relay и Х.25 является отсутствие явно выраженного управления потоком для каждой виртуальной цепи. В настоящее время, когда большинство протоколов высших уровней эффективно выполняют свои собственные алгоритмы управления потоком, необходимость в этой функциональной возможности на канальном уровне уменьшилась. Таким образом, Frame Relay не включает явно выраженных процедур управления потоком, которые являются избыточными для этих процедур в высших уровнях. Вместо этого предусмотрены очень простые механизмы уведомления о перегрузках, позволяющие сети информировать какое-либо устройство пользователя о том, что ресурсы сети находятся близко к состоянию перегрузки. Такое уведомление может предупредить протоколы высших уровней о том, что может понадобиться управление потоком.
Дополнения LMI
Форматы блока данных
Формат блока данных изображен на Рис. 14-1. Флаги ( flags ) ограничивают начало и конец блока данных. За открывающими флагами следуют два байта адресной ( address ) информации. 10 битов из этих двух байтов составляют идентификацию (ID) фактической цепи (называемую сокращенно DLCI от "data link connection identifier").
Центром заголовка Frame Relay является 10-битовое значение DLCI. Оно идентифицирует ту логическую связь, которая мультиплексируется в физический канал. В базовом режиме адресации (т.е. не расширенном дополнениями LMI), DLCI имеет логическое значение; это означает, что конечные усторойства на двух противоположных концах связи могут использовать различные DLCI для обращения к одной и той же связи. На рис. 14-2 представлен пример использования DLCI при адресации в соответствии с нерасширенным Frame Relay.
Рис. 14-2 предполагает наличие двух цепей PVC: одна между Aтлантой и Лос-Анджелесом, и вторая между Сан Хосе и Питтсбургом. Лос Анджелес может обращаться к своей PVC с Атлантой, используя DLCI=12, в то время как Атланта обращается к этой же самой PVC, используя DLCI=82. Аналогично, Сан Хосе может обращаться к своей PVC с Питтсбургом, используя DLCI=62. Сеть использует внутренние патентованные механизмы поддержания двух логически значимых идентификаторов PVC различными.
В конце каждого байта DLCI находится бит расширенного адреса (ЕА). Если этот бит единица, то текущий байт является последним байтом DLCI. В настоящее время все реализации используют двубайтовый DLCI, но присутствие битов ЕА означает, что может быть достигнуто соглашение об использовании в будущем более длинных DLCI.
Бит C/R, следующий за самым значащим байтом DLCI, в настоящее время не используется.
И наконец, три бита в двубайтовом DLCI являются полями, связанными с управлением перегрузкой. Бит "Уведомления о явно выраженной перегрузке в прямом направлении" (FECN) устанавливается сетью Frame Relay в блоке данных для того, чтобы сообщить DTE, принимающему этот блок данных, что на тракте от источника до места назначения имела место перегрузка. Бит "Уведомления о явно выраженной прегрузке в обратном направлении" (BECN) устанавливается сетью Frame Relay в блоках данных, перемещающихся в направлении, противоположном тому, в котором перемещаются блоки данных, встретившие перегруженный тракт. Суть этих битов заключается в том, что показания FECN или BECN могут быть продвинуты в какой-нибудь протокол высшего уровня, который может предпринять соответствующие действия по управлению потоком. (Биты FECN полезны для протоколов высших уровней, которые используют управление потоком, контролируемым пользователем, в то время как биты BECN являются значащими для тех протоколов, которые зависят от управления потоком, контролируемым источником ("emitter-controlled").
Бит "приемлемости отбрасывания" (DE) устанавливается DTE, чтобы сообщить сети Frame Relay о том, что какой-нибудь блок данных имеет более низшее значение, чем другие блоки данных и должен быть отвергнут раньше других блоков данных в том случае, если сеть начинает испытывать недостаток в ресурсах. Т.е. он представляет собой очень простой механизм приоритетов. Этот бит обычно устанавливается только в том случае, когда сеть перегружена.
Первый из мандатных байтов (unnumbered information indicator-индикатор непронумерованной информации) имеет тот же самый формат, что и индикатор блока непронумерованной информации LAPB (UI) с битом P/F, установленным на нуль. Подробная информация о LAPB дается в разделе "Уровень 2" Главы 13 "Х.25". Следующий байт называют "дискриминатор протокола" (protocol discriminator); он установлен на величину, которая указывает на "LMI". Третий мандатный байт (call reference-ссылка на обращение) всегда заполнен нулями.
В дополнение к общим характеристикам LMI существуют несколько факультативных дополнений LMI, которые чрезвычайно полезны в окружении межсетевого об'единения. Первым важным факультативным дополнением LMI является глобольная адресация. Как уже отмечалось раньше, базовая (недополненная) спецификация Frame Relay обеспечивает только значения поля DLCI, которые идентифицируют цепи PVC с локальным значением. В этом случае отсутствуют адреса, которые идентифицируют сетевые интерфейсы или узлы, подсоединенные к этим интерфейсам. Т.к. эти адреса не существуют, они не могут быть обнаружены с помощью традиционной техники обнаружения и резолюции адреса. Это означает, что при нормальной адресации Frame Relay должны быть составлены статистические карты, чтобы сообщать маршрутизаторам, какие DLCI использовать для обнаружения отдаленного устройства и связанного с ним межсетевого адреса.
Дополнение в виде глобальной адресации позволяет использовать идентификаторы узлов. При использовании этого дополнения значения, вставленные в поле DLCI блока данных, являются глобально значимыми адресами индивидуальных устройств конечного пользователя (например, маршрутизаторов). Реализация данного принципа представлена на Рис.14-4.
Глобальная адресация обеспечивает значительные преимущества в крупных комплексных об'единенных сетях, т.к. в этом случае маршрутизаторы воспринимают сеть Frame Relay на ее периферии как обычную LAN. Нет никакой необходимости изменять протоколы высших уровней для того, чтобы использовать все преимущества, обеспечиваемые их возможностями.
Реализация сети
Frame Relay может быть использована в качестве интерфейса к услугам либо общедоступной сети со своей несущей, либо сети с оборудованием, находящимся в частном владении. Обычным способом реализации частной сети является дополнение традиционных мультиплексоров Т1 интерфейсами Frame Relay для информационных устройств, а также интерфейсами (не являющимися специализированными интерфейсами Frame Relay) для других прикладных задач, таких как передача голоса и проведение видео-телеконференций. На Рис. 14-5 "Гибридная сеть Frame Relay" представлена такая конфигурация сети.
Обслуживание общедоступной сетью Frame Relay разворачивается путем размещения коммутирующего оборудования Frame Relay в центральных офисах (CO) телекоммуникационной линии. В этом случае пользователи могут реализовать экономические выгоды от тарифов начислений за пользование услугами, чувствительных к трафику, и освобождены от работы по администрированию, поддержанию и обслуживанию оборудования сети.
Для любого типа сети линии, подключающие устройства пользователя к оборудованию сети, могут работать на скорости, выбранной из широкого диапазона скоростей передачи информации. Типичными являются скорости в диапазоне от 56 Kb/сек до 2 Mb/сек, хотя технология Frame Relay может обеспечивать также и более низкие и более высокие скорости. Ожидается, что в скором времени будут доступны реализации, способные оперировать каналами связи с пропускной способностью свыше 45 Mb/сек (DS3).
Как в общедоступной, так и в частной сети факт обеспечения устройств пользователя интерфейсами Frame Relay не является обязательным условием того, что между сетевыми устройствами используется протокол Frame Relay. В настоящее время не существует стандартов на оборудование межсоединений внутри сети Frame Relay. Таким образом, могут быть использованы традиционные технологии коммутации цепей, коммутации пакетов, или гибридные методы, комбинирующие эти технологии.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Restrictions for Enabling Ethernet Local Management Interface
•Ethernet LMI relies on Ethernet CFM for the status of an EVC, the remote UNI identifier associated with an EVC, and remote UNI status.
•Ethernet LMI CE is available only on routing ports on routing platforms. For information about Ethernet LMI PE functionality on switching platforms, see the "Configuring Ethernet CFM and E-LMI" chapter of the Cisco ME 3400 Switch Software Configuration Guide, Release 12.2(25)SEG.
•Ethernet LMI in the Cisco IOS Software Release 12.4(9)T does not support autoconfiguration of CE devices.
Benefits of Ethernet LMI
•Communication of end-to-end status of the EVC to the CE device
•Communication of EVC and UNI attributes to a CE device
•Competitive advantage for service providers
Information About Enabling Ethernet Local Management Interface
An Ethernet virtual circuit (EVC) as defined by the Metro Ethernet Forum could be a port level point-to-point or multipoint-to-multipoint Layer 2 circuit. EVC status can be used by the customer edge (CE) device to find an alternative path in to the service provider network or in some cases, fall back to a backup path over Ethernet or another alternative service such as ATM.
Example: Enabling Ethernet LMI on a Single Supported Interface
Restrictions for Enabling Ethernet Local Management Interface
Ethernet Local Management Interface (LMI) relies on Ethernet connectivity fault management (CFM) for the status of an Ethernet virtual circuit (EVC), the remote user network interface (UNI) identifier associated with an EVC, and remote UNI status.
Ethernet LMI customer edge (CE) is available only on routing ports on routing platforms. For information about Ethernet LMI provider edge (PE) functionality on switching platforms, see the “Configuring Ethernet CFM and E-LMI” chapter of the Cisco ME 3400 Switch Software Configuration Guide.
Not all Cisco software releases support autoconfiguration of CE devices.
Enabling Ethernet LMI on a Single Supported Interface
Давайте поэтапно рассмотрим схему сети.
На схеме в левой части отображено два сервера, которые находятся в 192.168.30.0/24 и предоставляют сервисы для остальных клиентов сети. | |
В центральной части находятся два коммутатора, которые предоставляют сетевые подключения для всех устройств. Также эти коммутаторы имею подключение между собой для обеспечения базовой отказоустойчивости сети в случае обрыва одного подключения между коммутатором (SW01 или SW02) и маршрутизатором R1. | |
В правой части отображен роутер R1 который управляет сетевым взаимодействием всех участников данной топологии сети. | |
В верхней и нижней частях схемы расположились клиенты сети работающие за PC и Laptop. |
Итак полная схема топологии сети
Для того, чтобы правильно выдавать IP адреса нужных подсетей по DHCP всем участникам сети, разделим сеть на три VLAN. В итоге у нас получится
- Vlan 10 — 192.168.10.0/24
- Vlan 20 — 192.168.20.0/24
- Vlan 30 — 192.168.30.0/24
Укажем изменения на схему сети.
Теперь рассмотрим область сети, где расположена зона с Vlan 10. Так как устройства Vlan 20 это мобильные рабочие места, то возможно что одно или более рабочих мест может переподключиться из коммутатора SW02 в коммутатор SW01. Поэтому на коммутаторах нужно предусмотреть «гостевые» порты для устройств.
Итак итоговая топология сети в месте с Vlan и подсетями.
С топологиями сети достаточно, приступим к настройке оборудования.
Базовый принцип
Итак, теперь когда мы более или менее определились что такое Frame Relay, пора глянуть на то как он работает. Если говорить в терминах Frame Relay, то на схеме ниже у нас три устройства, которые подключены к Frame Relay облаку. Это DTE1, DTE2 и DTE3. Каждое их этих устройств подключено к провайдерскому устройству (DCE), которых на схеме тоже три.
- SVC (Switched Virtual Circuit) - такой канал сигнализируется DTE каждый раз, когда нужно передать данные.
- PVC (Permanent Virtual Circuit) - этот тип секита всегда присутствует в сети и настроен на узлах. DTE к нему всего лишь подключаются, но не сигнализируют.
- Роутер DTE1 инкапсулирует IP пакет в Frame Relay кадр, вставляет DLCI=102 в заголовок и отправляет получившийся сверток в сторону DTE2.
- В нашем случае, кадр попадает на DCE1. Внутри Frame Relay облака, перво наперво, проверяется заголовок Frame Relay, там находится идентификатор DLCI=102, это это часть секита VC12, DLCI в кадре меняется на 101 и отправляется в сторону DTE2.
- DTE2 так же смотрит заголовок Frame Relay, находит там DLCI 101 по которому он понимает, что данные пришли от DTE1. Далее заголовок отбрасывается и начинается работа с IP пакетом.
LMI (Local Management Interface)
Для взаимодействия между DTE и DCE существует специальный протокол LMI, который в сетях Frame Relay выполняет две важные функции.
Таким образом, после настройки линка наш DTE автоматически узнает о том, какие DLCI используются. Проблема только в том, что мы не знаем какой IP какому DLCI соответсвует. "ARP" - воскликнет читатель. "Почти" - отвечу я.
Inverse ARP
После того, как мы подключили устройство к сети Frame Relay, ближайший свитч расскажет нам какие DLCI настроены в канале. Для того, чтобы узнать какие L3 адреса (IP, короче говоря) за ними сидят нам нужно что-то вроде ARP в Ethernet, но наоборот. В Ethernet мы знаем L3, но не знаем какой MAC, т.е. L2 адрес, ему соответствует. Тут же мы знаем L2 адрес (DLCI), а вот IP нет.
Конечно, Inverse ARP можно отключить, отключив LMI, кстати говоря. В таком случае, всю настройку вы берете на себя. Нужно статически настроить DLCI на интерфейсах и записать каким DLCI на удаленных сторонах сети какие адреса соответсвуют.
Топологии
Стоит пару слов сказать про L3. Вы вольны как угодно строить дизайн L3 поверх Frame Relay облака. Можно одну подсеть "размазать" по всей сети, что я и сделал в своем примере (картинка ниже слева). Можно использовать логику точка-точка и на каждый VC выделить свою подсеть (справа).
Тип интерфейса
От типа интерфейса зависит то, как себя будет вести Frame Relay, и как будут вести себя протоколы динамической маршрутизации поверх него, кстати говоря. Сейчас рассмотрим немного исковерканную топологию из моего примера, у которой по какой-то причине убрали один линк между DTE1 и DTE3.
- Физическом интерфейсе. Хороший вариант, но не очень масштабируемый. В нашем примере выше, всю топологию можно настроить на физических интерфейсах. Прописываем инкапсуляцию 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 сабинтерфейс.
Если прикинуть, как будет ходить трафик в такой топологии, то получится примерно следующее. Допустим, в облаке уже все настроено и вы включили свои настроенные устройства.
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 в своем блоге. Теперь я буду спать спокойно.
1. Нужно настроить сеть таким образом, чтобы IP адреса выдавались по DHCP в зависимости от подключения клиентского оборудования к портам коммутатора (т.е. каждому типу устройства своя подсеть).
2. Если одно любое подключение от маршрутизатора (Router) к коммутатору (Swich) обрывается, то сеть должна остаться в рабочем состоянии, т.е. пункт №1 должен выполняться.
3. На маршрутизаторе три физических порта (Gi0/0, Gi0/1, Gi0/2). Порты Gi0/0 и Gi0/1 для локальной сети, но ситуация заключается в том, что эти порты обслуживают сети имея «одинаковые» IP адреса шлюза, т.е на роутере R1 для каждой подсети мы имеем по одному IP адресу, всего получается три IP на каждый физический порт. Нужно, чтобы IP адреса GW были одинаковы на портах Gi0/0, Gi0/1 маршрутизатора (Router) R1. Порт Gi0/2 для прочих сетей (например интернет, но мы его трогать не будем).
4. Требуется ограничение сетевого доступа.
- В подсеть для сервер-сервисов должны иметь доступ все клиенты из любой подсети.
- Подсети для PC и Laptop не должны видеть друг друга, но должны видеть сервера из п. выше.
Example: Enabling Ethernet LMI on All Supported Interfaces
DETAILED STEPS
Example:
Enables privileged EXEC mode.
Enter your password if prompted.
Example:
Enters global configuration mode.
interface type number
Example:
Specifies an interface and enters interface configuration mode.
ethernet lmi interface
Example:
Enables Ethernet Local Management Interface (LMI) on the interface.
Example:
Returns to privileged EXEC mode.
Prerequisites for Enabling Ethernet Local Management Interface
Business Requirements
•Ethernet OAM such as connectivity fault management (CFM) must be implemented and operational on the service provider's network.
Причины возникновения
После лирики самое время перейти к истории. Frame Relay появился в эру ISDN. Возникла надобность как-то организовать передачу данных по сети, для этого изначально была и разработана технология Frame Relay. Довольно редко встречающаяся в наши дни технология, однако не так уж редкая, как многие думают. Основным применением технологии был, так называемый, корпоративный сектор. В то время, для обеспечения канала связи между двумя офисами, применялись point-to-point serial линки. Штука простая и удобная, но не масштабируемая. Если нам нужно соединить 3 устройства через ISDN сеть, от каждого устройства понадобится прокладывать два serial линка. А если устройств 100. Эту проблему был призван решить Frame Relay. Он способен объединить все эти офисы чуть более эффективным методом. Понадобится всего один линк для соединения каждого устройства с 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, который стоит на стороне провайдера.
Business Requirements
Ethernet operation, administration, and management (OAM) such as connectivity fault management (CFM) must be implemented and operational on the service provider’s network.
SUMMARY STEPS
- enable
- configure terminal
- interface type number
- ethernet lmi interface
- end
How to Enable Ethernet Local Management Interface
Enabling Ethernet LMI on All Supported Interfaces
Perform this task to enable Ethernet LMI on all supported interfaces on a device.
Enabling Ethernet Local Management Interface
Ethernet Local Management Interface (LMI) is an Ethernet layer operation, administration, and management (OAM) protocol. It provides information that enables autoconfiguration of customer edge (CE) devices and provides the status of Ethernet virtual connections (EVCs) for large Ethernet metropolitan-area networks (MANs) and WANs. Specifically, Ethernet LMI notifies a CE device of the operating state of an EVC and the time when an EVC is added or deleted. Ethernet LMI also communicates the attributes of an EVC and a user-network interface (UNI) to a CE device.
The advent of Ethernet as a MAN and WAN technology imposes a new set of OAM requirements on Ethernet's traditional operations, which were centered on enterprise networks only. The expansion of Ethernet technology into the domain of service providers, where networks are substantially larger and more complex than enterprise networks and the user-base is wider, makes operational management of link uptime crucial. More importantly, the timeliness in isolating and responding to a failure becomes mandatory for normal day-to-day operations, and OAM translates directly to the competitiveness of the service provider.
DETAILED STEPS
Example:
Enables privileged EXEC mode.
Enter your password if prompted.
Example:
Enters global configuration mode.
ethernet lmi global
Example:
Enables Ethernet Local Management Interface (LMI) on all supported interfaces on the device.
Example:
Returns to privileged EXEC mode.
Contents
Finding Feature Information
SUMMARY STEPS
- enable
- configure terminal
- ethernet lmi global
- end
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Enabling Ethernet LMI on All Supported Interfaces
Technical Assistance
Table Of Contents
Additional References for Enabling Ethernet Local Management Interface
Приступим к настройке маршрутизатора R1.
Добавим к интерфейсу Gi0/0 и Gi0/1 по три виртуальных интерфейса для каждого Vlan.
Строка «encapsulation dot1Q 10» включает инкапсуляцию с помощью которой мы будем отлавливать пакеты сети предназначенные для подсети 192.168.10.0/24.
Строка «bridge-group 10» указывает группу для интерфейса, т.е. мы планируем сгруппировать два виртуальных интерфейса таким образом, чтобы физические интерфейсы Gi0/0 и Gi0/1 работали «одинаково» используя мостовые соединения.
Feature Information for Enabling Ethernet Local Management Interface
Ethernet Local Management Interface
Cisco IOS XE Release 3.9S
Ethernet LMI is an Ethernet layer OAM protocol. It provides information that enables autoconfiguration of CE devices and provides the status of EVCs for large Ethernet MANs and WANs.
The following commands were introduced or modified: clear ethernet lmi statistics , debug ethernet lmi , ethernet lmi , ethernet lmi global , ethernet lmi interface , show ethernet lmi .
Information About Enabling Ethernet Local Management Interface
An EVC as defined by the Metro Ethernet Forum could be a port level point-to-point or multipoint-to-multipoint Layer 2 circuit. EVC status can be used by the CE device to find an alternative path in to the service provider network or in some cases, fall back to a backup path over Ethernet or another alternative service such as Frame Relay or ATM.
Standards
Metro Ethernet Forum 16 Technical Specification
Draft Standard for Local and Metropolitan Area Networks
Liaison statement on Ethernet OAM (Y.17ethoam)
L2VPN OAM Requirements and Framework
Related Documents
Ethernet Connectivity Fault Management (CFM)
“Configuring Ethernet Connectivity Fault Management in a Service Provider Network” in the Cisco IOS Carrier Ethernet Configuration Guide
Configuring CFM and Ethernet Local Management Interface (E-LMI) in a service provider network
Cisco ME 3400 Switch Software Configuration Guide, Rel. 12.2(25)SEG
Commands used for configuring Ethernet LMI in a service provider network
Cisco ME 3400 Switch Command Reference, Rel. 12.2(25)SEG
Ethernet LMI at a provider edge
“Configuring Ethernet Local Management Interface at a Provider Edge” in the Carrier Ethernet Configuration Guide
Carrier Ethernet commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Cisco IOS Carrier Ethernet Command Reference
Cisco IOS commands: master list of commands with complete command syntax, command mode, command history, defaults, usage guidelines, and examples
Configuration Examples for Ethernet Local Management Interface
The examples in this section show the configurations that enable Ethernet LMI on all interfaces on a CE device (globally) and on a specific interface on a CE device.
How to Enable Ethernet Local Management Interface
Ethernet LMI
Ethernet LMI is an Ethernet layer OAM protocol between a CE device and the PE in large Ethernet MANs and WANs. It provides information that enables service providers to autoconfigure CE devices with service parameters and parameter changes from a user provider edge (UPE) device.
Figure 1 shows where in a network Ethernet LMI functions.
Figure 1
Position in the Network Where Ethernet LMI Functions
LMI also provides the status of Ethernet EVCs in large Ethernet MANs and WANs to the CE. Specifically, Ethernet LMI notifies a CE device of the operating state of an EVC and the time when an EVC is added or deleted. Ethernet LMI also communicates EVC and UNI attributes to a CE device.
The Ethernet LMI protocol includes the following procedures, as defined by the MEF 16 Technical Specification:
•Notifying the CE when an EVC is added
•Notifying the CE when an EVC is deleted
•Notifying the CE of the availability state of a configured EVC (Active, Not Active, or Partially Active)
•Communicating UNI and EVC attributes to the CE
SUMMARY STEPS
1. enable
2. configure terminal
3. ethernet lmi global
4. end
Ethernet Local Management Interface (LMI) is an Ethernet layer operation, administration, and management (OAM) protocol. It provides information that enables autoconfiguration of customer edge (CE) devices and provides the status of Ethernet virtual connections (EVCs) for large Ethernet metropolitan-area networks (MANs) and WANs. Specifically, Ethernet LMI notifies a CE device of the operating state of an EVC and the time when an EVC is added or deleted. Ethernet LMI also communicates the attributes of an EVC and a user-network interface (UNI) to a CE device.
The advent of Ethernet as a MAN and WAN technology imposes a new set of OAM requirements on Ethernet's traditional operations, which were centered on enterprise networks only. The expansion of Ethernet technology into the domain of service providers, where networks are substantially larger and more complex than enterprise networks and the user-base is wider, makes operational management of link uptime crucial. More importantly, the timeliness in isolating and responding to a failure becomes mandatory for normal day-to-day operations, and OAM translates directly to the competitiveness of the service provider.
Приступим к аналогичной настройке второго коммутатора — SW02.
Коммутатор SW02 Укажем новое имя коммутатору — SW02 Добавим VLAN на коммутационное устройство SW02 Теперь настроим интерфейсы. Количество интерфейсов можно указывать любое, в зависимости от задач и кол-во портов на коммутаторе. Посмотрим что у нас вообще есть из портов. Настройка сетевых интерфейсов для Vlan 20, для Laptop в подсети 192.168.20.0/24 Настройка «гостевых» сетевых интерфейсов для Vlan 10, для ПК в подсети 192.168.10.0/24. В моём случае это всего один интерфейс, но по идее можно указать любое количество. Настройка интерфейсов для Vlan 30, для сервисов, которые предоставляет серверная инфраструктура в подсети 192.168.30.0/24 Теперь настроим порты коммутатора которые будут подключены к маршрутизатору R1 и второму коммутатору SW01. Эти порты будут работать в режиме TRUNK. (Сокращённые команды) Включим spanning-tree улучшенную версию STP — rapid-pvst Посмотрим какие VLAN назначены на порты и их состояние. Сохраним конфигурацию Настройка коммутатора SW02 завершена.
Glossary
CE --customer edge. Edge equipment on the customer side of a user-network interface (UNI).
CE-VLAN ID --Identifier of a CE-VLAN.
E-LMI --Ethernet Local Management Interface. An Ethernet layer OAM protocol. It provides information that enables autoconfiguration of CE devices and provides the status of Ethernet virtual connections (EVCs) for large Ethernet MANs and WANs.
EVC --Ethernet virtual connection. An association of two or more user-network interfaces.
OAM --operations, administration, and maintenance. A term used by several standards bodies to describe protocols and procedures for operating, administrating, and maintaining networks. Examples are ATM OAM and IEEE Std. 802.3ah OAM.
PE --provider edge. Edge equipment on the service provider side of a user-network interface (UNI).
UNI --user-network interface. A common term for the connection point between an operator’s bridge and customer equipment. A UNI often includes a C-VLAN-aware bridge component. The term UNI is used broadly in the IEEE P802.1ag/D5.2 standard when the purpose for various features of LMI are explained.
Итак, я уже затрагивал тему xDSL и PDH/SDH. Но все никак не успокоится моя душа, пока я не напишу про Frame Relay. В этом посте попробую устранить это моё душевное неспокойствие.Как обычно, посмотрим, что такое Frame Relay как технология, как работает и какие интересные особенности в себе имеет. Погнали.
Для начала немного лирики. Уж не знаю почему, но к Frame Relay я всегда имел какие-то теплые чувства (если их вообще можно иметь к протоколу передачи данных. коллеги меня поймут, надеюсь). Впервые я узнал о нем давным давно, когда ещё готовился к CCNA. Тогда Frame Relay произвел на меня достаточно большое впечатление, хотя бы потому что это был не Ethernet. Это было что-то новое, что я не знал тогда. С тех пор, я почти не видел его имплементаций в жизни. Зато в цисковских экзаменах его до недавнего времени было просто завались. Давайте попробуем разобраться, что же в нем такого.
Prerequisites for Enabling Ethernet Local Management Interface
Подключаемся к коммутатору помеченному на топологии сети как SW01 и выполняем следующие настройки.
Коммутатор SW01 Укажем новое имя коммутатору — SW01 Добавим VLAN на коммутационное устройство SW01 Теперь настроим интерфейсы. Количество интерфейсов можно указывать любое, в зависимости от задач и кол-во портов на коммутаторе. Настройка сетевых интерфейсов для Vlan 10, для ПК в подсети 192.168.10.0/24 Настройка «гостевых» сетевых интерфейсов для Vlan 20, для Laptop в подсети 192.168.20.0/24. В моём случае это всего один интерфейс, но по идее можно указать любое количество. Настройка интерфейсов для Vlan 30, для сервисов, которые предоставляет серверная инфраструктура в подсети 192.168.30.0/24 Теперь настроим порты коммутатора которые будут подключены к маршрутизатору R1 и второму коммутатору SW02. Эти порты будут работать в режиме TRUNK Включим spanning-tree улучшенную версию STP — rapid-pvst Сохраним конфигурацию Настройка коммутатора SW01 завершена.
Ethernet LMI
Ethernet Local Management Interface (LMI) is an Ethernet layer operation, administration, and management (OAM) protocol between a customer edge (CE) device and the provider edge (PE) device in large Ethernet MANs and WANs. It provides information that enables service providers to autoconfigure CE devices with service parameters and parameter changes from a user provider edge (UPE) device.
The figure below shows where in a network Ethernet LMI functions.
LMI also provides the status of Ethernet virtual circuits (EVCs) in large Ethernet MANs and WANs to the CE. Specifically, Ethernet LMI notifies a CE device of the operating state of an EVC and the time when an EVC is added or deleted. Ethernet LMI also communicates EVC and user network identifier (UNI) attributes to a CE device.
The Ethernet LMI protocol includes the following procedures, as defined by the MEF 16 Technical Specification:
Notifying the CE when an EVC is added
Notifying the CE when an EVC is deleted
Notifying the CE of the availability state of a configured EVC (Active, Not Active, or Partially Active)
Communicating UNI and EVC attributes to the CE
Benefits of Ethernet LMI
Communication of end-to-end status of the EVC to the CE device
Communication of EVC and UNI attributes to a CE device
Competitive advantage for service providers
Читайте также: