Протокол Frame Relay

Протокол Frame Relay Протокол коммутируемый Протокол любимый в свою очередь провайдерами В современном мире Frame Relay вы вряд ли встретите Но как уже было сказано Frame Relay очень был Любим провайдерами Очень по этой причине был любим CISC в свое время Если говорить про обучение Роутингу свитчингу CISC И до сих пор очень любим CISC Именно за счет того, что когда-то В свою очередь это был очень-очень хороший протокол Очень-очень для своих дней Нам сейчас понадобится Немножко нудной истории

Она буквально там пару минут займет Так что не переживайте Если кто-то в детстве историю не любил Немного времени это займет История Frame Relay важна Потому что для того, чтобы понимать Чем Frame Relay был хорош Надо понимать, что вокруг него было А вокруг него было в общем голое поле Разработка Frame Relay началась в 1984 году В этот момент ничего Для коммутации в WAN сетях Толком и не было Был замечательный протокол X25 Который ну совсем старый Который был разработан там в 60-70-х годах И у него было все свое У него был свой отдельный стек У него был свой отдельный формат канального уровня Свой отдельный формат сетевого уровня То есть он вообще совершенно обособленный протокол И IP поверх него таскать было очень неудобно Ну и другие протоколы сетевого уровня Поверх него опять же работали Как-то вот очень в режиме совместимости Поэтому для того, чтобы передавать трафик Именно в чистом виде Без каких-либо там схем с совместимостью Был придуман Frame Relay Протокол еще раз подчеркну Коммутируемый В некотором смысле похож на Ethernet

Мы с вами сейчас увидим Чем он похож на Ethernet Чем не похож И протокол разрабатывался как стандартный То есть вот X25 это стандартный протокол Его и ту продвигало И все механизмы, которые в нем есть Они соответственно и тушные Частичные и ешные Ну в общем стандартный протокол Вот Frame Relay он тоже теоретически стандартный протокол Все, что в нем теоретически есть Это все теоретически вот должно быть стандартным Но в 1984 году разработку его начали Начали, начали, начали, начали И что-то как-то вот заглохло дело В 90-м году на это все дело посмотрел Консорциум из четырех компаний Cisco, DEC, Digital Equipment Company, Nortel и Stratacom Они сформировали консорциум, который стал называться Консорциум Frame Relay Вот как сегодня есть консорциум Wi-Fi Который фактически торговая марка Они продвигают стандарт 802.11 еешный Вот то же самое консорциум Frame Relay Это был консорциум совершенно коммерческой организации

Которая продвигала соответствующие стандарты Разработанные E-Tool И в 90-м году, да, вот эти вот четыре компании Они начали продвигать Frame Relay И достаточно неплохо продвинули его Потому что, ну, опять же, на тот момент Альтернатив Frame Relay никаких не было Он был достаточно быстрый Но достаточно быстрый не просто как Ну, протокол, который быстрый Быстрый протокол и так далее уже были А он еще... Пардон Он еще позволял управлять скоростью Причем достаточно гибко Вы могли на уровне коммутации Управлять количеством кадров, которые вы будете коммутировать То есть вы могли, например, сказать А давайте у нас вот этот клиент будет по Frame Relay Работать со скоростью 64 кбит в секунду А вот этот со скоростью 128 кбит в секунду А вот этот клиент, у него будет как бы номинально 2 мегабита Но только если у нас вся полоса свободна И у нас как бы теоретически мы можем в договоре написать 2 мегабита А по факту, если у нас все хорошо, мы пропускаем 2 мегабита А если нет, то мы начинаем понижать ему скорость

И вот гарантированная скорость у него будет, допустим, поменьше Что вот если он посылает до 100 кбит, он точно вот все пролезет Если он посылает больше, пролезет только если вот у нас все хорошо В сегодняшнем мире, на самом деле, эту технику задействовали почти все провайдеры Когда вы сегодня подключаете свой интернет, вам говорят Заплати вот столько-то денег и получи тариф 50 мегабит в секунду Или 10 мегабит в секунду, или 5 мегабит в секунду Вам говорят максимальную теоретически доступную вам скорость Что выше этой скорости вы точно не прыгнете Но это не означает, что всегда, когда вы будете посылать трафик со скоростью 50 или 10 мегабит в секунду Гарантированно весь трафик пойдет по сети У вас есть некая гарантированная скорость Зависит от того, насколько ваш провайдер плечный У плечных провайдеров есть гарантированная скорость в каждом договоре И эта скорость заметно меньше, чем максимальная декларируемая теоретически доступная скорость Например, если вы физлицо, вы подключаете договор на 10 мегабит в секунду Где-нибудь в договоре мелким шрифтом будет написано

Да, максимальная 10 мегабит, но гарантированная 128 кбит Ну это, конечно, перебор, но там обычно оно заметно меньше Ну, может мегабит будет, может что-то в таком духе Скоростью можно было гибко управлять Это, во-первых, за счет этого он полюбился провайдером Была так называемая гарантированная полоса пропускания То есть, вы могли указывать, что определенную полосу мы точно пропускаем А определенную полосу как получится Было управление качеством То есть, вы могли отправлять кадры, как клиент, во FrameRelayC У вас, например, там было 2 мегабита доступной полосы и 100 килобит гарантированной Вот вы отправляете 80 килобит промаркированных, это кадры важные

А все остальное промаркируете как попало Ну то есть не как попало, а промаркируете неважно И вот вы отправляете эти кадры, и тогда если вдруг в сети провайдера где-то возникнет перегрузка Клиент об этом не знает Тогда провайдер вынужден будет какие-то кадры не прокоммутировать Он их выбросит, но он выбрасывает те кадры, которые промаркированы Что это можно смело выбрасывать А вот те, которые требуют гарантированную доставку, они пропускались Еще раз подчеркну, это штатная фича в протоколе В протоколе 80-х годов Помимо того, что протокол был хороший, удобный, он еще был довольно простой Простой по сравнению с ATM, который предлагался примерно в то же время То есть они примерно одного возраста протоколы Но ATM это опять огромный толстый протокол, который наследует от X25 Свою монструидальную сложность Книжка по ATM, цисковская, она просто конского размера По фрейм рилей сильно меньше Фрейм рилей простой как барабан Вот там, не знаю, тот же самый Ethernet

Простой как барабан протокол, который выстрелил в LAN-сетях Фрейм рилей тоже простой как барабан протокол, который в свое время выстрелил в LAN-сетях И он за счет своей простоты оказался очень удобен, очень прост в обслуживании, очень дешевый в конце концов Ну и да, и за счет этого всего его любили Родилось все это из телефании То есть фрейм рилей это протокол коммутации Он не рассказывает про то, какая должна физика быть Сегодня, когда мы говорим про, допустим, протокол Ethernet Мы всегда держим в уме, что Ethernet это определенный формат кадра плюс соответствующая физика То есть мы не говорим, что вот у нас есть Ethernet просто абстрактный в вакууме Мы всегда имеем в виду, что там Ethernet 1000 BST У которого там гигабит по меди И получается, что физический и канальный уровень неотделимы Фрейм рилей это только проканальный уровень Физика может быть любая Но какая могла быть физика в те годы? Это была телефония Телефония цифровая, которая тогда появлялась не в OIP, в OIP, а вот именно цифровая телефония

То есть это ASDN сети И у вас было два фактически доступных потребителю варианта скорости Либо это был Basic, как называется, BRI, Basic Rate Interface У него скорость 64 кбит в секунду Либо это был, соответственно, T1 поток и, соответственно, там BRI, 1,5 мегабита или 2 мегабита Вот фрейм рилей позволял вам подключиться на скорость, как бы номинальной скорости физики Практически любой, которая вам была удобна А дальше поверх всего этого дела передавать кадры, которые бы коммутировались с нужной вам скоростью В чистом ASDN у вас было только два варианта Либо 64 кбит, либо 1,5 или 2 мегабита в секунду Теоретически на магистральных скоростях, естественно, 2 мегабита было абсолютно никому интересно Но вот максимум фрейм рилей раскачали до E3 каналов Это 35 мегабит европейские каналы Больше на тот момент казалось уже вообще недостижимым Потому что, ну, это годы были, когда даже 14400 модем был, в общем, очень-очень крутым решением

90-й год Вы пытаетесь вспомнить, какие каналы, какие скорости тогда были актуальны Вот 35 мегабит теоретически, вот это было на тот момент какой-то фантастической скоростью Сегодня, понятное дело, скоростью в 1,5 мегабит или в 35 мегабит можно только насмешить Особенно если говорить, что 35 это магистральная скорость Поэтому фрейм рилей сегодня использовать как-то грешновато Только если эмулировать наличие фрейм рилея поверхом PLS-сетей Так, что касается коммутации Мы предполагаем, что у нас есть некая битовая среда, которая умеет передавать отдельные биты Из этих битов мы строим кадры А вот кадры, соответственно, должны быть определенного формата Фрейм рилей как раз и говорит, какого формата должны быть эти кадры и как они должны передаваться Причем физика, которую использует фрейм рилей, это обязательно point-to-point физическая среда То есть если говорить про коммутируемый Ethernet Ну, тоже фактически современные Ethernet это все point-to-point среда У вас везде прямые провода от конечного абонента до свеча

Или от свеча до другого свеча идет просто отдельный провод Вы уже нигде не встретите Ethernet, который с общим доступом, где в одном проводе там 3, 4, 5 устройств сидит Когда-то давно было, сейчас нет Вот во фрейм рилея point-to-point коммутация была изначально Дальше У фрейм рилея отличие от чистого Ethernet заключается в том, что, во-первых, можно управлять качеством передачи В Ethernet, как вы помните, никакого управления качеством в принципе нету Чистый стандартный Ethernet заголовок это кто, кому, чего отправил и как посчитать чек-сумму Фрейм рилей чуть посложнее в смысле заголовка То есть там есть поля про качество, там есть поля про то же самое чек-сумму Там есть поле, кто кому чего отправил Ну, то есть в чем-то похоже на Ethernet, в чем-то не похоже Похоже на коммутацию в Ethernet Фрейм рилей будет то, что вы отправляете кадр И этот кадр коммутируется последовательно между коммутаторами Коммутационное решение принимается все время в зависимости от адреса

Куда отправили этот кадр Как же в Ethernet мы отправили кадр? Вот у него есть MAC адрес получателя Кадр дошел до первого свитча Свитч посмотрел на MAC адрес получателя Принял решение Это отправляем туда Дальше туда дошло Тот свитч посмотрел, куда отправлять Отправил дальше Вот та же самая история во фрейм рилею У вас есть некая таблица коммутации По этой табличке каждый коммутатор поднимает решение, куда это кинуть Абсолютно та же самая история, что в Ethernet Так же как в Ethernet нет коррекции ошибок Но есть контроль целостности В том смысле, что есть чек-сумма CRC В Ethernet CRC32, во фрейм рилею CRC16 Это контроль целостности То есть если что-то не дошло до получателя В смысле, что-то побилось по дороге То, соответственно, получатель про это дело узнает Почему в Ethernet CRC32, а во фрейм рилею CRC16? Потому что в Ethernet CRC32 придумывалось не для Не для определения целостности кадра А для того, чтобы определить, случилась ли коллизия или нет

Во фрейм рилею коллизии изначально не было А наличие одной ошибки в одном бите Которая случилась из-за битероррейт Того, что у нас где-то вот что-то произошло не так Это можно определить и с помощью более маленькой, более простой Ксума CRC16 Дальше Коррекции ошибок нету по сравнению с протоколом, допустим, X25 Вот в X25 предполагалось, что канальные физические среды, которые передают биты У них есть большой шанс ошибки То есть вы передаете кадр, а вот он типа по дороге может побиться И причем с большой вероятностью может побиться Ethernet разрабатывался исходя из того, что битероррейт будет очень маленький То есть у вас допустимая, ну скажем нормальная вероятность ошибки в Ethernet Просто вот передавали кадр, а на него ничего не влияло Ни там микроволновка не включалась, ни сварочный аппарат никто не включал В общем нормальная обычная работа Ethernet рассчитывает на то, что кадры будут биться

Не кадры, а отдельные битики будут биться С вероятностью 10 в минус 14 степени То есть вот надо передать, сколько получается, миллиард Это 9 нулей, триллион это 12 нулей 100 триллионов бит перед тем, как один битик случайно поломается Вот во фрейм рилей такая же примерно ситуация Там битероррейт бер немножко поменьше, пониже То есть вероятность возникновения ошибки повыше Но все равно фрейм рилей исходит из того, что кадр сам по себе не поломается Поэтому контроль целостности у него производится А вот восстановления ошибок нет Если вдруг у нас случайно отдельный битик побился Ну просто выкинем кадр, один кадр на триллион Это ничего страшного в том, что побилось нету Так же как в Ethernet, во фрейм рилей можно передавать данные совершенно произвольной длины Это намек на то, что был там ATM еще такой протокол У которого были ячейки, ячейки всегда одинаковые Нет, в Ethernet отправили кадр И дальше в зависимости от того, что за кадр мы отправляем

Вложение может быть от 46 до 1500 байт Во фрейм рилей тоже есть минимальное и максимальное значение, которое можно отправить Именно длина содержимого, которое отправляется Если посмотреть с большой вот такой колокольни То во фрейм рилей получается довольно похож на Ethernet Но есть и отличия Во-первых, фрейм рилей это протокол для WAN сетей, не для LAN Ethernet создавался как протокол WAN сетей Что все узлы находятся рядом, есть коллизии, все находятся в одном проводе В общем, всякая вот такая вот мутата, которая для LAN сети характерна, для WAN сети в общем нет Во фрейм рилей у вас не может случайно образоваться новый пользователь, новое подключение Фрейм рилей это протокол для провайдеров У провайдера новый клиент, никак случайно не получится Поэтому во фрейм рилей у вас нету такого, что просто подключили пользователя и с коробки начал работать Такого Zero Configuration У вас для того, чтобы пользователь начал работать во фрейм рилей, нужно провести какие-то действия

Физически подключили пользователя к сети и дальше настроили, чтобы это все работало В Ethernet этого нету Во фрейм рилей у вас может быть неполносвязная топология Кое-кто, кое-кого, кое-как видит, а все остальные нет То есть если вы не прописали маршрут, у вас не будет связи Во фрейм рилей может быть такое, что Вася Петю видит, Петя Колю видит, Вася Колю не видит То есть вот партиал менш, то что называется, да То, что в Ethernet такого быть не может То есть может, но с очень большими оговорками Если у вас умные свечи, вы можете там аксесс-листами заблокировать Чтобы вот Петя Колю мог отправить, Колю Вася нет Private VLAN и Protected Port, вот это вот все Во фрейм рилей это штатная штука из коробки То есть для провайдерских задач Не нужно передавать трафик совершенно от произвольных пользователей На совершенно произвольных Вот только там, где нужно Только те пользователи, которые должны между собой передавать трафик Только вот те пользователи могут Таблицу коммутации вы прописываете

