Newsgroup: it.comp.reti.cisco
Titolo: ipsec 827, tempi di risposta lunghi

sono riuscito a creare ipsec
tra du sedi, solo che il ping per es. nel tunnel
da risposte da 63 a 79 mms!!!
com'č possibile che sia cosě lento?
L'IOS č c820-k9osy6-mz.122-8.yj.bin
entambi sono collegati ad adsl 640...
qualcuno ha qualche idea da darmi?
grazie
Beppe

 wrote in news:OEJHa.96584$Ny5.2833345
@
twister2.libero.it
:

...
80 ms per un tunnel ipsec non mi sembrano poi tanti...
quanti hop hai da un router all'altro?
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
+-------
** Articolo inviato tramite i servizi gratuiti di 
www.x-privat.org
 **

 ha scritto nel messaggio
news:OEJHa.96584$Ny5.2...@twister2.libero.it...


 da risposte da 63 a 79 mms!!!
Ottimo !
Hai fortuna che vada cosi' veloce.
Di solito tra due ADSL si arriva anche a 120.


gli hop sono 2, i client nell'altra sede che si connetono
al server attraverso ipsec, attendono troppo tempo per ricevere i risultati
di query(anche di pochi risultati) fatte su
sql server, ho bisogno di velocizzare i tempi di risposta,
potrei puntare l'ipsec solo sull'indirizzo
privato del server, tipo 10.0.0.4? piuttosto che sull'intera 10.0.0.0?
sarebbe un'idea o non cambia nulla?
potrei postare la config. sempre che sia utile a risolvere il problema,
fatemi sapere.
grazie mille
Beppe

"Alex Limbeck" <acikN...@RIMUOVIiol.it> ha scritto nel messaggio
news:XxMHa.97425$Ny5.2...@twister2.libero.it...

ma abbassando il valore del'MTU
riuscirei a risolvere il problema?
oppure dovrei incrementare il Windows "TCP Receive Window" size
come dice questo link 
http://www.ifm.net.nz/research/vpn.html
 ?
qualsiasi consiglio a riguardo è apprezzato.
grazie cmq per avermi "tranquillizzato" sui tempi di risposta del ping :-)
ciao
Beppe

 L'IOS è c820-k9osy6-mz.122-8.yj.bin



ho provato a pingare da console pacchetti da 100 e da 6000 byte
nel tunnel
i 100 =ms 84/94/136
i 6000=ms 992/997/1008
che ne dite?
Inoltre qui sotto c'è il risultato di uno show crypto ipsec sa.
qualche suggerimento utile a riguardo x migliorare le prestazioni?...temo di
no! :-)
Se questo non dovesse riuscire purtroppo credo che sarò costretto
contro la mia volontà a implementare un tunnell GRE con tutti
i suoi risvolti negativi x il fatto che non crypta il traffico...
qualsiasi suggerimento a riguardo è ben accetto
grazie e ciao
Beppe
interface: ATM0.1
    Crypto map tag: xxxxxxxxx, local addr. xxx.xxx.xxx.xxx
   local  ident (addr/mask/prot/port): (
192.168.100.0/255.255.255.0/0/0
)
   remote ident (addr/mask/prot/port): (
192.168.99.0/255.255.255.0/0/0
)
   current_peer: xxx.xxx.xxx.xxx
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 2916, #pkts encrypt: 2916, #pkts digest 2916
    #pkts decaps: 2916, #pkts decrypt: 2916, #pkts verify 2916
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
failed: 0
    #send errors 0, #recv errors 0
     local crypto endpt.: xxx.xxx.xxx.xxx, remote crypto endpt.:
xxx.xxx.xxx.xxx
     path mtu 1500, media mtu 1500
     current outbound spi: 839A02FE
     inbound esp sas:
      spi: 0x45EC24D1(1173103825)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: xxxxxx
        sa timing: remaining key lifetime (k/sec): (4602431/2526)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x839A02FE
(2207908606
)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: xxxxxx
        sa timing: remaining key lifetime (k/sec): (4603314/2485)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas: