СПД

[[Image:]]spd1

Описание документа

ООО «Новотелеком»

Статус документа: служебная документация

Версия документа: V18 от 20121227

Дата редакции: декабрь 2012 года

Автор: Осипов Тимофей Борисович

Границы документа:

Содержит вводную информацию для сотрудников специалистов УПА по устройству СПД ООО «Новотелеком» и оказываемых на базе сети услуг абонентам компании.

Документ подготовлен на базе стенограммы лекции для сотрудников управления поддержки абонентов. Учитывая, что предполагается использование документа для лекций, стиль документа близок к разговорному.

Предполагается, что читатель является как минимум продвинутым пользователем Интернета, а таже предварительно ознакомился с базовой внутренней документацией компании по СПД, такой как: "термины и определения", "правила наименования агрегатов и узлов СПД".

Документ содержит описание оказываемых услуг. Для каждой услуги описаны:

• способы резервирования
• пути прохождение трафика через узлы СПД
• на каком уровне СПД что происходит с трафиком услуги
• какими сетевыми протоколами обрабатывается услуга
• какие накладываются ограничения, начиная от абонента и заканчивая источником услуги,
• методы диагностики типовых проблем.

В текущую редакцию не вошло освещение следующих вопросов:

• Устройство проекта wifi "территория электронного города"
• Подключение абонента конвертором
• Подключение абонента в частном секторе
• Новая схема оказания услуг voip, l2vpn, l3vpn
• Неисправности в работе различных услуг, вызванные ошибками коммутации: коммутация порт в порт, портов двух коммутаторов в одном элементе, одном влане, тоже разных вланов, тоже разных элементов
• аренда подсети (варианты серый IP уникальная подсеть, уникальный IP серая подсеть)

• Нюансы MPLS/VPLS маршрутизации
• Варианты услуг за портом и их дальнейшее развитие
• Развитие системы мониторинга абонентского трафика, любой влан с A2
• Элемент А4 типа "вектор"
• Соблюдение уникальности МАС в пределах пары узлов А3
• Кольцо за портом абонента
• Зависимости устройств и сущностей СПД по БД сеть, связи между ними, конфигурирование оборудования на базе связей

• Статус узла SVIP/VIP. Правила простановки статуса, обработки заявок и связанные проблемы.

• Проблемы с hash на оборудование A4, их диагностика и решение
• Карантин узла А4 и его влияние на абонентские подключения
• Алгоритм работы службы «Портчекер»

• Детальная информация про оборудование уровня А5 (роутеры, рекомендованные модели)

Организация сети данных на низком уровне (протоколы, пакеты)

Модель сетевого взаимодействия

[[Image:]]

В интернетах есть вот такие разные красивые картинки по графическому представлению уровней сети, так называемая модель OSI.

Наиболее устоявшаяся модель – семиуровневая

• первый уровень – физическое формирование сигнала;
• второй – одноранговое взаимодействие;
• третий – сетевое взаимодействие;
• четвертый – транспортный уровень;
• пятый – сессионный уровень и т.п.

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

Я буду рассказывать в лекции про 2й и 3й уровни семиуровневой модели и немного про 4й уровень.

Для понимания того, как обрабатываются пакеты на разных уровнях сети надо понимать, что такое Ethernet.

Ethernet и мак-адреса – как это работает.

Вся сеть построена по технологии Ethernet

Ethernet - это пакетная передача данных.

В нашей сети любое оборудовние работает исключительно с пакетами.

Вот самое примитивное представление сетевого пакета, именно так «видит» пакет простой коммутатор.

[[Image:]]

Коммутатор принимает решение о том, что делать с пакетом, на основании вот этих двух полей -

мак-адрес (mac-adress) назначения (D-MAC) и мак-адрес (mac-adress) источника (S-MAC). Размер мак-адреса в пакете - 12 байт.

Все достаточно просто.

Давайте всем устройствам в сети присвоим уникальные мак –адреса, построим большую сеть и будем работать. 6 байт мак адреса это 48 бит - 280 триллионов вариантов. Кажется, этого более чем достаточно, чтобы построить глобальную сеть. И действительно, первые сети в своей работе использовали только мак-адреса.

На самом деле, в мак-адресе первые 3 байта зарезервированы под производителя оборудования, ведь первые спецификации формата ethernet создавались тогда, когда еще интернета в существующем виде не было в планах. И сеть по такому принципу будет работать (до каких-то пределов). А оставшихся трех байт не хватит для глобальной адресации. Плюс часть мак-адресов зарезервирована под протоколы второго уровня. Для построения большой сети этого недостаточно, в частности, из-за особенностей технологии broadcast.

Ограничения сети, построенной на мак-адресах (ограничения broadcast’a).

Broadcast-пакеты - это пакеты, в которых в мак-адресе назначения все байты имеют значение «255». Коммутатор обрабатывает пакеты на основе мак-адресов, так что такой пакет коммутатор отправит всем своим абонентам. Здесь мы получаем такое понятие как broadcast–домен - Зона коммутации в пределах которой распространяются broadcast пакеты.

Broadcast–домен’ом могут быть как несколько коммутаторов, соединенных между собой, так и один большой коммутатор. Если устройств в такой сети подключено много, то каждое устройство генерирует широковещательные пакеты, в результате в домене будет генерироваться шум, ухудшающий качество связи.

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

Поэтому рекомендовано ограничивать размер broadcast-домена. Опытным путем установлено оптимальный размер:

255 устройств - это подсеть /24, т.е. 250 устройств в broadcast домене,

больше лучше не делать потому что будет много шума и больший широковещательный домен не будет работать.

И именно поэтому, используя только мак-адреса, нельзя построить большую сеть.

И поэтому такие broadcast домены нужно как то разделять между собой.

Отсюда возникает задача: как будут общаться между собой два сетевых устройства из разных broadcast-доменов?

Рассмотрим следующую иллюстрацию:

[[Image:]]

Вот здесь, в полезной нагрузке пакета, добавляется еще один заголовок протокола IP.

Это как раз протоколы, путем которых обеспечивается связность между broadcast-сегментами. Т.е. есть два сегмента, внутри каждого для обмена пакетами достаточно мак-адресов, а для связи между ними нужен маршрутизатор, подключенный разными интерфейсами к обоим сегментам.

Внутри каждого broadcast-домена пакеты обрабатываются на основании мак-адресов,

а между ними они обрабатываются маршрутизируются на основе данных заголовка.

IP-протоколов семейства IP было разработано много, но выжил в итоге только один.

Самое большое распространение получил протокол IPv4

Протокол IP позволяет однозначно идентифицировать компьютер в пределах нескольких broadcast доменов. В принципе, этим уже решена проблема броадкастных доменов, и у нас в распоряжении есть 2^32 уникальных IP адресов, казалось бы можно строить большую сеть.

В старые времена, когда компьютеры были, условно говоря, однозадачными, этого было достаточно. Но на компьютере сейчас работает несколько приложений, каждому из них требуется работать в сети, взаимодействовать с другими приложениями на других машинах. Как следствие, возникает потребность раздельно идентифицировать приложения.

[[Image:]]

Эту задачу решает протокол следующего уровня.

От broadcast к TCP/IP

Как мы видим, заголовок пакета инкапсулирован аналогично и идет сразу после предыдущего заголовка. Это протокол TCP

Тут уже появляются порты и появляется возможность однозначно идентифицироавть в глобальной сети и компьютеры и приложения на них.

Связка ipv4 & tcp называется TCP/IP и именно на этих двух протоколах построен весь Интернет.

Внутри broadcast-домена оборудование принимает решение об обработке пакета, ориентируясь на мак-адрес, там достаточно использовать коммутаторы. А если пакет предназначен за пределы сегмента то начинает работать маршрутизация,и здесь уже нужен маршрутизатор.

