DHCP server not responding to clients on other subnets

Hello everybody,

I have installed a Windows 2003 SP1 DHCP server that has to distribute
addresses to workstations located on four subnets. It works fine with the
workstations that are sitting on the same subnet, but not with the other
ones.
I had created superscopes, but then I deleted them following some advice I
found in this newsgroup.

The server has address 157.150.91.56 (subnet 255.255.255.0)
and in this subnet it distributes without problems the addresses in the
range 10.18.158/23, but for the other subnets, namely

10.18.154/23
10.18.146/23
10.18.168/23

it does not work.
We have an old Linux DHCP server which works fine in the four subnets. I
defined the ranges in order not to have overlaps and tried to shut it down,
but nothing happens.
I installed Ethereal on the new server and verified that the routers are
actually passing the DHCP requests to the new server.

Thank you in advance for your help

Cheers

"Massimo" <(E-Mail Removed)> wrote in message
news:5FCFF757-BB6F-4A42-8DB9-(E-Mail Removed)...
> Hello everybody,
>
> I have installed a Windows 2003 SP1 DHCP server that has to distribute
> addresses to workstations located on four subnets. It works fine with the
> workstations that are sitting on the same subnet, but not with the other
> ones.
> I had created superscopes, but then I deleted them following some advice I
> found in this newsgroup.

No Superscopes!

The LAN Router(s) that route the traffic between the subnets have to perform the
DHCP Relay. That is the Router's job,...not the DHCP Server's.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed (as annoying as they are, and as stupid as they sound), are
my own and not those of my employer, or Microsoft, or anyone else associated
with me, including my cats.
-----------------------------------------------------

I confirm that, even if I did create superscopes, I then deleted them after
reading other topics in this newsgroup, but this did not solve the problem.

The Linux server distribute addresses from 10.18.146.32 to 10.18.146.254
The new Windows 2003 distribute addresses from 10.18.147.2 to 10.18.147.240

Could it be possible that a client served by the old server (in my test it
has address 10.18.146.73) is trying to get the same address from the new
server, but i does not work becaus it falls within an exclusion range?

Thank you

Cheers

"Phillip Windell" wrote:

> "Massimo" <(E-Mail Removed)> wrote in message
> news:5FCFF757-BB6F-4A42-8DB9-(E-Mail Removed)...
> > Hello everybody,
> >
> > I have installed a Windows 2003 SP1 DHCP server that has to distribute
> > addresses to workstations located on four subnets. It works fine with the
> > workstations that are sitting on the same subnet, but not with the other
> > ones.
> > I had created superscopes, but then I deleted them following some advice I
> > found in this newsgroup.
>
> No Superscopes!
>
> The LAN Router(s) that route the traffic between the subnets have to perform the
> DHCP Relay. That is the Router's job,...not the DHCP Server's.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
> The views expressed (as annoying as they are, and as stupid as they sound), are
> my own and not those of my employer, or Microsoft, or anyone else associated
> with me, including my cats.
> -----------------------------------------------------
>
>
>

"Massimo" <(E-Mail Removed)> wrote in message
news955052A-F2AD-4DD3-B685-(E-Mail Removed)...
>I confirm that, even if I did create superscopes, I then deleted them after
> reading other topics in this newsgroup, but this did not solve the problem.
>
> The Linux server distribute addresses from 10.18.146.32 to 10.18.146.254
> The new Windows 2003 distribute addresses from 10.18.147.2 to 10.18.147.240
>
> Could it be possible that a client served by the old server (in my test it
> has address 10.18.146.73) is trying to get the same address from the new
> server, but i does not work becaus it falls within an exclusion range?

You have to get rid of the old DHCP Server completely,...it cannot even be
powered up n the LAN,...or the Client will try to connect to it. Clients always
try the last DHCP they contacted and will always ask for the same IP Specs they
had "last time".

When you create Scopes, always use the entire full range of the subnet,...then
reduce it down to the addresses you wish to grant by using the Exclusions.

[Example]
Range: 10.18.146.1 --- 10.18.146.254
Exclusion #1 10.18.146.1 -- 10.18.146.99
Exclusion #2 10.18.146.201 -- 10.18.146.254
Options <whatever>

This will grant address to clients in the range of 10.18.146.100 --
10.18.146.200. If you run low on addresses and need more, then just shorten the
Exclusions.

Windows DHCP must be authorized by the DC before it can give out addresses.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed (as annoying as they are, and as stupid as they sound), are
my own and not those of my employer, or Microsoft, or anyone else associated
with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------

