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