Interface Bonding & Kernel IP routing table issue

[Robbie]

I've got an insidious issue with my Active/Standby Bond that provides 10GbE to one switch and a fault-only 1GbE link to another switch.

Mostly it works ok with links going up and down and to the DSM GUI it reports either 10GbE or 1GbE being used by the bond, depending on which link/links are up. But sometimes it gets in a muddle and actually locks on the 1GbE link whilst displaying otherwise to the GUI. Clearly the performance collapses when in this state.

Digging into it further the Bond is misconfigured (under the hood) and it is associating the IP of the 10GbE port to the Bond but using the MAC address of the 1GbE port.

The Bond itself:

Rob@Rivendell:/$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.1.1        0.0.0.0         UG        0 0          0 bond0
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 bond0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
Rob@Rivendell:/$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.1.1        0.0.0.0         UG    0      0        0 bond0
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 bond0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

Bond split into respective interfaces:

Rob@Rivendell:/$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.1.1        0.0.0.0         UG        0 0          0 eth4
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 eth4
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 eth1
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
Rob@Rivendell:/$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.1.1        0.0.0.0         UG    0      0        0 eth4
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth4
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth1
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
Rob@Rivendell:/$

To my eyes the issue seems to be the conflation of DSM not adding a Routing Table Metric to any interface and the 10GbE PCIe card registering as eth4 and the 1GbE LAN as eth1, effectively giving it the lowest priority due to the absence of a Routing Metric. The variance in actual behaviour observed seen is probably down to the link bandwidth scoring, timing of link up/down and plain luck.

In regular linux I would apt-get install ifmetric to set the metric value on the interfaces as required to achieve the correct priority.

Is there a 'DSM way' to correctly fix this issue?

Can I install ifmetric ( eg ipkg install ifmetric ) and have it work and survive a future DSM update?


️


[I have never installed anything on DSM other than via Package Centre, so this may be new to me]

 

[jeyare]

ipkg install <pkg> survives DSM upgrades, otherwise it will be problem for people who needs more than check version of the kernel

into:
/opt/bin

then
export PATH="$PATH:/opt/bin"

 

[Robbie]

@jeyare Thanks and I may need the exact syntax required for the CLI bit but is the ipkg package compatible with DSM7, as I am reading some conflicting sources that suggested that it effectively died after DSM6?

If DSM7 did kill ipkg I guess entware would be the best replacement or will dpkg do the job?

️

[I am running 3 of my 4 Syno NASes at the moment; primary is on DSM6 for now, with the other 2 on DSM7.0]

 

[jeyare]

Can’t confirm that, here is everything on DSM6

 

[Robbie]

A wise man indeed

️