[ovs-discuss] How to support traceroute using OVS

Chao Hu chao.hu at ericsson.com
Wed Dec 2 09:21:14 UTC 2015

Pls see my comment inline with [CH]:


-----Original Message-----
From: Ben Pfaff [mailto:blp at ovn.org] 
Sent: Wednesday, December 02, 2015 2:54 AM
To: Nicholas Bastin
Cc: Chao Hu; discuss at openvswitch.org
Subject: Re: [ovs-discuss] How to support traceroute using OVS

On Mon, Nov 30, 2015 at 02:53:46PM -1000, Nicholas Bastin wrote:
> 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.

That's reasonable.  I added that comment to the bug report I filed.

> > 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.

[CH] we want to support traceroute for both IP and MPLS cases. Actually there's another issue here that when push mpls label, its TTL is copied from the IP TTL, but when pop mpls label, now seems there's no way to copy mpls TTL back to IP TTL. I think it'll be useful if provide a load action for TTL field. Then the user/controller can decide whether to copy TTL back or not.

> 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.

I guess I need to step back a bit.  So far, with OVN, we're planning to

    - TTL exceeded handling via ICMP.  I believe that this is the
      primary requirement for "traceroute" to succeed.

    - Replies to ICMP echo requests, for packets directed to an L3
      logical router IP.

    - UDP port unreachable, TCP reset, and protocol unreachable replies,
      for packets directed to an L3 logical router IP.

    - Network unreachable replies, for packets for which an L3 logical
      router has no route.

I don't need much guidance on the implementation mechanisms for these; I'm comfortable with how to do it.  I'm really looking for advice of the form "You're forgetting about <important message>."  Your information about MPLS extensions to ICMP, for example, is interesting and new to me, although I'm not sure whether it's relevant given that OVN doesn't yet have anything to do with MPLS.

PMTU is a good point.  We don't have a good story around MTU issues yet.

More information about the discuss mailing list