Работа с канальными средами (часть 2)

Мы продолжаем разговор про канальные среды в рамках нашего курса по маршрутизации. Когда мы передаем какие-то полезные данные с помощью процедур маршрутизации, у нас пакеты будут бегать поверх каких-то каналов связи. Эти каналы могут иметь самую разную природу. Мы с вами обсудили на прошлом занятии под конец, как работает передача данных в Ethernet. Рассказал я вам про то, как упаковываются в кадры Ethernet IP-пакеты. Обсудили мы вопросы того, что в Ethernet у нас есть мультикаст, в Ethernet есть бродкаст, в Ethernet есть полная связанность между любыми двумя узлами. И давайте обсудим еще один вариант, который мы проходили с вами на CCNA, того, как можно связать между собой несколько узлов. Мы с вами проходили в рамках CCNA протокол PPP как образцово-показательный протокол передачи данных в serial link. Если у

нас есть serial link, в этом serial link передаются нолики-единички, и соответственно из этих ноликов-единичек надо собирать каким-то образом кадры, и заработает канальный уровень. За процесс собирания из ноликов-единичек полноценных кадров будет, как правило, в таких линках отвечать как раз протокол PPP. PPP — это не единственный протокол, который можно использовать в serial link. Альтернативы — это может быть HDLC, фирменный цисковский, либо Frame Relay. Но PPP мы его обсуждали как наиболее распространенный вариант. Serial link как таковой вы уже вряд ли где-то встретите, но протокол PPP можно встретить еще во многих разных других применениях, поэтому его с вами и изучаем. Это протокол, в котором мы будем иметь возможность передавать кадры и соответственно в этих кадрах вкладывать какие-нибудь вложения. Причем вложения могут иметь разную природу, разные

типы протоколов мы можем передавать. Можно передавать поверх PPP IP-пакеты IPv4, можно передавать MPLS-ные кадры, можно передавать ATM-ные метки, можно передавать ячейки, можно передавать всё что угодно. CDP-шные, например, кадры тоже можно передавать. У нас есть вариант вкладывать внутрь PPP-шных кадров какую угодно полезную нагрузку. Протокол создавался для того, чтобы работать поверх WAN. И в этих WAN-сетях была своего рода особенность, что эти каналы на момент создания протокола были очень медленные. Классической скоростью для канала, в котором PPP-кадры гонялись, было, например, 300 бит в секунду. При определенных раскачиваниях его можно было догнать до 1200 бит в секунду. Это середина 70-х годов примерно. Поэтому для того, чтобы не занимать канал лишними кадрами, PPP использует процедуру согласования передачи данных по определенному каналу.

Он сначала убеждается, что какие-то кадры по каналу в принципе могут пройти, и только потом эти кадры будет посылать. Поэтому у PPP есть целая пачка служебных протоколов, которые, во-первых, согласуют возможность передачи данных по каналу. А во-вторых, для каждого конкретного протокола передачи данных, самих IP, например, или IPv6, будет еще специальный отдельный служебный протокол, который, во-первых, согласует возможность передачи данных именно этого протокола. А во-вторых, если вдруг это необходимо, согласует какие-то его дополнительные настройки. У PPP есть набор механизмов, который позволяет ему проверить, что канал действительно может быть установлен, и если он будет установлен, то как именно он будет работать. За решение задачи установления канала будет отвечать механизм, который называется LCP, Link Control Protocol.

В рамках этого механизма будет, во-первых, проверяться подлинность сессии, если вдруг мы захотим проверить эту самую подлинность. Мы можем в рамках установления PPP-шной сессии сказать: дорогой соседушка, представься, а то я не уверен, что ты действительно это ты. И сделать это мы можем несколькими разными способами. За это отвечать у нас будут протоколы PAP, CHAP и EAP. Можно будет дополнительно заказать шифрование данных, сжатие данных, причем я уже рассказывал на CCNA, можно отдельно сжимать только заголовки или сами данные. Можно заказать всякие плюшки типа распределения PPP-шных кадров по нескольким разным каналам. Или наоборот, работу в рамках одного канала по нескольким разным сессиям — сделано это для управления очередностью. Там же всякие interleaving. У PPP достаточно много всяких разных возможностей по необычной передаче данных. В нормальной ситуации PPP просто гоняет кадры. Он сначала передает один кадр, потом второй кадр, потом третий кадр.

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

Это все дополнительные механизмы, которые надо включать, по умолчанию их нету, но вы можете их включить, задействовать, и тогда они будут работать. PPP — протокол штатный, поддерживается практически всеми производителями сетевого железа и операционных систем. Можно будет его часто встретить во всяких VPN-ах. Как уже упоминалось, PPTP, L2TP — это всё протоколы, которые на самом деле задействуют возможности протокола PPP. Когда мы поднимаем VPN, например, из Windows, и нам система говорит «скажи пароль для подключения к VPN-серверу», этот логин и пароль проверяются по факту именно протоколом PPP. Кадры PPP будут наследоваться от древнего протокола HDLC. Соответственно, я про него опять же на CCNA рассказывал. Это протокол для передачи данных внутри сети мейнфреймов. У нас есть мейнфрейм — это центральный компьютер размером с комнату. Есть терминалы, состоящие из монитора и клавиатуры.

Соответственно, всё, что на клавиатуре мы набираем, отправляется в сторону мейнфрейма. Всё, что мейнфрейм хочет показать на терминале, он отправляет в сторону терминала, и оно показывается на мониторе, на экране. Для работы в такого рода сети использовался древний протокол HDLC. И формат кадра оказался довольно удачный. Он заимствован был и в протоколе PPP, и в протоколе Frame Relay. И Cisco его тоже немножко модифицировала и сделала из него свой собственный формат Cisco HDLC. Это не обычные стандартные HDLC-шные кадры. Это немножко модифицированные HDLC-шные кадры, которые позволяют Cisco передавать данные совершенно произвольного формата, а не только данные протоколов мейнфреймов. Но PPP заимствует некоторую идею из этого HDLC-протокола. И, в частности, следующее. Когда у нас есть провод, в котором передаются HDLC-шные данные,

на самом деле этот провод не позволяет передавать молчание. В Ethernet у нас есть возможность передавать, условно говоря, либо единичку, либо нолик, либо не передавать ничего. И если все в сети не передают ничего, то все узлы слышат, что среда свободна, что можно ее в какой-то момент занять. В HDLC нельзя было передавать молчание. Нужно было всегда передавать либо нолики, либо единички. И когда вы передаете какие-то полезные данные, вы формируете нолики-единички из этих данных и побитно их передаете. Но что делать, когда вы не хотите ничего передавать? Для этого есть специальная последовательность, которая называется флаг. И этот флаг — это 0, 1, 1, 1, 1, 1, 1, 0. 0, 6 единиц, 0. Эта последовательность означает, что среда свободна, что тот, кто передает такую последовательность из 0, 6 единиц и 0, он не хочет занимать среду. Но он вынужден отправлять что-нибудь в среду, чтобы показать, что сейчас ничего ценного не передается.

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

Причем не обязательно в рамках одного байта. Может быть такое, что у вас будет какой-нибудь байт 1, 1, 1, 0, 0, 1, 1, 1. Это первый байт, и потом рядышком 1, 1, 1, 0, 0, 0, 0, 0. Второй байт. Получается, что 6 единиц подряд у вас должны будут идти, обрамленные нулями. В этой ситуации, для того чтобы в мясе никогда не передавалось 6 единиц подряд, они искусственно разбавляются нулями. И правило будет следующее. Если вы хотите передать 6 единиц подряд в мясе кадра, вы должны будете после пятой единицы поставить 0. И получающий узел, если он видит 5 единиц и 0, он понимает, что этот 0 искусственно добавленный. Даже если вы хотите 5 единиц подряд отправить, и потом после них 0, то вы после 5 единиц добавляете искусственный 0, а потом тот 0, который вы изначально хотели отправить. Если у вас была последовательность 1, 1, 1, 1, 1, 0, которую вы хотели отправить, то после 5 единиц вы вставляете еще один нолик,

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

везде одинаковая. Это не какая-то фича именно PPP-шная, это именно HDLC-шная. Дальше, после того как мы начинаем передачу кадра, там, где у нас передача начинается, самое первое поле будет поле с адресом. И в этом поле мы передаем указание, кому мы это передаем. В протоколе HDLC это было важное поле, потому что там можно было передавать данные от мейнфрейма к терминалу, и терминалов было много. Или от терминалов к мейнфрейму, и мейнфрейм, наверное, мог быть только один. Но тем не менее всё равно надо было указывать, куда данные идут и в каком направлении, и до какого именно терминала. И для того чтобы показать, от какого мейнфрейма к какому терминалу данные идут, у нас было поле с адресом. Мейнфреймом одновременно не могло пользоваться много людей, и терминалов на нем не могло быть слишком много, но пара десятков могло быть вполне, поэтому однобайтного поля с адресом для этого было более чем достаточно.

Один байт — это 8 бит, и дает нам возможность 256 различных адресов создать. Там указывался типа номер терминала, куда мы отправляем, не знаю, номер 17, например. В HDLC это могло быть, что мы отправляем данные на терминал номер 17. В PPP у нас используется протокол этот Point-to-Point только в сценарии, когда у нас 2 участника в канале. Соответственно, один канал, 2 участника, левый и правый. Поэтому, когда мы передаем какие-то данные, мы передаем эти нолики-единички, и нолики-единички попадают только на одного единственного участника. Этот единственный участник либо прочитает ваши нолики-единички, тогда он поймет, что это ему — не по полю с адресом, а просто потому, что никого больше в канале нету. Либо не прочитает эти нолики-единички, тогда они вообще никому не достанутся. Поэтому особенного смысла в поле «адрес» в протоколе PPP уже нету. Оно наследовано от протокола HDLC. Это поле с адресом в HDLC означало номер терминала,

а в PPP оно всегда заполняется 8 единицами. Типа как аналог бродкаста в Ethernet. Всё, что вы отправляете, должно прочитаться всеми узлами в канале. В PPP, Point-to-Point протоколе, только один участник может прочитать ваши битики. И для того чтобы подчеркнуть, что какой бы потенциальный адрес у него ни был, он должен это прочитать, вы забиваете адрес всеми единицами. Типа как аналог бродкастового кадра. Адреса источника в PPP нету. В HDLC он был не особо нужен. А в PPP адресация вообще в принципе не нужна. Поэтому здесь у нас только адрес, просто какой-то абстрактный адрес FF, больше ничего нет. В Ethernet у нас есть два адреса. Адрес получателя, адрес отправителя. Получатель нужен для того, чтобы кто-то там мог зажмуриться или не зажмуриться. А адрес отправителя в Ethernet вообще-то не сильно нужен.

Но коммутаторы пользуются нагло тем, что он есть, для того чтобы заполнить таблицу коммутации. Напоминаю, что изначально коммутаторов в Ethernet не было. И тогда-то как раз адрес отправителя не сильно был кому-то интересен. Для того чтобы трафик вернуть, например, именно тому, кому вы хотите отправить ответ на какой-то кадр — там он просто чисто информационно был. Никакую особенную задачу не решал. Здесь в PPP он просто не нужен, адрес отправителя. Дальше. Control Word, контрольное слово, тоже заимствовано у протокола HDLC. Там можно было указывать, в какую сторону идут данные. Смысл был в том, что в поле с адресом указывался всегда адрес терминала. У вас был мейнфрейм, и к этому мейнфрейму цеплялись отдельные терминалы. Терминал номер 1, терминал номер 2, терминал номер 3. У самого мейнфрейма адреса особо не было. И когда вы передавали данные, вы отправляли данные с указанием своего адреса, своего номера терминала,

и дальше мейнфрейм эти данные мог прочитать. Или вы могли сами получать данные на терминал, и они тоже указывали, что данные именно на первый терминал идут. Всё это дело было в поле с адресом закодировано, но по самому направлению передаваемых данных непонятно было, кто и кому это передает, потому что зачастую это была просто среда с общей шиной. И для того чтобы понять, что терминал должен обрабатывать данные или не должен, или мейнфрейм должен обрабатывать данные или не должен, в поле Control указывалось направление передачи данных. Можно было указать: это идет от терминала к мейнфрейму или от мейнфрейма к терминалу. Фактически, единица в одну сторону, двойка в другую сторону, и тройка — это вообще какие-то абстрактные данные, которых в нормальной сети быть не должно. В PPP, во Frame Relay и в цисковском HDLC как раз в поле Control Word указывается, что это не данные, идущие от терминала к мейнфрейму, не данные, идущие от мейнфрейма к терминалу, это что-то другое.

И там записывается число 3, что означает, что это не мейнфреймовые данные вовсе. Абсолютно у любого HDLC-шного кадра, который мы увидим, как то, во что эволюционировал HDLC — будет адрес FF и контрольное слово 03. Это все разновидности кадра HDLC-шного, которые просто наследуют логику от оригинального протокола HDLC. Дальше HDLC-шная часть заканчивается. Начинается именно фирменная PPP-шная часть. Давайте я сотру со слайда всё. Так, проще сделать. Здесь заканчивается HDLC-шный заголовок. HDLC. Дальше начинается само мясо. И мясо начинается с того, что указывается, что внутри лежит. Полный аналог по смыслу поля EtherType в Ethernet. Если мы указываем, что внутри лежит IP, то это будет 0021.

