In questo documento vengono descritte le opzioni QoS (Quality of Service) per ambienti PPPoE (Point-to-Point Protocol over Ethernet) e DSL (Digital Subscriber Line). Dopo aver letto questo documento, sarà possibile comprendere le funzionalità QoS supportate sulle interfacce PPPoE e le versioni software Cisco IOS® richieste.
Questo documento è utile per conoscere i seguenti argomenti:
MQC (Modular QoS Command-Line Interface): per ulteriori informazioni, fare riferimento a Interfaccia della riga di comando Modular Quality of Service.
PPPoE: per ulteriori informazioni sul PPPoE, fare riferimento a PPPoE Baseline Architecture for the Cisco UAC 6400.
Il documento può essere consultato per tutte le versioni software o hardware.
Quando i clienti implementano la tecnologia ADSL (Asymmetric DSL), devono supportare l'autenticazione e l'autorizzazione nello stile PPP su una vasta base installata di apparecchiature CPE (Customer Premise Equipment) di bridging preesistenti. PPPoE consente di connettere una rete di host tramite un semplice dispositivo di accesso di bridging a un concentratore di accesso remoto o di aggregazione. Con questo modello, ciascun host utilizza il proprio stack PPP. In questo modo l'utente dispone di un'interfaccia utente familiare. Il controllo degli accessi, la fatturazione e il tipo di servizio possono essere eseguiti per singolo utente anziché per singolo sito.
PPPoE crea innanzitutto una sessione PPP. Queste sessioni sono avviate dal software client PPPoE, ad esempio Router, sul PC o dalla funzionalità client su un router Cisco IOS. Ad esempio, il software Cisco IOS versione 12.1(3)XG ha introdotto una funzionalità client PPPoE per Cisco SOHO77. In questo caso, è possibile installare più PC dietro Cisco SOHO77 e, prima di inviare il traffico alla sessione PPPoE, è possibile crittografarlo, filtrarlo e eseguire Network Address Translation (NAT). Per ulteriori informazioni, fare riferimento a Configurazione di un router Cisco SOHO77 come client PPPoE con NAT.
Dopo aver stabilito una sessione PPP, sia l'host o il client che il concentratore di accesso terminante allocano le risorse per un'interfaccia di accesso virtuale PPP.
Quando si configura un criterio del servizio QoS che applica code avanzate, ad esempio CBWFQ (Class-Based Weighted Fair Queueing) o LLQ (Low Latency Queueing), in un ambiente PPPoE, tenere presente le seguenti restrizioni:
Se il router esegue il software client o server PPPoE, le interfacce di accesso virtuale e modello virtuale non supportano un criterio di servizio che implementa le code per sessione. Tuttavia, è possibile applicare a un'interfaccia Virtual-Template o a un'interfaccia dialer un criterio di servizio che applichi funzionalità QoS diverse dalla coda. Le funzionalità MQC funzionano in base alla sessione.
Se il router ha un'interfaccia DSL configurata per i circuiti virtuali (VC) con routing RFC 1483 tramite la rete DSL ATM e il singolo VC contiene più sessioni PPPoE iniziate dai PC, i meccanismi standard di coda e backpression per VC funzionano nel software Cisco IOS versione 12.2(4)T e 12.2(4) e successive. Queste versioni supportano sofisticati meccanismi di coda e classificazione dei pacchetti sulle interfacce di accesso virtuale che utilizzano l'incapsulamento PPP.
Se l'interfaccia di uscita rivolta verso la rete DSL è una porta Ethernet che si connette a un modem DSL, è possibile implementare un criterio gerarchico in base al quale viene definita una velocità al livello padre che corrisponde alla velocità a monte del modem DSL e quindi la coda a un livello di criterio figlio. A tale scopo, è necessario utilizzare il software Cisco IOS versione 12.2(4)T e 12.2(4) o successive.
Il software Cisco IOS versione 12.2(4)T ha introdotto il supporto per un client PPPoE su Cisco serie 2600. Tuttavia, le interfacce DSL non supportano i criteri dei servizi che applicano le code complesse, in quanto queste interfacce non implementano l'"algoritmo di contropressione" necessario per segnalare che i pacchetti in eccesso devono essere accodati dal sistema di coda di layer 3 (L3). Tuttavia, se ci si connette a un modem DSL utilizzando una normale porta Ethernet, è possibile implementare la coda quando si configura un criterio gerarchico che si forma al livello padre e quindi applicare un criterio figlio che accoda e, facoltativamente, implementa LLQ. L'uplink DSL è molto più lento dell'interfaccia Ethernet, quindi Ethernet deve corrispondere alla velocità DSL e subire effettivamente la congestione, quindi i meccanismi di coda si applicano all'eccesso memorizzato nel buffer.
Quando il protocollo PPPoE viene eseguito su un'interfaccia ATM, prendere in considerazione una di queste opzioni per ottenere la qualità del servizio della voce in ambienti DSL. Queste opzioni presuppongono che il meccanismo di contropressione per segnalare la congestione venga utilizzato dai sistemi VC. La fornitura di QoS per la voce si basa sulla capacità del router di propagare correttamente lo stato di congestione di un sistema VC permanente (PVC) all'accodamento di layer 3.
Configurare i PVC indirizzati RFC 1483 con l'ottimizzazione degli anelli di trasmissione sul VC quando un criterio del servizio applica LLQ.
Configurare VC distinti, ad esempio una VC con velocità bit variabile in tempo non reale (VBR-nrt) per la voce e una VC con velocità bit non specificata (UBR) per i dati.
Configurare i bundle PVC, che sono VC paralleli separati tra gli stessi due router. Ogni VC dispone di una serie univoca di valori di IP Presence e viene in genere assegnata a una categoria di servizi ATM univoca, ad esempio VBR-nrt. Per ulteriori informazioni, fare riferimento a IP to ATM CoS su un elenco di attività di configurazione del bundle ATM.
Configurare la frammentazione e l'interfoliazione del collegamento per Frame Relay e i circuiti virtuali ATM, in cui i pacchetti di grandi dimensioni vengono segmentati e interlacciati usando il meccanismo di frammentazione di MLPPP. Configurare anche LLQ e applicare la sintonizzazione del ring di trasmissione. Insieme ai pool di interfacce pubbliche e private, Cisco IOS crea speciali strutture di controllo del buffer chiamate anelli. Quando si trasportano pacchetti VoIP, è importante sintonizzare la ghiera di trasmissione, che supporta solo la coda FIFO (First In, First Out), e spingere tutte le code alla coda di attesa di layer 3, dove si applicano meccanismi di coda sofisticati e criteri del servizio. per ulteriori informazioni, fare riferimento a Comprensione e tuning del valore limite di anello tx.
In questa configurazione di esempio vengono illustrati i comandi necessari per configurare CBWFQ o LLQ in un ambiente PPPoE.
Di seguito è illustrato un tipico design di questo ambiente. Nell'esempio, la rete DSL trasporta il protocollo Voice over IP (VoIP).
È possibile applicare una mappa gerarchica dei criteri (vedere la configurazione PPPoE) all'interfaccia Ethernet in cui PPPoE è abilitato. Assicuratevi di configurare la velocità corretta per la modellazione. Ad esempio, nell'ambiente DSL, se il limite upstream è 128 kbps, è necessario modellare a 128 kbps.
Un criterio gerarchico tipico utilizza solo valori predefiniti di classe nel criterio padre, poiché l'obiettivo del criterio padre è creare un flusso con larghezza di banda limitata e non ordinare il traffico in classi. Il criterio figlio specifica più classi di traffico e i comandi priority e/o bandwidth per implementare rispettivamente LLQ e CBWFQ.
PPPoE |
---|
policymap parent_shaping class class-default shape average {speed} service-policy child_queueing policymap child_queueing class c1 priority Y class c2 bandwidth X interface ethernet 1/0 pppoe enable service-policy output parent_shaping |
È possibile applicare una mappa delle policy con CBWFQ e LLQ (vedere la configurazione di PPPoE over ATM VC) al PVC ATM in cui è configurato PPPoE.
PPPoE over ATM VC |
---|
policymap P2 class c1 priority Y class c2 bandwidth X interface ATM0/0/0.132 point-to-point pvc 1/32 vbr-nrt 2000 2000 encapsulation aal5snap protocol pppoe service-policy output P2 |
Sul software Cisco IOS versione 12.2(4)B1 della serie 7200 a banda larga è stato introdotto il supporto per la limitazione della velocità sul profilo utente RADIUS applicato all'interfaccia di accesso virtuale in un ambiente PPPoE. Viene fornita una configurazione di esempio:
shashi@pepsi.com Password = "cisco" Service-Type = Framed, Framed-Protocol = PPP, Framed-MTU = 1400, Framed-Routing = 1 Cisco-Avpair = "lcp:interface-config=rate-limit output access-group 101 64000 16000 32000 conform-action transmit exceed-action drop", interface Virtual-Access2 mtu 1492 ip unnumbered Loopback1 rate-limit output access-group 101 64000 16000 32000 conform-action transmit exceed-action drop
È inoltre possibile utilizzare il criterio basato su classi per eseguire questa configurazione e associare un criterio del servizio QoS al modello virtuale.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
15-Feb-2008 |
Versione iniziale |