Concurrent 'secondary eth0' lease on one network adapter

[Kyle Johnson]

Hello everybody,

I am running into an issue for the second time where a new virtual machine
is receiving concurrent leases for a single network adapter.  This machine
has two interfaces - eth0 and eth1 - and receives two leases on eth0, and
one lease on eth1.

If I restart the secondary DHCP server, and then restart networking on my
client, the client no longer receives the secondary eth0 lease.  This is
how I resolved the original client's issue with the same problem, but has
just happened again to another new client yesterday.

My architecture looks like this:  Two CentOS 6.3 4.1.1-P1 DHCP servers,
each on their on subnet.  My cisco gateways are configured with ip
helper-addresses to send DHCP traffic to both servers, and each DHCP server
is configured as a failover peer.

interface Vlan123
 ip address 172.21.52.129 255.255.255.192
 ip helper-address 172.21.35.18
 ip helper-address 172.21.35.26
!

35.18 is the primary, 35.26 is the secondary.

When bringing up dhclient on my client, eth0 gets two IP addresses:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
    link/ether 00:50:56:a8:50:e3 brd ff:ff:ff:ff:ff:ff
    inet 172.21.52.167/26 brd 172.21.52.191 scope global eth0
    inet 172.21.52.145/26 brd 172.21.52.191 scope global secondary eth0
    inet6 fe80::250:56ff:fea8:50e3/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
    link/ether 00:50:56:a8:6e:db brd ff:ff:ff:ff:ff:ff
    inet 172.21.52.69/26 brd 172.21.52.127 scope global eth1
    inet6 fe80::250:56ff:fea8:6edb/64 scope link
       valid_lft forever preferred_lft forever

If I restart the DHCP service on the secondary server, and then restart
networking on the DHCP client, the secondary eth0 lease is no longer handed
out.

Has anyone run into this kind of issue before?  I haven't been able to find
any reports of this same issue.

If you need any other information to troubleshoot this, please let me know!

Thanks,
Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130426/72f9a0fa/attachment.html>