[ovs-discuss] How to support traceroute using OVS

Nicholas Bastin nick.bastin at gmail.com
Tue Dec 1 00:53:46 UTC 2015


On Sun, Nov 29, 2015 at 9:38 AM, Ben Pfaff <blp at ovn.org> wrote:

> I've filed a bug report EXT-559 with the ONF working group, so perhaps
> we can at least get "invalid TTL" defined for OF1.6.


My $0.02 - this shouldn't be in the spec at all.  It's a wart that a given
packet field gets special handling, although I realize this at least
partially reflects some existing ASIC realities.

The "right" way, I think, to deal with this would be to permit matching on
TTL and then executing the user instructions - then we don't get into a
silly discussion over what is "invalid", the user/controller simply sets
their intention.  At the very least perhaps it can move into a table
config, but I *definitely* don't want the spec written to say that packets
with TTL==(0|1) having some specific handling, when there's no
one-size-fits-all answer.

> You probably can't, at least not in a wholly satisfactory way, without
> > modifying the source to OVS, or inlining a function (linux tap interface
> > driver, etc.) in the path on each port.  What you really want to do is
> get
> > OVS to issue a packet-out of an ICMP Time Exceeded when an incoming
> packet
> > reaches a TTL of 0 within the pipeline (modulo the times when you
> actually
> > should send a Destination Unreachable reply), but this has all kinds of
> > nasty edge cases.
>
> We're working to make this possible.  What kinds of nasty edge cases do
> you have in mind?  I'd like to make everything as correct as possible,
> obviously.
>

Well, my first question would be what is "this" that you're working to make
possible.. :-)  If it's "traceroute", that's a tricky mess, because of
course traceroute is just a tool that relies on a side-effect of another
protocol.  As there's no actual traceroute protocol, you can't classify
packets as belonging to traceroute, and thus if you "only" implement the
bits that make traceroute work, you're likely to break a lot of other
things that experience half-implemented IP error handling (traceroute works
but PMTU-D doesn't?  That's going to confuse some hosts.  There are more
things along these lines.)

If the answer is "match TTL=0 (or X) packets and send them to the
controller", that's the easiest solution from the datapath standpoint as it
just punts the responsibility to the controller.  Even in a perfect world
this will result in the timing information presented by the traceroute tool
to be even more useless than it already is given the extra RTT and
encapsulation/decapsulation time.  If you were to try to handle this within
the datapath without going to the controller, the configuration gets a bit
out of hand (you need at the very least one MAC, and you need to have an IP
you're at least pretending to be, and if you have more than one of each now
you need some way to figure out which one you actually use in a given
circumstance, and you need to handle a traceroute actually ending at your
own IP, and don't look now but you're halfway to making a router.. :-))
 Similarly you need to identify when  MPLS ICMP extensions apply (RFC 4950,
I think), and whether you want to enable supporting traceroute using IP
options (although I think it was later deprecated due to lack of
deployment).  There are actually more complications (fragmentation, as
always, etc.), but I'm mostly writing this off the top of my head...  I'm
happy to be more thorough when I know more specifically what you're
actually trying to enable.

--
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20151130/8543bda5/attachment-0002.html>


More information about the discuss mailing list