Newsgroup: it.comp.reti.cisco
Titolo: QoS priorità a protocollo

Ciao a tutti,
posso dire ad un router cisco 12.4(22)T 877-k9 che un servizio ha una 
prioritï¿œ inferiore a tutto il resto?
mi piego: ho un software che fa molto traffico e quando l'interfaccia 
dialer0 va in congestione vorrei il router desse meno prioritï¿œ a questo 
software che utilizza la porta 2345.
online ho trovato una tonnellata di guide su come dare band reservation 
al voip, ma mai su come privare di prioritï¿œ un servizio.
Si puï¿œ

 Si puï¿œ?
Scusa, mi sfuge qualcosa nel ragionamento..... proviamo a ricapitolare 
un *riassuntissimo* di come funziona lo "standard" del qos cisco:
  -hai (in genere) 3 code: gold, silver, bronze
  -tutto cio' che non hai inserito in queste 3 code va nella coda di default
la coda di default e' la meno prioritaria se la linea e' in congestione 
percio' se tu metti tutto il traffico che in interessa nelle code 
precedenti lasci che l'applicazione che ti interessa cada 
automaticamente nella coda di default con la percentuale piu' bassa di 
traffico a disposizione (per altro definita da te questa percentuale)....
Inoltre, ma qui non vorrei dire una cavolata e mi aspetto conferme o 
smentite da chi ne sa piu' di me, credo tu possa creare anche solo 2 
code percio' lasci tutto nella coda principale e solo la tua 
applicazione nella coda di default e hai risolto il problema (anche se 
mi sembra un utilizzo del qos un po' limitato.... cmq ogni figlio e' 
bello a mamma sua percio'....)
No ? Mi e' sfuggito qualcosa ?
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra 
facile a prima vista...ma la veritï¿œ ï¿œ che non avere nulla da perdere 
significa essere pronti a rischiare tutto ciï¿œ che si possiede.

 traffico a disposizione (per altro definita da te questa percentuale)....
ok quindi in sostanza piï¿œ che "sminuire" un traffico dovrei "aumentare 
di prioritï¿œ" tutto il resto, giusto?
lo faccio mediante
policy-map match-any ALTO
match protocol http
match etc etc
perï¿œ non trovo protocol http...
cosa mi sfugge?

writethem ha scritto:

posso semplificarmi la vita se ho a monte del router un firewall che 
riesce a riscrivermi il DSCP in modo tale da dire al firewall 
semplicemente di rispettare le code in base al tag DSCP che legge nei 
pacchetti?

 cosa mi sfugge?
Mah.... non so cosa dirti, da me c'e' come tutti gli altri protocolli, 
temo possa dipendere dal fatto che non sei nel posto giusto (policy-map 
anziche' class-map).


 pacchetti?
Purtroppo non conosco DSCP percio' mi astengo da ogni commento.


 anziche' class-map).
ops pardon,
class-map match-any GOLD
match protocol ?
   arp            IP ARP
   bridge         Bridging
   cdp            Cisco Discovery Protocol
   compressedtcp  Compressed TCP (VJ)
   ip             IP
   ipv6           IPV6
   llc2           llc2
   pppoe          PPP over Ethernet
   snapshot       Snapshot routing support
   vofr           voice over Frame Relay packets
bho mi manca :ï¿œï¿œï¿œï¿œ| eppure ï¿œ anche k6 :\

 bho mi manca :ï¿œï¿œï¿œï¿œ| eppure ï¿œ anche k6 :\
Non so davvero cosa dirti :( devo lasciare la parola a Tosh o altri piu' 
esperti di me.
Personalmente l'unica cosa che proverei a fare e' un update di ios.
Un dubbio: ma hai attivato l'nbar discovery sull'interfaccia ? Cosa ti 
dice come statistiche ?


 Si può?
se in uscita tutto esce con l'indirizzo esterno del router perche'
stai facendo PAT, sul dialer e' troppo tardi. in questo caso
devi mettere un policy-map "in" da qualche parte per segnalare
i pacchetti come importanti/normali/poco-importanti in entrata.
in uscita se non stai usando PAT puoi usare direttamente le porte
e cosi' via per decidere cosa e' importante. altrimenti usi le cose
che hai aggiunto tu ai paccehtti in entrata.
poi, se stai usando ppp su una linea adsl, credo che sia necessario
mettere "ppp multilink" sul dialer altrimenti non funziona un bel
niente
in quanto a QoS, mi pare di capire.


Partiamo con il dire che l'877 non eccelle in funzionalit� legate al qos, ma 
te ne sarai gi� accorto.
Detto questo se il traffico da limitare � nella direzione del download il 
punto giusto dove intervenire sarebbe il router di centrale del provider, ma 
siccome non credo tu possa farlo l'unica possibilit� che hai � limitare il 
resto del traffico in ingresso sulla interfaccia wan, il che non sempre da i 
risultati sperati.
Adesso basta perch� non voglio toglierti il gusto di fare qualche sana 
ricerca in merito.
Ciao,
         Tosh. 

 risultati sperati.
Di intervenire si riesce perchï¿œ il problema ï¿œ in upload. Saturo la banda 
in upload e rendo ingestibili molti altri servizi.
Sono riuscito a riscrivere il DSCP grazie ad un firewall a monte del 
router. Quindi adesso sarebbe abbastanza semplice dire al router
"in upload il traffico di classe 1 gold ï¿œ prioritario, cl1 silver ï¿œ 
medio e cl1 bronze ï¿œ basso".
ma non mi ï¿œ chiara la logica :\

Ciao,
la trafila completa di quello che vuoi fare prevede 3 fasi:
1- classificare il traffico
praticamente devi riuscire a individuare il traffico che vuoi trattare in 
modo diverso dall'altro e marcarlo in qualche modo. DSCP puo' essere il 
modo. Non hai bisogno di un firewall, la rimappatura del DSCP la puoi fare 
direttamente dal router. Comunque se sai gia' la porta di destinazione puoi 
anche usare direttamente quella.
2- creare le regole di gestione del traffico
crei le regole di accodamento del traffico. Ricordati che nei router le 
regole vengono applicate solo in caso di congestione. Cioe' per quello che 
serve a te un flusso di traffico puo' allargarsi quanto vuole se non c'e' 
niente altro. Ma se arriva altro traffico e c'e' contesa sulla linea, allora 
vengono applicate le regole di accodamento
Ci sono diverse modalita' di gestione delle code ma alla fine si finisce 
sempre col "class based weighted fair queuing" che e' la modalita' piu' 
flessibile.
Ti conviene leggere un po' prima di buttarti a configurare:
http://www.cisco.com/en/US/tech/tk543/tk544/tsd_technology_support_protocol_home.html
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSIntro.html
http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/12_4t/qos_12_4t_book.html
3- applichi le regole al traffico che hai identificato
e' la fase finale nella quale metti insieme i primi due punti. Fai un po' di 
prove e fai attenzione al percorso del pacchetto. Cioe' e' importante 
l'ordine delle operazioni sull'intefaccia.
Ciao
Marco 

 l'ordine delle operazioni sull'intefaccia.
Questa sembra essere la parte difficile in quanto su un'interfaccia
dialer
non sembra funzionare senza ppp multilink.

 ma non mi � chiara la logica :\
Questa te l'ha spiegata molto bene Hozomeen.
Ciao,
         Tosh. 

 il che non sempre da i risultati sperati.
Non ho mai fatto shaping su cisco, ma non potrebbe applicare lo shaping 
stesso sull'interfaccia LAN, per controllare il traffico in download?

 non sembra funzionare senza ppp multilink.
eh si, non c'e' dubbio. E purtroppo le modalita' di config non sono sempre 
uguali su tutti gli apparati per n-mila motivi. Per questo conviene prima 
farsi un'idea di come procedere e solo dopo cercare come applicare la teoria 
in pratica. Comunque sempre sul sito cisco puoi trovare le diverse modalita' 
di configurazioni e le diverse modalita' supportate. Prova questo documento: 
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094ad2.shtml
 
L'ho scorso al volo ma non sembra sia obbligatorio il MLPPP, al limite il 
PPP.
Ciao
Marco 

 stesso sull'interfaccia LAN, per controllare il traffico in download?
Non credo che cambi molto, se il traffico attraversa entrambe le interfacce 
direi che � assolutamente indifferente dove farai lo shaping.
Ciao,
         Tosh. 

          Tosh.
Se stai NATtando, forse devi fare lo shaping sull'interfaccia LAN
perche'
sull'interfaccia WAN non puoi riconosere il traffico che vuoi shapare.

sull'interfaccia WAN non puoi riconosere il traffico che >vuoi shapare.
Perch�?
Da quanto ne so io il nat non maschera i pacchetti, ma cambia ip/porte in 
funzione di regole chiare e stabilite sul router stesso, non capisco dove 
stia la difficolt� nel riconoscere il traffico da "shapare".
Ciao,
         Tosh. 

Tosh ha scritto:

dipende esattante quando il router fa il NAT. in uscita non puoi fare
lo shaping sul traffico da un dato indirizzo interno se tutti gli
indirizzi sono
nascosti dietro lo stesso indirizzo esterno, per esempio.

Ciao

dipende sempre da che parametri utilizzi per riconoscere l'applicazione 
oltre all'ordine col quale sono eseguite le operazioni sull'interfaccia. In 
particolare il secondo punto e' fondamentale.
Se l'ordine delle operazioni e' shaping-natting-uscita allora e' possibile 
utilizzare qualsiasi metodo per riconoscere il traffico. Se l'ordine e' 
invece natting-shaping-uscita allora se il traffico e' riconosciuto 
dall'indirizzo sorgente col nat sei fregato. Sicuramente e' piu' comodo 
lavorare sull'interfaccia in uscita, perche' e' li che c'e' la 
discontinuita' di banda interno/esterno, solo che bisogna capire bene come 
funziona tutta la procedura.
Ciao
Marco
P.S. non confondete lo shaping con la qos e la gestione delle code. Sono due 
tecniche differenti di gestione del traffico 

nascosti dietro lo stesso indirizzo esterno, per esempio.
Forse � un mio limite, ma visto il titolo del thead ed avendo fino ad ora 
parlato di porte e addirittura di nbar mi sembrava di essere pertinente, ma 
se si parla di lavorare a livello di host non posso che darvi ragione.
Ciao,
         Tosh. 

 Ciao,
se c'e' di mezzo il PAT puoi avere lo stesso problema. mi pare di
ricordare
che in entrata e in uscita l'ordine delle operazioni e' diversa.
traducono le porte
prima o dopo access-lists, shaping, ecc.? c'e' un elenco sul sito
della cisco.
comunque, io in _uscita_ guardo i pacchetti entranti su vlan1, metto i
valori
ip-prec guardando indirizzi ip e porte, poi in uscita su adsl (beh,
dialer on ppp multilink) uso i valori ip-prec per fare queueing/
shaping. se facessi routing normale
senza PAT non sarebbe necessario, ovviamente.

che in entrata e in uscita l'ordine delle operazioni e' >diversa.
L'ordine � certamente diverso, ma queueing e shaping rimangono al loro 
posto, anche perch� il queueing avviene solo in uscita ed � sempre l'ultima 
operazione, mentre il policing � comunque una delle ultime operazioni (a 
parte il queueing e ipsec in uscita) prima che i pacchetti vengano 
inoltrati.
Il check delle acl e il marking avvengono sempre prima, mentre nat e routing 
dipendono ovviamente dalla direzione dei dati, se ci riferiamo 
all'interfaccia di ingresso avverranno sicuramente dopo, se ci riferiamo 
invece all'interfaccia di uscita sono per forza gi� intervenuti.
Ciao,
         Tosh. 

 Non credo che cambi molto
Cambia, perchè la stragrande maggioranza dei più comuni algoritmi di
queueing funziona in uscita.

 queueing funziona in uscita.
Oserei dire che il queueing funziona solo in uscita per definizione, non a 
causa degli algoritmi ma perch� il queueing fatto in ingresso � totalmente 
inutile, tant'� che i router cisco mi risulta abbiano le code differenziate 
solo in uscita.
Si stava invece parlando di shaping, che � un altra cosa e pu� essere 
applicato in linea di principio su qualunque interfaccia attraversata dai 
dati da "normalizzare", visto che lavora scartando o marcando i pacchetti in 
eccesso.
Ciao,
         Tosh. 

 differenziate solo in uscita.
il queuing puo' funzionare anche in ingresso per evitare di perdere 
pacchetti su una interfaccia che magari non riesce a smaltire il traffico 
che riceve. Ma qui la faccenda si complica parecchio...
Ciao
Marco 


Non riesco ad inquadrare bene lo scenario, se un interfaccia non riesce a 
smaltire il traffico in ingresso di solito la situazione � del tipo che il 
router � a palla con la cpu o roba del genere.
Che contributo significativo pu� dare il qos in quei casi?
Ciao,
         Tosh. 

 Si stava invece parlando di shaping, che è un altra cosa
Ah, beh, perchè lo shaping non usa delle code e degli algoritmi di gestione
di tali code, eh?
Non temere, è una domanda retorica.

 Non temere, � una domanda retorica.
HAI RAGIONE!
Scrivevo "shaping" ma mi riferivo a "policing", ho erroneamente scambiato i 
due termini, si capirebbe leggendo attentamente quello che ho scritto, ma 
non cerco scusanti, l'errore � grossolano.
Per fare un po' di ordine:
lo shaping � una tecnica avanzata di queueing che funziona solo in uscita, 
il policing scarta o marca i pacchetti in eccesso e funziona in entrambe le 
direzioni.
Entrambi possono essere usati per regolare il traffico, con vantaggi e 
svantaggi per ciascuno.
Basta sostituire la parola "shaping" con la parola "policing" nei miei post 
precedenti e tutto torna, tranne forse l'astio di qualcuno. 

 Che contributo significativo pu� dare il qos in quei casi?
si esatto una delle possibilita' e' proprio quella. Piuttosto che scartare i 
pacchetti li accoda per gestirli non appena ha tempo. Oppure se la matrice 
di switching non e' non bloccante potresti avere congestione ad accedergli. 
E infine se hai diverse interfaccie in uscita con alcune sature e altre no 
allora accodi anche in ingresso per preservare il traffico di quelle sature. 
Cmq sono casi abbastanza particolari nei quali vuoi essere davvero sicuro di 
non scartare traffico.
Ciao
Marco 

eh guarda...l'esempio migliore mi e' venuto in mente mentre cliccavo 
send...tipicamente gli switch modulari hanno una oversubscription 
nell'accesso alla matrice di switching. Ad esempio il Cat6500 ha 40Gbps per 
accedere alla supervisor, ma sono disponibili anche schede con 16porte 
10Gbps, quindi con oversubscription 4:1. In questi casi accodare anche in 
ingresso puo' aiutare ad evitare momentanei problemi di accesso alla matrice 
di switching.
Ciao
Marco
"Hozomeen" <a...@def.hg> wrote in message 
news:12474793...@sj-nntpcache-3.cisco.com...


 matrice di switching.
Claro. 

ma quindi, sostanzialmente, se avete un torrent che vi satura la banda 
in upload rallentandovi tutto, anche le sessioni TS e gli FTP in 
ingresso... e non potete toccare suddetto torrent perchï¿œ del capo che 
non vuole che si tocchi nulla ...cosa fareste a livello rete?

 tocchi nulla ...cosa fareste a livello rete?
Non conosco che porte usa torrent e nemmeno se usa porte ben definite, con 
questo dato alla mano puoi fare shaping sull'interfaccia wan oppure, pi� 
probabilmente visto il modello di router, policing sull'interfaccia lan.
Se fosse un problema lavorare con le porte puoi sempre prendere come 
riferimento l'ip della macchina che fa torrent, molto pi� grossolano, ma 
efficare, fin troppo magari.
Ciao,
         Tosh. 

 non vuole che si tocchi nulla ...cosa fareste a livello rete?
Il problema è che non puoi basarti a priori su porte, perchè ogni client
torrent può cambiarle a piacimento.
Io faccio così, ma è una soluzione non-cisco, purtroppo:
iptables -t mangle -I POSTROUTING -m ipp2p --bit -j CLASSIFY --set-class 1:2
dove la 1:2 è una apposita classe htb a bassa priorità e banda.


Sospetto che sia l'equivalente di nbar su ios, che per� pare non sia 
disponibile sull'877. 

 disponibile sull'877.
Ciao.
L'NBAR è disponibile anche per 877 dalla 12.4(15)T , ma vi consiglio
la 20T1 nella quale hanno migliorato parecchi aspetti della qos anche
per l'877
Ciao
Carlo