Hello, I have some domU accounts running CentOS 4.4 and whenever I try to bring up the network interface it fails with the following errors: [root@test5.liquidweb.com] ~ # ifup eth0 Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help'' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help'' for more information. Usage: arping [-fqbDUAV] [-c count] [-w timeout] [-I device] [-s source] destination -f : quit on first reply -q : be quiet -b : keep broadcasting, don''t go unicast -D : duplicate address detection mode -U : Unsolicited ARP mode, update your neighbours -A : ARP answer mode, update your neighbours -V : print version and exit -c count : how many packets to send -w timeout : how long to wait for a reply -I device : which ethernet device to use (eth0) -s source : source ip address destination : ask for what ip address Error, some other host already uses address xx.xx.xx.xx However there is NOT another host using that IP. If I bring the interface up manually using ifconfig everything works fine. I even added my own init script to bring up the eth0 interface at boot and it works fine. Anybody else have problems using ifup? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Eric Benton wrote:> There are a lot of problems related to the vif, > Try to send teh xen log files at /var/log/xen* > and see the xm dmesg output... > > ifup is just a script, try to add "prints" and see where it fails...From what I can tell it''s just an issue with the script, networking is fine once I bring it up and the other distros I''m running don''t have this issue. In the script it looks like the REALDEVICE variable is never getting set, I added an echo statement and it just comes out blank. If I add REALDEVICE=eth0 to the script it errors out looking for ifcfg-ifcfg-eth0. if ! arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR} ; then echo $"Error, some other host already uses address ${IPADDR}." echo "Real device is: $REALDEVICE" exit 1 fi I guess this isn''t an issue with Xen so I''ll have to submit a bug report to CentOS. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> if ! arping -q -c 2 -w 3 -D -I ${REALDEVICE} ${IPADDR} ; then > echo $"Error, some other host already uses address ${IPADDR}." > echo "Real device is: $REALDEVICE" > exit 1 > fi > > I guess this isn''t an issue with Xen so I''ll have to submit a bug report > to CentOS. >Does this per chance clear up if you alter (or manually specify) the mac of the device? Was the IP in use by another machine or bridge with a different mac within 15 or so minutes of you trying to bring up the device? This *could* be due to a router taking up to ~10 minutes to arp new changes when IP''s re-appear only with different macs. I''ve run into this a few times with older 3400 series with a more or less out of the box vanilla configuration. arping is just saying "Yes, this IP is already related to another mac (and host)", but it doesn''t take a 10 - 15 minute lag from the router into consideration. If the IP you are using was broadcast by another ethernet device with a different mac in the last 15 minutes .. it [arping] would still think the IP was in use because so does the router (again depending on your router). Cisco (and others) say the maximum time it should take for the router to pick up that kind of change and arp it is about 9 minutes. I''ve found its sometimes double that, depending on the setup. Very frustrating, you could be working with a good config and are being shot in the foot upstream.. Worth checking into anyway :) HTH -Tim> _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Does this per chance clear up if you alter (or manually specify) the mac > of the device? Was the IP in use by another machine or bridge with a > different mac within 15 or so minutes of you trying to bring up the > device? >Yes, I experienced this before as well. It works after the router picks up on the change. It could be fixed by using static MAC addresses I think, but I guess it''s too late for that in your case. Paul _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Paul Reilly wrote:>> Does this per chance clear up if you alter (or manually specify) the mac >> of the device? Was the IP in use by another machine or bridge with a >> different mac within 15 or so minutes of you trying to bring up the >> device? >> >>I tried clearing the ARP cache on our switches but that didn''t help either. I''ll try using a static MAC to see if that works. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, 2006-11-26 at 10:14 -0500, Michael Watters wrote:> Paul Reilly wrote: > >> Does this per chance clear up if you alter (or manually specify) the mac > >> of the device? Was the IP in use by another machine or bridge with a > >> different mac within 15 or so minutes of you trying to bring up the > >> device? > >> > >> > I tried clearing the ARP cache on our switches but that didn''t help > either. I''ll try using a static MAC to see if that works. >Try a different IP if possible too, since the one you''re fighting is arp''ed to another mac. Or, Find out what mac the ip you want is arp''ed to and clone it. Since the device is no longer broadcasting the IP it shouldn''t create much turmoil unless you have an ad-hoc BGP4 config in place. Unless you go through the trouble of setting up lots of smaller vlans ... its just going to be a recurring typical issue. Under more severe circumstances even Cisco has been known to bleed the mac layer in between vlans (typical only on major VOIP setups) .. but you can see why keeping them static [and unique] will save you some hair loss :) Best, -Tim> > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Tim Post wrote:> Try a different IP if possible too, since the one you''re fighting is > arp''ed to another mac. > > Or, Find out what mac the ip you want is arp''ed to and clone it. Since > the device is no longer broadcasting the IP it shouldn''t create much > turmoil unless you have an ad-hoc BGP4 config in place. > > Unless you go through the trouble of setting up lots of smaller > vlans ... its just going to be a recurring typical issue. Under more > severe circumstances even Cisco has been known to bleed the mac layer in > between vlans (typical only on major VOIP setups) .. but you can see why > keeping them static [and unique] will save you some hair loss :) > > Best, > -Tim >I''ve tried using a different IP and get the same results. Our network is already divided into VLANs as well. At this point I''m thinking about writing my own version of the network init script and using that for my templates. I don''t need half the stuff that Redhat puts in there any way. If I can find a copy of Redhat EL5 beta I''ll see if that does the same thing when I run it as a guest. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users