why are you using table_allocator?

[sasanj]

Hi
What is the need for a table_allocater when there is a simple way of naming routing tables through /etc/iproute2/rt_tables, which all kernels support. Take a look at Routing Tables.
One can name the tables using interface's name and then use them in ip command lines.
Here is a simple snippet I use in my /etc/dhcpcd.exit-hook:

#if there is no table with this name add one:
if [ $( grep $interface /etc/iproute2/rt_tables | wc -l ) -eq 0 ]; then
	NUM=$( cat /etc/iproute2/rt_tables | wc -l )
	echo "$NUM  $interface" >> /etc/iproute2/rt_tables
fi
#now add routing to that table
ip route add table $interface to $new_network_number/$new_subnet_cidr dev $interface scope link
ip route add table $interface default via $new_routers dev $interface
#check if the rule for this ip address exists
[ $( ip rule list | grep "from\\s+${new_ip_address}" | wc -l ) -eq 0 ] && \
	  ip rule add from $new_ip_address table $interface

[kristrev]

The main reason for using table_allocater is to avoid dealing with potential pitfalls of depending on the content of a file. For example, based on your snippet, I think the following would fail (cause incorrect configuration).

• You add four interfaces. Your file will then contain something like:

1 eth0
2 eth1
3 eth2
4 eth3

• You disconnect one interface, say eth0. I assume that you have some code deleting tables as interfaces are removed, and this will cause /etc/iproute2/rt_tables to now contain three entries.
• You then connect eth0 again. The $( cat /etc/iproute2/rt_tables | wc -l )command will return three. The routes will be inserted in the table of eth2.

Your script will work fine in most cases, but the devices running table_allocate are a bit ... special. Also, several of the devices have multiple addresses for each interface (but that can be easily added also to your script).

[sasanj]

I never delete anything from rt_tables. The script only adds a new alias if there isn't one. The table "aliases" will remain there because the corresponding interfaces come and go.

[sasanj]

Let me explain why I am asking this. Your dnsmasq solution is ingenious, and I love the way you have come up with scripts.
So I want to rewrite your multihomed-routing.sh and add a dhcpcd hookusing my approach.

1. I want to know if there are any scenarios which table_allocater can solve, that my approach cannot handle.
2. Then publish the new project, without table_allocater, since, it will be a more compact, scripts only and no compilations needed, project.
3. And because much of the project will change, I don't think it would be a good idea to create a pull request, or is it?

Your reply will be much appreciated.

[kristrev]

There were also some other reasons for using table_allocator, that I forgot to mention last night. table_allocator was developed for a multihomed network tested called Monroe. Each container runs in a separate network namespace and the users are allowed to do whatever they want inside this space. However, we need to map routes/rules into each namespace. table_allocater provides a convenient way for ensuring that the table values stay within a pre-defined range, so that we can tell users that tables between X and Y are reserved and should not be used. We would also like to minimize the number of tables we use (though I don't think any experiment will be close to using uint32_max number of tables :)), so we need to release a table once the interface is gone.

I am not married to table_allocator though, it was just my way of allocating tables. So creating a new folder in scripts/ and sending a PR for a solution without tables_allocator would be very much appreciated. My intention for this repo is to be a collection of automated ways of setting up multiple routes.

[sasanj]

Ok, I will do what you said.
Thanks for your replies.
Sorry for answering this late.