Re: [LARTC] policy routing problem

Linux Advanced Routing and Traffic Control

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

 



On Wed, Mar 12, 2003 at 10:15:21PM -0600, Martin A. Brown wrote:
> Hi Tomas,

hello again.
 
> I hope you didn't sit there waiting for this answer!

this time no. ;)

>  : things i like to clarify:
>  : 1. rules 31000 and 31100 is just so that one address on a defined network can reach an
>  : 	address on the internet, and that works perfect.
> 
> Looks perfect.
> 
>  : 2. rules 32100-32400 is supposed to be so that the router can reach
>  :    defined networks, this does not work.
> 
> This may be part of the "which comes first, the chicken or the egg"
> scenario you alluded to in your previous mail.  I'm still trying to wrap
> my mind around the intertwined relationship between source address
> selection and route selection.  I can't answer your implied question about
> why this doesn't work, nor can I answer your previous question about the
> ARP queries which never have a following ethernet frame with IP payload.

exactly my thought too with the "chicken or egg". i have looked at the iproute2
src code and also the kernel route.c code but since im not that good of a programmer
i couldnt make anything out of it.

i may be stupid here, the arp quierys were sent when i was trying to ping the voIP
network, but it _could_ have come from legatime traffic from the lan (the works) so
the arp request didnt necessarily had to come in conjunction with my ping. im not sure
but when we have now looked further into this, it seems possible that it was not from
ping but from other traffic.


> Maybe one of the people more familiar with the kernel source code can help
> out here.

yes. though im not sure anyone still reads this thread anymore, if anyone ever did. ;/


>  : some ascii art over the network:
> 
> How about some modified ASCII art!  Everybody loves ASCII....
> 
>     0/0 internet -----+ +-------------+ +---- defined networks ipsec
>                        \|      fw     |/       10.47.17.0/24
>                         +-------------+        10.46.23.0/24
>                         192.168.2.1/24         10.100.0.0/16
>                                 |              192.168.75.0/24
>                                 |
>                         192.168.2.2/24
>                         +-------------+
>         192.168.4.1/24 /| linux router|\ 192.168.1.1/24
>                       / +-------------+ +--- LAN
>       192.168.4.2/24 /
>           +------------+
>           |   voip     |
>           +------------+
>                |
>                +-- 172.16.1.0/24
> 
> This is what I'm able to gather from your routes and diagram, and you,
> sir, have a garden of networks.

indeed true. you figured it out and made a much better outline than me.
 
> I think what you want to do on "linux router" is to try the following
> (idiomatic) RPDB entry.
> 
> # ip rule add iif lo table all    # -- or table main in above case

hm. i do not have the possibility to check this right now, but i will do it
as soon as possible. but i have to tell you, i really dont see what this "means"
or will change. just that everything that exits (and enters?) on the loopback if
will use table all? 

> I know it seems a very simple answer, to a complex question, but I hope it
> will work for you.

well, so do i ;)

> By the way, Tomas, did you know that you can have rule types in the RPDB,
> e.g.,
> 
> # ip rule add blackhole from 192.168.4.2 to 10.0.0.0/8
> # ip rule add prohibit from 10.47.17.0/24 to 172.16.1.0/24
> # ip rule add unreachable from 192.168.75.0/24 to 192.168.4.0/24

yes, i knew that. i choosed prohibit since the blackhole just drops them on the floor
and let the client time out. 

> OK, I know that tidbit doesn't help you in your current troubles, but I
> was hoping that the "iif lo" trick might help.

ill check later today and ill mail back to you as soon as possible afterwards.

thank you martin

regards, 
tomas



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