Per Jessen wrote:
Linda Walsh wrote:
I didn't put it there initially, suseconfig did, but it has it wrong (w/o the gateway). It put 'lo' in the general routes file because, I'm guessing, it will always be there?
Since kernel 2.4 (I think), routes are automatically added/removed by the kernel when interfaces are brought up and down. The ifroute-lo file has a comment that it isn't actually necessary.
The only 'auto route' I see installed when an interface is brought up is to the 'subnet' for that interface. So if my interface on 'eth0' has addr X.X.X.41, *and* it's a /24 address, you automatically get a route for the /24 net (X.X.X.0) added. All I need is then add that X.X.X.1 is my 'gateway' host.
I don't have a weighted setup myself, but I do have a configuration with multiple redundant routes to the same place. I think(!) you could use BGP to work with multiple routes, but I don't know enough about it. In my setup, I switch between three routing-tables (1="both routes are fine, just alternate", 2="only route1 is availble", 3="only route2 is available".
You switch routing tables: automatically or manually? I'm looking for autodetect based on which interface comes up.
Can't do that. Doesn't work =illegal route=. n.n.n.n isn't a local address. My addr is n.n.n.l on eth0, while another host, 'n.n.n.n' is the gateway.
If 'n.n.n.n' is your gateway, it must be reachable, presumably via eth0 (n.n.n.1).
(I shouldn't have used letter 'l' as sample for my addr...too easily confused with number '1'; :-)). But what you are saying, basically, looks right. My addr is more like x.x.x.42. I need to add a default route to x.x.x.1 (number 1), on dev eth0. When eth0 is brought up, I automatically get the route to the x.x.x.0 subnet (it's a /24 subnet). All I need then is to add the default route -- using route command it would be: "route add default gw x.x.x.1 eth0" #gateway is at addr #1 on the subnet If I wanted to, I could put it in /etc/sysconfig/network/routes as "default 0.0.0.0 0.0.0.0 eth0 via x.x.x.1" (in fact, that's what I'm using as a workaround). But putting it in the "ifroute.eth0" file fails -- it seems the ifroute.ethX files are parse differently than the global 'routes' file, especially in regards to allowing "ip options" at the end of the line. That's the problem -- the ifroute.ethX files don't seem to process "ip options" at the end of the their config lines as the 'routes' file *does*. It appears just to be a "bug" -- the ifroute.eth0 file should be processed the same as the global 'routes' file, with the exception that the device doesn't need to be specified -- (it's would default to the device that is the last part of the filename (ifroute.ethX - routes for "ethX").
Okay. You can only have one default gateway - isn't that going to cause a problem if you try to add a second one when your cross-over interface comes up?
Let's say that I detect carrier loss on eth0. Also, say I run something like ifplugd that can detect carrier loss and run a script on loss -- then it could ifdown the non-working interface,which would remove both, the route to x.x.x.0 (the subnet eth0 was on) and the default route (as it is no longer accessible via eth0). Now, the sript could start the 2ndard interface, say, on eth3. It would have the same IPADDR as eth0 did, so I'd automatically get the route for subnet (x.x.x.0). Then, if I could get ifroute.ethX to allow specifying 'ip add' flags (as 'routes' does), I could install the new default route to the gw going out eth3. I can't put the default route in file 'routes', since it might be on eth0 or eth3 depending on the link status. That's why I'm trying to specify the default in the ifroute.ethX file. Unfortunately, it _looks_ like there is a 'bug' in the ifX script system that is not allowing (or not parsing) 'ip' options in the ifroute.ethX files as is allowed in the routes (/etc/sysconfig/network/routes) file. The ifroute.ethX file parser should allow giving 'ip' options just the same as it allows in 'routes' -- that way I can specify my default route IN the ifroute.ethX files (which requires me using the "gw x.x.x.1" option to 'ip'. The bit about the dedicated xtra line is not pertinent to the default route resetting. That's a separate case where being able to use the 'ip' option "weight" when specifying a route would be ideal. I can't be sure that the dedicated cable (the word 'line' is misleading, since they are sitting next to each other, so it's a 1m crossover cable) would be given preference over the normal connection through the switch. But theoretically, if I added a weight of '1' to the normal route going between the two machines (the one going through the switch), and the new route (one I bring up manually, or, perhaps later, auto, if it is of any benefit) has a weight (cost) of 0, then hopefully the kernel will automatically start routing packets over the lower-cost route (the direct cable). If they use the dedicated cable, I can also setup using jumbo packets on the cable (can't use them network wide as I have heterogeneous switches and cards that don't all support jumbo). Just having being able to have a dynamic route switch based on the route cost would be a great first step -- especially if I can use jumbo packets on the crossover cable. Separately from the dynamic route issue, I was also thinking of trying to setup the crossover cable as a primary and use the normal, switched route, as a 2ndary for overflow traffic. Even over the switch, I've seen spikes of ~75% (900+Mb in iftop) on the Gb channel. Was hoping that with bonding, I might double that -- then I'd be talking slowish (20-23MB/s) hard disk-like speeds. Calling the two machines 'server' and 'client' (my, what original names! ;^)), I might find it not too much of a performance penalty to put "client's" home-dir on 'server'. Might even try client as 'diskless'...been a while since I've done that -- that's for sure! Much of my work between 'client' and 'server', is "testing" and "educational"... The bit with the 'default' routes being in ifroute.ethX (which is allowed/supported, if you don't need the "gw <host>", 'ip' option) is more important. That's the one I'd claim is more likely a "bug", though being able to support the same 'ip' options in 'ifroute.ethX' as is supported in 'routes' would be the real goal for a fix.
Okay, now I understand - depending on your network, you may have multiple routes going to the same place?
Well not exactly -- with the 'default' route case, it'd only be which ever card was 'up' that would be the route to the same place.
Try this: http://lartc.org/howto/lartc.rpdb.multiple-links.html
Will look at the site, regardless of what I think it's current relevance is to my situation -- might give me ideas ...(if not for current problem, for future... ;^)). I didn't even know about the 'ip' command before a few weeks ago. When things broke and my server came up with all interfaces up and set to correct addressing, I used the 'route' cmd, and 'routes [-n]' to re-enable routing until I could figure out the problem. I understand why my virtual addressing stuff changed back in ~8.0 -- I had a note in the /etc/sysconfig/network/ifcfg-eth1 file, next to the new syntax for alternate IPADDR's on the same interface, that they were a conversion from the old, separate file format that existed. Certainly didn't understand why they changed, as the new format wasn't easily used with 'route' as I'd been used to. The documentation on 'ip' is quite 'terse' with few good examples relevant to my situation and, basically all the info I needed in a pseudo-BNF. I shudder to think of a non-computer science person reading and grokking that file. Linda
/Per
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org