Bob Beers wrote: > Will it be the same when I introduce the dynamic ppp0 for IFE1? > The IPE1 will be a NAT'd public IP, but the GWE1 will be > the P-t-P link. If you use the correct syntax, yes. Something like ip addr add IP/MASK peer BROADCAST dev PPP0 substituting the point-to-point remote IP for BROADCAST and the correct device for PPP0 (IIRC. Sorry, it has been a long time. Regardless, the keyword here is "peer".) > Also, what steps can be taken to expedite the detection and > route adjustment? Flush the cache. Again, IIRC ip route flush but a search of the archive will turn up the correct command. If you can arrange it, a remote computer pinging each IP and messaging you when the ping fails can be used to trigger the flush. Otherwise, "ping -c 1 -I PPP0 IP" (alternate between the devices for each ping) internally is about the best you can do; ping NEVER failed for me (see below) but YMMV. > Is it enough to decrease the sleep time in the ping_daemon? No help at all. AFAIC, less often is better, not worse. > Are there some /proc/sys/.../whatever that can/should be tweaked? Nope. And nothing anywhere else, either. DGD is _very_ hard because usually the next hop is OK, it is the one after it that is bad. I don't think that even Julian can deal with "next in the route is OK but his peer is dead". In my case, the net card could speak just fine to the DSL router; it was the modem (router) that could not I/O because it was dead. Of course, DGD knew the modem was OK so it thought the link was alive... gypsy _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
