Newb Mistake - Wrong Subnet Mask
I built a production voice network on UCS servers about 4 months ago. I just noticed I built every server with the wrong netmask. I misread /29 on the IP assignment sheet to be 255.255.255.240, it should have been X.X.X.248.
It doesn't appear to be an issue, all servers are up fine. I can access every device and no problem pinging devices, etc... The only problem is now that the network is in production to correct this would cause a reboot on every device. There's 8 servers total and at least a minimum of 1-2 virtual machines.
I don't have access to the switch environment to confirm the VLAN subnets, but I'm debating if I should make an issue about this or leave it alone. Anything to worry about here? Everything is surprisingly working fine...
It doesn't appear to be an issue, all servers are up fine. I can access every device and no problem pinging devices, etc... The only problem is now that the network is in production to correct this would cause a reboot on every device. There's 8 servers total and at least a minimum of 1-2 virtual machines.
I don't have access to the switch environment to confirm the VLAN subnets, but I'm debating if I should make an issue about this or leave it alone. Anything to worry about here? Everything is surprisingly working fine...
"The heights by great men reached and kept were not attained by sudden flight, but they, while their companions slept were toiling upward in the night." from the poem: The Ladder of St. Augustine, Henry Wadsworth Longfellow
Comments
-
ptilsen Member Posts: 2,835 ■■■■■■■■■■You wouldn't see impact unless the servers need to get to a /29 falling within their currently configured /28 on a different switch or VLAN. If the devices are on subnets that don't fall within the /28 you configured, there won't be impact now, but there could be in the future if changes are made, so I would correct it.
Just as an example, I ran into a DHCP server handing out class B IPs on a /24 subnet that were inadvertently configured with /16 SMs because it was the default for a class B IP and whoever configured it wasn't paying attention. It would have saved the pain of fixing the problems that eventually resulted if someone had fixed it when it was first noticed or configured. This is the sort of thing that could come back to bite someone else in the future, so it would be a nice professional courtesy to fix it at the very least. -
networker050184 Mod Posts: 11,962 ModThis is the sort of thing that could come back to bite someone else in the future, so it would be a nice professional courtesy to fix it at the very least.
My thoughts exactly. Schedule some down time and get it fixed before it becomes an issue down the road that takes someone forever to figure out.An expert is a man who has made all the mistakes which can be made. -
DevilWAH Member Posts: 2,997 ■■■■■■■■□□Fix it or not I think that is up to the company and management. But what you need to do is make them aware of the issue so they can decided. They might jsut want to up date there records and leave it as is, or go back and fix it.
I don't suggest you fix it with out notifying people though, if you cause an issue as you do for any reason people will not be please, we all make mistakes its how you resolve them that counts.
Tell management what has happened and make sure you outline the steps to fix it and any outage it may cause. The chances are they will let you fix it and be thankful for you holding your hand up. If get upset and have a go then you know you are working at the wrong place.- If you can't explain it simply, you don't understand it well enough. Albert Einstein
- An arrow can only be shot by pulling it backward. So when life is dragging you back with difficulties. It means that its going to launch you into something great. So just focus and keep aiming.
Linkin Profile - Blog: http://Devilwah.com -
networker050184 Mod Posts: 11,962 ModYes certainly do the change through proper channels. Don't going making a bigger problem by rebooting stuff in the middle of the day!An expert is a man who has made all the mistakes which can be made.
-
sieff Member Posts: 276made the changes tonight with no issues. glad i caught it. i was just browsing through and realized the mistake. the servers were all on separate VLAN's, so i assume this is why there were no adverse effects on the network."The heights by great men reached and kept were not attained by sudden flight, but they, while their companions slept were toiling upward in the night." from the poem: The Ladder of St. Augustine, Henry Wadsworth Longfellow
-
VAHokie56 Member Posts: 783if it that would have been me....I would of just scheduled a change to fix "an issue" maybe not specifically called it out as one I messed up on. If people started asking questions then I would certainly been honest about it. It also comes down to how controlled/reviewed your changes are in the environment I suppose too.ιlι..ιlι.
CISCO
"A flute without holes, is not a flute. A donut without a hole, is a Danish" - Ty Webb
Reading:NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures -
sieff Member Posts: 276I didn't announce the problem. I'm IT Consultant for Cisco partner, so really I should have been more precise... one of those reminders that you can never be too sure of yourself and to always double-check, triple-check your work."The heights by great men reached and kept were not attained by sudden flight, but they, while their companions slept were toiling upward in the night." from the poem: The Ladder of St. Augustine, Henry Wadsworth Longfellow