Linux DHCP Server Migration

Question

Background

I'm moving 2 existing Linux DHCP servers to a new network. The servers currently configured as follows:

shared-network network {

        #new network
        subnet 192.168.100.0 netmask 255.255.255.0 {
            option subnet-mask 255.255.255.0;
            option routers 192.168.100.1;
            deny unknown-clients;
            }

        # 1 Subnet
        subnet 192.168.1.0 netmask 255.255.255.0 {
                option subnet-mask 255.255.255.0;
                option routers 192.168.1.1;
                deny unknown-clients;
                }

        # 2/3 Subnet
        subnet 192.168.2.0 netmask 255.255.254.0 {
                option subnet-mask 255.255.254.0;
                option routers 192.168.2.1;
                }

        # 4 Subnet
        subnet 192.168.4.0 netmask 255.255.255.0 {
                option subnet-mask 255.255.255.0;
                option routers 192.168.4.1;
                deny client-updates;
                deny unknown-clients;
                }

        # 5 Subnet
        subnet 192.168.5.0 netmask 255.255.255.0 {
                option subnet-mask 255.255.255.0;
                option routers 192.168.5.1;
                option domain-name "domain.com";
                option domain-name-servers x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x;
                deny client-updates;
                deny unknown-clients;
                }


        # 6 Subnet
        subnet 192.168.6.0 netmask 255.255.255.0 {
                option subnet-mask 255.255.255.0;
                option routers 192.168.5.1;
                pool {
                        deny unknown-clients;
                        deny dynamic bootp clients;
                        failover peer "dhcp";
                        range 192.168.6.100 192.168.6.149;
                        }
                }
}

Issue

I stopped DHCP on the existing DHCP servers and started on the new DHCP servers. All the networks worked with the exception of subnet 4. The MACs (apples) on this network could not obtain an IP.

This is from the logs:

dhcpd: DHCPDISCOVER from d5:9d:11:0h:s3:5u via 192.168.4.1  

- This message is sent by a client that is connected to a local subnet. 

dhcpd: DHCPOFFER on 192.168.5.126 to d5:9d:11:0h:s3:5u via 192.168.4.1 

sent by a server. 

dhcpd: DHCPREQUEST for 192.168.5.126 (192.168.100.10) from d5:9d:11:0h:s3:5u via 192.168.5.1

- This DHCP message is sent in response to DHCPOFFER indicating that the client has accepted the network configuration

dhcpd: DHCPACK on 192.168.5.126 to d5:9d:11:0h:s3:5u via 192.168.5.1

- This message signals the end of the process.  Signals end of conversation.

This process appears to loop with the client never getting an IP address. Looking at the logs 2nd half of the conversation appears to happen via different gateways. Possibly asymmetric routing?

NOTE: BOOTP/ip helper-address is configured at the network level to forward DHCP traffic cross network. These networks are on the same vlan.

interface Vlan342
vrf forwarding central-duss
ip address 192.168.6.1 255.255.255.0 secondary 
ip address 192.168.5.1 255.255.255.0 secondary 
ip address 192.168.4.1 255.255.255.0 secondary 
ip address 192.168.1.1 255.255.254.0 
ip helper-address 192.168.1.9 (current)
ip helper-address 192.168.1.10 (current)
ip helper-address 192.168.100.10  (new)
ip helper-address 192.168.100.11 (new)
no ip redirects 
end

Also noticed that the /var/lib/dhcp/dhcpd.lease is owned by root. However DHCPD runs as dhcp user. Changing ownership to DHCP is overwritten at start up and changed back to root. This file holds lease DB info. — hokeycokey, Sep 06 '13 at 07:00
The problem was due to access rules at the firewall level. It was troublesome getting a full explanation from the network team. Thanks for the replies. — hokeycokey, Oct 17 '13 at 08:06

score 1 · Accepted Answer · edited Oct 17 '13 at 09:56

1

It was due to access rules on the firewall. I couldn't get full details from the network team.

edited Oct 17 '13 at 09:56

MadHatter

79,770
20
184
232

answered Oct 17 '13 at 08:10

hokeycokey

243
1
4
11

GioMac · Answer 2 · 2013-09-06T07:47:43.043

0

It doesn't matter for client from which IP will DHCP server will send data, unless it's unreachable to confirm or renew.

Check outgoing packets with tcpdump/wireshark/tshark and check for destination/source MAC/IP, ensure these packets can reach the client and vice-versa.

edited Sep 06 '13 at 07:47

answered Sep 06 '13 at 06:20

GioMac

4,544
4
27
41

Thanks @GioMac. That's next on the list. To you nothing appears to be incorrect with the config above? – hokeycokey Sep 06 '13 at 06:58
With dhcpd. you offer router from 192.168.5.0 network to hosts frpm 192.168.6.0 network with /24 mask, they will not reach that. – GioMac Sep 06 '13 at 07:42
regarding cisco - i don't know – GioMac Sep 06 '13 at 07:43

score 0 · Answer 3 · answered Sep 06 '13 at 08:07

Your .4 subnet includes the declaration deny unknown-clients;, which according to the man page means:

The unknown-clients flag is used to tell dhcpd whether or not to dynamically assign addresses to unknown clients. Dynamic address assignment to unknown clients is allowed by default. An unknown client is simply a client that has no host declaration.

Since you show us no pool declarations, it seems that no clients will be allocated addresses on the .4 subnet. It's possible that you're not showing us your whole dhcpd config, but in that case, it will be very difficult to advise you anyway.

Linux DHCP Server Migration

3 Answers3