nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Newb Mistake - Wrong Subnet Mask

sieff

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...

Find more posts tagged with

SAVE $250 on Your Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View Boot Camps

Comments

ptilsen

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

ptilsen wrote: »

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.

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.

DevilWAH

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.

networker050184

Yes certainly do the change through proper channels. Don't going making a bigger problem by rebooting stuff in the middle of the day!

sieff

made 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.

VAHokie56

if 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

sieff

I 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.