Значения не такие же, как в EtherType, но тем не менее логика примерно такая же. Если мы указываем, что внутри лежит IP, то здесь будет 0021. Если мы указываем, что внутри будет IPv6, значит, там будет какое-то другое значение. Я так на память не помню. Я уже сказал, что в PPP есть специальные служебные протоколы, которые решают задачи, во-первых, установления канала, во-вторых, согласования возможности передачи данных определенного типа и какие-то необходимые настройки. И есть правило, которое указывает, что первая четверть пространства протоколов — это протоколы, несущие полезные данные. Это IP, IPv6, что там еще бывает, CDP, MPLS — протоколы с пользовательскими данными. Вторая четверть не размечена, она зарезервирована. Третья четверть — это протоколы NCP, Network Control Protocol, те, которые согласуют возможность передачи полезных данных. И последняя четверть — это управляющие протоколы.

Там фактически нужен будет только один протокол — это LCP, у него будет C021. И начинается работа PPP-шного линка с того, что у вас включается физика, лампочка загорается на обоих узлах, что битики нормально передаются. Дальше отправляется кадр LCP-шный в каждую сторону, в котором мы рассказываем, как мы хотим работать в одну сторону и в другую сторону. Потом, после того как LCP отрабатывает, говорит LCP Open, дальше начинает работать NCP. NCP разные, их много: отдельно передается IPCP, IPv6CP, MPLSCP, CDPCP, NBTCP — их много разных, они самые разные бывают. Опять же, в разные стороны могут передаваться разные наборы NCP, и в итоге согласуются только те, которые поддерживаются обеими сторонами. И после того как все NCP согласуются, допустим, IPCP у нас согласовался, Open,

дальше начинают передаваться уже IP-шные кадры. Далее. Далее. Так же, как мы в CCNA проходили про то, что в PPP есть проверка подлинности, сейчас я просто вам напомню кратенько. Да, такая штука есть. Вы можете заказать на этапе согласования LCP, Link Control Protocol, что вас интересует проверить подлинность соседа. Каждый из узлов, который будет связываться по PPP, может проверить подлинность независимо от соседа. Обычно, когда у нас есть PPP, сегодня мы его используем в рамках VPN-подключения, и мы хотим, чтобы тот, кто подключается, типа клиент, предоставил свои учетные данные для проверки сервером. А сервер говорит, что я хочу проверить данные у тебя, дорогой клиент. Но PPP может позволить проверить подлинность независимо как серверу, так и клиенту. У PPP нет такого понятия сервер-клиент.

У PPP есть просто сторона, которая хочет отправлять данные. Соответственно, PPP LCP умеет заказывать проверку подлинности с помощью одного из трех механизмов. PAP, CHAP и EAP. PAP — это простая проверка, в которой пароль пересылается в открытом виде, логин и пароль точнее. CHAP — это процедура, при которой сам пароль по сети не посылается, но подтверждается знание этого пароля. И EAP — это фреймворк для того, чтобы можно было заказывать проверку подлинности с помощью каких-то дополнительных механизмов. Это не какой-то один протокол, а набор методов, которыми можно проверять подлинность самыми разными способами. Можно использовать, например, EAP-TLS с проверкой по сертификатам. Можно использовать EAP с биометрикой, где вы отпечаток пальца будете прикладывать. Только надо будет найти дырочку, куда отпечаток приложить в Cisco. А так Cisco теоретически это может позволить сделать. Ну и в сегодняшних реалиях, естественно, лучше всего будет использовать EAP.

Но тем не менее на экзамене EAP не спрашивают, спрашивают PAP и CHAP. Так. По поводу PAP. PAP передает по сети пароль в открытом виде. Точнее, не просто пароль, а логин и пароль. И выглядит процедура передачи этого пароля следующим образом. У нас есть роутер R2, который видит, что у нас подключается R1 по serial link. И R2 хочет проверить подлинность R1. Он говорит: скажи логин и пароль. Отправляется сообщение LCP Configuration Request, в котором мы говорим, что мы хотим использовать Authentication Protocol PAP. Мы такое сообщение отправляем. R1 видит это сообщение, и если он хочет на него отреагировать — а если он не отреагирует, то R2 со своей стороны LCP Open не сделает и не поднимет интерфейс. Если R1 хочет на него отреагировать, он говорит: я согласен проверить подлинность себя с помощью Authentication Protocol PAP. И отправляет сразу же сообщение по протоколу PAP.

PAP Authentication Request. Он указывает, как его зовут. Указывает свое имя хоста. Скажем, имя пользователя. И указывает здесь же рядышком пароль. И после того, как этот пароль по сети пробегает, R2 проверяет этот пароль каким-то образом и говорит: да, пароль хороший, всё хорошо, Authentication Acknowledge. После этого, если ничего больше не мешает процедуре установления соединений, LCP открывается и открывает дорогу следующим протоколам согласования уже конкретных сетевых протоколов. NCP. Механизм этот простой как барабан, но, естественно, он не очень безопасен. Потому что если у нас вдруг где-то здесь будет сидеть злоумышленник, который будет инспектировать проходящие данные по сети, он перехватит отдельные биты, которые передаются, увидит там кадр LCP, увидит внутри сообщение Authentication Request и скажет: о, прикольно, я вижу, что R1 передает свои данные с паролем, там, не знаю, 1, 2, 3, 4, 5. Более того, если вдруг вы заказываете взаимную проверку подлинности, у вас R1 и R2 оба хотят проверить подлинность соседа.

В этой ситуации получится, что сначала R1 скажет: я хочу Configuration Request, и R2 скажет тоже: я хочу Configuration Request. Кто-то из них должен свой пароль первым показать. Допустим, R1 скажет: окей, я согласен, Configuration Acknowledge, и посылает рядышком PAP Authentication Request. И R2 говорит: окей, всё хорошо, всё замечательно, Acknowledge, LCP открывается. И в свою очередь посылает ответное сообщение: я тоже согласен показать пароль, и он прямо тот пароль, который ему переслал R1, прямо в ответ посылает в сторону него же и обратно. Поэтому получается, что украдёт этот пароль сам. Поэтому когда вы подключаетесь к кому-нибудь, вы, конечно, свою подлинность открываете, но если вам требуется именно двусторонняя проверка, то получается некрасиво, что вы сами свой пароль показываете и вы, возможно, этот же пароль примете обратно. Поэтому PAP — не очень надёжный протокол.

Мало того, что злоумышленник, если он будет подслушивать канал, может узнать, что за пароль вы используете. Если злоумышленник будет с другого конца, он может ваш пароль опять же украсть и аутентифицировать себя на вас тоже с помощью этого же логина и пароля. Поэтому так делать не надо. PAP на недоверенных средах использовать прямо плохо. Если у вас есть среда, в которой злоумышленник может подслушать, что вы передаёте, вам нужно будет использовать какой-то механизм, который не передаёт пароль в открытом виде. Самый первый механизм, который был предложен и поддерживается Cisco, — это протокол CHAP, Challenge Handshake Authentication Protocol. Смысл заключается в том, что если R2 хочет проверить подлинность R1, он посылает Configuration Request, говорит: я хочу тебя проверить, но уже не с помощью протокола PAP, а с помощью протокола CHAP. R1 говорит: окей, я согласен, чтобы ты меня проверил с помощью CHAP. И дальше не он сам уже пароль сразу plaintext-ом гонит, а ждёт, пока R2, тот, кто хочет проверить пароль, отправит так называемый challenge.

Это некое случайное число. Прямо оно генерится на лету. R2 запоминает, что он придумал число. Допустим, 1, 2, 3, 4. Это challenge. И это число отправляется в сторону R1. 1, 2, 3, 4. R1 принимает challenge, и дальше он берёт тот логин и пароль, который он хочет отправить. Отправляет логин в открытом виде. И пароль он смешивает с этим challenge-ем, который получается каждый раз разный, и берёт от этого хэш. Логика заключается в том, что вы из хэша не сможете вычленить оригинальное значение пароля, даже если вы знаете тот самый challenge. Если вы знаете, как смешиваются пароль и challenge, если вы видите сам challenge, видите хэш, вы не можете из него извлечь пароль. И поскольку challenge каждый раз присылается разный, то в следующий раз злоумышленник должен будет уже показать другой хэш от другого challenge-а и пароля, и вычислить, какой будет другой хэш от другого challenge-а и пароля по известным наборам challenge-а и паролей, тоже не получится.

Или, по крайней мере, это будет достаточно сложно. Поэтому логика заключалась в этом, и она в принципе неплохо работала до тех пор, пока не появились компьютеры. И в этих компьютерах стало понятно, что те механизмы хэширования и генерации challenge-ей, которые были предложены авторами протокола CHAP, они всё-таки уязвимы. Они позволяют при достаточно большом наборе challenge-ей и хэшей восстановить оригинальный пароль, если у вас достаточно много накоплено образцов пар challenge и response. Поэтому challenge, конечно же, позволяет вам один раз не передать пароль в открытом виде, но если вдруг злоумышленник может подслушать достаточно большое количество пар challenge и ответ, он может попытаться угадать этот пароль. Для него это будет не так сложно. Поэтому CHAP тоже использовать в продакшене не надо. Если вдруг у вас есть продакшен, используйте EAP. Там уже можно заказать существенно лучшие механизмы хэширования, существенно лучшие механизмы генерации challenge-ей, и вы защитите своё подключение намного более стабильным образом.

Но тем не менее Cisco не рассказывает про то, как это делать, и не требует этого на экзамене. Особенность CHAP-а заключается в том, что для проверки правильности хэша, который пришёл, вам требуется на том, кто спрашивает, знать открытый пароль. 1, 2, 3, 4 — он придумал challenge. Он знает, что пароль, который должен прийти, должен прийти от R1, и в нём должно быть продемонстрировано знание пароля, не знаю, ABCD. Этот логин и пароль ABCD мы на R2 должны знать в открытом виде. Когда мы посылаем challenge, R1 знает, какой пароль он должен послать. Он знает, что у него R1 и ABCD — это пароль. Он берёт challenge 1, 2, 3, 4, берёт пароль ABCD и посылает указание, что R1 — это логин, и какой-то там хэш, не знаю, 0, 1, 2, 3, 4, 5, 6. Какой-то условно случайный хэш получается. R2 берёт тоже challenge, который он придумал, тоже пароль, который у него хранится в базе, хэширует это всё и сравнивает с тем, что прибежало.

Если результат совпал — значит хорошо. Если результат не совпал — значит всё плохо. Значит, знание пароля не продемонстрировано. Но фишка в том, что R2 вынужден знать именно plaintext-овый пароль. Он не может каким-то образом его закодировать, причём закодировать необратимо. Если он не будет знать оригинальный пароль или не сможет его на лету достать, то он не сможет проверить правильность хэша. В PAP на самом деле необязательно требовать знания открытого пароля для того, кто проверяет. Там можно, например, знать только хэш от пароля. Сейчас вернусь на предыдущий слайд. R2, например, может сказать, что у нас есть R1, который должен показать, что его зовут R1, и какой-нибудь хэш 123. Это хэш. Пароль при этом на самом деле ABCD. И когда мы говорим «покажи свой пароль», R1 присылает plaintext-ом свой пароль, мы берём хэш от этого пароля и сравниваем с тем хэшем, который у нас хранится в базе. Если вдруг базу R2 взломают и украдут, восстановить оригинальные пароли из хэша не получится.

PAP в этом смысле для проверяющего будет достаточно неплох. Он не обязан хранить базу открытых паролей. В CHAP-е вы обязаны хранить базу открытых паролей без какого-либо шифрования. Иначе процедура CHAP-а не сработает. Если вдруг вы, например, работаете с реальным миром, скорее всего, вы будете проверять логины и пароли по чему-то типа Active Directory. И у вас, скорее всего, будет какой-нибудь, например, RADIUS Server, вероятно, штатный виндовый NPS — Network Policy Server. И ваши Cisco будут посылать запросы на этот NPS Server, чтобы проверить подлинность по Active Directory. Cisco будет посылать указание, что у меня есть логин и пароль, которые надо проверить. И RADIUS Server должен будет сказать, хорошо или плохо, правильный логин и пароль прислали нам или неправильный. И если он проверяет учётки в Active Directory, то нам придётся в Active Directory отключить необратимое шифрование логинов и паролей.

По умолчанию там оно включено. Дальше. Где можно встретить PPP в современном мире? Как уже говорилось, во-первых, это VPN, а во-вторых, это протокол PPPoE, который позволяет нам внутрь кадра Ethernet сделать вложения, которые будут совпадать по формату с кадром PPP. Там тоже будет адрес, там тоже будет контрольное слово, там тоже будет указание, что внутри передаётся: LCP, NCP и всё такое. Я предлагаю вам сейчас немножко пройти теорию про PPPoE, а потом поднять PPPoE-шный интерфейс на наших роутерах, который позволит нам действительно проверить, что PPP может поверх Ethernet бегать. PPP работает поверх практически любой среды, которая обеспечивает полный дуплекс. На средах с полудуплексным взаимодействием он работать не может, а на полнодуплексных средах он прекрасно работает.

Ethernet, даже коммутируемый, он как раз полнодуплексный, поэтому PPPoE там тоже прекрасно себя будет чувствовать. Зачем PPPoE нужен? Казалось бы, если у нас уже есть Ethernet, в котором так всё замечательно работает, зачем поверх него поднимать PPP? А смысл на самом деле есть. Дело в том, что в PPPoE у вас получается отдельный интерфейс до каждого, кто запрашивает доступ к этой PPPoE-шной сети. В Ethernet-среде узлы, которые к свичу подключаются, могут передавать трафик друг на друга без каких-либо ограничений. Если вдруг вы, например, провайдер, вот это провайдерский роутер, provider edge роутер, а вот это всё — клиентская часть, провайдерский свитч тоже. И клиент номер один с клиентом номер два могут взаимодействовать без каких-либо ограничений. Вы никак не можете повлиять на них, сказать, что клиент номер один с клиентом номер два работать не могут. Или клиент номер один с клиентом номер три работать не могут.

