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

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

Сначала мы ушли от технологий с коммутацией каналов к коммутации по ячейкам, чтобы более оптимально использовать полосу пропускания.
Потом оказалось, что строить заранее канал для ячеек тоже неудобно — негибко, ненадёжно.
Мы создали 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.

Каверзные сетевые вопросы

Давно была идея собрать воедино интересные вопросы, касающиеся сетей.

Объединяет их то, что все они довольно простые, но мы подчас о них не задумываемся (я во всяком случае о них не задумывался).
В общем я их собрал, подбил, нашёл ответы.
Итак, блиц опрос:

Начнём с самых низких уровней и с самых простых вопросов



В1. Почему для витой пары выбран такой странный порядок: синяя пара на 4-5, разрывая зелёную, которая на 3, 6?



О1: Сделано это в угоду двухконтактному телефонному разъёму. Таким образом, например, в патч-панель можно вставить как телефонный кабель, так и витую пару.
Можно даже через один кабель вывести и сеть и телефонию, но я вам этого не говорил!

habrahabr.ru/post/158177/.


В2. В стандарте Ethernet между кадрами всегда имеется промежуток, называемый IFG (Inter Frame Gap) длиною 12 байтов. Для чего он нужен, и почему он присутствует в современных стандартах?

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

100 метров Ethernet

Статья опубликована на nag.ru.
=========

При подготовке к статье с каверзными вопросами я наткнулся на интересный вопрос — откуда взялось ограничение в 100 метров на длину Ethernet-сегмента.

Мне пришлось погрузиться глубоко в физику и логику процессов, чтобы приблизиться к пониманию.

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

CSMA/CD


Причина кроется в технологии CSMA/CD — Carrier Sense Multiple Access with Collision Detection. Если вдруг кто-то не знает, то это когда у нас одна шина (одна среда передачи данных), к которой подключено несколько станций (Multiple Access). Каждая станция следит за состоянием шины — есть ли в ней сигнал от другой станции (Carrier Sense). Если вдруг два устройства начали передавать в один момент, то оба они должны это обнаружить (Collision Detection).

Да, всё это касается полудуплексных сетей. Поэтому если у вас взгляд устремлён исключительно в светлое 10гигабитное будущее, эта статья не для вас.

В первую очередь, я хочу, чтобы все понимали, что скорость передачи сигнала в среде никоим образом не зависит от применяемого стандарта. Хоть в Ethernet (10Мб/с), хоть в 10Gbit Ethernet скорость распространения импульса в медном кабеле — примерно 2/3 скорости света. Как здорово написали в одном холиварном треде: вы можете говорить быстро или медленно, но скорость звука от этого не меняется.

Теперь обратимся к сути CSMA/CD. В современных сетях коллизии исключены, потому что у нас уже нет общей шины и практически всегда все устройства работают в полнодуплексном режиме. То есть у нас всего лишь два узла на конце одного кабеля и отдельные пары для приёма и передачи. Поэтому механизма CSMA/CD уже нет в 10Gbit Ethernet. Однако рассмотреть его будет полезно, так же, как например, изучать RIP, который, вроде, никому уже и не нужен, но прекрасно иллюстрирует принцип работы дистанционно-векторных протоколов маршрутизации.


Читать дальше →
  • 2
  • +1
  • 9640

LinkMeUp. Выпуск № 2

Здравствуйте, коллеги.
В новом выпуске обсуждаем

1) SDH/PDH (Synchronous Digital Hierarchy/Plesiochronous Digital Hierarchy)
2) Системы спектрального уплотнения каналов в оптических сетях
3) Технологии резервирования в сети Ethernet. Альтернативы STP — ERPS, RRPP.


Подкаст:

Скачать файл подкаста.




Добавить RSS в подкаст-плеер.


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