We have a LAN with a Catalyst 5509 routing for 35 vlans. Whenever, a user moves from VLAN to another, he/she does not get an IP address from the new VLAN, their workstation still retains the old vlan IP even after performing a release and renew. Only after releasing the IP address on the DHCP server is the user able to get an IP in the new VLAN. However, there does not seem to be any problem when PCs are statically configured with IPs in the new VLAN
The ip helper-address has been configured on each VLAN, bootp requests and replies have been verified on the RSM using "debug ip udp".
I really appreciate any recommendations or advice on this.
Currently, all PC/server connected switch ports have been manually configured for "speed" & "duplex" and portfast enabled on them. I will disable trunking and port channeling on them also.
Per the "Understanding and troubleshooting DHCP" document I also ran a sniffer trace. In a couple of instances, I could BOOTREPLY being sent back to client as broadcast insted of unicast in response to the BOOTREQUEST. Is this normal?
Bootreply from the server should be sent to the "router" so that it can be forwarded by the router to the actual client. Is this before you moved to the new vlan or after. I sugget that you open a TAC case for further troubleshooting.
I have a 4006 in a test environment with four vlans configured one that supports my 2000 server running DHCP. When a workstation is initially plugged into a vlan it obtains the correct IP setting from the proper scope. If I move the workstation to another vlan, I can release the old IP setting but it can not find the DHCP server. If a new workstation joins the new vlan it can find the server and obtains an IP setting from the proper scope. If I statically configure the IP address on the workstation that is moved I can ping everywhere. I have tried deleting the address from my server. If I move the workstation back to its orginial vlan it can communicate with DHCP. It appears to me that the mac address is being cached somewhere. Has anyone encountered this problem? I would like some suggestions on how to test the packets to follow the requests .. will debug ip udp packets be my best bet. Thanks, CB
Do you have a ip broadcast address defined for each vlan , we found that this screws up the dhcp process , by removing the ip broadcast statement it would work the way it is supposed to . The ip broadcast statement was causing the broadcasts to be handled incorrectly , it was using a specific address as opposed to an all "1's" broadcast (255.255.255.255) which would cause symptoms similiar to the ones you are indicating .
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...