hello list subscribers, i may have been too cocky in my previous posts regarding this policy routing problem of mine. (my old posts in further down). the problem that i cannot reach any defined network from the router still exists. i though that would be solved when adding "from interface-address, use routing table 'all'". well, it didnt. what i can conclude, with some help from tcpdump, from this is that the router can see the routing table when trying to reach a defined network. the routing table looks pretty much like this: "network a could be reached via router x". my router does send away a arp request to router x in order to send the packet through it, and router x does indeed reply, so everything tcpdump shows is these two packets, nothing more. 'ping a' on the router returns: root@xxxxxxxxxxx:~# ping 172.16.1.2 PING 172.16.1.2 (172.16.1.2): 56 octets data sendto: Network is unreachable ping: sent 64 octets to 172.16.1.2, ret=-1 i have googled on this but without any meaningful results. i was also concerned with the fact that only adding the interface address in the rules would be a problem, and it is. the arp reply from router x will be routed according to table 'main' and thus not reach the origin address. so i simpy added router x's address to the rules and told it to use table 'all'. i still cannot reach network a from the router. the thing i seem to think is the most difficult to understand here is that route lookup is correct, otherwise the arp request wouldnt be sent, but the packet never leaves the router. this is how i see it: 1. router is requested by me to ping network a 2. router looks in the RPDB to see which routing table to use 3. RPDB says "use table 'all'" 4. router looks after a route to network a in routing table 'all' 5. router finds a route to network a and understands that it has to send it via router x 6. router checks arp cache, doesnt see anything for router x 7. router sends out a arp request to router x 8. router x answers with a arp reply (this is where nothing happends) 9. router _should_ compose a packet and send it to router x ip route flush cache is not a problem. any insight on this would be helpful. thank you for your time and for reading this far. best regards, tomas bonnedahl On Tue, Mar 11, 2003 at 06:07:03PM +0100, Tomas Bonnedahl wrote: > hello again list. i have another solution to this that has some > advantages over my last post. > > when dealing with packets and their 'coming-back' i choosed to add routes > to these networks in table 'main', instead i can create two more rules (a > total of four rules altogether) that looks like the first two but uses > the to parameter unstead of the from. (they'll just say "packets that is going > to x, use table 'all'"). > > > -tomas bonnedahl > > On Tue, Mar 11, 2003 at 05:32:51PM +0100, Tomas Bonnedahl wrote: > > i have some additional information regarding this issue with policy routing. > > > > on the router that has policy routing implemented, read further down for > > more information on my gols, three ethernet interfaces exists. > > > > since the routing table 'main' just consists of a route to 192.168.1/24 > > with a prohihbit 0/0, you cannot from the router reach a network > > that is located on some of the other interfaces than 192.168.1/24 exists > > on. this is because the src address in the packet will be the address of > > that interface which the packet will exit. according to the rules that exists > > in the RPDB, that address will use the routing table 'main' which, in turn, > > does not have a route to that network. > > > > the solution to this would be to: > > 1. make (two) rules which says "if the src address of a packet is the adress > > of an interface, use table 'all'". (also note that im using the /32 address) > > 2. add, in routing table 'main', routes to these /32 addresses. > > > > the first part here is used so that a packet could be _sent_ away correct, the > > second part is used so that a packets can come _back_ correct. > > > > im sure martin have some insight in this, perhaps a simpler solution? > > > > indeed, i did not think of this when implementing policy routing since i was > > only concerned with networks and not the router itself. > > > > i hope this will help someone struggeling with policy routing. > > > > > > best regards, > > tomas bonnedahl > > > > On Thu, Mar 06, 2003 at 04:31:42PM +0100, Tomas Bonnedahl wrote: > > > hello list (and martin) ;x > > > > > > i have now composed my final(?) policy routing design. > > > > > > the goals i had when beginning with this, for you that have not follow > > > mine and martins thread, was to 1) only let 192.168.1/24 to see all routes, > > > 2) not route between defined networks, except to and from 192.168.1/24 and 3) not > > > defined networks should only be able to reach 192.168.1/24. > > > > > > this might sound simple. it wasnt for me. > > > > > > the solution i came up with, after days and days of thinking (and patience) was > > > this: > > > > > > two routing tables, one called "ALL" that, suprisingly, held routes to all networks defined > > > and a default route to internet. the other called "main", just for ease, that held one route to > > > 192.168.1/24 and had a default prohibit. > > > > > > the one rule that exists just says "if src == 192.168.1/24 use table ALL". of course there is > > > an additional rule, the standard one that says "from all lookup main" with a number of 32766. > > > > > > so, for you that doesnt understand my poor english, literally every network that passes, except > > > from 192.168.1/24, will use the main table that just holds the route to 192.168.1/24 and the > > > prohibit one. > > > > > > > > > this so simple, something just has to be wrong. feel free to englighten me. > > > > > > > > > please flame. > > > > > > best regards, > > > tomas bonnedahl > > > _______________________________________________ > > > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > > _______________________________________________ > > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >
