FireBrick IPsec Throughput: Difference between revisions
mNo edit summary |
m (clean up, typos fixed: 15Mb/s → 15Mbit/s (4), eg → e.g. (2)) |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
<indicator name="Tunnels">[[File:Menu-IPsec.svg|link=:Category: |
<indicator name="Tunnels">[[File:Menu-IPsec.svg|link=:Category:FireBrick IPsec|30px|Back up to the FireBrick IPsec Tunnels Category Page]]</indicator> |
||
On a FB 2700, throughput should be around 10 - |
On a FB 2700, throughput should be around 10 - 15Mbit/s. |
||
Here is a speedtest from a Road Warrior on a good internet connection connected to a FB2700 on a single |
Here is a speedtest from a Road Warrior on a good internet connection connected to a FB2700 on a single 60Mbit/s down and 20Mbit/s up FTTC, using HMAC-SHA1 |
||
[[File:FB2700 IPSec Speedtest.png|none|thumbnail|Speedtest over a FB2700 IPsec tunnel]] |
[[File:FB2700 IPSec Speedtest.png|none|thumbnail|Speedtest over a FB2700 IPsec tunnel]] |
||
[[File:FB2700 IPSec Speedtest2.png|none|thumbnail|Another speedtest over a FB2700 IPsec tunnel]] |
|||
[[File:2700 IPsec 100M download.png|none|thumbnail|Download over a FB2700 IPsec tunnel]] |
[[File:2700 IPsec 100M download.png|none|thumbnail|Download over a FB2700 IPsec tunnel]] |
||
A FB6000 can do nearer |
A FB6000 can do nearer 50Mbit/s, whilst newer generation of FireBrick hardware should be even better. |
||
==Other notes on throughput== |
|||
If an IPsec connection is slow, it is useful check a few other things. Latency can have large impact on e.g. a TCP connection so it's good to: |
|||
*Try a ping with a large payload (e.g. 1400 bytes) |
|||
*The window buffer size needs to be larger the larger the latency, as it needs to be able to support holding data for the whole round-trip-time. see below |
|||
===Window Buffer Size=== |
|||
Increasing the window size may help with throughput. |
|||
The window buffer size needs to be larger the larger the latency, as it needs to be able to support holding data for the whole round-trip-time. |
|||
The way TCP works is that the sender is not allowed to send more data than would fit in the receiver's incoming TCP window (which the sender knows the size of). |
|||
The sender only gets to know how much room is left in the receiver's buffer after each ACK comes back, which is the round-trip time since the data was sent |
|||
Which means there can never be more data in flow than would fit in the receiver's buffer. |
|||
This used to be a problem with older MS-windows machines which had small TCP windows - but is less of a problem now. |
|||
[[Category: |
[[Category:FireBrick IPsec|Throughput Speed]] |
||
Latest revision as of 23:59, 14 March 2017
On a FB 2700, throughput should be around 10 - 15Mbit/s.
Here is a speedtest from a Road Warrior on a good internet connection connected to a FB2700 on a single 60Mbit/s down and 20Mbit/s up FTTC, using HMAC-SHA1
A FB6000 can do nearer 50Mbit/s, whilst newer generation of FireBrick hardware should be even better.
Other notes on throughput
If an IPsec connection is slow, it is useful check a few other things. Latency can have large impact on e.g. a TCP connection so it's good to:
- Try a ping with a large payload (e.g. 1400 bytes)
- The window buffer size needs to be larger the larger the latency, as it needs to be able to support holding data for the whole round-trip-time. see below
Window Buffer Size
Increasing the window size may help with throughput.
The window buffer size needs to be larger the larger the latency, as it needs to be able to support holding data for the whole round-trip-time. The way TCP works is that the sender is not allowed to send more data than would fit in the receiver's incoming TCP window (which the sender knows the size of). The sender only gets to know how much room is left in the receiver's buffer after each ACK comes back, which is the round-trip time since the data was sent Which means there can never be more data in flow than would fit in the receiver's buffer. This used to be a problem with older MS-windows machines which had small TCP windows - but is less of a problem now.