<div dir="ltr">Hi Greg,<div><br></div><div>As I am doing unwell today, I didn&#39;t try it with the latest version.</div><div><br></div><div>I will do it tomorrow and update you on that.</div><div><br></div><div>Thank you!</div><div><br></div><div>-</div><div>Keerthana</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 21, 2019 at 4:31 AM Gregory Rose &lt;<a href="mailto:gvrose8192@gmail.com">gvrose8192@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 3/19/2019 6:25 PM, Ben Pfaff wrote:<br>
&gt; On Tue, Mar 19, 2019 at 05:19:42PM +0530, Ammu wrote:<br>
&gt;&gt; <a href="https://stackoverflow.com/questions/55223517/allow-df-not-to-be-set-on-gre-vxlan-tunnels" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/55223517/allow-df-not-to-be-set-on-gre-vxlan-tunnels</a><br>
&gt; That question reads:<br>
&gt;<br>
&gt;      I have created a bridge with a tunnel interface(be it either<br>
&gt;      vxlan/gre) and an internal interface. When incoming packets get<br>
&gt;      encapsulated with either vxlan/gre tunnel header, I don&#39;t want the<br>
&gt;      DF bit set on the outer IP layer of tunnelled packet.<br>
&gt;<br>
&gt;      Despite setting df_default tunnel option to False while creating the<br>
&gt;      tunnel interface, I get the DF bit set on the outer IP layer of the<br>
&gt;      tunnelled packet.<br>
&gt;<br>
&gt; Glancing through the userspace and datapath code in the tree, it looks<br>
&gt; to me like the DF setting propagates through the whole stack, so I&#39;m<br>
&gt; surprised there&#39;s a bug.  Perhaps Greg can take a look at some point, if<br>
&gt; he has time.<br>
<br>
I&#39;ll review the code but as you&#39;ve pointed out, the code bases used are <br>
very old.  I&#39;d suggest 2.10 at least since<br>
that&#39;s when we did a total review and upgrade of gre tunneling code to <br>
support erspan as well.  A lot has<br>
changed since 2.9.0<br>
<br>
Thanks,<br>
<br>
- Greg<br>
<br>
&gt;<br>
&gt; We probably need to know what version of OVS you&#39;re using, what version<br>
&gt; of the kernel you&#39;re running, and whether you&#39;re using the Linux kernel<br>
&gt; built-in version of the OVS kernel module or the one that is shipped<br>
&gt; with OVS itself.<br>
<br>
</blockquote></div>