А туда ли мы идём?

Просто представьте, во что мы себя уже втянули. Какова сложность архитектурной композиции из костылей, которую мы сооружаем?

Сначала мы ушли от технологий с коммутацией каналов к коммутации по ячейкам, чтобы более оптимально использовать полосу пропускания.
Потом оказалось, что строить заранее канал для ячеек тоже неудобно — негибко, ненадёжно.
Мы создали Ethernet, который в самом своём начале задумывался как протокол только для локальных сетей. Никому и в голову не могло прийти, что он может стать канальной технологией уровня города. Мы создали монстра, лишившего нас сна своими широковещательными штормами. При этом связка Ethernet+IP от рождения не предназначена для транспортировки старых протоколов, не может изолировать трафик разных клиентов друг от друга, даже элементарно управлять путём, которым пойдёт трафик мы не можем.
О, мой Лейбниц! А чего стоит рекурсивный поиск наиболее точного маршрута в таблице маршрутизации, отъедавший на заре IP драгоценные секунды процессорного времени? Пришлось выдумать MPLS, чтобы маршрутизаторы смотрели только на метку, что должно было происходить гораздо быстрее. В итоге мы опять вернулись к построению заранее определённых каналов, лишившись однако такой важной вещи, как гарантированное качество сервиса — то ли дойдёт пакет до получателя, то ли нет. Для этого были изобретены монструозные механизмы классификации трафика, токен-бакетов, аппаратных очередей QoS, управления перегрузками. А с появлением TCAM и FIB, быстрых процессоров и дешёвой памяти, чистый MPLS стал шпилем на уродливой башне из подпорок.


К слову, TCAM — самый дорогой и горячий компонент современного оборудования.

И что мы имеем в итоге? Канал без гарантированного качества, который строится как случай на душу положит, а под собой несёт все проблемы Ethernet.
И тут появляется MPLS Traffic Engineering. Который делает что? Правильно: IntServ QoS и возможность строить маршруты так, как этого хочет оператор, а не IGP. При этом вручную задаются узлы по пути, где можно строить туннель, где нельзя, требования по ширине, задержкам, вариациям.

И тут нужно задать себе и окружающим вопрос: а туда ли мы идём?


Классические технологии, такие, как E1 или SDH были прекрасны: у абонента всегда была гарантированная полоса, гарантированное качество канала, который если уж он занял, то никто не отнимет. Прекрасны во всём, кроме:
  • Полоса занята, даже если абоненты томно молчат в трубку, пытаясь придумать тему для разговора.
  • Количество абонентов, которые могут использовать линию строго ограничено, соответственно никакой переподписки и высочайшая цена.
  • Если вдруг кот погрыз радиоволну, то всё ваше телевидение испорчено. Не все технологии прошлого умели в резервирование. А те, что умели (тот же SDH восстанавливался за 50мс) стоили неприлично.

Вызов первых двух проблем приняло следующее поколение технологий — ATM. Была введена концепция ячеек. Стало лучше, стало легче — у клиентов по прежнему было гарантированное качество, но при этом их (клиентов) можно было подключить больше.
А вот с резервированием беда — АТМ по-прежнему был очень инертным и негибким, кроме экзотических реализаций IP over ATM.

А кроме того, появилась и новая идея — LAN — локальные компьютерные сети — все прежние технологии приходили в мир со стороны телефонных компаний и телефонных же стандартизирующих организаций. А там всё просто — инпут=оутпут, битрейт всегда плюс-минус одинаковый — чего хочет абонент, понятно.
LAN же ставил, можно сказать, противоположные задачи. АТМ потерпел сокрушительное поражение в схватке с Ethernet+IP.

