On 5 May, 2012, at 13:43 , Darren Reed wrote:
Dennis Ferguson wrote:
On 5 May, 2012, at 07:32 , Darren Reed wrote:
In that context, if a process belongs to a brane then all of its sockets,
etc, would also belong to the new brane.
But, speaking of a topic that came up a week or two ago, what if the thing
I want to use the multiple tables for is to implement strict host behavior
on a multi-homed host? That is, suppose I am running a server application
on a host with two interfaces, and I just want the reply packets to connections
that came in one or the other of the interfaces to go back out the same
interface (say the interfaces connect to different service providers). Two
routing tables, one per interface, are required for this since the outbound
routing from the host needs to be done through a table that only has routes
pointing out the interface the packet needs to leave on.
Branes are the wrong solution for that problem.
Probably, but multiple forwarding tables are essential to solve that
problem. This is the problem with "multiple forwarding tables" == "branes".
What is better is to be able to issue an ioctl on the socket
and in that fashion specify which network interface to use
for sending out packets.
The problem is that, no matter what the ioctl tells the socket
to do, the kernel cannot send a packet out an interface if it
does not have a route to the packet's destination pointing out
that interface. If the destination is being routed with a
default route then there need to be two default routes (if it
is being routed with some other route there need to be two
of those), one for each interface, which means you need two
forwarding tables to store the different routes in. It is a
multiple forwarding table problem even if it isn't one that
a "brane" works for.