Перед тем, как трафик может ходить И эта таблица коммутации, она вот четко указывает Кто, кому, куда Нет, соответственно, связи всех со всеми Нету бродкастов Вы не можете отправить кадр, который дойдет до всех В том числе и потому, что неполносвязная топология То есть вы не можете вообще, в принципе, доставить кадр до некоторых ее участников Поэтому нет бродкастов Нет мультикастов И нет unknown unicast Вот этот вот boom broadcast, unknown unicast и multicast Этого всего нету Вы должны точно отправлять кадр, в котором будет всегда написано, кому вы этот кадр отправляете Unicast и в адрес получателя Вы должны знать до момента отправки кадра В Ethernet вы можете отправить кадр кому угодно Вы можете отправить кадр на известный Mac или на неизвестный Mac Но когда такой кадр дойдет до свеча Свеч дальше разберется, что с этим кадром делать Если он знает, куда отправить такой кадр, он его отправит по назначению Если он не знает, он его разбросает на все порты Ну или, скажем, более точно, на все порты, кроме тех, на которые точно известно, что отправлять не надо

Во Frame Relay вы должны всегда указывать только известные unicast и Mac Если вдруг кадр такой дойдет до свеча, а свеч почему-то не знает, куда такой кадр девать То значит он его выкинет Это отличие от Ethernet Это и очень важное отличие Еще из таких, в общем, достаточно косметических отличий будет для нас важно то, что кадр будет содержать только одно поле для адреса И причем этот адрес будет такой сложный, композитный В Ethernet мы отправляем кадры, там два Mac Кто отправил, кому отправил Здесь только один адрес Можно сказать, кому отправил То есть адреса отправителя у вас нет В этом адресе у вас будет несколько подполей То есть адрес это комплексная структура Q922 И мы разберем сейчас, как она строится и почему она именно такая Ну и да, как я уже говорил, таблицу коммутации нужно заполнять перед тем, как у вас будет коммутация, собственно говоря, осуществляться

Можно сделать это вручную, можно сделать это с помощью какого-то автоматизированного механизма Мы с вами как раз будем говорить про то, что чаще всего таблица коммутации во фрейм риле заполняется вручную И это будет услуга, которая называется Permanent Virtual Circuit, PVC Вы указываете, что у вас есть некая сеть фрейм рилея И в этой сети есть пользователи Пользователи самые разные Что такое пользователи во фрейм риле? Это компании, которые говорят, вот мне нужно между двумя точками присутствия сделать канал А провайдер говорит, ты знаешь, замечательно, я тебе сделаю такой канал Только, пожалуйста, учти, что у меня таких, как ты, десяток или сотня клиентов И у вас у каждого по несколько патчек роутеров Мне надо, чтобы вы друг другу в пределах своей подписки, своего маршрута могли посылать трафик А вот в другие какие-то пользовательские сетки не могли То есть, сейчас попробую порисовать немножко Вот у нас есть облако фрейм рилея И, соответственно, это провайдер

У этого провайдера много клиентов Вот, допустим, приходит нам клиент и говорит Мне нужно связать между собой точку присутствия 1, 2 и 3 Вот это вот Point of Presence 1 Point of Presence 2 И Point of Presence 3 Что в этом случае делает клиент? Он говорит, окей, давай я тебе плачу деньги Вот мне, пожалуйста, свяжи их между собой И, соответственно, клиент говорит Вот мне не надо полно связанной топологии У меня Point of Presence 2 и Point of Presence 3 Между собой не должны связываться Это филиалы, не знаю, условно, магазины отдельные Вот они между собой трайвки не гоняют У меня есть только Headquarters у Point of Presence 1 Вот мне только туда надо связь у каждого из филиалов И, соответственно, он платит деньги за 2 канала Точек присутствия 3, а каналов он покупает только 2 И вот, соответственно, у него будет Virtual Circuit 1 Virtual Circuit 2 Вот он, зелененький первый канал Синенький второй канал Между собой филиалы общаться не могут Вот этого канала, его нету, он не куплен

Поэтому Spock 1 на Spock 2 кадр послать не может При этом физически это все равно выглядит как то, что есть один интерфейс Поверх которого можно отправлять кадры Вот Hub может отправить кадр в сторону первого канала Может отправить кадр в сторону второго канала По одному и тому же интерфейсу Такие кадры дойдут до получателей Spock 1 может отправить кадр в свой физический интерфейс И там указать адрес Hub И кадр дойдет А вот адрес Spock он не сможет указать Потому что у него нету связи со Spock Он даже если укажет, что вот Я знаю почему-то адрес Spock 2 Потому что у нас Spock 2 прописан адрес там, не знаю, 1, 1, 1, 1 То есть он кадр отправится с адресом 1, 1, 1, 1 Он на свече зарубится Потому что нету такого купленного канала В таблице коммутации не прописано, что отсюда Вот сюда можно пускать трафик Это вот что касается Virtual Circuit Virtual Circuit состоит фактически из отдельных настроек в таблице коммутации На всех свечах по каналу

То есть этих свечей, вот их не обязательно будет 1 Там может быть 2, 3, 5, 10 свечей И получается, что, ну давайте вот здесь для определенности Напишем, что здесь вот 1 свеч, здесь 2 свеч, здесь 3 свеча Когда мы прописываем три таких виртуальных канала Мы говорим, что у нас есть вот виртуальный канал номер 1 Он говорит, что если что-то пришло вот из одного интерфейса Надо это отправить в сторону второго свеча И точно то же самое, если у нас пришел кадр с адресом 2 Это тоже надо отправить в сторону вот центрального свеча Надо отправить в сторону центрального свеча На центральном свече мы указываем, что если у нас что-то пришло в первом канале Оно пришло слева, и мы это отправляем наверх А если что-то пришло с меткой, что это во второй канал Оно пришло из того же интерфейса интерфейса, но мы это отправляем вниз на спок номер 2. То есть вот этот вот фрейм релай свитч, он получает кадры на входящем интерфейсе слева и дальше в зависимости от того, что написано в адресном поле, он принимает решение куда это коммутировать. Если пришло с меткой единички, то он отправляет это наверх.

Если пришло с меткой двоечка, он отправил вниз. Ну и наконец то же самое нужно будет сделать на всех свитчах. То есть сказать, что если вот здесь пришло с меткой единичка, мы отправляем это дальше направо. И естественно все то же самое нужно в обратном направлении будет прописать. То есть если у нас есть сейчас я сотру все слайда. Если у нас есть филиал, этот филиал у него тоже есть вот этот самый virtual circuit. Ну давайте назначим его единичкой. Если что-то пришло с меткой единичкой справа на наш фрейм релай свитч, это надо с меткой, ну допустим опять же единичкой отправить налево. И равным образом если что-то пришло с меткой двоечкой на свитч снизу, то это надо тоже отправить налево. Вот эти вот правила коммутации, их надо прописывать вручную, если мы говорим про permanent virtual circuit. К вам пришел клиент, сказал вам нужно, мне нужно связать между собой вот эти три точки присутствия. Вы сели, аккуратно прописали на всех фрейм релай свитчах все правила коммутации.

Кто откуда, куда, с какими адресами, как коммутируются. И все, и дальше после этого клиент нормально работает. Если у вас есть какой-то другой клиент, он будет делать точно то же самое. То есть у него есть, там вот здесь мы говорили, есть какой-то свитч, у него есть другой интерфейс. Он будет, соответственно, использовать другие номера меток. Вот здесь он будет отправлять метку, допустим, третью или четвертую. Понятное дело, что он не должен использовать те же самые номера меток, что и другие клиенты. Ну или, по крайней мере, это должно быть не на магистральных каналах. То есть не должно быть такого, чтобы у вас вот отсюда приходил кадр с меткой третьей и отсюда тоже приходил кадр с меткой третьей. И все это дело с меткой третьей же отправлялось в магистраль. Иначе просто непонятно будет, от кого и куда передается. Так, а что касается Switched Virtual Circuit. Это услуга по коммутации каналов, по установлению канала по требованию и терминации этого канала после того, как канал перестает быть нужен. Очень похоже на телефонию. То есть если вы вспомните, как была устроена аналоговая телефония,

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

И вот здесь, говорит, у нас, соответственно, будет метка номер один, здесь получается метка номер один. Мы установили канал, мы запустили как бы процедуру установления канала по требованию, мы получили все метки, мы начинаем отправлять кадр с метками до получателя. Как только закончили, условно говоря, повесили трубку, послали сигнал Hang On повесить трубку и вот эти метки освободились. То есть в таблице коммутации все записи стерлись. Эта штука требует, естественно, и настройки одноразовые перед тем, как все начнет работать и, собственно, процедуру установления и терминации маршрута по требованию. Но опять же, если у вас есть какая-то организация, которая подключилась по фрейм-рилею и она хочет, чтобы у нее был какой-то канал между какими-то точками присутствия, она чаще всего хочет, чтобы этот канал был всегда. Она не готова платить только за время ее использования. Изначально, когда все это дело придумывалось, предполагалось, что вот как бы коммутируемый канал, это будет более круто, потому что если кто-то посылает трафик немножко, а потом долго молчит, то вот нет смысла держать под него полосу зарезервированную.

Лучше в момент, когда ему будет надо, вот его прокоммутировать. Но по факту вы в этом случае не можете фактически гарантировать ничего, потому что если у вас будет одновременно пик установлений и вызовов с одинаковым максимальным приоритетом, вы фактически не сможете в этом случае переподписку никакую сделать. А если у вас нет переподписки, то получается, что вы можете использовать и permanent virtual circuit. Они проще в настройке, проще в дебаге, проще в обслуживании. Поэтому permanent virtual circuit, они были несколько более популярны, чем switch virtual circuit. Так, да. В любом случае вы отправляете кадры. И в этих кадрах есть определенное содержимое. Для начала нужно будет заметить, что кадры вы отправляете по битовой среде. Point-to-point среда, провод, в котором ровно два участника. Либо левый участник, либо правый. Как правило, это дуплексная среда. То есть у вас одновременно оба участника могут передавать данные в эту среду.

И, как правило, это среда, которая не позволяет в нее молчать. То есть в Ethernet у вас есть, ну как бы изначально был общий провод, в котором есть четкое понимание, что среда занята или среда свободна. В смысле, среда свободна или среда как бы используется. Что если никто не передает, там условно говоря 0 вольт. Напряжение между двумя. Двумя жилами. Если у вас начинается передача, то там будет условно либо плюс 0,7 вольта, либо минус 0,7 вольта. В зависимости от конкретного стандарта, в зависимости от много чего. Ну, короче, вы там чувствуете напряжение. Если вы чувствуете напряжение, значит связь есть. Если не чувствуете напряжение, значит тогда свободно можно передавать. Во Frame Relay предполагается, что вы будете использовать, ну скорее всего, телефонию. В телефонии можно передавать нолики, единички, но нельзя молчать. И поэтому, когда вы хотите передать пустоту, что вот вы ничего полезного не передаете, вы еще кадр не сообразили, какой вам передавать, вы должны все равно передавать чего-нибудь.

И вот это вот пустое чего-нибудь будет иметь очень характерный вид 0,1,1,1,1,1,0. Это байт, состоящий из 8 бит. И эти 8 бит, они содержат нули по краям и, соответственно, единички в серединке. Это 6 единиц подряд. Так же, как в HDLC и наследники его PPP, эта штука обозначает, что я ничего не передаю. Никогда, ни при каких обстоятельствах вы эти самые 6 единиц подряд не будете передавать в боевых данных. Если вдруг у вас возникла потребность 6 подряд единиц передать в боевых данных, либо внутри одного байта, либо на стыке между несколькими кадрами, вы всегда после 5 бит единиц добавляете один ничего не значащий 0. Этот 0 получатель, когда увидит, он его выкинет. Он понимает, что если пришло 5 единиц и 0, этот 0 неважный. Он не содержался в исходных данных. Его просто добавили, чтобы 6 единиц подряд не было. А если вдруг у вас передаются 6 единиц подряд, это точно означает пустую среду. Значит, точно означает, что предыдущий кадр закончился.

Это причем может быть подчеркнут даже внутри, даже в нескольких кадрах. То есть, если у вас был какой-то кадр, допустим, 0,0,0,0,1,1,1,1,1. Это у нас 0x0f. А потом следующий кадр был 1,1,0,0,0,0,0,0. Не кадр, естественно, байт. То есть, у вас 2 байта подряд передавалось 0x0f. И дальше вот здесь вот это что у нас? 8,4,12. Это c0xc0. Вот у этих 2 байт 6 единиц подряд передается. Вот отправитель, когда будет пытаться такое передавать, он вам влепит вот здесь вот еще один ненужный нолик. И, соответственно, получатель, когда получит 5 единиц подряд, он этот нолик выкинет и сможет получить исходное значение. В общем, та же самая история, да, что вы ее ждете. Велосипи пипи. Флаги вы передаете постоянно, пока не хотите ничего передавать.

Как только вы начали что-то передавать, вы передаете первым делом адрес. Преамбула в азернете, как вы помните, была нужна для того, чтобы занять среду. И там она передавалась сразу после тишины. Здесь у нас нету такого понятия, как нам нужно занять среду. Поэтому после тишины, представленной флагами, никакая преамбула не нужна. Мы можем переходить сразу к тому, что было в азернете после преамбула. После преамбула была адресная информация. Точно так же и здесь. Что вот в азернете у нас после тишины была бы преамбула. Преамбл. Здесь ее не нужно. Вот, сразу идут адреса. Адрес в азернете у нас фиксированного размера. 6 байт MAC адрес получателя, 6 байт MAC адрес источника. Здесь адрес это сложная структура Q922 адрес, которая занимает непредсказуемое количество байт. Это очень хитрый момент. Во фрейм рилее адреса, да, они сложные. Во-первых, само место, куда можно вписать адрес, имеет непредсказуемый размер.

