Yeah, later on we have found that it was, again, more important that we think.
For example, there are still cases not covered by TCP MSS negotiation (or for UDP/other protocols): Imagine you have two clouds, both with an internal MTU (let’s imagine MTUb on cloud B, and MTUa on cloud A), and an external transit network with a 1500 MTU (MTUc). MTUb > MTUc. And MTUb > MTUc Also, imagine that VMa in cloud A, has a floating IP (DNAT_SNAT NAT), and VMb in cloud B has also a floating IP. VMa tries to establish connection to VMb FIP, and announces MSSa = MTUa - (IP + TCP overhead), VMb ACKs the TCP SYN request with MSSb = MTUb - (IP - TCP overhead). So the agreement will be min(MSSa,MSSb) , but… the transit network MSSc will always be smaller , min(MSSa, MSSb) < MSSc. In ML2/OVS deployments, those big packets will get fragmented at the router edge, and a notification ICMP will be sent to the sender of the packets to notify fragmenting in source is necessary. I guess we can also replicate this with 2 VMs on the same cloud with MSSa > MSSb where they try to talk via floating IP to each other. So going back to the thing, I guess we need to implement some OpenFlow extension to match packets per size, redirecting those to an slow path (ovn-controller) so we can Fragment/and icmp back the source for source fragmentation? Any advise on what’s the procedure here (OpenFlow land, kernel wise, even in terms of our source code and design so we could implement this) ? Best regards, Miguel Ángel. On 3 August 2018 at 17:41:05, Daniel Alvarez Sanchez (dalva...@redhat.com) wrote: Maybe ICMP is not that critical but seems like not having the ICMP 'need to frag' on UDP communications could break some applications that are aware of this to reduce the size of the packets? I wonder... Thanks! Daniel On Fri, Aug 3, 2018 at 5:20 PM Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > > We didn’t understand why a MTU missmatch in one direction worked (N/S), > but in other direction (S/N) didn’t work… and we found that that it’s > actually > working (at least for TCP, via MSS negotiation), we had a missconfiguration > In one of the physical interfaces. > > So, in the case of TCP we are fine. TCP is smart enough to negotiate > properly. > > Other protocols like ICMP with the DF flag, or UDP… would not get the ICMP > that notifies the sender about the MTU miss-match. > > I suspect that the most common cases are covered, and that it’s not worth > pursuing what I was asking for at least with a high priority, but I’d like > to hear > opinions. > > > Best regards, > Miguel Ángel. > > On 3 August 2018 at 08:11:01, Miguel Angel Ajo Pelayo (majop...@redhat.com) > wrote: > > I’m going to capture some example traffic and try to figure out which RFCs > talk about that behaviour so we can come up with a consistent solution. > I can document it in the project. > > To be honest, when I looked at it, I was expecting that the router would > fragment, and I ended up discovering that we had this path MTU discovery > mechanism in play for IPv4 . > > On 2 August 2018 at 22:21:28, Ben Pfaff (b...@ovn.org) wrote: > > On Thu, Aug 02, 2018 at 01:19:57PM -0700, Ben Pfaff wrote: > > On Wed, Aug 01, 2018 at 10:46:07AM -0400, Miguel Angel Ajo Pelayo wrote: > > > Hi Ben, ICMP is used as a signal from the router to tell the sender > > > “next hop has a lower mtu, please send smaller packets”, we would > > > need at least something in OVS to slow-path the “bigger than X” > packets, > > > at that point ova-controller could take care of constructing the ICMP > packet > > > and sending it to the source. > > > > Yes. > > > > > But I guess, that we still need the kernel changes to match on > > > those “big packets”. > > > > Maybe. If we only need to worry about ICMP, though, we can set up OVN > > so that it always slow-paths ICMP. > > Oh, I think maybe I was just being slow. The ICMP is generated, not > processed. Never mind. > >
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
