Inter-Vlan Routing & DHCP - Cannot obtain an address

I cannot obatin a DHCP address from the server when on a VLAN
different to the DHCP server.

I have a Cisco network with several buildings joined via fibre.

The core building has a single 3750 12 Port fibre switch that
terminates each of the fibre connections from the other buildings. It
also connects directly to the sever. Each building connection is
configured as a trunk with dot1q encapsulation

The outer buildings all have 3550-24/48 switches with a Gigabit SX
FIbre GBIC.

I have configured VLANing and each building has its own VLAN. I have
given an IP address to each VLAN on the 3750 and this is the default
gateway for each of the respective clients. I have also configured "ip
helper-address" on each VLAN interface and pointing it at the single
DHCP server.

The DHCP server has seperate scopes configured for each of the VLANs.
If I manually assign an IP address to a client machine in a seperate
VLAN to the DHCP server, I can ping each of the other vlans and all
the servers with no problem.

As soon as I set the client to DHCP I cannot obatin an address despite
the ip helper-address command being used on that VLAN and the fact I
can ping the DHCP server when I have a static address.

Any ideas?? Any help would be appreciated.

 

Anything in the logs of the DHCP server?

Have you run a packet sniffer to see what's happening? Run it at the
DHCP server and on the client. A great free sniffer can be found at
www.ethereal.com. It's available for windows, linux, etc and can
really help you figure out what's happening. For example is the
request not getting forwarded, is the reply a nack, is the reply not
getting back to the client, etc.

-Chris

 

are the ports set to portfast, I have had trouble with machines trrying to
get a lease before the network is up
Paul

 

Thanks for the responses.....

All the client ports are set to portfast.

I have yet to try a sniffer on the network however thanks for the
link, I will give this a try.

I have found several Cisco documents on this topic however the network
I am configuring this on is setup the same as in the documents.

I will try the sniffer during the week and post any results I get from
that.

 

OK, I have run a sniffer on the network with the client plugged into
the default VLAN (Obtains DHCP address instantly) and with the client
plugged into a port on a seperate VLAN.

The results:

For the example:
Client MAC = 00.01.02.03.04.06
DHCP Server MAC = 07.08.09.0A.0B.0C - IP = 10.1.1.1


Default VLAN (Obtains DHCP)

00.01.02.03.04.06 -> ff.ff.ff.ff.ff.ff ARP (Who has
10.1.1.1)
07.08.09.0A.0B.0C -> 00.01.02.03.04.06 ARP (Address is
07.08.09.0A.0B.0C)
00.01.02.03.04.06 -> 07.08.09.0A.0B.0C DHCP (DHCP REQ)
07.08.09.0A.0B.0C -> 00.01.02.03.04.06 DHCP (DHCP ACK)


Seperate VLAN (Does not obtain DHCP)

00.01.02.03.04.06 -> ff.ff.ff.ff.ff.ff ARP (Who has
10.1.1.1)


This is indicating to me that the ip helper-address is working as the
client is broadcasting for the MAC of the correct IP address of the
DHCP server however it is not getting a response. The default gateway
of the DHCP server is the backbone switch and the DHCP server can ping
the VLAN IP addresses. Once again if I give the client a static
address in th ecorresponding VLAN IP range it works fine.

There is nothing in the logs in relation to the DHCP server.

Any ideas??

 

Why is your PC arp'ing for someone outside of his subnet? I'm assuming
the server is at 10.1.1.1 but your PC is not (otherwise you wouldn't
need a router).


--

hsb

"Somehow I imagined this experience would be more rewarding" Calvin
*************** USE ROT13 TO SEE MY EMAIL ADDRESS ****************
********************************************************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
********************************************************************

 

The client thinks it already knows its ip address and it's just
confirming it with the server, whose address it also already knows.

The client is renewing an existing lease rather than requesting a new
one.

The client thinks it already knows its ip address and it's just
confirming it with the server, whose address it also already knows. This
time it doesn't work because there is no answer to the arp, because we are
no longer on the same vlan.

What the client should do here is give up trying to contact the server
directly, and go back to the beginning and broadcast a DHCP DISCOVER,
which will be forwarded by the ip helper on the router and the server will
respond.

Windows, some versions, is known for misbehaving in this respect. You
have to do ipconfig /release, ipconfig /renew if you move vlans.

This has nothing to do with ip helper address. Ip helper address
forwards udp broadcasts, which arp is not. Arp is local to the vlan and
doesn't cross routers.

Tell your client to forget wahtever it thinks it knows about its existing
ip address and start the process from the beginning by broadcasting a DHCP
DISCOVER, and you stand a better chance of success.

 

Thanks for your detailed responses. I revisted this yesterday to
obtain a packet trace from the DHCP server rather than from the
client.

I started the sniffer and attempted to obtain an adress to capture the
failure but this time it didnt fail !! I obtained an address from the
DHCP server in the correct VLAN scope. AND NOTHING HAS CHANGED !!! :s

The only difference is I tried what Martin suggested and I did a full
release before the renewal. So to prove this theory I connected a
second machine to this VLAN and did not do a release just a straight
renew and it also worked!

I then thought it had something to do with plugging teh DHCP server
into a hub to do the packet sniffing so I plugged it back into the
switch, added a third machine to the VLAN did a renewal and it also
worked.

I am glad that this problem has rectified itself but at a loss to why
it hasnt worked for two weeks and all of a sudden with no changes it
works. I am still investigating it as I have a number of additional
VLAN's to setup and would like to know the cause of the original
problem in case it reoccurs on the other VLAN's.

As suggested by Martin after the DCHP server fails to respond to the
confirmation it should go back to the beginning and broadcast a DHCP
DISCOVER. This was not occurring until after I did a release on one
machine.

One possible suggetsion is that these machines all have a Novell
client on them which may be interfering with the process.....only
possible explanation I can come up with at this time as within the
client there is a configuration option for DHCP so it may be trapping
the request and redirecting it.