А во-вторых, то, что вот именно там чистая адресная информация, она еще и, кроме всего прочего, по границе байта не выровнена. То есть это такой уникальный протокол, у которого адреса произвольные, но заведомо кривые. Эта структура, она будет содержать в себе под поля. Во-первых, DLCI, Data Link Connection Identifier, это, собственно, вот то, что является адресом. Оно будет разбито по нескольким байтам. То есть минимум поле адрес занимает 2 байта. Первый и второй, как ни странно. То есть байт, который передается по сети первым, байт, который передается по сети вторым. Вот часть DLCI будет в начале первого байта, а потом будет какое-то еще другое значение. А часть DLCI будет в начале второго байта. И тоже там в конце байта будет тоже всякое разное значение. Если у вас будет 3 или 4 байта в поле адрес, то, соответственно, у вас DLCI будет содержаться в начале каждого из этих байтов. Кусочек DLCI. И, соответственно, вам нужно будет понимать, закончился ли уже адрес или еще не закончился.

В конце каждого из байтов будет последний битик, называться EA. Сейчас, как же он называется-то? Extended Addressing. Вот. И этот битик будет означать, что закончилось ли уже поле с адресом или не закончилось. Похожая история есть в заголовке IP. Там у нас, если помните, фрагментация была. Если вы взяли, разбили пакет на несколько фрагментов, то у каждого фрагмента был флажок. Это еще дальше данные будут или это уже последний фрагмент. Вот здесь та же самая история, только с точностью до наоборот. Если в IP у нас флаг назывался MoreFragments и в непоследних пакетах он выставлен был в единицу, а в самом последнем в ноле. То здесь наоборот. Ноль означает, что это непоследний фрагмент, непоследний байт адреса. Единичка. Что это вот последний байт. Что дальше уже адрес закончился. Началось что-то еще. Дальше. Из HDLC протокола, причем подчеркну не цисковского, а оригинального HDLC, который для мейнфреймов был некрофильский стандарт, взят BTCR, Command Response.

В HDLC у вас было, как бы это сказать, не было возможности, кому попало, куда попало, отправлять, какие попало кадры. У вас был терминал и был мейнфрейм. Терминалов было много, мейнфрейм один. И, соответственно, вы из терминала вписали команды, а дальше с мейнфрейма вам возвращался ответ. И у вас по этому самому битику CR в HDLC было понятно, куда этот кадр передается, на терминал или на мейнфреймы. Вот в HDLC этот был битик полезный. Здесь его просто так для совместимости нарисовали. Для того, чтобы высокоуровневые приложения, которые фреймрилей использовали, могли бы эмулировать HDLC поверх фреймрилея. Но, да, в реальности не используются. И, наконец, битики управления качеством. FECON, BECON и DE. Начнем с последнего. DE это Discard Eligibility. В общем, битик, в котором вы указываете, можно ли этот кадр прибивать при перегрузке или нельзя.

Если вы выставляете нолик, это значит, что этот кадр нельзя убивать ни в коем случае, что вы претендуете на гарантированную полосу. Или, соответственно, вы можете выставить Discard Eligible в нолик и говорите, что вот если у нас возникла перегрузка, то есть кадры важные, а есть кадры не очень важные. Вот этим кадрам лучше пожертвовать, чтобы оставить полосу для очень важных кадров. Понятное дело, что вы можете промаркировать все, как это все очень важные кадры. Но тогда провайдер будет убивать все подряд. Без разбора на важные и неважные. Вы можете ему продиктовать, дать инструкцию, что если у тебя возникает перегрузка, вот этих убивай в первую очередь. Понятно, что ты убивать будешь, ты не можешь математически пропихнуть все в один и тот же канал. Но вот хотя бы не прибей то, что действительно важно. Телефония, какой-то трафик, прям бизнес-критикал приложения. Не знаю, вот образцово показать, например, биржевые сводки. Что если у вас передаются данные биржи, одно из первых применений для фреймрилейма в Москве было как раз биржа.

То как раз вы маркировали такие бизнес-критикал данные, битиком Discard Eligible, что это нельзя убивать ни в коем случае. А дальше, если полоса пропускания осталась в интерфейсе, можете добить это все какими-то менее важными данными. Интернетиком, например, какими-то, не знаю, ВКонтактиками, условно. Главное, что если у вас будут передаваться и важные данные одновременно, и условный ВКонтактик, то ВКонтактик пострадает первым. Дальше, соответственно, FECON и BECON. Два бита, они в большой степени заимствованы в других протоколах, немножко там в IPTCP. Смысл будет следующий. Если у вас возникла перегрузка, и кадр прокоммутировали мы все равно, но его соседа пристрелили, то есть у нас возник выбор, кого пристрелить, и мы взяли и пропустили кадр, а вот другой кадр, который был не настолько удачным, мы все-таки вынуждены были пристрелить, то в том кадре, который все-таки выжил, провайдер проставляет битик FECON.

Forward Explicit Congestion Notification Bit. Тогда, когда получатель, до получателя дойдет такой кадр, он поймет, что где-то в сети есть затык, и столько кадров посылать не надо. Но он получатель, он ничего не отправляет, он только получает. Поэтому ему, чтобы отправить сообщение изначальному источнику, нужно дать уведомление, что вот дорогой источник ты слишком много посылаешь, притормози, а то там затык где-то. И для этого нужен флаг BECON. FECON идет вперед к получателю, BECON идет от получателя к источнику. Какие кадры, которые будут отправлять источник в сторону, в смысле в сторону источника оригинальный получатель, он будет отправлять с установленным флагом BECON. BECON – это Backward Explicit Congestion Notification, что в сторону получателя где-то случился затык, и получатель об этом уведомляет источника. Вот. Как это все дело выглядит? У нас есть роутер, ну или свитч, давайте назовем его свитч. Сейчас попробую нарисовать такую картинку с фреймрилеевским роутером.

У него есть интерфейс, здесь у нас узел А, здесь у нас узел Б. Как-то плохо получается, но неважно. Узел А посылает кадр. В этом кадре у нас стоит какой-то, ну просто обычный кадр, короче, послали. Роутер. У него не только эти два узла А и Б, у него еще десяток других каналов есть. У него через коммутируемые сети еще приходят какие-то левые кадры. В общем, он этот кадр пропускает, но он выставляет флаг F, FECON, что здесь где-то случился затык. Вот, допустим, отсюда кадры уже не прошли из-за затыка. А вот наш кадр от узла А до узла Б дошел. Вот узел Б говорит, ага, вижу пострадавшего. И, соответственно, в обратную сторону он выставляет BECON, BACKWARTH EXPLICIT CONGESTIMENT NOTIFICATION, и такой кадр уже нормально проходит до узла А. И узел А понимает, что ага, у нас до узла Б возникла проблема с коммутацией, что надо притормозить его в сторону и поменьше отправлять, а то оно может не дойти.

Так, это что касается структуры адреса. Вот такая вот она, достаточно сложная. Для нас важно то, что есть вот это вот самое поле DLCI, Data Link Connection Identifier. Это сама адресная информация по типу MAC адреса в Ethernet. То есть смысл ее примерно такой же, что вот это та самая адресная информация, на которой осуществляется коммутация. Но другой разговор, что поле адреса, да, оно само по себе сложное, и там есть некоторые служебные поля. Дальше идет поле с данными и чек-сумма. Чек-сумма CRC16, про нее тут уже, в общем, ничего не расскажешь. А с информацией ситуация следующая. В Ethernet у нас было ограничение снизу на разбир с данными, потому что могла возникнуть коллизия. Во Frame Relay коллизий быть не может. То есть Frame Relay это протокол, который изначально создавался для Point-to-Point подключения. У вас всегда в проводе ровно два участника. Они коллизию между собой не устроят. Поэтому минимальный размер данной, который вы можете передать, это 1 байт. Вот хотя бы 1 байт передали, уже хорошо. 0 байт передавать как-то грешновато, а 1 уже вполне нормально.

Максимальный размер поля с данными может быть следующим. В стандарте написано, что любое устройство, которое поддерживает Frame Relay, обязано поддерживать поле с данными не менее чем 262 байтовой длины. По факту, если вы возьмете и попытаетесь использовать Frame Relay в реальности, то вы, скорее всего, захотите гонять пакеты айпишные. Айпишные пакеты чаще всего у нас бывают до 1500 байт размером. Поэтому консорциум из CISC, Nortel, DECO и Stratocom сказал, давайте мы будем все-таки использовать какой-то более разумный размер Frame Relay кадров. Что вот 1500 байт должно быть обязательно допустимо отправлять во Frame Relay кадрах. Поэтому в консорциуме CISC, вот этом консорциуме CISC, Nortel, DECO, Stratocom сказали, 1600 байт будет вполне нормально. Что вот если у нас есть устройство, которое Frame Relay поддерживает, то до 1600 байт оно должно раскачиваться.

В пределах одного кадра. На что это влияет? На буферы, на то, как, соответственно, часто нужно будет отправлять кадры, на то, сколько кадров можно в буфер поместить перед тем, как первый из них начнет отправляться. То есть это действительно намного влияет на транзитных узлах. На получателя, отправителя, с точки зрения именно физики и канального уровня, это не сильно влияет. А вот на транзитные узлы сильно. И получатель, он получает возможность получать, получать, ну и отправитель отправляет, соответственно, кадры, содержащие IP-пакеты, которые до 1500 байт могут быть. Так, и здесь мы плавно подходим к тому, что внутри этих самых данных может содержаться разная хитрая информация. Если вы посмотрите, давайте сейчас покажу еще раз на слайд, здесь не написано, что внутри лежит. И возникла та же самая беда, на самом деле, что с протоколом Ethernet. Вот, помните, там 802.3 формат был и Ethernet.2 формат. Потому что в Ethernet.2, изначально как бы придуманный формат Ethernet,

там не было написано, чего внутри лежит. Там зато было написано, точнее, там было написано, что внутри лежит, там не было написано, сколько это внутри лежит. Но в Ethernet это было нужно, потому что там не совсем было понятно, как это дело определять автоматически. Во Frame Relay, соответственно, здесь просто указывается, что есть какое-то содержимое. А дальше все это дело на откуп тем организациям, которые регулируют доступ к сетевому уровню. И таких организаций оказалась примерно одна. Это и ETF. И ETF сказала, да, у нас есть замечательный протокол, он организует, соответственно, связь между двумя участниками. Нам нужно написать, что внутри лежит, сколько это внутри лежит. Написать не обязательно, потому что и так понятно. Все, что в кадре получилось, все надо передать на уровень выше. Поэтому вот ETF-ный формат кадра, он следующий. Недолго думая, они сказали, у нас есть уже замечательный протокол, который называется PPP. У него после поля с адресом,

вот это поля с адресом, это адресная информация Q922. Поле с адресом в PPP тоже есть, там 1 байт FF, в общем, нас не сильно интересует. После 1 байт этого поля адреса в PPP у нас шло контрольное слово 0x03. Дальше шло указание, что внутри лежит, и там всякие NCP, LCP, вот это вот все, что внутри лежит, IP. Здесь та же самая история, что если вы хотите IPv4 указывать, вы здесь, например, указываете 0xCC. То есть точно тот же самый формат, что в PPP. Давайте назовем ETF-ный, это PPP. И дальше идет поле с данными. Ну и чексума, которая от самого фрейм релея. То есть этот формат, он заимствован от протокола PPP. Учитывая, что поле с адресом может быть кривое, оно может быть от 2 до 4 байт, включая, например, 3 байта. Иногда для некоторых случаев может понадобиться паддинг. То есть вы указываете контрольное слово 0x03,

а потом, если нужно, добавляете еще один пустой байт нулевой. Для случая с нормальными, красивыми 2-байтовыми адресами этого делать не нужно. У вас 2-байтовое поле с адресом, 2-байтовое поле... В смысле, 2-байтовое... 1-байтовое поле control, 1-байтовое поле протокол. Если нужно использовать какой-то протокол, который достаточно популярный, ну, например, там IPv4 или IPv6, то вы указываете прямо, что внутри лежит сразу. Если вам нужно указывать, что там внутри лежит какое-то хитрое вложение, у вас всегда есть возможность использовать snap. ЦИСК на это дело посмотрел и сказал, эй, батеньки, вы знаете, мы так с вами далеко не уйдем, потому что вот эти вот все игры со snap, мы это уже проходили. Вы там придумывали дорогие ETF, всякие LLC вложения, snap вложения. Не, не, не, хватит этого всего. Давайте сделаем проще. Сделаем поле EtherType. Как в Ethernet. Классический чистый Ethernet. У нас есть поле, адрес, потом, что внутри лежит EtherType, потом данные, потом чек-сума. Это фирменный цисковский стандарт.

Ну, не цисковский, консорциумовский. Это фактически, да, Ethernet. Вы видите, что на самом деле эти форматы, да, они очень похожи. Вот этот вот кадр, это получается PPP-шный кадр, вот этот кадр, это получается Ethernet-овский кадр. Один в один. Ничего нового. Что касается того, что у нас есть, получается, два формата данных, которые друг с другом несовместимы, а они действительно несовместимы. Все, что содержится внутри поля Information, оно неинтересно транзитным свитчам Frame Relay. Поэтому у вас инкапсуляция должна совпадать на уровне конечных узлов. Конечные узлы во Frame Relay называются DTE, Data Terminating Equipment. И вы фактически задаете это на уровне, я написал DLCI, да, давайте напишем PVC или SVC. То есть у вас есть канал связи от одной DTE-шки к другой DTE-шки от пользовательского устройства к другому пользовательскому устройству. И, соответственно, вот в этом виртуальном канале вы должны будете соблюдать

определенное соглашение о том, какие кадры вы используете. С Васей вы используете CISC-овский формат, с Петей вы используете ETF-ский формат. И все это дело в одном интерфейсе. В изолнете у вас, как вы помните, нельзя смешивать разные кадры фактически в одном этом же интерфейсе. Что если вы отправляете кадры, но они всегда одинаковые, вы знаете, там особо не поиграешь. А здесь вот можно говорить, вот эти кадры мы отправляем Вася, вот эти Петя. Вася CISC-овский, поэтому он понимает, что такое внутри изолтае. Петя ETF-овский, поэтому мы ему используем фактически эмуляцию PPV. Так, что касается адресации, те самые PVC. Адресация, да, как уже говорилось, может быть произвольной длины, но не совсем произвольной, там есть несколько вариантов, которые она может быть по длине, причем не кратная байту. FrameRelay – это удивительный протокол, в котором, ну, единственно известный мне, в котором размер поля с адресом не кратен байту. Так, чаще всего, если у вас поле двухбайтовое, используется 10-битные

DLC-ки, и если у вас двухбайтовое поле адрес, тот самый Q922, то формат его будет следующий. Первые 6 байт, бит первого байта, вот этот вот, 6 бит, они будут, соответственно, содержать первые 6 бит в DLC-ки. Дальше, флаг CommandResponse и указание, это не последний байт, не последний, да, байт адреса. А дальше, оставшиеся 4 бита адреса, флаги FECON-BECON, указание DiscardEligibility и указание, что все, адрес закончился. Если у вас будут другие байты использоваться, то вы можете здесь вот еще сверху наколбасить еще себе байтов, соответственно, там будет тоже 6 или там 7 байт, 7 бит DLC-ки и IA-шка будет 0. Для того, чтобы использовать вот эти вот кривые DLC-ки, которые вот не 10-битные, а какие-то другие и, соответственно, поле с адресом не 2-байтовое,

а 3-х или 4-байтовое, у вас должна быть хитрая сигнализация, про которую мы поговорим дальше. То есть это все не совсем стандартное. Что касается самих этих самых DLC-ек. это DLC-ки, это 10-битовые значения, которые значимые и уникальные в пределах физической среды. Что это значит? Что если у вас есть коммутация кадров, у вас с одной стороны кадр приходит, в другой физический провод этот кадр будет уходить после коммутации. Так вот, это самое поле с DLC-кой, оно может меняться. В Ethernet такого никогда не было. В Ethernet, если у вас с одной стороны приходили кадры, они всегда в другой интерфейс уходили с теми же самыми адресными значениями. С одной стороны получили кадр с таким Mac, в другую сторону отправили кадр по таблице коммутации и Mac'и там естественно сохранились. Во фрэмли-лейе DLC-ки могут меняться. Фактически, когда вы прописываете

PVC-шку, вы указываете не только кто кому куда может отправлять данные, но и то, какие DLC-ки на какие вы будете менять. То есть, если у вас есть, давайте сейчас опять же нарисуем, свитч, как-то так рисуется, раз, два, здесь тоже свитч, здесь тоже свитч, да я уже не буду рисовать, свитч и свитч. И есть у нас узлы, конечные абоненты и связи между свитчами. Мы отправляем кадр с адресом единичка. У нас есть правило коммутации, по которому мы говорим, что если что-то приходит слева с адресом единичка, мы это отправляем направо, в интерфейс направо с измененной DLCI, допустим, DLCI уже будет, не знаю, 100. Дальше на втором свитче мы говорим, когда у нас что-то приходит с адресом 100 слева, мы это отправляем направо с адресом, ну не знаю, 17. И последнее правило на правом свитче, соответственно, говорим, что если что-то приходит с 17 адресом,

мы это прописываем на 34 адрес, на 34-ю DLCI в сторону получателя. поэтому внутри кадра у вас может меняться DLCI по заданным правилам. И эти правила прописываются на свитчах. Вы говорите, какие DLCI должны быть в входящих кадрах, на каком интерфейсе, и на какие DLCI мы переписываем все это, соответственно, на выходном интерфейсе. И фактически, когда вы прописываете PVC, он будет состоять, этот самый PVC, из вот этих вот правил, что, кому, куда отправляем, какие DLCI всякие, на какие перебиваем. Так, дальше. Вот эта самая таблица, она будет выглядеть примерно следующим образом. У нас есть для простоты Frame Relay. Вот он. Он представлен в виде просто роутера, ну, написано FR Switch, так что не обращайте внимания, что нарисован роутер. На самом деле, это Frame Relay Switch. И у нас есть три пользовательские железки.

роутер 1, роутер 2 и роутер 3. Они все между собой связаны какими-то, как это сказать, какими-то интерфейсами. У нас есть канал. Мы прописываем канал связи между роутером 1 и роутером 2. Вот эта вот штука будет называться PVC, Permane Virtual Circuit. R1 знает, что этот PVC есть. У него есть указание, что есть PVC в сторону R2. Но у него есть указание, что когда мы отправляем кадры в сторону R2, мы должны отправлять эти кадры с DLC 102. И он отправляет такой кадр и указывает 102 адрес. На свече есть указание, что если что-то приходит с 102 DLC, это надо прокоммутировать и выплюнуть на сериал 1.2 с указанием 201 DLC. Это правило, вот оно. То есть, если у нас что-то приходит на сериал 1.1, вот он, сериал 1.1, с DLC, входящий 102, это надо отправить на интерфейс

сериал 1.2 с выходной DLC, 201. Абсолютно аналогично, если у нас что-то приходит на... не приходит, если что-то должно уйти с роутера R1 на роутер R3, это тоже PVC-шка, отдельная, купленная. Соответственно, у роутера R1 есть указание, что PVC-шка 103 на R2, R2... PVC-шка для R2 использует DLC-ку 103. Вот он говорит, я отправляю кадр, который будет отправляться в сторону R3, я указываю DLC-103. Этот кадр приходит на свитч с меткой 103, и у свитча есть указание, что если что-то приходит слева с меткой 103, мы отправляем с 301-й DLC-кой на роутер R3, на S3 интерфейс. Вот оно, что если что-то пришло, входящее на S1 1 интерфейс с меткой 103, мы это коммутируем на S1 3, на 301. В Ethernet таблица коммутации пополнялась автоматически.

Здесь надо все вручную прописывать. То есть администратор сети FrameRelay, когда к нему пришел, клиент и сказал, я хочу купить вот эти два канала между R1 и R2 и между R1 и R3. Вот, соответственно, он взял, вздохнул и прописал, что вот отсюда туда коммутируем с вот такими правилами по изменению. Что если приходит что-то вот с S1 1 со 102 меткой, коммутируем на S1 2 с 201 меткой. Причем это все односторонняя коммутация. То есть если вдруг будут идти ответы, ответы тоже должны идти. Вот здесь вот у нас будет указание, соответственно, что вот 201 метку будет от R2 посылать. Поэтому должно быть в обратную сторону. Что если что-то пришло с 201 меткой с Serial 1 2, это надо прокоммутировать обратно с меткой 102. Поэтому администратор опять тяжело вздохнул и прописал все обратные правила коммутации. Что вот такой вот интерфейс S1 2 входящий 201 метка будет S1 1 102 метка исходящая. Здесь то же самое. S1 3 301 коммутируется в S1 1 103. Здесь вы уже,

наверное, если кто-то знаком, поняли, что на что-то это напомекает. Ну да. Не спешите раскрывать тайну. Да, естественно, что есть такой протокол, который вырос из Frame Relay и мы про него естественно отдельно проговорим. Запомните вот эту табличку, если вы не знаете, про что идет речь. Что во Frame Relay была на каждом маршрутизаторе заранее составленная табличка. Что-то пришло с одного интерфейса с такой-то меткой, это надо отправить в другой интерфейс с другой меткой. Так. Дальше. После того, как мы узнали, что есть PVC-шки, и эти PVC-шки состоят из кучи правил коммутации, какие дел сяйки, в какие, куда мы перебиваем. Дальше возник вопрос, а как узнать, вот какие дел сяйки, они вообще рабочие, не рабочие, то есть у нас этих дел сяйок там много, даже если они 10-битовые, это 1024 разных варианта, какие можно отправить. Вот какие из них по факту задействованы, какие нет. Если у вас есть среда,

фрейм релеевская, там, как правило, скорости маленькие, то есть это речь идет про десятки, может быть, сотни килобит в секунду. Когда это создавалось, это были очень крутые скорости. И если вы можете что-то отправить в канал, то вы должны понимать, оно скорее всего дойдет или скорее всего не дойдет. Если с той стороны сдох узел, нет смысла вообще ему ничего отправлять. Поэтому во фрейм реле есть сигнализация, так называемая. Она называется специфическим термином LMI, Local Management Interface. Когда давным-давно это что-то означало, сейчас просто запомните, что это LMI, это сигнализация. В Ethernet классическом ее нету, но в провайдерских Ethernet оно есть. Он называется OAM, Operations, Administration, Management. Но если вы не работали с провайдерским Ethernet, то вам, наверное, это ничего не скажет. Ну так вот, что это такое? Это способ узнать о том, какие дел сяйки находятся в каком состоянии. То есть, если бы это было в классическом Ethernet, ну, если бы мы посмотрели

на провайдерский Ethernet, там аналогичная штука OAM позволила бы узнать, какие MAC-адреса в сети есть, с какими MAC-адресами у вас есть связь, и какие из них живы или не живы. То есть, вы как потребитель слушали бы сообщения сигнализации, или, допустим, отправляли бы запрос на сигнализацию, вам приходил бы ответ, и вы бы сразу понимали, в сети живы MAC-адреса 1, 2, 3, 4, а 5, вот нету его. То есть, может быть, там сказали, вот должен быть MAC-адрес 5, но что-то вот как-то с ним проблема, до него кадры не доходят. А до 6 перегрузка в сети, не надо им отправлять ничего. Вот такие вот штуки во фрейм-рилее были в 90-м году. У вас она должна совпадать на всех следах, простите, этих сигнализаций несколько типов. Один из типов, который называется unscishный, он рекомендован для использования в PVC, то есть он адресно заточен под то, чтобы использовать PVC-каналы. И он по этой причине довольно часто используется.

Второй вариант, etushный, он используется в основном для SVC. То есть, если у вас перманентный virtual circuit, вы используете unscishный, если у вас switch virtual circuit, вы используете etushный. Оба два типа сигнализации они используют для вот этих кадров сайной сигнализации точно такие же кадры фрейм-рилей. Но для того, чтобы подчеркнуть, что вот этот кадр особенный, это не пользовательские данные, а вот именно сигнализация, они используют номер DLC-ки 0. Соответственно, 0 зарезервированный кадр, для пользователей остаются номера DLC-ки с 16 по 976. То есть, если вы используете стандартные 10-битные DLC-ки, то вот этот диапазон 16-976 вы можете использовать. Что касается различия между ними, они заключаются в формате пакета, они заключаются в том, что там в одном случае удобно использовать перманентный канал, в другом коммутируемые каналы, поскольку с фрейм-рилейом

вы связываться не будете, фактически вам это знать уже не надо. Они различаются форматом кадра. С точки зрения плюшек, у них между ними вот нулевые различия, то есть, нету такого, что в одном случае вам доступно что-то прям такое ах, чего нету в другом. Просто они чуть более удобны для каждого своего варианта. Консорцию Cisco, Nortel, DEC и Stratacom на это все дело посмотрели и сказали, а давайте мы сделаем свой проприетарный, вендорский, уникальный и дорогой, естественно, формат сигнализации, в котором можно было бы делать всякое. Во-первых, сделаем какое-нибудь подобие мультикаста. То есть, его мультикаста там полноценного не появится, но зато можно будет хотя бы как-то намекать на то, что Switch умный, он может нам что-нибудь такое на мультикаст похожее сообразить. Во-вторых, скажем, что у нас есть Flow Control. Как раз сигнализация, что до какого-то узла есть перегрузка в сети и как бы узел формально доступен,

но до него, скорее всего, кадры не пойдут. Есть, соответственно, всякие другие няшки, которые в цисковском варианте, в этом консорциумском варианте появились, но они не так популярны, поэтому по факту есть кое-какие плюшки, которые можно использовать в случае с таким типом сигнализации. Главная плюшка заключается в том, что вы можете использовать дополнительные номера DLC, если вдруг вам не хватает штатной тысячи. Для своей работы фирменная цисковская, ну, оно как бы известно под именем цисковская сигнализация LMI, на самом деле разработанная то, что вся штука Нортелла, для работы цисковской сигнализации используется другой номер DLC, не нулевой, а 1023, то есть не самый первый, который можно использовать, самый последний. И для пользователей доступно чуть побольше DLC, с 16 по 1007. Ну, опять же, тут кто-то может вспомнить номера Виланов в фирменном цисковском протоколе

VTP, которые там тоже в этом же диапазоне заканчивались, там, 1200, 1300, 1400, 1500, фирменные, родные, дальше вот с 1600 началось расширенное поле. Но здесь вот тоже циска пошла и свои любимые циферки 1000 плюс какая-то мелочь использовала для DLC. Ну, естественно, что этот вот тип сигнализации он поддерживается не всеми устройствами, а только теми, которые несут правильный шильдик. Если вы связываете между собой какие-то произвольные железки, причем не просто связываете, вы провайдер, у вас есть фрейм релеевская сеть, вот если у вас все свечи и все клиентские железки не фрейм релеи поголовно, не циска поголовно, вы скорее всего захотите использовать стандартные и тушные или античные сигнализацию. И клиентов вы тогда обязываете использовать именно ее. Так, что касается, что касается, что касается, да,

в нашем случае сигнализация, которая у нас будет, она позволит нам узнать, кто живой в сети, а кто не живой. вот вы периодически можете отправлять запрос LMI inquiry и, соответственно, inquiry и вам будут возвращаться сообщения LMI статус. Эти сообщения, они могут бегать также внепланово, то есть вы можете отправлять inquiry, можете не отправлять и статусы вам, соответственно, будут приходить. По этим LMI очень удобно определять, жив интерфейс или нет, потому что штатно большая часть оборудования настроена на то, чтобы примерно раз в 10 секунд посылать inquiry. Да, вот тут вопрос, как часто отправляются. Примерно раз в 10 секунд. Можно это рассматривать как своего рода индикатор работоспособности канала. Если вы видите, что у вас на интерфейсе настроен фрейм релей, вот никаких других настроек нету, ни PVC-шки не прописаны, ничего вообще нету, вы отправляете LMI inquiry, вам возвращается LMI статус. Это значит, что фрейм релей живой, что с той стороны фрейм релей настроен, что сигнализация правильная,

что настройки типа сигнализации совпадают. Значит, по всем остальным вопросам можно грызть мозг провайдера и говорить, дорогой провайдер, ты мне не прописал PVC-шку, если у вас что-то не работает. Если вы отправляете inquiry, а статусы вам не приходят, ну, значит, что-то не в порядке. Вот, да, как часто отправляются, все зависит от конкретной железки, но вот нацистский, раз в 10 секунд. Что касается того, что внутри этого статуса будет написано. Вы отправляете указания, какие дел сяйки с вашей стороны прописаны, если у вас где-то какие-то прописаны. LMI статус указывает, какие дел сяйки известны свечу. И в нашем случае вот он будет отправлять сообщение, что с 102 дел сяйкой, ой, пардон, что-то у меня здесь не в порядке. Со 102 дел сяйкой все в порядке. Вот, а с 103 дел сяйкой какая-то беда, что вот дальше в коммутируемое, не в коммутируемое, в permanent virtual circuit