Но возникает другая проблема!

TCP/IP начал использоваться для глобальной маршрутизации и адресации больше 15ти лет назад. Двигателем технологий можно считать большие компании и корпорации с большой внутренней инфраструктурой. Допустим, что некой компании надо построить защищенную корпоративную сеть, в которой требуется разграничение доступа для разных групп сотрудников, при этом все они должны выходить в интернет и во внутреннюю сеть, а также иметь отдельные сервера. Причем все построено на одной инфраструктуре, есть одна физическая сеть (интранет).

И проблема такова: как разделить трафик ?

Строить отдельную физическую инфраструктуру для обеспечения изолированной внутренней сети дорого. Использовать везде вместо коммутаторов маршрутизаторы тоже дорого.

От TCP/IP к VLAN

Для решения проблемы разделения трафика были придуманы ВЛАН’ы.

Аббревиатура VLAN расшифровывается как «Virtual Local Area Network» (виртуальная локальная сеть).

Грубо говоря суть технологии ВЛАН - как сделать из одного коммутатора несколько виртуальных,

чтобы трафик между ними никак не пересекался. Было много различных реализаций, на базе портов, на базе мак-адресов, но самое большое распространение получил vlan на базе меток.

Пакет при этом принимает вот такой вид:

[[Image:]]

В пакет добавляется еще одна метка и коммутатор начинает принимать решение что делать с пакетом, основываясь не только на мак-адресах, но и еще на метке vlanID.

Как это работает:

• для каждого влана внутри коммутатора работает отдельная матрица коммутации
• коммутатор отправляет пакет в ту или иную матрицу коммутации основываясь на метке vlanID в заголовке пакета
• пакет попав в один виртуальный свитч никогда не попадет в другой в пределах этого коммутатора
• между двумя вланами трафик внутри одного коммутатора пересечься никак не может
• мы берем одну физическую железку и делаем 10(до 4095) виртуальных сетей
• не нужно строить отдельную физическую инфраструктуру
• используется при этом также протокол второго уровня

Все это очень хорошо красиво и интересно реализовано, есть вланы для реализации разграниченных сегментов, есть маршрутизаторы, которые перекидывают пакеты между ними и друг другом, теперь можно построить Интернет.

И Интернет построили.

Но по мере роста сети (и главное – роста трафика) возникла другая проблема – перегрузка маршрутизаторов, как следствие, рост задержек/потерь трафика..

Ведь каждый маршрутизатор для того, чтобы обработать пакет должен:

• разобрать пакет по заголовкам,
• удостовериться что пакет пришел с меткой влана, предназначенной конкректному интерфейсу
• убедиться что мак назначения это его интерфейс
• сверить с arp таблицей мак-адрес отправителя
• прочитать IP заголовок и определить, кто отправитель, кто получатель
• принять решение что делать с этим пакетом на основе таблицы маршрутизации
• и после этого собрать пакет в обратном порядке чтобы отправить с другого интерфейса

• все эти заголовки которые надо обработать занимают в пакете до 38 байт

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

MPLS – хит сезона

Дешевым и быстрым решением стал протокол MPLS - multiprotocol label switching

[[Image:]]

MPLS-связи между маршрутизаторами точка:точка, так что мак-дреса в этих выделенных каналах анализировать не требуется. Основной плюс в том, что технология позволяет не анализировать и все другие метки в пакете.

Решение «что делать с пакетом?» маршрутизатор принимает на основе одной единственной метки, а она в себе агрегирует всю необходимую информацию и занимает от 3х до 8ми байт, отсюда выигрыш в производительности.

Вот как распределяются метки по уровням:

[[Image:]]

MPLS находится где-то посередине между 2 и 3 уровнями.

Тут дело в том, что протокол придумали намного позже стандартной семиуровневой модели.

[[Image:]]

На картинке найденная на просторах интернета показана сеть. Все узлы здесь на схеме - это MPLS маршрутизаторы. Все связи точка-точка. Как видим топология не полносвязная. Куда ни ткни - выход из строя любого узла или связи не влияет на работоспособность оставшейся сети.

Пакет данных на разных уровнях СПД

Абонентский уровень:

[[Image:]]

Большинство абонентов ничего не знают про вланы. Трафик до абонента спускается не тегированный. Тэг присваивается непосредственно на оборудовании доступа (в новотелекоме это типовое подключение даты исключение телефония и аренда канала, об этом будет дальше). Большинство софта по умолчанию с вланами работать не умеет.

На уровнях A3-A4 все пакеты идут в тегированном виде:

[[Image:]]

Трафик между разными сегментами изолирован и не пересекается.

Основная задача уровня A3-A4 – это доставить пакет вот в таком виде до уровня A2.

[[Image:]]

Доходя до уровня A2, пакет дальше попадает в ядро сети.

На оборудовании A2 интерфейсы в сторону А3 - обычные вланы L2, интерфейсы вверх – MPLS.

На уровне А2 пакету присваивается соответствующая MPLS метка. И на уровнях A2-A1-A0 он пакет обрабатывается уже на основании метки MPLS.

Частный случай это VPLS (Virtual Private LAN Service), в котором не содержится маршрутизирующей информации.

Но особенности MPLS-маршрутизации выходят за рамки данного документа.

[[Image:]]

На границе сети у пакета может быть MPLS-метка, может быть вланы, может обычные соединения. Зависит от того какие условия подключения согласованы с присоединяемыми поставщиками услуг. Оборудование позволяет прописать требуемый для услуги признак.

Краткий словарь

Во всей документации и системах управления сетью присутствует базовое понятие - сегмент

сегмент

• это один broadcast домен
• один vlan, внутри которого используется определенный его тэг и определенная маска IP адресов закрепленная за ним
• один виртуальный коммутатор в котором у всех абонентов определенные IP адреса из одного диапазона

Сегменты (в том числе и для услуги дата, телефонии, аренды канала и управления оборудованием) группируются в элемент СПД.

Элемент - структурная единица построения и управления сетью..

Элемент это просто набор сегментов.

Конфигурирование всех услуг и оборудования базируется именно на элементах.

В зависимости от того, какой элемент обслуживает оборудование, так оно и будет сконфигурировано, будут выделены соответствующие IP для различных услуг абонентам закрепленным за этим оборудованием.

Элементы группируются в микросети.

В управлении сетью «Новотелекома» микросети не используется.

Главное - понимание того, что практически всё оборудование и услуги конфигурируются на основании данных этой БД.

Строение сети Новотелекома

Схема СПД. Уровни А0-А1-А2-А3-А4 .

[[Image:]]

Что мы видим на картинке?

Начнем сверху:

На самом верху у нас то, что находится за пределами нашей сети: источники доступа к интернет, пиринг-партнеры, головная станция телефонии, головная станция ТВ, другие операторы связи (в т.ч. телефонной). Портал cn.ru и «Пирс» - тоже подключены отдельно как пиринг-партнеры.

Это - внешние поставщики услуг.

Все поставщики услуг подключаются в уровень A0. Уровень A0 - это граница сети,

Ниже уровня А0 располагается уровень А1.

A1 - транспортный уровень ядра сети.

Основная задача этого уровня - высокоскоростной транзит трафика внутри СПД компании между уровнями A0 и A2 .

Весь трафик на входе, на выходе и внутри ядра сети обрабатывается по технологии MPLS.

Уровень A2 - это граница между MPLS ядром сети и уровнем агрегации.

Если все пакеты в ядре сети обрабатываются при помощи MPLS, то на нижних уровнях трафик обрабатывается протоколами второго уровня. Узел А2 имеет с одной стороны обычные интерфейсы во вланах, те самые сегменты, а в сторону ядра настроены MPLS-связи.

