I’ll keep this post about your situation specifically.
First and foremost, managing over 3,000 devices with static IP addresses is just plain foolish. DHCP is a well-known and established protocol that solves the tedious task of manually assigning and fixing manual IP addresses. If they are that concerned about making sure they have control over every IP address on their network, set them as DHCP reservations. Even from a security standpoint, you don’t stand to benefit that much from eliminating DHCP servers.
By sticking with this route, you will lose:
- Change management capabilities
- Customer insight
The big hitter on this list is change management capabilities. If you need to swap IPs around, you really don’t have a good way to do this; and that makes (or will make) your life arduous. If your teammates aren't on board with it and want to stick with their old ways, try to rope in your management and inform them of what a colossal waste of time it is.
Regarding your nifty IP scheme; you will still be able to maintain that; If anything, to a greater degree. IPAM gives you the capability to drill down into smaller and smaller subnet ranges, making it seemingly easy to implement in your case. This will allow you to cascade further and further down into the building/device class you desire.
This is normal behavior for a layer 3 switch, management traffic can be sent to any active Switch Virtual Interface (SVI). If you only want to allow management traffic from a specific vlan/subnet, you could set up ACLs.
A layer 2 switch can be assigned a management IP address, attached to one vlan, called the management vlan. It will only be reachable inside this vlan.
In the case of the SF300, I believe you have to define a management ACL instead of a normal IP ACL if you want to filter management traffic into the switch. Use the management access-list
command, and then apply the ACL using management access-class
.
Best Answer
Quoting from Cisco:
https://www.cisco.com/c/en/us/td/docs/ios/security/configuration/guide/sec_mgmt_plane_prot.html#wp1049321