When I go back and read my mantis notes about all the problems I had doing this the entries all point to bidir.c having issues bringing the correct interface UP after one went down. When you know you'll only have 2 interfaces with the same addresses then you know that if you are ppp1 and are now UP and ppp0 is UP then you need to take ppp0 down. If you are ppp1 and go DOWN and you see ppp0 DOWN then you need to take ppp0 UP. Even in this setup it is possible that a death off pppd on the device would not execute if-down and then ppp0 would remain in a DOWN state. All communication would then fail from that device. A call from the server would then put things back in working order. I may have experienced this effect but it has not been painful. All my notes point to using the interface metric and assign a metric to that interface but as I've read before "Linux does not support interface metrics". Those are to be used but the "routing protocol". I would like to be able to use a modem as a failure of the VPN. I do that now in some cases but I end up assigning the demand system a different set of addresses than the VPN system. For example on the demand system the server is at 10.0.6.1 and the clients start at 6.2. In VPN the server is at 10.0.5.1 and the clients start at 5.2. This means in my software I have to track 2 addresses for those hosts. Maybe with more than 2 ppp interfaces with the same address the bidir.c code is a bad idea. What could be my other options? Chris On Wed, 2007-07-04 at 20:06 -0400, Christopher Fowler wrote: > The problem is that I do not really use gateways in this setup. It is > possible that I do have static routes but no default gateways. > These are "point-to-point" PPP connections. > > I guess I screwed up when I said "metric" and "route" in the same > sentence. What I meant to say was "metric" and "interface" it may be > the same though. > > Here is my if-up and if-down programs that are ran by pppd after LCP > packets are negotiated successfully. The comments explain exactly why > we use that program and what it does. I run pppd with the demand option > on the remote and on the server. The both have the same address so when > the server dials the remote the device ends up with 2 ppp interfaces > with the same addresses after LCP negotiation. To keep packets moving > if-up downs the other interface and when the link dies if-down ups the > one that was taken down. > > Code: http://demo.opsdc.com/bidir.c > > You could write the same thing in Perl or whatever but our device does > not have the luxury of running scripting languages. > > What I would like to do is throw in a 3rd PPP interface. The 3rd being > vtun using PPP. We use vtun now but not with this demand concept. I > might just need to setup my test bed again and see if I can have any > luck. > > Feel free to use the code. Modify or enhance. Send me back anything > that needs fixing. > > Chris > > On, 2007-07-04 at 19:41 -0400, Bill Davidsen wrote: > > Christopher Fowler wrote: > > > On Tue, 2007-07-03 at 16:25 -0400, Charlie Brady wrote: > > > > > >> Google for "linux policy routing" and/or go to > > >> http://www.policyrouting.org/ and http://artc.org/howto/. > > >> > > > > > > This brings up a question in regards to something I tried a few years > > > ago. Is there a way to use metrics on the routes? > > > > > > > > That's a good question, and the answer is "sort of." I was setting the > > defaults like this: > > > > RPolicy1="src ${ext_p_IP} via ${ext_p_gate} dev ${ext_i1}" > > ip route add default ${RPolicy1} metric 2 table mail.in > > > > (assume I have set the values in the script above, ext_p_IP is the > > static IP, etc. Then I set the route which is fast and sheap but uses > > DHCP for the IP: > > > > RPolicy2="via ${ext_s_gate} dev ${ext_s_nic}" > > ip route add default ${RPolicy2} metric 1 > > > > where the secondary IP comes from IPfromNIC after the DHCP has been started. > > > I have system that use demand mode PPP to communicate between the server > > > and them. the if-up and if-down script actually looks for the other ppp > > > interface and takes it down. I wanted to use vtun that uses pppd and > > > then only use the modem when the tunnel was down. All my attempts > > > failed and everything pointed to me needing to use metrics. > > > > > > > I did some diddling with this back when I still had a fallback to dial, > > through an ISP who would give me a static IP. I had a somewhat similar > > setup, and had the dial line set to "demand" startup. I gave it up, the > > incoming mail melted even bonded modems. > > > > Anyway, the important thing is that the setup above doesn't work, the > > metric gets lost off the "metric 2" setting. However, if I set it with > > the old route command "route add default gw x.x.x.x dev eth1 metric 2" > > it sets and stays set. I haven't chased that part yet, I'm fighting the > > original problem, and it really only matters if the fast NIC goes down. > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