Уровень A3 (он же уровень агрегации).

Основная задача этого уровня - агрегация множества линков со стороны узлов A4. Со всех связей все вланы(сегменты) собирает в кучу и отправляет на A2.

Также уровень A3 обеспечивает резервирование связей A4.

Уровень частично задействован в функционале мониторинга передачи данных и ограничении нежелательного трафика с нижнего уровня.

Подробнее в описании каждой услуги.

Уровень A4

Это уровень абонентского доступа, куда непосредственно подключаются абоненты.

На этом же уровне обеспечивается базовый контроль доступа к услугам СПД.

• Для даты это будет связка МАК IP ПОРТ ВЛАН.
• для IPTV это управление профилями подписок на абонентских портах
• для аренды канала - ограничение полосы пропускания

Вкратце про резервирование и вытекающую топологию:

На уровнях A0, A1 обеспечивается резервирование N+1. Сейчас в сети два узла A0 и два узла A1.

Также выдвинуто требование распределения по территории в целях большей надежности - узлы дублирующие функционал должны располагаться на разных физических площадках.

ООО «Новотелеком» имеет два датацентра, на каждой площадке стоит узел A0 и A1.

Это обеспечивает минимальную конфигурацию в два узла исходя из требований N+1.

Когда в сети не хватает пропускной емкости, то проблема решается так:

• расширением возможностей существующего оборудования интерфейсными картами
• досустановка еще узлов на нужный уровень и перераспределение связей между узлами.

На уровне A0-A1 топология не обязательно должна быть полносвязная.

• Для A0 требуется соединение каждого узла минимум с двумя узлами своего уровня.
• Для A1 главное требование - чтобы каждый узел соединялся минимум с двумя узлами A0 и двумя узлами A1.

Более интересно обстоят дела на уровне A2.

• для уровня A2 обеспечивается резервирование N+1
• каждый A2 должен быть подключен как минимум к двум A1
• причем эти узлы должны быть расположены физически на разных площадках

То же требование к узлам A3

• узлы A3 работают парами
• парные узлы A3 не могут располагаться на одной площадке
• каждый узел в паре должен подключаться к двум разным узлам A2 расположенным на разных площадках
• таким образом для узлов A3 обеспечивается резервирование 2N

Пример реальной топологии: вот эти узлы A3 A2 A1 и A0 (выделены зеленым) могут быть на одной площадке

но тогда вот эти (выделены красным) должны быть на другой.

[[Image:]]

На уровне A4 обеспечивается резервирование только канального уровня. Звено коммутаторов должно быть подключено к двум разным узлам A3

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

Связи звена коммутаторов до A3 не должны проходить в одном физическом кабеле.

Уровень А3 подробно.

Вот два узла A3 (см ниже). Показаны связь между ними, связи от каждого наверх до A2,

два звена коммутаторов.

Устройство СПД в пределах пары узлов А3

[[Image:]]

Пара узлов А3 - это единица построения СПД, та часть сети которую можно легко клонировать.

Резервирование канального уровня в пределах пары узлов А3 обеспечивается протоколом STP. Протокол работает на связах между всеми узлами А4 и А3 и не работает на связях А3-А2.

Возвращаясь к управлению сетью, каждое звено коммутаторов в идеале принадлежит одному элементу СПД. В этом элементе 16 сегментов для разных услуг Вланы этих элементов у нас есть на всех коммутаторах, принадлежащих элементу и обслуживающих его.

На другой группе коммутаторов у нас будет другой набор сегментов. А раз это другой элемент, то, соответственно, вланы этих двух элементов будут на обоих узлах A3.

Между двумя узлами A3 у нас может быть до 16ти элементов спд.

Это ограничение связано с тем что используемое оборудование поддерживает 16 MSTP деревьев, при этом один элемент может состоять из нескольких звеньев.

При использовании другого оборудование в роли А3 ограничение может быть расширено

Вот так выглядят все физические связи на уровне А3:

[[Image:]]

А вот так может выглядеть логическая топология сети,

[[Image:]]

после того. как отработает протокол STP.

Основная задача протокола STP - не допустить возникновения кольца в broadcast-сегменте, при этом обеспечив резервирование.

На альтернативных связях между коммутаторами не передается никаких пакетов данных, кроме служебных пакетов протокола STP.

От А3 к А4

Распределение элементов на уровне А3. Переход к детальному рассмотрению на уровне А4:

[[Image:]]

В идеале, каждое звено A4, это отдельный элемент. Это правило выполняется при новом строительстве с 2010 года. А старая сеть к этому виду приводится и сейчас.

На картинке подписаны элементы и какие группы вланов в него входят.

Элемент (А4) обозначается пятисимвольным числовым значением, где

• первые два - номер микросети
• последние три - номер элемента в микросети

[[Image:]]

Есть еще такое понятие как нулевой элемент

Номер этого элемента имеет шестизначное значение, где

• первые два - номер микросети
• следующие три - номер наносети и последний ноль
• этому элементу принадлежат все узлы пары A3

Понятие нулевой элемент введено для обеспечения совместимости и работоспособности систем управления СПД на время перехода от СПД1 к СПД2.

Таких элементов в паре A3 два, т.к. эти два узла ранее обслуживали две наносети. В нулевые элементы включены старые трехзначные вланы наносетей.

Т.е. получается так, что каждый узел A4 может принадлежать одновременно двум элементам, при этом при конфигурировании оборудования на коммутаторах узла будут только вланы этих двух элементов, которым он и принадлежит.

Пример реализации элементов в паре узлов А3

[[Image:]]

Так должны выглядеть зоны распространения broadcast-сегментов для одного элемента.

Broadcast-сегмент включает в себя все магистральные связи всех коммутаторов А4 входящих в элемент, связь между узлами А3 и от узлов А3 до узлов А2.

На остальных звеньях этих вланов быть не должно, и так для каждого элемента.

[[Image:]]

И так для каждого элемента.

Помимо вот такого набора распределения у нас есть еще элемент номер ноль. Сегменты принадлежащие ему распространяются по всем связям всех узлов А3 и А4 отображенных на рисунке. Это одна из основных причин перехода от проекта спд1 к спд2.

Цель перехода отказаться от сегментов которые распространяются по всем коммутаторам в паре А3. Это очень большая зона, много коммутаторов, каждый влан есть везде. В итоге получаем много броадкастных доменов которые работают по всей сети. Это дает лишнюю нагрузку на коммутаторы. В случае аварии и возникновении шторма он будет затрагивать всю эту часть сети, а не только одно звено.

После окончания перевода всех услуг на спд2 элемента номер ноль быть не должно. На коммутаторах A4 должны быть только те вланы которые он обслуживает, ничего лишнего.

В том числе это позволит снизить нагрузку по мак адресам на коммутаторы A4

Реализация услуг в СПД

Доступ в Интернет/внутрисеть

DATA услуга передачи данных, она же интернет, оно же внутрисеть

[[Image:]]

Здесь и дальше само ядро спд отображено в виде черного ящика. Как я говорил ранее основная задача ядра это высокоскоростная передача пакетов, для всех услуг ядро сети обеспечивает только транзит, нас интересуют только связи входящие и выходящие из ядра.

С одной стороны у нас абоненты, с другой сервисные сервера которые тоже в конечном итоге подключаются в ядро спд, такие как DNS, SHAPER, DHCP и источники услуг.

Узлы A2 стоят на границе между ядром сети и уровнем агрегации, с одной стороны они смотрят в MPLS ядро сети, с другой стороны интерфейсы в сторону А3 это обычные сегменты.