Всё, что вы можете, — это сказать, что когда вы выпускаете клиента номер один в интернет, трафик интернетовский мы через маршрутизатор будем пропускать и там будем каким-то образом ограничивать. Окей, с интернетом более-менее понятно, а внутри сети вы проконтролировать этот момент не можете. Если же вы говорите: окей, давайте мы будем на каждом роутере с провайдерским ставить отдельную виртуальную трубу, и у нас получается отдельный интерфейс на каждого клиента, с этим интерфейсом мы можем управлять очередями, мы можем управлять качеством обслуживания, мы можем управлять скоростью, мы можем, в конце концов, видеть, какой трафик пришёл по каждому конкретному интерфейсу от каждого конкретного клиента. Если нам будет нужно, мы можем таким лёгким, непринуждённым образом сделать так, чтобы трафик от каждого конкретного клиента складывался, например, в базу — и привет закону Яровой. Эта штука как раз очень удобная для провайдеров.

Плюс к тому, мы можем сделать то, чего в Ethernet в принципе штатно нет. Мы можем сказать: к этой PPP-шной трубе подключается только тот, кто покажет логин и пароль. И всякие другие плюшки, которые в PPP есть. Это сжатие заголовков, сжатие данных. Мы можем передавать данные по Ethernet-среде, сразу же сжимая их. Трафик, который будет бегать именно с самого протокола PPPoE, будет использовать следующий подход. Когда у вас есть клиент, он хочет установить сессию с сервером, он отправляет broadcast. Этот broadcast — это поиск сервера PPPoE, запрос идёт broadcast-ом. После того как такой запрос слышат все, включая настоящий PPPoE-шный сервер, он отвечает unicast-ом, и дальше весь остальной PPPoE-шный трафик будет ходить уже unicast-ом только между этими двумя узлами.

Остальные узлы этот PPPoE-шный трафик не увидят. Даже если какой-то роутер трафик захочет отправить broadcast-ом внутри туннельного интерфейса PPPoE, он не будет ничего отправлять в тот интерфейс, который просто обычный Ethernet-овский. Для него эта PPPoE-шная труба будет отдельный виртуальный интерфейс, куда можно отправлять весь трафик. И поверх этого виртуального псевдопровода трафик будет догоняться до роутера провайдера, а дальше уже будет ходить в интернет. Чем хорошо для провайдера эта проверка подлинности? Что если вдруг кто-то взял и подключился к порту абонента, он должен показать логин и пароль. И если он показывает логин и пароль, то это точно абонент. Уже не получится такого, что клиент уехал в отпуск, на его место пришёл сосед по лестничной клетке, взял, вытащил провод из свича, который на лестничной клетке стоит, воткнул свой провод и получил доступ к интернету соседа, не платя за него деньги.

Плюс к тому, всякие фишки типа сжатия заголовков, сжатия данных и прочее — они экономят полосу пропускания и в общем довольно полезны. Если у нас будет IP поверх PPP, например, поверх PPPoE бегать, то нам понадобится протокол IPCP, который будет согласовывать IP-адреса. Но в IPCP очень мало чего можно согласовать. Можно согласовать IP-шник соседа и, пожалуй, всё. Если мы захотим использовать какие-то дополнительные фичи, например, DNS-ы выдать или что-то ещё, то нужно будет использовать и DHCP рядышком с ним. Можно будет всё в принципе по DHCP выдавать, но можно только то, что необходимо прямо для базовой работы, пригнать по IPCP — и всё. Но чаще всего используется и то, и другое. Опять же, если вы используете операционную систему Windows, например, там PPPoE-шный клиент штатный есть. И он как раз настроен и на использование IPCP, и на использование DHCP. Так.

Какой ещё может быть вариант, если у нас есть serial link и мы хотим поверх него гонять данные? Помимо PPP можно ещё придумать другие варианты. Например, Frame Relay. Изначально этот протокол создавался с коммутацией. У нас уже есть протокол с коммутацией — это Ethernet. Но коммутация в Ethernet появилась после того, как придумали сам протокол. И придумали её для эмуляции того, чтобы подключённые к свичу пользователи думали, что они находятся в общем толстом коаксиале. Для пользователя фактически что он находится в коаксиале, что он находится в коммутируемой сети — абсолютно всё равно. Он не предпринимает никакие действия для того, чтобы подключиться к свичу. Никаких специальных действий для этого ему не требуется. А Frame Relay — это протокол, в котором коммутация изначально была. И она там была хитрая. Этот протокол будет в чём-то похож на Ethernet, потому что и там, и там коммутация есть, и там, и там есть кадры.

И в чём-то этот протокол на Ethernet похож не будет. Вы в реальном мире Frame Relay, скорее всего, не встретите, и ни зачем он вам не понадобится. Единственная польза от Frame Relay — это, во-первых, сдать экзамен. Одна единственная польза — сдать экзамен. Вторая единственная польза, которая уже перестаёт быть единственной, — это подготовить вас к тому, что бывает такая штука, как MPLS, которая наследует своей концепцией очень сильно как раз от Frame Relay. Поэтому мы Frame Relay быстренько пробежим. Мы не будем как-то внимательно на него смотреть. Мы даже лабы на него делать не будем. Но если вдруг вам интересно, у нас есть выложенное бесплатное видео про Frame Relay. И можно его посмотреть, там два часа рассказа именно про него адресного. Чем Frame Relay будет похож на Ethernet? Тем, что у нас есть коммутаторы, к которым подключаются пользователи. И эти пользователи могут посылать битики, нолики, единички, которые складываются в кадры, так же как в Ethernet. В каждом кадре написано, куда этот кадр идёт.

Каждый коммутатор принимает кадр, смотрит в этот кадр и принимает решение, куда этот кадр отдевать. Так же как в Ethernet, кадр может быть переменной длины. В Ethernet кадр может быть переменной длины. В Frame Relay тоже кадр переменной длины. Только в Ethernet у нас кадры отделяются друг от друга процедурой молчания ягнят. Когда у нас есть так называемый interframe spacing в Ethernet. Когда мы кадр передали, мы немножко помолчали Как минимум 96 биттаймов Потом снова кадр передали, снова помолчали Можно помолчать подольше, можно помолчать поменьше Но как минимум 96 биттаймов мы должны будем подождать Во Frame Relay мы используем кадры HDLC-шного или похожего на HDLC формата И когда мы передаем кадры, мы не передаем флаги Когда мы закончили передачу кадров, мы передаем флаги Кадры могут быть маленькие, могут быть большие Что в Ethernet, что во Frame Relay И в этом эти протоколы будут похожи друг на друга Все остальное во Frame Relay может быть не похоже на Ethernet

В частности, в локальных сетях, для которых создавался Ethernet И для которых потом создавалась коммутация для Ethernet У нас пользователи находятся рядышком друг с другом Все пользователи плюс-минус одинаковые LAN-сеть — это одноранговая сеть У нас все пользователи одинаковые Все пользователи имеют одни и те же права Никто из них не лучше, чем другие И любой пользователь может любому другому пользователю посылать трафик Ethernet классический, с толстым желтым коаксиалом Общая среда Мы не можем отправить кадр одному и не отправить кадр другому Мы отправляем кадр сразу всем Во Frame Relay у нас это протокол для WAN сетей И там нет необходимости доставлять кадр между любыми двумя узлами Более того, если мы будем иметь возможность отправлять кадр, который достанется до всех участников То мы тем самым забьем каналы всем-всем-всем участникам Поэтому в Frame Relay нету бродкастов Вы не можете отправить такой кадр, который дойдет до всех-всех-всех участников

Есть только Unicast И вы можете в явном виде указать, что вы хотите отправить кадр в сторону Васи И коммутаторы, если смогут, прокоммутируют ваш кадр именно и только в сторону Васи Если вдруг непонятно будет, куда такой кадр девать Его не отправят никуда, его просто выкинут А если будет известно, где сидит Вася Будет понятно, как доставить трафик до Васи То до него кадр доставлен будет Но не может быть такого, что вы отправили один кадр, а он разделился И копии его отправились в несколько разных портов Коммутация в Ethernet у нас как раз так и устроена Что мы любой кадр отправляем в виде копии на все порты, кроме некоторых Куда мы точно знаем, что кадры посылать не надо Здесь уже коммутация честная Мы принимаем кадр с одной стороны И если мы знаем, куда его девать, мы его всегда выплевываем ровно в одну сторону А если не знаем, то выкидываем Мультикаста, как следствие, тоже нету Вы не можете взять и раздвоить кадр во Frame Relay Он пришел с одной стороны, вы можете отправить его только в одну сторону

В один другой порт Если вы знаете адрес получателя, вы можете доставить кадр до него Можете отправить кадр, и дальше он прокоммутируется в сторону получателя Если вы не знаете адрес получателя, то вы кадр ему доставить не сможете Это принципиальное отличие от Ethernet Вы должны знать заранее Unicast-овый адрес вашего получателя Может показаться немножко странным Потому что как же мы узнаем адрес получателя Если мы только что к сети подключились И мы никакой информации от него еще не получали И что вообще в такой ситуации делать Но здесь надо опять же вспомнить, что Frame Relay — это протокол для WAN-сетей Что такое WAN-сеть? Это у нас есть распределенная сеть Которая не принадлежит какому-то отдельному клиенту Она принадлежит провайдеру И к этому провайдеру подключаются клиенты У нас есть клиент-офис с одной стороны, офис с другой стороны И эти два офиса должны между собой взаимодействовать Новые офисы просто так в провайдерской сети не возьмутся ниоткуда Это единичный случай, когда у нас подключаются какие-то новые точки присутствия

И можно просто позвонить провайдеру и сказать Дорогой провайдер, у нас сегодня подключается новый офис Я хочу знать заранее Unicast-овый адрес того роутера, который подключается к такой сети Скажи мне его, пожалуйста И вы можете его просто на бумажке записать И каждый раз, когда вам нужно будет, вы его можете использовать Можете статически прописать в настройке вашего роутера В настройке вашего абонентского устройства, которое подключается к провайдеру Бродкаста нету Как следствие никакой процедуры типа Заорать на всю сеть и сказать У кого из вас такой айпишник, скажите свой мак Это в принципе невозможно сделать Потому что бродкаста нету как такового И мультикаста нету Поэтому распознавание адресов соседей может осуществляться только вручную Когда мы достали блокнотик Из блокнотика прочитали, какой мак у соседа Там не маки, там другие адреса Но тем не менее, какой адрес должен быть у соседа И прописали статическую привязку Что такой айпишник соответствует такому адресу Дальше Еще одна штука, которая во Frame Relay принципиально не похожа на Ethernet

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

Это единичные случаи, когда подключается новый абонент И вам нужно подключить этого абонента в сеть Вы в этом случае прописываете, что новый абонент с таким адресом Будет сидеть вон в том направлении И каждый раз, когда будут приходить кадры на этого абонента Вы говорите Окей, не проблема, мы его уже прописали Кадры до его узла, до его адреса Могут коммутироваться в его сторону Но если вы не пропишете нигде указания, где сидит абонент То трафик до него ходить уже не будет Так, дальше Что касается примерного возраста Frame Relay На самом деле протокол довольно старый И он примерно тех же самых годов, что Ethernet Ethernet в 1974 году появился, в 1973 И разрабатывал его Metcalf для LAN сетей А в 1975 году появился Frame Relay И разрабатывался он именно для WAN сетей Поэтому некоторые концепции у них похожи Потому что протоколы решают схожие задачи

И то, во что выродился Ethernet в современном мире Тоже в принципе на Frame Relay в некотором смысле похоже А некоторые концепции у них различаются Именно потому, что раньше, 40 лет назад Передача данных в LAN сетях и передача данных в WAN сетях Они были прямо совсем друг на друга не похожи В LAN сетях были большие скорости В WAN сетях скорости были маленькие В LAN сетях можно было себе позволить заорать на всю сеть В WAN сети заорать на всю сеть было нельзя Процедура передачи данных во Frame Relay Ее свойства определяются именно решением задачи Организации передачи данных в WAN сети Как будет выглядеть процедура коммутации кадра во Frame Relay? У нас есть провайдерская сеть P-network И здесь есть Frame Relay свитчи На картинке только один свитч Но тем не менее их может быть несколько

Для нас это не сильно важно Трафик, который может проходить, может коммутироваться через эту сеть Должен проходить определенными трассами И эти трассы будут называться словом virtual circuit Они бывают постоянные Permanent virtual circuit или switched virtual circuit Чаще всего как раз использовались PVC Permanent virtual circuit Фактически вы говорите, что если у нас есть Роутер клиентский номер один И роутер клиентский номер два То для того, чтобы трафик прошел от клиента один до клиента два Мы должны будем сказать, что все, что приходит от клиента один Мы отправляем на клиента два по такой трассе А если у нас есть какой-то другой маршрут трафика Который должен отправляться Допустим, от первого до третьего роутера То мы принимаем кадр от первого Дальше коммутируем его в сторону третьего И отправляем в сторону третьего Мы жестко указываем, что когда трафик идет с первого на второй То он всегда проходит по этой трассе

