[alibek]

Помогите выбрать между тремя зайцами.

 

Есть сеть: ядро -> агрегация -> доступ. Доступ это один или несколько (обычно не более 2-3) L2-коммутаторов, подключенных цепочкой (гирлянда).

В сети есть несколько классов трафика: управление, IPTV, важный трафик, обычный трафик. Различается по VLAN.

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

В принципе, есть три варианта:

- красить трафик на ядре, на агрегации и доступе доверять раскраске;

- красить трафик на агрегации, на доступе доверять раскраске;

- красить трафик непосредственно на доступе.

 

И никак не могу выбрать, что лучше.

Первый вариант - красить трафик на ядре — выглядит наиболее логичным. Обработка выполняется в одном месте, если что-то поменяется в дизайне сети, то на агрегации и доступе настройки QoS менять не нужно, нужно поменять схему раскраски только на ядре. Но есть и минусы — если вдруг кто-то ошибется при настройке коммутаторов или подключении и клиент окажется подключен в порт, меткам которого коммутатор доверяет, то он в теории сможет флудить приоритетным трафиком. Кроме того, при такой схеме восходящий трафик (от абонента) не раскрашивается, пока не дойдет до ядра. Правда наиболее важный трафик (управление и IPTV) генерируется на ядре и он в любом случае будет раскрашен.

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

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

[vurd]

На ядре только, остальное траст на магистральных портах.

[s.lobanov]

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

 

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

 

Что такое "важный" трафик?

[alibek]

Важный трафик это:

- управление

- IPTV (не из-за того, что в полосу не влезает, а из-за того, что у некоторых коммутаторов буферы маленькие и его приходится приоритезировать, чтобы не сыпалось)

- видеопотоки с IP-камер

 

Первые два генерируются в ядре, а последний наоборот, на доступе.

[Negator]

на мой взгляд чем ближе к ядру, тем лучше.

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

[s.lobanov]

Вы противоречите сами себе. В первом посте "важный трафик" это отдельный класс. Ну да ладно, не суть.

 

Ваша задача решается очень легко ибо нет заморочек с трафом от кастомеров и их извращенными фантазиями. IPTV красите на источнике или на порту куда он включен. Трафик с камер красите на порту свитча в 802.1p, на агрегации делаете маппинг в dscp. Дальше можно тупо pq+trust. Управление - аналогично iptv, обратный трафик для управления - пинги обычно идут с таким же dscp как и пришло. SNMP - сами гляньте, tcp и так прорвертся

[OKyHb]

А как обычно делается:

1. раскрашивать по DSCP и дальше доверять этой раскраске (смотреть только на значение DSCP)

2. раскрашивать DSCP, на порту коммутатора мапить DSCP в 802.1p CoS vlan-тега, и дальше на транзитных коммутаторах проверять только этот L2 приоритет?

 

То есть, что выбрать - trust-CoS или trust-DSCP?

[nnm]

А как обычно делается:

1. раскрашивать по DSCP и дальше доверять этой раскраске (смотреть только на значение DSCP)

2. раскрашивать DSCP, на порту коммутатора мапить DSCP в 802.1p CoS vlan-тега, и дальше на транзитных коммутаторах проверять только этот L2 приоритет?

 

То есть, что выбрать - trust-CoS или trust-DSCP?

 

В идеальном мире было-бы здорово не менять клиентской маркировки (DHCP). Т.е. кодировать класс при помощи 802.1p CoS и "на транзитных коммутаторах проверять только этот L2 приоритет". Но возможности коммутаторов вносят коррективы.

Изменено 7 сентября, 2016 пользователем nnm

[s.lobanov]

в теории если весь доступ настолько умный, что умеет обрабатывать DSCP и красить в него, то можно забыть про 802.1p, только если внутри pppoe не надо что-нибудь приоритезировать. Такая задача у меня была - OTT TV внутри PPPoE надо было раскрасить, чтоб дешёво победить торренты внутри полосы и бёрсты на сети - пришлось красить в 802.1p на pppoe-сервере (linux vlan egress-qos-map)

 

кстати, кто-нибудь тестил dscp в IPv6-трафике в свитчах ценовой категории ~150-180$ в розницу? есть мысль, что не везде оно работает...

[Tosha]

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

Мне кажется это не спасет. Буфер общий. И как в этом буфере пакеты не перемешивай - все равно будут теряться невзирая на типы пакетов.

[alibek]

На Orion это помогло.

Без приоритезации качество IPTV было плохим. Хотя порт утилизировался меньше чем на 5%.

С приоритезацией стало намного лучше.

[s.lobanov]

Tosha

Фреймы с большим приоритетом проходят вперёд, а другой трафик копится и дропает. На свитчах с малым буфером и наличием шпд+udp tv нужно обязательно делать qos

[Tosha]

Тут надо знать алгоритм работы железки.

Если помогает - поднимать приоритет до тех пор пока сыпаться не перестанет и затем еще для запаса.

 

Красить надо на порту источника трафика. Или как можно ближе к источнику.

Но можно красить в любом месте где это легко сделать но до первого места где COS используется.

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

 

Тут я так понимаю источники потоков к ядру подключены. Проще всего в ядре и красить. Заодно и на агрегации приоритеты можно настроить на случай если вдруг начнут DDOS-ить. Ну и джиттер будет сильно меньше.

[s.lobanov]

Тут надо знать алгоритм работы железки.

 

Если на железке нет возможности побороть congestions (microburst это тоже congestion), то просто считайте что на ней нет поддержки QoS. На всех современных свитчах что я видел (начиная с websmart'ов) в том или ином виде qos есть, кто-то умеет матчить dscp, кто-то нет, перекрашивать и т.д. Но заставить пройти один трафик вперёд другого сейчас все умеют.

 

Если же сам поток IPTV настолько кривой (неравномерный), что количество трафика в его всплесках больше, чем буфер свитчей,то тут надо что-то делать со стримерами/входным потоком от апстрима, это уже никак не решить без перестроения потока.

[v_r]

Что касается покраски, обычно красят как можно ближе к источнику, а внутри сети настраивают trust cos или trust dscp чтобы городить схему с покраской на каждом линке. Чему верить, cos или dscp, зависит от возможностей оборудования на котором настраиваете QoS, важно чтобы схема поддерживалась всеми устройствами, и зависит от трафика в вашей сети, например если у вас бегает mpls который тоже надо приоритизировать то лучше использовать cos, во всяком случае пока все оборудование не начнет поддерживать trust mpls exp. Трафику от домонетов можно ставить класс "интернет" если нет специфических требований, трафик от бизнес-абонентов можно направлять в несколько классов либо в один класс "бизнес-абоненты", опять-таки зависит от типа трафика и возможностей оборудования, на некоторых свитчах всего 4 очереди на порт поэтому сильно выбирать не приходится.

 

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

 

Примерная схема: 50% канала - приоритетные очереди для VoIP/IPTV, остальные 50% делятся поровну между Интернет-трафиком, трафиком бизнес-абонентов, служебным трафиком протоколов маршрутизации.

Изменено 13 сентября, 2016 пользователем v_r