Thread (7 messages) 7 messages, 3 authors, 2017-12-13

Re: BUG REPORT: iproute2 seems to have bug with dsfield/tos in ip-rule and ip-route

flat view

From: David Ahern <hidden>
Date: 2017-12-13 23:06:00

On 12/13/17 3:52 PM, Daniel Lakeland wrote:
On 12/13/2017 02:40 PM, David Ahern wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help