На рисунке отображено две пары узлов A3, каждый узел каждой пары A3 подключен к двум разным узлам A2, одинаковым цветом отмечены цепочки А4 и узлы А3 которые для них основные. В каждой паре А3 половина элементов имеют основным один узел A3 другая половина другой парный A3, соответственно для всех абонентов в элементе основным узлом А2 будет узел имеющий прямую связь с основным А3.

Шлюз для абонентов расположен на узле A2, при штатной работе сети когда работают все связи и узлы это будет основной A2, резерв находится на узле A2 к которому подключен резервный A3

Для сегментов ДАТА в качестве шлюза используется первый адрес из выделеной подсети, трафик от абонента (попадает в нужный сегмент) на порту A4 путем присвоения метки vlanID, дальше трафик идет до своего A3 и до своего A2 где шлюз.

Основная задача уровней A3 A4 это доставить пакет от абонента до шлюза, т.е. до A2

Для того чтобы равномерно распределить нагрузку на связи A3-A2 половина элементов обслуживающихся A3 имеет шлюз на одном A2, другая на другом A2. Внутри каждой пары A3 если все узлы и связи функционируют то нагрузка распределяется примерно равномерно

[[Image:]]

Рассмотрим вот этого абонента(обведен кружочком), абонент включил компьютер, что происходит сначала? Первое это надо получить IP адрес, компьютер отправляет DHCP запрос.

Раньше, шлюз был подключен напрямую к узлу А3, шлюз находился в том же сегменте(влане) что и абонент, на шлюзе работал DHCP сервер. Это прямая коммутация в пределах одного broadcast сегмента, непосредственно от абонента через A4 через A3 до сервера, обратный путь был тот-же.

Сейчас DHCP сервера вынесены отдельно от шлюза, расположены где то в датацентре и подключены в ядро, в сегменте куда подключен абонент нет DHCP сервера который мог бы ответить.

Как абоненту получить IPcutter!из зала --- а некоторые получают!?

Каждый сегмент обслуживается двумя DHCP серверами находящимися на разных площадках, на каждом из узлов A3 для каждого сегмента ДАТА куда подключены абоненты активирована опция DHCP RELAY. Согласно базе данных на узлах А3 прописаны для каждого сегмента два IP адреса DHCP серверов. Как я говорил DHCP сервера подключены гдето в ядро.

Не важно через какой A3 пойдет трафик, где альтернативный порт, на каждом узле A3 настройки одинаковые, задача у DHCP RELAY простая: взять DHCP запрос из коммутируемого сегмента и отправить его по маршрутизации до DHCP сервера, получить ответ и от своего имени передать ответ в коммутируемый сегмент, если быть точнее запрос перенаправляется сразу на два DHCP сервера, основной и резервный.

От A3 запрос маршрутизируется по сегментам управления оборудованием, проходит через A2, через ядро сети до DHCP сервера, ответ идет обратно тем же путем, A3 опять преобразует в обычный броадкастный ответ DHCP сервера и отправляет в сегмент откуда был запрос.

Абонент получает IP, при этом абонент не знает что DHCP сервер находится вне в его сегмента.

Если быть более точным то запрос абонента как и любой броадкастный пакет доходит до обоих узлов A3, и оба уза A3 перенаправляют его на оба дхцп сервера которые обслуживают этот сегмент, и в итоге абонент получает 4 ответа от двух DHCP серверов через два узла А3. Это можно увидеть при дампе трафика сегмента. По правилам работы протокола DHCP клиент считает верным только первый пришедший ответ, остальные игнорируются

DNS запрос пойдет тем же путем. Одно отличие что это уже обычный пакет unicast который пойдет через шлюз. A3 не вмешивается в трафик, коммутирует его до шлюза на A2. Узел A2 отправляет в ядро, в ядре по кротчайшему маршруту пакет идет до DNS, и обратно тем же путем.

Выход в интернет

[[Image:]]

Адрес назначения в данном случае находится за пределами коммутируемого сегмента, соответственно пакет будет отправлен на шлюз. Шлюз находится на узле А2. А2 отправляет пакет в ядро, где тот выйдет из ядра для обработки на шейпере, вернется обратно в ядро, и уйдет на границу сети. На границе сети он может как проходить через NAT так и маршрутизироваться напрямую.

