> > I didn't try to specifically, but he did eventually respond and only > > asked a simple question which had no relevance. > > Wow, maybe he is onto other things these days or short of time. Julians > was very very helpful when I was trying to get things working back in > the day. Some of it got quite crazy, with route cache timing, and all > kinds of things I was messing with before I got things working. Most all > are in this lists archives. Some was off list. > > > Still i responded > > with an answer, and pointed out the symptoms that I had previously > > stated which ruled that out as a possible problem. > > http://mailman.ds9a.nl/pipermail/lartc/2006q1/017946.html > > Hey the question he asked in that is relevant. Because arp stuff is very > much related to multipath, or multiple gateways. Since in my case I am > having some arp issues due to what I believe are replies going out the > wrong device the request came in on. To resolve have made some static > arp entries for now. Maybe for ever not sure there. > > Granted the question is not to relevant to kernel panics :) > I just figured noone who was knowledgeable enough had time to help which is understandable. I figured he likely knew better than me, so I did answer the question that yes I was running a script that pinged the gateways each minute. However the symptoms he mentioned definately did not match the problem I was having since a simple swap of order of nexthops could cause me to get the exact opposite of what he stated. > I assume you were flushing not only the route cache, but the arp cache > as well? In between switching them. However with your weights, it should > have been using the one much more often then than the other. Regardless > of position or order. > > If you swapped them and did not fully flush everything out, it could > explain some of the behavior you were seeing. Granted it does not fully > explain why it would always use the second gateway and not the first. I > would assume it had to do with some cache or etc. > > FYI, really in hind site with my past experience, and current trial and > error wows at times. I am starting to think when you are messing with > this stuff. It's best to shut down all interfaces, flush out everything. > Bringing everything back up from a clean, empty state. Then doing > comparisons. > > Stuff get's put into cache so fast. That even when you flush, by the > time the next command has run. More than likely something has made it > into cache. > Hmm, that is something I was likely not doing as well as I could. I'm fairly sure my script was only flushing the route cache and not the ARP cache. I was however bringing the interface down and then back up in some of my tests. I tended to always try progressively more drastic steps, occasionally going to a full reboot. > Yeah and most have no clue about multipath routing etc. Are totally > happy with 1 ISP. Most broadband providers seem to have good uptime > these days. > Or as you stated, they used some prefabbed hardware solution. There were a few people with such hardware solutions that weren't entirely happy with them, or wanted other things that linux has to offer like traffic shaping. > > In the end, I'm still not sure why the patches would not work for me. > > At this point I'm guessing it is entirely possible some of my kernel > > config options conflicted with the changes. > > I was starting to be curious about that myself. Maybe try to make the > kernel with no experimental stuff. Which might be impossible depending > on what support you need in the kernel ;) > I did review my kernel options, and i believe disabled as many experimental options as I could. Then I tried with enabling more options that i thought might possibly be needed despite not being listed anywhere as neccassary. > Regardless of configs or etc. You have two issues. One that the > multipath gateways did not use both gateways/links. Two that you have > kernel panics. Which I would be way more concerned with kernel panics > then the routing issues ;) Well the 2 issues were directly inter connected. If I only specified a single nexthop, the kernel panics would not occur. > Well I might be there sooner than later. If all goes well, sometime this > year I will get another T1 from a different provider, and have redundant > lines here. I would have done that already as I did in CA using SDSL. > But this area only has 1 SDSL provider, Covad, and everyone else > re-sells their stuff. Or provides really low bandwidth SDSL lines. > > In the mean time I might have to apply the patches to resolve some of my > arp issues. If I get kernel panics I will be upset, because I have not > seen those in years. Since the last time I was messing with all this. > But those were boot time panics. Should be perfectly safe, as I only saw the panics when I had the multiple nexthops. Also I believe I saw a common thread that others who experienced the problem were also using gentoo. However since I think its safe to rule out the kernel patches used, that leads me to believe it is the kernel config options, as tweaking those is something more likely to be done by a gentoo user. I wonder if i would of fared better with a genkernel setup. > For the record it is possible, I have done it. And once done, it's so > great. I literally had no issues, worries, downtime, etc for over a year > with it. It was so great, kept the machine around as an internal router. > Only recently decommissioned it. Good old LRP install and etc. Way > outdated and totally insecure. Now that my linux router is back > connected to a wan. I had to update. Not using a ramdisk atm, and > booting from and using a HD. Totally un cool. For now ;) Numerous people did respond they had it working as I asked for their configs to see if i could maybe see through comparison what I was doing wrong. If I do this again, I think I'm going to try and scrounge up another pc to test it on and maybe dedicate to just the routing and traffic shaping. Then completely dropping one distro for another would be an option, along with any other drastic changes to the system. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
