@@ -241,7 +241,13 @@
<p>
This table is the core of the logical router datapath functionality. It
contains the following flows to implement very basic IP host
- functionality:
+ functionality.
+ </p>
+
+ <p>
+ Logical flows in this table that advance to the next table set
+ <code>reg0</code> to the next-hop IP address. (<code>ip4.dst</code>, the
+ final destination, is left unchanged.)
</p>
<ul>
> Maybe it's obvious to others, but my first thought was that this was
> the original "ip.dst", but now that I look at it more carefully, my
> guess is that it is the original "ip.src". It might be good to add a
> comment to clarify.
I guess that's about this line:
reg0 = ip4.dst;
so I changed it to:
reg0 = ip4.dst; // Route back to original IP source.
> Finally, should it always be the original source IP? If we have
> multiple routers in between, shouldn't it be the gateway's address?
> (This question holds for all the places where reg0 is being set.)
XXXXXXXXXXXXx
> > +next;
> > +</pre>
>
> Is it possible in these examples to have "<pre>" and "</pre>" line up?
I thought that the spaces would result in an extra blank line but it
doesn't seem to make a difference. I must misunderstand some subtlety
of XML or nroff. Anyway, I made the change, it does look better.
> > + <li>
> > + <p>
> > + TCP reset. These flows generate TCP reset messages in reply to TCP
> > + datagrams directed to the router's IP address. The logical router
> > + doesn't accept any TCP traffic so it always generates such a reply.
> > + </p>
>
> Do you want to add the comment about not matching on IP fragments with
> nonzero offset like you did for UDP and protocol unreachable? (TCP
> shouldn't generate IP fragments, but it can happen.)
OK.
> > + <p>
> > + Protocol unreachable. These flows generate ICMP protocol unreachable
> > + messages in reply to packets directed to the router's IP address on
> > + IP protocols other than UDP, TCP, and ICMP.
> > + </p>
>
> I think for all of these error generators, we should consider some
> sort of rate-limiting. Obviously, this is a little complicated if we
> want to do it in ovs-vswitchd--especially in the fast path.
I agree. I've thought about that, but I don't have a detailed design
for it.
For now I've added a TODO item:
@@ -260,6 +260,15 @@ those that become stale.
*** MTU handling (fragmentation on output)
+** Ratelimiting.
+
+*** ARP.
+
+*** ICMP error generation, TCP reset, UDP unreachable, protocol unreachable, ...
+
+As a point of comparison, Linux doesn't ratelimit TCP resets but I
+think it does everything else.
+
* ovn-controller
** ovn-controller parameters and configuration.