At 17:20 99-3-24 -0600, Phil Z. wrote:
>We ran into the same problem with 2.2.3. moving to 2.2.4 seemed to fix
>the arp problems. The only problem that we still have to overcome is
I patched the kernel to 2.2.4 and rebuild the kernel. The ARP problem
still exists, although the patch-2.2.4.bz2 did some modification of the
/linux/net/ipv4/ipip.c.
If you don't believe, you can test yourself with the instructions posted
in the last message.
>speed. There is about a 2 second delay between the time a request is
>made at the load balancer and when the real server (pop3) gets the
>request.
>I thought it be reverse lookups but all ips have dns entrys both reverse
>and forward. I noticed when I made a call to the server directly it was
>fast. But when I used the load balancer the delay shows up.
>
>Any Ideas?
2 second delay, it doesn't like the DNS resolving problem, but like the ARP
problem.
I list my configuration of two node virtual server with tunneling here,
and hope it can give you some clue.
The load balancer (LinuxDirector), kernel 2.0.36
ifconfig eth0 172.26.20.111 netmask 255.255.255.0 broadcast 172.26.20.0 up
route add -net 172.26.20.0 netmask 255.255.255.0 dev eth0
ifconfig eth0:0 172.26.20.110 netmask 255.255.255.255 broadcast
172.26.20.110 up
route add -host 172.26.20.110 dev eth0:0
ippfvsadm -A -t 172.26.20.110:23 -R 172.26.20.112
The real server, kernel 2.0.36
ifconfig eth0 172.26.20.112 netmask 255.255.255.0 broadcast 172.26.20.0 up
route add -net 172.26.20.0 netmask 255.255.255.0 dev eth0
ifconfig tunl0 172.26.20.110 netmask 255.255.255.255 broadcast
172.26.20.110 up
When I is on other hosts, 'telnet 172.26.20.110' appears as fast as 'telnet
172.26.20.112'. I cannot feel any delay, although there is around 1
mini-second delay.
Good luck,
Wensong
>
>Regards
>
>Phil Z.
>
>
>Wensong Zhang wrote:
>>
>> Hi All,
>>
>> Today I upgraded the kernel to 2.2.3 with tunneling support on one of a
>> real server, and found a problem that the Linux 2.2.3 tunnel device answers
>> ARP requests. Even if I used the NOARP options as follows:
>> ifconfig tunl0 172.26.20.110 -arp netmask 255.255.255.255 broadcast
>> 172.26.20.110
>> It still answers the ARP requests. This will greatly affect the virtual
>> server via tunneling work properly. In fact, the tunnel device shouldn't
>> answer the ARP requests from the ethernet. I think it is a bug of
>> linux/net/ipv4/ipip.c, which is now a clone of ip_gre.c not the original
>> tunneling code.
>>
>> If you are interested, you can test yourself on kernel 2.2.3, choose a free
>> IP address of your ethernet and configure it on the tunl0 device, then
>> telnet to that IP address from other host, I guess you can. Finally, have a
>> look at the ipip.c, maybe you can debug it. :-)
>>
>> Have a good day,
>>
>> Wensong
>>
>
>
|