[ovs-discuss] How to support traceroute using OVS

[Ben Pfaff]

On Fri, Nov 27, 2015 at 11:23:09PM -1000, Nicholas Bastin wrote:
> On Thu, Nov 26, 2015 at 9:44 PM, Chao Hu <chao.hu at ericsson.com> wrote:
> 
> >  In the ovs-ofctl manual, it’s said in dec_ttl action that “If controller
> > ids are not specified, the “packet_in” message will be sent only to the
> > controllers having controller id zero which have registered for the invalid
> > ttl packets.”  In my test, I didn’t specify the controller’s controller-id,
> > which should have 0 by default.  And it’s said in the code of ofproto.c
> > that “OFPC_INVALID_TTL_TO_CONTROLLER is deprecated in OF 1.3”, does it
> > mean in OF1.3, “packet_in” on invalid ttl will be sent by default and no
> > register is needed? Or such packet-in is not supported in OF1.3?
> >
> 
> The spec is unclear.  In fact it doesn't even specify what an "invalid TTL"
> value would actually be.  (The OF 1.1 spec specified "invalid" as 0 or 1 in
> a code comment, but future specs seem to have eliminated even that hint of
> what values qualifies as "invalid" - I did not then, nor do I now, know why
> 1 would be regarded as an invalid TTL value for a packet transiting a
> layer-2 switch).

Well, that's a mess.

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.

> > BTW, match on “nw_ttl” seems also not supported in OF1.3.
> >
> 
> This was never supported in the spec, but it's possible that OVS supported
> that match field at some point (I'm not sure).

Yes, OVS has supported matching on the IPv4/v6 TTL/hop limit since Open
vSwitch version 1.4.

> > How to solve this problem?
> >
> 
> 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.