How to define static host/net routes in RHES v4 ?

[Al Licause]

I should know this one but it hasn't come up often enough to sink in....and much of the documentation on the Internet including Redhat doesn't seem to cover this topic.

Does anyone know the correct procedure for defining static network and host routes in RHES V4.0 ?

The correct method for RHES V3.0 to define the following route add command which is:

route add -net 14.157.1.0/24 gw 10.10.14.1

would be to create a file in /etc/sysconfig/network-scripts called route-eth0, assuming the route is added to device eth0:

GATEWAY0=10.10.14.1
NETMASK0=255.255.255.0
ADDRESS0=14.157.1.0

This works in v3....it doesn't work in V4.

The only way I can get a static route defined at boot time in v4 is to set it up using the full route add syntax in /etc/rc.local.

I suspect Redhat has done something to make it more generic, but that's only a guess.

[Matti_Kurkela · Accepted solution]

I'm using a similar syntax as yours, with just one difference: I've put double quotes around the variable values. I have it on several RHES4s and it works.

So, in your case, try creating the /etc/sysconfig/network-scripts/route-eth0 file with content like this:

GATEWAY0="10.10.14.1"
NETMASK0="255.255.255.0"
ADDRESS0="14.157.1.0"

After that, you must either reboot or do a "ifdown eth0; ifup eth0" to make the route definition take effect.

Ensure that you have a line-feed character at the end of each line, or the last line may get ignored. Some editors allow you to create files with "incomplete" last lines. If you use such an editor, you might want to cultivate a habit of ending your script files (and configuration files, whenever possible) with a comment line like
# EOF
to ensure you're not getting bitten by the "incomplete last line" quirk.

I used to prefer joe as my default editor, and it has this quirk. However, as I have to work on several different installations, some with a strict no-extra-software policy, I've ended up using vi. It does not have this problem, at least not in any of the vi incarnations I've come across.

[Al Licause]

Matti,

Thanks very much....this did work. I tried adding the quotes and rebooting, but didn't see the new routes until I realized that I had route-eth0 configured when it should have been route-eth1.

You wouldn't happen to know if these files are referenced during a Service Guard cluster failover would you ?

The customer is looking for some method of moving these routes to a different host should the initial host need to fail over.

[Al Licause]

Turns out the quotes are optional. It was my own stupidity and bad eye sight that did me in.

I created a file called route-eth0 for routes that should have been added to eth1. After removing the quotes and renaming the file to route-eth1, it installed the routes on reboot.

[Matti_Kurkela]

Hmm... ServiceGuard package failover manipulates only IP aliases, and assigns the numbers for the aliases dynamically per interface. So it cannot use the files in /etc/sysconfig/network-scripts at all.

If you need to add/remove those routes in a failover situation, you'll have to add route add/del commands to the customer_defined_run_commands and customer_defined_halt_commands portions of the package control scripts.

However, this sounds a bit odd for a ServiceGuard setup. Because the cluster nodes usually have static IP address in the same network(s) as the package IP address(es), there should be no need to add/remove routes while the packets move around.

Unless your network setup is very odd, you should be able to just add the route to all the cluster nodes, so the route is set up whether the package requiring that route is running on that node or not.

The requirement to move the routes along with the package is definitely not the normal way to do things: in your situation I'd definitely ask about reasons for that. This strange requirement might come from incomplete understanding of ServiceGuard on the client's part, or it might be an indication of further oddities in the client's network. If it's the latter, you'll want to know about it so you can take it into account when you have to document or troubleshoot the system.

[Al Licause]

Matti,

Thanks much for the explaination. At this point I'm trying to find a Service Guard support person that is familiar with the product so as to further assist the customer.