Все посты про MPLS VPN можно посмотреть по тегу MPLS или в обобщающем посте.
Переоценка ценностей
Небольшое вступительное слово. Я вообще всегда считал себя (наверное, как и большинство) адептом Cisco. Я начинал знакомство с сетями с Cisco и их подход казался мне долгое время правильным и логичным. Потом я начал знакомиться с другими вендорами и тем, как они пытаются строить сети. Первый раз я понял, что конфигурить железо можно совершенно по-другому, когда довольно плотно начал работать с Extreme Networks. Мало того, что принцип конфигурирования девайса разительно отличался от любимой и уютной Cisco, так ещё и некоторые рекомендации по началу просто заставали врасплох. Cisco говорит, что везде надо включать STP, а у Extreme он выключен везде по-умолчанию. Настроить его в Cisco 5 минут и две строчки в конфиге, у Extreme - простыня команд. Есть отличный пост в ЖЖ, который иллюстрирует это. Зато включить какой-нибудь кольцевой протокол ERPS (EAPS) на Extreme проще простого. Сам подход Extreme сильно отличается от Cisco. Довольно интересные чувства, заменить старый шумный огромный Cisco 6509 на пару одноюнитовых Extreme с 48 10G портами и отсутствием переподписки вообще. Хотя для того чтобы перенести все вланы с 6509 на Extreme и назначить их на соответствующие порты, мне понадобилось сначала писать приблуду в Excel, а затем ещё и скрипт на Python. Стоит отметить, что эту приблуду можно запустить прям на свиче в который встроен интерпретатор Python. Про Extreme есть что расскзать, но как-нибудь в другой раз. |
| Google Drive Spreadsheet выручает... |
Самая последняя моя "переоценка ценностей" случилась после знакомства с Alcatel-Lucent Service Routing Portfolio (ALSRP). Я давно слышал, что у Алкателей "все не так" и что все в них делается через сервисы. Изначально мне такая мысль казалось сомнительной. Но сейчас, мне кажется, что это, вероятно, должно быть удобно. К сожалению, можно считать, что я практически не конфигурил Alcatel-Lucent железки. Мои знания сугубо теоретические. Основанные на книгах, мнениях коллег и на анализе конфигов. Надеюсь, я ещё поработаю с ними. Сейчас же я хотел лишь кратко законспектировать мои знания по данной тематике.
Сервисно-ориентированный подход
Тема сервисно-ориентированного подхода одновременно и сложна и проста. Её можно выразить в одном предложении. Все есть сервис. Когда вы предоставляете абоненту какой-либо сервис, в общем смысле, больше не нужно бегать по конфигу железки, менять настройки портов, тут подправить, там подправить. Вы настраиваете сервис, а в нем уже настраиваете какие порты в этом сервисе участвуют, какие политики на этот сервис вы хотите применить, какие ресурсы вы задействуете под него. В итоге, на железе вы видите лишь набор сервисов, которые используют ресурсы вашего железа (порты, вланы, pseudowire, метки, очереди, политики и прочее).Соответственно, вы должны иметь возможность настраивать все необходимые параметры более гранулярно что ли. Вы должны иметь возможность применить те же политики качества обслуживания на сервис, а не на порт или VLAN.
Более того, маршрутизатор в сервисно-ориентированной сети имеет на своем борту некую базу данных сервисов. В этой базе хранятся ассоциации сервисов и абонентов, опционально контактные данные абонентов. Контактные данные? На роуетере? В этой базе так же хранятся какие ресурсы используют сервисы и прочая информация.
Сервисно-ориентированный подход неразрывно связан с IP/MPLS. Более того, подход основан на IP/MPLS, это та база, которая позволяет добиться всех этих возможностей. Но именно сама технология IP/MPLS проста как тапок, меняй метки да и все. Намного интересней то, что придумали делать основываясь на тех возможностях, которые может дать IP/MPLS. Тут мы подошли к Pseudowire Emulation Edge to Edge.
Pseudowire Emulation Edge to Edge (PWE3)
В далеком, вроде как, 2001 году начала свою работу рабочая группа PWE3, которая выпустила уже много RFC по теме того, как все что угодно передать через IP/MPLS. Ethernet, Frame Relay, ATM, SDH/PDH, IP и т.д. Базовый из них, вроде как, RFC 3985. Во всяком случае, там много полезного. Так же PWE3 работают над составлением рекомендаций по построению архитектуры распределенных VPN. Все технологии основаны на pseudowire. вообще pseudowire это прям базис IP/MPLS VPN.Pseudowire - это "псевдо кабель", который прозрачно для абонента соединяет две его точки. Pseudowire проходит через все транспортную IP/MPLS сеть и передает трафик абонента "как есть". Принимая абонентский трафик (Ethernet, TDM, Frame-Relay...) с одной стороны, передавая его через всю IP/MPLS сеть основываясь на метках, и отдавая его с другого конца pseudowire без изменений другой точке присутствия абонента. Абоненту не нужно ничего знать про сеть провайдера и про то как он там организовал связь. В отличии от L3VPN, абоненту не нужно настраивать протокол маршрутизации с провайдером. Абонент просто подключается к провайдеру нативной технологией и уже сам организует логику работы своей сети. Сеть может быть распределенной, то есть для абонента сеть провайдера выглядит как один большой коммутатор (в случае Ethernet). Более того, этот большой коммутатор даже может участвовать в STP, к примеру.
Обратимся к схемке, которая вводит другие базовые понятия.
Абонентский CE1 девайс (Customer Edge) подключается через Attachment Circuit (AC) к PE1 девайсу (Provider Edge). AC в данном случае символизирует ту технологию, какую хочет передать абонент через сеть провайдера (ATM, например). PE1 сигнализирует pseudowire через провайдерскую сеть, проходя P девайсы (Provider). PE2 является выходным устройством из pseudowire. Его задача, передать трафик из него в нативном формате (ATM, в нашем случае) к клиенту на его девайс CE2.
На схеме так же есть и другие важные сущности.
PSN tunnel (Packet Switched Network tunnel) - это туннель по которому передается трафик другого туннеля (Pseudowire). То есть PE1 сигнализирует с PE2 pseudowire-туннель и они выделяют для него метки. Но для того чтобы доставить до PE2 трафик, PE1 должен передать его через огроменную сеть провайдера. Внутри сети провайдера строиться другой туннель, как правило тоже MPLS, этот туннель и называется PSN. К слову, pseudowire обычно сигнализируется средствами T-LDP, а PSN можно организовать разными способами (LDP, RSVP-TE, LDPoRSVP и даже GRE).
Emulated Service - это сервис, который прозрачно эмулирует провайдер от одного абонентского девайса до другого.
Сервисно-ориентированный подход + PWE3 в понимании Alcatel-Lucent
Alcatel-Lucent взял все это, добавил нового и хорошенько перемешал. В итоге мы имеем PWE3 концепцию в имплементации вендора. Внесено довольно много новых понятий, самые важные из которых:Service Instance - это тот самый сервис, который имеет уникальный ID, проассоциирован с кастомером и имеет в себе все настройки, которые к сервису относятся (как минимум SAP и Pseudowire)
Service Access Point (SAP) - это логическая сущность, которая обозначает точку соединения с абонентом.
Service Distribution Path (SDP) - PSN в понимании PWE3. Это однонаправленный транспортный туннель соединяющий PE устройства по которому бегает трафик pseudowire.
Нюансов тут много, на самом деле. Вот пара из них.
Pseudowire - двунаправленный туннель. Он строиться поверх SDP, который однонаправленный. Соответственно, один pseudowire использует минимум два SDP (туда и обратно).
Один SDP могут использовать много psudowire. Это всего лишь путь, по которому можно достичь устройство. Если трафику нужно будет попасть на это устройство, то он будет передан по этому SDP.
Ну на этом пока все, я думаю. Хотел так же написать о множестве ID, которыми оперирует Alcatel-Lucent (service-id, sap-id, encapsuation-id...), но не буду. Пост не об этом все же. С этим я должен буду столкнуться когда (или если) дойду до лабы.
Спасибо за внимание.
Комментариев нет:
Отправить комментарий