> Hello, > Hi julian ! > On Sat, 16 Nov 2002, Vincent Jaussaud wrote: > > > On All servers, we setup multipath default route, so that they can use both link as well. > > That means they know which link is alive or it does not > matter? :) > Well, at this time, it doesn't matter yet :-) Anyway, it would be best if they could, but I'm afraid that all internal servers will have to run your patch in order for this to work. And I'm talking about 20 production servers. So, I can't easily patch them & reboot :) On top of this, defaults gateways for internal servers are unlikely to become unreachable, since they are on the firewall itself. Gateways which are likely to colapse, are the ones used by the firewall, eg ISP1 & ISP2 routers, and this will never be noticed by the internal servers since they are not directly connected to them. Am I wrong ? > > Let's say we have Server A in our internal public network, with 2 network adapters, one > > using 10.0.0.1 (routed through ISP1), other using 172.16.0.1 (routed through ISP2) > > > > Assuming that rp_filter is configured correctly on our firewall, what happens when a > > client want to reach Server A using 10.0.0.1 ? What path will be used for the replies, > > with what source IP ? > > The server uses the 10.0.0.1 as source when resolving > route for the reply. Then it depends on the routing rules. That's good news. So it means that if my routing rules are setup correctly, it will work. I was afraid of having some packets sent back using a wrong SRC IP :) I assume however that this will work only for usual protocol such as http, smtp, ssh... I'll have to find a workaround for protocols like FTP, if any. Any idea ? > > > I assume that if rp_filter is configured correctly, return path do not matter (since we > > don't do NAT), but I'm worried about the SRC IP beeing choosed for the reply. Because, if > > the kernel choose the src IP according to the output default route beeing choosed, then > > half clients<->servers sessions will just break. > > I'm sure you need correct routes on firewall and all internal > hosts, for example: > > ip rule add prio ... from pubnet_X to 0/0 table table_for_ISP_X > ip rule add prio ... from pubnet_Y to 0/0 table table_for_ISP_Y > ip rule add prio ... from 0/0 to 0/0 table your_multipath_route > > Of course, the internal hosts use the proper firewall > IP as gateway. > Yes, of course. Firewall already have routing policy setup this way, and all internal servers will be reconfigured in a similar way. > That is all, traffic from specific pub IP should use only > its gateway. You can expect rp_filter drops in firewall if > the internal servers select wrong NIC by using multipath > route for all route resolutions. The multipath route should be > used only for source address autoselection: > Ok, this is not a problem. But, just beeing curious, why would rp_filter drop such packets ? I mean, we don't really care what link is beeing used for a reply, as soon as the SRC IP & DST IP are correct. It's likely that ISP1 & ISP2 router won't do source address validation anyway. Am I wrong ? > - originating connections without bind() > - selecting masquerade address (for NAT) > - etc > > I.e. it is a bad idea to use only multipath route. > > Internal servers creating outgoing connections after > using bind() to specific pubip should not reach the multipath route. > Ok. I'll ensure that multipath route is beeing used only if SRC IP isn't set, on all internal servers. > > So, basically my question is, what rules decide of the SRC IP to be used in a reply > > packet on a system with several default route through different network interfaces ? > > The transport and the application decide what source IP > to put in the reply. Then they decide how to call the routing. > The right thing to do when addresses to both ends are known is > to feed the routing with saddr and daddr. If callers use 0.0.0.0 > as saddr when resolving routes, they will hit the multipath > route which is bad. > I'm not sure to understand this point, especially "to feed the routing with saddr and daddr." I know we can instruct the routing to use a specific saddr, but what about daddr ? > > Has anyone already experiencing such setup ? > > Not exactly, but everything is in the details :) Once again, you're saving me :-) Thanks a lot. Regards, Vincent. > > > Vincent. > > Regards > > -- > Julian Anastasov <ja@ssi.bg> -- Kelkoo.com: http://www.kelkoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