вот здесь вот случился затык, поэтому в 103 дел сяйку нет смысла посылать данные. С точки зрения вот этого канала сам канал живой. Только 102 кадры пройдут через него, а 103 дальше споткнутся. И сигнализация скажет, 102 дел сяйка активная, 103 дел сяйка нестабильная, не рабочая. Не надо туда отправлять данные. И вы можете сопоставить те дел сяйки, которые прописаны у вас, с теми, которые пришли в статусе, в статистике. И вы можете тогда по этому списку понять, что стоит отправлять, что не стоит. Если вам сосед свеч говорит, что вот у тебя есть какая-то дел сяйка, не знаю, 120, которого прописано, значит, певисишку для нее провайдер прописал, а ты ее не используешь. Но это повод как бы насторожиться и понять, не платишь ли ты деньги, непонятно за что. Если же ты у себя прописал, там, не знаю, 120 дел сяйку, а в статусе ее не приходит, ну, значит, надо мозг провайдеру грызть, говорить, что вот, дорогой провайдер, я ожидаю от тебя, что 120 дел сяйка будет коммутироваться.

А у тебя в статистике она не приходит, и, как бы, коммутация тоже не осуществляется. Статистика штук, не статистика, а сигнализация штук во фрейм рилей довольно ленивая, то есть, времени на то, чтобы все свечи сообразили, что происходит, и отправили правильные сообщения, ну, нужно довольно много. То есть, если вы где-то прописали связь между свечами, то времени на то, чтобы правильные статусы уже начали вам приходить, может понадобиться довольно много. Если говорить про даже достаточно простую сеть, вот типа той, которая на картинке нарисована, когда у нас всего один свеч, вы на нем прописываете правила коммутации, и, ну, пару минут вполне может потребоваться для того, чтобы он очухался и начал новые статусы присылать. Поэтому не ожидайте, что это прям немедленное сообщение будет. Это нужно для того, чтобы немножко повысить эффективность. Это не нужно для того, чтобы вы точно знали, что вот дальше там точно не работает или точно работает. Это лишь такой подспорье для того, чтобы вы могли как-то более эффективно работать.

Так. Да. Соответственно, если вы видите, что в статусах перестало приходить сообщение, что там какая-то DLC-кожевая, это не значит, что вот узел упал только что. Он мог упасть пару-тройку минут назад. Так. Дальше. Если вы хотите использовать поверх фреймрилея какой-нибудь протокол, ну, например, вот некоторые хотят использовать протокол IP. Странные люди, но бывают и такие. Вам понадобится механизм, с помощью которого вы IP-адреса будете резолвить в адреса фреймрилеевские. В Азернете за это отвечает протокол ИРП. Если у вас есть браткаст, вы берете и говорите, я хочу отправить кадр 172, 168, 1, 2 или там, 5, 7. А ну-ка, у кого такой IP-шник, скажите свой Mac. Херачьте на всю сетку браткастом, и вам приходит сообщение. У меня такой Mac, я вот услышал твой браткаст и отвечаю тебе. Здесь, соответственно, ситуация другая. Здесь вы не можете браткастом

на всю сеть заорать, мужики, у кого такой IP-шник, скажите свой Mac. Вы даже мультикастом не можете заорать, потому что мультикаста нету тоже. Поэтому вы должны будете заранее знать, кому вы отправляете кадр, перед тем, как вы ему что-то отправите. Если вы хотите спросить, у кого такой MAC, у кого такой IP-шник, простите, скажите свой MAC, вам для этого АРП не подходит. Что же делать? Выхода нет. или есть, или нет. А есть один вариант просто тупо прописать статически, что у IP-шника 172, 168, 5, 7, DLC-йка сотая, а у IP-шника 172, 168, 19, 1, DLC-йка трехсотая. Это не так много работы, как может показаться. В Эзернете прописывать придется всех на всех. То есть, если у вас там 10 узлов в Эзернет-сети, вам придется на каждом узле 9 соседей прописать. Это много работы. Во Frame Relay у вас каналов не так много. Каждый канал состоит всего лишь из двух участников. Поэтому,

если вы купили 5 PVC-шек, вам придется всего 10 маппингов прописать. Это допустимое количество работы. Оно одноразовое. Узлы у вас меняться будут редко. В Эзернете у вас постоянно приходят новые и уходят старые. Прописывать постоянно в актуальном состоянии поддерживать таблицу маппингов это вручную удовольствие такое очень сомнительное. Во Frame Relay ничего страшного нет. Один раз прописали оно работает. Но все равно как бы лень двигателя прогресса. Администраторы сети они люди особенно ленивые. Особенно двигатели прогресса. Поэтому они придумали следующую штуку. Если у нас есть сигнализация и она живая, давайте мы посмотрим какие в LMI приходят живые DLCI и в эти живые DLCI напихаем мы же знаем канальный адрес мы же знаем DLCI мы напихаем им сообщение мой IP вот такой и до получателя придут такие сообщения и он сможет такие сообщения принять к себе и записать что вот какое-то сообщение с IP не знаю 172 16 1

1 внутри пришло из-под какой-то его собственной DLCI какая DLCI у него в последнем плече канала мы не знаем мы только свое плечо знаем но вот у нас есть фрейм рилеевское облако вот у нас есть свой IP 172 16 5 5 и у нас от фрейм рилея LMI пришла что сотый DLCI живая то есть мы отправили запрос на инквари нам пришло сообщение сотка живая мы отправили туда сообщение привет я 172 168 5 5 то же самое сделал другой свитч другой роутер но это сейчас не важно и этот самый PVC она вот такая вот но она состоит из нескольких плечей вот здесь вот у нас плечо DLCI сотый здесь у нас плечо там не знаю 173 здесь плечо не знаю 201 и вот здесь плечо последнее 400 эти DLCI меняются по цепочке и эти цепочки мы как получатель не знаем но мы знаем только свой вот этот вот номер живой сотый DLCI мы туда отправляем отправляем кадр сотый DLCI

он меняется на 173 он меняется на 201 меняется на 400 и вот из 400 DLCI выплевывается с другого конца и другой конец получает сообщение привет меня зовут 172 168 55 и 400 DLCI и другой конец может у себя где-нибудь пометочку сделать 172 168 55 сидит за 400 DLCI если что-то ему потребуется отправить в сторону этого IP он будет отправлять все это дело в 400 DLCI и наоборот он отправит свой IP в 400 DLCI и оно вылетит из-под сотой DLCI слева и соответственно левый роутер запомни что 172 168 5 7 это у нас сотая DLCI для того чтобы это все хорошо работало нужно чтобы у вас выполнились три условия первое условие живая сигнализация то есть если сигнализация не работает этот механизм работать не будет второй вариант

второе требование к этому механизму на всех узлах на всех DTE-школах должен поддерживаться протокол InverseARP он называется так потому что у него логика обратная к обычному классическому протоколу ARP вы отправляете не тогда когда вам нужно не тогда ARP запрос когда у вас есть кадр который вы хотите отправить на получателя не после того как вы получили кадр до получателя а до того но соответственно вы сразу после того как у вас интерфейс поднялся как вы в сигналке получили номера живых дел CICV вы сразу туда и отправили не дожидаясь боевых данных у вас должен этот самый протокол везде работать использует он те же самые форматы ARP сообщений что и классические ARP но только там код операции будет немножко другой не запрос а ответ а просто одно поле отличается короче а так это те же самые сообщения ARP ну и для того чтобы все совсем хорошо работало вам еще

один момент требуется помните когда мы говорили что у вас фактически коммутация прописывается в две разные стороны то есть вы должны будете указать как какой кадр приходит с одной стороны допустим сотой куда мы его коммутируем в 120 и в обратную сторону что вот 120 должна коммутироваться в сотой это не всегда не обязательно так то есть это вы можете в принципе сделать так чтобы у вас с одной стороны приходила сотая DLC в 120 коммутировалась а с другой стороны вы можете сказать а пусть абонент будет отправлять нам кадры не в 120 DLC а в 240 а мы его будем возвращать в 200 и это все будет между одними и теми же участниками то есть PVC она односторонняя и обратный трафик он вообще говоря идет по совершенно другим правилам он может идти по другой траектории он может идти с другими номерами DLC и да даже на конечного получателя он может приходить с другими DLC может быть такое что левый роутер направо отправляет сотую DLC а от правого на левый

трафик приходит с двухсотой может такое быть вот если у вас такое будет то инверсарп работать не будет но опять же это довольно наркоманский сценарий если уж вы выделили какую-то DLC под какую-то конкретную PVC то нет смысла выделять под нее еще второй только если вам очень хочется трафик туда и обратно направить как какими-то разными трассами сделать асимметричную коммутацию в Ethernet опять же подчеркну такой фигни не было так далее Ethernet у нас был с рядой с браткастами и мы этим нагло пользовались любой желающий мог отправить кадр куда угодно и обязательно все бы получили этот кадр вы могли отправить браткаст вы могли отправить мультикаст тогда некоторые кто бы получили такой кадр они бы зажмурились и сказали не нам это неинтересно но все равно физически оно бы дошло до всех ну или Switch понимает что кому-то какой-то конкретный мультикаст не нужен он бы

кому-то бы его не посылал есть такая штука как unknown unicast который фактически тоже ведет себя как браткаст во фрейм риле всего этого безобразия нету и у нас среда в которой называется фрейм рилей называется non-broadcast multiple access non-broadcast потому что нет браткастов и ничего похожего на них тоже нету и multiple access означает что у вас в одном канале за одним проводом может сидеть много разных участников то есть в AzorNet это классический пример у вас есть Switch за этим Switch 10 абонентов вот физический провод до Switch у вас один вы в этот физический провод отправляете кадры и пишите этот кадр Васе этот кадр Пете этот Коля этот Сережа во фрейм риле то же самое есть физический Switch к нему тянется один провод вы пишете этот кадр Пете этот Васе этот Коля это Сережа но вы не можете во фрейм риле отправить браткаст который всем сразу Пете, Васе, Коля и Сережа ему текас не может в AzorNet можно было здесь нет в фрейм риле помимо всего прочего еще может быть неполносвязная топология

это не обязательно связано с NBMA то есть NBMA говорит про то что нет браткаста про связность полная она не полная NBMA ничего не говорит но фрейм рилей как раз такая вот штука это не обязательно полносвязная сеть если говорить про то что есть допустим у нас курс по роутингу цисковский и там в качестве примера живых NBMA сетей сейчас используется DMVPN протокол который в общем довольно популярен и в этом протоколе для разрешения ну для скажем получения канальной информации о том кому куда чего посылать используется протокол NHRP тут NHRP он протаскивает указания кто кому посылать трафик может и делает фактически с DMVPN NBMA среду с полной связностью если вдруг вы хотите понаркоманить вы можете взять и использовать DMVPN без NHRP прописать статические маппинги указать какой IP с кем может связываться и тогда вы получите NBMA

среду с неполной связностью с DMVPN ну вот фреймрелей он классическая сеть NBMA с неполной связностью поэтому циск очень любит на примере фреймрелея показывать экзотическое поведение протоколов динамической маршрутизации когда у вас есть роутер он связан интерфейсом с некоторыми другими роутерами поверх какого-то поверх канальной среды и там он кого-то видит а кого-то не видит и еще браткастов нету OSPF EGRP RIP все это очень любит NBMA прям вот настолько любит что прям жить не может то есть если у вас есть OSPF он как бы под это адаптируется неплохо но если у вас есть EGRP или RIP не дай бог то вот поверх NBMA среды им прям очень хреново ну естественно если вы хотите стать профессионалом в области динамической маршрутизации вы должны будете примерно представлять на какие грабли можно наступить используя динамическую маршрутизацию особенно дистанс-векторную в неполно связанной топологии

а вот как раз да фрейм рилей для этого прям очень уж удобен поэтому Cisco его в курсе по роутингу любит она его до сих пор оставила там и вот причина по которой мы читаем наш вебинар заключается именно в том что во-первых фрейм рилей есть в блюпринте курса роут во-вторых Cisco обещала давным-давно закопать стюардессу и она закопала фрейм рилей и два года по фрейм рилею не было вопросов в экзамене в блюпринте было а на экзамене не было это нормально но в последние пару месяцев у нас возникает обратная связь что на экзамене роут появились вопросы по фрейм рилею не просто по поведению протоколов динамической маршрутизации во фрейм рилею что можно как бы тупо заботать или там на дмвп не изучить но именно по настройке фрейм рилея именно по этой причине мы вынуждены читать этот вебинар чтобы догнать ту информацию которая не была рассказана в курсе по подготовке к экзамену так

что касается настройки в Cisco у нас нужно будет если мы настраиваем оконечное оборудование сделать несколько вещей первая вещь это указать какой тип кадров мы будем отправлять если у вас есть интерфейс соответственно там кадры фрейм рилеевские которые будут отправляться они будут иметь заголовок и содержимое то самое поле информация и это поле информация может быть одного из двух вариантов Ethernet-like или PPP-like вот вы должны будете указать один из двух вариантов это будет можно сделать двумя способами либо сказать давайте все кадры которые мы будем отправлять за исключением тех которые нам будут как-то хитро отправлять будем отправлять одним способом или другим вот на интерфейсе Serial Link например вы можете сказать соответственно encapsulation frame relay и тогда будет использоваться по умолчанию цисковский формат инкапсуляции то есть похожая на Ethernet либо указать encapsulation frame relay и ETF и тогда вы будете

отправлять по умолчанию PPP-шный формат кадра это подчеркну включение в режим отправки frame relay кадров то есть не HDLC не PPP а вот именно frame relay и указание какой тип кадра используется по умолчанию но это умолчание можно переопределить переопределить вы можете его на уровне либо конкретной DLCI либо конкретного IP-шника если вы хотите сказать что вот конкретной DLCI нужно будет отправлять кадры какие-то хитрые то вы указываете frame relay интерфейс DLCI дальше указываете номер DLCI и EETF то есть чаще всего это нужно когда у вас связывается между собой циски и вы говорите вот у нас есть encapsulation frame relay просто здесь EETF не пишите а вот говорите для того чтобы связываться с Васей нужно отправлять кадры вот эти самые EETF потому что Вася это не циска допустим не знаю 102-я взялсяйку у Васи будет вы можете для того чтобы

