Hey Guys,

Could you help me understand the practical use of the "local tables" ( versus the "main routing table"), displayed with command : ip route show table rt_eno2


My understanding of basic routing is that for a given destination the Kernel will find the best interface to use to output the packet based on destination IP address ( whichever the packet source is local or non-local via Ipv4_forward) and whichever it is a connected interface or a static route ( specific or default)--> this process is made globally to the kernel and not per interface.

( being a CCIE myself , I assume it should work pretty much like a Cisco router , beside vrf)

I don't see any practical use cases where we would need to use this sub-routing table , versus using the main routing table.

The only case that comes to my mind is if we have two Linux interfaces in the same subnet with a different default gateway configured in each local table.
You will then like to use one gateway or the other to send your packet to, and will need to force destination to one interface or the other. But I also understand that having two interface in the same subnet leads to confusion inside the Kernel .
( example with Eno1=192.168.0.1 and eno2=192.168.0.2 , on which interface should I send back a packet with destination 192.168.0.3 ?)

Anyway, I'm using Linux quite a lot and I only use the main table, I wanted to understand the practical use case of this "per-interface" / local routing tables option in the Linux.

Thanks!

Alternate routing tables are used in policy routing scenarios.

If you're a CCIE, then you should be intimately familiar with route maps. Well, local routing tables are basically the Linux equivalents to the routing rules of a route map on a Cisco router.

IP rules are used to select an alternate routing table based on some set of criteria. These rules work very much like the access lists used with route maps, only they have a lot more features than a Cisco ACL.

1 members found this post helpful.

We're using it the following way:

We have one "router" with two Internet connections which are in use at the same time.
And there are multiple Servers connected to it.

There will be connections coming in on both Internet connections and DNATed to the servers, depending on which Internet connection it came in on.
When the servers reply that reply has to be routed back to the same Interface the request came in.
Since we cannot know if the request came via Internet connection #1 or #2 a normal ip route default ... won't help.

So we have a rule (ip rule) saying if the reply comes from Server X use table X if it comes from Server Y use table Y.
Then table X has a default route to Gateway X, and table Y has a default route to Gateway Y.

Example:
Client A calls Internet-Address X, DNAT to Server X, Server X replies to A, ip rule sees that reply comes from X, uses table X, and in that table there is a default route via Gatweay X.
Client A calls Internet-Address Y, DNAT to Server Y, Server Y replies to A, ip rule sees that reply comes from Y, uses table Y, and in that table there is a default route via Gateway Y.

It would also work with a firewall mark.
If you can find the book "Policy Routing Using Linux", that explains it very well.

1 members found this post helpful.

Thanks Guys ! understood.

In my company, we develop Video Streaming applications based on Linux Debian, and our network settings GUI include an "interface Field" for each of the route we would add. It was exposed as such since our first product back 15 years ago.
Our devices are just like end hosts, we aren't doing any sort routing between interfaces, let alone any "policy based routing", so I'm trying to convince our R&D to just suppress this "interface Field" from the Network Settings GUI, as it is not needed and may un-necessary introduce complexity and conflicts.

Having that said, my conclusion is that all the "routing" need that we have ( i.e sending the packets to the correct interface) is already fullfilled using the "Main" Routing table , and the local routing tables should never be used.

Let me know if you disagree with that ! Thanks Again !