On 12/13/17 3:52 PM, Daniel Lakeland wrote: > On 12/13/2017 02:40 PM, David Ahern wrote: >> >> In fib4_rule_configure, this the check that is failing: >> >> if (frh->tos & ~IPTOS_TOS_MASK) >> goto errout; >> >> and EINVAL is returned. >> >> IPv4 routes has not checking on tos -- it is passed from user and >> rtm_tos to fc_tos to fib alias tos. > > it seems to me that this IPTOS_TOS_MASK check should be either gotten > rid of, or equal to 0x03 in modern usage. The bottom 2 bits are ECN and > I suppose someone might want to route based on congestion... and hence > maybe the mask should be dropped entirely, but if you refuse to allow > routes on ECN then you'd want 0x03 as the mask > > it seems to me this is left over from before DSCP. > > apparently most people don't route on DSCP or work around this with > firewall marks, and so this doesn't cause trouble enough to have been > reported before? > > I think the follow up question is does anyone have any idea why someone > who set up routes with dsfield settings is not seeing packets routed? > The kernel may not handle ip rule with DSCP, but it takes > > ip route add default dsfield CS6 dev veth0 > > just fine... and shows up in the route table, but for example the person > is not seeing CS6 marked packets going to veth2 and instead is seeing > them routed to veth0 the default route... > >
If you are running a modern kernel (>= ~4.5) there are fib tracepoints you can use to try to answer that: perf record -e fib:fib_table_lookup -a -g perf script [-G] I've had some doubts about tos handling in the output path but have not had the time (or motivation) to dig into it. Specifically, the tos adjustments in ip_route_output_key_hash look weird to me.
