<div dir="ltr">Thank you Paul.<div>It turns out that we do have some other issue. We somehow could not repro it later and things look fine now.</div><div><br></div><div>Thanks,</div><div>Xinwei</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 23, 2017 at 8:25 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 21 Mar 2017, Xinwei Hong wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We noticed that the packets are fragmented around 332bytes (raw data about 244B). This value is much smaller<br>
than what we expected and it affects performance. Is this configurable? I noticed we have a ike-frag option,<br>
but that sounds like only apply to IKE, not to IPSEC esp packets. The sender sends packet with size around<br>
1000B.<br>
</blockquote>
<br></span>
You can set mtu= which causes a route to be added with the specified<br>
mtu to work around this.<br>
<br>
But IPsec is not fragmenting at 332 bytes. In fact, isn't that smaller<br>
then the minimum allowed MTU size? It seems you have another non-IPsec<br>
problem on your network that needs addressing.<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>