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

Thu Jan 17 15:43:42 EST 2013

Thanks to all who explained that, especially Mike's detailed
explanation.   It does explain the behavior. 

With a little digging, we find what you perhaps already know, which is
that the 'ping' command will indeed demonstrate this behavior. 

THIS server has an explicit route to the T1 router at .1...
[neal at HDIATBE02 net]$ ping  xxx.yyy.47.9
PING xxx.yyy.47.9 (xxx.yyy.47.9) 56(84) bytes of data.
64 bytes from xxx.yyy.47.9: icmp_seq=0 ttl=251 time=20.7 ms
64 bytes from xxx.yyy.47.9: icmp_seq=1 ttl=251 time=20.0 ms
64 bytes from xxx.yyy.47.9: icmp_seq=2 ttl=251 time=20.4 ms
64 bytes from xxx.yyy.47.9: icmp_seq=3 ttl=251 time=20.1 ms

THIS little piggy does NOT...
[neal at ev4 ~]$ ping  xxx.yyy.47.9
PING xxx.yyy.47.9 (xxx.yyy.47.9) 56(84) bytes of data.
>From 192.168.220.1: icmp_seq=1 Redirect Host(New nexthop:
192.168.220.254)
64 bytes from xxx.yyy.47.9: icmp_seq=1 ttl=251 time=20.0 ms
>From 192.168.220.1: icmp_seq=2 Redirect Host(New nexthop:
192.168.220.254)
64 bytes from xxx.yyy.47.9: icmp_seq=2 ttl=251 time=19.8 ms

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. )

On Thu, 2013-01-17 at 13:31 -0500, Michael H. Warfield wrote:

> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130117/673e1ce9/attachment.html>