Wie kann ich die Metrik für Interfaces einstellen?

[jayrock]

Hallo,

ich habe zwei Interaces bond0 und eth2 mit der gleichen Destination 192.168.0.0 . Wie kann ich die Metrik für die Interfaces einstellen, um auszuwählen, welches Interface für diese Destination gewählt wird?

root@Diskstation:/# ifconfig bond0
bond0 Link encap:Ethernet HWaddr 00:11:32:E4:AA:C8
inet addr:192.168.0.104 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::211:32ff:fee4:aac8/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:9000 Metric:1
RX packets:122600 errors:0 dropped:0 overruns:0 frame:0
TX packets:354968 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:31191708 (29.7 MiB) TX bytes:1196618370 (1.1 GiB)

root@Diskstation:/# ifconfig eth2
eth2 Link encap:Ethernet HWaddr A0:CE:C8:F9:27:9E
inet addr:192.168.0.105 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::a2ce:c8ff:fef9:279e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:1228624 errors:0 dropped:0 overruns:0 frame:0
TX packets:305838 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1479578174 (1.3 GiB) TX bytes:26974669 (25.7 MiB)

Beste Grüße,
jayrock

 

[Benares]

Danach hab ich auch schon gesucht, aber nichts gefunden.
Aber ich vermute, die Einstellung der "Dienstreihenfolge" (Netzwerk/Netzwerkschnittstelle/Verwalten) bewirkt ähnliches. Das schnellste Interface sollte oben stehen, die Reihenfolge kann mit Drag&Drop geändert werden.

Edit: Ich habe bei mir die Schnittstellen auf DHCP stehen und ihnen im DHCP-Server unterschiedliche Namen verpasst, wie z.B. "DS1522" (eth4, 10GBit-NIC) und "DS1511-LAN1" (eth0, 1GBit-NIC). So kann man auch ganz gut steuern, welche Schnittstelle man anspricht. Und über diese läuft dann auch die gesamte Kommunikation, soweit ich das bisher beobachten konnte.

 

[jayrock]

Danke @Benares. Zur Klarstellung, mir geht es generell um den Egress-Traffic, und nicht nur bei TCP.

"Service Order" wählt leider nur das Default Gateway aus, aber nicht das Interface. Siehe hier: https://kb.synology.com/en-global/DSM/help/DSM/AdminCenter/connection_network_route?version=7

 

[Benares]

Ja, ich weiß, was in der Hilfe steht. Trotzdem scheint es mehr zu sein, als nur eine reine Priorisierung des Gateways. Probiere es einfach mal aus, welche Wirkung diese Einstellung hat. Und wenn du doch noch ein Möglichkeit zur Einstellung der Metrik findest, lass es uns wissen.

 

[jayrock]

Dann werde ich weiter suchen.

Die Service Order hat übrigens keinen Einfluss - hatte ich schon zuvor ausprobiert. Warum scheint dir das mehr zur sein?

 

[Benares]

Warum scheint dir das mehr zur sein?

Das weiß ich nicht mehr. Ich erinnere mich nur noch dunkel an irgendwelche Diskussionen dazu, entweder hier oder im englischsprachigen Forum.
Fragen zur Metrik gab es schon öfter, aber w.W. keine Lösung. Der DSM ist in vielen Belangen halt leider kein Standard-Linux.

 

[jayrock]

Ich hab's über die Routingtabelle gelöst/gefunden. Die Metriken braucht man gar nicht. Das Problem ist der erste Eintrag.

Die ursrpüngliche Routingtabelle:

(synogear) root@Diskstation:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 bond0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.23.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker-1a95f3f6
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 bond0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2

Jetzt z.B.

(synogear) root@Diskstation:/# sudo route del -net 192.168.0.0 netmask 255.255.255.0 dev bond0

... und die neue Routingtabelle

(synogear) root@Diskstation:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 bond0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.23.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker-1a95f3f6
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2

Jetzt wird der Traffic ins lokale Netz 192.168.0.0 über eth2 ausgeleitet und aller andere Traffic über bond0.

Weiter geht's:

(synogear) root@Diskstation:/# sudo route del -net 0.0.0.0 netmask 0.0.0.0 dev bond0
(synogear) root@Diskstation:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.23.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker-1a95f3f6
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2
(synogear) root@Diskstation:/# sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.0.254 dev eth2
(synogear) root@Diskstation:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 eth2
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.23.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker-1a95f3f6
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth2

Jetzt läuft der gesamte Egress über eth2.

Nach einem Reboot ist alles zurück gesetzt, man brauch also ein Startscript.

Übrigens, beim Starten sieht man schön, dass bond0 zuerst hochkommt und zum Default Gateway wird. Wenn eth2 hochkommt, ändert sich dass Default Gateway nicht mehr.

Beste Grüße,

jayrock

 

[Benares]

