Configurazione di Frame Relay Traffic Shaping su router 7200 e piattaforme inferiori

Introduzione

In questo documento viene fornita una configurazione di esempio per il traffic shaping Frame Relay.

Prerequisiti

Requisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

Il traffic shaping Frame Relay è supportato dal software Cisco IOS® versione 11.2.

È supportato sui router Cisco 7200 e sulle piattaforme inferiori. Distributed Traffic Shaping è supportato sui router Cisco 7500, 7600 e sul modulo FlexWAN.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

Le implementazioni comuni del traffic shaping Frame Relay sono:

1. Errori di corrispondenza tra circuiti ad alta velocità e a bassa velocità: Esistono due possibilità:

   • Il sito hub ha una linea T1 nel cloud, mentre il sito remoto ha una velocità inferiore (56 Kbps). In questo caso, è necessario limitare la velocità del sito hub in modo che non superi la velocità di accesso remoto.

   • Il sito hub ha una singola linea T1 nel cloud, mentre i siti remoti hanno anche una linea T1 completa nel cloud, connettendosi allo stesso sito hub. In questo caso, è necessario limitare la velocità dei siti remoti in modo da non sovraccaricare l'hub.

2. Sottoscrizione in eccesso: Ad esempio, se la velocità garantita su un circuito virtuale permanente (PVC) è di 64 Kbps e la velocità di accesso è di 128 Kbps su entrambe le estremità, è possibile superare la velocità garantita quando non vi è congestione e tornare alla velocità garantita in caso di congestione.

3. Quality of Service (QoS): Per implementare le funzionalità di frammentazione FRF.12 o di accodamento a bassa latenza per ottenere una migliore qualità del servizio, vedere VoIP su Frame Relay con Quality of Service.

Nota: la velocità di accesso è la velocità della linea fisica dell'interfaccia che si connette al Frame Relay. La velocità garantita è la velocità CIR (Committed Information Rate) che la Telco ha fornito per il PVC. È consigliabile evitare di impostare CIR o minCIR alla velocità di accesso, in quanto ciò potrebbe causare perdite di output e rallentare il traffico. Il motivo è che la velocità delle forme non tiene conto dei byte di sovraccarico dei campi flag e CRC (Cyclic Redundancy Check). Quindi, plasmare alla velocità della linea in realtà significa sovrascriversi, e causerà una congestione dell'interfaccia. Non è consigliabile utilizzare la velocità di accesso. Il traffico deve essere sempre modellato al 95% della velocità di accesso. Più in generale, la velocità di forma aggregata non dovrebbe essere superiore al 95% della velocità di accesso.

Configurazione

In questa sezione vengono presentate le informazioni necessarie per configurare le funzionalità descritte più avanti nel documento.

Nota: per ulteriori informazioni sui comandi menzionati in questo documento, usare lo strumento di ricerca dei comandi di IOS

Esempio di rete

Nel documento viene usata questa impostazione di rete:

Nell'esempio precedente sono presenti i valori seguenti:

• HUB - velocità di accesso = 192 Kbps, velocità garantita = 32 Kbps

• REMOTE - velocità di accesso = 64 Kbps, velocità garantita = 32 Kbps

In questo caso, stiamo implementando il traffic shaping su entrambe le estremità in modo che la velocità media di trasmissione sia di 64 Kbps. Se necessario, l'HUB può esplodere. In caso di congestione, può scendere al minimo a 32Kbps. La notifica di congestione dal cloud è tramite la notifica di congestione esplicita all'indietro (BECN). Pertanto, la forma è configurata per adattarsi alla BECN.

Nota: il traffic shaping Frame Relay è abilitato sull'interfaccia principale e si applica a tutti gli identificatori di connessione dati (DLCI) sotto quell'interfaccia. Non è possibile abilitare il traffic shaping solo per un particolare DLCI o sottointerfaccia nell'interfaccia principale. Se a un determinato DLCI non è associata alcuna classe di mappa e il traffic shaping è abilitato sull'interfaccia principale, al DLCI viene assegnata una classe di mappa predefinita con CIR = 56000.

Configurazioni

Nel documento vengono usate queste configurazioni:

• Hub

• Remoto

interface Serial0/0 
 no ip address 
 encapsulation frame-relay 
 no fair-queue 
 frame-relay traffic-shaping 

!--- Apply traffic shaping to main interface (step 3).
 