связываться с Васей использовать inverseARP для распознавания его IPшника в DLCI или прям прописать вручную этот самый как называется маппинг прописывается на уровне интерфейса его указываете frame relay map дальше указываете DLCI указываете номер который вам нужен ну допустим 102-й так пардон map IPшник здесь IPшник там 172-16-1-1 дальше указываете DLCI и номер 102 то есть вы указываете что IPшник 172-16-1-2 вот здесь он будет он доступен за DLCI 102-й и указываете если нужно что этот IPшник и этот номер DLCI будет EETF то есть вот ему надо отправлять кадры хитрого формата по умолчанию используется циска где захотите вы использовать

скажем указать какой тип инкапсуляции будет использоваться для конкретного клиента все равно то есть можете на уровне интерфейса DLCI указать можете на уровне IPшник указать если у вас используется InverseArp про него чуть попозже проговорим то IPшники можно вручную не прописывать тогда вы если вы используете InverseArp должны быть использовать интерфейс DLCI если у вас все соседи одинаковые все поддерживают либо циск формат либо только EETF формат то вы можете указать в циске вот Inksulation Frame Relay EETF тогда все кадры будут отправляться типичные помимо всего прочего вы должны будете заказать сигнализацию то есть сигнализация у нас будет не двух вариантов а трех по умолчанию как всегда цисковская и вы указываете Frame Relay LMI Type то есть это какой тип сигнализации вы хотите использовать и дальше либо циск либо ANSI либо вот это вот итушное ANSI для PVC итушное для SVC циска для всего когда у вас есть

оборудование купленное от правильного производителя эту информацию вам естественно должен сказать провайдер то есть вы как клиент пришли к провайдеру сказали дорогой провайдер я хочу подключиться к твоему облаку Frame Relay какие настройки мне сделать и вот провайдер говорит ты используй пожалуйста сигнализацию цисковскую или там ты используй пожалуйста сигнализацию античную скорее всего он скажет античную так далее давайте посмотрим на то как выглядит Frame Relay в цисках я подготовил такую простенькую демо среду у нас есть некоторое количество роутеров и здесь можно будет заметить следующее есть роутеры ну не называем это Frame Relay свечи это у нас соответственно Point of Presence 1 это Point of Presence 2 то есть это провайдерские узлы которые стоят где-то рядышком с клиентами это третий и это четвертый Point of Presence 4

здесь у нас два клиента А и Б здесь тоже два клиента А и Б и здесь тоже два клиента А и Б и как понятно здесь тоже два клиента А и Б клиенты пришли к провайдеру и сказали дорогой провайдер у нас в каждой из точек присутствия есть роутеры нам надо связать их между собой в сеть то есть для клиента А это будет выглядеть как такая вот конфигурация А1 А2 А3 и А4 и соответственно есть некая коммутируемая среда давайте ее нарисуем таким вот образом куда каждый из клиентов смотрит интерфейсом и клиент говорит вот я хочу чтобы у меня трафик допустим вот такой вот шел вот такой вот шел и вот такой вот шел то есть между А1 и всеми остальными связь была а между А2 А3 А4 связь быть не должна она должна быть только через А1 классическая неполносвязная среда когда у нас один узел со всеми остальными имеет полную связь а все остальные с ним нет

это да можно будет например указать что здесь у нас там headquarters а здесь филиалы споук 1 споук 2 или споук 3 а вот это споук 2 и при этом абсолютно параллельную структуру будет иметь узел B ну не узел а клиент B то есть у него есть то же самое B1 B2 B3 и B4 и у него то же самое облачко и он тоже связывается с этим облачком но здесь какая-то другая структура между каналами допустим B2 B3 и B4 вот так вот вот такие PVC-шки будут куплены это все поверх одной и той же топологии то есть мы должны будем прописать указание что связь есть между вот такими узлами между вот такими узлами между вот допустим вот такими узлами и соответственно для B-шки тоже надо давайте другой цвет выберу

здесь где-то можно выбрать цвет это вот рыженький попробую для B-шки нужно будет вот такой канал прописать вот такой канал прописать и вот такой то есть это поверх одной и той же среды нужно прописать несколько разных правил коммутации вот здесь будут какие-то правила коммутации здесь здесь здесь в общем везде они будут практически нет интерфейсов где не нужно было прописывать правила как мы это будем делать Сейчас я подключусь к узлу, допустим, вот этому вот А1 И попробую настроить его так, чтобы у нас было что-то примерно аналогичное К тому, что мы хотим получить Так Поскольку этот роутер только что загружен Вот, соответственно, у него никакой конфигурации нет Вы сами видели, что он спрашивал, взял от начальной настройки

У этого роутера только 4 сервиса интерфейса То есть это все эмуляция давно, как это сказать, старинной глубокой И мы сейчас будем делать следующие вещи ConfT ConfT, конфигура терминал Интерфейс, который у него смотрит на провайдера Если мне память не изменяет, сериал 0.0 0.0 Этот интерфейс надо включить Так, простите, no shutdown И затем нужно прописать encapsulation frame relay Encapsulation frame relay По умолчанию цисковские роутеры на сериал интерфейсах используют инкапсуляцию циска HDLC Соответственно, когда мы используем frame relay, то мы меняем формат кадра Но хитрость в том, что релейевские кадры, они немножко совместимы с HDLC

Поэтому, если мы меняем HDLC на frame relay, то сразу связь не падает Он все еще надеется отправлять кадры, то есть у него интерфейс как бы формально живой Но через 30 секунд после смены encapsulation он поймет, что сигнализация не приходит Ничего не приходит, в общем, связи нет Так, вот сейчас у него, по идее, должно наступить озарение И интерфейс должен упасть Упал Это мы видим, что кадры frame relay не проходят Физика живая, то есть мы можем отправлять в середу нолики и единички А вот кадры не приходят Мы не можем отправлять кадры, мы не принимаем никакую сигнализацию Давайте попробуем настроить провайдерский роутер Вот этот вот самый point of presence 1 Так Сейчас он прочухается Тоже роутер, на самом деле, тоже абсолютно не настроенный Абсолютно вот голый-голый

У него вообще ничего нет Интерфейс, в котором этот роутер смотрит на клиента, это тоже serial 00 Мы сейчас его тоже будем настраивать Надо немножко подождать, пока он очухается после диалога начальной настройки Enable Конфигурить терминал Conf.t Интерфейс serial 00 Так, и здесь мы прописываем, соответственно, encapsulation Encapsulation Frame relay Указываем No shutdown Что-то пошло не по-плаву Так, чтобы это могло быть Conf.t Conf.t А, у меня control был зажат, простите Conf.t No shutdown

Так, интерфейс serial 00 No shutdown Опять интерфейс поднимается И через некоторое время он, как ни странно, снова потухнет Связано это с тем, что, несмотря на то, что у нас с обеих сторон прописано все правильно Сигнализации там нету То есть, если посмотреть Вот он поднялся С одной стороны Ну вот сейчас потухнет На R1 Вот на этом, на A1 роутере Связи не появилось И не появилось там, потому что сигнализация приходить не стала Вы можете увидеть, что настройки, которые мы сделали на двух роутерах Они абсолютно идентичные Эти настройки характерны для узла, который конечный То есть, мы просто указали, что вот у нас есть узел, который просто использует FrameRelay Нигде никто не сказал, что должна приходить сигнализация А FrameRelay ожидает, что сигнализация приходить должна для того, чтобы интерфейс появился И здесь я немножко забегу вперед Со следующего слайда возьму следующую команду FrameRelay

FrameRelay Интерфейс Так IntType DCE Это я указываю, что этот интерфейс будет посылать сигнализацию DTE-шки сигнализацию принимают А DCE-шки сигнализацию посылают Так Ну-ка Shot NoShot А, еще сигнализацию надо тип задать Вот FrameRelay Так И сигнализацию мы будем использовать Так Вот он поднялся Ахахахахаха FrameRelay LMI Так, что-то мне не понравилось Cisco LMI-type

Cisco Вот Вот Интерфейс поднялся И начал посылать сигнал И начал посылать сигналку И как вы видите На клиентском роутере тоже поднялся интерфейс На этом клиентском роутере можно будет посмотреть, что действительно приходит сообщение Сигнализация Не просто приходят, они там еще действительно вот видны ShowFrameRelay ShowFrameRelay LMI И мы здесь видим, что у нас есть интерфейс, который называется Serial00 Это DTE, то есть клиентское устройство у нас, вот этот вот роутер R1, это клиентское устройство Он не посылает сигнализацию сам, он ожидает, что посылает ему будет DCE-шка Тип сигналки Cisco Мы послали 29 статус-инквари И мы получили 8 статусов То есть эти статусы приходят в ответ на каждый запрос сигнализации Но мы этих сигнализаций, запросов послали много У нас интерфейс включился, мы начали долбать Скажи сигнал, скажи сигналку, скажи сигналку

И ничего не получаем А вот, соответственно, как только у нас сосед появился Мы начали получать статусы И вот 21 раз у нас был тайм-аут 8 раз мы получили ответ Сигнализация приходит раз в 10 секунд по умолчанию Вот в Cisco, да, она примерно так и есть И на FrameRelay в свече мы можем сейчас вот тоже посмотреть LCE ShowFrameRelay LMI Это статистика по тому, что мы здесь видим Опять же, мы получили 23 запроса Status Enquiry Received и отправили 14 ответов Так Запросы здесь очевидно Были получены, потому что мы некоторое время были клиентом, DTE-шкой И мы получали эти статусы, но мы на них не отвечали, потому что мы клиент

А вот как только мы стали DCE-шкой, мы сразу на них стали отвечать Так, это что касается LMI, статистики Вот базовая настройка, она такая Возвращаясь на предыдущий слайд Указали тип инкапсуляции, что мы используем FrameRelay Не указывали ETF, потому что по умолчанию мы хотели использовать Cisco Cisco формат кадра с EtherType Дальше, указали FrameRelay LMI Type для сигнализации Если у вас используется не Cisco, то вы должны указать, какая явная Если используется Cisco, то можно оставить по умолчанию И если нужно, указываем интерфейс DLCI Для конкретной DLCI-ки использовать другой формат кадра Сигнализация указывается одна на всех Формат кадра указывается для каждого конкретного абонента Так, далее Если вы хотите настроить роутер Cisco как FrameRelay Switch

То вам понадобится несколько команд Во-первых, естественно, потребуется задание сигнализации Во-вторых, потребуется указание типа DCE вместо DTE По умолчанию все узлы считают себя клиентскими устройствами FrameRelay Interft Type DCE указывает на то, что вы будете отправлять сигнализацию Дальше Вы должны будете прописать правила коммутации И это правило можно прописать двумя способами Один из способов прописать именно классическое одностороннее правило Когда с одной стороны приходит кадр с такой меткой Отправить в другую сторону с другой меткой Или можно воспользоваться командой connect Которая пропишет сразу двустороннее правило Что слева отправляем направо, а справа отправляем налево Здесь синтаксис очень простой, как вы видите Так Вот И вы указываете в случае с первой командой FrameRelay Дальше Road Указываете, какая DLCI приходит слева На интерфейсе Понятно на каком, потому что это все делается в настройке интерфейса

То есть вы в Config.if, в настройке интерфейса указываете Если приходит с этого интерфейса DLCI 123 Мы ее отправляем на интерфейс сериал 01 с DLCI 456 То есть это вот у нас есть роутер У него есть входной интерфейс и там два выходных И мы говорим, если что-то приходит со 123 DLCI Это отправляется вон туда с 456 Если у вас есть тут каком-нибудь 300, там не знаю, 45 То вы можете прописать такое же правило Что она отправляется вниз на, не знаю, 500, там, 567 Так, если вы хотите сразу прописать двустороннюю коммутацию То да, вы это делаете в глобальном конфиге Не в настройке интерфейса А вот именно в глобальном конфиге Указываете команду Connect Дальше указываете имя Ну, комментарий просто Кто, кого, куда, с чем, почему То есть это абсолютно ничего не значит, чьи имя Нужно просто для того, чтобы вы сами не запутались Какое правило вы создаете Указываете, какой входной интерфейс с какой меткой

И какой выходной интерфейс с какой меткой И наоборот, соответственно То есть здесь уже в обратную сторону прописывать не надо Одна пара, вторая пара И, соответственно, в этом случае вы указываете Что 123 на 0.00 уходит в 456 на 0.01 А 456 с 0.01 приходит на 123.00 Это удобно Вы не запутаетесь, где, какие правила вы прописываете Вы просто пишите Connect И сразу достаточно простой командой вы создаете два правила Можно ли несколько маршрутов прописать на одном интерфейсе Не просто можно, а нужно Если у вас есть, допустим, вот FrameRelayRouter И здесь вот клиент Давайте напишем DTE А здесь мы напишем FRSwitch DTE на Switch смотрит физическим проводом одним И вот этот вот Serial 0.00, допустим, интерфейс Здесь приходят сообщения Для роутера 1, для роутера 2, для роутера 3 Это все разные DLCI

Для R1 будет приходить DLCI, допустим, 101 Для R2 будет приходить DLCI, 102 Для R3 будет приходить 103 Они все маршрутизируются по-разному 101 надо отправить сюда, 102 надо отправить тоже сюда 103 надо отправить куда-то наперекосяк Поэтому, да, вам придется прописывать Вот эти вот правила указывать Что с такого интерфейса могут приходить DLCI Такие, сякие, пятые, десятые И разруливать их надо вот таким образом С помощью FrameRelayRouter вам придется делать В два раза больше работы, чем с помощью команды Connect Как посмотреть, что написано? Ну, в конфиге проще всего Showrun То есть какой-то удобной команды Как посмотреть, какие правила коммутации вообще прописаны Там, на вроде show, там, не знаю, MAC address table В коммутации Ethernet Такого нет Ну, или, по крайней мере, я про это не знаю Сказать, что я хорошо знаю FrameRelay нельзя Потому что, да, боевого опыта у меня с ним нет Ну вот Что знаю, то рассказываю На экзамене в любом случае Вас от этого не потребуют никогда и ни за что

Сами понимаете, что Максимум потребуют это вот Простые команды по настройке интерфейса Как на DTE-шке включить связь с DTE-шкой Как настраивается FrameRelay Switching? Упаси боже Я вам это даю для того, чтобы вы могли В домашних условиях Labo собрать Если вдруг вы захотите Вот вам понадобится делать так Чтобы у вас коммутация какая-то во FrameRelay осуществлялась Вот эти вот команды вам достаточно Для того, чтобы вы на доступных вам эмуляторах Смогли собрать FrameRelay-овскую Labo Сериал-интерфейсы Поверх них ингубсуляция FrameRelay Так же, как мы PPP или HDLC включали Вот так же FrameRelay Поддерживается это все дело Динамипсом Более известным под названием GNS3 Поддерживается все это дело ИУшками То есть, как вы это будете использовать С какими эмуляторами Это ваше право выбора Так Дальше Для экзамена по роутингу Вам пригодится следующая информация

