In questo documento viene spiegato come i messaggi del protocollo di routing, ad esempio helper e descrittori del database, nonché altri importanti dati di controllo del traffico, vengano accodati quando un'interfaccia del router in uscita viene configurata con una policy di servizio utilizzando i comandi dell'interfaccia della riga di comando (MQC) modulare quality of service.
In particolare, questo documento esamina i due meccanismi usati dai router Cisco IOS® per assegnare la priorità ai pacchetti di controllo:
Campo | Posizione | In cui si considera la priorità |
---|---|---|
Bit di precedenza IP | Byte TOS (Type of service) nell'intestazione IP | Assegna priorità tramite la rete |
priorità_pak | Etichetta del pacchetto interno al router, assegnata dal driver di interfaccia | Assegna priorità tramite il router (per hop) |
Entrambi i meccanismi sono progettati per garantire che i pacchetti di controllo della chiave non vengano scartati per ultimi dal router e dal sistema di coda quando un'interfaccia in uscita è congestionata.
Nessun requisito specifico previsto per questo documento.
Il riferimento delle informazioni contenute in questo documento è il software Cisco IOS versione 12.2.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
La RFC (Request for Comments) 791 definisce il byte TOS nell'intestazione di un pacchetto IP. Sebbene la RFC 2474 e la RFC 2475 ridefiniscano questo byte come valori DSCP (Differentiated Services Code Point), un router Cisco IOS utilizza ancora i bit di precedenza IP originali del byte TOS, come mostrato nella RFC 791. Si noti come la RFC definisca il byte TOS:
"Il tipo di servizio fornisce un'indicazione dei parametri astratti della qualità del servizio desiderato. Questi parametri devono essere utilizzati per guidare la selezione dei parametri effettivi del servizio durante la trasmissione di un datagramma attraverso una particolare rete. Diverse reti offrono la precedenza dei servizi, che in qualche modo considera il traffico con precedenza elevata più importante di altro traffico (generalmente accettando solo il traffico che supera una certa precedenza in momenti di carico elevato)."
Come mostrato nel diagramma, il campo IP Precence occupa i tre bit più significativi del byte TOS. Solo i tre bit di precedenza IP riflettono la priorità o l'importanza del pacchetto, non il valore completo del byte TOS.
In questa tabella vengono elencati i valori dei bit di precedenza:
Numero | Valore bit | Nome |
---|---|---|
0 | 000 | Routine |
1 | 001 | Priority |
2 | 010 | Immediato |
3 | 011 | Flash |
4 | 100 | Sostituzione Flash |
5 | 101 | CRITICO/ECP |
6 | 110 | Controllo Internetwork |
7 | 111 | Controllo della rete |
Cisco IOS assegna una precedenza IP di 6 ai pacchetti del protocollo di routing sul control plane. Come indicato nella RFC 791, "La designazione Controllo interrete è destinata all'utilizzo esclusivo da parte dei creatori di controlli gateway". In particolare, Cisco IOS contrassegna i seguenti pacchetti di controllo basati su IP: Open Shortest Path First (OSPF), Routing Information Protocol (RIP), hellos Enhanced Interior Gateway Routing Protocol (EIGRP) e keepalive. I pacchetti Telnet da e verso il router ricevono anche un valore di precedenza IP pari a 6. Il valore assegnato rimane tra i pacchetti quando l'interfaccia di output li trasmette nella rete.
Mentre il valore di precedenza IP specifica il trattamento di un datagramma nella trasmissione attraverso la rete, il meccanismo pak_priority specifica il trattamento di un pacchetto durante la trasmissione all'interno del router.
Oltre al core della CPU di un router, ogni interfaccia utilizza un controller di rete o una CPU locale, che esegue un software speciale denominato driver. Il codice del driver fornisce istruzioni specifiche dell'interfaccia.
Quando riceve un pacchetto, il driver di interfaccia lo copia da un piccolo buffer FIFO (First-In, First-Out) in un buffer di dati in memoria di input/output (I/O). Infine, collega una piccola intestazione al buffer. L'intestazione del pacchetto, indicata nella terminologia Cisco IOS come struttura del tipo di pacchetto, contiene informazioni chiave sul blocco di dati nel buffer. A seconda del contenuto del pacchetto, l'intestazione può puntare all'indirizzo in memoria dove iniziano l'intestazione Ethernet encapsulation, l'intestazione IP (Internet Protocol) e l'intestazione TCP (Transmission Control Protocol).
Il software Cisco IOS utilizza i campi nell'intestazione del pacchetto per controllare il trattamento del pacchetto nelle code dell'interfaccia. L'intestazione del pacchetto include il flag pak_priority che indica l'importanza relativa dei pacchetti contrassegnati per il sistema di coda.
I processi di routing RIP e OSPF in esecuzione sulla CPU principale di un router contrassegnano tutto il traffico che hanno origine sia con IP precedence 6 che con pak_priority. Al contrario, il Border Gateway Protocol (BGP) ordina al TCP di contrassegnare il traffico con IP precedence 6, ma non imposta pak_priority.
Cisco IOS deve anche garantire una bassa probabilità di perdita per diversi tipi di pacchetti non IP. I tipi di pacchetto includono:
Messaggi del protocollo di routing IS-IS (Intermediate System-to-Intermediate System)
Messaggi EIGRP (Enhanced Interior Gateway routing protocol)
Mantenimento dei pacchetti keepalive PPP (Point-to-Point Protocol) e HDLC (High-Level Data Link Control) su interfacce seriali e POS (Packet over SONET)
Celle Operazioni, amministrazione e manutenzione (OAM) e messaggi ARP (Address Resolution Protocol) sulle interfacce ATM
Poiché tale traffico non è IP, Cisco IOS non può corrispondere al valore di precedenza IP per fornire la definizione di priorità. ma utilizza solo il valore pak_priority interno nell'intestazione del buffer del pacchetto.
Nota: Cisco Catalyst serie 6000 / Cisco 7600 inizialmente supportava il meccanismo pak_priority solo sulla FlexWAN. Successivamente sono stati implementati miglioramenti nella definizione delle priorità dei pacchetti di controllo IP e non IP.
I router come Cisco 7500 Route/Switch Processor (RSP) e i router di fascia inferiore (come Cisco serie 7200 e 3600) utilizzano un meccanismo diverso per indirizzare e controllare il traffico rispetto al Cisco 7500 Versatile Interface Processor (VIP). In questa tabella vengono riepilogati i due approcci e si presume che all'interfaccia in uscita sia applicato un criterio dei servizi configurato con MQC.
Piattaforma | Accodamento dei messaggi pak_priority |
---|---|
Cisco serie 7500 (con QoS e VIP distribuiti) |
|
QoS basato su RSP e altre piattaforme, tra cui Cisco serie 7200, 3600, 2600 |
|
In altre parole, se su Cisco serie 7500 all'interfaccia è collegata una policy del servizio di output, i pacchetti vengono classificati in base alle classi incluse nella policy e il pacchetto pak_priority viene posizionato alla fine della coda delle classi scelta. Se il pacchetto pak_priority non corrisponde ad alcuna classe definita dall'utente, viene posizionato alla fine della coda classe-default.
Nota: con i metodi di accodamento legacy, ad esempio l'accodamento delle priorità e l'accodamento personalizzato, o con una coda FIFO dell'interfaccia predefinita, i router non RSP accodano i messaggi pak_priority all'inizio della coda per garantire sia una latenza minima che una probabilità di perdita minima.
Come indicato nella tabella Packet Prioritization Tags and Queuing, le piattaforme dei router Cisco come le serie 7200, 3600 e 2600 inseriscono i messaggi pak_priority in un set separato di code e non nel set di code predefinito della classe.
Su un'interfaccia sono disponibili tre set di code:
2^n serie di code basate sul flusso che considerano i valori di intestazione come gli indirizzi IP di origine e di destinazione. Il numero effettivo di code si basa sulla larghezza di banda dell'interfaccia o del circuito virtuale. Fare riferimento alla descrizione del comando fair-queue nella guida di riferimento dei comandi di Cisco IOS.
Code per le classi create dall'utente.
Code a cui è stato eseguito l'accesso sulla base di un hash del tipo di collegamento. Ad esempio, i microflussi IP vengono classificati dal sistema di coda Fair in code basate su un hash degli indirizzi e delle porte di origine e di destinazione, sui bit TOS e sul numero di protocollo IP. I messaggi LMI (Frame Relay Local Management Interface) vengono accodati in base a un hash del numero chiave che indica che il messaggio è LMI. I messaggi con il flag pak_priority vengono inseriti in queste code separate del tipo di collegamento.
In questa tabella vengono elencate le diverse code e i relativi ID di conversazione (come mostrato nell'output dell'interfaccia show policy-map o nei comandi show queue) per un'interfaccia con larghezza di banda superiore a 512 Kbps.
Conversazione/Numero coda | Tipo di traffico |
---|---|
1 - 256 | Code di traffico generali basate sul flusso. Il traffico che non corrisponde a una classe creata dall'utente corrisponde alla classe predefinita e a una delle code basate sul flusso. |
257 - 263 | Riservato per il protocollo Cisco Discovery e per i pacchetti contrassegnati con un flag interno ad alta priorità. |
264 | Coda riservata per la classe di priorità (classi configurate con il comando priority). Cercare il valore "Strict Priority" per la classe nell'output dell'interfaccia show policy-map. La coda di priorità utilizza un ID conversazione uguale al numero di code dinamiche più 8. |
265 e superiore | Code per le classi create dall'utente. |
Nota: i valori riportati in questa tabella dipendono dall'implementazione e sono soggetti a modifica.
I pacchetti di controllo del routing IS-IS (Intermediate System to Intermediate System) rappresentano un caso speciale in relazione all'accodamento e all'assegnazione di priorità ai pacchetti.
IS-IS è il protocollo di routing per il protocollo CLNP (Connectionless Network Protocol) dell'ISO (International Organization for Standardization). Gli sviluppatori di CLNP hanno considerato TCP/IP come una suite di protocolli provvisori che la suite OSI (Open System Interconnection) avrebbe infine sostituito. Per supportare questa transizione prevista, è stato creato IS-IS integrato (o IS-IS doppio) come estensione di IS-IS per fornire un singolo protocollo di routing in grado di instradare sia il servizio CLNS (Connectionless-Mode Network Service) che l'IP. Il protocollo è stato progettato per funzionare in un ambiente CLNS puro, IP puro o duplice CLNS/IP.
Anche quando IS-IS viene utilizzato per instradare solo TCP/IP, IS-IS è ancora un protocollo CLNP ISO. I pacchetti con cui IS-IS comunica con i peer sono PDU (Protocol Data Unit) CLNS, il che a sua volta significa che anche in un ambiente solo IP, il sistema di coda e Cisco IOS non possono utilizzare la precedenza IP per assegnare la priorità ai messaggi di controllo CLNS. Al contrario, i pacchetti IS-IS hanno priorità tramite il meccanismo pak_priority all'interno del router.
In questa sezione vengono illustrati tre approcci generali alla progettazione di una strategia di coda per ridurre al minimo le possibilità che i pacchetti di controllo vengano scartati in condizioni di congestione grave sui Cisco serie 7500 e sui VIP. Per impostazione predefinita, le piattaforme non RSP inseriscono i pacchetti di controllo in code separate.
Strategia | Scenari d'uso | Descrizione della configurazione |
---|---|---|
Associa a una coda separata. | La strategia più conservativa. Assicura che non vi siano cadute. | Usare la CLI QoS modulare per configurare una classe separata e usare il comando bandwidth per assegnare un'allocazione minima della larghezza di banda al traffico corrispondente durante i periodi di congestione. Una classe configurata con il comando bandwidth utilizza un "peso" di pianificazione basato sulla larghezza di banda e non sulla precedenza IP. Fare riferimento alla sezione sulla descrizione di Class Based Weighted Fair Queuing su ATM. |
Corrispondenza con l'impostazione predefinita della classe con l'accodamento corretto. | Sufficiente per la maggior parte delle configurazioni. Alcuni pacchetti di controllo possono essere scartati in presenza di congestione. | Usare la priorità IP 6 assegnata automaticamente da Cisco IOS al pacchetto per influenzarne il peso e quindi la quota di larghezza di banda. Vedere Informazioni su Weighted Fair Queuing su ATM. |
Corrispondenza con class-default con l'accodamento FIFO. | Non consigliato per collegamenti congestionati. Alcuni pacchetti di controllo possono essere scartati in presenza di congestione. | Questo approccio non considera la precedenza IP. Con la funzionalità QoS basata su VIP, i messaggi pak_priority vengono accodati all'estremità finale della coda FIFO. |
Questo è un esempio di come creare una coda separata per i pacchetti di controllo RIP.
class-map match-all rp match access-group 104 ! access-list 104 permit udp any eq rip any eq rip !--- Create a class-map that matches an ACL permitting RIP. ! policy-map bandwidth class voip priority 64 class bus bandwidth 184 class RP bandwidth 8 !--- Create a policy-map (named "bandwidth") and specify !--- class RP. ! interface Serial1/0:0.1 point-to-point bandwidth 256 ip unnumbered Loopback0 ip accounting precedence input no cdp enable frame-relay class sample frame-relay interface-dlci 100 IETF !--- Apply the map-class named "sample" to the PVC. ! map-class frame-relay sample frame-relay cir 256000 frame-relay bc 2560 frame-relay mincir 256000 no frame-relay adaptive-shaping service-policy output bandwidth frame-relay fragment 160 !--- Create a frame relay map-class and apply the service !--- policy inside the map-class.
Quando si sceglie uno di questi approcci, tenere presenti i fattori seguenti:
Il particolare protocollo di routing utilizzato e i valori del timer configurati per hellos e aggiornamento database
La dimensione del database da scambiare e se vengono aggiornati periodicamente solo gli aggiornamenti/le modifiche o le tabelle complete
Quantità di congestione prevista all'interfaccia o al circuito virtuale
In altre parole, considerate le possibilità di mettere in coda pacchetti con priorità alta in presenza di congestione.
Il traffico generato dal router rappresenta un caso speciale per i criteri del servizio QoS in uscita. Parte del traffico generato localmente deve essere trattato come qualsiasi altro traffico utente e il sistema QoS deve applicare i meccanismi QoS configurati a questo traffico. Un esempio di tale traffico sono le richieste di prestazioni progettate per misurare il comportamento dei pacchetti di una determinata classe. Il resto del traffico generato localmente, in particolare i messaggi del protocollo di routing e i pacchetti keepalive di layer 2, sono essenziali per il funzionamento base del router e non devono essere soggetti ad alcune funzionalità QoS. Ad esempio, WRED (Weighted Random Early Detection) non deve eliminare i pacchetti keepalive di layer 2 quando la profondità media della coda raggiunge un limite massimo
Inoltre, i pacchetti destinati al router devono essere gestiti attentamente. Ad esempio, tenere presente che un criterio dei servizi che applica il policing basato su classi non deve essere applicato ai pacchetti destinati al router per evitare di eliminare importanti messaggi di controllo.
Nota: In base alla progettazione, i pacchetti generati dal protocollo RP non vengono considerati nei contatori CLI QoS modulari anche se sono classificati/accodati correttamente. Questi pacchetti non vengono considerati nell'output del comando show policy-map interface.
In questa tabella viene mostrato come i pacchetti destinati a e provenienti dal router interagiscono con le funzionalità QoS principali.
Funzione QoS | Descrizione |
---|---|
Contrassegno basato su classi |
|
Traffic policing |
|
Quando si esegue Cisco IOS sul supervisor e sull'MSFC (MultiLayer Switch Feature Card) di Catalyst 6000, l'RP contrassegna i pacchetti di controllo del routing con la precedenza IP 6. Questo valore di nota può essere utilizzato con la programmazione dell'output per mappare i pacchetti di controllo del routing alla coda alta, soglia alta nel sistema WRR (Weighted Round Robin). Questa mappatura dei pacchetti di controllo del routing inviati dall'MSFC viene eseguita automaticamente se QoS è abilitato a livello globale con il comando mls qos. Se si abilita QoS, il sistema imposta tutti i parametri di accodamento, quali soglie di perdita WRED, larghezze di banda WRR e limiti di coda. Se QoS è disabilitato a livello globale, tutti i pacchetti vengono mappati sulla coda bassa, una soglia bassa per la pianificazione dell'output, del WRR.
Come indicato nel capitolo Configurazione di QoS della Guida alla configurazione di Catalyst 6000, QoS supporta la classificazione, la contrassegno, la pianificazione e la prevenzione delle congestioni utilizzando i valori CoS (Class of Service) di layer 2 sulle porte di entrata Ethernet. Le operazioni di classificazione, contrassegno, pianificazione e prevenzione delle congestioni sulle porte di entrata Ethernet non utilizzano o impostano la precedenza IP o i valori DSCP del layer 3. Inoltre, con qualsiasi motore di switching, QoS supporta la pianificazione delle porte di uscita Ethernet e la prevenzione delle congestioni con i valori CoS di layer 2. Di conseguenza, i pacchetti IP e non IP cruciali devono essere mappati su un valore CoS, anche se tali valori vengono usati solo internamente come parte dell'intestazione del bus dati. I pacchetti IP cruciali hanno un valore di precedenza IP pari a 6 associato a un valore CoS equivalente di 6. I pacchetti non IP cruciali, che includono pacchetti IS-IS provenienti dall'MSFC, sono contrassegnati con il flag pak_priority e quindi i pacchetti contrassegnati vengono mappati su un valore CoS pari a 6. Questo mapping viene eseguito automaticamente nelle versioni Cisco IOS correnti.
I policer in entrata e in uscita non contrassegnano i pacchetti provenienti dall'MSFC e destinati alla trasmissione tramite un'interfaccia Ethernet fisica.
La configurazione QoS su Catalyst 6000 non rientra nell'ambito di questo documento. Per ulteriori informazioni, fare riferimento a Configurazione di QoS e alla pagina di supporto degli switch Catalyst LAN e ATM.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
15-Feb-2008 |
Versione iniziale |