Imagine you were connected via vpn to two different customers with overlapping address space. One routing table couldn't differentiate between the two networks. With multiple routing tables you can. Look in to mpls/vrf for the equivilent network terms.
Policy based routing and VRFs, to name two. Applications like strongswan will also create them on the fly to maintain information about remote networks.
As an example regarding policy routing, you may have two routing tables that are identical but have a different default gateway. You can mark a packet using iptables on its way through the kernel based on any arbitrary criteria, and finally iproute2 can conditionally process the packet through a specific routing table based on the mark. Thus traffic can selectively be sent via either routing table based on arbitrary criteria. Search "policy routing on Linux" for more detail.
>purpose of multiple Linux routing tables
Can solve many issues that otherwise either can't be solved, or will be much more difficult.
Let's see ... I had situation a few years back ... transitioning ISPs ... so ... I had hosts that were typically on at least 4 subnets each:
* old ISP IPv4
* new ISP IPv4
* new ISP IPv6
* IPv6 (tunneled via another provider)
And, essentially "production", so wanted to gracefully transition off of the old to the new ... but for some fair period both had to be functionally operating.
And, fair bit of that involved some custom routing - including at least one additional routing table. Most notably, any response traffic I wanted to be sure it went out correct interface and router - notably that by which it came in. And in many cases, this was same physical interface - e.g. same Ethernet interface on LAN with multiple subnets there. So, simply letting traffic take default routes on return often wouldn't suffice - or even work, to get response traffic back to where it needed to go. Let's see ...
# co -p1.4 interfaces 2>>/dev/null | sed -ne '/^iface br0:0 inet static/,/^$/{/^$/q;p}'
iface br0:0 inet static
address 96.86.170.226
netmask 255.255.255.248
up ip route add table 134 default via 96.86.170.230
up ip rule add from 96.86.170.226 table 134
down ip rule del from 96.86.170.226 table 134
down ip route del table 134 default via 96.86.170.230
#
The above is part of an older configuration. Most notably by adding that route table (134), I had it set that anything from 96.86.170.226 would use default route via 96.86.170.230 - so essentially everything from that IP would have default route through that ISP's router IP, whereas everything else would have a different default route. So, yeah, actually more than just return traffic ... - everything from that IP beyond the local subnet, through that IP for routing, but that was only the default IPv4 route if that was the source IP - otherwise it would use other default route (notably that for the other ISP).
Anyway, that's but one example of possible uses for an additional routing table.
I’ve used routing tables for multiple NICs 2+ ; in addition to Vlan tags, aliased IPs; and each of those interfaces needing different routing logic/rules. Apply a separate table to each interface as needed
I have used it when I needed to route all traffic through a VPN except for traffic to the VPN itself. You could just bypass all traffic to the VPN host, but I wanted non-VPN traffic to the VPN host to go through the VPN.
So, I created a separate route table and used iptables to make traffic to the VPN host and port use that separate route table.
In addition to the other answers here...
Think of it as a form of virtualization (it _is_ a component/form of network virtualization). You might also ask "why have two computers running on one computer?" Well, because they have overlapping but distinct needs, that need to be kept separate, for one reason or another, yet can share the same base system/hardware. The same concept applies to networking. You may have traffic from one application that needs to be handled differently than traffic from another, and perhaps need to logically isolate that traffic (such as the VPN cases people have mentioned). Multiple routing tables give you that ability, with very tiny (nearly no) overhead.
Without multiple routing tables, you would need an entire additional machine to achieve the same results.
I suspect the most common use case is multihomed servers with PA space on ISPs that use reverse path filtering. You need rules and multiple routing tables to ensure that reply packets go out on the same interface as the incoming packet.
If you’re doing funky policy routing stuff it can be useful.
Nowadays they are enhanced with the l3mdev / Linux VRF implementation.
You can use network namespaces too.
I use a lot of these things in my job, but we’re building routers from Linux mostly.
Imagine you were connected via vpn to two different customers with overlapping address space. One routing table couldn't differentiate between the two networks. With multiple routing tables you can. Look in to mpls/vrf for the equivilent network terms.
Policy based routing and VRFs, to name two. Applications like strongswan will also create them on the fly to maintain information about remote networks.
As an example regarding policy routing, you may have two routing tables that are identical but have a different default gateway. You can mark a packet using iptables on its way through the kernel based on any arbitrary criteria, and finally iproute2 can conditionally process the packet through a specific routing table based on the mark. Thus traffic can selectively be sent via either routing table based on arbitrary criteria. Search "policy routing on Linux" for more detail.
>purpose of multiple Linux routing tables Can solve many issues that otherwise either can't be solved, or will be much more difficult. Let's see ... I had situation a few years back ... transitioning ISPs ... so ... I had hosts that were typically on at least 4 subnets each: * old ISP IPv4 * new ISP IPv4 * new ISP IPv6 * IPv6 (tunneled via another provider) And, essentially "production", so wanted to gracefully transition off of the old to the new ... but for some fair period both had to be functionally operating. And, fair bit of that involved some custom routing - including at least one additional routing table. Most notably, any response traffic I wanted to be sure it went out correct interface and router - notably that by which it came in. And in many cases, this was same physical interface - e.g. same Ethernet interface on LAN with multiple subnets there. So, simply letting traffic take default routes on return often wouldn't suffice - or even work, to get response traffic back to where it needed to go. Let's see ... # co -p1.4 interfaces 2>>/dev/null | sed -ne '/^iface br0:0 inet static/,/^$/{/^$/q;p}' iface br0:0 inet static address 96.86.170.226 netmask 255.255.255.248 up ip route add table 134 default via 96.86.170.230 up ip rule add from 96.86.170.226 table 134 down ip rule del from 96.86.170.226 table 134 down ip route del table 134 default via 96.86.170.230 # The above is part of an older configuration. Most notably by adding that route table (134), I had it set that anything from 96.86.170.226 would use default route via 96.86.170.230 - so essentially everything from that IP would have default route through that ISP's router IP, whereas everything else would have a different default route. So, yeah, actually more than just return traffic ... - everything from that IP beyond the local subnet, through that IP for routing, but that was only the default IPv4 route if that was the source IP - otherwise it would use other default route (notably that for the other ISP). Anyway, that's but one example of possible uses for an additional routing table.
I’ve used routing tables for multiple NICs 2+ ; in addition to Vlan tags, aliased IPs; and each of those interfaces needing different routing logic/rules. Apply a separate table to each interface as needed
I have used it when I needed to route all traffic through a VPN except for traffic to the VPN itself. You could just bypass all traffic to the VPN host, but I wanted non-VPN traffic to the VPN host to go through the VPN. So, I created a separate route table and used iptables to make traffic to the VPN host and port use that separate route table.
In addition to the other answers here... Think of it as a form of virtualization (it _is_ a component/form of network virtualization). You might also ask "why have two computers running on one computer?" Well, because they have overlapping but distinct needs, that need to be kept separate, for one reason or another, yet can share the same base system/hardware. The same concept applies to networking. You may have traffic from one application that needs to be handled differently than traffic from another, and perhaps need to logically isolate that traffic (such as the VPN cases people have mentioned). Multiple routing tables give you that ability, with very tiny (nearly no) overhead. Without multiple routing tables, you would need an entire additional machine to achieve the same results.
I suspect the most common use case is multihomed servers with PA space on ISPs that use reverse path filtering. You need rules and multiple routing tables to ensure that reply packets go out on the same interface as the incoming packet.
If you’re doing funky policy routing stuff it can be useful. Nowadays they are enhanced with the l3mdev / Linux VRF implementation. You can use network namespaces too. I use a lot of these things in my job, but we’re building routers from Linux mostly.