Вы можете использовать Настройку FrameRelay на самом интерфейсе То есть, у вас физический интерфейс Допустим, Serial 0.0 И вы поверх этого интерфейса Включаете FrameRelay Вы, да, там действительно можете Сразу и IP-шник повесить И все настройки Там, не знаю, правила QoS И NAT И все, что захотите В CISC-ах по умолчанию На родительских интерфейсах Работает InverseArp При условии, что с другого конца Тоже InverseArp поддерживается При условии, что у вас сигнализация живая При условии, что провайдер Не сделал асимметричную Решутизацию В общем, там При условии, что все вот эти Сложности не возникли У вас будет работать InverseArp Просто прописываете IP-шник Просто все на родительских интерфейсах Включаете И у вас оно как бы само узнает Какие соседи с какими IP-шниками За какими дел всякими живет Если у вас не работает InverseArp Вы должны будете прописать Маппинги вручную Маппинги прописывают с командой Которую я вам уже давал

FrameRelay, Map, IP Вот оно FrameRelay, Map, IP Дальше IP-шник DLC-ка И возможно вы указываете Ключевое слово Broadcast Зачем? Сейчас расскажу Дальше Субинтерфейс Ну это спорно По поводу субинтерфейс Как бы с точки зрения русского языка В таких случаях после B Должна ставиться И Я понимаю, что выглядит коряво Некрасиво В любом случае Слово не словарное Поэтому да Можно было бы написать по-английски Но тоже как-то Нет идеального варианта К сожалению Так вот Если у вас есть родительский интерфейс Нет инверсарпа Ну окей Прописывайте маппинги Там как бы С этим уже особых проблем нет По поводу Ключевого слова Broadcast Ситуация следующая Если вдруг У вас будет протокол Который прям Очень сильно хочет Использовать Broadcast Или Multicast Вы можете В указании маппингов Прописать Вот это вот самое Ключевое слово Broadcast

Если у вас есть инверсарп Он по умолчанию Прописывает для всех маппингов Broadcast Если вы делаете вручную Вы можете это дело контролировать И тогда Когда у вас будет Какой-нибудь протокол Например Например РИП Который не умеет Работать Ни с чем Кроме как с Multicast Вот он отправляет На 224.009 И все Вот ему подавай Multicast Живой рабочий И все В этом случае Циска У которой прописаны Несколько соседей С ключевым словом Broadcast В шоу Frame Relay Map Вы можете посмотреть Кому прописан Broadcast Кому не прописан Вы соответственно Будете Эмулировать Broadcast Или Multicast На Frame Relay В RIP условный Или EJRP Или USPF Или еще другой какой-то протокол Который хочет использовать Broadcast Или Multicast Он пытается Отправить кадр Broadcast Но Нельзя отправить Broadcast Поэтому вместо Такого одного Broadcast Кадра Циска делает пачку Unicast Кадров И она делает Пачку Unicast Кадров На все DLCI Которые у вас

Прописаны С ключевым словом Broadcast В маппингах То есть Вот в нашем случае Если представить себе Что только Вот эти две команды В маппинге есть Вот эти вот две И больше ничего То есть Нинверс Арп Ничего У вас будет Допустим Рип Который сделает Кадр 220 Не кадр А протокол Рип Сделает IP пакет 224.0.0.9 Его надо упаковать В кадр Мультикастовый А мультикаста Нету Поэтому вместо него Будет сделано Два Unicast Кадра Один На 102 ДЛС С содержимым IP пакета На LADS 224.0.0.9 Другой На 103 ДЛС С содержимым 224.0.0.9 Эти два Unicast Кадра Будут прокоммутированы Как обычный Unicast Трафик Так По поводу Субинтерфейсов Мы сейчас пока Ничего не говорили Это я говорю Про родительские интерфейсы Безо всяких Субов Зачем нужны Сабы Иногда

В некоторых Случаях Вы хотите Избавиться От проблем Которые возникают В случае С неполно связанными Топологиями С отсутствием Браткастов Со всякой Вот этой вот фигней Циско Предлагает Два типа Виртуальных интерфейсов Так же Как допустим 802.1 Кьюшные Субинтерфейсы На роутерах Вы можете сделать И сказать Вот весь трафик Терминируется На родительском интерфейсе А часть Которая По известному Правилу Отбирается Она терминируется На другом Логическом интерфейсе А на физическом Типа не показывается Та же самая история И здесь Вы можете сделать Субинтерфейс Или Сабинтерфейс Кому как больше нравится И делается он Следующей командой Указываете команду Интерфейс Дальше Даете название Физического интерфейса Serial 00 Дальше Через точку Указываете Номер логического Субинтерфейса 0.0.1 Этих логических интерфейсов Можно наплодить Сколько угодно Там Сколько хотите Столько и делайте Ограниченного Только вашей фантазией Ну и по-моему Там номерная емкость Есть у этих интерфейсов

Но их много Вам столько явно Не понадобится Но в отличие от 802.1 Кьюшных виланов Вам потребуется Указать тип Субинтерфейса Либо Point-to-point Либо Point-to-multipoint С Point-to-point Ситуация очень простая Point-to-point интерфейс Это такой интерфейс В котором Вы указываете Номер DLCI Кей командой Frame Relay Интерфейс DLCI 102 Весь трафик Который будет уходить В Point-to-point Субинтерфейс Он весь будет уходить В эту DLCI Что бы вы не захотели Отправить в этот интерфейс Как бы вы не извращались Захотели мультикаст отправить Пожалуйста В 102 DLCI Захотели браткаст отправить Пожалуйста В 102 DLCI Захотели юникаст отправить На адрес 192.168.0.17 Пожалуйста Отправили в 102 DLCI Распознавание адресов Не нужно Потому что это Point-to-point Субинтерфейс С другого конца ПВС Заведомо 102 DLCI Вам не нужно Использовать Ни инверсарп Ни маппинги Вручную прописывать Все в одну и ту же

ДЛCI Понятное дело Что в таком случае У вас Работа с Point-to-point Субинтерфейсами Превращается в легкое удовольствие То есть если у вас есть Там не знаю EJRP Frame OSP FRIP Ну там обычный Point-to-point Интерфейс В нем всегда один сосед Браткаст не нужен Мультикаст не нужен Просто отправляет С той стороны И оно выплевывается То есть когда у вас Просто Point-to-point Субинтерфейсы Все легко и приятно InARP не нужен На point-to-point Субинтерфейсах Просто потому что Не нужно распознавать IPшники в ДЛСИ Когда у вас есть Point-to-point Интерфейс На котором прописана Команда Frame Relay Интерфейс ДЛСИ Весь трафик Вообще не важно Какие IPшники будут Будет отправляться На эту 102 ДЛСИ Второй тип Субинтерфейсов Более сложный Это Point-to- Мульти Пойнт Субинтерфейса Указываете Соответственно Точно так же Интерфейс Дальше Serial 0 Физический интерфейс Дальше Отбираете Не отбираете Указываете Точка 1 На номер

Субинтерфейса И указываете Мультипоинт То есть Не point-to-multipoint А просто Мультипоинт И с point-to-point С point-to-multipoint С субинтерфейсами Возникает Соответственно Беда И беда Заключается в том Что там нету Inverse ARP То есть Вот здесь Вот И на ARP Нету Вот Вот В мультипоинт Субинтерфейсе Вы обязаны Прописывать Всех Ручками Прописывать Все маппинги Указывать Какие IP За какими Делосиаками Живут И какие Адреса Должны получать Копии Мультикаста Какие нет Ну Браткаста Мультикаста Во-вторых Вы должны Будете Использовать IP Которые У вас Вот Есть Они должны Быть У всех В одной Сети То есть Если вы Отправляете Пакеты Из 192 168 01 То У всех 01 по 24 Маске Здесь у нас 24 маска Дробь 24 Соответственно У всех Стальных узлов В пределах Frame Relay

Облака Которые могут Получать Ваши Такие Пакеты Должны быть Адреса Из этой Сети Давайте Сейчас Немножко Цвет Поменяю Опять Так Красненький Сделаю Вот у нас Облако Frame Relay Вот у нас Есть Там допустим Роутер Давайте Обозначу 1 2 3 И мы Везде Используем Вот эти Point to Multipoint Субинтерфейсы Соответственно Здесь будет 10 001 По 24 Маске Здесь будет 10 002 По 24 Маске Здесь будет 10 003 По 24 Маске Так Что Получается Получается Что у вас Будет Тут Работать Эмуляция Браткаста Что у вас Будет Тут Отправляться Кадры На несколько Участников Но Если вдруг У вас Здесь будет Неполносвязная Топология То есть

Допустим Первый Второго Видит Второй Третьего Видит Первый Третьего Не Видит Вы Здесь Огребете Кучу Проблем И Это Проблем Прям Вот Такие Большие И Серьезные Особенно Если у вас Не три Участника Будет А четыре Пять И там Кое-кто Кое-кого Кое-как Видит Остальные Друг друга Не видят Это не звезда Не Там Не Не Point to Multipoint Когда у вас Один Видит всех Все остальные Видят только его А вот Кое-кто Кое-кого Кое-как Вот там Что-то Где-то Давайте попробую Нарисовать Прямо образцово Показать На хреновую Топологию Вот здесь Четвертый Здесь пятый И у вас Каналы Вот такой канал Есть Вот такой Канал Есть Вот такой Допустим Вот такой И вот такой Все Вы застрелите Здесь С прописыванием Этих самых Правил Кто кому Чего Куда Поэтому Для чего Нужны Вот эти Самые Point to Multipoint Subinterfaces Вы берете И создаете Несколько Point to Multipoint Subinterfaces Каждый Из которых Смотрит В свое Подоблачко То есть Вы разбиваете Фактически Одну Frame Relay Среду На несколько

Разных Виртуальных Подсред В каждой Из которых У вас Есть Полная Связь И указываете Что вот У вас Есть Роутер Он физически Это интерфейс Смотрит Родительским В общую Frame Relay Среду Но он Делает Отдельные Логические Point to Multipoint Subinterfaces В которые Он смотрит Отдельно Как бы И в эти Point to Multipoint Интерфейсы Смотрят Также Некоторые Другие Участники Вот между Этими Другими Участниками И нами В пределах Point to Multipoint Интерфейса Есть Полно Связная Топология Вот Когда Вы Такую Штуку Сможете Сделать Вы Сможете Надежно Рассчитывать На то Что у вас Будет Работать Браткаст Именно В том Смысле В котором Вы Привыкли Понимать Отправляете Кадр Якобы Один А он Доходит До Всех Участников Да Физически Это Будет Не Браткаст Это Будет Эмуляция Браткаста Но Зато Оно Будет До Всех Участников Это Будет Неэффективно Но Это Будет Работать Вот Так Вопрос Поступил Можно Ли Работать В Point to

Point Вообще Без IP Адреса Можно Разрешаю То есть Вы Должны Будете Придумать Какой Сетевой Протокол Вы Будете Использовать Поверх Всего Этого Вместо IP Хотите Использовать Можно Без IP Адреса Работать В Point to Point Адреса Могут Быть Вообще Из Разных Подсетей Все Будет Работать Будет Только Вам Надо Будет Как-то Заставить Трафик Посылать В Такую Сеть У У У Таблица Маршрутизации Должна Быть Указано Что Трафик Определенный Должен Отправляться Именно В Определенный Интерфейс Если У Разные С одной С одной С одной Прописывать 192 168 01 С другой С другой С другой С другой С другой С другой С другой С другой С другой Вам Потребуется Игрища С таблицей Маршрутизации Ну и да Там Как правило Будут Проблемы Со связью С Успи С С С С С С Потому что Они Очень Не любят Когда

У них Пакеты Приходят Hello Из Под IP Которая Не В Родной Сети Можно Сделать Но Это Будет Себе Выстрел В Колено Так Допустим Есть Несколько Трафиков В разных Виланов Физически Приходит Транг На Один Интерфейс А Логически Можно Сделать Несколько Субинтерфейсов Для Работки Каждого Потока Чтобы Субинтерфейс Каждый Имел Свой Собственный IP Не Только Можно А Только Так И Нужно То есть Вы Делаете Отдельные Где Кое Кое Кто Кое Кого Кое Как Кое Зачем Видит Вам Придется Делать Отдельные Субинтерфейсы Скорее Всего Поинты Мультипоинтов Для того Чтобы Вы Смотрели Не в одно Физическое Большое Облако А в Несколько Разных Виртуальных Облаков Фактически Можете Считать Это Виланами У вас Есть Один Физический Интерфейс Он Смотрит В среду В которой Бегают Разные Трафик Условно Горя Разных Виланов В разных Условно Широковещательных

Доменов И в пределах Каждого Широковещательного Домена Каждого Вот Это Point Мультипоинт Субинтерфейса Вы Имеете Полно Связную Топологию Это Средство Упрощения Связи Во Фрейм Рилей Без Этого Просто Никуда Как только Вы начинаете Поверх Очень Сильно Кривой Топологии Видят Что Первый Второго Видит Второй Третьего Видит Первый Третьего Не Видит Ему Прямо Очень Тяжело Становится В простых Случах Можно Будет Отключить Сплит Горезон И Там Как-то Можно Будет Это Дело Обойти В сложных Случаях Только Мультипоинт Субинтерфейса Так Это Что касается Циски Да Работа С ОСПФ Во Фрейм Рлей В цисках Достаточно Простая Потому Что ОСПФ Заточен Под Небродкаст Сети И С Неполной Связностью У него Есть Специальный Режим Работа Для Этого Если У вас Есть

Фул Меш Связь То Каждый Смотрит На Каждого Вот Вы Взяли Раскошелились И Провайдер Заплатили За Каналы Между Вообще Всеми Узлами Тогда Вы Проще Всего Будете Указывать Что У вас Есть Родительский Интерфейс Там Скорее Всего Будет Работать Инверсар А Если Нет То Прописывать Статические Маппинги С Бродкастом Дальше Указывайте Тип Сети IP OSPF Network Broadcast В Настройке Интерфейса И Тогда OSPF Будет Отправлять Обычные Свои Привычные Мультикастовые Пакеты Hello И Они Будут Преобразовываться В Пачку Unicast Кадров Которые В себе Содержат Мультикастовые Пакеты OSPF И Они Будут Нормально Доставляться До Получателей У вас Полно Связанная Топология У вас Есть Какое-то Подобие Мультикаста У вас Автоматическое Обнаружение Соседей Проблем Никаких Нет Проблема В том Заключается Что FullMesh Предполагает Что вы Деньги Заплатите За Полную Связь Если У вас 50 Точек Присутствия Есть

