|
Hi Julian!
On Fri, 18 Jul 2003, Julian Anastasov wrote:
> 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
|