Подход с коммутацией пакетов оказался очень гибким.
IP — обеспечил связность любых двух компьютеров в мире. А учитывая, что каждый маршрутизатор самостоятельно принимает решение, как поступить с каждым пакетом, резервирование стало очень простым и переключение в случае поломки происходило практически без перерыва сервиса.
Ethernet прекрасно справлялся с задачами локальной сети с минимальной настройкой — дошло до смешного — воткнул кабель в свитч — и всё работает. АТМ вместе с ISDN грустно утирают слезу.
Купить же себе бухту витухи, пару коммутаторов и собрать простую локалку мог позволить себе любой студент.

Да, пришлось пожертвовать гарантированным качеством сервиса. Однако Ethernet+IP, реализующий плавающий битрейт и открывающий широкие возможности для переподписки, оказался очень дешёвым по сравнению не только с ATM/E1, но и с SDH/SONET, поэтому вытеснил все другие технологии из локальных сетей, а сейчас вовсю и из магистральных вытесняет (прощай, SDH!).
А вопрос качества сервиса был адресован новаторскому механизму — PHB — DiffServ QoS, когда каждый маршрутизатор должен самостоятельно управлять трафиком. Концепция приоритезаци пакетов блестяще проявила себя, позволяя важному трафику выдать максимум ресурсов. В результате, по сравнению с моделью качества сервиса в старых технологиях Ethernet+IP оказался более или менее на уровне.

Но новые стандарты не заменяли старые — они использовались на новых сетях, а АТМы и SDH жили на старых. И долгое время они едва пересекались. У нас были отдельно сети для телефонии, отдельно для ШПД, отдельно для телевидения.

Единственная серьёзная проблема IP была в Control Plane'е — очень уж ресурсоёмкой процедурой был поиск нужной строчки в таблице маршрутизации. И этот вопрос был адресован молодой технологии MPLS, разработчики которой решили взять лучшее от ATM, избавиться к чертям от его канальной функции и внедрить её в связку Ethernet+IP, аккурат между ними. Да, странная вставка L2,5 между L2 и L3 выглядит неорганично, но кому какое дело до этой модели OSI (спросите об этом Иннокентия в чате linkmeup)?
Первоначально MPLS был призван упростить процедуру коммутации пакетов. То есть connectionless IP сначала находит все маршруты в сети, а поверх них натягиваются MPLS-туннели, которые с одной стороны являются каналами между двумя точками, но с другой автоматические и опираются на IP. В итоге MPLS-пакет приходил на MPLS-маршрутизатор, тот проверял его метку, менял её и отправлял дальше. В его таблицах было чёткое соответствие — пакет с такой меткой нужно отправить в такой-то интерфейс, а с меткой сделать то-то и то-то. Никаких многократных переглядывалок с таблицей маршрутизации.
Но в этом плане MPLS прискорбно опоздал — микроэлектроника тоже не топталась на месте и подставила ему подножку — появились TCAM, которые за фиксированное время возвращали нужный маршрут, появилась концепция FIB — когда все необходимые параметры для действий с IP-пакетами были в близком доступе — в том самом TCAM, выросли процессорные мощности, а гигабайты оперативки можно было купить вместе с луком на рынке.
И вот тут хотелось сесть и заплакать — всё зря. Мы создали 11-й стандарт вместо того, чтобы свести 10 предыдущих к одному.
И вдруг какая-то светлая голова обнаружила, что MPLS-инкапусляция скрывает для транзитных маршрутизаторов внутренности пакета. То есть происходит туннелирование, как, например, в GRE. А почему бы нам внутрь MPLS-пакета закинуть не IP, а какой-нибудь E1?
Ну в самом деле, технологиям PDHoverEthernet или PDHoverIP сто лет в обед — просто это было неудобно. А тут уже есть есть автоматически созданные туннели — нужно только направить в них E1.
Как словом, так и делом, AToM через сеть MPLS может передать любые существующие протоколы канального уровня. Это MPLS L2VPN.
Можно подключить пару клиентов по Ethernet и, изолировав их друг от друга MPLS-метками, обеспечить им виртуальную локальную сеть — это MPLS VPLS, MPLS VPWS, EVPN и другие.
А ещё можно всё тот же IP прятать, но разными MPLS-метками обозначать разных клиентов и предоставлять им IP-связность. Это MPLS L3VPN.

