DHCP Relay not working

[mcvosi]

I have a 3550 doing routing between vlans with two 3548's connected. I've enabled the ip helper address for the specified vlan I'm testing, but the workstation is unable to contact the server. The DHCP server is Windows Server 2003.

What am I missing here?

[Prashanth Krishnappa]

Make sure you have Spanning-tree portfast enabled on interfaces which connect to workstations and servers. Also, the following page should help out

http://www.cisco.com/warp/public/473/100.html

[Richard Burts]

A few specifics would make it easier to find the problem: in what subnet (and on what VLAN) is the DHCP server located? What VLAN (and what subnet) is the workstation that can not access the DHCP server? On which interface did you configure the helper address? and what syntax did you use to configure the helper address?

If we know these things we may be able to help you better.

HTH

Rick

[mcvosi]

The DHCP server is currently in VLAN 1 (currently a flat network structure). The new vlan looks like this:

interface Vlan15

description Testing VLAN

ip address 192.168.15.254 255.255.255.0

ip helper-address 192.168.1.100

Of course, the helper is the DHCP server's address. The DHCP scope is all configured properly.

I don't know if this matters or not, but the 3550's default gateway currently points to a pix, so I wasn't sure if that would cause problems as I have not configured yet the internal routes on the pix for the new vlans, etc. I wanted to ensure that I had the newly created vlans talking to the DHCP server first.

[Richard Burts]

Thanks for posting the additional information. Assuming that vlan 1 is configured on the 3550 and that the DHCP server is on a port in vlan 1 and that the IP address on the vlan 1 interface makes the DHCP server address part of the connected subnet, then I do not see how the 3550 default gateway pointing to the PIX should be an issue.

The configuration of interface vlan 15 looks ok and the helper-address configuration appears proper. Assuming that the PCs are on ports that are assigned to vlan 15 and assuming that trunking is correct so that the vlan 15 packets get to the 3550, it looks to me like the DHCP requests should get to the server. Perhaps you could post the configuration of vlan 1.

HTH

Rick

[mcvosi]

The only configuration for vlan 1 is an ip address for management, which I don't use anyway because I console in via a console server but I digress.

VTP all seems to be working fine on the switches - the 3550 as the server and the 3548's and 2950 as clients. I did some debugs on the traffic and for some reason the DHCP server is not receiving the intended packets from vlan 15. Here's what it looks like:

2w1d: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308

2w1d: UDP: sent src=192.168.15.254(67), dst=192.168.1.100(67), length=333

2w1d: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67), length=308

There are no packets from the DHCP server, so I don't know where to go from here. I've been round and round with this.

[Richard Burts]

I would like to verify my understanding of some things about the environment you have. I believe that you have told us that the 3550 is providing the routing and layer 3 services for the network. Attached to the 3550 are two 3548. Attached to at least one of the 3548 is a 2950. The 2950 is where the workstations are connected that are attempting to contact the DHCP server. Is this correct?

Where is the DHCP server connected? If you do an extended ping on the 3550 which specifies the DHCP server as destination and specifies the VLAN 15 interface as source, does the ping work? This will veify IP connectivity between VLANs and verify the default gateway on the DHCP server.

If the extended ping from the 3550 works, then please do a ping from the console of the 2950 to the address of the DHCP server. This will verify IP connectivity from the 2950 to the server.

It would also be helpful if you would post the output of show vlan from the 2950, the 3548, and the 3550.

HTH

Rick

[mcvosi]

Rick,

The extended ping fails:

Protocol [ip]:

Target IP address: 192.168.1.100

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: vlan 15

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.100, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

---

Here are the VLAN outputs. The VLAN is question is the Testing VLAN:

3550:

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Gi0/1, Gi0/2, Gi0/3, Gi0/4

Gi0/5, Gi0/6, Gi0/7, Gi0/8

Gi0/9, Gi0/10

2 Accounting active

3 Engineering active

4 Legal active

5 Ops active

6 Purchasing active

7 Executive active

8 Recep active

9 Admin active

15 Testing active

3548:

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4,

Fa0/5, Fa0/6, Fa0/7, Fa0/8,

Fa0/9, Fa0/10, Fa0/11, Fa0/12,

Fa0/13, Fa0/14, Fa0/15, Fa0/16,

Fa0/17, Fa0/18, Fa0/19, Fa0/20,

Fa0/21, Fa0/22, Fa0/23, Fa0/24,

Fa0/25, Fa0/26, Fa0/27, Fa0/28,

Fa0/30, Fa0/31, Fa0/32, Fa0/33,

Fa0/34, Fa0/35, Fa0/36, Fa0/37,

Fa0/38, Fa0/39, Fa0/40, Fa0/41,

Fa0/42, Fa0/43, Fa0/44, Fa0/45,

Fa0/46, Fa0/47, Fa0/48, Gi0/2

2 Accounting active

3 Engineering active

4 Legal active

5 Ops active

6 Purchasing active

7 Executive active

8 Recep active

9 Admin active

15 Testing active

2950:

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/2, Fa0/3, Fa0/4, Fa0/5

Fa0/6, Fa0/7, Fa0/8, Fa0/10

Fa0/11, Fa0/12

2 Accounting active

3 Engineering active

4 Legal active

5 Ops active

6 Purchasing active

7 Executive active

8 Recep active

9 Admin active

15 Testing active Fa0/9

[Richard Burts]

This is a very helpful piece of information. I assume that a standard ping to the server from the console of the 3550 will succeed.

Assuming that the standard ping does work and the extended ping does not work, I think it points to the problem most likely being misconfiguration of the default gateway on the server. Can you find and post the default gateway on the server?

HTH

Rick

[mcvosi]

The current default gateway of the server is the pix because the network topology is currently flat. So, once I configure the default gateway as the vlan 1 interface it should be able to respond?

[Richard Burts · Accepted solution]

If you configure the default gateway on the server to be the 3550 vlan 1 interface I believe that the workstations on vlan 15 will be able to talk to the DHCP server.

In one of your previous posts you mentioned that you have not yet configured routes on the PIX for the new internal networks. I believe that if you go ahead and configure the PIX with routes for vlan 15 it may allow the workstations on vlan 15 to communicate with the server (assuming that the PIX will route back out the interface on which the packet was received).

HTH

Rick

[mcvosi]

I changed the default gateway on the DHCP server and the client was able to get an address.

Thank you very much for all your help. I really appreciate it.

Matt

[mcvosi]

I do have portfast configured on the workstation in question.

[glen.grant]

On the layer 3 SVI is the ip helper pointing towards the dhcp server address ? I am assuming that the server is on a different . Also on the 3548 make sure all user ports have spanning tree portfast turned on .

[mcvosi]

I have a 2950 hanging off the 3548, and the workstation that will be in the new vlan is off that 2950. For that reason I cannot enable portfast on the 3548 due to that port connecting to the 2950, but I do have the port on the 2950 on portfast.

Hope my wording makes sense. :-)