DHCP server not handing out IP addresses

Ryan McCain Ryan.McCain at dss.state.la.us
Mon Aug 4 20:13:23 UTC 2008


More info...

It appears the VM isn't accepting broadcasts...

This is the working server:
ns1:/media/nfs/scripts # tcpdump -nepi eth0 broadcast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:22:49.351972 00:11:43:34:77:1d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 10.120.9.168.137 > 10.120.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:22:49.699931 00:0b:db:93:b6:80 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 10.120.9.120.137 > 10.120.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:22:49.701163 00:02:55:9a:b6:f8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.9.120 tell 10.120.11.107
13:22:49.735706 00:0b:db:93:b5:5d > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.10.48 tell 10.120.9.38
13:22:49.751367 00:0b:db:93:b5:7c > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.9.16 tell 10.120.9.144
13:22:49.907586 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.9.38 tell 10.120.11.2
13:22:49.919579 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.9.194 tell 10.120.11.2
13:22:49.929567 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.10.58 tell 10.120.11.2
13:22:49.977555 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.10.62 tell 10.120.11.2
13:22:50.035540 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.10.64 tell 10.120.11.2
13:22:50.091521 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.9.176 tell 10.120.11.2
13:22:50.101893 00:11:43:34:77:1d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 10.120.9.168.137 > 10.120.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:22:50.107561 00:06:5b:3b:1c:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 92: 10.120.9.108.137 > 10.120.11.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
13:22:50.108596 00:02:55:9a:b6:f8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.9.108 tell 10.120.11.107
13:22:50.142506 00:06:5b:f6:d8:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 10.120.10.74 tell 10.120.11.2
--SNIP--


This is the Linux VM:

ns2:/var/log # tcpdump -nepi eth0 broadcast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes


0 packets captured
0 packets received by filter
0 packets dropped by kernel

---

So.. where in the land of the mainframes is this being blocked? :)

>>> On Mon, Aug 4, 2008 at 12:23 PM, in message
<4896F4A5.A79C.003A.0 at dss.state.la.us>, "Ryan McCain"
<Ryan.McCain at dss.state.la.us> wrote: 
> One more bit of information that might help..
> 
> 3N2DHB1:~ # nmap -sU -p67 ns1    <---- x86 Server
> 
> Starting Nmap 4.20 ( http://insecure.org ) at 2008-08-04 12:17 CDT
> Interesting ports on ns1.dss.la.gov (10.120.11.85):
> PORT   STATE         SERVICE
> 67/udp open|filtered dhcps
> 
> 
> 3N2DHB1:~ # nmap -sU -p67 ns2   <---- s390x Server
> 
> Starting Nmap 4.20 ( http://insecure.org ) at 2008-08-04 12:17 CDT
> Interesting ports on ns2.dss.la.gov (10.120.11.107):
> PORT   STATE         SERVICE
> 67/udp open|filtered dhcps
> 
> 
> ..As you can see, the port looks to be ready to handle DHCP traffic on ns2.
> 
> Just to verify, there is no software firewall running on ns2:
> 
> ns2:~ # rcSuSEfirewall2 status
> Checking the status of SuSEfirewall2                                  unused
> ns2:~ #               
> 
> 
> ...??
> 
>>>> On Mon, Aug 4, 2008 at 11:01 AM, in message
> <4896E190.A79C.003A.0 at dss.state.la.us>, "Ryan McCain"
> <Ryan.McCain at dss.state.la.us> wrote: 
>> To add to the oddness of this.  I originally had failover configured and 
> when 
>> the primary would go down, the secondary would pick up.  So, DHCPD seems to 
>> be functioning, its just no requests are getting to it.   The logs don't 
> show 
>> any errors either.
>> 
>> 
> 
> --------------------------------------
> 
> Ryan McCain
> Northrop Grumman Corporation
> Linux System Administrator 3 (CLP / LPIC-2)
> email: ryan.mccain at dss.la.gov
> Phone: 225.219.0556
> 
> Registered Linux User #364609
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>>>> On Mon, Aug 4, 2008 at 10:35 AM, in message
>> <4896DB64.A79C.003A.0 at dss.state.la.us>, "Ryan McCain"
>> <Ryan.McCain at dss.state.la.us> wrote: 
>>> I recently attempted to migrate DHCPD from SLES10 x86 to SLES10 s390x.  I 
>>> have  a primary and secondary server.
>>> 
>>> Everything worked fine when DHCPD was running was on the x86 servers.  I've 
>>> used tcpdump to verify that no DHCP requests are even hitting the SLES10 
>>> s390x servers.  I've turned off all software firewalls.  All DHCP helpers on 
> 
>> 
>>> the routers have been updated.  Also, when I take the config file from a 
>>> SLES10 s390x server and move it to a SLES10 x86 server, it works fine on the 
> 
>> 
>>> SLES10 x86 server.
>>> 
>>> The version of DHCP on both platforms is dhcp-3.0.3-23.33.
>>> 
>>> Any ideas?  Is there something in the mainframe world that needs to be 
>>> configured to allow in UDP traffic on port 67?
>>> 
>>> Thanks, 
>>> Ryan



More information about the dhcp-users mailing list