kernel 2.6 routing anomaly

I'm porting our old satellite-networking package from kernel 2.2 to kernel
2.6. Most everything is coming along okay. Today, for the first time, I
have two gateways connected via the "satellite" link (using a satellite-
delay simulator), and I can ping across the link. If I ping the remote
gateway at its satellite interface, I see a normal ping response:

hub26:/usr/src/sat # ping 192.168.13.2
PING 192.168.13.2 (192.168.13.2) 56(84) bytes of data.
64 bytes from 192.168.13.2: icmp_seq=1 ttl=64 time=541 ms
64 bytes from 192.168.13.2: icmp_seq=2 ttl=64 time=541 ms
64 bytes from 192.168.13.2: icmp_seq=3 ttl=64 time=541 ms

However, if I ping the ethernet interface of the remote gateway, I see
something odd:

hub26:/usr/src/sat # ping 192.168.14.1
PING 192.168.14.1 (192.168.14.1) 56(84) bytes of data.
From 192.168.13.2: icmp_seq=1 Redirect Host(New nexthop: 192.168.13.1)
From 192.168.13.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.13.1)
From 192.168.13.2: icmp_seq=3 Redirect Host(New nexthop: 192.168.13.1)
From 192.168.13.2: icmp_seq=4 Redirect Host(New nexthop: 192.168.13.1)

--- 192.168.14.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms

However, I *have* a route to the 14.0 network, via the 13.2 address which
is the remote satellite gateway. I don't understand what this "redirect
host: new nexthop: 192.13.1" entry is telling me; the 13.1 address is my
own eth1 interface; that shouldn't require redirecting anything??

Can anyone tell me what I'm doing wrong here?? I'm enclosing my routing
table and interface info at the end of this message for reference.

Dan Miller

# routing data
hub26:/usr/src/sat # netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.18.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.14.0 192.168.13.2 255.255.255.0 UG 0 0 0 eth1
192.168.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 172.18.100.1 0.0.0.0 UG 0 0 0 eth0

hub26:/usr/src/sat # ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:90:05:A6:0B:C9
inet addr:172.18.100.34 Bcast:172.18.100.255 Mask:255.255.255.0
inet6 addr: fe80::290:5ff:fea6:bc9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8055 errors:0 dropped:0 overruns:0 frame:0
TX packets:2035 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:858316 (838.1 Kb) TX bytes:164214 (160.3 Kb)

eth1 Link encap:Ethernet HWaddr 00:00:C0:A8:0D:01
inet addr:192.168.13.1 Bcast:192.168.13.255 Mask:255.255.255.0
inet6 addr: fe80::200:c0ff:fea8:d01/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:180 errors:0 dropped:0 overruns:0 frame:0
TX packets:96 errors:0 dropped:16 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16260 (15.8 Kb) TX bytes:8406 (8.2 Kb)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1108 (1.0 Kb) TX bytes:1108 (1.0 Kb)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

Dan Miller wrote:
> I'm porting our old satellite-networking package from kernel 2.2 to kernel
> 2.6. Most everything is coming along okay. Today, for the first time, I
> have two gateways connected via the "satellite" link (using a satellite-
> delay simulator), and I can ping across the link. If I ping the remote
> gateway at its satellite interface, I see a normal ping response:
>
> hub26:/usr/src/sat # ping 192.168.13.2
> PING 192.168.13.2 (192.168.13.2) 56(84) bytes of data.
> 64 bytes from 192.168.13.2: icmp_seq=1 ttl=64 time=541 ms
> 64 bytes from 192.168.13.2: icmp_seq=2 ttl=64 time=541 ms
> 64 bytes from 192.168.13.2: icmp_seq=3 ttl=64 time=541 ms
>
> However, if I ping the ethernet interface of the remote gateway, I see
> something odd:
>
> hub26:/usr/src/sat # ping 192.168.14.1
> PING 192.168.14.1 (192.168.14.1) 56(84) bytes of data.
> From 192.168.13.2: icmp_seq=1 Redirect Host(New nexthop: 192.168.13.1)
> From 192.168.13.2: icmp_seq=2 Redirect Host(New nexthop: 192.168.13.1)
> From 192.168.13.2: icmp_seq=3 Redirect Host(New nexthop: 192.168.13.1)
> From 192.168.13.2: icmp_seq=4 Redirect Host(New nexthop: 192.168.13.1)


> However, I *have* a route to the 14.0 network, via the 13.2 address which
> is the remote satellite gateway. I don't understand what this "redirect
> host: new nexthop: 192.13.1" entry is telling me; the 13.1 address is my
> own eth1 interface; that shouldn't require redirecting anything??
>
> Can anyone tell me what I'm doing wrong here?? I'm enclosing my routing
> table and interface info at the end of this message for reference.

The remote gateway (192.168.13.2) has a route to the target
(192.168.14.x) via your own host (192.168.13.1), and it's
trying to tell you that according to his route table, you're
the proper way to the target. It seems that you've set up a
bounce automaton.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio <(E-Mail Removed)> wrote in
news:MoQ3g.466$(E-Mail Removed):

> Dan Miller wrote:
>> I'm porting our old satellite-networking package from kernel 2.2 to
>> kernel 2.6. Most everything is coming along okay. Today, for the
>> first time, I have two gateways connected via the "satellite" link
>> (using a satellite- delay simulator), and I can ping across the link.
>> If I ping the remote gateway at its satellite interface, I see a
>> normal ping response:
>>
>> However, I *have* a route to the 14.0 network, via the 13.2 address
>> which is the remote satellite gateway. I don't understand what this
>> "redirect host: new nexthop: 192.13.1" entry is telling me; the 13.1
>> address is my own eth1 interface; that shouldn't require redirecting
>> anything??
>>
>> Can anyone tell me what I'm doing wrong here?? I'm enclosing my
>> routing table and interface info at the end of this message for
>> reference.
>
> The remote gateway (192.168.13.2) has a route to the target
> (192.168.14.x) via your own host (192.168.13.1), and it's
> trying to tell you that according to his route table, you're
> the proper way to the target. It seems that you've set up a
> bounce automaton.
>
OOPS!!! You're right!! I thought I specified that interface, but I
didn't... It didn't occur to me that the ICMP message might be coming
from somewhere else. Thanks!! That worked great, once I set up the
remote correctly...

Dan


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---

>> However, if I ping the ethernet interface of the remote gateway, I see
>> something odd:
>>
>> hub26:/usr/src/sat # ping 192.168.14.1
>> PING 192.168.14.1 (192.168.14.1) 56(84) bytes of data.
>> From 192.168.13.2: icmp_seq=1 Redirect Host(New nexthop: 192.168.13.1)

> The remote gateway (192.168.13.2) has a route to the target
> (192.168.14.x) via your own host (192.168.13.1), and it's
> trying to tell you that according to his route table, you're
> the proper way to the target. It seems that you've set up a
> bounce automaton.

I agree it's probably a routing SNAFU. Look at the traffic (for ICMP
redirects).