[nos-bbs] tun0 and more Linux routing commands

[Jay Nugent]

Greetings,

On Mon, 14 Feb 2011, George [ham] VerDuin wrote:

> Interesting question Maiko.
> 
> 
> On 02/14/2011 05:09 PM, Maiko Langelaar wrote:
> >
> > >>SNIP<<I've never understood this need for ARP that I see so many 
> > times. Is this
> > something from the old days ? I've never used it. If I am on a 
> > particular Winxp on my LAN, I simply do 'route add 192.168.1.201 
> > 192.168.1.60' on the
> > particular PC, and I can telnet, browse, whatever to my JNOS. In the 
> > above
> > example route, JNOS=192.168.1.201 and LINUX(running JNOS)=192.168.1.60.
> >
> > Can anyone educate me on why I see so many people putting this arp 
> > thing in ? Is there some functionality that I am missing out of this ?

   When a link (TUN) between two points is defined, it can be done in two
ways.  First, as two IP addresses including a 'net' address and a
'broadcast' address.  This eats up 4 IP addresses and is *totally*
unnecessary.  *WHY* on a link with only TWO ends would there ever be the
need to ARP to determine the MAC address of the far end?  Insane...

   The second (and better) method is to define the TUN link as
"point-to-point".  With this method the two ends KNOW about each other and
NO need to ARP the far ends MAC address before passing layer-2 packets
over it.  And, this only uses up two IP addresses.  I might add that there
is NO reason these end-point addresses even be within the same subnet.  
They can, and in large scale networking often are, on completely different
subnets.


   Suggestion:  
      - Assign the Linux box an IP on your LAN (192.168.1.88)
      - Assign the Linux end of the TUN interface another IP on your LAN 
        (192.168.1.44)

      On your gateway router to the Internet:
         - Port forward SSH to the Linux address (192.168.1.88)
           In this way you can remotely log onto your Linux machine to 
           read mail, perform maintenance, play around.

         - Assign the JNOS address (192.168.1.44) as the "DMZ Host".
           This lets everything *other* than SSH (which has been port 
           forwarded elsewhere) to be automatically directed to the JNOS 
           application (and into its own TCP/IP stack).  In this way ALL 
           protocols including "IPIP Encapsulation (Protocol-4)" to go 
           directly to JNOS.
           You can now Telnet and FTP and Finger the JNOS application from 
           anywhere on the Internet :)
           (WARNING! Block inbound SMTP(25) with the "tcp access" tools or 
                     you *will* be flooded with spam!)


   Here is the 'interesting' thing about ARP.  When any host on your LAN
(or an incoming packet from the Internet destined for the "DMZ Host")  
causes an ARP "Who Has" request asking for the JNOS/TUN MAC address --
even though the TUN interface is *inside* the Linux box, the Linux box
WILL respond to that ARP and answer giving the MAC of the Linux ethernet
card.  It answers for BOTH the Linux machine itself and for the JNOS TUN.

   As you can see, both the Linux machine itself -and- the JNOS 
application/VM *look* like two completely seperate machines as far as ARP 
and addressing are concerned.  Their only common part happens to be their 
MAC address :)


> I sorta get the concept of ARP broadcast causing any host listening on 
> the LAN to insert the address into its own routing cache for future use 
> in routing path decisions at the remote host.  The part that baffles me 
> about it's popularity is timing of the action.  Say the remote host 
> boots later than the ARP broadcast -- just how does that  remote host 
> take benefit from the ARP?  Also -- if routing to jnos stack works for 
> hosts booting later than jnos startup then why ARP at all?  I guess I 
> could hear from that same expert?

   Many folks haven't a clue how and why ARP is necessary.  IP has *no*
clue how to talk between any two machines on an ethernet!!!  ONLY the
802.3 ethernet "frames" know how to talk from machine to machine, using
their respective MAC addresses.

   IP "packets" (LINK Layer-2) ride over the top of these 802.3 frames.  
So there needs to be a way to "associate" the MAC address with an IP
address.  This is done using Address Resolution Protocol (ARP).

   When Box-A wishes to talk to Box-B it first sends out an ARP "Who Has" 
stipulating the desired destination IP address.   ALL boxes listen to this 
Packet addressed to the "Broadcast IP Address" (regardless of MAC).

   Box-B 'hears' this "Who Has" packet, recognizes its IP address in the
request, and responds back to Box-A with an "I Have" packet containing
Box-B's MAC address.

   Once this exchange is completed, BOTH boxes now store what they learned
into their ARP Table.  You can see this on a UNIX/Linux machine by typing
'arp -a'.  The ARP table automatically expires its entries every 5 to 10
minutes.  So as long as that entry lives, Box-A and Box-B talk 
effortlessly.  Once the ARP table expires, they will again do an ARP 
exchange to refresh the ARP table data.


   Hope this helps to shed some light on the process...


   Enjoy!
      --- Jay Nugent  WB8TKL

        () ascii ribbon campaign in
        /\ support of plain text e-mail
             
Train how you will Operate, and you will Operate how you were Trained.
+------------------------------------------------------------------------+
| Jay Nugent   jjn at nuge.com    (734)484-5105    (734)649-0850/Cell       |
|   Nugent Telecommunications  [www.nuge.com]                            |
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring |
| Web-Pegasus    [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
+------------------------------------------------------------------------+
 11:01am  up 79 days, 19:40,  3 users,  load average: 0.62, 0.16, 0.07