Linux Routing

[Florian Lohoff]

On Fri, Jan 16, 2026 at 05:30:03PM +0100, lug at hoetger.org wrote:
>Moin,
>ich hatte gedacht, ich hätte das mit dem Routing verstanden.
>Ist aber offenbar doch nicht so.
>
>Kann mir jemand erklären, warum 1.1.1.1 durch das VPN
>geroutet wird und nicht direkt über die Defaultroute
>rausgeht?
>
>hajo at ryzen:~$ ip route get 1.1.1.1
>1.1.1.1 dev wg_fritz table 52110 src 192.168.178.203 uid 1000
>    cache
>hajo at ryzen:~$ ip r
>default via 172.19.88.94 dev wlo1 proto dhcp src 172.19.88.122 metric 600
>172.19.88.0/24 dev wlo1 proto kernel scope link src 172.19.88.122 metric 600
>192.168.178.0/24 dev wg_fritz proto static scope link metric 50
>192.168.178.0/24 dev wg_fritz proto kernel scope link src 192.168.178.203 metric 50

Also - die anderen beiden haben ja schon geschrieben was du dir ansehen 
kannst.

Der Trick hier ist das es mehr als eine routing tabelle geben kann. Es
gibt eine "default" table - die hast du dir ja mit "ip r" angesehen.

Jetzt kann es mehr als eine geben (z.b. du hast 2 Interfaces und beide 
sollen traffic der da ankommt da auch wieder raus schieben).

Aber zusätzlich zu den routing tabellen musst du dem kernel noch sagen 
wenn er denn welche routingtabelle nehmen soll.

Das wird über "ip rule"s gemacht

Default setup:

flo at p5:~$ sudo ip rule  
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Hier sieht man schon das es im default schon 3 routing tabellen gibt.
Das wird genutzt um die verschiedenen routen zu separieren. Denn das
was du mit "ip r" siehst ist ja nur das was du manuell konfigurierst.
Dazu kommen ja multicast, loopback und so dinge wie broadcast etc.
Das wird alles in der "local" versteckt.

Wie man in den rules sieht werden die einfach nacheinander angefahren.

Was du jetzt dir mit "ip r get 1.1.1.1" angesehen hast ist nicht die routing
tabelle sondern der "route cache". Sieht man an dem "cache" am ende.

Wobei den "route cache" gibt es wiederum gar nicht mehr. Das ist jetzt
der FIB (NH) Cache. (FIB -> Forward Information Base)

Denn sagen wir du hast den route lookup gemacht dann weisst du das du 
dein paket bei 192.168.178.1 abkippen willst. Das würde aber bedeuten 
das du für jedes paket wieder einen ARP Lookup im cache machen müsstest.
Um das zu beschleunigen werden die nexthop informationen für jede 
destination im fib cache abgelegt.

Der FIB Cache ist dann auch wieder mehrteilig. Mit realen und exception
destinations. In dem zeugs wird dann auch die Path MTU information und
IIRC die RTT abgelegt (Initialisierung des TCP congestion algo)

Also - es ist alles noch viel viel viel komplexer als man so glaubt - 
das liegt zum großteil da dran das man da performance rauskitzeln will.

Und ich meine da gibt es dann noch prozess und socket basierende 
Informationen. Wenn ich einen connected socket habe für eine destination
dann ist das immer dieselbe destination (Es sei denn es ist SCTP)

Und mit der ganzen verwirrung.

Flo
-- 
Florian Lohoff                                                     f at zz.de
   Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20260117/65673ebc/attachment.sig>