(Прежде всего, я извиняюсь за эту стену текста. Я не знаю, как сделать ее короче, не потеряв важную информацию. Сначала я хотел использовать чат для этого, как мы делаем на serverfault для такого рода. вопросов, но нет никого в инженерной комнате сети).
Мы являемся корпорацией с несколькими дочерними компаниями, где у нас довольно большой управляемый IP-VPN с примерно 70 различными местоположениями, варьирующимися от 2 Мбит / с SHDSL до 100 Мбит / с. IP-VPN несет несколько VPN (или, если быть точным, туннелей).
Приоритет трафика с точки зрения управления и проектирования:
- VoIP (Avaya и Lync)
- Видео (Lync)
- RDP
- Внутренние службы (файловые серверы, Active Directory, интранет и т. Д.)
- Внутренние службы без приоритетов (прокси-серверы для использования в Интернете, службы обновления Windows, управление конфигурацией системного центра, прокси-серверы для обновления антивируса и т. Д.)
- Несоответствующий трафик (интернет)
VoIP используется только в определенных офисах, где мало пользователей. Самый большой удаленный офис, использующий VoIP, имеет SHDSL 4 Мбит / с с 5 сотрудниками и 5 IP-телефонами avaya с кодеком G.711 ALAW 64K. Это никогда не должно доводить трафик VoIP-данных до более чем 320 кбит / с. Я проверил, что телефоны используют DSCP 46 для аудио, и поэтому он правильно соответствует EF (см. Конфигурацию ниже). Сигнализация однако соответствует DSCP 24, что я не уверен, если наш профиль QoS срабатывает ..
Все удаленные офисы используют RDP против нескольких ферм RDS в нашей штаб-квартире (2x100 Мбит / с). Полоса пропускания, используемая для RDP, не так легко определить, поскольку она в основном использует все, что получает. У нас есть определенные ограничения, чтобы убедиться, что он не слишком ресурсоемкий, но это, вероятно, выходит за рамки этого сайта. В последнее время у нас есть довольно серьезные проблемы с RDP ( /server/515809/mouse-cursor-jumps-around-when-using-rdp ), поэтому я публикую это по сетевой инженерии.
Lync использует DSCP 46 для аудио и DSCP 34 для видео. Внутренние сервисы и внутренние сервисы без приоритетов сопоставляются подсетями, а все остальное просто совпадает с любым.
Вот копия последней версии конфигурации QoS, которую я немного изменил, чтобы скрыть определенные имена и IP-адреса:
!
class-map match-any INTERNAL-PRI
match access-group name CUST-INT-PRI
match access-group name CUST-DMZ
class-map match-any INTERNAL-NOPRI
match access-group name CUST-INT-NOPRI
class-map match-any REMOTEDESKTOP
match access-group name RDP
class-map match-any ALL
match any
class-map match-any NETWORK
match ip precedence 6
match ip precedence 7
class-map match-any EF
match ip dscp ef
match ip dscp cs5
class-map match-any AF-HIGH
match ip dscp af41
match ip dscp cs4
class-map match-any AF-MEDHI
match ip dscp af31
match ip dscp cs3
class-map match-any AF-MEDIUM
match ip dscp af21
match ip dscp cs2
class-map match-any AF-LOW
match ip dscp af11
match ip dscp cs1
class-map match-any BE
match ip dscp default
!
!
policy-map setTos
class EF
class REMOTEDESKTOP
set ip dscp af31
class INTERNAL-PRI
set ip dscp af21
class INTERNAL-NONPRI
set ip dscp af11
class class-default
set ip dscp default
policy-map useTos
class EF
priority percent 10
class AF-HIGH
bandwidth remaining percent 35
class AF-MEDHI
bandwidth remaining percent 25
class AF-LOW
bandwidth remaining percent 20
class BE
bandwidth remaining percent 10
class NETWORK
policy-map QOS
class ALL
shape average 4096000
service-policy useTos
!
!
ip access-list standard CUST-DMZ
permit 123.123.123.0 0.0.0.255
!
ip access-list standard CUST-INT-PRI
permit 10.50.0.0 0.0.0.255
permit 10.51.0.0 0.0.0.255
!
ip access-list standard CUST-INT-NOPRI
permit 10.50.10.0 0.0.0.255
permit 10.51.10.0 0.0.0.255
!
ip access-list extended RDP
permit tcp any eq 3389 any
permit tcp any any eq 3389
!
Как видите, это довольно большая конфигурация QoS. Обратите внимание, что мы сами не создавали эту конфигурацию, все было сделано предыдущим сотрудником нашего провайдера IP-VPN. Также обратите внимание, что значение формы изменяется в зависимости от типа соединения (2 Мбит / с, 4 Мбит / с, 8 Мбит / с и 10 Мбит / с).
К настоящему времени вы, вероятно, задаетесь вопросом - что за вопрос здесь? Поехали..
- Как я уже упоминал ранее, мы тонем в жалобах пользователей RDP на то, что задержка / пользовательский ввод не распознается. Разве мы не расставляем приоритеты правильно? Можно ли быть уверенным, что RDP получает минимальные потери пакетов, задержки и джиттер, но все еще ограничен в полосе пропускания?
- Я не вижу никаких упоминаний об очередях в этом конфиге. Я прочитал некоторую документацию Microsoft, и они рекомендуют использовать приоритетную очередь на VoIP и WRED на видео. Как мне это сделать?
- Как показывает конфигурация, ни в одной из классификаций AF не используется среднее или высокое падение. Какие виды услуг безопасно отбросить? RDP, видео и VoIP не работает хорошо с каплями ..
- Полоса с процентами в порядке? Суммирует до 100% использования
Любые другие предложения приветствуются, так как я отчаянно пытаюсь разобраться с этим. Если вы думаете, что слишком много ответов на сайте вопросов и ответов, я просто укушу пыль и найму консультанта у нашего партнера Cisco Gold, что финансово нормально - я просто хочу узнать это, если смогу.
show policy-map interface
,show proc cpu history
,show interface <your-interface-w-QOS-service-policy>
,show buff
иshow runn interface <your-interface-w-QOS-service-policy>
от маршрутизатора и добавить его в нижней части вопроса?Ответы:
Чтобы ответить на ваши вопросы:
show policy-map <your wan interface> output class REMOTEDESKTOP
и проверка на потерянные пакеты.
Cisco назначает очередь каждому определенному пользователем классу, который включает команды полосы пропускания или полиции . Для простоты изложения эти команды определяют полосу пропускания, назначаемую каждой очереди во время перегрузок.
Теоретически каждый поток на основе TCP должен быть в порядке с отбрасыванием. На практике некоторые из них нет. Биты приоритета сброса сообщают маршрутизаторам, какие пакеты следует отбросить в данном классе, прежде чем произойдет перегрузка. Поскольку RDP является единственным типом трафика, определенным в вашем классе REMOTEDESKTOP , вам не следует об этом беспокоиться.
Процент пропускной способности не в порядке (как сказал Джереми).
Тем не менее, есть много вещей, которые я бы изменил в вашей конфигурации:
Нет совпадений между некоторыми классами setTos и картой политик useTos . Например, тот, который называется AF-HIGH, не обрабатывает пакеты, так как ни один класс в setTos не устанавливает DSCP в AF41.
Класс BE в setTos как-то саморазрушителен, поскольку делает класс по умолчанию бесполезным. Обратите внимание, что class-default является единственным определяемым системой классом и получает 25% пропускной способности по умолчанию (100 - max-reserved-bandwidth).
Процент оставшейся полосы пропускания не самый лучший вариант (как объяснил Джереми). Я бы изменил это на процент пропускной способности .
Я бы предпочел помечать пакеты EF самостоятельно, а не полагаться на настройки телефонов.
источник
Первое, что бросается в глаза, это то, что вы, кажется, формируете все до 4 Мбит / с. Я предполагаю, что скорость изменяется на маршрутизаторах / узлах с разными скоростями каналов, но вы, как правило, хотите избежать формирования при работе с чувствительными к задержке приложениями, такими как VoIP и RDP, поскольку это может вызвать чрезмерную буферизацию и дрожание в периоды перегрузки.
Кроме того,
bandwidth remaining percent
команда немного сложна: каждый экземпляр фактически выделяет n% оставшейся доступной полосы пропускания, а не n% от общей. Этот рисунок из статьи Ардена Пакера должен помочь проиллюстрировать идею:Важно отметить, что любые определяемые вами классификации должны соответствовать тому, что поддерживает ваш провайдер WAN. Большинство провайдеров предлагают лишь несколько предварительно настроенных профилей QoS, из которых вы должны выбрать наиболее подходящий для вас. Вы можете классифицировать любой входящий трафик на границе WAN, но контроль QoS провайдера - это то, что контролирует обработку трафика во время транзита через WAN.
источник