(Перш за все, мені шкода цієї стіни тексту. Я не знаю, як скоротити її, не втрачаючи важливої інформації. Спочатку я хотів використовувати для цього чат, як це робимо на сервері за замовчуванням для подібного роду питань, але в кімнаті з інженерної мережі немає нікого).
Ми є корпорацією з кількома дочірніми компаніями, де у нас досить великий керований 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 у нашому штаб-квартирі (2х100 Мбіт волокна). Пропускну здатність, яка використовується для 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>від маршрутизатора і додати його в нижній частині питання?