On Thu, 24 Jan 2002 kuznet@xxxxxxxxxxxxx wrote:
> > This change causes ip_route_input to select different path from
> > the multipath route when masqueraded.
> Pheew... "multipath" route + when "masqueraded" + rules introducing
> dependency on tos. Do not make this and live in peace. :-)
No, there are no rules depending on tos but ip_route_input
selects different paths for masqueraded packets from same connection
but with different tos.
> > - we need a place (ROUTING chain?) where each masqueraded connection
> > can feed ip_route_input
> ip_route_input is called on a packet. It needs no more arguments.
> Shortly, you can understand from this my statemnet above that
> I have lost sync and confused a lot. :-) :-) Seems, I need to return
> to that your mail where "lsrc" was explained.
Yes, it is a complicated issue, simple setup:
ip rule add prio 10 table main
ip addr add 10.0.1.1/24 brd + dev wan0
ip addr add 10.0.2.1/24 brd + dev wan1
ip rule add prio 20 from 10.0.1.0/24 table 20
ip route add default via 10.0.1.1 dev wan0 src 10.0.1.2 table 20
ip rule add prio 30 from 10.0.2.0/24 table 30
ip route add default via 10.0.2.1 dev wan1 src 10.0.2.2 table 30
ip rule add prio 100 table 100 nat 0.0.0.0
ip route add default table 100 \
nexthop via 10.0.1.1 dev wan0 \
nexthop via 10.0.2.1 dev wan1
nothing special, only a multipath route, universe through 2 gateways
> No matter:
> > - without lsrc arg the multipath usage can easily fail on route
> > cache flush
> sounds like a nonsense. Multipath surely cannot fail just because
> all the attributes of balanced routes are equivalent.
> Or were you able to imagine situation when one of paths is masqueraded
> and another is not or masqueraded differently? Just stop such fantasms.
No :) See above: two distinct IP blocks through two ISPs,
flush the cache and the paths are forgotten.
> NAT is _not_ permitted in environments with not trivial routing and
> based on notion of strict barrier. It is an axiom.
Julian Anastasov <ja@xxxxxx>