Если трафик идет с первого на третий, то он всегда жестко проходит по этой трассе Это все равно, что если бы мы сказали, давайте мы выкинем движок коммутации из Ethernet свитчей И заменим его другим, который будет смотреть на MAC-адрес отправителя и на MAC-адрес получателя И по этим 12 байтам будет принимать решение Когда на порту источника мы принимаем какой-то кадр, мы смотрим на 12 байт начала заголовка И говорим, когда приходит кадр с такими 12 байтами, мы его отправляем ровно в один тот порт Когда приходит кадр с другими 12 байтами, мы отправляем его в другой порт Фактически PVC — это будет связка порт источника плюс адрес, от кого пришло и к кому пришло На самом деле во Frame Relay нету отдельных адресов, там это всего один адрес будет И он кодирует в себе сразу и кто отправил, и кому отправил Если кадр пришел по определенному интерфейсу Там стоит адрес отправителя и получателя, это адрес единый в двух лицах

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

Коммутация с помощью Switched Virtual Circuit — это штука, которая наследует от телефонных звонков Когда вы хотите позвонить кому-нибудь, представьте себе старый аналоговый телефон С дисковым номеронабирателем, который крутить надо было Вы снимаете трубку, у вас раздается гудок Дальше вы начинаете набирать номер Хотите службе точного времени позвонить, набираете 1-0-0 И через некоторое время после того, как вы прокрутили достаточное количество раз Этот диск с номеронабирателем, у вас звонок осуществлен И вы слышите длинные гудки, а потом кто-то снимает трубку Когда вы набираете номер, тем самым вы посылаете сигнализацию На ближайшую вашу телефонную станцию Она делает примерно то же самое, что и Switch Frame Relay Когда вы работаете со Switched Virtual Circuit Она принимает ваше пожелание установить связь с дальней какой-то точкой С дальним вашим абонентом, и говорит Для того, чтобы в этом направлении осуществить вызов

Или осуществить соединение, осуществить коммутацию Мне надо найти следующий в цепочке Switch и попытаться договориться с ним Сказать, если он согласен принять мой вызов Если у него есть достаточная мощность, если у него все хорошо Тогда я с ним свяжусь и по специальному служебному протокольчику Постараюсь согласовать с ним передачу данных И дальше если у вас это удалось сделать То вы прописываете динамическое правило на Switch Сам Switch прописывает, что трафик от одного узла до другого Будет ходить в сторону следующего Switch Тут то же самое делает Он пытается найти направление, в котором находится получатель С помощью сигнализации связывается со следующим Switch И если все хорошо, прописывает правила коммутации И после того, как все свитчи в цепочке друг с другом договорились С помощью сигнализации, они друг на друга ставят правила коммутации И трафик в пределах этого временного канала будет бегать После того, как вы закончили работу, вы отправляете сигнал Что все, вы закончили, и все эти звонки терминируются

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

Если вам надо срочно позвонить кому-нибудь И передать ему какие-то данные Вы пытаетесь это сделать, и у вас не получается Ну, беда А с Permanent Virtual Circuit у вас получается гарантированная полоса Которой можете пользоваться вы и никто другой И эта штука реально была востребована На самом деле весь Frame Relay послужил основой для MPLS Концепция с временными вызовами — Это фактически MPLS Traffic Engineering в чистом виде с RSVP А сама процедура коммутации PVC — это в принципе сам чистый MPLS классический В том виде, в котором мы его знаем, он тоже отсюда растет Поэтому мы сейчас с вами пробежимся быстренько по Frame Relay Запомним основные термины, и потом, когда вы MPLS будете смотреть Для вас некоторые концепции по крайней мере будут уже знакомы Frame Relay был интересен тем, что у него адрес в кадре был не кратен байту

Более того, он мог быть еще и разной длины Чаще всего использовались 10-битные адреса И назывались они DLCI — Data Link Connection Identifier В кадре этот DLCI не просто был не кратен байту Не просто был 10-битный, а он еще хранился в двух разных местах Часть адреса хранилась в одном месте, часть адреса в другом месте И эта наркомания была опять же от телефонистов Телефонистам это было типа норм А потом, когда в 70-х годах решили развивать Frame Relay Они недолго думая заимствовали эту концепцию Даже несмотря на то, что для телекома она была какая-то немножко дурацкая И в итоге получилось, что у нас адрес состоит из двух частей Ни одна из которых байту не кратна, и в совокупности они тоже байту не кратны Но тем не менее, выглядеть это будет следующим образом. Здесь показан кусочек кадра Frame Relay, который содержит 16 бит,

два машинных слова по 8 бит. Первое машинное слово и второе машинное слово. И первые 6 бит адреса этой самой DLCI, DLCI High Order, хранились в первом байте. Потом указывался битик CR, это битик команды или ответа, и всегда хорошо известное зарезервированное значение 0. После чего ещё 4 бита адреса передавалось. Два битика FECN и BECN, которые вы, возможно, будете помнить из протокола IP. Там тоже аналогичные штуки есть. Вы можете сказать, что у вас где-то в сети случилась перегрузка. И если вдруг вы отправляете какой-то кадр, и он проходит через коммутатор, и коммутатор говорит, что я не могу все кадры отправлять, которые проходят через этот интерфейс. Я этот кадр пропускаю, но некоторые другие кадры на этом интерфейсе выбрасываю, потому что у нас случается перегрузка.

Этому кадру выставляется флажок, что он чудом прошёл через свитч. Этот флажок как раз FECN — Forward Explicit Congestion Notification. Обратите внимание, это не отправителю уведомляют, что твои кадры вызывают перегрузку. Это получателя кадра уведомляют о том, что этот кадр чудом прошёл через мясорубку. И когда этот кадр прошёл через сеть и доходит до получателя, получатель принимает такой кадр с флажком, и он отправляет ответ. Возможно, отправляет. Может быть, он не отправит ответ. Но тем не менее, он отправляет ответ, что встречные пакеты чудом прошли через мясорубку. И этот самый BECN — Backward Explicit Congestion Notification — означает, что если вдруг вы, как отправитель, получаете от получателя ответы на ваши кадры, и у них проставлен BECN, значит, ваши кадры чудом прошли через мясорубку, и вам надо притормозить немножко отправку данных, поменьше их отправлять. Эта штука есть в TCP, есть она в IP, в современных версиях IP.

Во Frame Relay она первая появилась ещё до того, как это стало трендом. В IP ещё не придумали, когда Frame Relay появился. И FECN, BECN там уже как раз были. Это механизм, с помощью которого можно управлять перегрузками. Если вдруг вы отправляете данные, и они вызывают перегрузку в сети, то вас можно уведомить, но уведомляет об этом не тот узел, где возникла перегрузка, а тот, кто является конечным получателем этого трафика. До получателя доходит уведомление. Твои пакеты, которые до тебя сейчас только что дошли, вызывают перегрузку. И в ответных пакетах получатель уведомит отправителя, что перегрузка действительно есть, надо притормозить. Этот самый DLCI, состоящий из двух частей, 6-битный High Order и 4-битный Low Order, в итоге получает 10 бит размера. И в этом DLCI кодируется сразу и отправитель, и получатель.

Значение DLCI будет назначаться на пару отправитель и получатель. Более того, это будет значимое в пределах физического провода значение. Если у вас есть какая-то Frame Relay сеть, в которой несколько разных свитчей... Давайте попробую сейчас её нарисовать. Сотру всё со слайда, чтобы оно не мозолило глаза. Предположим, у нас есть провайдерская сеть, состоящая из, например, первого свитча, второго свитча и третьего свитча. И у нас есть два узла, которые подключены к этой сети. Здесь у нас узел А, здесь у нас узел Б. И узел А хочет отправить кадр в сторону узла Б. Он его посылает и указывает, кто он и куда он хочет отправить. И он здесь указывает DLCI, например, сотую. Что означает? Это от узла А до узла Б. По какому-то правилу он эту самую сотую DLCI узнаёт. Самый простой способ — ему провайдер сказал, что когда ты, узел А, хочешь отправить трафик к узлу Б,

пожалуйста, помечай все свои кадры номером 100. Если хочешь отправить по какой-то другой трассе, например, здесь где-то у нас есть узел С, ты, пожалуйста, используй номер 200. Поскольку сейчас у нас идёт именно до узла Б, то используется номер 100. Кадр доходит по проводу до Frame Relay свитча. Свитч говорит: я получил этот кадр на входящем порту, и на этом порту у меня висит указание. Всё, что промаркировано DLCI сотой, мы отправляем в выходной порт, который у меня здесь. Фишка в том, что DLCI может меняться в этот момент. Мы не просто кадр перекладываем, а мы можем ещё и DLCI поменять, а можем и не поменять. Допустим, представим себе, что здесь мы ничего не меняли, что кадр мы просто переложили, и так случайно получилось, что DLCI осталась та же самая, сотая. Но это всё равно — DLCI указывает, что трафик идёт от А до Б. И этот кадр доходит до следующего свитча в цепочке.

Следующий свитч в цепочке уже говорит, что надо дальше делать, и он перекладывает этот кадр по своей таблице коммутации. Но здесь уже, например, может поменять DLCI. Содержимое кадра от этого не изменится. Но номер DLCI будет уже меняться. И здесь, допустим, указано 150. Это по-прежнему означает, что трафик идёт от узла А до узла Б. Но эта зона, в пределах которой 150 означает, что это именно от узла А до узла Б, это только в пределах канала между двумя свитчами. Равно как и здесь 100 означало только в пределах этой области, что это от А до Б. И здесь тоже, что это от А до Б было в своей области. И наконец, последний свитч в цепочке может передать трафик в сторону узла Б. И если он захочет, он тоже может поменять DLCI. Он скажет, что это DLCI, например, 400-я. 400-я. Это опять же означает, что это от А до Б. Поэтому номер DLCI — это не постоянный адрес, как в Ethernet был,

когда мы отправляем кадр и он не меняется. У него никакие поля не меняются. Не меняются адреса отправителя-получателя. Не меняется содержимое, не меняется чек-сумма. Здесь адрес может меняться при коммутации. И более того, он чаще всего меняется. Конечный получатель в этом случае получает кадр с DLCI четырёхсоткой. И по этой DLCI он понимает, что это кадр, который пришёл к нему от А. И если он будет отправлять кадр в сторону А, он может воспользоваться этим номером или, может быть, каким-то другим. Эта совокупность указаний, что на что меняется, в какой момент, в какую сторону коммутируется, она будет как раз и называться PVC. Может быть такое, что PVC здесь была одна, а в другую сторону PVC будет уже другая. Здесь трафик будет приходить с четырёхсотой DLCI, а в другую сторону он будет отправляться с четырёхсот пятидесятой.

То, что мы отправляем от А до Б, маркируется четырёхсоткой. То, что мы отправляем от Б до А, маркируется четырёхсот пятидесятой DLCI. Значение DLCI назначает администратор провайдерской сети. Именно провайдер говорит, какой трафик он согласен через свои свитчи пропускать. Именно провайдер говорит, в какую сторону надо коммутировать кадры, приходящие через определённый интерфейс с определённой DLCI. И он из числа свободных DLCI в пределах определённого канала просто выдаёт конкретную DLCI своему клиенту и говорит: дорогой клиент, ты, пожалуйста, маркируй сотой DLCI. После чего он просто в каждом канале выбирает свободную DLCI. Это абсолютно то же самое, что в MPLS. В MPLS тоже метки, которые будут передаваться, будут абсолютно локальные для канала. И здесь та же самая история. MPLS вырос из Frame Relay. Именно поэтому здесь всё вручную, всё локально значимое.

И вы должны будете вручную указывать, в какую сторону, какие пакеты, с какими метками перекладывать. Единственное, что практика показывает: если у вас клиентов не очень много, то будет удобнее, если везде в пределах PVC эти метки будут совпадать. Если у вас в 10-битных DLCI, это 1024 различных номера, некоторые из них будут служебные, примерно 1000 DLCI у вас будет. Если точек присутствия всех клиентов не больше, чем 1000, то мы можем просто сказать, что трафик от одной точки присутствия клиента до другой будет использовать одну DLCI, и она будет везде в пределах всей сети одна и та же. Здесь мы сказали клиенту: используй сотку — значит, оно везде будет сотка. И здесь сотка, и здесь сотка, и здесь сотка. Так просто удобнее. Если мы будем видеть в каком-то, неважно каком интерфейсе, DLCI сотку, мы понимаем — это от А до Б.

Мы не должны будем вспоминать: у нас там сотка была занята под что-то ещё, поэтому именно здесь мы дали 150, а там 200, а здесь 400, а здесь 709. Если мы сможем это сделать, мы сможем знать просто, что DLCI сотка — это всегда от А до Б. DLCI 101 — это всегда от Б до А. Опять же, это всё изначально назначалось вручную. Потом придумали механизмы автоматизации, но когда придумали, было уже поздно. Тогда Frame Relay стал уже неактуален. Просто потому, что работает он поверх serial-линков, и скорости в serial-линках не те, чтобы на них как-то серьёзно можно было обращать внимание. Изначально Frame Relay придумали для ISDN, для цифровой телефонии. И там скорости, характерные для этой цифровой связи — это полтора-два мегабита. В современном мире не совсем актуально. Если говорить про то, что в современном мире будет актуально, это, например, скорости, характерные для того же самого Ethernet.

