<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
Thanks to all who explained that, especially Mike's detailed explanation. It does explain the behavior. <BR>
<BR>
With a little digging, we find what you perhaps already know, which is that the 'ping' command will indeed demonstrate this behavior. <BR>
<BR>
THIS server has an explicit route to the T1 router at .1...<BR>
[neal@HDIATBE02 net]$ ping xxx.yyy.47.9<BR>
PING xxx.yyy.47.9 (xxx.yyy.47.9) 56(84) bytes of data.<BR>
64 bytes from xxx.yyy.47.9: icmp_seq=0 ttl=251 time=20.7 ms<BR>
64 bytes from xxx.yyy.47.9: icmp_seq=1 ttl=251 time=20.0 ms<BR>
64 bytes from xxx.yyy.47.9: icmp_seq=2 ttl=251 time=20.4 ms<BR>
64 bytes from xxx.yyy.47.9: icmp_seq=3 ttl=251 time=20.1 ms<BR>
<BR>
THIS little piggy does NOT...<BR>
[neal@ev4 ~]$ ping xxx.yyy.47.9<BR>
PING xxx.yyy.47.9 (xxx.yyy.47.9) 56(84) bytes of data.<BR>
>From 192.168.220.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.220.254)<BR>
64 bytes from xxx.yyy.47.9: icmp_seq=1 ttl=251 time=20.0 ms<BR>
>From 192.168.220.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.220.254)<BR>
64 bytes from xxx.yyy.47.9: icmp_seq=2 ttl=251 time=19.8 ms<BR>
<BR>
So, while I haven't figure out if one can ferret out what temporarily stored redirects exist, at least I can verify that it's going on, and I can verify that my routing changes have eliminated it without having to test by rebooting the linux server AND turning off the Sonicwall gateway. (which means that I could no longer get to the Linux server, dang. )<BR>
<BR>
On Thu, 2013-01-17 at 13:31 -0500, Michael H. Warfield wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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
> <A HREF="mailto:Ale@ale.org">Ale@ale.org</A>
> <A HREF="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</A>
> See JOBS, ANNOUNCE and SCHOOLS lists at
> <A HREF="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>