QoS guai - VPN IP gestita

(Prima di tutto, mi dispiace per questo muro di testo. Non so come accorciarlo senza perdere informazioni importanti. Inizialmente volevo usare la chat room per questo, come facciamo su serverfault per questo tipo di domande, ma non c'è nessuno nella stanza di ingegneria della rete).

Siamo una società con diverse società figlie, dove abbiamo una IP-VPN gestita piuttosto grande con circa 70 posizioni diverse, che vanno da SHDSL da 2 Mbps a fibra da 100 Mbps. L'IP-VPN trasporta più VPN (o tunnel per l'esattezza).

La priorità del traffico è questa, dal punto di vista gestionale e progettuale:

1. VoIP (Avaya e Lync)
2. Video (Lync)
3. RDP
4. Servizi interni (fileserver, Active Directory, intranet ecc.)
5. Servizi interni senza priorità (server proxy per l'utilizzo di Internet, servizi di aggiornamento di Windows, gestione della configurazione del centro di sistema, proxy di aggiornamento antivirus ecc.)
6. Il traffico non abbinato (internet)

Il VoIP viene utilizzato solo in determinati uffici, dove c'è un basso numero di utenti. Il più grande ufficio remoto che utilizza VoIP in questo momento ha uno SHDSL da 4 Mbps con 5 dipendenti e 5 telefoni IP avaya che eseguono il codec G.711 ALAW 64K. Ciò non dovrebbe mai portare il traffico di dati voip a più di 320kbps. Ho verificato che i telefoni utilizzano DSCP 46 per l'audio ed è quindi correttamente abbinato come EF (vedere la configurazione seguente). La segnalazione tuttavia è abbinata a DSCP 24, che non sono sicuro se il nostro profilo QoS acquisisce.

Tutte le sedi remote utilizzano RDP nei confronti di diverse farm RDS nel nostro quartier generale (fibra 2x100Mbit). La larghezza di banda utilizzata per RDP non è così facile da capire, poiché utilizza fondamentalmente tutto ciò che ottiene. Abbiamo alcune limitazioni impostate per assicurarci che non sia troppo affamato di risorse, ma che probabilmente non rientra nell'ambito di questo sito. Recentemente abbiamo alcuni problemi piuttosto gravi con RDP ( /server/515809/mouse-cursor-jumps-around-when-using-rdp ), motivo per cui sto pubblicando questo sull'ingegneria di rete.

Lync utilizza DSCP 46 per l'audio e DSCP 34 per il video. I servizi interni e i servizi interni non prioritari sono appena abbinati alle sottoreti e tutto il resto è semplicemente uguale a qualsiasi.

Ecco una copia dell'ultima revisione della configurazione QoS, che ho leggermente modificato per nascondere determinati nomi e indirizzi 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
!

Come puoi vedere, è una configurazione QoS piuttosto grande. Nota che non abbiamo creato questa configurazione per noi stessi, è stato fatto tutto da un precedente dipendente del nostro provider IP-VPN. Si noti inoltre che il valore della forma viene modificato in base al tipo di connessione (2 Mbps, 4 Mbps, 8 Mbps e 10 Mbps).

Ormai probabilmente ti starai chiedendo: qual è la domanda qui? Ecco qui..

1. Come ho accennato in precedenza, stiamo annegando nei reclami degli utenti RDP sul fatto che l'input di ritardo / utente non sia stato riconosciuto. Non stiamo assegnando le priorità correttamente? È possibile assicurarsi che RDP ottenga una quantità minima di perdita di pacchetti, latenza e jitter, ma che sia ancora limitata in banda con?
2. Non vedo alcuna menzione delle code in questa configurazione. Ho letto un po 'di documentazione Microsoft e mi consigliano di utilizzare la coda prioritaria su VoIP e WRED su video. Come posso farlo accadere?
3. Come mostra la configurazione, nessuna delle classificazioni AF usa la caduta media o alta. Che tipo di servizi è sicuro di abbandonare? RDP, video e voip non funzionano bene con le gocce ..
4. Le percentuali di banda sono in ordine? Riassume fino al 100% di utilizzo

Qualsiasi altro suggerimento / i sono i benvenuti, in quanto sono disperato di ottenere questo risolto. Se pensi che sia troppo rispondere a un sito di domande e risposte, mi limiterò a mordere la polvere e assumerò un consulente dal nostro partner Cisco Gold, che è finanziariamente OK - Voglio solo imparare questo se posso.

Per rispondere alle tue domande:

• Il traffico RDP dovrebbe arrivare fino al 25% della larghezza di banda rimanente. Dove la larghezza di banda già prenotata è il 35% (l' impostazione predefinita di classe ottiene il 25% per impostazione predefinita e EF ottiene il 10%). Quindi, se ho ragione, hai assegnato ~ 665Kbps a RDP. Ad ogni modo, dovresti verificare se stai rilasciando i pacchetti che eseguono il comando seguente:

show policy-map <your wan interface> output class REMOTEDESKTOP

e verifica la presenza di pacchetti persi.

• Cisco assegna una coda a ciascuna classe definita dall'utente che include la larghezza di banda o i comandi di polizia . Per rendere semplice una lunga storia, questi comandi definiscono la quantità di larghezza di banda assegnata a ogni coda durante le congestioni.

• In teoria ogni stream basato su TCP dovrebbe essere OK con drop. In pratica alcuni di loro non lo sono. La caduta di bit di precedenza indica ai router quali pacchetti devono essere rilasciati, all'interno di una determinata classe, prima che si verifichi la congestione. Poiché RDP è l'unico tipo di traffico definito nella classe REMOTEDESKTOP , non dovresti preoccuparti.

• La percentuale di larghezza di banda non è in ordine (come affermato da Jeremy).

Detto questo, ci sono molte cose che vorrei cambiare nella tua configurazione:

• Non ci sono corrispondenze tra alcune delle classi di setTos e la mappa delle politiche useTos . Ad esempio, quello denominato AF-HIGH non sta elaborando pacchetti poiché nessuna classe in setTos imposta DSCP su AF41.

• La classe BE in setTos è in qualche modo autolesionista poiché rende inutile la classe predefinita di classe. Si noti che la classe predefinita è l'unica classe definita dal sistema e ottiene il 25% della larghezza di banda per impostazione predefinita (100 - larghezza di banda massima riservata).

• la percentuale di larghezza di banda rimanente non è la migliore opzione (come spiegato da Jeremy). Lo cambierei in percentuale di larghezza di banda .

• Preferirei contrassegnare i pacchetti EF da solo e non fare affidamento sulle impostazioni dei telefoni.

La prima cosa che mi salta fuori è che sembri modellare tutto a 4 Mbps. Immagino che la velocità cambi su router / siti con diverse velocità del circuito, ma in genere si desidera evitare la modellatura quando si ha a che fare con applicazioni sensibili alla latenza come VoIP e RDP in quanto può causare buffering e jitter eccessivi durante i periodi di congestione.

Inoltre, il bandwidth remaining percentcomando è un po 'complicato: ogni istanza alloca effettivamente n% della larghezza di banda disponibile rimanente, non n% del totale. Questa grafica di un articolo di Arden Packeer dovrebbe aiutare a illustrare l'idea:

È importante notare che qualsiasi classificazione definita deve corrispondere a ciò che supporta il provider WAN. La maggior parte dei provider offre solo una manciata di profili QoS preconfigurati da cui è necessario scegliere quale si adatta meglio alle proprie esigenze. Puoi classificare come preferisci sul traffico in entrata sul lato WAN, ma i controlli QoS del provider sono ciò che controlla il trattamento del traffico durante il transito attraverso la WAN.