DHCP'ish problem.

srg

I'm having some strange dhcp-related problems.. this is the scenario: 6500(dhcpserver)--trunk--3550--user(dhcpclient).
Sometimes users behind the 3550 stops to get ips from the dhcp. If i look up the users mac in the arp table of the 6500, its bound to a external ip (which it SHOULD get from the dhcp), but according to the dhcp server bindings, it's not leased. The user just gets a 169.254 ip.

It seems to be port-specific, if I change a users port on the 3550, it works right away. Any idea what might be causing this? Reloading the 3550 will fix this, but thats not a desirable solution :P

larkspur

maybe running debug or posting teh configs so others have a little info to review.

dtlokee

Are you using any type of DHCP snooping / Dynamic ARP inspection on the switches? The default arp timeout will be 4 hours, so even if the ip address is dropped, it will not drop the arp entry right away. My thought is there is some form of DHCP snooping/DAI on the switch that prevents what it thinks is an invalid dhcp to IP address binding but when you move the client to a different interface it is successful.

Of course more information would help in the diagnosis

srg

ok a sample interface conf from the 3500:

interface FastEthernet0/2
 switchport access vlan 301
 switchport mode access
 switchport nonegotiate
 switchport port-security maximum 50
 switchport port-security
 switchport port-security aging time 900
 switchport port-security violation protect
 switchport port-security aging type inactivity
 speed 10
 storm-control broadcast level 10.00
 no cdp enable
 spanning-tree bpdufilter enable

no DHCP snooping or arp inspection whatsoever on that one.. dont have access to the 6500 at the moment, but i'm guessing the problem is on the 3550.

dtlokee

I don't see portfast on the interface, it could be the interface is not active until after the client has already given up on gatting an IP from DHCP and used APIPA

srg

Haha this is so ridiculous . Someone had trashed around the vlans so they didn't match without me knowing. Everything works fine now. Sorry for your time..

dtlokee

heh, it's times like this that remind me why companies have change management procedeures. Glad to see you got it sorted out.

njcowboy

dtlokee wrote:

I don't see portfast on the interface, it could be the interface is not active until after the client has already given up on gatting an IP from DHCP and used APIPA

I had this exact problem with BootP using Novell's imaging. The system would time out looking for a n ip number before the port became active.

Once you spend a couple hours of overlooking the obvious then you tend to remember the fix

Netstudent

**taking notes**

LOkrasa

oh noes... this all sounds like greek to me...