All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Basic Routing
Date: Tue, 04 Nov 2008 17:13:38 -0600	[thread overview]
Message-ID: <4910D722.6050008@riverviewtech.net> (raw)
In-Reply-To: <490F5103.8070409@amfes.com>

(Now that I have time *AND* internet, DSL was out at the house last 
night... *GR!!!*)

On 11/03/08 13:29, Daniel L. Miller wrote:
> *dumbly nodding*  Ok.

Ok as in "Dough!" or ok as in "???"?

> *dumbly nodding - slight eye glazing*  Um....ok.

Remember that a system will decide where to hand the packet(s) off to 
(which router) by looking through its own routing table sequentially. 
The first route that is found that matches the destination that you are 
trying to reach is the route that is used to send the packet(s).

The /Default Gateway/ is a special route in such as it is the last 
resort at the end of the routing table.  So if no other routes (if there 
are any) match then the /Default Gateway/ route will match any 
destination, thus sending any packet(s) that did not match any other 
routes out through the /Default Gateway/.  Another way to think of the 
/Default Gateway/ is as a 'Catch All' route.

> *significant eye glazing - jaw slack*  Um...er...maybe...

(Are you having fun yet?)

> Rephrase - "Router C checks it's list of routes, figures out it's 
> clueless with regard to the route for Router D, and passes the buck to 
> Router C's default gateway"

Much closer.  Try this on for size.  "Router C checks it's list of 
routes, figures out it's clueless with regards to the route to host B, 
and passes the buck to Router C's default gateway."  (Remember that 
Router C knows how to reach Router D because they share the common 
connection.)


> *Excitedly* - That's it!  That's the part we need to talk about!  Router 
> "hands off the IP packet to the next router to the next to the next" -

Ok.  I think it's time for a quick segway in to how a packet(s) are 
passed around ethernet networks.

Remember that IP addresses /cross/ network boundaries and that MAC 
addresses are /confined/ with in network boundaries.  So we talk IP 
addresses across multiple different networks.  When two hosts with in 
the same network talk they really talk MAC address to MAC address.

Let's take your fairly simple diagram below.

+---+         +---+         +---+         +---+
| A +---(x)---+ C +---(y)---+ D +---(z)---+ B |
+---+         +---+         +---+         +---+

This is what the sequence of events will be for host A to send an IP 
packet to host B.

  - A sends an ethernet frame with a source MAC address of x.A and a 
destination MAC address of x.C, containing an IP packet with a source IP 
address of x.A and a destination IP address of z.B.
  - C sends an ethernet frame with a source MAC address of y.C and a 
destination MAC address of y.D, containing an IP packet with a source IP 
address of x.A and a destination IP address of z.B.
  - D sends an ethernet frame with a source MAC address of z.D and a 
destination MAC address of z.B, containing an IP packet with a source IP 
address of x.A and a destination IP address of z.B.

Notice how each pair of locally connected hosts (on the same network) 
talk to each other with their own MAC addresses to work together to pass 
the IP packet containing the actual message that is to be sent.

> Router C has a route table -
> 192.168.0.0/24 dev eth0
> 2.3.4.5 dev eth1
> default gateway 2.3.4.4
> 
> Router 2.3.4.4 (premise equipment from mysterious ISP)
> mysterious routing table
> 
> Router 5.4.3.1 (premise equipment from other ISP)
> more mysterious routing table
> 
> Router D has a route table -
> 10.0.0.0/8 dev eth0
> 5.4.3.2 dev eth1
> default gateway 5.4.3.1

Ok.  You just indicated that routers C and D are not directly connected 
to each other on the same ethernet network but rather are in different 
subnets, likely using different ISPs.  This complicates things a bit.

> Does the above communication involve NAT?  No "hosts" or private 
> networks involved - all public IP's between them (unless of course the 
> packets traverse private IP ranges within the ISPs' networks before 
> coming back out.

Possibly, at least for general internet access.  There will be NAT 
between the private LAN IP address space (192.168.0/24 and 10/8) and the 
internet.