The DHCP server is authorized by the DC (it does distribute addresses to
clients sitting on its subnet).

When I do my tests I shutdown the other DHCP server (or I disconnect it from
the network, which, I guess, it is the same thing).

I apologize for the length of the post, I copied here below the Ethereal
output concerning the two frames DHCP inform and DHCP ack between a client
workstation and the server. It looks like the router (Cisco, IP address
157.150.88.1)) is actually propagating the DHCP request and the DHCP server
(IP address 157.150.91.56) seems getting it and replying, but then on the
client workstation I get the message "DHCP server unreachable".




No. Time Source Destination Protocol Info
46 19.240503 157.150.88.1 157.150.91.56 DHCP
DHCP Inform - Transaction ID 0xc46233ab

Frame 46 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: Cisco_c1:a0:c0 (00:14:1b:c1:a0:c0), Dst: Intel_9f:28:de
(00:04:23:9f:28:de)
Destination: Intel_9f:28:de (00:04:23:9f:28:de)
Address: Intel_9f:28:de (00:04:23:9f:28:de)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This
is a FACTORY DEFAULT address
Source: Cisco_c1:a0:c0 (00:14:1b:c1:a0:c0)
Address: Cisco_c1:a0:c0 (00:14:1b:c1:a0:c0)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This
is a FACTORY DEFAULT address
Type: IP (0x0800)
Internet Protocol, Src: 157.150.88.1 (157.150.88.1), Dst: 157.150.91.56
(157.150.91.56)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 1
Transaction ID: 0xc46233ab
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 10.18.146.213 (10.18.146.213)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 157.150.88.1 (157.150.88.1)
Client MAC address: Intel_4d:8e:bb (00:11:11:4d:8e:bb)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Inform
Option 61: Client identifier
Hardware type: Ethernet
Client MAC address: Intel_4d:8e:bb (00:11:11:4d:8e:bb)
Option 12: Host Name = "UNC2447"
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
249 = Classless static routes
43 = Vendor-Specific Information
252 = Proxy autodiscovery
End Option
Padding

No. Time Source Destination Protocol Info
47 19.240653 157.150.91.56 10.18.146.213 DHCP
DHCP ACK - Transaction ID 0xc46233ab

Frame 47 (348 bytes on wire, 348 bytes captured)
Ethernet II, Src: Intel_9f:28:de (00:04:23:9f:28:de), Dst: Cisco_c1:a0:c0
(00:14:1b:c1:a0:c0)
Destination: Cisco_c1:a0:c0 (00:14:1b:c1:a0:c0)
Address: Cisco_c1:a0:c0 (00:14:1b:c1:a0:c0)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This
is a FACTORY DEFAULT address
Source: Intel_9f:28:de (00:04:23:9f:28:de)
Address: Intel_9f:28:de (00:04:23:9f:28:de)
.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame
.... ..0. .... .... .... .... = Locally Administrated Address: This
is a FACTORY DEFAULT address
Type: IP (0x0800)
Internet Protocol, Src: 157.150.91.56 (157.150.91.56), Dst: 10.18.146.213
(10.18.146.213)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xc46233ab
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 10.18.146.213 (10.18.146.213)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 157.150.88.1 (157.150.88.1)
Client MAC address: Intel_4d:8e:bb (00:11:11:4d:8e:bb)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK
Option 54: Server Identifier = 157.150.91.56
Option 1: Subnet Mask = 255.255.254.0
Option 15: Domain Name = "unctad.unctad.org"
Option 3: Router = 10.18.146.1
Option 6: Domain Name Server
IP Address: 157.150.64.76
IP Address: 192.168.200.3
IP Address: 192.168.201.3
Option 44: NetBIOS over TCP/IP Name Server
IP Address: 157.150.64.77
IP Address: 157.150.64.203
End Option




"Phillip Windell" wrote:
>
> You have to get rid of the old DHCP Server completely,...it cannot even be
> powered up n the LAN,...or the Client will try to connect to it. Clients always
> try the last DHCP they contacted and will always ask for the same IP Specs they
> had "last time".
>
> When you create Scopes, always use the entire full range of the subnet,...then
> reduce it down to the addresses you wish to grant by using the Exclusions.
>
> [Example]
> Range: 10.18.146.1 --- 10.18.146.254
> Exclusion #1 10.18.146.1 -- 10.18.146.99
> Exclusion #2 10.18.146.201 -- 10.18.146.254
> Options <whatever>
>
> This will grant address to clients in the range of 10.18.146.100 --
> 10.18.146.200. If you run low on addresses and need more, then just shorten the
> Exclusions.
>
> Windows DHCP must be authorized by the DC before it can give out addresses.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
> The views expressed (as annoying as they are, and as stupid as they sound), are
> my own and not those of my employer, or Microsoft, or anyone else associated
> with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/downlo...7/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
> -----------------------------------------------------
>
>
>

