Paul, On Thu, 2003-01-30 at 15:58, Paul Evans wrote: > I've been subbing this list for a couple of months now, knowing this day would > come :-) My gut says I was not alone, you are not alone, and others will eventually be going down this path as well. > I too am trying to do an equalize/next hop for 2 adsl lines. At the moment > though I am testing with 1 2MB adsl modem and an ether connection to a switch > from a second 2MB line. > > I am doing it from the *outside* via ssh, which makes it a little more > difficult, since when I mess up I lose access until I can get someone to > restart the network without my changes... Ouch, that will slow things down during testing. > I began by using the example from lartc.org, combined with a cron to undo my > changes every half hour, but moved to following this page from sysadmin > magazine: > http://www.samag.com/documents/sam0201h/ Good article, I cam across it as well. However it really only is accurate on the DNS point of view from the outside world. For things to work the other way around, from the inside going out you will need the nano-how-to and possible Julian's patches applied to a custom compiled kernel. http://www.linuxvirtualserver.org/~julian/#routes > For some reason I got a better sense of what I was trying to do from it, plus > it included a section on just where to place the new rules into the system > scripts. It did not say just where to place the section for ifup-routes > though. When doing something of this nature I recommend not using any provided networking scripts and make your own. It's fairly straight forward and easy to do. Just put all your commands into a function that can be called from outside of the script. Like ./mynetwork.sh start will call the start function. > I think I've got it pretty close, but since I just locked myself out again... That sucks. :) > It's a mandrake 9.0 box and I didn't see where to prevent a default route from > being set when it brings up ppp0 on the adsl line. I sort of hoped that my > default routes would get set first and force the other to fail with the > Exists error. Since I couldn't find it, I don't know in what order it gets > run. I think that's where I messed up, but I can't get back in to read the > logs right now. Like is said make your own scripts and do not use the originals for now, if possible. I think that your doing this from the outside may require you to use the default ones until you get things working. Then make your own and forget about the default ones. > Also, the above article uses ip to route to the lan, and I had > intended/understood that I would masquerade to it later. Which is the correct > approach then? I will want to move on to tc when I finally get this part > working. The way it works for me, and to my knowledge the only way it works is by masquerading. That's where the patches make things work. However I thought I saw a comment from Julian that masquerading was not necessary? I thought it was? I would imagine Julian will set me straight one way or the other. ;) > from the article: > > advanced eth0 10.0.0.0/24 via 10.0.0.1 table 1 > advanced eth0 10.0.0.0/24 via 10.0.0.1 table 2 > advanced eth1 0/0 via 63.89.102.1 table 1 > advanced eth2 0/0 via 65.3.17.1 table 2 > > Where eth0 is their lan and eth1/2 are isp. They have a new section in > ifup-routes grepping a file named static-routes for '^advanced'. This stuff forget from the sys-admin article and stick to the routing rules on the nano-how-to. The only part of the sys-admin article that I used and recommend others to use is the DNS aspect for redundancy/load balancing from the outside world. Although most of the same info with other examples can be found in the BIND manual. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com
