On Sun, Nov 29, 2015 at 9:38 AM, Ben Pfaff <[email protected]> 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
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
