01-22-2013 11:37 AM
I work for a company that recently upgraded to a Cisco RVS4000 router in place of a failing D-Link router. I configured the RVS4000 to utilize the same address space as the D-Link previously did (192.168.0.0 Network Address, 255.255.255.0 Subnet Mask, RVS4000 in Gateway Mode with IP Address 192.168.0.1, DHCP Scope from 192.168.0.101 - 200 managed by the RVS4000) before installing it on the network. I powered down the D-Link as well as the cable modem, then all of the workstations in the office. Then, I installed the RVS4000, powered up the cable modem, and once it was ready, powered on the RVS4000.
When devices connect, the RVS4000 is assigning them an IP address in the 192.168.1.0/24 subnet, instead of the 192.168.0.0/24 subnet. I have verified that the RVS4000's GUI is showing the correct settings, but connected devices are not picking up addresses from the correct address pool. In troubleshooting, I went to each workstation, released and renewed their IP addresses, and they picked up addresses in the correct subnet. I thought everything was solved, but the next day, the same problem resurfaced.
I left the DHCP lease time at the defaul value "0", which according to the unit's documentation should correspond to a 24-hour lease period. I suspect this is why I had to renew the clients' IP addresses the next day (today), but I still don't get why the RVS4000 wants to give out addresses in the 192.168.1.0/24 scope. Could this be a holdover from the factory settings? Does anyone have a suggestion to prevent this from happening every day?
Additional Information:
I did not set up any VLANs on the network and the office only requires one subnet as there are not a lot of devices connected, nor do we need the traffic segragated. The VPN functions of the RVS4000 work fine. Using the QuickVPN utility, I can access the network and resources on the network remotely without issue.
01-22-2013 03:04 PM
Thanks for using our forum
Hi Robert, my name is Johnnatan and I am part of the Small business Support community. In order to resolve your problem, could you check your DHCP configuration? After that please save your settings and try again in your computers, here I leave a document where you can see the configuration.
http://www6.nohold.net/CiscoSB/Loginr.aspx?login=1&pid=2&app=search&vw=1&articleid=711
If this doesn´t work, change the lease time to your DHCP pool to 720 minutes, also check if your router has the latest firmware, the latest release is:
If your device is the first version the latest firmware is 1.1.13 and you can download it here:
If your device is the second version the latest firmware is 2.0.2.1 and you can download it here:http://software.cisco.com/download/release.html?mdfid=282414016&flowid=790&softwareid=282487380&release=2.0.2.1&relind=AVAILABLE&rellifecycle=&reltype=latest
I hope this answer help you.
*Please mark the question as Answered or rate it so other users can benefit from it"
Greetings,
Johnnatan Rodriguez Miranda.
Cisco Network Support Engineer.
01-23-2013 06:19 AM
Thank you for the reply.
I have taken a screenshot of the LAN Configuration as viewed through the web interface. There is no other DHCP server on the local network. The RVS4000's IP address is 192.168.0.1, and I am able to access the web interface by navigating to that address in a web browser. I left the 192.168.0.1 - .100 and .201 - .255 out of the DHCP pool to leave room for static IP address assignments for devices like network printers, wireless access points, etc.
As far as the firmware is concerned, the status tab indicates that the router is running V2.0.2.7, which seems higher than the V2.0.2.1 which you have recommended. Should there have been an extra digit at the end of the firmware version that you linked?
The issue has persisted on some of the computers on the local network, with both Windows XP Professional and Windows 7 Professional. A number of the machines received the correct IP addresses this morning. Is it possibly something in the Windows TCP/IP configuration that could be causing the PCs to request/receive the incorrect addresses? There is one thing that doesn't make sense in that case though, which is the fact that the network has never used the 192.168.1.x subnet...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide