[Novalug] stuck at reading route, traceroute

Peter Larsen peter@peterlarsen.org
Fri Dec 9 18:14:34 EST 2016


Walt,
Before I venture further into trying to help, I really think taking time
to read a book or taking a class on networking fundamentals would help
you a lot. While I love the "learn while stumbling" myself - ie. I jump
in on the deep water and see what happens, there are times where that
leads to more frustrations for what it's worth (gives an evil stare to
his Satellite Server as he says that).  There are a ton of free
resources online - this one is is quite readable:
http://www.tcpipguide.com/free/t_NetworkingFundamentals.htm

I think there's some fundamental issues here that we need to address
before talking about IPs and stuff.  Ethernet - the most typical network
we have today (it's not always been so), is a very chatty network. It's
a network where all devices connected to the same subnet have a direct
connection to everyone else in the same network. No gateway, no nothing.
Every machine can send a signal and have it received by another one on
the "same wire" so to speak. Before Ethernet "won" we had another very
popular networking type, called Token Ring. In this network topology,
all devices were serially connected to one an another, and the ends were
connected together. In other words, forming a ring. The nodes on such a
network had to have a "token" to speak, and the advantage was speed - no
chatter. Ethernet on the other hand, everyone can speak whenever they
want to, but if two speak at the same time, we have a collision and
"everyone tries again". This is what switches helps fixing - a switch
only forwards traffic from a node when "the coast is clear" and will
hold on to traffic while other stuff is passing thru. A hub is dumb, and
basically just connects all the wires together so here the nodes will
see all the chatter from the other nodes, and well - that keeps them
quite busy. So well, we got rid of hubs - switches are so cheap today
that they make no sense.

So in a traditional ethernet today, you have a "star' topology. Everyone
is connected to a central "switch". The switch is a layer 2 thing - it
understands hardware addresses - nothing more, ie MAC addresses. Ie. the
switch will know which MAC addresses are visible on each port, so when a
package comes in to a specific MAC address it sends it out of the port
where it knows the MAC is. Only on that port - not the others. A hub
would send it to everyone, and it's up to each node to ignore traffic
not meant for them.

This means, that in the same network like your home network, there's no
need for a gateway for laptop1 to send/receive to/from laptop2. It
simply needs to set the MAC for the receiving system and off it goes.
That's what the ARP protocol is for - and you will notice quite a few
broadcasts on your network with ARP's saying "who has this IP address"
and answers back "IP is at this MAC" - and the node builds up an ARP
table (you can see it with the arp command) so it doesn't have to ask
all the time. So if you have a package to 192.168.10.2 here's what your
network does:

Look for 192.168.10.2 in the arp table - if found, fill in the ARP
destination address with what's in the cache.
If not found, send an ARP "who-has 192.168.10.2" broadcast to
ff:ff:ff:ff:ff:ff - that means everyone. The system that has IP
192.168.10.2 sees that broadcast and responds "192.168.10.2 is at
1a:2b:3c:4d:5e:6f", the arp table gets updated and the package is
created and sent on the network.  Yup - it's that basic.

For your computer to know if it's got access to the 192.168.10/24
network, it uses the route table. If it finds that subnet it finds the
port on which that subnet is found, and that determins which port to
send it on. If it does NOT find it, it knows it has to get there through
an intermediary - and that's what we call a route. Routing is between
networks. Not within it. To figure out who that intermediary is, your
system looks for the first route that matches the subnet it wants to
send to.  The "wildcard" here is 0.0.0.0 - which means "everything
matches" (named "default") so if you have nothing else, the IP that
comes with that wildcard is where your system sends the package to,
expecting it to know where to send it. It may just end up sending it to
someone else etc. - and that's what traceroute shows you.

Ie. here's a simple server I have:
# ip route
default via 192.168.11.1 dev enp4s0  proto static  metric 100
192.168.11.0/24 dev enp4s0  proto kernel  scope link  src 192.168.11.90 
metric 100

The route table here says that traffic to 192.168.11/24 is sent via
enp4s0 (remember, I explained that eth0, eth1 etc. aren't really that
good of a name). When it sends to that network, it will say it comes
from 192.168.11.90.  Now, if it has to send packages to ANY OTHER IP, it
has to go through intermediare 192.168.11.1 - note, and this is
important, that this gateway address is within the already known subnet.
If it wasn't it wouldn't know how to send stuff there. So if I try to
send a package to 10.2.3.4, this system will send the package to
192.168.11.1 and wait for that server to get a response. However, if
that server wants to talk to 192.168.11.12 for instance, it will look in
the ARP table for the MAC and just send it there:

# arp -n
Address                  HWtype  HWaddress           Flags
Mask            Iface
192.168.11.14            ether   0c:c4:7a:b3:fa:63  
C                     enp4s0
192.168.11.213           ether   54:ee:75:86:bd:69  
C                     enp4s0
192.168.11.12            ether   d4:3d:7e:9c:5a:a0  
C                     enp4s0
192.168.11.13            ether   52:54:00:c3:c7:57  
C                     enp4s0
192.168.11.45            ether   00:1e:8c:f5:6b:b7  
C                     enp4s0
192.168.11.16            ether   52:54:00:28:e5:59  
C                     enp4s0
192.168.11.1             ether   d4:3d:7e:9c:5a:a0  
C                     enp4s0
192.168.12.103           ether   54:ee:75:86:bd:69  
C                     enp4s0

As you can see, 192.168.11.12 is at d4:3d:7e:9c:5a:a0 so it sends the
package DIRECTLY to that server - not via the gateway.  And yes, it's
not an error that more than one IP points to the same MAC - think about
it and ask if that doesn't make any sense. The route table can easily be
larger - here's a server running OpenShift:

$ ip route
default via 192.168.11.1 dev eth0  proto static  metric 100
10.1.0.0/16 dev tun0  proto kernel  scope link
172.30.0.0/16 dev tun0  scope link
192.168.11.0/24 dev eth0  proto kernel  scope link  src 192.168.11.61 
metric 100

As you can see, it has 3 networks associated with it - so it will only
use the 192.168.11.1 router if it has a package that doesn't fall within
the 3 listed networks (subnets).

To me, it was very late that it actually sunk in what layer 2 was used
for, why everything had MAC addresses etc. So please don't think that
because it doesn't make sense initially that there's something wrong.

As for cabling - our devices are smart today. There's no male/female
issues anymore. All cables are male/male. The only difference in
cat5/5e/6 is insulation. All devices are female. And the cables only go
in one way. With ethernet you center your network around one or more
switches (home networks are typically just a single switch maybe 4 or 8
ports). It gets really funky when we have networks connected to one
another and there may be loops in them. That's where the big ass
expensive switches comes in - but for simple home networking there's
nothing fancy going on (we also call those switches "unmanaged" - vs.
managed switches that has command interfaces, configurations, security
and lots more).  So if you imagine having 4 PCs you want in a network in
the same room, they all plug into the same switch. Assuming that switch
also pretends to do some routing and offers DHCP, that means every PC
gets an IP in the same subnet, and presto they can talk together, do
gaming etc. without bugging the router part. But the switch on the other
hand deals with every package going in/out of the ports - that's mostly
electrical circuits and not so much CPU/processing so that's why they're
cheap.

I hope things are a bit clearer now.


-- 
Regards
  Peter Larsen




On 12/09/2016 05:20 PM, Walt Smith via Novalug wrote:
>
> Hi,
>
> Thought I'd better review fundamentals:
>
> the routes as the packets leave my box 
> and get out to the Internet:
>
>
> On a ppp dialup, I show a route  and a traceroute
> and a ifconfig below, hopefully readable on wide screen..
>
> 1. 
> The route -n shows the gateway as 0.0.0.0, which I always
> thought of as default going out.  However, some reading 
> has told me that the * means there is No Gateway !!
>
> But the default route below also shows no gateway.
> Is destination 0.0.0.0 a special case ?  IF default is
> by definition 0.0.0.0, where does the next packet go- 
> i.e. which interface etc?
>
> 2.
> Neither route nor traceroute  show the linux end at the modem
> of the ppp0 IP number:  69.72.x.x which I assume to be at the 
> dialup modem at my end.  It starts at the other end of the telco.
>
> Aren' there interfaces ( even if ppp virtual ) between the lo
> interface and the telco's access point end ?  does the 69.x.x
> belong to the modem ?  or the serial port ?
>
> 3. why does the traceroute  in case 2 below show the telco's
> access point as the first IF rather than the virtual ppp 69.72.x.x ?
>
> 4. And a validating Q:
> in ifconfig below, would 209.163.x.x be considered a "gateway "
> and the 69.x.x.x be the virtual ppp address at my end ?
>
> thx,
>
> Walt . . . .
>
> ----------------------
>
> [root@CentOS68 etc]# route
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> mgmt-apx01.bltm *               255.255.255.255 UH    0      0        0 ppp0
> default         *               0.0.0.0         U     0      0        0 ppp0
>
> [root@CentOS68 etc]# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 209.163.113.81  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
> 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
>
> [root@CentOS68 etc]# traceroute 69.72.61.28
> traceroute to 69.72.61.28 (69.72.61.28), 30 hops max, 60 byte packets
>  1  core-bltm-69-72-61-28.dynamic-dialup.coretel.net (69.72.61.28)  0.068 ms  0.019 ms  0.018 ms
>
> [root@CentOS68 etc]# traceroute 209.163.113.81
> traceroute to 209.163.113.81 (209.163.113.81), 30 hops max, 60 byte packets
>  1  mgmt-apx01.bltm.coretel.net (209.163.113.81)  1210.309 ms  1210.215 ms  1212.207 ms
> [root@CentOS68 etc]# traceroute sdf.org
> traceroute to sdf.org (192.94.73.15), 30 hops max, 60 byte packets
>  1  mgmt-apx01.bltm.coretel.net (209.163.113.81)  122.757 ms  137.267 ms  247.392 ms
>  2  gw1-apx1.bltm.coretel.net (209.163.113.193)  213.304 ms gw2-apx1.bltm.coretel.net (209.163.113.197)  232.230 ms gw1-apx1.bltm.coretel.net (209.163.113.193)  247.196 ms
>  3  jr1-balt-ge-0-0-9.qis.net (209.150.98.73)  232.163 ms  268.888 ms  287.851 ms
>
>
>
>
> ppp0      Link encap:Point-to-Point Protocol  
>           inet addr:69.72.61.236  P-t-P:209.163.113.81  Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
>           RX packets:596 errors:5 dropped:0 overruns:0 frame:0
>           TX packets:618 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:3 
>           RX bytes:264368 (258.1 KiB)  TX bytes:64163 (62.6 KiB)
>
>
>
> ----
>  The government is lawless, not the press (people).
>  ( [Supreme Court] Justice Douglas re: The Pentagon Papers )
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug






More information about the Novalug mailing list