Это хотя бы, например, 100 мегабит. Иногда говоришь, что на нашем стенде только 10 мегабит у нас интерфейсы есть, потому что больше не нужно. И люди как-то начинают расстраиваться. Они думали, что придут на стенд, а тут 10-гигабитные интерфейсы. Потому что 2018 год же. А начинаешь спрашивать: а зачем вам столько? Если мы захотим занять этот интерфейс полностью, то нам проще будет уложить в 100% загрузку 10-мегабитный интерфейс. Мы это хотя бы сможем сделать. Если будет 10-гигабитный интерфейс, мы хоть выпрыгнем из штанов, но нам его нечем загрузить. Нам невозможно будет даже представить себе ситуацию, в которой 10-гигабитный интерфейс в наших лабораторных условиях будет загружен на 100%. Поэтому даже 10-мегабитный интерфейс — это на самом деле дофига трафика. Если вы будете гонять по нему торренты, видюшки какие-то, VHD или что-то ещё, то 10 мегабит загрузить особых проблем не будет.

Но даже 100-мегабитный интерфейс, который уже лет 10 назад был немодный, это уже довольно проблематично загрузить. Это уже реально какие-то большие файлы гонять. Если говорить про 10-гигабитный интерфейс, даже если вы будете ISO-шку 5-гигабайтную гонять, загрузится он у вас на пару секунд, и что? Да. Для современного человека характерно использование больших скоростей. 2 мегабита во Frame Relay — не впечатляет. Вот так будет выглядеть коммутация во Frame Relay. Эта центральная железка — это у нас Frame Relay свитч. Она нарисована как роутер, и на самом деле, если вы будете зачем-то заниматься в лабораторных условиях с Frame Relay, а некоторые эмуляторы позволяют Frame Relay поднять, вы как раз будете использовать serial-линки на роутерах. И с помощью несложных команд можно будет обычный роутер с serial-интерфейсами

превратить во Frame Relay свитч. У нас здесь как раз он такой нарисован, Frame Relay свитч. И он говорит, что всё, что приходит от роутера R1, мы должны будем отправлять либо в сторону R2, либо в сторону R3. У нас две PVC: одна PVC и другая PVC. И правила коммутации говорят, что всё, что приходит на интерфейсе Serial 1.1 с меткой 102 — это значит от первого до второго роутера — мы отправляем в сторону Serial 1.2 с выходящей меткой 201. Всё, что со 102 пришло, мы отправляем на 201. В то же время то, что пришло со 103, мы отправляем на 301. По этой же логике: всё, что пришло на S1.1 с меткой 103, мы перебрасываем на Serial 1.3 с меткой 301. И здесь сделано так, что трафик, который будет приходить из serial-линка на роутер R2, и трафик, который R2 будет отправлять в сторону роутера R1, они будут использовать одну и ту же метку.

Здесь метка 201 используется для выхода трафика R1 в сторону R2, и она же, метка 201, используется для того, чтобы R2 посылал трафик в сторону R1. Если мы захотим, мы сделаем обратную PVC — мы чаще всего захотим — и мы можем сделать так, чтобы они совпадали. Опять же, не обязательно это делать, чтобы они совпадали. Можно сказать, что трафик приходит с DLCI 201, а уходит с 202. Но технически можно, практически не нужно. Поэтому обратная DLCI будет говорить, что то, что пришло с интерфейса 1.2 с меткой 201, такой же, как у нас была здесь, мы коммутируем обратно в Serial 1.1 интерфейс с меткой 102. То, что со 102 пришло на одном интерфейсе, мы выплёвываем с 201 в другой интерфейс. То, что с 201 пришло с этого интерфейса, мы выплёвываем со 102 обратно. И аналогично указываем, что возвратный трафик от третьего до первого роутера,

если приходит с интерфейса, на котором третий роутер сидит, и с меткой 301, то мы это отправляем в сторону Serial 1.1 интерфейса с меткой 103. Достаточно простая концепция, очень не похожа на Ethernet. Потому что в Ethernet мы не говорили, что трафик, который пришёл с адресом таким-то и с такого интерфейса, мы обрабатываем так, а трафик, который пришёл с другого интерфейса, может быть, с таким же адресом, мы обрабатываем эдак. Мы в Ethernet обрабатываем трафик по таблице коммутации только по адресу назначения. Адрес источника там нам не интересен. Интерфейс источника нам там не интересен. Во Frame Relay коммутация происходит в зависимости от интерфейса и в зависимости от метки. Трафик пришёл на определённом интерфейсе с определённой меткой — мы его перекладываем в определённый интерфейс и меняем выходящую метку. Следующий роутер или следующий свитч будет смотреть уже на ту метку, которую мы проставили, и коммутировать её будет по своей таблице. Таблицу надо будет пополнить вручную. Никаких процедур автоматического пополнения здесь особых нет.

Сразу возникает вопрос: а что делать с преобразованием IP-адресов в DLCI? Нам потребуется либо ручками всё назначать, что неудобно, либо можно воспользоваться протоколом, который называется InARP. InARP. И здесь нас спасёт такая штука, что во Frame Relay есть сигнализация. Сигнализация, опять же, во Frame Relay заимствована от телефонистов. И Frame Relay может вам сказать, какие живые DLCI у вас есть. На какие номера вы можете отправлять пакеты. И специальный служебный протокольчик от Frame Relay свитча до вашего роутера может указать список живых DLCI. Он может, например, сказать: 102-я DLCI живая, 103-я DLCI живая, а всё остальное неживое. И если вы знаете, какие DLCI у вас живые, на какие DLCI вы можете отправлять кадры, и они до кого-то дойдут,

но вы не знаете, кто за этими DLCI сидит, вы можете для некоторых задач воспользоваться тем фактом, что вы хотя бы просто знаете их список. Если вдруг у вас есть острое желание отправить IP-пакет на адрес соседа, вы IP-шник соседа знаете: 192.168.5.7. IP-шник вы знаете, а DLCI, за которой он сидит, вы не знаете. Если бы вы были за Ethernet-узлом, что бы вы сделали? Вы бы заорали на всю сеть: ребята, у кого из вас IP-шник 192.168.5.7, скажите свой MAC. И вам бы рано или поздно пришёл бы MAC того, кто обладает этим IP-шником. Что можно было бы сделать во Frame Relay? Во-первых, можно было бы сказать: давайте мы отправим ARP-запросы на все DLCI, которые к нам прибегают. Нам же говорят, что есть здесь 102-я DLCI, 103-я DLCI, 104-я, какие-то ещё. Давайте мы в каждую из них отправим запрос.

А не ты ли случайно 5.7? А не ты ли случайно 5.7? Если нам прибежало, например, тысяча DLCI, мы в каждую из них отправим запрос. А не ты ли там сидишь? Если у нас тысяча соседей, тысяча DLCI прописано, каждая DLCI — это фактически PVC, которую мы купили, за которую мы деньги заплатили. И у нас тысяча офисов подключено к Frame Relay сети. И в каждую из тысячи DLCI мы посылаем тысячу запросов. А не ты ли IP-шник такой? А не ты ли IP-шник такой? А не ты ли IP-шник пятый? А не ты ли IP-шник десятый? В каждую DLCI мы должны послать каждый IP-пакет с запросом, а не ты ли он там такой. Поэтому это очень затратная получается штука. И от такой идеи отказались. Фактически от идеи вместо одного broadcast ARP-запроса сделать огромную тучу unicast-запросов отказались по совершенно логичной, очевидной причине. Если IP-шников много, DLCI много, это превращается всё в безумный совершенно объём. Поэтому вместо того, чтобы запрашивать адрес соседа, мы вместо этого отправляем единоразово на этапе установления соединения уведомление о том, какой IP-шник у нас.

У нас есть DLCI 102, мы один раз туда отправляем наш собственный IP-шник 172.168.55. У нас есть DLCI 103, в которую можно отправлять трафик. Мы в неё тоже отправим наш IP-шник 172.168.55. И делать мы это будем с помощью протокола Inverse ARP. Эти DLCI нужны для того, чтобы отправить трафик в удалённую сеть. Если мы узнали по сигнализации, что такие DLCI живые, эти DLCI использовались для доставки трафика по указанным адресам. И какой-то узел 172.168.57 узнал, что к нему пришёл пакет из 400-й DLCI, в которой написано, что меня зовут 172.168.55. И в предположении, что DLCI, в которых приходит трафик, и DLCI, в которых уходит трафик, одинаковые, он будет знать, что все пакеты на адрес 172.168.55 надо посылать на 400-ю DLCI.

Эта штука не всегда хорошо работает. Во-первых, она требует, чтобы у вас сигнализация работала. А сигнализаций во Frame Relay бывает три разных вида, и они несовместимы между собой. Если у вас везде, во всём Frame Relay используется железо, настроенное в одной и той же логике, что на всех свитчах поддерживается нужная сигнализация, на всех абонентских железках поддерживается та же самая сигнализация, что в провайдерской сети, то вы можете рассчитывать на то, что InARP сможет получить список живых DLCI. И во-вторых, надо, чтобы администратор провайдерской сети не сошёл с ума и не настроил такое, что трафик в PVC туда приходит с одной DLCI, а в PVC обратно поднимается с другой. Если он такое сделал, то InARP тоже сломается. Но тем не менее, в предположении, что все не делают какой-то ерунды, что у вас всё железо куплено как положено от Cisco, InARP работать будет. Если не работает — значит, надо ручками прописывать, ничего тут не сделаешь.

Если у нас есть IP поверх Frame Relay, то нам потребуется либо ручками прописать все связки IP-адресов и DLCI, либо использовать InARP в предположении, что у нас работает сигнализация, что InARP поддерживается, и администратор провайдерской сети ничего не натворил. По сути, эта штука не часто работает, и чаще всего мы просто ручками вынуждены были прописывать, какой IP-адрес какой DLCI соответствует. Это не так много работы, как может показаться. Если у вас есть провайдерская сеть, и у вас есть офис в Москве, и у вас есть офис в Питере, то здесь у вас роутер, и здесь у вас роутер, и вам нужно только один IP-адрес соседа прописать. Вы указываете, что провайдер сказал: сотая DLCI, это IP-адрес 192.168.2.2. А здесь у нас 101 DLCI и 192.168.1.1. Мы указываем, что такой IP-шник сидит за такой DLCI.

Два узла связаны между собой через провайдерскую сеть, и они здесь — 1.2 и 1.1. И они друг на друга настроили указание, что сосед сидит за такой-то DLCI, и IP-шник у него такой. И всё, этого достаточно для того, чтобы оно работало. Ещё одна штука, которая у нас в рамках курса будет, это GRE, тот самый упоминавшийся уже протокол Generic Routing Encapsulation, который позволяет внутрь себя положить всё что угодно. Он может передавать любые пассажирские данные и таскать их по транспортной сети поверх, например, транспортного протокола IP. Смысл будет в следующем. Если у нас есть какая-то сеть, например, публичный интернет, в нём работает передача IP-пакетов, и если нам нужно передавать по этой публичной сети какие-то данные, которые в норме через этот интернет передавать не хочется или не можется, например, потому что у нас где-то есть частная адресация,

то мы можем поверх этого публичного интернета, поверх публичной транспортной сети построить псевдопровод. И дальше использовать этот провод как обычный провод для того, чтобы поверх него запустить динамическую маршрутизацию и гонять, например, внутри него какие-то частные данные. GRE просто берёт и упаковывает данные в свой заголовок. Он из какого-то плохого, например, частного пакета, путём приклеивания к нему правильного публичного заголовка, делает нормальный пакет для прохождения через публичную сеть. Так. GRE будет использовать вложения напрямую в IP, у него будет свой заголовок, вкладывается в IP с кодом 47, и дальше внутри заголовка GRE есть поле, что внутри лежит — это protocol type. Фактически это то же самое, что EtherType. Там даже значения те же. Если вы вкладываете в GRE IP, то у вас здесь будет 0800. То же самое, что в Ethernet мы вкладывали. Если вы вкладываете в GRE ARP,

у вас будет 0806. Если вы вкладываете IPv6, у вас будет 86DD. Бывают экзотические варианты, когда вы, например, хотите внутрь GRE положить тот самый Ethernet, уже упоминавшийся Ethernet over IP микротиковский. Я, честно говоря, не помню, какой там protocol type. Там, по-моему, 6500 что-то. Тоже какое-то значение. 6900. Какое-то значение, которое не совсем стандартное. Не сказать, чтобы оно прямо проприетарное было, но из области, которая не регламентирована в явном виде. Там используется обычный GRE. И внутрь GRE вкладывается кадр Ethernet. И внутри, чтобы показать, что именно лежит Ethernet, указывается специальное хитрое значение. Дальше. Заголовок у GRE будет следующий. Он будет кратен 4 байтам. Всегда по размеру.

Но он будет переменной длины. И его длина будет определяться тем, какие опции вы заказали. Самый первый бит будет указывать, есть ли второе машинное слово. Там первое машинное слово, второе машинное слово, третье машинное слово, четвёртое машинное слово. Если GRE захочет, он может отправить данные с только первыми четырьмя байтами заголовка. И первые четыре байта заголовка будут нести в себе указание, что внутри лежит, и больше практически ничего. Такой минималистичный заголовок. Левая половина будет отводиться под всякое служебное. А в правой половине в двух байтах будет лежать указание, что внутри лежит. Из того, что здесь ещё было бы интересно. Первый бит указывает, есть ли второе слово.

