Hi Jason, Jason Haar wrote: > Hi there > > I'm on an "openvpn optimization drive" (ie it's all working great and > I'm trying to squeeze more greatness out of it) and reading the Internet > (took a while ;-) leads me to a confused state on the usefulness of > "fragment". > > There are several postings by long-term openvpn gurus who seem to lead > their diagnostics of other people's openvpn connectivity problems with > "remove the fragment option". I, on the other hand, have found that I > have NEVER got openvpn-over-udp to work without it! It looks to me like > it cannot even get through the initial negotiation phase without > fragment being enabled at both ends (I use 1400 - but that's just a lazy > guess that works) > > In fact, I just did a related test. I removed "fragment" from the server > and only set it on the client - end result, NO CONNECTION. Put that one > line back (identical fragment values of course) and it all works again > > the thing is - either both client and server have 'fragment' set or neither of them. If either end sets the 'fragment' option then indeed the connection will not work. > So I have two questions. > > 1. it looks to me like fragment is always needed for UDP. If so, > shouldn't that be declared more strongly (maybe even error-ing on > configs without it). > not entirely true - if you remove it on both ends then it works (just tested this )
> 2. shouldn't both ends negotiate the fragment option and both ends > should use the *smallest* value (or maybe "fragment automatic" as an > option to achieve it), so that the server can have it disabled, and the > client (where fragmentation issues are vastly more variable) can control > it. However, my test makes me think that maybe even openvpn negotiation > can create packets big enough to break negotiation? (ie that option has > to pre-date the initial connection) > > what is not very well known is that the fragment option does not need to be symmetric. All that the 'fragment' option does is that it tells the openvpn process to break up UDP packets into smaller bits before sending them. The client side will re-assemble them no matter what the setting is on the server side. Thus, you could set a 'sane' value on the server side (e.g. fragment 1500 or fragment 1472) and tweak the clients on a per-case scenario. I just ran some tests with a server with --fragment 1440 and the client had --fragment 100 perf: 10 Mbps --fragment 500 perf: 22 Mbps --fragment 1500 perf: 50 Mbps without openvpn: perf ~ 60 Mbps (the client is on a wifi network) Thus, for your setup it would make sense to add fragment 1500 (or 1472, it might cause a little less fragmentation) to the server config and then add 'something default' to the client side. I hope this clarifies things a bit, JJK ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
