Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Both interfaces are in the same subnet, is this a requirement?
I have not tried running two interfaces to the same subnet for many years, but in general this creates a problem. Normally the routing decission is based on the first (or top most) entry in the table for a given subment. If ETH0's subnet entry happens to be "on-top" of ETH1's subnet then ETH1 may be unreachable, visa-versa if ETH1 is the first entry found. I hedge with "Normally", and "May" as I know there are solutions that allow subnet sharing... ... ... although that is normally to the same set of physicl devices. In the case you outline, you have device set "X" on subnet "A" and another device set "Y" on the same subnet "A", I see this as a difficult or just maybe NOT.
If you are forced to use the same subnet, you might be able to use the "longest netmask" rule to your advantage. It sounds like your DB is a single device, and could be concidered a very small subnet by its self. To avoid having to think, assume the last octet of the network address for your DB server is ...6 and your ETH0 IP address it ...5 with a 30 bit mask (255.255.255.252). On ETH1 you showed a 24 bit mask (255.255.255.0) and on a router the longest subnet is positioned higher in the table, thus the more 1-bits in the mask the more perfered the route. I do not know if this would work, as linux might be smart enough to disallow this "trick". If this does work, and you have other routers in the network, they would have to be modified to allow connectivity at which point the request would get the network engineers really upset with you and give you a new subnet.
If all your other machines are restricted to a single subnet because you have no other router in the network. Because all devices are on the same physical network on the same subnet, then every device already has direct access to the DB server. If this is the case just add a static route in /etc/hosts pointing to the DB server. If I could find my glasses I could look it up for you, but I think if you use the command:
route add -net <db server IP address> netmask 255.255.255.255 eth0
an entry will be added to your hosts table saying to use eth0 only to access this device.
Is this sort of the thing you looking for?
Oops.. I just reread and see you are talking about 2 DB servers. If that is the save then the subnet mask in option 1 would be different and in option 2 you would have to insert 2 static routes.
Last edited by dscott1644; 11-17-2004 at 10:49 AM.
I really don't know what the best solution is. The problem is the one active interface is overloaded with too much traffic. Half of the traffic goes to a DB and the other half goes to various other machines. By adding a second interface and routing it to the DB I expect the load will be reduced and performance improved. Unfortunately I haven't found a good example of this being done and the details on how to do it. Any help would be appreciated.
The easiest (and I feel best) solution would be to create a new LAN segment for your DB servers and insert a router between the existing LAN segment and the new LAN segment (you would then have 2 subnet). Your Linux server would be connected to both LAN segments and the other devices would only be on the original LAN segment. The Linux machine would know the best path to each LAN segment automatically so all you would have to do is put the IP address on the interface and do a ifconfig up. How the router would need to be configured and changing each hosts gateway address would depend on what the rest of the network looks like.
/ \ <---- gateway addresses
/ | existing LAN
| | |
I don't know if the Internet is in the picture or not. An alternate approach would be:
| <---- gateway address for existing LAN devices including Linux
| | existing LAN
| | <----- gateway address for DB servers
** a routing protocol would be needed between Router1 and Router2 which could include a dynamic routing protocol or manually using static routes.
*** EDITED comment here *** I was afraid the spaces would be changed to nulls making my wonderful stick figure drawings somewhat difficult to read. Can you figure out how to insert the spaces to make this make sense?
Last edited by dscott1644; 11-17-2004 at 12:17 PM.
if your db's are being accessed from the outside and not just 127, then you would be able to insert a rule into your firewall rules. i seen the version of redhat, are you running the old kernel(2.2) still, or have you upgraded(2.4-2.6)?
if not then you will have to look at the ipchains which i don't have a page for.
basically you will have your zones defined, eth0, eth1, loc, net, and so on. now you will have a fw that ties theses together and in the spot for eth0 you open up the routing for db's, for eth1 you shut it down.
i would set up your dhcp to give the db's a static address on that subnet that you're setting up. you can do that with your mac addresses from the db machines so it shouldn't be all that hard.
Thanks for your input everyone. I have found that the Option 2 (route add -net <db server IP address> netmask 255.255.255.255 eth0) will work best in this situation because all machines are on the same network, attached to the same switch, and other machines communicate to the same DB. I have tested this option out and it appears to work well. But there is one problem. When I reboot the machine this route goes away.
Do you know if there is a way to make this change permanent or make a change somewhere else that will be permanent. I saw a file named /etc/sysconfig/static-routes, but don't know if this is the right place or the format to put the entry in.
You might want to place the comend into /etc/rc.d/rc.local. If things are still like they use to be, you should just add:
/sbin/route add -net <db server IP address> netmask 255.255.255.255 eth0
Just a suggestion: Buy 2 additional ethernet cards to be inserted into each DB server, plus a small switch (or build a VLAN on an existing switch). Connect your Linux server and your 2 DB servers (new ethernet interfaces) to this newly created LAN segment using a completely different IP subnet. This is not really a very expensive solution and it will provide you with the very high performance configureation I think you are looking for.
Are you currently using a switch or a hub for your existing ethernet connectivity? If you are currently using a hub, you might want to get a 4 or 5 port switch connecting your Linux server Eth0, DB1 and DB1 plus a cross-over cable between the switch and the existing hub (that'd fill up 4 ports). Although the LinkSys and NetGear switchs are NOT enterprise quality, mine have been working flawlessly for a couple years now.