И если есть, это означает, что у вас добавлено 4 байта под хранение чексуммы. Но чексумма в GRE будет двубайтовая. Поэтому такой хитрый подход. Используется тот же самый алгоритм, что и в IP, что в ICMP, что в TCP, в UDP. Называется Internet Checksum. Если здесь лежало число 0, то этого поля просто нет. Если там была единица, то это поле появляется. И в первые 2 байта вкладывается чексумма. Оставшиеся 2 байта будут пустые. Нулями забиты. Второй бит ни на что не влияет. Там зарезервирован нолик. Третий бит используется для того, чтобы можно было поднять между двумя узлами несколько разных псевдопроводов. Например, у нас есть роутер здесь и здесь. И мы хотим поднять один псевдопровод такой и другой псевдопровод сякой. И для того, чтобы не перепутать, где какой провод у нас используется, где какие данные, каким заголовком помечены,

каждый псевдопровод будет передавать данные и указывать в каждом пакете так называемый ключ. Фактически это просто 4-байтовое число. Это не пароль. Это именно ключ. И вы говорите, что всё, что отправляется по нижнему проводу, всё идёт с ключом 1. А всё, что идёт по верхнему проводу, идёт с ключом 2. Поэтому мы не перепутаем, какие данные прошли по одному псевдопроводу, какие по другому. Опять же, это может быть интересно, если у вас используется, например, какой-нибудь хитрый сценарий с NAT, где-то какие-то данные через NAT проходят, где-то не проходят. И нам нужно не перепутать, какие именно пакеты относятся к какому из клиентов. Например, у нас есть какой-то центральный роутер HQ, и есть облако интернета. И какой-то провайдер, он выполняет трансляцию сетевых адресов NAT. И к этому провайдеру подключаются два других роутера. Первый и второй. И они оба хотят подключить GRE-соединение с центральным.

С точки зрения роутера в центральной штаб-квартире, оба роутера — и R1, и R2 — будут выходить из-под NAT, из-под одного и того же IP-шника. Поэтому для того, чтобы не перепутать, что пришло в одной сессии, а что пришло во второй, как раз роутеры 1 и 2 могут этим ключом играть и указывать, что пришло от них, а что пришло не от них. Его надо назначать вручную, он автоматически не назначается. Если вам нужно, если ваше железо его поддерживает, вы можете его заказать. Но по умолчанию его нет. Всё это поле нулевое. Там, где бит K. И всей этой штуки просто тоже нет. Ещё одна штука, которая есть в GRE, называется sequence number. Если вдруг вы захотите её использовать, вы можете каждый пакет, который вы отправляете, нумеровать. И смысл заключается в том, что если вдруг на получателя приходят пакеты в неправильном порядке, потому что что-то случилось в сети, и ваши GRE-пакеты по дороге перепутались — в интернете такое может произойти — вы можете на уровне самого стека GRE пересобрать пакеты в правильном порядке, как в TCP.

Но если чего-то не доставилось, то ничего с этим не сделаешь. Вы не можете перезаказать отправку GRE-данных. Но, тем не менее, вы их, по крайней мере, можете в правильном порядке собрать. И опять же, по умолчанию этого не происходит. Но если вы хотите, если ваше железо это поддерживает, вы можете поставить флажок sequence number — четвёртый бит. И у вас тогда на 4 байта заголовок вырастет. И все 4 байта будут содержать в себе этот самый sequence number. GRE будет использоваться во всяких разных сценариях, в том числе и довольно полезных. Типичный пример для него — это VPN. Когда нам нужно связать между собой два офиса, мы берём, ставим GRE-туннель, и они получается связаны. На самом деле, когда мы используем PPTP — это такой Remote Access VPN, Point-to-Point Tunneling Protocol от Microsoft — там тоже используется GRE. Сам PPTP используется только для того, чтобы сказать: поставь, пожалуйста, на меня GRE-трубу.

И если у вас есть много офисов, которые надо связывать между собой по GRE, то чистый классический GRE, который по сути своей имеет Point-to-Point природу, становится неудобен. Потому что если у нас есть, например, даже 6 офисов, и мы хотим сделать связь между ними всеми, то мы можем сказать: давайте мы выделим какой-нибудь один офис и поднимем с каждым из них трубу. И на каждом роутере, который не центральный, у нас будет всего один туннель, который смотрит на центральный. Но на центральном придётся иметь 5 туннелей до каждого из остальных. А если мы ещё и не хотим, чтобы трафик через центральный каждый раз проходил, то нам вообще надо сделать Full Mesh. И это, я думаю, вы уже видите, превращается в какую-то пентаграмму — не знаю, будто дьявола пытаемся вызвать. Количество туннелей, которое будет на каждом роутере, будет пропорционально количеству роутеров всего. Если у нас там 100 роутеров, то на каждом из роутеров нам нужно будет поднять 99 туннелей. Это невозможный объём работы. И если у вас действительно много точек присутствия, много роутеров, много туннелей получается,

то поддерживать это в актуальном состоянии становится невозможно. Представьте себе, что вам нужно новый роутер добавить. Вам нужно будет прописать на каждом из роутеров туннель до этого нового роутера. И на нём прописать ещё 6 туннелей. Cisco на это посмотрела и сказала: как-то нехорошо получается, некрасиво, что если у нас какой-нибудь кастомер, у которого 1000 клиентов, 1000 офисов, получается 1000 туннелей на центральную надо прописывать — это перебор. И Cisco придумала хитрую технологию, которая называется DMVPN — Dynamic Multipoint VPN. Эта штука будет позволять на каждом роутере иметь только один интерфейс, который смотрит на всех остальных одновременно. Классический GRE предполагает, что это Point-to-Point туннель, который смотрит только на одного соседа. А DMVPN — это штука, которая использует Multipoint GRE, или mGRE. Это тот же самый GRE, только Multipoint. И оно смотрит одним виртуальным туннелем на всех одновременно. Это не один псевдопровод, который смотрит на одного соседа,

а это псевдопровод, который смотрит на виртуальный свитч. Только свитча нету. И вы имеете один виртуальный интерфейс, который смотрит на всех одновременно. Если вы хотите отправить какой-то кадр куда-нибудь, вы должны будете отправить этот кадр просто по одному единственному проводу. Но единственное, что надо будет — адрес указать, кому вы это отправляете. И здесь возникает вопрос. Окей, пока это всё работает на уровне виртуализации, на уровне того, что псевдопровод, виртуальный туннель — это всё красиво. Но если мы оборачиваем всё это заголовком, у нас есть пакет, который мы хотим отправить. Мы должны будем его завернуть в новый пакет. В этом новом пакете мы должны прописать IP-шники источника и получателя. IP-шник источника мы можем свой прописать. У нас есть адрес, который на нашем публичном интерфейсе, который смотрит в интернет. Мы знаем свой IP-шник. А вот какой IP-шник надо указывать, когда мы хотим отправить трафик Васе? Мы должны его адрес каким-то образом узнать. Когда у нас туннель прописывается до центрального офиса, там всё понятно.

Мы прописываем адрес центрального офиса. Когда у нас туннель поставлен вручную от офиса 1 до офиса 2, мы должны будем прописать на этом туннеле адрес получателя офиса 2. А вот когда у нас всего один туннель, который смотрит на всех одновременно — как узнать тот IP-шник, который нужен для того, чтобы отправить трафик именно к какому-то конкретному клиенту? И здесь начинает работать специальный протокол, который называется NHRP — Next Hop Resolution Protocol. Это протокол стандартный, RFC 2332, но для него сделано небольшое расширение, которое позволяет Cisco использовать его с расширениями. DMVPN стал проприетарным. В принципе сам протокол стандартный. GRE тоже штука стандартная. Но если NHRP использовать с хитрыми TLV, то он становится проприетарным немедленно. И связка GRE плюс этот самый проприетарный NHRP тоже получается проприетарная. Как будет работать протокол NHRP? Если у нас появляется новый узел в сети, он у себя должен будет прописать,

что у него есть интерфейс, который смотрит в это самое облако. Он прописывает свой IP-шник источника и говорит: пожалуйста, зарегистрируйся на Next Hop сервере. NHS. Next Hop Server. И публичный IP-шник этого Next Hop сервера у него будет прописан. И он идёт, регистрируется на сервере, сообщает свой частный адрес — только ему и никому больше. И если вдруг кто-нибудь захочет отправить трафик на этот новый узел, он пойдёт не на него сразу, а пойдёт на Next Hop сервер и спросит у него: а какой публичный IP-шник у узла с частным IP-шником таким-то? И Next Hop сервер ему отдаст публичный адрес, и Spoke уже пойдёт сразу напрямую на публичный IP-шник другого Spoke. У хаба будет база, кто за каким публичным IP-шником сидит. И эта база будет пополняться: когда новый узел приходит, он регистрируется на Next Hop сервере и указывает, какой у него публичный IP-шник, какой у него частный IP-шник.

После чего любой узел может спросить у хаба, как зовут кого. И хаб ответит. Эта штука совершенно гениальна в том смысле, что она прекрасно масштабируется. Для того чтобы новый узел добавить, вам достаточно настроить только один туннель на этом новом узле. На Next Hop сервере вообще ничего прописывать не надо. Next Hop серверу всё равно, сколько узлов на нём будет регистрироваться. Один, десять, сто, миллион. На нём вообще никакая конфигурация не меняется от того, что появляется новый узел. На самом новом узле, который вы добавляете в сеть, конфигурация будет абсолютно та же самая, что и на всех других узлах. Добавление нового узла в сеть заключается в том, что вы просто копипастите конфиг, и он у вас появляется автоматически. И кроме того, всё это дело ещё дополнительно можно шифрованием закрыть. Штатно сам DMVPN не включает шифрование, потому что GRE не включает шифрование. Next Hop Resolution Protocol тоже никакого отношения к шифрованию не имеет. Поэтому DMVPN в чистом классическом виде данные не шифрует. Но если вы захотите, вы можете относительно легко всё это дело ещё дополнительно защитить.

Я пытался нарисовать замочек, но замочек у меня как-то так себе получился. Мы с вами обязательно сейчас сделаем лабу на это дело и попробуем проверить, что действительно оно работает. DMVPN — немножко хитрый механизм передачи данных. Дело в том, что у него неполносвязная топология получается в некотором смысле. Юникастовый трафик будет ходить между любыми двумя участниками. А вот мультикаст в DMVPN работает очень специфически. Между хабом и споками мультикаст ходит. Правда, со специальной настройкой. Если у нас есть желание отправить мультикастовый пакет с хаба, он уйдёт на всех, но уйдёт в виде отдельных фактически юникастовых пакетов. Мы сделаем кучку копий одного мультикастового пакета и завернём их отдельно в юникастовый трафик. И отправим копию мультикаста одному узлу, копию мультикаста другому узлу,

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

Поэтому если вдруг вы захотите здесь какой-нибудь OSPF запустить — OSPF здесь, OSPF здесь — у вас hello-пакеты, которые отправляет один узел, и hello-пакеты, которые отправляет другой узел, они по определению не будут встречаться. Спок 1 никогда не увидит мультикастовый пакет от спока 2 и никогда, ни при каких обстоятельствах не будет считать его своим нейбором. Отсюда, кстати, вывод. Если вдруг вы захотите, чтобы у вас выбирались DR и BDR, то DR должен быть вот этот товарищ — хаб. Потому что только он мультикастовый пакет от всех принимает. Только у него есть полносвязная мультикастовая связность со всеми остальными узлами. По поводу особенностей DMVPN. Хотелось бы сказать пару слов. Есть такая штука, которая называется фаза DMVPN.

Это очень неудачное название, потому что фактически это не фаза в том классическом смысле, в котором мы понимаем это слово. Обычно фаза — это какой-то этап: сначала его не было, потом он наступил, потом он закончился, и процесс перешёл в какую-то другую фазу. Классический термин. Слово «фаза» как-то так воспринимается. Так вот, это никакого отношения к фазам DMVPN не имеет. Фазы у DMVPN обозначают режим работы. Есть три фазы. Это фактически три режима работы, в которых DMVPN может работать. Либо так, либо эдак, либо наперекосяк. Это не означает, что надо сначала поработать в фазе номер один, потом в фазе номер два и в фазе номер три, как некоторые почему-то думают. Я понимаю, почему они так думают. Когда вам говорят, что есть три фазы — фаза один, фаза два, фаза три — вы думаете, что сначала мы посидим в фазе один, потом перейдём в фазу два, потом в фазу три. Нет. Это абсолютно не то, что здесь есть.

Фаза один в случае с DMVPN означает, что у вас поднимается DMVPN, Spoke регистрируется на хабе, и весь трафик между споками ходит через хаб. Сейчас картинку нарисую. Вот хаб. Вот споки. Спок один. Спок два. Спок три. Есть у нас интерфейсы, которыми это всё смотрят друг на друга через какую-то сеть. И Spoke регистрируется на хабе. Один, второй, третий. И когда спок номер один хочет ходить на спок номер два, он посылает трафик на хаб, на тот IP-адрес хаба, который ему известен. А хаб этот пакет пересылает обратно уже другому споку. Хаб знает, за каким IP-адресом какой спок сидит. Смысл фазы один заключается в том, что весь трафик ходит через хаб.

Если у нас есть спок, который хочет отправлять трафик к другому споку, он всё равно отправляет трафик на хаб, и уже хаб отправляет трафик к конечному получателю. Фишка в том, что в такой ситуации динамическая маршрутизация в DMVPN превращается в очень интересную штуку. Хаб может отдавать по динамической маршрутизации дефолтный маршрут и больше ничего. Любой трафик, который принимается хабом, он дальше уже сам разруливает. Что надо отправить куда-нибудь по направлению, что надо отправить обратно внутрь DMVPN, но уже на нужного конкретного получателя. Таблица маршрутизации на наших маленьких споках превращается в одну единственную запись с дефолтным маршрутом. Фаза 2 — это режим работы, при котором трафик у вас ходит не через хаб. Если у вас есть споки, которые зарегистрировались на хабе, и нужно, чтобы трафик между споками ходил напрямую, то спок, допустим, номер 1 спрашивает у хаба, какой публичный IP-адрес у спока 2, получает этот IP-адрес, и трафик между ними начинает ходить уже напрямую.

