*SOLVED* arpsend: x.x.x.x is detected on another computer
There are a few similar questions in this forum, but none has an usable answer. I'm probably doing something very stupid, but what I've one public IP-adres, so I figured to use a private serie for all my guest nodes. I tried with and without and eth0:1 with IP-adress 192.168.13.1 and there is no difference. strato:~# vzctl set 1313 --ipadd 192.168.13.2 --save strato:~# vzctl start 1313 Starting VPS ... VPS is mounted Adding IP address(es): 192.168.13.2 arpsend: 192.168.13.2 is detected on another computer : 00:00:5e:00:01:02 vps-net_add WARNING: arpsend -c 1 -w 1 -D -e 192.168.13.2 eth0 FAILED Setting CPU units: 1000 VPS start in progress... In another thread someone is suggesting that IP-address is used elsewhere on the network, but that is not the case. If I do an /etc/init.d/vz stop and then a ping there is no reply. If VZ is started all private IP-adresses give an reply, probably this is the function of the vznetdev module? After entering the guestnode 1313 nothing has be done, so the above warning is serious? But I've no idea how to solve it. Any suggestions would be appreciated...
Re: arpsend: x.x.x.x is detected on another computer
you can try to find whom belongs this MAC address 00:00:5e:00:01:02. This MAC reports that it uses IP address 192.168.13.2. Most often error which is done is that VPS IP address is used in host system, because people believe they should assign it to eth0:1 or something. IP address should not be in use when assigned to VPS. Check output of the following command in the host: # ifconfig # ip a l # ip r l
In addition - it is quite frequent that switches are configured in "arp guarding"(?) mode so they report that they own the IP. That's done for security(?) reasons. So it is better that you ask your network administrator (or HSP) on that to be 100% sure. P.S. Sorry for lame description - not the biggest networking guru
aistis wrote on Mon, 10 July 2006 23:45 "arp guarding"(?) mode I don't know if Strato is doing this. However as said, it only happens when OpenVZ is started. If it is indeed an feature of an upstream switch, it should also raise the problem without OpenVZ. Right? strato:~# iptables -t nat -F strato:~# iptables -F strato:~# iptables -vxnL Chain INPUT (policy ACCEPT 33 packets, 2988 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 16 packets, 1600 bytes) pkts bytes target prot opt in out source destination strato:~# /etc/init.d/vz stop Shutting down VPS 1313 Stopping OpenVZ: ..done strato:~# lsmod | grep vz vzdquota 40800 0 [permanent] vzdev 2624 1 vzdquota strato:~# ping -c4 192.168.13.2 PING 192.168.13.2 (192.168.13.2) 56(84) bytes of data. --- 192.168.13.2 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms strato:~# /etc/init.d/vz start Starting OpenVZ: ..done Bringing up interface venet0: ..done Configuring interface venet0: ..done strato:~# lsmod | grep vz vznetdev 17952 1 vzmon 45020 1 vznetdev vzdquota 40800 0 [permanent] vzdev 2624 3 vznetdev,vzmon,vzdquota strato:~# ping -c4 192.168.13.2 PING 192.168.13.2 (192.168.13.2) 56(84) bytes of data. From 85.214.0.133 icmp_seq=2 Destination Net Unreachable --- 192.168.13.2 ping statistics --- 4 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2999ms strato:~# vzctl start 1313 Starting VPS ... VPS is mounted Adding IP address(es): 192.168.13.2 arpsend: 192.168.13.2 is detected on another computer : 00:00:5e:00:01:02 vps-net_add WARNING: arpsend -c 1 -w 1 -D -e 192.168.13.2 eth0 FAILED Setting CPU units: 1000 VPS start in progress... strato:~# ping -c4 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=0.086 ms 64 bytes from 192.168.13.2: icmp_seq=2 ttl=64 time=0.014 ms 64 bytes from 192.168.13.2: icmp_seq=3 ttl=64 time=0.012 ms 64 bytes from 192.168.13.2: icmp_seq=4 ttl=64 time=0.013 ms --- 192.168.13.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.012/0.031/0.086/0.031 ms There is a slight difference with my start of this topic. The ping with only vz started doesn't work anymore. Probably because after much experimenting I now have networking in the VE nodes. But as you can see the aprsend is still failing. At first I thought that that was the cause of my problems. Now I think that this message is complete bogus. It would be nice if it can be resolved however, bacuase now I wasted a day before I decided that it probably doesn mean anything...
dev wrote on Sun, 09 July 2006 13:34 Check output of the following command in the host: # ifconfig # ip a l # ip r l I have experimented with IP-adress 192.168.13.1 on eth0:1 but that didn't resolve my networking problems inside the VE. As said above, this MAC address can only come from OpenVZ itself. But may be you see something different in this output: strato:~# /etc/init.d/vz stop Shutting down VPS 1313 Stopping OpenVZ: ..done strato:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:30:48:58:09:F0 inet addr:85.214.61.55 Bcast:85.214.61.55 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:96934 errors:0 dropped:0 overruns:0 frame:0 TX packets:11622 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30646960 (29.2 MiB) TX bytes:3059910 (2.9 MiB) Interrupt:24 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 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) strato:~# ip a l 2: 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 scope host lo 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:58:09:f0 brd ff:ff:ff:ff:ff:ff inet 85.214.61.55/32 brd 85.214.61.55 scope global eth0 6: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:30:48:58:09:f1 brd ff:ff:ff:ff:ff:ff strato:~# ip r l 85.214.48.1 dev eth0 scope link default via 85.214.48.1 dev eth0 strato:~# /etc/init.d/vz start Starting OpenVZ: ..done Bringing up interface venet0: ..done Configuring interface venet0: ..done strato:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:30:48:58:09:F0 inet addr:85.214.61.55 Bcast:85.214.61.55 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:97042 errors:0 dropped:0 overruns:0 frame:0 TX packets:11676 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30660432 (29.2 MiB) TX bytes:3068042 (2.9 MiB) Interrupt:24 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 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) venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 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) strato:~# ip a l 2: 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 scope host lo 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:58:09:f0 brd ff:ff:ff:ff:ff:ff inet 85.214.61.55/32 brd 85.214.61.55 scope global eth0 6: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:30:48:58:09:f1 brd ff:ff:ff:ff:ff:ff 5: venet0: <BROADCAST,POINTOPOINT,NOARP,UP> mtu 1500 qdisc noqueue link/void strato:~# ip r l 85.214.48.1 dev eth0 scope link default via 85.214.48.1 dev eth0 strato:~# vzctl start 1313 Starting VPS ... VPS is mounted Adding IP address(es): 192.168.13.2 arpsend: 192.168.13.2 is detected on another computer : 00:00:5e:00:01:02 vps-net_add WARNING: arpsend -c 1 -w 1 -D -e 192.168.13.2 eth0 FAILED Setting CPU units: 1000 VPS start in progress... strato:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:30:48:58:09:F0 inet addr:85.214.61.55 Bcast:85.214.61.55 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:97115 errors:0 dropped:0 overruns:0 frame:0 TX packets:11716 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:30671056 (29.2 MiB) TX bytes:3075326 (2.9 MiB) Interrupt:24 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 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) venet0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 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) strato:~# ip a l 2: 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 scope host lo 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:48:58:09:f0 brd ff:ff:ff:ff:ff:ff inet 85.214.61.55/32 brd 85.214.61.55 scope global eth0 6: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:30:48:58:09:f1 brd ff:ff:ff:ff:ff:ff 5: venet0: <BROADCAST,POINTOPOINT,NOARP,UP> mtu 1500 qdisc noqueue link/void strato:~# ip r l 192.168.13.2 dev venet0 scope link src 85.214.61.55 85.214.48.1 dev eth0 scope link default via 85.214.48.1 dev eth0 See also my ping answers in the previous post. An Google on the MAC address gives more hits than you would believe. And almost always in combonation with OpenVZ. So I think it is somewhere in there . As said, the FAILED arpsend is probably bogus. I now have networking, after rebooting the computer. Setting the following in Debian /etc/modules.conf doesn't work: options ip_conntrack ip_conntrack_enable_ve0=1 I now have the following first line in my firewall/iptables script: modprobe ip_conntrack ip_conntrack_enable_ve0=1 That only works if the module wasn't loaded before without this option! rmmod doesn't help, you NEED to reboot.
hvdkamer wrote on Tue, 11 July 2006 12:03 aistis wrote on Mon, 10 July 2006 23:45 "arp guarding"(?) mode I don't know if Strato is doing this. However as said, it only happens when OpenVZ is started. If it is indeed an feature of an upstream switch, it should also raise the problem without OpenVZ. Right? I'm almost 100% sure they are doing it. And like i mentioned in the previous post - it is best to check this with their support. Fast and painless. Regards,
aistis wrote on Tue, 11 July 2006 12:22 I'm almost 100% sure they are doing it. Sometimes I'm so stupid . It didn't occur to me that it is possible for Strato to make a server which does reply to ARP requests, but doesn't reply to ping requests. I've booted to another Debian partition on the same machine which doesn't have any OpenVZ stuff on it. With a tcpdump I see the ARP reply and that the ping requests are going to this MAC address. But no answers of course. I hate it when they make networks this complex Ok, now going through the scripts to see if I can exclude eth0 in the arpsend test that OpenVZ is using. So that I can rely on the arpsend test in the future... Thanks for the help.
Oh, I see. BTW, better be carefull and ask your provider for a range of private IP addresses which you can safely use. Otherwise in case of collision and poor provider network security they can cancel your contract deciding that you did harm intentionally.
hm.. i'm also have this problem with arpsend. Short description: Host server: hp01 ~ # uname -ra Linux hp01 2.6.16-026test015 #1 SMP Thu Jul 20 19:10:00 TJT 2006 i686 Intel(R) Xeon(TM) CPU 3.00GHz GNU/Linux with two fastethernet - eth0 192.168.0.250/24 eth1 195.x.x.8/28 3 testing openvz system (template gentoo) - 192.168.1.[1-4]/24 Quote: hp01 ~ # vzctl --verbose restart 814 Restarting VPS Stopping VPS ... VPS was stopped Running: /usr/lib/vzctl/scripts/vps-net_del Running: /etc/vz/814.umount Running: /usr/sbin/vzquota stat 814 -f Running: /usr/sbin/vzquota off 814 VPS is unmounted Running: /usr/lib/vzctl/scripts/vps-stop Starting VPS ... Running: /usr/sbin/vzquota show 814 Running: /usr/sbin/vzquota on 814 -r 0 -b 1048676 -B 1153534 -i 200100 -I 220100 -e 0 -n 0 -s 0 Mounting root: /vz/root/814 /vz/private/814 Running: /etc/vz/814.mount VPS is mounted Adding IP address(es): 192.168.1.4 Running: /usr/lib/vzctl/scripts/vps-net_add arpsend: 192.168.1.4 is detected on another computer : 00:0e:38:46:a8:c4 vps-net_add WARNING: arpsend -c 1 -w 1 -D -e 192.168.1.4 eth1 FAILED Running VPS script: /etc/vz/dists/scripts/gentoo-add_ip.sh Setting CPU units: 1000 Set hostname: test1 Running VPS script: /etc/vz/dists/scripts/gentoo-set_hostname.sh Running VPS script: /etc/vz/dists/scripts/set_dns.sh File resolv.conf was modified Running: /usr/sbin/vzquota stat 814 -f Running: vzquota setlimit 814 -b 1048576 -B 1153434 -i 200000 -I 220000 -e 0 -n 0 VPS start in progress... i don't have any firewall installed and i can't resolve this. 2 Moderators May be you transfer this post to russian zone of forum, because my english is very ugly
Currently I just ignore this warning . I now know that there is a server on the Strato network who is doing this. But afterwards my VEx's work perfectly, so this check if the IP-address is in use is in my case not returning an useful answer. I could remove the eth0 form the NETDEVICES in the controlscript I suppose. The only problem with this warning is that it got me confused for two days because of another problem. And that one was the cause of my VEx's not owrking. Because the only warning I got was the one about arpsend, it took me quite some time... So the real question to you is this. If you ignore this warning and go into your newly started VEx. Does the network work? If not, do you use the 2.6.8 kernel?