[LARTC] Re: two WANs one LAN

[LARTC] Re: two WANs one LAN

[Bob Beers]

Bob Beers wrote:

> But I've done something wrong, obviously(?).
> 
> I suspect a typo or other oversight, but haven't found it yet.
> 


Ok, after re-checking the cabling ( <- error here), and
  re-checking the commands (verbatim from the nano.txt) it does work!
  (in my static ethernet setup).  Great stuff!

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.

Also, what steps can be taken to expedite the detection and
  route adjustment?
Is it enough to decrease the sleep time in the ping_daemon?
Are there some /proc/sys/.../whatever that can/should be tweaked?

Thanks for any help.

-- 
Bob Beers


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Re: two WANs one LAN

[gypsy]

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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/