Трафик между ними напрямую в том смысле, что споки отдают все свои маршруты хабу — это в любом случае так. В случае с фазой 2 получается, что для того, чтобы знать, какой трафик посылать какому споку, нужно знать, какие сети за спиной у каждого спока сидят. И для того, чтобы понимать на споке 1, что какой-то трафик надо послать именно споку 2, нам нужно иметь полноценную таблицу маршрутизации на споках. Здесь у нас будет какая-нибудь сетка, например, 10.1.1.0/24, здесь 10.2.2.0/24, здесь 10.3.3.0/24. В таблице маршрутизации каждого спока все эти сетки должны быть. И должно быть указание на S1, допустим, что сетка 10.2.2.0 сидит за S2. И мы можем направить трафик в эту сеть, и нам достаточно будет для этого понимать, какой публичный IP-адрес у S2. Но в таблице маршрутизации при фазе 2 у каждого роутера будет полное понимание, какие сетки существуют.

Вместо одного несчастного дефолта они будут вынуждены держать в голове всю полную таблицу маршрутизации. Это большие маршрутные таблицы, это необходимость запрашивания IP-адреса по NHRP. И фаза 2 именно так и выглядит. Наиболее популярный режим — когда используется фаза 2, весь трафик ходит напрямую. А то, что в таблицах маршрутизации приходится держать достаточно много маршрутов, для большинства сценариев это не сильно критично. Но если у вас маршрутов действительно много, если у вас споков, например, 1000, и 1000 записей в таблице маршрутизации на споке держать не получается, что в этой ситуации делать? В этой ситуации можно воспользоваться как раз фазой 3. Когда вы по протоколу динамической маршрутизации, дистанц-векторному, отдаёте спокам только маршрут по умолчанию, а они вам отправляют на хаб все свои маршруты. На этом этапе у нас работает всё очень похожим образом на фазу 1.

Казалось бы, в чём отличие фазы 3 от фазы 1, если у нас отдаётся только дефолт, и весь трафик, казалось бы, должен идти только через хаб. Но мы хотим, чтобы трафик через хаб не ходил. И здесь фаза 3 от фазы 1 будет отличаться сообщением NHRP Shortcut. Если до конкретного IP-адреса трафик лучше посылать через другой спок, то вместо того, чтобы спрашивать, как добраться до конкретного спока, конкретный спок в сторону хаба будет просто посылать свои пакеты. И хаб действительно их будет, как в фазе 1, перекладывать в сторону нужного спока. Но одновременно с этим он ещё в сторону отправителя пошлёт сообщение Shortcut. Что, пожалуйста, отправляй в следующий раз пакеты на этот адрес, на этот публичный IP-адрес. И тогда получается, что трафик между всеми споками будет ходить напрямую. За счёт некоторого количества этих шорткатов. В таблицах маршрутизации у вас будет жить только 0.0.0.0 маршрут по умолчанию.

А все эти шорткаты будут добавляться дополнительно, и добавляться они будут в аппаратный ускоритель CEF. Фаза 3 предполагает, что у вас работает CEF. И в таблице маршрутизации будет только один маршрут, а в CEF будут уже все эти шорткаты храниться. И эта штука позволяет в наиболее простом режиме на несложных цисковских железках реализовать взаимодействие, при котором и трафик между споками ходит напрямую, а не через хаб, и в таблицах маршрутизации маршрутов при этом мало. Она требует некоторой дополнительной настройки по сравнению с первыми двумя фазами. Как долго шорткаты хранятся? Если мне память не изменяет, по умолчанию 2 часа. Это можно регулировать, сколько записи NHRP, какой тайм-аут они будут иметь. Понятно, что если у нас интерфейс упадёт и поднимется, то все шорткаты, которые через него были получены, перестанут быть доступны.

У него будет в таблице маршрутизации только один дефолт через хаб, а по факту трафик будет ходить не по таблице маршрутизации, а по таблице аппаратного ускорителя. И в таблице аппаратного ускорителя будет указание, куда трафик посылать. Мы с вами этого пока ещё не прошли, но аппаратный ускоритель — у него будет своя таблица, как по факту посылать трафик. Если у вас аппаратный ускоритель будет работать, у него в таблице будет указание, куда посылать трафик. И это указание будет содержать в себе все шорткаты, которых может быть много. А в таблице маршрутизации при этом будет только один маршрут. Нет, это не кастомная таблица. Это именно таблица аппаратного ускорителя. Про CEF мы с вами будем говорить уже, наверное, не сегодня, а скорее всего завтра. Сегодня мы сделаем лабу на DMVPN и на PPPoE. А завтра, с самого начала занятия, мы будем рассказывать про то, как CEF устроен.

Сначала просто про маршрутизацию говорим, потом про CEF. И там как раз можно будет вспомнить этот момент и вспомнить работу NHRP. Так, безопасность и правила ограничения на передачу трафика между подсетями. Безопасность здесь только с помощью IPsec. Если вы всё это закроете IPsec, то вы можете это реализовать. От режима работы DMVPN, от этой фазы, безопасность никак не зависит. В том смысле, что если вы хотите это всё зашифровать, то вы можете это зашифровать в любом случае. А передачу трафика access-листами вы можете закрыть. Это как в Ethernet. Представьте себе, что у вас есть свитч, к которому подключается пачка роутеров. Роутер 1, роутер 2, роутер 3 и роутер 4. И вы хотите сказать, какой роутер кому куда посылает трафик.

Вы можете access-листами закрыться на выход с интерфейса или на вход и сказать, что мы не отправляем или мы не принимаем трафик определённого характера. То же самое и в DMVPN. Вместо свитча у вас получается облачко. Так. Бывают ещё VPN провайдерские. Мы в нашем курсе не будем особенно внимательно на них смотреть, но рамочно я про них вам расскажу. Провайдерские VPN делятся на два больших семейства. Они используют разные технологии, они используют разные подходы. И для вас как для клиента тоже будет важно понимать, каким именно провайдерским VPN вы будете пользоваться. Со стороны клиента вы получаете просто провод. Обычный провод, возможно, даже Ethernet, в который вы можете отправлять просто обычные данные. Этот провод — на нём написано, что это провод провайдерский, и дальше он втыкается в провайдерскую железку.

В этом проводе вы можете посылать Ethernet-кадры, которые в себе будут содержать что-нибудь. Например, IP-пакеты. Точно так же, как если бы вы соединяли свои собственные устройства проводом. Тоже такой же провод, ничем не отличается. Единственный нюанс заключается в том, что к провайдерской сети вы можете подключить несколько узлов. И вы можете их подключить не к одной и той же провайдерской железке, а к разным железкам, которые находятся друг от друга на большом расстоянии. Здесь нарисовано, что у нас есть свитч, и провод идёт от одного роутера в этот свитч, а от другого роутера в этот свитч. Но вокруг этого свитча облачко. Физически это может означать, что эти два провода втыкаются в абсолютно разные, никак не связанные между собой устройства, которые находятся на большом расстоянии друг от друга. Между ними может быть, не знаю, тысяча километров. И это не будет на самом деле один большой широковещательный домен. Те кадры, которые вы будете посылать с одного роутера на провайдерский свитч, они будут оборачиваться специальным заголовком MPLS,

если вдруг вам интересно. Дальше по MPLS провайдерской сети будут передаваться на другую железку. Дальше заголовок MPLS срежется. И то содержимое, которое вы изначально передавали, будет отправляться на другой ваш роутер. Получается, как будто бы у вас есть прямой провод между двумя железками, которые территориально разнесены между собой на очень большое расстояние. Естественно, это не прямой провод. Естественно, там много разных транзитных железок. Но ваши устройства никак не могут определить их наличие или не могут ощутить, что с пакетами что-то эти транзитные железки сделали. Вы отправили кадр, и этот кадр без изменений прошёл через провайдерскую сеть и дошёл до другого узла, который находится в совершенно другом месте. Эта штука будет называться L2 VPN, потому что фактически с точки зрения вас как клиента вся провайдерская сеть представляет собой один такой мега-свитч.

У услуги L2 VPN есть две разновидности. VPWS — Virtual Pseudowire Service. Это виртуальный провод, псевдопровод. И она по определению точка-точка. Если вы заказываете VPWS, то вы можете к этой сети подключить только два узла. Если вам надо больше, то вам надо несколько таких псевдопроводов заказывать. Или если вы хотите подключить несколько разных устройств к сети и получить доступ к одному и тому же широковещательному домену, то вам надо заказать услугу VPLS — Virtual Private LAN Service. Это две разные услуги. VPWS для провайдера намного проще реализуется, чем VPLS. Но для вас как для клиента, если вам достаточно всего две точки подключить, то вы можете сказать, что, дорогой провайдер, я хочу у тебя псевдопровод. Если вам надо 3, 4, 5, 10 точек подключать, то вы вынуждены будете платить за VPLS. Всякие CDP, LLDP и прочие работать не будут. Как настроит провайдер, так и сделают.

Если вам очень сильно захочется, можно CDP и LLDP пробрасывать. Это не норма в индустрии, но тем не менее можно. Вторая разновидность услуги провайдерского VPN — это L3 VPN. В случае с L3 VPN провайдерская сеть представляет собой виртуальный роутер. Вы подключаетесь к этому псевдороутеру по проводам. И как в случае с любой маршрутизацией, для того, чтобы IP можно было передавать через роутер, надо его накормить маршрутами. Вам потребуется динамическая маршрутизация. OSPF, либо BGP, либо EIGRP. В общем, как договоритесь. Вы кормите его маршрутами. Каждый из роутеров, который вы подключаете к провайдерской сети, должен получить все маршруты. И каждый роутер, который вы подключаете, вы должны будете отдать те маршруты, которые за спиной у него есть. Здесь у нас есть сетка A, здесь у нас есть сетка Б.

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

И трафик, который вы будете посылать, будет бегать только по тем маршрутам, которыми вы снабдите провайдерские роутеры. Он не будет передвигаться по маршрутам других клиентов. И может такое быть, что у вас есть сетка 192.168.1.0/24, и вы эту сетку по динамической маршрутизации вашему провайдеру отдаёте. У другого какого-то клиента есть 192.168.1.0/24, и он тоже эту сетку отдал, и тоже трафик у него бегает. Но ваша сетка 192.168.1.0 и чужая сетка 192.168.1.0 в провайдерской сети не перемешиваются. Это будет именно разделение с помощью MPLS-меток трафика по VPN. И таблицы маршрутизации на конечных железках будут работать каждая в своём VRF, каждая в своей таблице маршрутизации.

Мы с вами про VRF и будем дальше говорить. Но здесь я просто рассказываю про то, что так бывает. Что можно подключиться разным клиентам к роутеру провайдера, запустить с провайдером динамическую маршрутизацию, обменяться маршрутами, совершенно произвольными, с провайдерским роутером. И при этом со стороны провайдера вам ничего лишнего не прилетит, даже если к этому провайдеру подключены другие клиенты, которые обмениваются с ним точно такими же маршрутами. L2 VPN предполагает, что сетка провайдера представляет собой один такой мега-свитч. L3 VPN представляет собой такой мега-роутер. Мега-роутер может быть территориально очень сильно распределён. Может быть такое, что вы хотите с провайдером дружить по OSPF. Вы дружите по OSPF с одной стороны, дружите по OSPF с другой стороны. Провайдер вас в свой внутренний OSPF, естественно, никогда не пустит. Но он может сделать так, чтобы физически — давайте я сотру со слайда, подрисовал всякого —

физически OSPF-пакеты, которые вы будете отправлять, они себя ведут, как будто бы это действительно один роутер, или по крайней мере два роутера. Но то, что между этими роутерами физически связи никакой, естественно, не будет. Они могут находиться очень далеко друг от друга. Один, как уже говорилось, допустим, в Москве, второй в Питере. На самом деле здесь, конечно же, будет работать MPLS, BGP и прочие разные провайдерские штуки, которые мы сейчас с вами не обсуждаем. Но для вас как для клиента вы никогда провайдерского BGP, провайдерского OSPF, провайдерского MPLS не увидите. Вы дружите с ним только по тому протоколу, который вы с ним согласовали. Что эффективнее использовать в рамках одного провайдера — DMVPN или L3 MPLS VPN? Если вам нужна именно минимизация задержек и гарантированная полоса пропускания,

то намного лучше будет использовать провайдерский VPN. Потому что, когда вы заказываете услугу VPN у провайдера, провайдер вам даёт гарантии. Он с вами подписывает соглашение о качестве оказания услуг. Когда провайдер вам предоставляет просто доступ в интернет, трафик, который вы будете посылать в провайдерскую сеть, будет иметь заведомо меньший приоритет, чем трафик именно VPN. И поэтому там не гарантируются задержки, там не гарантируется джиттер, там вообще ничего не гарантируется. Дойдёт до получателя? Хорошо. Не дошло? Значит, не дошло. Если вы знаете, что в принципе провайдер у вас неплохо работает, скорее всего, дойдёт. Но насколько хорошо дойдёт, с какими задержками, с каким джиттером — это зависит от расположения звёзд на небе. И даже если сегодня вы померили и получили неплохой результат, нет никакой гарантии, что завтра тот же самый туннель не начнёт козлить. Поэтому, если для вас критично сокращение расходов, то вы можете сказать, что порт L2 VPN по состоянию на сегодня

