There is some weird behavior of ip-rule with specific IP ToS-values. It works fine just with values up to 0x10, but doesn't accept DSCP-part.

I tried:

ip ru a tos 0x20 table 1234

And got:

RTNETLINK answers: Invalid argument

TOS was defined in RFC 791 and further in RFC 1349 with only 4 possible bits as seen in RFC 1349's chapter 3:

            0     1     2     3     4     5     6     7
         |                 |                       |     |
         |   PRECEDENCE    |          TOS          | MBZ |
         |                 |                       |     |

and 4:

                1000   --   minimize delay
                0100   --   maximize throughput
                0010   --   maximize reliability
                0001   --   minimize monetary cost
                0000   --   normal service

As the MBZ (must be zero) bit is reserved and precedence was (allegedly?) never really used, there are only even values between 0x00 and 0x1E possible. Linux defines this in ip.h:

#define IPTOS_TOS_MASK        0x1E
#define IPTOS_TOS(tos)        ((tos)&IPTOS_TOS_MASK)
#define   IPTOS_LOWDELAY      0x10
#define   IPTOS_THROUGHPUT    0x08
#define   IPTOS_RELIABILITY   0x04
#define   IPTOS_MINCOST       0x02

and ip rule ('s kernel part) is just following those definitions to tell what is allowed.

Now if you want instead to use DSCP defined in RFCs 2474 to be an alternate mechanism replacing the TOS view of the same byte (along with ECN in RFC 3168), there doesn't appear to exist a direct equivalent using ip rule.

What you can still do instead, is use iptables or nftables to match the dscp field value then mark the packet and reuse it with fwmark in ip rule.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.