Thanks for the reply, Here are a few more questions > > LAN > > | (172...) > > | (eth1) > > _/\__/\_ +---+----+ _/\__/\_ > > / \ (63...) | | (204...) / \ > > ( Internet )-----------+ Router +----------( Internet ) > > \_ __ _/ (eth0) | | (eth2) \_ __ _/ > > \/ \/ +----+---+ \/ \/ > > (eth3)| 63.. > > | 204.. > > | > > --+---------------+----------+-- <---single physical > > net > > | | (i.e. one hub) > > | | > > +---+---+ 63..1 +---+---+ 63..2 > > | Linux | 63..4 | Linux | 63..3 > > +-------+ 204..1 +-------+ 204..2 > > 204..4 204..3 > a. There are examples for these files in /usr/doc/iproute-2.2.4/iproute2/ on > RedHat 6.2 systems with iproute2 installed and in > /usr/share/doc/iproute-2.2.4/iproute2/ on RedHat 7.0 systems. > These files all have names starting with rt_, and should also be in > the iproute2 tarball, but I'm too lazy to check :). > b. The directory can contain the files rt_dsfield, rt_protos, rt_realms, > rt_scopes and rt_tables. Most of the values in these files are user > settable, and will be read when the files exist. If they do not exist you > do not get nice names and have to deal with the raw numbers. Note: they > are *not* necessary for operation, just useful from a user's point of > view. OK.. someplace else to look. Are the examples the only thing available in the way of file syntax? Also could someone help me understand how these files are read at startup if they exist. (what code/script is responsible for doing it, and what happens if there are syntax errors. I have a redhat 6.2 system.) > Well, an ASCII-gram such as the one above and step by step explanations of > your setup and *why* you've taken those steps would be great. ;) If/When I get this written up, is this mailing list the place to post it? Would there be any value in puting it into a separate (mini)-HOWTO? Based on what everyone's said, here is what I'm contemplating (this still assumes that that packets are answered on the same interface they come in on. I'm getting conflicting information for this. Someone said they do, and someone else said they don't. I suppose if they don't I could use an explicit source address hint in a routing table entry.): Packets coming in on eth0,1, and 2 would be marked with different TOS values based on what interface they came in on using ipchains, and routed through the proper address on eth3 using the advanced routing. Since the TOS field doesn't change (an assumption, is this true?) I would know which interface to route the packet back through while at the same time being able to reset the TOS field back to zero for routing on the internet. Comments? Suggestions? Thanks, -Andrew depaan@xxxxxxxxxxxxx