Also das Interface für das Default-Gateway zu ändern, kannst du dir sparen genau das macht die Änderung der Dienstreihenfolge schon. Sprich es setzt Iface beim Default-Gateway auf den obersten Eintrag, bei dir wohl bond0.

Gerade bei den beiden Routen ins eigene Netz wäre die Metrik m.E. schon sinnvoll, um einen der Wege zu bevorzugen. Man kann aber auch die Holzhammermethode wählen und eine der beiden entfernen.

Was bezweckst du eigentlich damit? Wozu ist bond0 dann noch da, wenn keine Route mehr über ihn führt?

 

[jayrock]

genau das macht die Änderung der Dienstreihenfolge schon. Sprich es setzt Iface beim Default-Gateway auf den obersten Eintrag, bei dir wohl bond0.

Wie im letzten Post beschrieben. Eben nicht. Das Default-GW bleibt auf bond0, auch wenn ich die Service Order ändere. Das macht auch Sinn, da beide Interfaces im gleichen Segment sind und daher die gleiche Default-Route haben. Steht alles in Post 1.

Was bezweckst du eigentlich damit? Wozu ist bond0 dann noch da, wenn keine Route mehr über ihn führt?

Wie im oben geschrieben, möchte ich den egress steuern. Die DS bliebt weiter über bond0 erreichbar.

Also, Problem gelöst. Danke für deine Hilfe.

 

[Benares]

Also bei mir nicht

LAN5 (eth4) oben:

root@DS1522:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth4
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth3
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth2
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth4

LAN1 (eth0) oben:

root@DS1522:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth3
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth2
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth4

Und wenn du dein NAS nach deiner Modifikation über bond0 ansprichst und Daten liest, laufen die dann über eth2 oder über bond0?

 

[jayrock]

Oh, interessant! Das sieht bei mir anders aus. Kannst du sehen, ob beim Boot deine Interfaces zeitgleich kommen? Mein eth2 kommt erst einige Zeit nach bond0

Ich habe keine Wireshark oder so am laufen, aber ich gehe davon aus, dass jedes Egress-IP-Paket entsprechend der Routing Tabelle auf die Interfaces verteilt wird, also über eth2 rausgeht. Egal UDP oder TCP.

 

[Benares]

Ist das so wichtig, was beim Booten passiert? Wichtig ist doch nur, was am Ende gilt.
Mein eth4 ist ein 10GBit-Nic und ich möchte verständlicherweise, dass alles hauptsächlich darüber läuft. eth0 ist ist eigentlich nur am Netz, weil eth4 kein WOL kann. Außerdem kennt der DSM eth4 erst nach dem Booten, da das Bios nur 1GBit-Devices kennt. eth4 kommt daher immer verzögert hoch.

Aber ich hab auch auf meiner DS415 geschaut, die hat einen 1GBit-NIC als LAN1 und 2 (eth0/eth1, eth1 nicht angeschlossen) und einen 2,5GBit-USB-NIC als LAN3 (eth2). Da ist es aber genauso, das 1. Interface bei der Dienstreihenfolge steht als Iface beim Default-Gateway.

Du brauchst kein Wireshark. Schau dir einfach die NIC-Auslastung im Ressourcen-Monitor unter Netzwerk an. Da siehst du, über welches Interface der Hauptteil der Kommunikation läuft.

 

[jayrock]

Ich glaube, das hast du was missverstanden. Schau dir mal deinen Post von 15:29 an. Wo gehen die Pakete raus, die du an dein LAN Segment schickst? Sowohl eth0 als auch eth4 haben das als Destination und beide haben die gleiche Prefix-Länge. Der Algorithmus kann frei entscheiden, welches Interface er nimmt, also nimmt er das erstbeste und das ist eth0.

Wenn deine Peers allesamt in einem anderen Netz sind, ist das egal, weil der Verkehr über das Gateway läuft. In meinem Fall sind viele Peers im gleichen Segment, und ich hätte gerne, dass auch der Egress über eth2 (oder eth4 bei dir) läuft.

Lass doch mal iperf laufen auf einem Host, der mit 10GbE angebunden ist. Wenn der Host der iperf-Client ist, bekommst du 10 Gbps, alles prima. Wenn der Client aber auf der Diskstation ist, wirst du nur 1 Gbps Durchsatz haben. Die 10 Gbps erreichst du nur, wenn du die Route nach 192.168.0.0 über eth0 rausnimmst.

 

[Benares]

Nein, ist nicht so. Wenn ich meine NASe über das schneller Interface anspreche (s. Edit in #2) kommen auch die Daten über dieses Interface. Die antworten immer über das Interface, über das sie auch angesprochen werden. Wenn beide Interfaces im DNS den gleichen Namen, geb ich dir Recht, dann entscheidet mein Client (z.B. \\DS1522) zuerst, welches Interface er anspricht - und darüber kommt auch die Antwort.