В прошлый раз мы не оставили камня на камне при разборке MPLS. И это, наверное, хорошо.
Но его применение в реальной жизни пока намечено лишь смутно.
И это плохо.
Этой статьей мы начнем исправлять ситуацию.
В общем, читателя ждет серия из трех статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся полностью объяснить, зачем на практике нужен MPLS. Итак, linkmeup — это больше не аутсорсинг поддержки крупной, а единственной компании, мы — провайдер.
Можно даже сказать федеральный провайдер, ведь наша оптика доходит до всех уголков страны.
И нашим многочисленным клиентам больше не нужен только высокоскоростной доступ в Интернет, им нужен VPN. Сегодня мы разберемся, что нам придется сделать в нашей сети (на которой уже настроен MPLS), чтобы удовлетворить эти необузданные аппетиты.
Содержание номера
- VRF, VPN-экземпляр, экземпляр маршрутизации
- > > > ВРФ-Лайт
- МПЛС L3VPN
- > > > Плоскость данных или передача пользовательских данных
- > > > > > > Роль меток MPLS
- > > > > > > > > > Транспортная этикетка
- > > > > > > > > > Метка
- > > > Терминология
- > > > Плоскость управления или передача служебной (маршрутной) информации
- > > > > > > Протоколы маршрутизации
- > > > > > > > > > МБГП
- > > > > > > > > > > > > Отличитель маршрута
- > > > > > > > > > > > > Цель маршрута
- Упражняться
- > > > ВРФ-Лайт
- > > > МПЛС L3VPN
- > > > > > > Связь между VPN
- Трассировка в MPLS L3VPN
- Вопросы и ответы
- Полезные ссылки
В любом случае, чтобы соединить две точки в Интернете, нужны два публичных адреса — по одному с каждой стороны.
Что, если наши адреса частные (10/8, 172.16/20, 192.168/16)? Тогда они «надавят» с одной стороны, а затем «отсоединятся» с другой стороны.
А NAT – это вещь, я вам скажу, ох какая неприятная штука.
Вот почему существует VPN. Виртуальная частная сеть — это набор технологий и протоколов, которые позволяют вам подключаться к вашей частной сети через чью-либо сеть, в частности через Интернет. Например, томский филиал linkmeup можно подключить к головному офису в Москве с помощью VPN через Интернет, как мы это сделали в проблема с VPN .
То есть другие филиалы вы увидите через VPN так, как будто они находятся в соседней комнате и вы подключены к ним через кабель, свитч или роутер.
Соответственно, узлы могут общаться, используя свои частные адреса, а не публичные.
В этом случае ваши персональные данные с приватными адресами упаковываются в пакеты с публичными адресами и летят по Интернету как по туннелю.
Это называется клиент VPN , потому что клиент сам занимается его настройкой и поднятием.
Его единственным посредником является Интернет. Мы обсуждали это в 7-м выпуске, и в блоге linkmeup об этом есть огромная страница.
статья наш читатель - Вадим Семенов.
Другой возможный вариант — провайдер VPN .
В этом случае провайдер предоставляет клиенту несколько точек подключения и строит каналы между ними внутри своей сети.
В этом случае от клиента требуется только заплатить провайдеру за этот канал.
Поставщик VPN, в отличие от клиентского VPN, позволяет обеспечить определенное качество обслуживания.
Обычно при заключении договора подписывается Соглашение об уровне обслуживания , где указан уровень задержки, джиттера, процент потерь пакетов, максимальный период недоступности сервисов и т.д. И если с клиентским VPN вы можете только надеяться, что сейчас в Интернете все спокойно и ваши данные придут в полном порядке, то с провайдерским VPN вам есть у кого спросить.
На этот раз речь пойдет о провайдере VPN.
Мы поговорим о VPN уровня 3 — L3VPN, когда нам необходимо обеспечить маршрутизацию сетевого трафика.VRF, VPN-экземпляр, Маршрутизирующий экземпляр Когда дело доходит до VPN, возникает проблема изоляции трафика.L2VPN — тема следующего выпуска.
Никто другой его не должен получить, а ваши частные адреса не должны появляться там, где им не положено - то есть в Интернете, в сети нашего провайдера и в VPN других клиентов.
Когда вы настраиваете туннель GRE через Интернет (или OpenVPN, если хотите), ваши данные автоматически изолируются — никто не сможет увидеть ваши частные адреса в Интернете, и трафик не попадет в чужие руки (если только вы не поднимете вопрос о целенаправленной атаке).
То есть между двумя публичными адресами есть некий туннель, который никак не связан ни с вашим провайдером, ни с другими транзитными туннелями.
Две разные VPN — два совершенно разных туннеля — и через ваш туннель проходит только ваш трафик.
У VPN-провайдера вопрос совсем другой — одна и та же магистральная сеть должна передавать данные сотен клиентов.
Как мы можем быть здесь? Нет, конечно можно, и тут GRE, OpenVPN, L2TP и иже с ними, но тогда все, что будут делать инженеры по эксплуатации, это ставить туннели и перелопачивать миллионы строк конфигурации.
Но проблема глубже — вопрос организации такого универсального для всех канала вторичен: главное теперь — как изолировать двух клиентов, подключенных к одному роутеру? Если, например, оба используют сеть 10.0.0.0/8, как мы можем предотвратить маршрутизацию трафика между ними? Здесь мы подходим к понятию ВРФ - Экземпляр виртуальной маршрутизации и пересылки.
Терминология здесь не устоялась: в Cisco это VRF, в Huawei — VPN-instance, в Juniper — Routing Instance. Все имена имеют право на жизнь, но суть одна – виртуальный роутер.
Это что-то вроде виртуальной машины в каком-нибудь VirtualBox — на одном физическом сервере много виртуальных серверов, а здесь на одном физическом роутере много виртуальных роутеров.
Каждый такой виртуальный маршрутизатор по сути представляет собой отдельный VPN. Их таблицы маршрутизации, FIB, список интерфейсов и другие параметры не пересекаются — они строго индивидуальны и изолированы.
Они точно так же отделены от самого физического роутера.
Но, как и в случае с виртуальными серверами, связь между ними возможна.
VRF — он строго локальный для маршрутизатора — вне его VRF не существует. Соответственно, VRF на одном роутере никак не связан с VRF на другом.
Поскольку мы рассматриваем все примеры на оборудовании Cisco, то будем придерживаться их терминологии.
ВРФ Лайт
Так называется создание провайдерского VPN без MPLS. Например, вот как можно настроить VPN в пределах одного роутера:
Здесь у нас два клиента — TAR’s Robotics и C3PO Electronic. Интерфейсы FE0/0 и FE0/1 принадлежат VPN C3PO Electronic, интерфейсы FE1/0 и FE1/1 принадлежат VPN TAR's Robotics. Внутри одного VPN узлы общаются без проблем, но не друг с другом.
Вот как выглядят их таблицы маршрутизации на роутере провайдера: 
Электронные маршруты C3PO не будут включены в сети TARS Robotics, и наоборот.
Клиентские интерфейсы здесь привязаны к конкретному VRF.
Один интерфейс не может быть членом двух VRF одновременно или одновременно членом VRF и глобальной таблицы маршрутизации.
Используя VRF Lite, вы можете легко пересылать VPN между разными концами сети.
Для этого нужно настроить одинаковые VRF на всех промежуточных узлах и правильно привязать их к интерфейсам: 
То есть R1 и R2 будут взаимодействовать друг с другом через одну пару интерфейсов в глобальной таблице маршрутизации, через другую пару в Robotics VRF TARS и через третью в C3PO Electronic VRF. Конечно, это могут быть субинтерфейсы.
Аналогично между R2-R3. Таким образом, мы получаем две виртуальные сети, которые не пересекаются друг с другом.
Учитывая этот факт, каждой такой сети необходимо запустить собственный процесс IGP для обеспечения возможности подключения.
В этом случае будет один процесс для физического маршрутизатора, один для TARS' Robotics, один для C3PO Electric. Соответственно, сигнал о каждом из них будет передаваться отдельно от остальных через свои интерфейсы.
Если говорить о передаче данных, то пакет, поступающий от узла из сети TARS Robotics, сразу попадает в соответствующий VRF, поскольку входной интерфейс R1 является его членом.
Согласно FIB этого VRF, он направляется на R2 через выходной интерфейс.
На участке между R1 и R2 передаются самые обычные IP-пакеты, которые даже не подозревают, что принадлежат разным VPN. Единственная разница состоит в том, что они используют разные физические интерфейсы или содержат разные теги в заголовке 802.1q. R2 получает этот пакет через интерфейс, который также является членом Robotics VRF TARS. R2 подготавливает пакет в необходимом FIB и отправляет его дальше согласно IGP. И так до тех пор, пока пакет не будет выпущен на другом конце сети.
Как узел определяет, что полученный пакет принадлежит определенной VPN? Все очень просто: этот интерфейс привязан («привязан») к конкретному VRF. Как вы, наверное, уже заметили, на иллюстрации эти интерфейсы отмечены кольцами соответствующего цвета.
Давайте немного включим наше воображение: Если пакет проходит через серое кольцо, он переходит на серую сторону и становится серым.
Далее он будет сверен с серой таблицей маршрутизации.
Аналогичным образом, когда пакет проходит через золотое кольцо, он покрывается чистым золотом и сверяется с золотой таблицей маршрутизации.
Аналогично, выходные интерфейсы привязаны к VPN, и соответствующие таблицы маршрутизации знают, какие сети находятся за ними.
Имейте в виду, что все, что мы говорим о таблицах маршрутизации, применимо и к ФИБ — у каждого VPN есть свой FIB. Пакеты между маршрутизаторами не окрашенный .
Пакеты из разных VPN не смешиваются, поскольку они либо проходят через разные физические интерфейсы, либо по одному, но имеют разные теги VLAN (каждый VRF имеет свой собственный выходной подинтерфейс).
Это простой и прозрачный VPN — для клиента создана максимально приватная сеть.
Но этот способ удобен, если у вас 2-3 клиента и 2-3 роутера.
Он совершенно немасштабируем, поскольку одна новая VPN означает новый VRF на каждом узле, новые интерфейсы, новый пул IP-адресов каналов, новый процесс IGP/BGP. А если точек подключения не 2-3, а 10, да ещё и резервирование нужно, каково поднимать IGP с клиентом и обслуживать его маршруты на каждом его узле? И вот мы подходим к MPLS VPN. МПЛС L3VPN MPLS VPN позволяет избавиться от этих неприятных шагов: 1) Настройка VRF на каждом узле между точками подключения 2) Настройте отдельные интерфейсы для каждого VRF на каждом узле.
3) Настройте отдельные процессы IGP для каждого VRF на каждом узле.
4) Необходимость ведения таблицы маршрутизации для каждого VRF на каждом узле.
Как это возможно?
Давайте рассмотрим, что такое MPLS L3VPN на примере такой сети: 
Итак, это три филиала нашего клиента TARS' Robotics: головной офис в Москве и офисы в Новосибирске и Красноярске - очень удаленные, чтобы добраться до них по нашему оптоволокну.
И у нас там уже есть каналы.
Центральное облако — это мы — linkmeup — провайдер, предоставляющий услугу L3VPN. Вообще говоря, TARS Robotics, как заказчику, совершенно безразлично, как мы организуем L3VPN — даже если мы возим их посылки поездом, лишь бы Соглашение об уровне обслуживания были упакованы.
Но для целей этой статьи, конечно, MPLS работает внутри нашей сети.
Плоскость данных или передача пользовательских данных
Во-первых, следует сказать, что в MPLS VPN VRF создается только на тех маршрутизаторах, к которым подключены клиентские сети.В нашем примере это R1 и R3. Любым промежуточным узлам не нужно ничего знать о VPN. И между ними нужно как-то обеспечить изолированную передачу пакетов от разных VPN. Именно такой подход предлагает MPLS VPN: коммутация внутри магистральной сети осуществляется, как мы описали в разделе предыдущая статья , по одной метке MPLS, а принадлежность к конкретному VPN определяется другой — дополнительной меткой.
Более подробная информация: 1) Здесь клиент отправляет пакет из сети 172.16.0.0/24 в сеть 172.16.1.0/24. 2) Пока он движется внутри своей ветки (сети клиента), это самый обычный IP-пакет, в котором IP источника — 172.16.0.2, IP назначения — 172.16.1.2. 3) Филиальная сеть знает, что через сеть провайдера можно попасть на 172.16.1.0/24. До сих пор это самый распространенный пакет, поскольку соединение осуществляется по чистому IP с частными адресами.
4) Далее R1 (маршрутизатор провайдера) получает этот пакет, знает, что он принадлежит определенному VRF (интерфейс привязан к VRF TARS), проверяет таблицу маршрутизации этого VRF - в какую ветку отправить пакет - и инкапсулирует это в пакете MPLS. Метка MPLS на этом пакете означает, что он принадлежит определенной VPN. Это называется "Метка обслуживания" .
5) Далее наш роутер должен отправить пакет на R3 — за ним находится нужный клиентский офис.
Естественно, через MPLS. Для этого при выходе из R1 Транспортная этикетка MPLS .
То есть в этот момент на упаковке две отметки.
Пакет MPLS распространяется через облако точно так, как описано в разделе Основная проблема MPLS .
В частности, транспортная метка заменена на R2 – SWAP Label.
6) R3 в итоге получает пакет, отбрасывает его транспорт отметьте, и по услуга понимает, что он принадлежит компании VPN TARS' Robotics.
7) Он удаляет все заголовки MPLS и отправляет пакет на интерфейс в том виде, в котором он изначально пришел на R1.
Диаграмма железо-углерод показывает, как трансформируется пакет при перемещении от ПК1 к ПК2: 
Помните, чем хорош MPLS? Дело в том, что никого не волнует, что находится под этикеткой.
Поэтому внутри магистральной сети не имеет значения, какие адресные пространства есть у клиента, то есть какой IP-пакет скрыт под заголовком MPLS. Поскольку пакет коммутируется по меткам, а не маршрутизируется по IP-адресам, нет необходимости поддерживать таблицу маршрутизации VPN на промежуточных узлах.
То есть мы получаем такой удобный MPLS-туннель, который, как вы увидите далее, сигнализируется автоматически.
Итак, между R1 и R3 (то есть в облаке MPLS) никто понятия не имеет, что такое VPN — VPN-пакеты следуют по меткам до места назначения, и только ему приходится беспокоиться о том, что с ними делать дальше.
Это избавляет от необходимости поднимать VRF на каждом узле и соответственно вести таблицу маршрутизации, FIB, список интерфейсов и т.д. Учитывая, что весь дальнейший путь пакета определяется первым MPLS-маршрутизатором (R1), необходимости в индивидуальном протоколе маршрутизации в каждой VPN нет, хотя остается вопрос, как найти выходной маршрутизатор, на который мы ответим далее.
.
Чтобы лучше понять, как передается трафик, необходимо выяснить значение меток в пакете.
Роль меток MPLS
Если вернуться к исходной схеме с ВРФ-Лайт , то проблема в том, что серый цвет IP-пакета (индикатор принадлежности к TARS' Robotics VPN) существует только внутри узла; когда она передается другому, эта информация переносится в тегах VLAN. А если отказаться от субинтерфейсов на промежуточных узлах, начнется хаос.И делать это надо во благо всего хорошего.
Чтобы этого не произошло в сценарии MPLS, Ingress LSR присоединяет к пакету специальную метку MPLS — Услуга — она же идентификатор VPN. Выходной LSR (последний маршрутизатор — R3) использует эту метку, чтобы понять, что IP-пакет принадлежит Robotics VPN TARS, и просматривает соответствующий FIB. То есть это очень похоже на VLAN, с той разницей, что о нем должен заботиться только первый маршрутизатор.
Но по сервисной метке пакет не может коммутироваться по сети MPLS — если мы его где-то поменяем, то Egress LSR не сможет распознать, к какому VPN он принадлежит. Вот здесь-то и приходит на помощь стек меток, которого мы так старательно избегали в прошлом релизе.
Сервисный тег оказывается внутренним — первым в стеке, поверх него еще и транспортный тег вешается.
То есть пакет проходит по сети MPLS с двумя метками — верхней — транспортной и нижней — служебной).
Зачем вам две метки, почему нельзя обойтись одной сервисной меткой? Пусть, например, одна метка на Ingress LSR установлена одной VPN, а другая — другой.
Соответственно, дальше по пути они также переключались бы как обычно, и Egress LSR точно знал бы, на какой VRF нужно отправить пакет. Вообще говоря, можно было бы так сделать, и это бы работало, но тогда для каждого VPN в магистральной сети был бы отдельный LSP. А если, например, у вас связка из 20 VPN от R1 до R3, то вам придется создать 20 LSP. А это сложнее обслуживать, это перебор с метками, это лишняя нагрузка на транзитные ЛСР.
И, собственно говоря, именно от этого мы и пытаемся уйти отсюда.
Кроме того, разные префиксы одного и того же VPN могут иметь разные метки — это также значительно увеличивает количество LSP.
Насколько проще создать один LSP, который будет туннелировать все 20 VPN одновременно?
Транспортная этикетка
Итак, нам нужна транспортная этикетка.Она находится на вершине стека.
Он определяет LSP и изменяется на каждом узле.
Он добавляется (PUSH) входным LSR и удаляется (POP) выходным LSR (или предпоследним LSR в случае PHP ).
На всех промежуточных узлах он меняется от одного к другому (SWAP).
Протоколы LDP и RSVP-TE распределяют транспортные метки.
Об этом мы тоже очень хорошо говорили в прошлой статье и не будем сейчас на этом останавливаться.
В целом транспортная маркировка нас мало интересует, так как и так все понятно, за исключением одной детали – FEC. FEC здесь больше не является сетью назначения пакета (частным адресом клиента), а является адресом последнего LSR в сети MPLS, к которому подключен клиент. Это очень важно, поскольку LSP не знает обо всех видах VPN и, следовательно, ничего не знает об их частных маршрутах/префиксах.
Зато он хорошо знает адреса Loopback-интерфейсов всех LSR. Итак, BGP сообщит вам, к какому LSR подключен этот клиентский префикс — это и будет FEC для транспортной метки.
В нашем примере R1, исходя из адреса назначения клиентского пакета, должен понимать, что ему необходимо выбрать LSP, ведущий к R3. Мы вернемся к этому вопросу чуть позже.
Метка
Нижняя метка в стопке — это служебная метка.
Это уникальный идентификатор префикса в конкретной VPN. Он добавляется входным LSR и больше нигде не изменяется до тех пор, пока сам выходной LSR не удалит его.
ТЭК для Service Label — это префикс в VPN или, грубо говоря, подсеть назначения исходного пакета.
В приведенном ниже примере FEC — 192.168.1.0/24 для C3PO VRF и 172.16.1.0/24 для TARS VRF. То есть Ingress LSR должен знать, какая метка выделена этому VPN. Как это происходит – предмет наших дальнейших исследований.
Вот как выглядит весь процесс передачи пакетов в различных VPN: 
Обратите внимание, что метки обслуживания различаются для двух разных VPN — выходной маршрутизатор использует их, чтобы узнать, какому VRF передать пакет.
А транспортные в данном случае одинаковы для обоих VRF-пакетов, потому что они используют один и тот же LSP — R1R2R3.
Терминология
Прежде чем зайти слишком далеко, нам необходимо ввести некоторую терминологию.Когда речь заходит о MPLS VPN, появляется несколько новых терминов, которые, однако, вполне очевидны: CE — пограничный маршрутизатор клиента — пограничный маршрутизатор клиента, подключенный к сети провайдера.
PE — пограничный маршрутизатор провайдера — пограничный маршрутизатор провайдера.
Собственно, К? к этому и подключены.
VPN рождаются на PE, и на этом они заканчиваются.
Здесь расположены интерфейсы, связанные с VPN. Именно PE назначает и удаляет теги обслуживания.
Именно PE являются входным LSR и выходным LSR. PE должны знать таблицы маршрутизации каждой VPN, поскольку именно они принимают решение о том, куда отправлять пакет, как внутри сети провайдера, так и с точки зрения клиентских интерфейсов.
P — маршрутизатор провайдера — транзитный маршрутизатор, который не является точкой подключения — через него VPN-пакеты проходят без какой-либо дополнительной обработки, иными словами, они просто коммутируются с помощью транспортной метки.
Нет необходимости знать таблицы маршрутизации VPN или метки служб.
На P нет интерфейсов, завязанных на VPN. Фактически, роль P-PE специфична для VPN. Если в одном VPN R1 и R3 — PE, а R2 — P, то в другом они могут поменяться ролями.
Например, на схеме ниже роли синих маршрутизаторов различаются для зеленого клиента и фиолетового: 
Стек этикеток — набор заголовков MPLS, прикрепленных к одному пакету.
Каждый из них играет определенную роль.
В нашей реальности немногие поставщики поддерживают более шести меток в стеке.
Будет еще ряд терминов, но вводить их пока рано.
В общем, с тем, как передаются данные, то есть с тем, как работает Forwading Plane, мы закончили.
Подведем итоги: PE-маршрутизатор прикрепляет к клиентскому трафику две метки — внутреннюю служебную метку, которая не меняется до самого конца пути, и по ней последний PE понимает, какому VRF принадлежит пакет, и внешнюю транспортную метку, по которой пакет передается через сеть провайдера – эта метка меняется на каждом P-маршрутизаторе и удаляется на последнем PE или предпоследнем P. Благодаря наличию сервисной метки и VRF трафик разных VPN изолируется друг от друга как внутри роутеров, так и в каналах.
И действительно, теперь мы можем сформулировать ряд тревожных вопросов: 1) Как распределяются метки MPLS? 2) Как распределяется информация о маршрутизации для каждой VPN? 3) Каким образом маршруты разных VPN изолированы друг от друга и не смешаны? На эти и другие вопросы мы отвечаем ниже.
Плоскость управления или передача служебной (маршрутной) информации
Отвечая на них, поговорим о том, как подготавливается вся эта среда, в которой пакеты данных будут успешно проходить.
Протоколы маршрутизации
Итак, у нас есть два типа сетей и связей между ними:- Клиентская IP-сеть;
- Магистральная сеть провайдера с работающим на ней MPLS.
Не зря существует народная мудрость: Как ни настрой ЧП, оно всё равно смотрит на клиентов.
MPLS настраивается только на магистральных интерфейсах.
Напомню, что речь идет о L3VPN. И здесь нужно позаботиться об IP-связности.
А сейчас у нас много ограничений.
Давайте разберемся, какие протоколы в каких сферах нам пригодятся.
Во-первых , вам необходимо обеспечить базовое IP-подключение в магистральной сети провайдера.
Чтобы были известны все адреса Loopback, сети каналов, префиксы сервисов и, возможно, некоторые выходы наружу.
Для этого запускается IGP (ISIS, OSPF).
MPLS уже занимает лидирующие позиции в подключенных сетях.
Так мы обеспечили работоспособность магистральной сети .
Во-вторых , у клиента в филиалах может быть не один роутер, а несколько сетей.
Эти сети также должны быть проложены как минимум внутри себя.
Очевидно, что внутри своей сети клиент волен распределять информацию о маршрутизации по своему усмотрению.
Мы, как провайдер, не можем на это повлиять, и для нас это не имеет значения.
Это обеспечивает передачу маршрутов внутри клиентских сетей.
.
Третий , клиенту необходимо каким-то образом сообщить свои маршруты провайдеру.
На интерфейсе CE-PE клиенту и провайдеру уже необходимо договориться, какой протокол будет использоваться.
Хотя вряд ли у клиента есть свой самописный протокол IGP. Наверняка это OSPF/ISIS/RIP. Поэтому обычно провайдер идет навстречу и выбирает тот, который удобен клиенту.
Тут нужно понимать, что этот протокол взаимодействия с клиентом работает в VPN и никак не пересекается с IGP самого провайдера.
Это разные независимые процессы.
BGP часто работает на этом интерфейсе, поскольку позволяет гибко фильтровать префиксы по различным атрибутам.
Вот как провайдер получает клиентские маршруты .
До сих пор все было ясно.
Даже если ты так не думаешь.
Четвертый , и это самое интересное — остаётся только передать маршруты одной ветки в другую через магистральную сеть.
При этом их нельзя потерять в пути, не спутать с чужими и доставить в целости и сохранности.
Здесь нам поможет расширение протокола BGP — MBGP — многопротокольный BGP (Часто называемый MP-BGP).
Мы поговорим об этом сейчас.
Но сначала посмотрим, что и где работает: 
Возможно, пример из реальной жизни прояснит ситуацию.Допустим, вы живете в поселке Ола и решили отдохнуть в Шэньчжэне.
1) Самостоятельно, на машине или на такси вы доберетесь до автовокзала в поселке Ола (ИГП внутри сети).
2) Сядьте на автобус и он отвезет вас в Магадан (IGP/BGP с ISP).
3) В Магадане туроператор выдает вам паспорта, билеты и ваучер (бирка внутреннего обслуживания).
Теперь вы являетесь участником определенного рейса (VPN).
4) В аэропорту никого не волнует, в какой отель вы в итоге поедете - их задача доставить вас в Шэньчжэнь (BGP), а для этого им нужно посадить вас на нужный самолет согласно вашему ваучеру (назначить внешний транспорт label — PUSH Label — и отправит вас в правильный интерфейс) Итак, вы сели в самолет. Этот самолет является вашей внешней транспортной меткой, а ваучер — вашей сервисной меткой.
Самолет доставит вас до следующего перелета, а ваучер доставит вас в отель.
5) Самолет летит из Магадана в Шэньчжэнь не напрямую, а с пересадками.
Сначала вы вышли в Москве и сели на новый самолет, летящий в Пекин.
Затем в Пекине вы сели на самолет до Шэньчжэня.
(Так произошло переключение меток — SWAP Label).
При этом ваучер – сервисная бирка по-прежнему находится у вас в кармане.
6) В Шэньчжэне вы выходите из самолета (метка POP) и здесь проверят ваш ваучер - куда вас следует отвезти (в какой VPN).
7) Вас посадят в автобус до отеля (IGP/BGP с вашим провайдером).
8) Во дворе отеля вы самостоятельно попадаете в свой номер через ресепшен (IGP внутри сети).
Итак, аэропорт Магадана — это PE/Входной LSR, аэропорт Шэньчжэня — еще один PE/Выходной LSR, Московский аэропорт — P/Промежуточный LSR. Особенно интересно в этой фантазии будет смотреться PHP .
МБГП
Мы ответим сейчас Теги: #Сетевые технологии #Системное администрирование #mpls #bgp #l3vpn #сети для самых маленьких #сети для самых маленьких #vrf #linkmeup #MBGP-
Открытый Вебинар «Css-Препроцессоры»
19 Oct, 24 -
Обновление Для .Net 3.5 Sp1
19 Oct, 24