Серверов shaper`ов опять же два кластера на двух площадках для обеспечения резервирования так же как и NAT и каналов в интернет.

При диагностике следует учитывать что прямой и обратный трафик за пределы СПД пойдет через один и тот же shaper

Как пойдет трафик до другого абонента в нашей сети

[[Image:]]

От абонента 1 до абонента 2, подключенного к другой паре A3 трафик пойдет точно так же как и в интернет. IP адрес назначения не принадлежит подсети абонента, поэтому пакет будет направлен на шлюз. Либо через свой A3 на свой A2, либо через резервный A3 на свой A2, либо если A2 недоступен то любым путем на резервный A2. Попадает в ядро сети и кратчайшим маршрутом направляется к адресу назначения.

А вот обратный трафик может идти двумя путями.

Первый это полностью симметричный маршрут, тут показывать ничего не буду.

Но как я говорил ранее основная задача ядра сети это транзит трафика, транзит идет по наикратчайшему пути. В данном случае наикратчайший путь будет через A2 резервный для первого абонента, т.к. он одновременно является основным для второго абонента.

В этом случае трафик пойдет как обозначено на схеме зеленым.

Попадая в MPLS ядро трафик всегда идет по наикратчайшему маршруту.

Прямой и обратный трафик между двумя абонентами внутри СПД может не совпадать по маршруту, эту специфику следует учитывать при диагностики связности абонентов внутри СПД.

Мониторинг услуги ДАТА

[[Image:]]

Рассмотрим вот этого абонента. Если все узлы и связи в представленной схеме работают, то трафик от абонента и к абоненту будет проходить через свой узел A3.

На узле A3 весь трафик из сегмента куда подключен абонент будет дублирован в другой влан, влан мониторинга. Влан мониторинга присутствует на связях между узлами A3 и на связи от парного A3 до резервного A2.

По пути от основного А3 до резервного A2 на соседнем A3 на этот влан накладывается фильтр, который отбрасывает unicast трафик не относящийся к этому абоненту, т.е. до узла A2 во влане мониторинга доходит весь трафик интересующего нас абонента и весь широковещательный трафик сегмента куда он подключен. Сделано это для того чтобы избежать переполнения связи A3-A2. Широковещательный трафик нужен для тех ситуаций когда абонент например не получил IP, или отправляет неправильные DHCP запросы, или в сегменте вирус, или ничего не отправляет и клятвенно это утверждает. На оборудовании A2 этот влан перенапраляется на сервер мониторинга.

Весь процесс автоматизирован в РМО, одновременно возможно три сессии мониторинга для каждого узла A3.

Если например альтернативная связь в звене где подключен абонент переместится так что трафик пойдет через резервный A3 схема всеровно работоспособна, т.к. трафик пойдет до шлюза на A2 через свой A3.

Минусы: схема требуется работоспособность узлов обоих A2 и A3, если хотя бы один из узлов не исправен, автоматика не работает

схема применима в текущей реализации только для мониторинга сегментов ДАТА, с ее помощью не получится посмотреть трафик сегмента телефонии или аренды канала, или

управления оборудованием

Ограничения, накладываемые на абонентское подключение

Основные ограничения накладываются на оборудовании доступа (A4).

На порту непосредственного подключения настроены ACL для пакетов входящих на порт, т.е. со стороны абонента. Таким образом что разрешены только пакеты протокола IP в которых МАС отправителя и IP отправителя совпадают с реквизитами ТД выделенной абоненту.

Любой другой трафик на порту будет отброшен, что приведет к увеличению счетчика DROP packets на порту коммутатора, т.е. обеспечивается жесткая связка МАС IP port vlanID.

Этого было бы достаточно если у всех абонентов были реквизиты прописаны статически. Но это не так. Поэтому дополнительно созданы правила для нормальной работы DHCP. А именно разрешены пакеты протокола ARP и запросы DHCP где мак источника совпадает с МАС абонента.

Т.к. пришлось разрешить все arp запросы со стороны абонента, это потенциальная угроза. Поэтому дополнительно на порту настроена функция traffic control которая не позволяет абоненту отправлять более 50ти пакетов в секунду типа broadcast или multicast. Пакет arp попадает под определение broadcast. При превышении порога порт будет закрыт, по истечению таймаута открыт, и так может продолжаться до бесконечности. Срабатывание отображается в логах коммутатора.

Так же на порту доступа активирована опция port_security в режиме 1 MAC permanent

Требования СПД и связанных систем для успешной работы абонента

Что должно быть для нормальной работы при подключении абонента:

• в БД создан элемент
• в элементе созданы сегменты типа ДАТА
• к элементу привязаны узлы А4
• элемент привязан к DHCP
• элемент привязан к шейперу
• порт а4 должен быть открыт
• на порту А4 настроены ACL
• договор в АСР
• точка доступа с подпиской на услугу ДАТА
• положительный баланс счета
• МАС адрес должен быть прописан на DHCP сервере
• данные сегмента должены быть настроены на всем оборудовании А4 А3 А2 shaper DHCP

Блокировка доступа

Система АСР и управления оборудованием СПД поддерживает два типа блокировки:

• мягкая блокировка: в мягкой блокировке абоненту ограничивается скорость доступа в интернет на оборудовании a0-bs до 48килобит/сек, для юр лиц 1килобит/сек (например первые две недели при отрицательном балансе)
• жесткая/добровольная блокировка: закрывается порт на оборудовании А4
• Аренда подсети

аренда подсети

[[Image:]]

Что такое подсеть и с чем ее едят.

Еще более упрощенно отображена схема подключения и прохождения трафика. Оборудование A3 A4 обеспечивает только транзит трафика в сегменте от абонента до узла A2 где находится шлюз.

На отображенной схеме никакой подсети нет. На узле А2 в сегменте есть шлюз. Вот реквизиты прописанные у абонента. Подключен один компьютер, на интерфейсе в сторону A4 прописан указанный ИП.

Все работает, работает нормально, всех устраивает. Но обычно у абонента в квартире не один потребитель интернета.

Чтобы подключить более одного устройства в подавляющем большинстве случаев используется роутер.

Что делает маршрутизатор и как он устроен

[[Image:]]

Вот типичный пример подключения нескольких абонентских устройств к одной линии через роутер. Никакой подсети нет.

Роутер представляет из себя логически два устройства, маршрутизатор с двумя интерфейсами WAN и LAN, внешним и внутренним, и простой коммутатор подключенный к внутреннему интерфейсу. Схематически это выглядит как показано на рисунке.

На внешнем интерфейсе настраивается IP адрес выделенный абоненту, на внутреннем интерфейсе используются приватные не маршрутизируемые IP адреса, обычно 192.168.*.*. Из этого диапазона приватных адресов назначаются IP адреса для устройств внутренней сети, обычно на внутреннем интерфейсе маршрутизатора для этих целей используется DHCP сервер. IP адрес внутреннего LAN интерфейса при этом будет шлюзом для внутрених устройств.

Основная функция роутера в этой схеме это обеспечение функционала NAT.

Как работает NAT

Когда какой-то компьютер из внутренней сети отправляет пакет предназначенный для внешней сети маршрутизатор запоминает номера портов TCP адресов источника и назначения, и отправляет пакет с внешнего интерфейса перезаписав в пакете адрес источника на IP своего внешнего интерфейса. За пределами внутренней сети в пакетах нет IP адресов приватного диапазона 192.168

Когда маршрутизатор получает пакет на внешний интерфейс он сверяется с таблицей запомненных сессий на основании портов TCP, и отправляет его с внутреннего интерфейса именно на тот компьютер который отправлял запрос с этого порта TCP.

Если пакету пришедшему на wan порт нет соответствия в таблице сессий пакет будет отброшен.

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

Для решения этих вопросов на маршрутизаторе существует несколько вариантов:

• опции virtual server или static port forwarding где можно статически назначать маршруты пакетам пришедшие на внешний интерфейс на основании портов назначения на определенного клиента во внутренней сети.
• использовать DMZ. В этом случае любой пакет неинициированный извне будет перенаправлен на определенный компьютер во внутренней сети.
• или более интеллектуальный сервис UPNP. Когда приложение из внутренней подсети может при необходимости само сообщить маршрутизатору какие порты ему нужны.

Но вернемся к подсетям:

[[Image:]]

Абонент заказал подсеть, вот эта подсеть. На маршрутизаторе A2 прописывается подсеть. Теперь A2 знает что если IP адрес назначения принадлежит этой подсети, то такой пакет нужно отправить вот на этот абонентский IP адрес. В принципе при должной квалификации использовать эту подсеть абонент может на одном ПК. Но обычно ставят роутер.

[[Image:]]

Вот довольно распространенная ошибка. Так выглядит подключение если абонент не знает зачем ему подсеть. Подсеть настроена только на А2, но не на абонентском роутере, все компьютеры выходят наружу по-прежнему через один IP адрес. Узел A2 честно отправляет пакеты предназначенные подсети на абонентский IP, но абонентский маршрутизатор не знает что с ними делать. Для того чтобы в такой схеме нормально заработала подсеть надо отключить на абонентском маршрутизаторе NAT и настроить его в режиме простого маршрутизатора.

[[Image:]]

В этом режиме каждый компьютер подключенный к внутренней подсети будет общаться с внешней сетью под своим уникальным IP адресом. Для LAN интерфейса выбирается один ИП из выделенной подсети, для абонентских устройств назначаются остальные. В таблице маршрутизации при этом должна быть только одна запись. Настройки WAN интерфейса при этом остаются такие же как и при использовании NAT.

IPTV

[[Image:]]

На рисунке максимально упрощенная схема. Два узла A3. Где-то наверху ядро сети. Звено распределительной сети из двух коммутаторов

[[Image:]]

На рисунке один сегмент. В нем подключено три абонента, влан сегмента как говорили ранее присутствует на всех магистральных связях оборудования

Что такое multicast? multicast пакет этот тот же самый широковещательный пакет. Изначально при создании ethernet протоколов не было дифференциации multicast и броадкаст, было просто определение широковещательный пакет. Коммутатор по умолчанию будет обрабатывать multicast пакет как обычный широковещательный трафик, т.е. multicast пакет пришедший в одном влане с одного порта будет отправлен на все порты включенные в этот влан.

В этой схеме допустим где то наверху подключен источник multicast каналов, внизу три абонента. Каждый из них желает смотреть свой IPTV канал, соответственно чтобы multicast пакет дошел до абонентов источник должен транслировать все три канала в этот сегмент одновременно. При этом коммутатор не различает каналы мультикаст, весь multicast трафик который он получит сверху он отправит на все порты, т.е. в данном случае каждый из трех абонентов будет получать все три канала, независимо от того хочет он смотреть или нет.

А теперь представим себе не упрощенный как на рисунке сегмент а сегмент из рабочей сети. В нем 20 коммутаторов, 200 абонентов, 100 из них хотят смотреть IPTV причем каждый свой канал при такой схеме источник должен вещать в сегмент все 100 каналов. При этом каждый коммутатор получив multicast в сто каналов на магистральном порту будет пытаться отправить этот поток каждому абоненту. Простой расчет: 100 каналов это примерно 400 мегабит трафика

по всем магистральным связям которые имеют пропускную способность гигабит трафик пройдет без проблем, а вот клиенты уже подключены на скорости 100 мегабит, коммутатор пытается каждому клиенту передать 400 мегабит трафика. Как следствие работать ничего не будет, каждая абонентская линия будет полностью забита мультикастом.

IPTV: протокол IGMP

Для разрешения этой проблемы придумали протокол IGMP. Протокол IGMP работает в пределах одного broadcast домена, одного влана. Грубо говоря одного виртуального свитча в коммутаторе

его можно сравнить с функцией NAT у маршрутизатора, где маршрутизатор помнит пакеты с какими портами TCP какому внутреннему абоненту перенаправить. Протокол IGMP работает только с multicast трафиком. Позволяет коммутатору направлять на порт только тот канал multicast который заказал абонент, абонентское оборудование тоже должно поддерживать протокол IGMP.

Для того чтобы абоненту начать смотреть какой либо канал multicast он сначала отправляет запрос на подписку, igmp query. Этот запрос содержит в себе информацию о запрашиваемом канале. Для каждого канала на коммутаторе хранится отдельная таблица портов на которые будет коммутироваться пакеты этого multicast канала. Протокол IGMP активирован на всех портах коммутаторов A4 в том числе магистральных, и на портах оборудование A3 в сторону A4.

Теперь в нашей текущей схеме с тремя абонентами каждый абонент будет получать на свой порт multicast трафик только того канала который он запросил.

Можно вещать в сеть все 128 каналов, при этом у абонентов не будет переполнения трафика на порту. Без протокола IGMP каждый абонент получал бы все 128 каналов.

Протокол устроен таким образом что абонент должен периодически подтверждать подписку. Коммутатор удалит порт из таблицы соответствия канала по достижении таймаута если не будет получать подтверждение подписки. Таймаут на коммутаторах А4 настроен на 260 секунд. При этом абонент переключая каналы за минуту может подписаться на пару десятков каналов и они переполнят 100 мегабит. Поэтому в протоколе IGMP реализована функция отписки. Перед тем как подписаться на новый канал клиент сначала отписывается от предыдущего.

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

[[Image:]]

И пользователи в каждом сегменте хотят смотреть IPTV

Как я говорил ранее пакеты из одного влана никак не могут попасть в другой влан, так устроен коммутатор. Чтобы в такой схеме обеспечить каждому пользователю возможность просмотра любого multicast канала нам потребуется в каждом сегменте где подключен хоть один пользователь вещать все 128 каналов. Внутри каждого сегмента работает протокол IGMP, абонент будет получать только тот канал на который подписался. Но в такой схеме предоставления услуги начинаются проблемы с переполнением гигабитных связей между коммутаторами. Потому как мы получаем дубликаты multicast каналов в каждом влане где подключены абоненты.

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

Чтобы избежать дубликатов мультикаста в разных сегментах на магистральных связях придумали следующую надстройку над существующими протоколами.

IPTV: технология мультикаст влан

краткая история как мы до этого дожили

сначала были хабы

потом из них сделали коммутаторы

потом научились делать из одного коммутатора несколько виртуальных посредством вланов

потом разделили широковещательные пакеты на броадкаст и мультикаст

научили multicast обрабатывать по IGMP протоколу

коммутаторы стали жирными, поддерживать много абонентов в разных вланах

а вещать всем абонентам надо один и тот же multicast

Придумали технологию multicast vlan(в терминологии cisco MVR)

[[Image:]]

Что из себя представляет multicast vlan. Это еще один broadcast сегмент, еще один виртуальный коммутатор, но теперь мы выключаем вещание multicast во всех дата вланах куда подключены абоненты, и транслируем все каналы в один единственный влан, multicast vlan.

Технология multicast vlan как бы нарушает классические правила работы коммутатора, если используются вланы на базе меток то за портом без тега может быть только один влан. Мы не спускаем отдельный влан с мультикастом до абонента в тегированном виде, абонент по прежнему ничего не знает про вланы в нашей сети, при этом абоненткий порт у нас получается как бы в двух вланах одновременно в нетегированном виде, в дата влане и мультикаст влане.

Как это работает:

В зависимости от того какой пакет пришел от абонента на порт коммутатора. Если пакет на входе порта коммутатора является multicast пакетом, то такой пакет будет направлен в multicast vlan. Все другие пакеты по прежнему будут попадать в дата влан. При этом как и раньше со всех пакетов в сторону абонента метка влана снимается, будь то дата влан или multicast vlan со стороны абонента все выглядит прозрачно.

Внутри multicast vlan работает все тот же протокол IGMP, чтобы каждый участник получал только те каналы которые запросил.

Задача решена. Абоненты сидят в своих вланах. Переполнения 100 мегабит на абонентских линиях нет. Дубликатов multicast трафика на магистральных портах нет.

[[Image:]]

На схеме отображен только multicast vlan. В отличие от дата вланов, multicast vlan отсутствует на связи между узлами A3 и на связях A2 -A3. Узлы A3 получают multicast от узлов A2 по другому протоколу маршрутизации multicast PIM. Каждый узел А3 получает мультикаст от узла А2 к кторому он подключен напрямую, если он недоступен, то от парного А3, который в свою очередь от А2.

multicast vlan начинается на узле A3, на связях между A3 multicast vlan отсутствует за ненадобностью. Каждый узел A3 ретранслирует каналы в multicast vlan в сторону A4, но как помним на связях A4 у нас работает протокол СТП, который обеспечивает логический разрыв. Поэтому в один момент времени абонент будет получать мультикаст только с одного А3. От какого из узлов А3 абонент будет получать multicast трафик зависит от расположение альтернативного порта STP в звене.

Исходя из вышеописанной схемы следует обратить внимание при работе через резервный узел А3 мультикаст поток будет идти к абоненту с резервного А2, а при работе через свой узел А3 от своего основного А2. Маршруты прохождения ДАТА трафика и мультикаст трафика могут различаться.

Это следует учитывать при диагностике IPTV.

IPTV: ограничение подписок

Ограничение доступа к услуге IPTV обеспечивается на оборудовании A4, аналогично ACL для привязки абонентов к порту для дата вланов. На оборудовании A4 есть списки доступа multicast. У коммутаторов dlink это называется multicast профили, у huawei это обычный ACL.

Работает это на уровне протокола IGMP - подписок от абонента, в мультикаст влане. Когда на порт приходит запрос на подписку он сначала проходит проверку, разрешено ли с этого порта принимать подписку на этот канал, если нет то пакет будет отброшен и не дойдет до обработки IGMP протоколом, на порт не будет добавлен канал.

Более кардинальное решение это либо можно просто исключить порт из multicast vlan.

Еще одно ограничение накладываемое на абонента это количество одновременных подписок. Оборудование A4 настроено на разрешение не более 20 подписок с одного порта, т.е. 20 каналов мультикаст одновременно.

Как оказывается услуга с точки зрения всей сети:

IPTV: от головной станции до абонента

[[Image:]]

Головная станция агрегирует источники сигнала от поставщиков услуг, это может быть присоединение по кабелю, сигнал со спутника или эфира. Резервирование по источникам сигнала происходит внутри узла A0, внутри ГС ТВ. Всё собирается вместе, формируется один поток каналов, который уже отдается в СПД на уровень A1 по двум связям.

Протокол PIM (Protocol Independent Multicast) призван решить проблемы маршрутизации для произвольного числа и расположения членов группы и для произвольного числа отправителей информации. Проще говоря это специальная маршрутизация для широковещательных пакетов типа мультикаст. т.е. по средствам этого протокола обеспечивается маршрутизация от головной стации ТВ до каждого коммутатора A3. Источник услуги в данном случае это оборудование A0, A1 и A2 участвуют в маршрутизации, основная задача доставить трафик до каждого узла A3. Маршрутизация внутри ядра происходит в отдельной MPLS сущности, услуга изолирована от других.

Узел A3 для данной услуги является маршрутизатором, конечным клиентом для протокола PIM. Интерфейс в мультикаст влане называться pim border interface, именно тут заканчивается маршрутизация и начинают работать L2 протоколы.

Это одна из двух услуг в которых коммутатор A3 используется в качестве маршрутизатора. A3 это коммутатор третьего уровня, коммутатор с поддержкой функций маршрутизации. Как говорили ранее для услуги дата он не более чем транзитный коммутатор, а для IPTV это маршрутизатор.

как пойдет трафик до абонента:

[[Image:]]

На схеме выше коммутатор в звене где подключен абонент работает от своего А3, соответственно коннективность по мультикаст влану у него есть только до своего А3, он в свою очередь получает мультикаст трафик от своего узла А2, это более приоритетный маршрут чем с парного А3. т.е. если все связи A3-A2 работают то каждый A3 будет получать multicast через свой A2.

Путь прохождения трафика для услуги ДАТА и IPTV на схеме выше одинаковый.

[[Image:]]

Что произойдет если в звене переместить альтернативный порт как отображено выше.

Распределительная сеть настроена на один multicast vlan, multicast vlan нет на связях A3-A3. Получается что если все связи A3-A2 работают, то если звено развернуть так чтобы связь пошла через резервный A3 для абонента поменяется источник multicast влана. Абонент будет получать multicast через резервный A3, а тот в свою очередь через резервный A2.

При этом дата трафик(внутрисетевой и интернет) будут идти по прежнему через свой A2 хотя и через резервный A3.

IPTV: диагностика ряда типичных проблем

Ситуацию в предыдущем пункте следует учитывать при диагностике, если наблюдается проблема на связи A2-A3: то у половины абонентов в паре A3 интернет может работать нормально, а multicast плохо, или наоборот, или у одной половины плохо и интернет и IPTV, а у другой все хорошо. При диагностике надо учитывать что маршруты для услуг IPTV и дата могут различаться

На что следует обратить внимание при диагностике:

• проверить наличие подписок на канал на оборудовании A3 и A4, учитывая путь
• проверить счетчики ошибок на портах оборудования по пути прохождения трафика
• проверить правильность настройки QOS на оборудовании, трафик должен доходить до абонента с нужной меткой
• следует проверить показания пробника на оборудовании A3 и сверить его с качеством канал на ГС
• при долгой подписке проверить загрузку CPU оборудования по всей цепочке от A4 до A3
• исключить проблему с hash

Телефония: схема оказания услуги

[[Image:]]

Рассматривается текущая схема оказания услуги. Первичные цели отказаться от функционала маршрутизации на оборудовании A3 и привести под критерии СПД2 - уникальный набор вланов для элемента.

Головная стация телефонии разнесена по двум площадкам, на каждой стоит sip сервер, сервера резервируют между собой один IP sipserver.novotelecom.ru Всё это подключено двумя связями в ядро сети, ядро сети как и для услуги телевидения обеспечивает маршрутизируемый транспорт от оборудования A0(ГСТВ) до узлов A3.

Это еще одна услуга для которой коммутатор A3 выступает в роли маршрутизатора.

Что происходит в паре узлов A3 и коммутаторах доступа A4 в ней:

В старых сетях, которые строились как наносети в каждой паре A3 есть два нулевых элемента в каждом из которых есть влан телефонии, который остался от наносетей. Это вланы трехзначные начинающиеся на 8 и заканчивающиеся на 9 от 809 до 899.

В новых сетях для каждого элемента назначается свой влан телефонии, но так же возможна схема с двумя сегментами телефонии на пару узлов А3 с одновременным созданием фиктивных нулевых элементов исключительно только с этими сегментами.

Влан сегмента телефонии присутствует на связях между A3-A4 и A3-A3, в отличие от дата вланов в него не добавлены связи A3-A2

В каждом сегменте телефонии, будь то старый влан в нулевом элементе, или новый из нужной цепочки, A3 имеет интерфейс в этом сегменте. Это интерфейс шлюза для абонентского телефонного устройства. Этот IP резервируется между двумя A3 по протоколу hsrp или аналогичному, т.е. в один момент времени этот IP адрес поднят только на одном устройстве.

Есть два варианта подключения абонентского оборудования:

• первый это один влан на порту A4 без тега
• второй это тегированный влан параллельно с услугой ДАТА

Именно из за второго варианта услуга дата имеет привязку IP МАК ПОРТ ВЛАН

Параллельно спущенная с датой телефония не имеет ограничений.

Телефония new: схема оказания услуги

[[Image:]]

Шлюз для телефонии перенесли с А3 на А2

Телефония: типичная диагностика

влан сегмента телефонии должен быть на всех связях узлов А3 А4 соответствующих элементов

для работоспособности со стороны абонента должен быть доступен шлюз на А3

через этот шлюз должен отвечать DNS

через этот шлюз должен быть доступен sip сервер

на sip сервере должна быть настройка согласно данным АСР

положительный баланс

блокировка при отрицательном балансе производится на уровне sip сервера

Аренда канала (VLAN): схема оказания услуги

[[Image:]]

Эта услуга не выходит за пределы СПД. Все подключения абонентов производятся только к узлам A4. На уровнях A3 A4 вланы распространяются по тому же приципу что и дата вланы, основная задача это транспорт трафика до A2. Ядро сети для арендованных вланов представляет из себя большой коммутатор, один большой коммутатор для всех вланов. Это достигается при помощи MPLS. В итоге мы получаем что один номер tag сквозняком проходит через всю сеть, от одного узла A4 до другого A4 в любой другой части сети.

На коммутаторах A3 в конфигурации присутствуют только те номера вланов точки доступа в которых есть в элементах которые обслуживаются узлом A3 и его парным.

На всех коммутаторах A4 элемента настроены только те номера вланов точки доступа в которых есть в этом элементе.

[[Image:]]

На рисунке пример распространения одного влана в СПД. В одной части распределительной сети влан есть на коммуатторах элемента где выдедела ТД, на обоих коммутаторах A3 бслуживающих этот элемент, на связях A3-A3 и A3-A2

Из особенностей: в каждую пару узлов A3 со стороны ядра, от узлов A2, вланы спускаются только с одной стоны, т.е. всегда для всех вланов аренды канала. т.е. основной A2 для арендованных вланов в паре узлов A3 не зависит от того в каком элементе подключена ТД, основной он для этого A2 или резервный.

[[Image:]]

Вот пример распространения двух вланов.

В обоих частях сети в каждой паре A3 включения в эти вланы произведено в элементы у которых основные A3 разные, но вланы спускаются только через один A2.

Аренда канала (VLAN): резервирование

[[Image:]]

Если по какой либо причине связь A3-A2 не работает, или не работает A2 или A3, вланы автоматически переключаются на другой A2, не имеет значение какой A3 и A2 у абонента основной, это следует учитывать при диагностике.

Для услуги используются номера вланов из диапазона 3072-3327. Эти вланы уникальны в пределах всей СПД, т.е. метка присваивается пакету на порту A4 в одной части сети, например на родниках, и снимается на другом порту A4 в Искитиме.

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

Аренда канала (VLAN): ограничения

Так же на порту ограничивается количество допустимых МАС адресов, по умолчанию для одного влана это 5 адресов, значение так же суммируется если вланов несколько. Количество допустимых МАС адресов для каждой ТД задается в АСР и может быть изменено корпоративным отделом.

Ограничение МАС работает в режиме clear on timeout. т.е. порт коммутатора обучает МАС адресам, добавляет их в таблицу коммутации динамически, но когда количество превышает допустимое прекращает обучение, мак адреса удаляются с порта по истечению времени жизни ARP записи на коммутаторе. На коммутаторах A4 время жизни АРП 300 секунд, т.е. если на порту стоит ограничение в 5 адресов, а у абонента подключен удаленных офис на 10 компьютеров то в один момент времени работать будут только 5, обычно самых активных.

Аренда канала (VLAN): диагностика типичных проблем

Трафик прямой и обратный между двумя точками включение будет проходить по одному маршруту.

т.к. используется один номер тега влана для всей СПД - самая простая диагностика это проверка наличия МАК адресов. Требуется проверить связность между двумя точками включения во влан. На одной точке включения следует установить генератор трафика, достаточно ping на несуществующий адрес, эта команда будет генерировать arp запросы. arp запрос широковещательный, мы должны увидеть его в другой части СПД на коммутаторе с другим включением в этот влан, где находится вторая точка включения до которой заявлено отсутствие связности, если на коммутаторе A4 в таблице FDB присутствует МАC устройства генерирующего широковещательные пакеты - значит связность есть. Если МАС адреса нет, то следует идти от источника, от порта включения в A4, по цепочке A4, до A3 основного и резервного и до A2 через который вланы спускаются в пару A3, в другой части СПД аналогично.

Жалобу на низкую скорость во влане можно проверить только включением двух устройств на точках между которыми заявлена проблема, И проведением замеров. Удаленно жалобу на скорость можно подтвердить или опровергнуть поставив порты A4 на мониторинг трафика, вероятнее всего на одной точке включения будет утилизирована вся полоса пропускания. Особенно часто это можно наблюдать на схемах с подключением удаленных офисов к главному, на порту включения главного офиса полоса пропускания меньше чем суммарная всех других точек.

Приоритизация трафика

[[Image:]]

Качественное оказание услуг абонентам сети Новотелекома было невозможно, если бы в сети не была настроена правильная приоритизация обработки пакетов.

На рисунке предоставлена еще одна упрощенная схема предоставления услуг. Здесь отображены все типы абонентских подключений, источники всех услуг и все транзитные узлы спд через которые проходит трафик от источника до абонента.

Всё оборудование через которое проходит трафик той или иной услуги обрабатывает каждый пакет на основании метки приоритета внутри пакета. На уровнях A4 A3 очередь определяется исходя из метки COS из 802.1q заголовка пакета. На уровнях A3 A2 A1 A0 очередь в которую попадет пакет определяется на основании метки DSCP из IP заголовка пакета.

[[Image:]]

Из представленной схемы можно понять в каких частях пакета какие заголовки. Метка COS идет совместно с номеров тэга, эти два параметра неразделимы и опредеделены в одном стандарте 802.1q . Из двух байт заголовка первые 12 бит определяют номер влана, это 2^12=4096 значений

под метку COS отведено всего 3 бита, это 2^3=8 значений. Для метки DSCP в IP заголовке отведено 6 бит это 2^6=64 значения.

Обратите внимание на то что метка DSCP это часть более общего заголовка IP пакета называемого TOS, при мониторинге трафика tcpdump показывает именно значение TOS а не DSCP. Таблицу соответствия несложно найти в интернете.

В реальности используемое оборудование на уровне A4 A3 умеет работать с 4мя очередями приоритета, на уровне A2 с 8мью. Этого достаточно для оказания наших услуг

Как обрабатываются пакеты в зависимости от метки:

На оборудовании A4 используется жесткая очередь, на остальном оборудовании жесткая очередь используется только для телефонии, для остального трафика разделяемая очередь.

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

Приведу только один пример, если абонент подпишется на 7 ХД каналов IPTV то интернета у него скорее всего не будет т.к. IPTV приоритетнее обычного трафика, а 7 каналов забьют полосу порта подключения 100 мегабит на коммутаторе A4

Чем больше значение метки тем приоритетнее трафик. Схема работает только если всё оборудование на пути прохождения трафика настроено одинаково для всех типов трафика, любой промежуточный узел настроенный не по шаблону может испортить всю картину.

Приоритизация трафика: правила преобразования меток

[[Image:]]

Откуда появляются метки и как они преобразуются по мере прохождения через узлы сети:

Начнем с исходящего трафика от абонента. Трафик от абонента приходит без тега влана. На узле A4 на порту пакету присваивается номер влана и метка COS. Для оборудования dlink это параметр порта default_priority, эта опция работает только для не тегированного трафика входящего на порт. Исключение составляет подключение телефонии для физ лиц: в этом случае тегирование пакета и присвоение метки настраивается на телефонном оборудовании. На магистральных портах коммутаторов A4 весь трафик тегированый и уже имеет нужную метку.

Таким образом получаем что на входе и выходе в коммутатор все пакеты имеют метку и обрабатываются в соответствии с ее значением

Самое интересное происходи на оборудовании A3. Оборудование A3 определяет трафик в нужную очередь основываясь на метке DSCP. С портов в сторону A4 трафик приходит тегированый с правильной меткой COS. Эти порты настроены в режиме trust cos доверять метке COS в пакете, все входящие пакеты на этих портах подвергаются обработке согласно таблице соответствия COS <=> DSCP, при этом в пакетах перезаписывается поле DSCP независимо от его содержимого и трафик попадает в нужную очередь обработки.

На магистральных портах в сторону A2 и на оборудовании A2 A1 стоит правило доверять метке DSCP. Далее все оборудование ядра СПД A2 A1 обрабатывает пакеты согласно метке DSCP и не вмешивается в содержимое пакета.

Трафик от источников услуг до клиента обрабатывается похожим образом. На входе в ядро СПД для каждой услуги принудительно выставляется метка DSCP соответствующей очереди, причем интернет трафику принудительно присваивается низший приоритет. Трафик распространяется через ядро спд до A2 от A2 к A3, на всем пути обрабатывается согласно метке DSCP в нужной очереди. На узле A3 перед отправкой в сторону A4 в пакете согласно таблице соответствия на основании метки DSCP перезаписывается метка COS. Трафик идет через узлы A4, на порту абонентского подключения метка в месте с тэгом влана снимается.

[[Image:]]

Таблица соответствия COS DSCP по которой работает перемаркировка на оборудовании A3

В таблице красным обозначены номера меток используемых в распределительной части сети и на уровне ядра. Причем правило преобразования DSCP<=>COS на оборудовании A3 устроены таким образом что любая другая метка DSCP будет обнулена, это упрощает диагностику.

При диагностике услуги, если есть подозрение на неправильную приоритизацию проще всего посмотреть номера меток в пакетах на абонентском подключении, для этого временно придется спустить все услуги абоненту в тегированом виде, смотреть нужно как метку COS так и метку DSCP в заголовках пакета, если трафик услуги имеет отличную от обозначенной метку значит что то сломалось и это может влиять на качество.

Перезапись метки DSCP на уровне А3 является не желательным, но пока необходимым решением. На это могут жаловаться клиенты с услугой аренды канала т.к. они не могут использовать приоритизацию трафика на основе DSCP меток. Исправить ситуацию с перезаписью DSCP заголовков позволит новая схема организации аренды канала.

Вместо P.S.

Благодарности:

• Полозникову Артему за технические консультации
• Филатову Диме за консультации по работе служб АСР
• Болдыреву Роману за вопросы
• Ане Новиковой за рецензирование и верстку
• Чуб Ивану за видеозапись
• Авдееву Алексею за консультации по организации
• всем кто вытерпел первую пробную лекцию

продолжение следует