On Thu, Nov 26, 2015 at 9:44 PM, Chao Hu <[email protected]> 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). OFPR_INVALID_TTL is still a valid ofp_packet_in_reason even in 1.4 (whose changelog claims that reason to have been added in 1.4, but in fact was added in 1.3), but it doesn't ever specify how that reason would be set in a packet_in. 1.3 removed the config option (OFPC_INVALID_TTL_TO_CONTROLLER) that allowed the user to set what behaviour they wanted directly, but replaced it with a per-controller-connection mechanism for filtering messages to be sent based on type and reason (A.3.10 in the 1.3 spec), so you can still in theory get the same behaviour (although general implementation is more difficult on the vendor side, so whether that filter is available is a per-device / per-firmware question). There is still the open question of how this packet-in reason gets set at all, regardless of connection filters (also there's no real way to be sure that your async filters were actually applied, other than knowing they weren't when you receive a message you had asked to be filtered). > 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). > 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. You *could* try to send this to your controller, as it seems that you are doing, but ultimately this is very expensive and not a scalable solution, on top of even the basic scenarios already not working. -- Nick
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
