DHCP'ish problem.

srgsrg Member Posts: 140
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

Comments

  • larkspurlarkspur Member Posts: 235
    maybe running debug or posting teh configs so others have a little info to review.

    :o
    just trying to keep it all in perspective!
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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
    The only easy day was yesterday!
  • srgsrg Member Posts: 140
    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.
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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
    The only easy day was yesterday!
  • srgsrg Member Posts: 140
    Haha this is so ridiculous icon_redface.gif. Someone had trashed around the vlans so they didn't match without me knowing. Everything works fine now. Sorry for your time.. icon_rolleyes.gif
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    heh, it's times like this that remind me why companies have change management procedeures. Glad to see you got it sorted out.
    The only easy day was yesterday!
  • njcowboynjcowboy Member Posts: 42 ■■□□□□□□□□
    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
  • NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    **taking notes**
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • LOkrasaLOkrasa Member Posts: 343 ■■■□□□□□□□
    oh noes... this all sounds like greek to me...
Sign In or Register to comment.