Re: Rout looping through local host.

[Grant Taylor <gtaylor@riverviewtech.net>]

On 08/21/07 12:26, michel banguerski wrote:
 > here's  my 2¢:
 > there is no need to patch the kernel.
 > what you should do is PBR and little arp hacking:
 > let's say your eth0 is 10.0.0.1/24
 > what i'd do is to put eth1 and eth2 in different subnets:
 > eth1 -> 10.0.1.1/24
 > eth2 -> 10.0.2.1/24

(For the sake of discussion) Ok...

 > default routes:
 > ip ro add default via 10.0.1.254 table 252 # from eth1 to eth2
 > ip ro add default via <gateway on eth3 side> table default # from eth3
 > to outside

I can see how this might get packets from eth1 in to eth2, but I fail to 
see how returning packets will get from eth2 back to eth1 with out doing 
the same in reverse.  Doing the same in reverse will either require more 
routing tables or make routing table 252 more complex if possible.

 > PBR rules:
 > ip rule del prio 32766 # we need to put rules between lookup to main 
and default
 > ip rule add prio 100 lookup main # rule 32766 becomes 100
 > ip rule add 200 lookup 252 iif eth0 # alternative default route for 
local LAN

Again, returning traffic is going to be problematic.

 > arp override:
 > arp -s 10.0.1.254 <ETH addr of eth2>

Presuming that the reverse path can be worked out, this might work if I 
was really using cross over cables, but for scalability reasons I'm not 
doing so, but rather a program more like a tunnel than a physical 
interface.  Said program generates a NOARP interface, so I don't think 
this approach will work.

 > disable antispoof on eth{1,2} (may be not needed if you do NAT)
 >  echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
 >  echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

Agreed.  I don't know for sure if reverse path protection is or is not 
needed yet, so for safety sake we'll turn it off and do our own reverse 
path filtering in IPTables or see if the kernel can do it for us later on.

 > there is one thing to look after: the dhcp client will put its default
 > route in table main(252) and you should move it from here to table
 > default(253)

Agreed.  However this is what the options for dhcpcd (or the likes) are 
for to tell it not to over write any files or change any thing else for 
that matter.  In fact, I think I'll just have the client request the 
information and log it to files in the /etc/dhcp<what ever> directory 
and I'll alter interfaces and routing table(s) my self.

 > This setup should work with or without NAT

Possibly.

 > Hope this works(did not test this exact setup) and helps

In theory (what I understand of what you are suggesting) has merit, but 
lacks return path.  Even if the return path can be fixed, there is still 
the issue of the NOARP interfaces.

Also, my project requires me to have multiple of these additional 
routers, so this will not scale very well and thus is not really an 
ideal solution.  (Look at a follow up post to my own question.)



Thank you very much for your input and for providing a very unique 
solution, all be it fairly out side of the ball park one (sending 
traffic to an IP address that does not exist...).

Grant. . . .