interface Serial0/0.1 point-to-point 
 ip address 10.1.1.1 255.255.255.0 
 frame-relay interface-dlci 16  
 frame-relay class cisco 

!--- Apply map class to the DLCI / subinterface (step 2).
 
! 
! 

!--- Configure map class parameters (step 1).
 
map-class frame-relay cisco 
 frame-relay cir 64000  
 frame-relay mincir 32000 
 frame-relay adaptive-shaping becn 
 frame-relay bc 8000 
 frame-relay be 16000 
!

interface Serial0/0 
no ip address 
encapsulation frame-relay 
no fair-queue 
frame-relay traffic-shaping 
! 
interface Serial0/0.1 point-to-point 
ip address 10.1.1.2 255.255.255.0 
frame-relay interface-dlci 16                            
frame-relay class cisco 
! 
map-class frame-relay cisco 
frame-relay cir 64000 
frame-relay mincir 32000 
frame-relay adaptive-shaping becn 
frame-relay bc 8000 
!

Il diagramma mostra il traffico in uscita dal router HUB:

Supponendo che il traffico venga inviato con un burst di 80000 bit, viene inviato dal PVC in intervalli di 8 Tc (125 msec ciascuno). È possibile ottenere questo risultato perché, nel primo intervallo, il credito disponibile è Bc + Be = 8000 + 16000 = 24000 bit. Ciò significa che la velocità è di 24000 bit / 125 msec = 192 Kbps.

Nei sette intervalli successivi è solo Bc = 8000 bit. Di conseguenza, la velocità è 8000 / 125 msec = 64 Kbps.

Ad esempio, se si riceve una frammentazione di 8800 bit, non sarà possibile inviare tutto il traffico in intervalli di 8 Tc. Gli ultimi 8000 bit verranno inviati al nono intervallo Tc. Pertanto, il traffico viene ritardato dal meccanismo di traffic shaping.

Verifica

Le informazioni contenute in questa sezione permettono di verificare che la configurazione funzioni correttamente.

Comandi show

Alcuni comandi show sono supportati dallo strumento Output Interpreter (solo utenti registrati); lo strumento permette di visualizzare un'analisi dell'output del comando show.

Utilizzare il comando show frame relay pvc <dlci> per visualizzare i dettagli della configurazione:

Hub#show frame relay pvc 16
     PVC Statistics for interface Serial0/0 (Frame Relay DTE)
     DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
       input pkts 8743          output pkts 5            in bytes 2548330
       out bytes 520            dropped pkts 0           in FECN pkts 0
       in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
       in DE pkts 0             out DE pkts 0
       out bcast pkts 0         out bcast bytes 0
       Shaping adapts to BECN
       pvc create time 6d01h, last time pvc status changed 6d01h
       
cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 
      mincir 56000 byte increment 1000 Adaptive Shaping BECN 
      pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 
      shaping inactive 
      traffic shaping drops 0
 
       Queueing strategy: fifo 
       Output queue 0/40, 0 drop, 0 dequeued

shaping inattivo/attivo

Questo comando mostra in tempo reale se il meccanismo di traffic shaping è stato attivato o meno. Il Traffic Shaping è attivo nei seguenti scenari:

1. Vengono ricevuti i BECN e il DLCI è stato configurato per la forma dei BECN.

2. Il numero di byte di dati da trasmettere da un'interfaccia è superiore al credito disponibile (limite di byte) in un dato intervallo (Tc).

3. La frammentazione FRF.12 è stata configurata e i pacchetti sono in attesa di essere frammentati.

pkts ritardati / byte ritardati

Questo comando mostra il numero di pacchetti e byte che sono stati ritardati a causa dell'attivazione del meccanismo di traffic shaping. Ciò si verifica principalmente se il numero di byte da trasmettere supera il credito disponibile per intervallo, o se i pacchetti devono essere frammentati (FRF.12). Questi pacchetti e byte vengono memorizzati nella coda di shaping (allocata per VC) e quindi trasmessi a intervalli successivi quando è disponibile credito sufficiente.

cadute del traffic shaping

Mostra il numero di rilasci nella coda di shaping. I byte vengono prima ritardati dal meccanismo di modellazione e memorizzati in questa coda. Se la coda è piena, i pacchetti vengono scartati. Per impostazione predefinita, la coda è di tipo FCFS (First Come First Server) o FIFO, ma può essere modificata in WFQ, PQ, CQ, CBWFQ o LLQ. Vedere le informazioni correlate