|
Hi Julian!
On Thu, 17 Jul 2003, Julian Anastasov wrote:
> On Thu, 17 Jul 2003, Stephan Wonczak wrote:
>
> > I have just reproduced the problem again (we got around it last time by
> > rebooting lvr8). Here is a snippet of 'tcpdump -e -i eth2 -l arp' from a
> > time after the director is back on lvr7:
> >
> > 16:10:15.916326 0:0:be:a6:50:21 Broadcast arp 60: arp who-has
> > lrv.rrz.uni-koeln.de (Broadcast) tell starfire.rrz.Uni-Koeln.DE
>
> Are you sure that at this point 134.95.19.15 (lrv)
> is not configured on some interface in lvr8?
Yup, I am :-) I was just trying to save a little space for explanations.
Wrong idea, obviously!
> May be not on
> eth2, may be on another interface? Please, do 'ip a' and save
> the output at that point, showing only eth2 is absolutely not enough.
Yes, you are right, showing the total is better. Here is the complete
output from both machines:
[root@lvr7 root]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:06:5b:f0:f4:c4 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.7/24 brd 192.168.20.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 100
link/ether 00:06:5b:f0:f4:c5 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:02:b3:be:8a:9e brd ff:ff:ff:ff:ff:ff
inet 134.95.19.105/24 brd 134.95.19.255 scope global eth2
inet 192.168.19.7/24 brd 192.168.19.255 scope global eth2:3
inet 134.95.19.15/24 brd 134.95.19.255 scope global secondary eth2:0
inet 192.168.19.254/24 brd 192.168.19.255 scope global secondary
eth2:3:0
inet 134.95.19.54/24 brd 134.95.19.255 scope global secondary eth2:1
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 100
link/ether 00:02:b3:be:8a:9f brd ff:ff:ff:ff:ff:ff
[root@lvr8 root]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:06:5b:f0:f4:c9 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.8/24 brd 192.168.20.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 100
link/ether 00:06:5b:f0:f4:ca brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:02:b3:be:8a:a6 brd ff:ff:ff:ff:ff:ff
inet 134.95.19.106/24 brd 134.95.19.255 scope global eth2
inet 192.168.19.8/24 brd 134.95.19.255 scope global eth2:3
inet 134.95.19.111/24 brd 134.95.19.255 scope global secondary eth2:4
inet 134.95.19.58/24 brd 134.95.19.255 scope global secondary eth2:0
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 100
link/ether 00:02:b3:be:8a:a7 brd ff:ff:ff:ff:ff:ff
eth0 on both machines is used for an internal management network that
has no physical connections to the public network. eth1 and eth3 are
unused yet. The reason for this slightly stange setup is symmetry with
some other machines that only have two physical interfaces.
> Do you know that Linux can reply to requests coming from eth2
> even if the local IP is configured on dummy0, for example?
*nod* Yes, I was aware of that. But this does not seem to be the problem
in this case. What do we look at next?
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
|