"Massimo" <(E-Mail Removed)> wrote in message
news:3A89F5A0-EAD1-4DC7-AD49-(E-Mail Removed)...
> The DHCP server is authorized by the DC (it does distribute addresses to
> clients sitting on its subnet).
>
> When I do my tests I shutdown the other DHCP server (or I disconnect it from
> the network, which, I guess, it is the same thing).
>
> I apologize for the length of the post, I copied here below the Ethereal
> output concerning the two frames DHCP inform and DHCP ack between a client
> workstation and the server. It looks like the router (Cisco, IP address
> 157.150.88.1)) is actually propagating the DHCP request and the DHCP server
> (IP address 157.150.91.56) seems getting it and replying, but then on the
> client workstation I get the message "DHCP server unreachable".

There is nothing I can do with a packet capture.
There isn't that much to this.
If the Scopes are built correctly and the Router passes the packets to the DHCP
Server it "just works".

Give a Client static addressing instead of DHCP and see if it actually works
properly on the LAN. If there are routing or other LAN issues, then something
should show up. You always have to make sure the condition of the LAN's
topology is "pertfect" before you deploy DHCP to the Clients.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed (as annoying as they are, and as stupid as they sound), are
my own and not those of my employer, or Microsoft, or anyone else associated
with me, including my cats.
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/IS...cessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004
http://download.microsoft.com/downlo...7/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp
-----------------------------------------------------

It si not the problem of one client, but of all the clients that are on a
subnet different from the DHCP server one. These clients work fine and have
no connectivity problems with the addresses distributed by the old Linux DHCP
server.
Following your advice I will try to give one client a fixed IP. There are
already a number of printers on our LAN which have a fixed IP address and
they work fine.
I'm not sure whether our LAN topology is "perfect" or not, but it is working
with DHCP since several years with no particular problems.
I apologize again for posting the packet capture, if this was not
appropriate. I am just looking for DHCP troubleshooting tools in order to
solve my problem.

"Phillip Windell" wrote:

> There is nothing I can do with a packet capture.
> There isn't that much to this.
> If the Scopes are built correctly and the Router passes the packets to the DHCP
> Server it "just works".
>
> Give a Client static addressing instead of DHCP and see if it actually works
> properly on the LAN. If there are routing or other LAN issues, then something
> should show up. You always have to make sure the condition of the LAN's
> topology is "pertfect" before you deploy DHCP to the Clients.
>
> --
> Phillip Windell [MCP, MVP, CCNA]
> www.wandtv.com
>
> The views expressed (as annoying as they are, and as stupid as they sound), are
> my own and not those of my employer, or Microsoft, or anyone else associated
> with me, including my cats.
> -----------------------------------------------------
> Understanding the ISA 2004 Access Rule Processing
> http://www.isaserver.org/articles/IS...cessRules.html
>
> Troubleshooting Client Authentication on Access Rules in ISA Server 2004
> http://download.microsoft.com/downlo...7/ts_rules.doc
>
> Microsoft Internet Security & Acceleration Server: Partners
> http://www.microsoft.com/isaserver/partners/default.asp
> -----------------------------------------------------
>
>
>

"Massimo" <(E-Mail Removed)> wrote in message
news:F9CAB874-0E32-4805-9159-(E-Mail Removed)...
> I'm not sure whether our LAN topology is "perfect" or not, but it is working
> with DHCP since several years with no particular problems.

Ok,... well, it is like I said in the last post, ...
If the Scopes are built correctly and the Router passes the packets to the DHCP
Server it "just works".


> I apologize again for posting the packet capture, if this was not
> appropriate.

There is nothing "wrong" with doing that,..but I don't use them,...not in news
groups anyway. There is only a certain amount of complexity that can be dealt
with in a newsgroup with "email messages" and for me,... Packet Captures, Raw
Log Entires, and even in some cases Rotuing Table outputs are just too much over
the edge for me to deal with. The line wrap destroys them and all they do is
make me dizzy to try to read them.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

The views expressed (as annoying as they are, and as stupid as they sound), are
my own and not those of my employer, or Microsoft, or anyone else associated
with me, including my cats.
-----------------------------------------------------