Bandbreedte probleem over VPN tunnel

[Verwijderd]

Op twee lokaties heb ik goed werkende lijnen van 2Mbit synchroon.

Down/Uploaden naar het internet verloopt met bijna volle 2Mbit.
Op beide lokaties zijn Juniper Netscreens 20 aanwezig. Basic geprogt.

Tussen de vestigingen heb ik een VPN tunnel opgezet tussen twee subnets.
Als je bijv. FTP protocol gebruikt om door de tunnel bestanden over te halen, dan gebeurt dit met een snelheid van +- 1024Kbit.

Door een tweede of meer threads te openen, dan loopt de 2Mbit lijn wel vol.


Hoe kan het de lijn niet bij de eerste thread dicht loopt? Niet echt efficient dus.

[Verwijderd]

Wat heb je zelf al geprobeerd om dit probleem te tackelen ? Reeds een sniffer trace gemaakt en bekeken ? MTU aangepast voor je tunnel transport ?

[Verwijderd]

Het eerste is dat ik de firewalls een frisse factory default heb gegeven.
Daarna via wizard verbinding laten maken.

Verder heb ik op de support page van Juniper gezocht, maar niets kunnen vinden.
GeGoogled, helaas kan ik niet dit probleem in een trefwoord samen vatten.


MTU staat op WAN 1492, LAN 1500.

Heeft fragmenteren van packets geen invloed op dit verschijnsel?

[JackBol]

Verwijderd schreef op woensdag 25 januari 2006 @ 09:06:
Heeft fragmenteren van packets geen invloed op dit verschijnsel?

Jazeker! Wat voor tunnel gebruik je? IPSec? ESP/AH Tunnel/Transport mode? Ik neem aan ESP Tunnel mode. Daar wordt je pakketje ook nog eens +/- 20 a 30 bytes groter van. (weet ff niet precies)

Probeer je MTU van je LAN lager te zetten totdat het probleem niet meer optreed.

Probeer eerst eens een MTU van 1400, vervolgens kun je je MTU size een beetje intrainen op de grootst mogelijke MTU zonder dat je hoeft te fragmenteren.

Zorg er wel voor dat je veel data verstuurd, anders krijg je natuurlijk geen max packets.

[ Voor 61% gewijzigd door JackBol op 25-01-2006 09:44 ]

[Verwijderd]

Ik gebruik ESP-CBC met 3DES encryptie algorithm.
Authentication Algorithm SHA.

Moet ik AES 128bits met MD5 gebruiken?

Scheelt dit echt bijna 40%?

[JackBol]

Verwijderd schreef op woensdag 25 januari 2006 @ 09:44:
Ik gebruik ESP-CBC met 3DES encryptie algorithm.
Authentication Algorithm SHA.

Moet ik AES 128bits met MD5 gebruiken?

Scheelt dit echt bijna 40%?

Voor auth en encruptie zou ik voor AES-CBC en SHA1 gaan, dat is momenteel 'industry-standard' zo'n beetje...

[TrailBlazer]

wat zijn is je rtd over je tunnel heen. Je kan er last van hebben dat de TCP acks te lang op zich laten wachten waardoor je uit je window loopt en de datatransfer stokt. Probeer het ook eens met een tftp progje ofzo. Dit is udp en heeft hier geen last van

[Verwijderd]

TrailBlazer schreef op donderdag 26 januari 2006 @ 08:16:
wat zijn is je rtd over je tunnel heen. Je kan er last van hebben dat de TCP acks te lang op zich laten wachten waardoor je uit je window loopt en de datatransfer stokt. Probeer het ook eens met een tftp progje ofzo. Dit is udp en heeft hier geen last van

RTD is ongeveer 50ms. Nederland - Hongarije, met 9 hops er tussen.

Zijn de TCP acks te tweaken?

Ik heb AES encryptie ingesteld en het geeft al een veel betere performance over FTP. Klein 10% verlies.
Denk dat dat redelijk is.

Alleen Windhooz SMB lijkt er nog niet al te veel zin te hebben, erg traag ivm FTP. Is dit te tweaken?

Modbreak:

Noem het gewoon bij z'n naam als je hier serieus genomen wilt worden. Dit is geen speeltuin.

[ Voor 8% gewijzigd door Verwijderd op 28-01-2006 12:15 ]

[JackBol]

Verwijderd schreef op donderdag 26 januari 2006 @ 08:51:
[...]


RTD is ongeveer 50ms. Nederland - Hongarije, met 9 hops er tussen.

Zijn de TCP acks te tweaken?

Ik heb AES encryptie ingesteld en het geeft al een veel betere performance over FTP. Klein 10% verlies.
Denk dat dat redelijk is.

Alleen Windhooz SMB lijkt er nog niet al te veel zin te hebben, erg traag ivm FTP. Is dit te tweaken?

SMB is gewoon een traag protocol en niet bedoelt voor over WAN verbindingen. Hou er maar eens DUmeter langs als je een bestand van 10 mb overzet, dan zie je dat er in werkelijkheid bijna 20mb over de lijn gaat...

[TrailBlazer]

Verwijderd schreef op donderdag 26 januari 2006 @ 08:51:
[...]


RTD is ongeveer 50ms. Nederland - Hongarije, met 9 hops er tussen.

Zijn de TCP acks te tweaken?

Ik heb AES encryptie ingesteld en het geeft al een veel betere performance over FTP. Klein 10% verlies.
Denk dat dat redelijk is.

Alleen Windhooz SMB lijkt er nog niet al te veel zin te hebben, erg traag ivm FTP. Is dit te tweaken?

je kan in de registry de max tcp windowsize aanpassen zal eens ff kijken of ik het op de microsoft site kan vinden de exacte uitleg. Hoewel volgens mij 50 ms nog geen probleem zou mogen zijn.

http://www.microsoft.com/.../depovg/tcpip2k.mspx#EEAA

hier staat het uitgelegd met name de zin

Throughput can never exceed window size divided by round-trip time.

Ik zeg niet dat dit jouw probleem is maar is wel een leuk probleem. Heb ooit een klant dit moeten uitleggen.
Bij een windowsize van 64KB en rtd van 50 ms zou je max zou je dan max 10Mb kunnen halen. Kortom jow probleem wordt hier niet door veroorzaakt

[ Voor 27% gewijzigd door TrailBlazer op 26-01-2006 11:18 ]