From: Andrew andrewd@uccsda.org
To: lartc@vger.kernel.org
Subject: [LARTC] A complicated routing scenario (for me at least)
Date: Wed, 15 Nov 2000 20:11:23 +0000 [thread overview]
Message-ID: <marc-lartc-98373938216925@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938216914@msgid-missing>
<PRE>><i> > > > LAN
</I>><i> > > > | (172...)
</I>><i> > > > | (eth1)
</I>><i> > > > _/\__/\_ +---+----+ _/\__/\_
</I>><i> > > > / \ (63...) | | (204...) / \
</I>><i> > > > ( Internet )-----------+ Router +----------( Internet )
</I>><i> > > > \_ __ _/ (eth0) | | (eth2) \_ __ _/
</I>><i> > > > \/ \/ +----+---+ \/ \/
</I>><i> > > > (eth3)| 63..
</I>><i> > > > | 204..
</I>><i> > > > |
</I>><i> > > > --+---------------+----------+-- <---single physical
</I>><i> > > > | | net
</I>><i> > > > | | (i.e. one hub)
</I>><i> > > > | |
</I>><i> > > > +---+---+ 63..1 +---+---+ 63..2
</I>><i> > > > | Linux | 63..4 | Linux | 63..3
</I>><i> > > > +-------+ 204..1 +-------+ 204..2
</I>><i> > > > 204..4 204..3
</I>><i>
</I>><i> > 1. If I modify the TOS field on incomming packets with IPchains, and then route
</I>><i> > those packets to the proper internal server on my protected network, when that
</I>><i> > server replies, what do the TOS fields in the reply packets look like? Are they
</I>><i> > copies of the ones that came from the outside initiating the connection routed
</I>><i> > through my router? (I hope that's the case) Or does the kernel on the replying
</I>><i> > machine invent some new TOS value for those packets?
</I>><i>
</I>><i> I really do not know.
</I>Based on your comments below, It appears to be a moot point.
><i>
</I>><i> > 2. On a machine with two IP addresses on the same nic (A and B). If someone on
</I>><i> > the internet makes a connection to IP address A. What is the source address of
</I>><i> > reply packets in the IP header diagram above? A? (I hope that's the case too.)
</I>><i>
</I>><i> Yes, reply packets originate from the exact same IP address as the
</I>><i> originating packets were sent to. At least as far as I understand the
</I>><i> IP RFC's
</I>><i>
</I>><i> > 3. Finally, is it necessary for the router box above to have two addresses on
</I>><i> > the internal network. Does it matter that the default gateway that packets,
</I>><i> > having a 204.. source address, go to might be a 63.. address? (or vice versa, as
</I>><i> > long as all machines are connected to the same physical network) If it doesn't
</I>><i> > then there is no need for a second IP address on the internal side of the router
</I>><i> > (eth3 above). If it does matter, can I put in some fancy next-hop routes on the
</I>><i> > servers based on what the source address of reply packets ends up being? (This
</I>><i> > would essentially completely ignore the default route)
</I>><i>
</I>><i> As long as there is a route from the nodes having a 204... address via the
</I>><i> router, the IP address of the router does not matter. Let me clarify a
</I>><i> little more. Suppose the Router only has a 63... address on the eth3
</I>><i> interface. To route 204 addresses from the internal servers you would set it
</I>><i> up so that *all* addresses *but* the address of that specific internal server
</I>><i> are routed via the Router. In the Router you can then decide where to send
</I>><i> the packets. They will have the correct source and destination addresses, so
</I>><i> that is not a big problem.
</I>
Wonderful...
><i>
</I>><i> > Something to remember (it may or may not matter to you): Valid packets coming in
</I>><i> > on eth2 (204... above) will have a 204... destination address. Also Valid
</I>><i> > packets coming in on eth0 (63... above) will have a 63... destination address.
</I>><i> > Marking the packets as they come in is merely so that we can route them back on
</I>><i> > the same interface they came in on. I don't want assymetric routes.
</I>><i>
</I>><i> Oh, but in that case you won't even need to do the marking. The information
</I>><i> you need is already fully encapsulated in the IP addresses inside the
</I>><i> packet. Ofcourse, I'm assuming there's no nasty machine doing dastardly
</I>><i> deeds on that internal network of yours... :)
</I>
You're right. Since packets get responded to on the exact same address they came
in on, All I have to do in the router is look at the source address. If it is a
204.. address then route it out the 204.. pipe. If it is a 63.. address then
route it out the 63... pipe. Cool!
</PRE>
next prev parent reply other threads:[~2000-11-15 20:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-13 22:58 [LARTC] A complicated routing scenario (for me at least) Andrew
2000-11-14 14:34 ` Arthur
2000-11-14 14:44 ` Wingtung.Leung
2000-11-14 20:15 ` Andrew
2000-11-14 21:47 ` Whit
2000-11-14 23:10 ` Wingtung.Leung
2000-11-15 10:49 ` Arthur
2000-11-15 11:27 ` Arthur
2000-11-15 14:57 ` Warren
2000-11-15 19:20 ` Andrew
2000-11-15 19:30 ` Arthur
2000-11-15 20:11 ` Andrew [this message]
2000-11-17 1:07 ` Andrew
2000-11-17 12:11 ` Mike
2000-11-17 12:24 ` Mike
2000-11-17 13:00 ` Arthur
2000-11-17 21:25 ` Mike
2000-11-18 16:28 ` Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-98373938216925@msgid-missing \
--to=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.