All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arthur van Leeuwen arthurvl@sci.kun.nl
To: lartc@vger.kernel.org
Subject: [LARTC] A complicated routing scenario (for me at least)
Date: Wed, 15 Nov 2000 19:30:26 +0000	[thread overview]
Message-ID: <marc-lartc-98373938216924@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938216914@msgid-missing>

<PRE>On Wed, 15 Nov 2000, Andrew wrote:

&gt;<i> Hello,
</I>&gt;<i> 
</I>&gt;<i> I appreciate all the comments, Let's keep it up. I promise I'll post the whole
</I>&gt;<i> thing when I have it all figured out. My mental picture is slowly filling out.
</I>&gt;<i> Three specific things I've got to know though: (diagrams are just for reference)
</I>
&gt;<i>  &gt; &gt;                                  LAN
</I>&gt;<i> &gt; &gt;                                   | (172...)
</I>&gt;<i> &gt; &gt;                                   |  (eth1)
</I>&gt;<i> &gt; &gt;          _/\__/\_             +---+----+            _/\__/\_
</I>&gt;<i> &gt; &gt;         /        \   (63...)  |        | (204...)  /        \
</I>&gt;<i> &gt; &gt;        ( Internet )-----------+ Router +----------( Internet )
</I>&gt;<i> &gt; &gt;         \_  __  _/    (eth0)  |        |  (eth2)   \_  __  _/
</I>&gt;<i> &gt; &gt;           \/  \/              +----+---+             \/  \/
</I>&gt;<i> &gt; &gt;                              (eth3)| 63..
</I>&gt;<i> &gt; &gt;                                    | 204..
</I>&gt;<i> &gt; &gt;                                    |
</I>&gt;<i> &gt; &gt;                  --+---------------+----------+--  &lt;---single physical
</I>&gt;<i> &gt; &gt;                    |                          |             net
</I>&gt;<i> &gt; &gt;                    |                          |        (i.e. one hub)
</I>&gt;<i> &gt; &gt;                    |                          |
</I>&gt;<i> &gt; &gt;                +---+---+ 63..1            +---+---+ 63..2
</I>&gt;<i> &gt; &gt;                | Linux | 63..4            | Linux | 63..3
</I>&gt;<i> &gt; &gt;                +-------+ 204..1           +-------+ 204..2
</I>&gt;<i> &gt; &gt;                          204..4                     204..3                       
</I>
&gt;<i> 1. If I modify the TOS field on incomming packets with IPchains, and then route
</I>&gt;<i> those packets to the proper internal server on my protected network, when that
</I>&gt;<i> server replies, what do the TOS fields in the reply packets look like? Are they
</I>&gt;<i> copies of the ones that came from the outside initiating the connection routed
</I>&gt;<i> through my router? (I hope that's the case) Or does the kernel on the replying
</I>&gt;<i> machine invent some new TOS value for those packets?
</I>
I really do not know.

&gt;<i> 2. On a machine with two IP addresses on the same nic (A and B). If someone on
</I>&gt;<i> the internet makes a connection to IP address A. What is the source address of
</I>&gt;<i> reply packets in the IP header diagram above? A? (I hope that's the case too.)
</I>
Yes, reply packets originate from the exact same IP address as the
originating packets were sent to. At least as far as I understand the
IP RFC's

&gt;<i> 3. Finally, is it necessary for the router box above to have two addresses on
</I>&gt;<i> the internal network. Does it matter that the default gateway that packets,
</I>&gt;<i> having a 204.. source address, go to might be a 63.. address? (or vice versa, as
</I>&gt;<i> long as all machines are connected to the same physical network) If it doesn't
</I>&gt;<i> then there is no need for a second IP address on the internal side of the router
</I>&gt;<i> (eth3 above). If it does matter, can I put in some fancy next-hop routes on the
</I>&gt;<i> servers based on what the source address of reply packets ends up being? (This
</I>&gt;<i> would essentially completely ignore the default route)
</I>
As long as there is a route from the nodes having a 204... address via the
router, the IP address of the router does not matter. Let me clarify a
little more. Suppose the Router only has a 63... address on the eth3
interface. To route 204 addresses from the internal servers you would set it
up so that *all* addresses *but* the address of that specific internal server 
are routed via the Router. In the Router you can then decide where to send
the packets. They will have the correct source and destination addresses, so
that is not a big problem.

&gt;<i> Something to remember (it may or may not matter to you): Valid packets coming in
</I>&gt;<i> on eth2 (204... above) will have a 204... destination address. Also Valid
</I>&gt;<i> packets coming in on eth0 (63... above) will have a 63... destination address.
</I>&gt;<i> Marking the packets as they come in is merely so that we can route them back on
</I>&gt;<i> the same interface they came in on. I don't want assymetric routes.
</I>
Oh, but in that case you won't even need to do the marking. The information
you need is already fully encapsulated in the IP addresses inside the
packet. Ofcourse, I'm assuming there's no nasty machine doing dastardly
deeds on that internal network of yours... :)

Doei, Arthur.

-- 
  /\    / |      <A HREF="mailto:arthurvl@sci.kun.nl">arthurvl@sci.kun.nl</A>      | 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



</PRE>

  parent reply	other threads:[~2000-11-15 19:30 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 [this message]
2000-11-15 20:11 ` Andrew
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-98373938216924@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.