Configurazione del QOS su singolo IP

Tutto ciò che ha a che fare con la configurazione di apparati Cisco (e non rientra nelle altre categorie)

Moderatore: Federico.Lagni

Rispondi
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Da tempo stò cercando di configurare invano una politica di Qos che possa funzionare.
La mia intenzione è quella di dato un certo tipo di traffico sensibili alla latenza garantirgli un minimo di banda e fargli utilizzare una coda del tipo LLQ.

il tutto sarebbe più o meno così

1) Identifico il traffico sensibile tramite access-list
********************************************
ip access-list ex POCALATENZA
permit ip 10.0.0.1 0.0.0.255 any
********************************************

2) Creo la classe relativa all'access list
********************************************
class DATISENSIBILI
ip access-group POCALATENZA
********************************************

3) Creo la policymap che setta i parametri da mè scelti
********************************************
policy-map TEST
class DATISENSIBILI
priority percent 30
class class-default
********************************************


Applicando poi la policy-map in OUTPUT sull'interfaccia Dialer 0 non funziona più nulla. Non è che il -deny ip any any- implicito sull'access list possa dare fastidio ? Boh
Marx
Cisco fan
Messaggi: 57
Iscritto il: ven 04 nov , 2005 6:42 am

mogliasi ha scritto: 2) Creo la classe relativa all'access list
********************************************
class DATISENSIBILI
ip access-group POCALATENZA
********************************************
E' sbagliato. Non avevo nemmeno idea che si potesse applicare una ACL in quel modo.....

class DATISENSIBILI
no ip access-group POCALATENZA
match access-group name POCALATENZA

o qualcosa di simile, usa il "?"

Verifica: # show policy-map interface Dialer0

Ricordo che solo se c'è saturazione sull'interfaccia scatta la policy.
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Chiedo scusa. L'errore c'è ma è uno sbaglio di copia incolla.
Quelle che hai suggerito è effettivamente impostato sul router, e cioè

match access-group name POCALATENZA


comunque eseguirò ulteriori verifiche e posterò i risultati

PS
Ma non mettere nulla nella classe class-default a cosa equivale ?
Marx
Cisco fan
Messaggi: 57
Iscritto il: ven 04 nov , 2005 6:42 am

mogliasi ha scritto: PS
Ma non mettere nulla nella classe class-default a cosa equivale ?
La class-default viene creata in automatico quando crei una policy(non occorre nemmeno specificarla). TUTTO il traffico che non ha match con le altre classi finisce in questa che di default viene gestita in FIFO(= no QoS) ma volendo potresti abilitarci il WFQ/WRED o assegnargli banda garantita(comando bandwidth).


Per quanto riguarda il tuo problema potresti provare ad applicare il comando sull'int. / subint. fisica.
Domanda... Non è che c'è qualche altro filtro che bloccca il traffico? Se rimuovi il service policy dall'int. funziona?
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Forse ho trovato dove è il problema.
Non riesco ad intercettare il traffico dell'ip sorgente ecco tutto. Tale ip è 10.1.0.252/24

e l'accesss list POCALATENZA è


permit ip 10.1.0.252 0.0.0.0 any


ma non c'è verso di fargli riconoscere i pacchetti che transitano ! Ho provato con altre inverse subnet mask ma non c'è nulla da fare. In che cosa questa ACL è sbagliata ???
Marx
Cisco fan
Messaggi: 57
Iscritto il: ven 04 nov , 2005 6:42 am

mogliasi ha scritto:Forse ho trovato dove è il problema.
ma non c'è verso di fargli riconoscere i pacchetti che transitano ! Ho provato con altre inverse subnet mask ma non c'è nulla da fare. In che cosa questa ACL è sbagliata ???
Può essere anche tutto corretto. Ti ripeto che la policy che applichi entra in funzione solo in fase di congestione sulla coda hardware in uscita dell'interfaccia fisica.
In base a cosa dici che il flusso non viene classificato?
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Semplicemente guardo se l'access list viene "conteggiata".
Ho provato a metterla semplicemente sull'interfaccia Fastethernet e negare il traffico ma a differenza delle altre non si incrementa.

Faccio uno sh ip access-list e verifico se ci sono dei match, ma nulla.

Ho creato questa

deny ip 10.1.0.252 0.0.0.0 any
permit ip any any

ho configurato il mio Mac con tale indirizzo ma continua a uscire in rete. Evidentemente c'è qualcosa con che quadra. I miei dubbi ricadono sempre sulla maschera di sottorete inversa ma configurata... Forse può dare qualche problema l'indirizzo di Classe A subnettato in classe C /24 ????
Marx
Cisco fan
Messaggi: 57
Iscritto il: ven 04 nov , 2005 6:42 am

C'è il NAT? Con l'ACL in outbound devi usare l'IP pubblico..... ci sono altre considerazioni da fare... se c'è il NAT
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Certo che c'è il NAT. Che consderazioni devo fare allora per dare priorità ad un IP interno oramai nattato ?

