Thank you Rick.

Here is tunnel configuration

MYRO#show run int tu0

Building configuration...

Current configuration : 267 bytes

!

interface Tunnel0

description IPSec VTI to HIM via SibirTCOMM

bandwidth 512

ip address 10.10.110.22 255.255.255.252

qos pre-classify

tunnel source 87.103.133.13

tunnel destination 89.175.97.74

tunnel mode ipsec ipv4

tunnel protection ipsec profile KM4

!

What I am trying to find out:

As you see this is the tunnel from point A to point B via Internet.

I am experiencing a low rate smb file transfers (20 - 40 kbytes/sec - or 160 Kbits/s - 255 Kbits/s).

Point A Internet bandwidth 10 Mbit/s; C3845

Point B Internet bandwidth 512 Kbit/s; C2621XM

But why it is so slow? I am expecting file transfer about 60 Kbyte/s or 480 Kbit/s. Is it encryption overhead?

Tim

I would guess that it is primarily the encryption overhead. Would I be correct in assuming that the 2621XM (and perhaps the 3845) does not have the module (AIM or VPN module) for the hardware assist with encryption processing? If the encryption processing is being done in the router CPU there is likely to be a performance hit while doing this.

[edit] I see that there is not an ip mtu command as I had thought there might be. But I am pretty sure that this is being done automatically as a result of the tunnel protection ipsec processing.

HTH

Rick

Rick, is it possible to speed up file transfers?

MYRO#show inventory

NAME: "2621XM chassis", DESCR: "2621XM chassis"

PID: C2621XM-2FE , VID: 1.0, SN: JAE073000HE

NAME: "Voice AIM with 4 DSPs 0", DESCR: "Voice AIM with 4 DSPs"

PID: 59-03 , VID: 1.0, SN: JAE07220ZZC

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

HIM#show inventory

NAME: "3845 chassis", DESCR: "3845 chassis"

PID: CISCO3845 , VID: V01 , SN: FCZ094872UH

NAME: "c3845 Motherboard with Gigabit Ethernet on Slot 0", DESCR: "c3845 Motherboard with Gigabit Ethernet"

PID: CISCO3845-MB , VID: V03 , SN: FOC0945267B

NAME: "4 Port FE Switch on Slot 0 SubSlot 0", DESCR: "4 Port FE Switch"

PID: HWIC-4ESW , VID: V01 , SN: FOC11122SRN

NAME: "One port E1 voice interface daughtercard on Slot 0 SubSlot 1", DESCR: "One port E1 voice interface daughtercard"

PID: VWIC-1MFT-E1= , VID: 1.0, SN: 35568679

NAME: "PVDMII DSP SIMM with four DSPs on Slot 0 SubSlot 4", DESCR: "PVDMII DSP SIMM with four DSPs"

PID: PVDM2-64 , VID: NA , SN: FOC09430DHX

Yes, there is no ip mtu command. I think this is not necessary. Am I correct?

Also, I am monitoring file transfer in WIRE-SHARK.

I see a lot TCP retransmits.

Блять нахуй заебало все, спать пойду.

Tim

If you add the hardware accelerator to the routers I believe that it would speed up the file transfers. This link discusses the hardware accelerator for the 2621XM:

http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet0900aecd800fa5be.html

and look for references to AIM-VPN

This link discusses the hardware accelerator for the 3845:

http://www.cisco.com/en/US/prod/collateral/routers/ps5853/data_sheet_vpn_aim_for_18128003800routers_ps5855_Products_Data_Sheet.html

and again look for references to AIM-VPN

HTH

Rick

Thank you Rick.

Tim

I now see your post which says you are monitoring with wireshark. If you are seeing lots of TCP retransmits then these would also impact the performance of the file transfer.

I am a bit puzzled about this. If the router is using IPSec to protect traffic through the tunnel, then I would expect that wireshark would see IPSec traffic using the ESP protocol rather than using TCP traffic.

HTH

Rick

I am monitoring inside interface.

Tim

Monitoring the inside interface would certainly explain why you are seeing TCP rather than ESP.

If there are TCP retransmissions they would impact the performance of the file transfer. And I am not sure that the hardware assist for encryption would change anything about the retransmissions.

HTH

Rick

"is it possible to speed up file transfers? "

Two common issue are encryption processing load (best dealt with by hardware support), and fragmention impact. See http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml for the latter.