基於tos返回錯誤網關的Linux路由策略

我在 Docker 上執行了一個模擬的 ad-hoc 網路，使用 Ubuntu 16.04 作為基礎。

我有許多路由表。有問題的表，表 102，顯示為：

root@b22e0eafe06d:~# ip route show table 102
172.17.0.3 via 172.17.0.3 dev eth0  proto static
172.17.0.4 via 172.17.0.4 dev eth0  proto static
172.17.0.5 via 172.17.0.3 dev eth0  proto static
172.17.0.6 via 172.17.0.3 dev eth0  proto static
172.17.0.7 via 172.17.0.3 dev eth0  proto static
172.17.0.8 via 172.17.0.3 dev eth0  proto static
172.17.0.9 via 172.17.0.3 dev eth0  proto static

還有一些策略規則，包括將 ToS 設置為 0x02 的任何內容定向到表 102 的規則：

root@b22e0eafe06d:~# ip rule list
0:  from all lookup local
1:  from all tos 0x02 lookup 102
2:  from all tos 0x04 lookup 104
3:  from all tos 0x06 lookup 106
4:  from all tos 0x08 lookup 108
32766:  from all lookup main
32767:  from all lookup default

但是，當我做一個ip route get 172.17.0.9 tos 0x02，當我應該172.17.0.3作為網關返回時，我得到172.17.0.4：

root@b22e0eafe06d:~# ip route get 172.17.0.9 tos 0x02
172.17.0.9 via 172.17.0.4 dev eth0  src 172.17.0.2
   cache

這恰好是要選擇的網關，並且使用了主路由表。我懷疑引用 tos 0x02 的規則由於某種原因不匹配。

我將規則 1 替換為將所有發往 172.17.0.9 的數據包發送到表 102 的規則，並且成功了。我得出的結論是表 102 正在工作，但由於某種原因，在 tos 0x02 上的匹配不是。

root@b22e0eafe06d:~# ip rule del priority 1
root@b22e0eafe06d:~# ip rule add to 172.17.0.9 table 102
root@b22e0eafe06d:~# ip route get 172.17.0.9
172.17.0.9 via 172.17.0.3 dev eth0  src 172.17.0.2
   cache

有什麼解釋嗎？

順便說一句，當我嘗試使用其他 tos 值（例如 0x04、0x08）進行路由時，它看起來正在工作。是 0x02 出現問題。我正在使用自定義 tos 值進行測試。

想通了，問題是我使用的 tos 值。

在數據標頭中，tos 由 8 位表示。有許多 RFC 規定瞭如何解釋這些位，但在所有情況下，只有最高 6 位與 tos 相關。最低 2 位保留用於附加資訊（例如，擁塞通知）。

在策略規則中設置 tos 時，您設置的是整個欄位（全部 8 位）。由於我使用的 0x02 的值僅設置 2s 列位，因此它被解釋為 0x00 （基本上根本沒有 tos）。

因此，重要的是要記住，當您選擇 tos 值時，在分配它們之前將位向左移動 2 個位置。

引用自：https://serverfault.com/questions/942379