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. . . .
next prev 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.