How are you sending the packets and what exactly do you see with tcpdump? 1480 is a suspicious length since it is the maximum payload of an IP packet, not a GRE packet. It sounds like the host is simply fragmenting the packet before it gets to OVS.
On Fri, Aug 23, 2013 at 5:47 PM, Theodore Elhourani <telho...@email.arizona.edu> wrote: > This is version 1.10. > > Setting the MTUs to take into account the additional GRE headers, was > actually the only way to get packets of 1480<size<1500 to show up on the > tunnel. > > > > > > On Fri, Aug 23, 2013 at 4:55 PM, Jesse Gross <je...@nicira.com> wrote: >> >> On Thu, Aug 22, 2013 at 5:24 PM, Theodore Elhourani >> <telho...@email.arizona.edu> wrote: >> > If the original packets are of length <= 1400, then they are >> > successfully >> > transmitted through the tunnel. Only when a packet is greater than ~1480 >> > it >> > gets dropped. You are right the ip stack is fragmenting the large >> > packets, >> > but because some of them are a notch below 1500 they are passed as is. >> > For >> > these packets, adding gre/ip headers would increase their size to > >> > 1500bytes. Subsequently they are dropped. The reason may be because the >> > packets are already beyond the ip stack of the host, and no further >> > manipulation of the packets is done after this point. >> >> What version is this? If it is before 1.9 then setting >> header_cache=false in the tunnel options may help. >> >> > Reducing the size of packets, via MTU tweaking, seems to be a common >> > practice when gre is used. Any ideas on this ? >> >> Regardless of the outcome of the above, setting the MTUs to take into >> account the additional GRE headers will improve performance. > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss