Subject: [LARTC] A complicated routing scenario (for me at least)

From: Andrew <[email-masked]>
Date: Mon, 13 Nov 2000 14:58:14 -0800

Greetings:

I've been pouring over every piece of documentaiton on the subject I can
find, and I've concluded that advanced routing + ipchains is what I
need. It also appears that the people that can answer some of the more
in depth questions I have, read this list.

I'm fairly new to this so please forgive me if I ask stupid questions.
Anyway.

Here is what I'm trying to accomplish in ASCII art:

                                 LAN
                                  | (172...)
                                  |
         _/\__/\_             +---+----+            _/\__/\_
        /        \   (63...)  |        | (204...)  /        \
       ( Internet )-----------+ Router +----------( Internet )
        \_  __  _/            |        |           \_  __  _/
          \/  \/              +----+---+             \/  \/ 
                                   | 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

The desired end result is a redundant connection to two dns/mail servers
from the 
internet. I'm willing to fight through this, but I have a few specific
question's 
for now that I'm hoping someone can answer.

1. From a server's perspective, do incoming packets get responded to on
the same interface they came in on? Does it matter if the interface in
question is an alias?

2. if I tag a packet coming into the router/firwall above with ipchains
for routing purposes, will the tag persist to the reply packets? Or do I
have to tag the reply packets with ipchains from the responding server?

3. In reading the various documentation, I noticed several references to
files in the /etc/iproute2 directory. Related to this directory:
	a) is there any documentation on the names and syntax of the various
files other than the source code, and the casual references I've found?
	b) I don't currently have this directory in /etc. Is it something I
just create, and does it's existance imply that the kernel will read
configureation data from it on boot?

Incidentally I'm currently using kernel 2.2.17 on my boxes. Since I'm
already going to be meticulously documenting my setup, I'd be willing to
do so in a format that could be posted as a HOWTO or as an example in
someone else's HOWTO, whatever would be most usefull.

Suggestions in this area are much appreciated since I have no experiance
in HOWTO writing. (Plenty of writing experiance, just not howtos)

Anyway, Thanks for the help.

-Andrew

---

From: Arthur van Leeuwen <[email-masked]>
Date: Tue, 14 Nov 2000 15:34:36 +0100 (MET)

> in depth questions I have, read this list.

Might be true, might be true. ;)

> I'm fairly new to this so please forgive me if I ask stupid questions.

We're all fairly new to this. It isn't older than a year or two, three at the
most.

>                                  LAN

Hmmm. Right.

> from the internet. I'm willing to fight through this, but I have a 
> few specific question's for now that I'm hoping someone can answer.

> the same interface they came in on? 

No, unfortunately not. In fact, unless you specifically set things up so
that it will go right the kernel will even play haywire with which interface
packets with certain IP addresses are routed out.

> Does it matter if the interface in
> question is an alias?

No. By the way, drop the mental concept of alias. With the iproute2 ip tool
it only serves to confuse matters. Interfaces kan have multiple IP addresses
attached to them. This is *much* more portable to IPv6... :)

> for routing purposes, will the tag persist to the reply packets? 

No.

> Or do I have to tag the reply packets with ipchains from the responding 
> server?

Yes.

> configureation data from it on boot?

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.

> in HOWTO writing. (Plenty of writing experiance, just not howtos)

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. ;)

> Anyway, Thanks for the help.

No problem.

Doei, Arthur.

-- 
  /\    / |      [email-masked]      | Work like you don't need the money
 /__\  /  | A friend is someone with whom | Love like you have never been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody watching

---

From: "Wingtung.Leung" <[email-masked]>
Date: Tue, 14 Nov 2000 15:44:09 +0100 (MET)

> have to tag the reply packets with ipchains from the responding server?

You'll have to tag them whenever they enter your gateway. The reply
packets are just packets, at ip level there is no difference between them.
Only the very first packets, which initiate the connection, carry some
extra flags.

> configureation data from it on boot?

I believe you can just create that directory and the files.

> in HOWTO writing. (Plenty of writing experiance, just not howtos)

There is an HOWTO about writing HOWTO's, I think. Try
http://www.linuxdoc.org/ for more elaborate info.

Salukes,

Tung

---

From: Andrew <[email-masked]>
Date: Tue, 14 Nov 2000 12:15:47 -0800

Thanks for the reply, Here are a few more questions

> >                                   |  (eth1)
> >         \_  __  _/    (eth0)  |        |  (eth2)   \_  __  _/
> >           \/  \/              +----+---+             \/  \/
> >                              (eth3)| 63..
> >                                    | 204..
> >                                    |

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.)

> 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
[email-masked]

---

From: Whit <[email-masked]>
Date: Tue, 14 Nov 2000 16:47:28 -0500

Andrew,

I'm awfully glad you're asking these questions, since I'm contemplating a
similar setup and am not yet to that wonderful place where this presently
obscure new technology resolves into clarity. So I'll be trying to follow
along closely as you work out your scheme.

One question I have, in addition to those you're asking, is whether iproute2
in itself is adequate to handle fallover routing when one of the outside
links goes down - that is, can it just be set up with lower priority rules
to route the other way, or does something like mon
(http://www.kernel.org/software/mon/) need to be set up to actively change
the routing tables when an outside line goes down?

 \/\/ I-I I T 
 Blauvelt
 [email-masked]

---

From: "Wingtung.Leung" <[email-masked]>
Date: Wed, 15 Nov 2000 00:10:41 +0100 (MET)

> have a redhat 6.2 system.)

Maybe you should try it first and experiment a bit. It's rather hard to
answer on vague questions.

> same time being able to reset the TOS field back to zero for routing on

As far as I understand your question: you can change the TOS based on the
incoming interface (and lots of other options). And I think it isn't
usefull to reset the TOS field when you send out the packets into the
internet, because most routers won't use the field and simply ignore it.
When a packets comes back, you should route it dependand on the
destination, not on the TOS field because that can be anything.

I hope I haven't told complete nonsense.

Tung

---

From: Arthur van Leeuwen <[email-masked]>
Date: Wed, 15 Nov 2000 11:49:50 +0100 (MET)

> along closely as you work out your scheme.

Hey, I've never done stuff like Andrew's proposing either. It's cool. I want
to know if it'll work. :)

> the routing tables when an outside line goes down?

Hmmm. Methinks that with the preferences associated with routes and the
effects of neighbor unreachability detection this should work. This 
remark is wholly untested, though.

Doei, Arthur.

---

From: Arthur van Leeuwen <[email-masked]>
Date: Wed, 15 Nov 2000 12:27:29 +0100 (MET)

> answer on vague questions.

But not impossible. There is the iproute2 code that does the actual
parsing of the files in /etc/iproute2, and there is some information in the
ip-cref doc. The parser is the function rtnl_tab_initialize in
lib/rt_names.c of the iproute2 source tree. The syntax is one of the
following for scanf formats (read the manpage for scanf if you can't parse
these by sight):

0x%x %s\n
0x%x %s #
%d %s\n
%d %s #

Implied is basically a key-value table, with decimal or hexadecimal numbers
as keys and strings as values. Comments are allowed and whitespace is mostly
ignored. There has to be some between keys and values though. :)

If there are syntax errors you will only see numbers instead of nice user
friendly names, after the ip or tc tool has complained about 'Database <xyz>
is corrupted at <foobar>', with one of the files instead of <xyz> and part
of the file instead of <foobar>

Doei, Arthur.