[ale] Does Linux discover routes by magic? Does Traceroute fib?

[Michael H. Warfield]

Neal,

On Thu, 2013-01-17 at 12:41 -0500, Neal Rhodes wrote:
> Maybe this is basic linux routing that I've been oblivious to all these
> years. 

> Picture a local lan with a primary Sonicwall router at 192.168.220.1, 
> and a little Cisco router to handle one side of a T1 circuit sitting at
> 192.168.220.254, and the network on the other side of the T1 is
> xxx.yyy.47.0. 
> 
> The servers have nothing but the most minimal routing: 
> Kernel IP routing table on EV4:
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0
> eth0
> 169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0
> eth0
> 0.0.0.0         192.168.220.1   0.0.0.0         UG        0 0          0
> eth0

> When we traceroute to a host on the other side of the T1...
> traceroute to xxx.yyy.47.9 (xxx.yyy.47.9), 30 hops max, 60 byte packets
>  1  192.168.220.254 (192.168.220.254)  2.043 ms  2.055 ms  2.128 ms
>  2  xxx.yyy.42.129 (xxx.yyy.42.129)  20.148 ms  20.974 ms  22.040 ms
>  3  xxx.yyy.41.41 (xxx.yyy.41.41)  23.397 ms  24.409 ms  25.533 ms
>  4  * * *
>  5  xxx.yyy.47.9 (xxx.yyy.47.9)  30.735 ms  31.734 ms  33.216 ms

To answer your subject line...

Does Linux discover routes by magic?  Depends on your definition of
magic.

Does traceroute fib?  No, traceroute reports on the responses it
receives at the application layer.

What, I believe, you have encountered here is an ICMP REDIRECT.

The Sonicwall router probably has in it a default route pointing to
192.168.220.254.  When it receives a packet that it would then route
back out the same interface, it issues an ICMP redirect back to the
requester to reroute the packet to the new address.  The low level stack
on originating system receives the redirect and sends further packets to
the new router, if it properly honors the redirect, which Linux does.

I believe that the Sonicwall also directly forwards the packet,
unprocessed, to the redirect target, so you get your first response from
it, not the Sonicwall, otherwise the originating system would have to
resend the packet which would not work with UDP.

This all happens at the IP layer, well below the UDP or TCP layers, so
the high level packets, that traceroute depends on, never get tested for
TTL failure (which is what traceroute uses for a hop count) so it never
sees a first hop response from the .1 gateway it sent to but, the first
packet response returns from the .254 gateway to which the packet was
directed.

If the Linux box failed to heed the ICMP redirect for one reason or
another (blocked by firewall rules), the .1 gateway will continue to
low-level forward them to the .254 gateway and send ICMP REDIRECTS back
to the originating host.  If the originator does heed the REDIRECT, it
will send future packets directly to the redirect gateway from then on.

Regards,
Mike

> one gets the impression that it never hit its default gateway at
> 192.168.220.1, but somehow figured out that the .254 router could get it
> there. 
> 
> Is that accurate? Or was there an access to the default gateway that
> isn't shown by the traceroute?    Looking at several other hosts,
> including our own,  it looks like traceroute or mtr to "google.com"
> never shows me hitting our local gateway.    If I had two different
> routes, two local routers, how would I know which one it took? 
> 
> 
> What I'm trying to do is configure the routes such that access through
> this T1 be independent of failure of the primary Sonicwall router.
> But adding a specific route for the xxx.yyy LAN appears to have no
> effect, as least from what I'm seeing. 
> 
> Is there a layer deeper that I should be looking at?  Does the gateway
> just not count as a hop?  The route cache shows no reference to
> xxx.yyy. 
> 
> BTW, this is a Centos 6.x (mumble) server.    (2.6.32-279.1.1.el6.x86_64
> #1 SMP)
> 
> Regards, 
> Neal 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://mail.ale.org/pipermail/ale/attachments/20130117/e2aedca2/attachment.sig>