стоит порядка 700 долларов за штуку. Если вы подключаете два узла к провайдерской сети, вам нужно два порта — это полторы тысячи долларов в месяц. Очень часто люди говорят: да пошло оно всё. GRE-туннель стоит бесплатно. И если у вас две точки присутствия просто получают доступ в интернет, мы фактически получаем точно такой же транзит пакетов через провайдерскую сеть, просто с отсутствием гарантий. И в одном случае мы платим полторы тысячи долларов, в другом случае мы не платим. И работает вроде и так, и так. В такой ситуации, если для вас критично сокращение расходов и критично, чтобы меньше денег платить, лучше будет использовать просто туннель, который вы сами построите через интернет. Если для вас критично, чтобы у вас не булькал звук, чтобы хорошо работала видеоконференц-связь, особенно та, которая с телепрезенсом, с ощущением присутствия, там для вас потребуется минимальность задержки и минимальность джиттера. И в этом случае вы фактически будете привязаны к использованию L2 VPN.

Как я уже сказал, есть L2 VPN, есть L3 VPN. Разница между ними в том, что придётся сделать клиенту для того, чтобы организовать передачу данных. Если вам провайдер предлагает оба варианта VPN и говорит, что примерно одинаково они будут стоить, у вас возникает вопрос как у клиента, какой VPN взять. Вы можете взять L2 VPN или взять L3 VPN. И очень часто люди говорят, что для L3 VPN нам придётся поднимать динамическую маршрутизацию, а для L2 VPN нам этого делать не придётся. Мы просто получаем как будто бы виртуальный свитч, который Zero Configuration, который просто воткнули — он просто работает. Возникает очень большой соблазн ничего дополнительного не делать, просто сказать: у нас провайдер, он хороший, он всё сделает за нас. Давайте просто будем пользоваться тем, что он нам сделает сразу хорошо. Проблема в том, что нет кнопки «сделать хорошо». Если у вас провайдер эмулирует свитч, а свитч эмулирует толстый жёлтый коаксиал,

то получается, что L2 VPN — это некое подобие жёлтого толстого коаксиала. В случае с именно классическим толстым жёлтым коаксиалом, когда у вас есть какие-то абоненты, которые локально расположены, они подключены к одному и тому же проводу, и если вдруг этот провод рвётся, то у вас просто вся сетка разваливается. Вы про это сразу быстро узнаёте. Если кто-то помнит, как коаксиалы выглядели — там где-нибудь в каком-то месте отвалился коаксиальный терминатор, всё, сетка вся перестала работать, у вас у всех отвалился линк. Если где-то что-то пошло не так, это вызывает отказ всего канала целиком. Если у вас происходит эмуляция этого самого толстого жёлтого коаксиала с коммутатором ли, с L2 VPN ли, то у вас получается, что в каком-то месте может произойти отказ. И в каком-то другом месте другой кусок сети продолжит работать Потому что отвалился только один из фрагментов этой сети, который эмулирует толстый жёлтый коаксиал У вас может случиться такая штука, которая в классическом кластерном мире называется brain split

Когда у вас была какая-то сетка Давайте представим себе, например, что у нас было два коммутатора Это пока ещё не про L2 VPN, это просто про обычные коммутаторы Ethernet Здесь были юзеры и здесь были юзеры И между двумя коммутаторами провод Может произойти такая штука, что этот провод между двумя коммутаторами сдохнет Каждый из коммутаторов эмулирует кусочек жёлтого коаксиала Он говорит: давайте мы представим себе, что всё это один большой коаксиал И другой говорит: это тоже один жёлтый коаксиал Но если бы это действительно был жёлтый коаксиал То падение куска провода сделало бы невозможным работу вообще всех узлов одновременно В случае же с коммутаторами, если вдруг у нас где-то отвалился один провод У нас сетка развалилась на две части Каждая из которых абсолютно самостоятельная Левая часть сети работает, правая часть сети работает А связь между левой и правой не работает Соответственно, получается, что у нас этого отказа в Ethernet просто не было

И протоколы, которые поверх Ethernet работают Которые ожидают, что если у нас где-то что-то развалилось, то развалилась вся сеть Ethernet Тоже таких подлостей не ожидают Классический пример — это, например, HSRP Мы про него говорили немножко на CCNA: HSRP, VRRP, GLBP и прочее Протоколы, которые нужны для отказоустойчивости шлюза по умолчанию Которые работают с широковещательным доменом И которые не ожидают того, что он может у вас развалиться на две несвязанные части внезапно Они говорят, что если у нас есть сетка 192.168.1.0 внизу Где-то там, где юзеры сидят Не может такое произойти внезапно, что эта одна сетка превратится в две разные сетки 192.168.1.0, несвязанные между собой И соответственно, не может быть такого, что у нас один из узлов не видит другого в этой сети Если у вас появляется L2 VPN, то вы можете эту штуку вывести на новый уровень Принципиально недоступный для ситуации с коммутаторами Вы можете сделать эмуляцию междугороднего и даже международного толстого жёлтого коаксиала

Как вы понимаете, вероятность того, что в случае с междугородней и международной связью часть сети будет недоступна И она будет видна как-то иначе, не так, как должна быть Она практически равна единице Поэтому L2 VPN не надо использовать, если у вас есть такая возможность В некоторых ситуациях это неизбежное зло Например, если у вас есть дата-центры и вы хотите мигрировать машину В некоторых случаях вам нужно будет сохранить IP-шники у этих машин И если вы не используете всякие разные штуки типа EVPN или всего остального То вам придётся эмулировать, как будто между этими двумя точками будет физический провод и общий широковещательный домен Но если у вас есть возможность использовать L3 VPN А L3 VPN — это эмуляция маршрутизатора А маршрутизатор — это какая-то железка, которая хорошо перекладывает пакеты между разными физическими средами Которые ожидают, что некоторые физические среды могут отвалиться И тогда надо пойти в обход Чего Ethernet не ожидает Соответственно, если есть возможность использовать L3 VPN, лучше использовать L3 VPN

L3, или IP, скажем, в широком смысле этого слова Специальный протокол, который заточен под то, чтобы между разными точками присутствия Можно было пойти по разным маршрутам Что пакеты у нас будут перекладываться между отдельными интерфейсами, между отдельными проводами И что эти провода могут между собой как-то по-разному, по-хитрому соединяться Поэтому, если есть возможность, используйте L3 VPN В завершении разговора о канальных средах нужно, наверное, упомянуть ещё один вариант Это когда кое-кто кое-кого кое-как видит, но не все всех Например, Wi-Fi В Wi-Fi у нас может быть такое, что кое-кто кое-кого кое-как видит, но кое-кого также кое-как и не видит Типичный пример Есть абонент номер один Wi-Fi Есть абонент номер два Wi-Fi Есть абонент номер три Wi-Fi

Как мог, нарисовал Первый до второго дострелить может Второй до третьего дострелить может Между первым и третьим у нас кирпичная стена, железобетонная, которая не простреливается Соответственно, трафик от первого до третьего дойти не может Абоненты, которые собираются обмениваться трафиком между собой У них нет понимания, что трафик может пойти от одного до другого И от одного до третьего До кого-то одного дойдёт, до кого-то третьего не дойдёт У них есть просто антенка И в эту антенку они могут послать какой-то сигнал А то, что от этой антенки сигнал от одного до другого дойдёт А от одного до третьего не дойдёт Антенка уже про это ничего не знает Поэтому в Wi-Fi, в котором может быть такое, что кое-кто кое-кого не видит, приходится использовать костыли Самый первый костыль, который может предложить Wi-Fi, называется IBSS, Independent Basic Service Set, более известен как Ad hoc Если у вас есть несколько узлов, которые связаны между собой по Wi-Fi, вы говорите: если кто-то кого-то не видит, то это проблема того, кто не видит

Соответственно, просто работаем и всё. Пляшем, улыбаемся и машем, как в «Мадагаскаре» говорили Если, например, в чистом поле несколько человек собрались и захотели попередавать друг другу какие-то файлы, поиграть в Counter-Strike Они поднимают IBSS, поднимают Wi-Fi в режиме Ad hoc и просто передают трафик друг другу Если где-то кто-то до кого-то не дострелливает — значит, такова селяви, как говорят французы Для того чтобы работать в режиме, когда все друг другу передавать трафик могут, используется режим BSS, Basic Service Set Буковок меньше, но на самом деле это более продвинутый режим Здесь не хватает слова Independent Это не то, что каждый сам за себя Соответственно, у нас есть какая-то услуга, и мы за эту услугу отвечаем как администратор Мы ставим точку доступа, и эта точка доступа видит всех Мы договариваемся так, что эта точка доступа видит всех И если есть какой-то узел, который находится у нас в Wi-Fi-сети, то он обязательно до точки доступа может дострелить

Если есть кто-то, кто не может дострелить до точки доступа, то он не покрывается Wi-Fi Если кто-то может достучаться до точки доступа, он покрывается Wi-Fi Если вдруг между какими-то двумя участниками у нас есть кирпичная или железобетонная стена, которую они не могут пробить Это не проблема, потому что трафик между обычными абонентами напрямую не ходит Весь трафик Wi-Fi, который работает в режиме BSS, идёт только через точку доступа Если мы хотим отправить кадр от узла А до узла Б, мы его отправляем точке доступа, а уже точка доступа переотправляет его узлу Б Точку доступа всегда можно достать, и точка доступа всегда может достать до кого угодно Да, получается в этом случае, что времени, которое потребуется от узла А до узла Б доставить трафик, потребуется в два раза больше, чем в IBSS Но зато это гарантированно получится Есть ещё третий вариант, когда у нас точек доступа будет несколько Это ESS, Extended Service Set

На картинке тут как раз оно и нарисовано Когда есть точка доступа, вы посылаете кадр ей, она пересылает этот кадр дальше по Wi-Fi уже, по тому же самому каналу какой-то другой точке доступа И та уже отправляет его третьему Это режим ESS, и он наиболее продвинутый, наиболее сложный И он позволяет покрыть Wi-Fi достаточно большую площадь BSS — это одна точка доступа, ESS — это несколько точек доступа Если вдруг вы хотите с Wi-Fi работать, скорее всего, вы захотите работать в режиме BSS Одна точка доступа ставится, и дальше она обриджуется просто с проводной сетью И трафик направляется в проводную сеть А если вдруг где-то в другом здании, например, ещё надо будет поставить тоже Wi-Fi То там тоже будет просто провод И из этой точки доступа Wi-Fi будет распространяться уже дальше по остальным зданиям Такая штука

На всякий случай, вдруг вы любопытствуете, какие форматы кадра в Wi-Fi бывают Там их много В Ethernet формат кадра один, и он простой Во Frame Relay формат кадра один, и он простой, хотя там адресация ещё дурацкая В PPP формат кадра один, и он вообще примитивно простой А в 802.11 кадров много, и они разных форматов Они решают абсолютно разные задачи И это примерно как выглядит кадр в Wi-Fi Сначала идёт 2 байта управляющей информации для кадра, в которых много разных полей Потом идёт продолжительность передаваемых данных Потому что в Wi-Fi проблема ещё в том, что разные абоненты могут работать на разной скорости Поэтому мы не указываем размер передаваемых данных Мы указываем, в течение какого времени мы будем передавать эти данные Дальше идёт адресная информация Причём адресов в Wi-Fi аж 4 штуки в каждом кадре

A1, A2, A3 и A4 Каждый 6 байт, как MAC-адрес в Ethernet, но их там 4 штуки И после этого идут данные, которых может быть до 2 с лишним килобайт И после этого чек-сумма Так что если вы вдруг думали, что Wi-Fi очень похож на Ethernet Нет, очень не похож на Ethernet У него абсолютно всё другое: формат кадра другой, адресация другая И взять кадр Wi-Fi и переложить его в Ethernet, и наоборот, нельзя Но что можно сделать? Если у вас есть точка доступа, можно взять... Где он? Рисовалка Можно взять точку доступа, у которой есть антенка и есть физический провод И эта антенка У нас приходит какой-то кадр из Ethernet Обычный предсказуемый кадр из Ethernet Мы берём, отрезаем от него весь Ethernet-заголовок Сохраняя при этом MAC-адреса И передаём в Wi-Fi в виде кадра с новым заголовком Но в один из адресов A1, A2 и A3 Мы положим тот MAC-адрес, который нас интересует в качестве адреса получателя

И, возможно, MAC-адрес источника тоже пытаемся сохранить Просто кадр из Ethernet переложить в Wi-Fi нельзя Это будет просто невозможно, у них форматы разные Но можно взять мясо из кадра Ethernet И, сохранив адресную информацию в одном из адресов A1, A2, A3, A4 Передать кадр Wi-Fi, содержащий то же самое мясо На экзамене вопросов на это не будет Но вы просто должны понимать, что Wi-Fi немножко иначе устроен, чем Ethernet Что это отдельная канальная среда, которая живёт по совершенно своим отдельным законам Которые на Ethernet не похожи Даже по детализации, которая на этом слайде есть Что в Wi-Fi много всякого, но я вам про это не расскажу Вы уже понимаете, что это очень сильно опциональная информация Которую заучивать не обязательно Просто запомните, что там всё хитро и сложно Wi-Fi — боль Боль, боль, боль

Так, мы прошли всю теорию про канальные среды Нам нужно сейчас сделать лабочку Лаба будет посвящена DMVPN и PPPoE Так что давайте