Re: iproute2, alternative tables, no default route: routing trouble for localhost [SOLVED]

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've found the answer in debian-firewall@xxxxxxxxxxxxxxxxx

First:

I'm sorry, there was a typo while writing message. The correct subnets
are 10.10.101.0/24 and 10.10.100.0/24, not 10.10.100.101/24 and
10.10.100.100/24.

The solution is:

# ip rule add dev lo table Servers

as Pascal Hambourg <pascal.mail@xxxxxxxxxxxxxxx> advised, I'll quote:

> > So, the question is: how does the routing of packets comming from
> > localhost is being accomplished?
> 
> In the same way as the routing of forwarded packets. From "ip rule" 
> point of view, locally generated traffic is selected with "iif
lo" (see 
> iproute manual). Be aware that when the local source address is not 
> explicitly specified by the sending application, none of your custom 
> rules will match, so the "main" table will be used. But it contains
no 
> default route.



В Птн, 18/08/2006 в 14:31 +0300, Покотиленко Костик пишет:
> Hi.
> 
> The task:
> 
> 1. There 3 servers and a router with 2 PPPoE connections (let call them:
> ppp0, ppp1).
> 2. There are several groups of Inet-clients to be served (Servers,
> Clients and Club).
> 3. The task is:
>    - to route Club through the ppp1;
>    - to Servers and Clients through ppp0;
> 
> (Next is reproduced from memory and may be slightly incorrect)
> 
> router # netstat -nr
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0
> eth0
> a1.a2.a3.a4     0.0.0.0         255.255.255.255 U         0 0          0
> ppp0
> b1.b2.b3.b4     0.0.0.0         255.255.255.255 U         0 0          0
> ppp1
> 
> router # cat /etc/iproute2/rt_tables
> #
> # reserved values
> #
> 255     local
> 254     main
> 253     default
> 0       unspec
> #
> # local
> #
> #1      inr.ruhep
> 200 Servers
> 201 Clients
> 202 Club
> 
> router # ip rule ls
> 0:      from all lookup local
> 32763:  from 10.10.100.101/24 lookup Club
> 32764:  from 10.10.100.100/24 lookup Clients
> 32765:  from 192.168.1.0/24 lookup Servers
> 32766:  from all lookup main
> 32767:  from all lookup default
> 
> router # ip route ls table Clients
> default via a1.a2.a3.a4 dev ppp0
> 
> router # ip route ls table Servers
> default via a1.a2.a3.a4 dev ppp0
> 
> router # ip route ls table Club
> default via b1.b2.b3.b4 dev ppp1
> 
> ========================================
> 
> So, to summarize, the is no default route in main routing table. Each
> group of clients is to be routed through its respective connection, and,
> when its connection is down it is not to be routed.
> 
> This scheme works almost fine, 10.10.100.100/24 addresses are really
> being routed through ppp0, 10.10.100.101/24 through ppp1 and
> 192.168.1.0/24 (3 Servers) through ppp0. BUT the router itself
> (192.168.1.4) has no route to any host. I get "network is unreachable"
> to any connectiion attempt from 192.168.1.4. And I can't connect to this
> router from outside, because the packets have no route to be sent back.
> 
> I thought that there is different routing politics for localhost and
> added default route to "local" table. 192.168.1.4 has started to have
> the route, but the rest of the scheme started to work incorrectly.
> 
> So, the question is: how does the routing of packets comming from
> localhost is being accomplished?
> 
> As to me there is a kind of "vicious circle" situation, because to enter
> alternative routing table there should already be "source address", but
> for localhost which have many source addresses it should decide which
> route it needs to have the corresponding "source address" be set.
> 
-- 
Покотиленко Костик <casper@xxxxxxxxxxxx>

_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux