Pagina 1 di 1
Qos basato su ip over vpn
Inviato: mar 14 apr , 2009 6:00 pm
da neo2season
Permetto che sono a digiuno di qos. Sto cercando di mettere in piedi un minimo di qos per dei centralini voip su tre sedi distinte e collegate in vpn. Ecco la mia configurazione:
Codice: Seleziona tutto
!
version 12.4
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname sede_master
!
boot-start-marker
boot-end-marker
!
!
aaa new-model
!
!
aaa authentication login vpnauth local
aaa authorization network vpngroup local
!
aaa session-id common
!
resource policy
!
!
!
ip cef
ip domain name domain.local
ip name-server 151.99.125.3
!
!
!
username zzzzzzzzzz password 7 rrrrrrrrrrrrrrrrr
!
!
class-map match-all qos-voip-map
match access-group 111
!
!
policy-map qos-voip-policy
class qos-voip-map
priority 80
!
!
!
crypto isakmp policy 3
encr 3des
hash md5%0
authentication pre-share
group 2
A lifetime 28800
!
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2
lifetime 28800
crypto isakmp key XXXXXXXXXXXX address XXXXXXXXXXXX no-xauth
crypto isakmp key XXXXXXXXXXXX address XXXXXXXXXXXX no-xauth
!
crypto isakmp client configuration group ZYX2MUVPN
key XXXXXXXXXXXX
dns 151.99.125.3
domain write
pool localVPNpool
acl 103
save-password
!
!
crypto ipsec transform-set VPN2MUVPN esp-3des esp-md5-hmac
crypto ipsec transform-set VPN2SEDE1 esp-3des esp-md5-hmac
crypto ipsec transform-set VPN2SEDE2 esp-3des esp-md5-hmac
!
crypto dynamic-map VPNDYNMAP 9
set transform-set VPN2MUVPN
reverse-route
!
!
crypto map VPNMAP client authentication list vpnauth
crypto map VPNMAP isakmp authorization list vpngroup
crypto map VPNMAP client configuration address respond
crypto map VPNMAP 9 ipsec-isakmp dynamic VPNDYNMAP
crypto map VPNMAP 10 ipsec-isakmp
set peer XXXXXXXXXXXX
set transform-set VPN2SEDE1
match address 103
crypto map VPNMAP 11 ipsec-isakmp
set peer XXXXXXXXXXXX
set transform-set VPN2SEDE2
match address 102
!
!
!
interface Loopback0
no ip address
!
interface Ethernet0
ip address 192.168.0.254 255.255.255.0
ip nat inside
ip virtual-reassembly
hold-queue 100 out
!
interface Ethernet0.1
shutdown
!
interface Ethernet2
no ip address
shutdown
hold-queue 100 out
!
interface ATM0
no ip address
ip nat outside
ip virtual-reassembly
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.1 point-to-point
ip address XXXXXXXXXXXX 255.255.255.248
ip nat outside
ip virtual-reassembly
no snmp trap link-status
crypto map VPNMAP
pvc 8/35
oam-pvc manage
oam retry 3 5 1
encapsulation aal5snap
!
!
interface ATM0.2 point-to-point
no snmp trap link-status
!
interface FastEthernet1
duplex auto
speed auto
!
interface FastEthernet2
duplex auto
speed auto
!
interface FastEthernet3
duplex auto
speed auto
!
interface FastEthernet4
duplex auto
speed auto
!
ip local pool localVPNpool 192.168.50.1 192.168.50.100
ip route 0.0.0.0 0.0.0.0 ATM0.1
no ip http server
no ip http secure-server
!
ip nat inside source list 100 interface ATM0.1 overload
!
access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
access-list 101 permit tcp XXXXXXXXXXXX 0.0.0.7 any eq 22
access-list 101 permit tcp XXXXXXXXXXXX 0.0.0.7 any eq 22
access-list 101 permit tcp XXXXXXXXXXXX 0.0.0.7 any eq 22
access-list 101 permit tcp XXXXXXXXXXXX 0.0.0.7 any eq 22
access-list 102 permit ip 192.168.0.0 0.0.0.255 192.168.200.0 0.0.0.255 log
access-list 103 permit ip 192.168.0.0 0.0.0.255 192.168.100.0 0.0.0.255 log
access-list 110 permit ip 192.168.0.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 111 permit ip host 192.168.0.251 host 192.168.100.2
access-list 111 permit ip host 192.168.0.251 host 192.168.200.2
access-list 111 permit ip host 192.168.100.2 host 192.168.0.251
access-list 111 permit ip host 192.168.200.2 host 192.168.0.251
!
control-plane
!
banner login ^C
-----------------------------------------------
Ogni accesso non autorizzato e' proibito
Unauthorized access is prohibited
-----------------------------------------------
^C
!
line con 0
no modem enable
line aux 0
line vty 0 4
access-class 101 in
!
scheduler max-task-time 5000
end
L'ho un po' ripulita da ip, nomi. Ma dovrebbe essere funzionante. Oltre ai tunnel su questo, c'è anche una vpn per il client cisco.
Io posso identificare gli indirizzi Ip dei vari centralini e sulla rete non ho switch gestibili ma solo dei cagatori da 10euri.
Ho pensato quindi che l'unico sistema è quello di gestire la precedenza. Mi sono fatto un ACL, la 111, per gli apparati interessati e ho creato :
Codice: Seleziona tutto
class-map match-all qos-voip-map
match access-group 111
!
!
policy-map qos-voip-policy
class qos-voip-map
priority 80
ma non mi suona corretta. Inoltre dove la applico ? aulla atm0.1 ?
Grazie per eventuali suggerimenti.
Inviato: mer 15 apr , 2009 8:44 am
da francesco_savona
Scusami un attimo....ma i tunnel dove sono???
Ti conviene filtrare a livello di interfaccia locale ethernet(vlan 1) dato che hai più interfacce di uscita.
Tunnel e Atm0.1 e Virtual per cisco vpn.
Inviato: mer 15 apr , 2009 12:24 pm
da neo2season
Ciao
In che senso dove sono i tunnel? Per la vpn ho usato le crypto-map applicate alla atm0.1. Infatti ho provato ad applicare su quell'interfaccia la policy-map ma non sembra funzionare.
Dici che mi conviene creare una interfaccia di tipo tunnel e applicare li la service-policy ?
Tipo cosi ?:
Codice: Seleziona tutto
interface Tunnel30
bandwidth 1024
ip address XXXXXX YYYYYYY
ip access-group 150 out
ip mtu 1418
delay 10000
keepalive 2 3
tunnel source XXXXXXXXX
tunnel destination XXXXXXXX
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
service-policy output qos-voip-policy
!
Ma è un casino cosi. Poi il tutto è in produzione... Non c'è un'altro sistema ?
Inoltre è giusto dare la precedenza in base ad una ACL ?
Inviato: gio 16 apr , 2009 12:43 am
da Marx
neo2season ha scritto:Ciao
In che senso dove sono i tunnel? Per la vpn ho usato le crypto-map applicate alla atm0.1. Infatti ho provato ad applicare su quell'interfaccia la policy-map ma non sembra funzionare.
Dici che mi conviene creare una interfaccia di tipo tunnel e applicare li la service-policy ?
Tipo cosi ?:
Codice: Seleziona tutto
interface Tunnel30
bandwidth 1024
ip address XXXXXX YYYYYYY
ip access-group 150 out
ip mtu 1418
delay 10000
keepalive 2 3
tunnel source XXXXXXXXX
tunnel destination XXXXXXXX
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI
service-policy output qos-voip-policy
!
Ma è un casino cosi. Poi il tutto è in produzione... Non c'è un'altro sistema ?
Inoltre è giusto dare la precedenza in base ad una ACL ?
Non ci sono problemi a classificare il traffico tramite ACL. Eventualmente potresti anche usare altre tecniche di classificazione.
Proverei ad applicare il preclassify (comando "qos pre-classify") all'inteno della crypto map relatica a ciascun tunnel.
In questo modo viene considerato l'header IP prima che venga incapsulato in IPSEC.
Se avessi fatto la classificazione in base al ToS(match ip dscp) non avresti avuto questo problema(sempre che sia questo il problema), perchè l'IOS copia le info dal ToS dell'header originale a quello del tunnel. Puoi sfruttarlo nel caso il paccketto sia già marcato dal telefono/centralino (solitamente i tel taggano con EF) oppure hai fatto il marking sui device di rete o sul router stesso.
Se non ricordo male, se c'è uno specifico livello di saturazione del traffico(qui bisognerebbe dilungarsi) il meccanismo LLQ che stai applicando non entra in azione perchè giustamente ...non ce n'è bisogno. Possibile che c'era poco traffico sull'interfaccia quando hai fatto le verifiche? Magari sta funzionando.
show policy-map interface {x/y} può darti qualche info utlile in merito ai pacchetti che sono passati per quella coda.
Altra piccola nota: quell'80 che specifichi non viene calcolato sulla banda totale dell'interfaccia, ma sulla banda non riservata ....che di solito è il 75%(della banda totale).
Il 20% che ti rimane potresti usarlo per altre classi di traffico che vogliono banda garantita.
Se può servire...
http://www.cisco.com/en/US/tech/tk543/t ... 3eae.shtml
Mai visto un tunnel con IPSec implementato nel modo che hai indicato nell'ultimo post.. Dove l'hai trovata quella conf?
Inviato: gio 16 apr , 2009 11:47 am
da neo2season
Grazie per le info. Ho trovato altra documentazione attinente:
http://www.cisco.com/en/US/docs/ios/12_ ... cfvpn.html
Solo che sembra che non ho questo comando:
Codice: Seleziona tutto
sede-master(config-crypto-map)#?
Crypto Map configuration commands:
default Set a command to its defaults
description Description of the crypto map statement policy
dialer Dialer related commands
exit Exit from crypto map configuration mode
match Match values.
no Negate a command or set its defaults
reverse-route Reverse Route Injection.
set Set values for encryption/decryption
oppure:
Codice: Seleziona tutto
0711304811901(config-crypto-map)#qos pre-classify
^
% Invalid input detected at '^' marker.
Strano. Non riesco a trovare però i riferimenti relativi alla versione del ios. La mia comunque è:
Codice: Seleziona tutto
System image file is "flash:c837-k9o3y6-mz.124-5b.bin"
Cerco meglio...
Tornado però al discorso ho gli apparati sono in realtà dei media gateways della AudioCodes e, credo perche non li ho installati io, sono configurati con SIP. Ho dato un occhiata al manuale di sti cosi e risulta che di default hanno una configurazione DiffServ. Vediamo quindi se ho capito. I media gw taggano pacchetti solo in presenza delle vlan... Il che mi taglia fuori... Sottolineo nuovamente la mia ignoranza in merito.
Detto questo (che potrebbe essere un eresia) non riesco a identificare il pacchetto se non via IP sorgente/destinazione. Bene. Visto che la crypto map è applicata alla atm0.1 provo ad associarci la policy-map e faccio delle prove.
Per quanto riguarda la modalità vpn è basata sulle crypto map. Visto che non devo (o meglio dovevo) gestire traffico tra gli endopint vpn, sono any-any, non avevo bisogno di vti. Credo che sta configurazione la trovi un po' dovunque sulla documentazione cisco. Io personalmente mi sono basato sulla documentazione del corso di certificazione ccsp che ho fatto. E poi a me vti mi sa tanto di gre, ma sono gusti.
Mi documento meglio e faccio delle prove...
Inviato: gio 16 apr , 2009 2:05 pm
da Marx
In effetti è strano; dall'esempio è evidente che quel comando bisogna applicarlo nella crypto-map. Potresti provare a metterlo sull'interfaccia/subint. fisica dove applichi la crypto. Se va è la soluzione più veloce.
Cerco meglio...
Tornado però al discorso ho gli apparati sono in realtà dei media gateways della AudioCodes e, credo perche non li ho installati io, sono configurati con SIP. Ho dato un occhiata al manuale di sti cosi e risulta che di default hanno una configurazione DiffServ. Vediamo quindi se ho capito. I media gw taggano pacchetti solo in presenza delle vlan... Il che mi taglia fuori... Sottolineo nuovamente la mia ignoranza in merito.
mmm...visto che non gestisci tu tutto l'ambaradan, se vuoi risparmiare un pò di tempo potresti far lavorare solo il router ed i applicare una service policy sull'interfaccia LAN per marcare come più ti piace il traffico in ingresso in base ad ACL. (continuando ad usare la logica delle ACL, ma anzichè impostare l'accodamento, setti solo il DSCP )
Il/ii valori/e che assegnerai a quei flussi li richiami poi nella policy applicata in uscita (togli il match all'ACL che c'è ora e fai i match in base al DSCP con cui i pacchetti sono stati marcati nell'interfaccia in ingresso ad esempio).
Alla fine dovresti ritrovarti con una service-policy in ingresso per il marking del DSCP in base a sorgente/destinazione-IP ed un altra in uscita per il policyng in base al DSCP applicato prima.
Ti faccio presente che sto parlando in base alla teoria che conosco. Non mi è mai capitato di implementarla. Se hai domande chiedi pure che almeno ripasso un pò
e se posso ti rispondo.