И это немного больше, чем просто дополнительные сервисы — это огромный скачок в направлении конвергентных сетей. Теперь MPLS-сеть провайдера может использоваться для предоставления услуг ШПД, телефонии, телевещания, L3VPN и L2VPN одновременно.
Это уже серьёзный удар по классическим телефонным компаниям, которым пришлось скинуть путы старых стандартов и свои сети тоже переводить на Ethernet+MPLS+IP. Не удалось им почивать на лаврах фиксированной телефонии вечно.

Следующее поколение конвергентных сетей — FMC — Fixed-Mobile Convergence. Одна и та же сеть теперь может использоваться для всего перечисленного выше плюс являться транспортной сетью для мобильной сети.
В самом деле — базовые станции LTE подключаются только по Ethernet, 3G — частично по Ethernet, частично по ATM, 2G могут быть Ethernet или E1. И для всего этого есть MPLS.
И концепция DiffServ вместе с приоритезацией пакетов в целом неплохо справляется с таким потоком данных. Например, служебные протоколы MPLS-сети имеют приоритет 6-7, данные 2G и IP-телефонии могут идти с приоритетом 5, 3G — 4, LTE — 3, real-time video — 3, сёрфинг — 2, FTP, почта — 1 а торренты — 0.
Вместо инсталляции из палок, скреплённых жвачкой, перед нами прекрасная пирамида, которая медленно эволюционировала долгие годы.

И вот он — Traffic Engineering — самое неоднозначное применение MPLS.

Сети Для Самых Маленьких. Микровыпуск №6. MPLS L3VPN и доступ в Интернет

Статья про L3VPN получилась большой — ни много ни мало 130 000 символов.
Учитывая, что и её ещё не все дочитали, эту часть про доступ в Интернет мы вынесли в отдельную публикацию.
Это особенно важно, потому что в рунете, да и вообще в интернетах, нет доступного разбора этой темы.
Вполне вероятно, что вы сейчас читаете эксклюзивный материал.

Итак, есть оператор связи, который предоставляет своему клиенту L3VPN. Ни с того ни с сего, с бухты да барахты понадобился ему ещё и Интернет.
Самое очевидное решение — прокинуть ещё один кабель — в одном VPN, в другом Интернет.
Допустим, это сложно. Тогда можно поднять сабинтерфейс и передавать фотки вконтактике в отдельном VLAN'е.
Допустим, там сложный арендованный канал, где можно прокинуть только 1 VLAN или оборудование клиента не умеет VLAN (стоит обычный компьютер), что тогда?

Об этом следующие 36 000 букв вашей жизни.

Содержание выпуска


Читать дальше →

Сети для самых маленьких. Часть одиннадцатая. MPLS L3VPN

Все выпуски


В прошлый раз мы не оставили камня на камне при разборе MPLS. И это, пожалуй, хорошо.

Но до сих пор только призрачно прорисовывается применение его в реальной жизни. И это плохо.

Этой статьёй начнём исправлять ситуацию. Вообще же читателя ждёт череда из трёх статей: L3VPN, L2VPN, Traffic Engineering, где мы постараемся в полной мере рассказать, для чего нужен MPLS на практике.


Итак, linkmeup — уже больше не аутсорсинг по поддержке хоть и крупной, но единственной компании, мы — провайдер. Можно даже сказать федеральный провайдер, потому что наша оптика ведёт во все концы страны. И наши многочисленные клиенты хотят уже не только высокоскоростной доступ в Интернет, они хотят VPN.
Сегодня разберёмся, что придётся сделать на нашей сети (на которой уже меж тем настроен MPLS), чтобы удовлетворить эти необузданные аппетиты.

SDSM11-L3VPN

Читать дальше →