49 Умножить На 48 Пополам Ну Короче Дофига Этих Самых Каналов Поэтому Скорее Всего В некоторых Случаях Вы FullMesh Использовать Не захотите Просто По причине Дороговизны Здесь Все Линейно Зависит От количества Каналов Каждый Канал Стоит Денег Если Вам Нужно 50 Каналов Это Будет Стоит Одно Количество Денег Если Вам Нужно 100 Каналов Это Будет Стоит В Два Раза Дороже Что Касается Варианта С Point To Point Какая Бы У Вас Кривая Среда Не Была Вы Можете Сделать Всегда Среду Виртуальную Которая Будет Иметь Один Point To Point Субинтерфейс На Каждую PVC Которую Вы Купили Что Бо Вы Не Делали Как Бо Вы Не Извращались На Уровня Коммутации Вы Используете Как Бо Поверх Frame Relay Среды Пачку Субинтерфейсов Point To Point В Которых У Нас Есть Эмуляция Broadcast А Что Там Эмулировать Она Просто Отправляется В Среду И Все Нам Ничего Эмулировать

Не Нужно Вместо Одного Мультикастового Или Браткастового Кадра Мы Делаем Один Юникастовый Все Просто У нас Между Двумя Участниками Ну Естественно Связь Полная Вот То есть Если У вас Есть Какой-то Вот Там Пять Роутеров Как Мог Так Нарисовал И Облако Frame Relay Между Ними Есть Какие-то Кривые Связи Допустим Вот Как-то Вот Так Вот Это Сделано И Вот Так Да Вот Вы Просто Поднимаете Поверх Каждой Пвс Отдельно Point To Point Субинтерфейс Плюс Этого Решения Будут Заключаться В том Что Простая Настройка Всех Протоколов Поверх Point To Point Субинтерфейс Все протоколы Себя Чувствуют Прекрасно Что РИП Что EGRP Что SPF В общем Никаких Проблем Нет Недостатком Будет Являться То Что Это У вас Фактически Каждый Отдельный Субинтерфейс Будет Представлять С собой Отдельную Канальную Среду Виртуальную Но Тем Не

Менее Поэтому Вам Потребуется Много IP Адресов Много IP Сетей Если У вас IP Сетей Как Б Много То Используйте Point To Point Среду Это Самый Удобный Самый Простой Вариант Работы С Фрейм Рилеем Но Иногда Особенно В экзаменах Вам Говорят А вот Вы Не Можете Использовать IP Адреса Какие Попало Вот IP Адреса Вы Должны Использовать У вас Всего Одна Сетка На 50 Узлов В Этой Сети У вас 50 Абонентов Вот Что Хотите То И Делайте И Тогда Вы Будете Использовать Point Multipoint Что Касается Point Multipoint Его Имеет Смысл Использовать Если У вас Partial Mesh Связь То Кое Кто Кое Кого Кое Как Возьму Вот Опять Другой Цвет Так Зелененький Например И нарисую Какие Каналы У нас Есть Вот Такой Канал Есть Вот Такой Канал Есть Вот Такой

Канал Есть Вот Такой Канал Есть И Вот Такой Канал Есть Ничего Не забыл Ничего А что Получается У нас Есть Один Вот Этот Вот Треугольник В котором Все Друг Друга Видят Мы Его Ничтоже Сумя Выделяем В отдельный Point-to-Multipoint Субинтерфейс И дальше Отдельно Поднимаем Субинтерфейс Point-to-Point Вот здесь И Point-to-Point Вот здесь Вот это Вот у нас Будет Point-to-Point Вот это У нас Будет Point-to-Point А вот Эти Три Товарища Друг на друга Будут смотреть Point-to-Multipoint То есть Отдельно Перерисую Кусочек Раз Два И три И облако Frame Relay И у них Будет Соответственно Один интерфейс Два интерфейса Один Point-to-Point И один Вот этот Вот он Один Point-to-Multipoint На вот этом Вот узле Опять же Один Point-to-Multipoint И здесь Один Point-to-Multipoint И один Point-to-Point И тогда Поверх

Point-to-Point У вас Все просто А в Point-to-Multipoint У нас Начинает Работать Та же Самая Эмуляция Или что-то Еще Если У вас Есть Partial Mesh Соответственно Какие Рекомендуемые Сценарии У вас Можно предположить Если вы знаете Точно Что у вас Точно-приточно Точно-приточно Везде полная связанность Внутри Point-to-Point Сумуинтерфейса Есть Вы можете использовать IPOSPF Network Broadcast Через эмуляцию Бродкаста Работать Опять же Легко и приятно Если вы Не уверены Что у вас Все прям Ой, пардон Все прям Совсем хорошо Что вы точно Смогли Разбить сетку На Point-to-Point И Point-to-Multipoint Или вам говорят Опять же На экзамене Это может быть Что вы не можете Разбивать Топологию Frame Relay На отдельные Point-to-Multipoint Субинтерфейсы Тогда вы можете Сказать Что для OSPF Поверх Frame Relay С неполно связанной Топологией Есть специальный Хитрый режим Называется Тип среды

IPOSPF Network А дальше Здесь не Бродкаст Не Point-to-Point Не Loopback А Point-to-Multipoint И дальше Non-Broadcast Non-Broadcast Потому что Бродкастов нет Point-to-Multipoint Потому что Неполная связанность И тогда У вас OSPF Перестает Генерировать ЛСЭК Второго типа Которая предполагает Что у вас есть Полная связанность Между узлами Он будет Работать Исключительно С ЛСЭК Первого типа Он будет указывать Какой роутер По факту Видит Какой другой роутер Вы должны будете Прописать всех соседей Вручную Для того чтобы он Понимал Вообще Куда ломиться Указывайте командой В настройке Config-Router Neighbor Neighbor И дальше указывайте IP-шник Пока вы не Подписали IPOSPF Network Point-to-Multipoint Эта команда Не работает А вот когда вы Прописали IPOSPF Network Point-to-Point Он смотрит Что в IP-сети На этом интерфейсе Вот этот вот IP-шник будет входить И он на этот IP-шник Посылает Hello Он берет Маппинг Соответствующего IP-шника В DLC-IQ

И в эту DLC-IQ Посылает Hello-пакеты Для того чтобы Достать до этого Участника На самом деле Там достаточно Только с одной Стороны Прописать Neighbor С другой Стороны Он автоматом Поднимется Но это уже Как бы Некрасиво Если вы так Делаете Если уж Делать Так с обеих Сторон Одинаково Вот И вот Этот вот Самый режим Point-to-Multipoint Non-Broadcast Ну или даже Просто Point-to-Multipoint Он позволит Вам Указать Кто на кого По факту Как смотрит И у SPF Сможет построиться Под Partial Mesh В этом смысле Он выгодно Отличается От EJRP EJRP Такого не сможет Так Что касается EJRP С Full Mesh Все просто Опять же Та же самая история Удобно использовать Радиканский интерфейс Надеяться на Inverse Arp Если Inverse Arp Нет То использовать Статический Маппингер Используйте Broadcast Ключевое слово Обязательно Потому что EJRP не умеет Работать с Соседями До которых Он не может Достать Мультикаст Дальше Point-to-point Ничего не делаем Все работает Автоматически Опять же Та же самая история У вас есть Point-to-point

Субинтерфейс Туда заведомо Отправляются Мультикастовые пакеты Туда Там автоматически Обнаруживаются соседи Там все Очень просто То есть просто Указываем Point-to-point Субинтерфейс С той стороны Сосед Автоматом Обнаруживается Если у вас Есть Hub and Spoke Топология Где один Участник Видит всех остальных А другие Видят только его То есть Вот у нас Физически Оно будет выглядеть Вот так Раз Два Три Четыре Пять Но я сейчас Поменяю опять цвет И Каналы Которые вы покупаете Они будут Вот только такие То есть У вас Между HQ и филиалами Связь есть Между филиалами Между собой Вот связи нет Это у нас HQ Вот в такой И только Такой Топологии Вы имеете Право Сделать Следующую Штуку Вы говорите Что да У нас Должен быть Мультикаст Или его Аналог То есть Стимуляция Мультикаста С помощью Ключевого Слова Broadcast Будет то Inverse Arp Или будет Статический Маппинг

Не важно Но у вас Есть интерфейс В этом интерфейсе Вы отправляете Пакеты Апдейты С точки зрения Обычного Споука Никаких проблем Нет Просто отправляем И все С точки зрения Вот этого Товарища HQ Любые Апдейты Которые он Получил Он должен Отправить Обратно Потому что Никакой Способ Получить Апдейт От споука Номер 1 На споуке Номер 2 Нету Кроме Как через HQ HQ Получил Один кадр И он должен Его обратно В сторону Узла 2 Отправить Это будет Нарушение Правила Сплитуризон Соответственно Если у вас Хаб И споуки Отдельные Филиалы И споуки Между собой Нигде Никогда Ни при каких Обстоятельствах Не связаны Вы имеете право На хабе Выключить IP Сплитуризон No IP Сплитуризон Дальше указывается Что это для EJRP И номер автономки EJRP Тогда Апдейты Полученные Через этот интерфейс Через физический интерфейс Или через Point to Multipoint Субинтерфейс

Они будут Все что получено Все будет отправляться Назад В тот же самый интерфейс С эмуляцией Браткаста Так что все апдейты Которые получены Через этот интерфейс В этот же интерфейс Обратно будут выплюнуты И все остальные участники Их получат На обычных Споуках Вы делаете настройки Как Point to Point То есть у вас Один сосед Заделся и сидит Который Просто нормально работает И все Больше ничего не нужно Самое боле страдания Когда у вас Partial Mesh То есть Никакого варианта Поверх Partial Mesh Среды сделать Без субинтерфейсов Нормально работающие И GRP нету Разбивайте его На отдельные полносвязанные участки Разными Point to Point Субинтерфейсами И делайте настройки Как в случае с Full Mesh Так Ну и последний слайд На сегодня На самом деле Который ценный Это намек на MPLS Помните вот эту картинку Она у нас была Когда я показывал Правила коммутации Что вот на Frame Relay Таблица коммутации На свече Должна быть заполнена

До того Как вы Начнете Саму коммутацию Вот эта вот табличка Она нам сейчас пригодится Это точно тот же слайд Который был То есть вот у него Входящие указания То есть на каком интерфейсе Что у нас было Какая DLC И какой исходящий интерфейс Какая DLC Использовалась Знаете что MPLS из вот этого Получается Простым переименованием То есть Входящий интерфейс С входящей меткой Выходящий интерфейс С выходящей меткой MPLS изначально Придумывался для других вещей Не для того Чтобы вы могли там Как-то хитро разделить Трафик разных абонентов Или там Не смешать между собой Разных пользователей MPLS родился Для немножко других вещей Но сегодня MPLS используется Для того Чтобы мультиплексировать Разные потоки От разных абонентов В том числе И смотрите Что получается У вас есть Некий роутер У этого роутера Есть интерфейс На этом интерфейсе Приходит трафик

Разных пользователей Давайте вот Для определенности Напишем Что здесь у нас есть Point of presence И здесь вот есть Абонент А И абонент Б Абонент А Посылает свои кадры Абонент А Не кадры Пакеты IP пакеты Абонент Б Посылает свои IP пакеты В этих IP пакетах Может быть Одинаковая адресация То есть Никто вам не запретит У абонента А Использовать адреса 192 168 Там не знаю 1 1 И вот здесь 192 168 Пардон 168 1 1 И Эти узлы Хотят отправлять Трафик в какие-то Свои сети Вот у нас есть Клиент А И клиент Б У клиента А Там сеть назначения 192 168 2.0 У клиента Б 192 168 2.0 MPLS в этом случае Очень удобен Потому что вы говорите Вот если мы сейчас Будем заморачиваться С IP адресацией Будем думать У кого какие там IP адреса Где находятся В какой стороне сети Это нам придется Зверскую таблицу Маршрутизации На всех транзитных Маршрутизаторах иметь Представьте себе Что было бы

Если бы у нас было Там тысячу клиентов У каждого из которых Ну не знаю Тысячу маршрутов Но нам пришлось Иметь там Свои таблицы маршрутизации Помимо того Что там как-то еще Интернет устроен Чисто миллион Клиентских маршрутов Это не так мало В чем заключается Преимущество MPLS Вы говорите Нас плевать на то Какие там IP адреса Вот просто наплевать и все Мы берем И поверх IP пакетов Которые присылает нам клиент На входящем роутере Здесь у нас Point of presence есть У нас приходит пакет От клиента А мы на него шлеп Меточку ставим И отправляем В транзитную сеть Пакет с такой меточкой И вот мы говорим Отправляем пакет С меткой 123.10 Это значит Что он получен От клиента А А если мы отправляем Пакет с меткой 123.20 Это значит Он получен От клиента Б И эти метки Доходят до Транзитного маршрутизатора Что говорит Транзитный маршрутизатор Окей Говорит Транзитный маршрутизатор У меня есть Правило Что 123.10 Я коммутирую Вот наверх А 123.20 Я коммутирую Вот вниз

Вся та же самая история Что была В В В В В В В В Как назывался В В В В В ada Во В В В 2311 а здесь будет 12330 вот как-то так то есть мы указываем с какой стороны какая метка приходит куда ее девать и как перебить метку это и есть mp-l с коммутация в mp-l си она выглядит ровно так же и это не удивительно потому что то как был устроен frame relay он оказался устроен очень удачно вот эта вот сама идея коммутации пакета по каким-то меткам которые на него наложены она оказалась очень быстро и да когда возникла идея с мпл сом когда возникла потребность реализации

мпл сада первым что пришло в голову автором это как раз заимствовать хорошую идею за фрэм рилы для чего нужны mp-l с и как его настраивать это совсем другая история приходите к нам на курсы по провайдер и мы вас научим а пока что вот сегодня это примерно все все что я хотел рассказать про frame relay я сказал то что нужно для экзаменов cisco в частности для экзамена по роутингу я рассказал не буду вас больше мучить всего вам хорошего и встретимся на наших курсах у нас много всяких разных замечательных курсов на которых мы рассказываем много всяких замечательных историй в частности есть курс по роутингу да ну все а