I few years ago I took over as the IT Director for a small organization. It is and has been my dream job ever since. BUT on major factor that concerned me when I started was the specific subnet that was used for the enterprise network… I am willing to bet you can guess what they who came before me used… It started with 192…
Anyways, I have left it but it has always bugged me. I have always wanted to re-IP everything to something less common, but the thought of what I might break always prevented me.
Has anyone out there does something like this for a network that has been established for a while? And if so what issues did you discover? Are there any considerations I should make if I did want to do this? Or is it really not worth my time and should I just ride it out?
The main reason I am thinking about it again is we are starting to expand and have welcomed a number of remote users who MAY VPN into the network from time to time. I am just waiting for someone to try and connect to our network when their home network is on the same subnet…
I’m waiting for new switches, and then my goal is to move away from the legacy class C (192) to a class B (172) scope. I think I can just add the new interfaces to me servers, add the new scope to my dhcp, and paint all the switch ports to the new vlan. Then clean up all the other stuff that works with static addresses. I’ve done a quick test in my lab and this should work fine, hopefully without breaking membership in the domain.
After the move works, I can then remove the old class C stuff and go forward. The new switches are a year overdue, hoping they get here straight away. The last update was the end of May, which is now gone.
@Greg_E I completely feel your pain. I had wanted to add some 10Gb transmission to our internal systems but my switch options were VERY limited. So we are holding off until stock figures itself back out. What MFG are you waiting for out of curiosity?
ALSO: I like your approach. I had not considered splitting everything off to a new VLAN and figuring it out on the back end. That sounds like a good course of action. The only thing that continues to concern me are the setting that I am unaware of. Like I said all this was setup WAY before I worked here, and the individual who initially set the network up unfortunately has passed away. So I am playing Sherlock Holmes for a lot of this stuff. I just very much don’t want to cause myself a week of running around putting out fires. I think the VLAN addresses that aspect in someways. You have given me something else to think about. Thanks!
These are Extreme Networks and I think it is more how we purchased them. It was about a $1.5 million project and the reseller sold switches and power supplies separately to reduce the cost. Most switches will only have a single PS installed, only heavy POE loads will get the second supply. I think if we just ordered the standard configuration, everything would have been here by now, been about a year and 9 months since the order went out.
Out of that big order, mine was 3 switches and 5 years of support, about 1.5% of the total.
I agree with Greg and think it would be easiest to build all the new networks and then work to migrate one service at a time. Once they are all out of those networks you can simply delete them.
I will say that my moving from physical to virtual machines was not without headache. For a reason I still don’t understand, I had a lot of replication issues with my AD servers and DNS servers. Also DHCP eventually stopped being failover too. It was a mess and I waited out the last few months with every service I really needed running on a 2012 4 core server with a hard drive that looked like it could fail at any moment (and already did back in November). Tore all my VM’s back down to nothing except for the one running my KMS host, cleaned up AD and DNS best I could., and then started building things back. Once I was happy that replication continued to work, I added DHCP failover to that VM. Once I was happy there, I moved the FSMO roles to the VM. And once I was happy that things were still working, I shut down the last physical AD, stood up the new VM to take it’s place, and installed AD, DNS, and DHCP again. It’s been under watch for the last week to make sure it keeps replicating and that DNS is working between both servers.
DHCP failover did do a strange thing and deleted most of my DHCP options on one server, I had to go back and fix them about 2 weeks ago, so far so good. Kind of worrying when you log in on Monday and you no longer have a DNS server set for your workstation, it grabbed DHCP from the other server where the settings vanished. It was a quick fix with some RDP by IP address, but still something I wouldn’t want to happen during our semesters.
Be very careful of the DCs as VMs. While it’s great for what it is but being a controller of the entire domain it can bite you in the butt fairly quickly. What most system admins don’t realize if you ever restore the DC VM you must do it offline and then go through the process of making sure it’s set to non-authoritative replication otherwise it’s going to replicate the OLD AD data to all of your DCs.
Now supposedly starting with Server 2012 Microsoft put in a failsafe that checks to see if the VM ever been rolled back and if so it will automatically put into non-authoritative replication mode. This is contingent on what vm hosting environment you have. I use ProxMox which is QEMU/KVM based and it uses special serial number identifiers to let the OS know that it’s been rolled back.
I have 4 DCs. Two physical DCs (one as primary) and other two as VMs. If something happens to the DC VM I let it fail so I can handle it manually.
I was not aware, thanks. There are supposed to be protections built in where if replication has not happened in XX days, it forces the “disconnected” partner into manual replication to prevent stale records. I don’t remember if that time period is 5 days or 115 days. I had a similar problem a few months ago where the AD was disconnected for a few days, then several weeks later the SYSVOL share was no longer available on the “disconnected” AD. I reverted everything back to the last physical machine and rode it out. I think I caused this by having the last physical machine off for about 4 days and stuff got out of sync and eventually cascaded to a big failure.
I’ll have to make a test domain when I get my lab back together and see if I can break this, and then see if I can fix it. I’ll have to test bringing an old backup back online and see if it replicates old data. Just a note, old X5650 processors with the latest updates from XCP-NG and Windows Server 2022 seem to have some problems staying running (my old lab). Not sure where the fault lies, but I’m guessing it is something with Server 2022 because I’ve had this lab running for about 3 years and most of that with Server 2022. But recently I started having issues so I tore it apart and bought “newer” HP DL360p G8 servers with Xeon E5-2650L v2 processors and a pile more ram. I have more cores in my lab (per host) now than I do in my production system. All my Linux VMs were working fine on the lab which again points to Server 2022 with the most recent updates being the issue.
Pretty sure it’s possible to tie in network permissions, network shares, network service restrictions + more in a granular fashion via domain controller so that your VPN guests stay restricted only to what you allow. Redoing the IP scheme seems like a good idea either way.
Overall complexity of doing so will depend a lot on what’s running internally.
Run something like https://www.runzero.com/ on your firewall or node that has access to all your network vlan etc … to discover all the device you have and their associated network settings. Take it from there
