|
Hello, all!
I hate replying to my own mail, especially since there is nothing new in
it. But after my last posting there wasn't any additional response, and we
are slowly getting desperate. So please, if anyone has *any* idea at all,
please speak up. (btw, I had another report by private mail from a guy who
has the exact same problem. At least now I know that I am not dreaming and
it is not a quirk of our particular setup)
On Fri, 18 Jul 2003, Stephan Wonczak wrote:
> > > [root@lvr8 conf]# arp -an
> > > ? (134.95.19.54) at 00:02:B3:BE:8A:A6 [ether] PERM on eth2
> <snip>
> > > ? (134.95.19.43) at 00:03:47:9A:53:C6 [ether] on eth2
> >
> > lrv 134.95.19.15 has static ARP entry, so the kernel replies:
> >
> > > ? (134.95.19.15) at 00:02:B3:BE:8A:A6 [ether] PERM on eth2
> >
> > There is no IP but the ARP entry is enough to
> > generate reply.
>
> <snip>
>
> Thanks for this suggestion, but we already noticed this, too. In other
> cases this entry does not seem to be a problem. Anyway, removing it does
> not turn off the false replies. I did
>
> 'arp -i eth2 -d lrv'
> 'arp -i eth2 -d msa'
>
> to remove both entries from the ARP cache. First they showed up as
> <incomplete>, after a minute or so they vanished completely. 'arp -an' and
> 'ip neigh' now reads as follows:
>
> [root@lvr8 arplog]# arp -an
> ? (134.95.19.28) at 00:03:BA:00:DA:E6 [ether] on eth2
> ? (134.95.19.58) at 00:02:B3:BE:8A:A6 [ether] PERM on eth2
> ? (134.95.19.30) at 08:00:20:A1:4C:FE [ether] on eth2
> ? (134.95.19.24) at 00:00:BE:A6:50:21 [ether] on eth2
> ? (134.95.19.25) at 08:00:20:72:92:B7 [ether] on eth2
> ? (134.95.19.27) at 08:00:20:9A:9E:C4 [ether] on eth2
> ? (134.95.19.7) at 00:03:BA:07:40:73 [ether] on eth2
> ? (134.95.19.104) at 00:03:47:73:0E:94 [ether] on eth2
> ? (192.168.20.3) at 00:B0:D0:D1:AB:E6 [ether] on eth0
> ? (134.95.19.105) at 00:02:B3:BE:8A:9E [ether] on eth2
> ? (192.168.20.5) at 00:06:5B:F0:5E:66 [ether] on eth0
> ? (134.95.19.3) at 08:00:20:72:92:C0 [ether] on eth2
> ? (192.168.20.7) at 00:06:5B:F0:F4:C4 [ether] on eth0
> ? (134.95.19.1) at 00:0B:60:AC:39:8A [ether] on eth2
> ? (192.168.20.6) at 00:06:5B:F0:5E:3E [ether] on eth0
> ? (134.95.19.14) at 00:03:BA:0C:9A:27 [ether] on eth2
> ? (134.95.19.43) at 00:03:47:9A:53:C6 [ether] on eth2
> ? (134.95.19.12) at 00:03:BA:0C:8E:79 [ether] on eth2
> ? (134.95.19.13) at 00:03:BA:07:40:74 [ether] on eth2
> ? (134.95.19.103) at 00:03:47:73:0E:92 [ether] on eth2
> ? (134.95.19.47) at 00:03:47:9A:53:7D [ether] on eth2
> ? (134.95.19.11) at 08:00:20:82:BA:70 [ether] on eth2
> ? (134.95.19.44) at 00:03:47:9A:53:34 [ether] on eth2
>
> [root@lvr8 arplog]# ip neigh
> 134.95.19.28 dev eth2 lladdr 00:03:ba:00:da:e6 nud stale
> 134.95.19.58 dev eth2 lladdr 00:02:b3:be:8a:a6 nud permanent
> 134.95.19.30 dev eth2 lladdr 08:00:20:a1:4c:fe nud reachable
> 134.95.19.24 dev eth2 lladdr 00:00:be:a6:50:21 nud stale
> 134.95.19.25 dev eth2 lladdr 08:00:20:72:92:b7 nud reachable
> 134.95.19.27 dev eth2 lladdr 08:00:20:9a:9e:c4 nud reachable
> 134.95.19.7 dev eth2 lladdr 00:03:ba:07:40:73 nud reachable
> 134.95.19.104 dev eth2 lladdr 00:03:47:73:0e:94 nud delay
> 192.168.20.3 dev eth0 lladdr 00:b0:d0:d1:ab:e6 nud stale
> 134.95.19.105 dev eth2 lladdr 00:02:b3:be:8a:9e nud reachable
> 192.168.20.5 dev eth0 lladdr 00:06:5b:f0:5e:66 nud stale
> 134.95.19.3 dev eth2 lladdr 08:00:20:72:92:c0 nud reachable
> 192.168.20.7 dev eth0 lladdr 00:06:5b:f0:f4:c4 nud reachable
> 134.95.19.1 dev eth2 lladdr 00:0b:60:ac:39:8a nud reachable
> 192.168.20.6 dev eth0 lladdr 00:06:5b:f0:5e:3e nud reachable
> 134.95.19.14 dev eth2 lladdr 00:03:ba:0c:9a:27 nud stale
> 134.95.19.43 dev eth2 lladdr 00:03:47:9a:53:c6 nud reachable
> 134.95.19.12 dev eth2 lladdr 00:03:ba:0c:8e:79 nud reachable
> 134.95.19.13 dev eth2 lladdr 00:03:ba:07:40:74 nud reachable
> 134.95.19.103 dev eth2 lladdr 00:03:47:73:0e:92 nud stale
> 134.95.19.47 dev eth2 lladdr 00:03:47:9a:53:7d nud stale
> 134.95.19.11 dev eth2 lladdr 08:00:20:82:ba:70 nud reachable
> 134.95.19.44 dev eth2 lladdr 00:03:47:9a:53:34 nud reachable
>
>
> Testing again with 'tcpdump -e -i eth2 -l arp' i still get
>
> 13:48:44.546270 0:0:be:a6:50:21 Broadcast arp 60: arp who-has
> lrv.rrz.uni-koeln.de (Broadcast) tell starfire.rrz.Uni-Koeln.DE
> 13:48:44.546309 0:2:b3:be:8a:a6 0:0:be:a6:50:21 arp 42: arp reply
> lrv.rrz.uni-koeln.de is-at 0:2:b3:be:8a:a6
>
> as a response to a 'ping lrv' from another machine. We were at this
> point when we ran out of ideas what to do next and ask on this list. (btw,
> for the moment we get around the problem of the wrong ARP answers by
> putting static entries in the caches of the relevant client machines, but
> this kind of defeats the purpose of a freely relocatable service :-) )
> Now, where else could the machine hide the information to answer the ARP
> request?
Dipl. Chem. Dr. Stephan Wonczak
Institut fuer Angewandte Informatik (ZAIK)
Regionales Rechenzentrum der Universitaet zu Koeln (RRZK)
Universitaet zu Koeln, Robert-Koch-Strasse 10, 50931 Koeln
Tel: ++49/(0)221/478-5577, Fax: ++49/(0)221/478-5590
|