That being said, if you establish a VPN between Router C and Router D 
across the internet (which I'm going to assume will be done), you can 
have LAN to LAN traffic with out NATing in between them.  This can 
happen because the VPN will encapsulate the traffic leaving the 
192.168.0/24 network going to the 10/8 network.  This encapsulation raps 
the packets and uses the globally routable IP address of Routers C and D 
as the source and destination IPs for the /VPN/ traffic.  When the VPN 
traffic reaches Router D, it will decapsulate it and send it out to the 
LAN on its end.

So, yes NAT is used to send normal traffic to the internet and no NAT is 
not used (VPN encapsulation is) to send LAN to LAN traffic.

> *Sheepishly* Assume for sake of argument I'm expressing myself poorly - 
> no proxies involved in this discussion.  That would make it too simple.

Ok.  I just had to double check, you understand why.  :)

> *Assertively* No proxy.

*nod*

> Um...no.  Too complicated.
> 
> A==>C<==Internet==>D<===B

(See my email from yesterday afternoon.)

> Two offices on opposite sides of the world linked via Internet.

*nod*

This means that you will most likely be dealing with VPNs

> So the world's most expensive super-duper whatchamacallit (fill in the 
> blank here with router, firewall, bridge, modem, magic cauldron), placed 
> between giant corporate's network (using private address space) and the 
> Internet - will perform NAT?  Somewhere somehow NAT (in particular, 
> source NAT for outbound access from the private and destination NAT to 
> provide services to Internet) must be performed?

Correct.  The word you are looking for is usually a router that does 
firewalling, or sometimes knows as a firewalling router.  (Remember that 
firewalls really /filter/ traffic while routers /route/ traffic, 
sometimes altering it along the way.)

Even IBM and Microsoft (presuming they are using private class IP 
address space) are either running NATing routers between their internal 
corporate networks.  (As an alternative they could be doing proxying, 
but it is most likely that they are using NAT.)



Grant. . . .

  parent reply	other threads:[~2008-11-04 23:13 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-02 16:15 Basic Routing Daniel L. Miller
2008-11-02 17:03 ` Rob Sterenborg
2008-11-02 18:43   ` Daniel L. Miller
2008-11-02 19:53     ` Rob Sterenborg
2008-11-03  1:59       ` Daniel L. Miller
2008-11-02 20:04     ` Grant Taylor
2008-11-02 20:51     ` Grant Taylor
2008-11-03  1:52       ` Daniel L. Miller
2008-11-03  2:34         ` Grant Taylor
2008-11-03 19:29           ` Daniel L. Miller
2008-11-03 19:39             ` Daniel L. Miller
2008-11-03 20:26               ` Grant Taylor
2008-11-05  0:00                 ` Daniel L. Miller
2008-11-05  5:21                   ` Rob Sterenborg
2008-11-05 15:56                     ` Grant Taylor
2008-11-05 18:22                       ` Rob Sterenborg
2008-11-05 18:30                         ` Grant Taylor
2008-11-05 19:49                           ` Rob Sterenborg
2008-11-05 15:24                   ` Grant Taylor
2008-11-03 23:40               ` Amos Jeffries
2008-11-04 23:13             ` Grant Taylor [this message]
2008-11-04 23:53               ` Daniel L. Miller
2008-11-05 12:24                 ` John Haxby
2008-11-05 17:31                   ` Grant Taylor
2010-09-20 21:40                     ` Daniel L. Miller
2010-09-20 23:41                       ` Jan Engelhardt
2010-09-21  3:34                       ` Grant Taylor
2008-11-05 17:17                 ` Grant Taylor
2008-11-02 19:06   ` Grant Taylor
2008-11-03 10:54     ` Pascal Hambourg
2008-11-03 16:35       ` Grant Taylor
  -- strict thread matches above, loose matches on Subject: below --
2014-10-04  1:10 Basic routing John Smithee
2014-10-04  1:24 ` John Smithee
2014-10-04  8:50   ` George Botye
2014-10-04  1:34 ` Neal Murphy
2014-10-04  2:52   ` John Smithee
2014-10-04  3:05     ` Dennis Jacobfeuerborn
2014-10-04  5:02     ` Neal Murphy
2014-10-04  7:04     ` John Lister
2014-10-04 11:06       ` John Smithee
2014-10-04 13:56         ` Thomas Bätzler
2014-10-04 15:07           ` John Smithee
2014-10-04 17:44             ` John Smithee
2014-10-05 15:41               ` John Lister
2014-10-06  9:41               ` André Paulsberg

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=4910D722.6050008@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=netfilter@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.