Subject: Re: [vserver] odd network problem
From: Chuck <chuck@sbbsnet.net>
Date: Sun, 16 Nov 2008 19:39:58 -0500


ok i have done some testing and discovered certain 'rules' to make this 
rtnetlink error appear.

regardless of the version of the guest o/s or if a gentoo guest is baselayout1 
or 2, or if it is one of the older centos 4.4 guests, the error occurs if the 
guest has more than 2 ip addresses. in each case with only 2 however they 
were different networks assigned to different nics. when there are more than 
2 ips assigned eth0 got the brunt of them. there were no more than 6 ip 
addresses assigned  to eth0 in any given guest. eth1 never has more than 1 ip 
assignment.


this does not occur with the older production 2.2.0.6 kernel. it happens with 
either of the 2.3.0.34 or 35 kernels

in each case util-verver is 0.30.215.

i did not try to narrow it down further by discovering if the multiple 
addresses had to be in the same network or not to get the error.

On Thursday 13 November 2008, Chuck wrote:
> On Thursday 13 November 2008, Herbert Poetzl wrote:
> > On Thu, Nov 13, 2008 at 10:03:42AM -0500, Chuck wrote:
> > > i stopped and restarted our openfire server and all was well with that
> > > action. however, 2 web servers, one running an older centos and the
> > > other running gentoo64 with openrc/baselayout2 both lost any network
> > > communication. ips showed present on the host but were unusable even
> > 		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ that is unusual
> > 
> > > from the host. the ip blocks of the various guests and the host use 3
> > > networks on the same nic.
> > 
> > > i restarted each of those affected servers. when they stopped each    
> > > gave this error:                                                      
> > 
> > > RTNETLINK answers: Cannot assign requested address
> > > RTNETLINK answers: Cannot assign requested address
> > > 
> > > it appears it gave one line for every ip assigned to the guest.
> > 
> > that happens if the IP is already there (maybe with
> > the wrong netmask or so)
> > 
> 
> i double checked all the ips and netmasks to be sure. they are right... 
there 
> is one thing tho... if i have no guests running the host only has its one ip 
> which is a subnet of its network. all but one of the guests belong to 
> different networks. i am wondering if i should 'prime' the host by assigning 
> an ip in each network to it to start with? by having only the one network ip 
> running with all guests down, i do not have table entries for routing or 
> rules for the other networks.. maybe this is the problem and by assigning 
> a 'dummy' ip in the top end of each network to this host it will have routes 
> and rules/tables to work with?
> 
> 
> > > restarting those 2 vservers cured the problem. these are the only two
> > > affected out of the others living on that host.
> > 
> > this will have removed and re-added the IPs properly
> > 
> > > i dont think this has anything to do with it but the centos guest was
> > > moved to this server by simply tarring its /vservers and /etc/vservers
> > > entries. the openfire and gentoo guests were created and configured on
> > > this host. no ip addresses clash.
> > 
> > > the host is running gentoo64 baselayout1 with
> > 
> > > kernel 2.6.22-vs2.3.0.34-gentoo
> > > util-vserver 0.30.215
> > > iproute2 version 2.6.22.20070710
> > 
> > > i am planning on updating the kernel to 2.6.26-vs2.3.0.35.6-gentoo and 
> > > baselayout2/openrc but it is on my 'when i get to it' priority list.
> > 
> > > anyone seen this behavior of stopping a guest and it affecting
> > > networking on other guests before? this is new behavior to me.
> > 
> > well, it is kind of expected, if you are using several
> > IPs in the same network (i.e. with a netmask) and without
> > secondary propagation, that when you remove the primary,
> > all secondaries are gone too (that is a mainline 'feature')
> > 
> > but I'm not sure that matches what you are seeing, because
> > as I said, the secondaries are gone, so they are not supposed
> > to show up on the host or anywhere (in this case)
> > 
> > best,
> > Herbert
> > 
> > > -- 
> > > 
> > > Chuck
> > 
> 
> 
> 
> -- 
> 
> Chuck
> 



-- 

Chuck