Considerando ciò, è corretto allora applicare tali politiche sull'interfaccia WAN in output ?
Marx
Cisco fan
Messaggi: 57
Iscritto il: ven 04 nov , 2005 6:42 am

mogliasi ha scritto:Certo che c'è il NAT. Che consderazioni devo fare allora per dare priorità ad un IP interno oramai nattato ?

Considerando ciò, è corretto allora applicare tali politiche sull'interfaccia WAN in output ?
Con un nat statico sarebbe semplice l'implementazione , ma suppongo che tu usi quello con overload... qua il discorso diventa interessante e sinceramente, volendosi impuntare ad applicare una sola policy in uscita, l'unica cosa che mi viene in mente è che sarebbe necessario limitare il Pat per quell'host su un numero di porte TCP limitato e poi fare il match su queste...ma non credo sia possibile....o forse si con una configurazione avanzata del NAT con route-maps.

Altra soluzione: potresti usare una policy sull'interfaccia in ingresso (della lan) che fa il marking DSCP per i pacchetti che arrivano da quell'host. In uscita poi applichi le policy in base al marking anzichè in base all'ACL.

Altra soluzione: imposti una sola policy in input sulla fastethernet dove andrai a creare una policy gerarchica: puoi fare shaping con il rate dell'interfaccia internet e all'interno dello shaping vai a definire il queuinq LLQ per l'host che ti interessa (ACL based). Sempre che la fastethernet sia solo un'interfaccia di transito esclusiva per il traffico internet, altrimenti ha poco senso
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Marx ha scritto: Con un nat statico sarebbe semplice l'implementazione , ma suppongo che tu usi quello con overload... qua il discorso diventa interessante e sinceramente, volendosi impuntare ad applicare una sola policy in uscita, l'unica cosa che mi viene in mente è che sarebbe necessario limitare il Pat per quell'host su un numero di porte TCP limitato e poi fare il match su queste...ma non credo sia possibile....o forse si con una configurazione avanzata del NAT con route-maps.
E infatti uso il NAt con overload :-) Ieri ho cambiato l'access list e mi sono dovuto accontentare di controllare solo il traffico con determinate porte invece che il singolo IP. Così però funzionava.

es
permit tcp xxxx any eq 88
permit udp xxxx any eq 88
etc
etc

Marx ha scritto: Altra soluzione: imposti una sola policy in input sulla fastethernet dove andrai a creare una policy gerarchica: puoi fare shaping con il rate dell'interfaccia internet e all'interno dello shaping vai a definire il queuinq LLQ per l'host che ti interessa (ACL based). Sempre che la fastethernet sia solo un'interfaccia di transito esclusiva per il traffico internet, altrimenti ha poco senso
Ok proverò anche quella strada. In effetti fare lo shaping sulla Fa0/0 con il rate della WAN non lo avevo ancora fatto.

Comunque i contatori dei pacchetti identificati salivano sempre. PEccato che non sono riuscito a congestionare l'interfaccia per vedere dei pacchetti droppati. Ho provato ripetutamente con download e speedtest.net ma nulla da fare.


PS
Pensandoci bene lo shaping serve, in questo caso, a creare un limite per congestionare l'interfaccia ? Solo così si avrebbe una corretta gestione delle code sull'interfaccia Fastethernet ?
Marx
Cisco fan
Messaggi: 57
Iscritto il: ven 04 nov , 2005 6:42 am

mogliasi ha scritto:
Marx ha scritto: Comunque i contatori dei pacchetti identificati salivano sempre. PEccato che non sono riuscito a congestionare l'interfaccia per vedere dei pacchetti droppati. Ho provato ripetutamente con download e speedtest.net ma nulla da fare.
Se applichi la policy in inbound (sulla fast) o outbound (sull'int internet) controlli solo l'upload.
Pensandoci bene lo shaping serve, in questo caso, a creare un limite per congestionare l'interfaccia ? Solo così si avrebbe una corretta gestione delle code sull'interfaccia Fastethernet ?
Si , detto a grandi linee non fa una piega.
Avatar utente
mogliasi
Cisco fan
Messaggi: 42
Iscritto il: lun 06 giu , 2005 11:04 am

Piccola nota:
ho notato che i valori del calcolo della banda delle policy-map viene fatto con il valore bandwidth dell'interfaccia e non sulla banda reale.

In questo caso avendo una linea ADSL e quindi per natura asimmetrica ho dovuto specificare 2 diverse velocità con i comandi
bandwidth banda in upload
bandwidth receive banda in download

ed ecco il risultato

Dialer0 is up, line protocol is up (spoofing)
Hardware is Unknown
Internet address is xx.xx.xx.xx/32
MTU 1500 bytes, BW 384 Kbit/sec, RxBW 7168 Kbit/sec, DLY 20000 usec,

Applicando la policy-map in OUTBOUND sulla Dialer0 il valore sul quale verrà calcolato il tutto sarà ovviamente basato sull' UPLOAD, però tanto vale specificare i valori corretti nei due sensi.
Spero di aver fatto la cosa nel modo giusto.

[/i]
Rispondi