The IP addressing conversation comes up on every deployment. Not always at the right time. I have walked into more than a few projects mid-installation where nobody had planned the addressing scheme and the team was handing out addresses verbally as devices came out of boxes. The cabling is done, the cameras are going up, and someone is keeping track of what went where in a sticky note on the switch cabinet. It works until it does not.
This is not a certification study guide. It is a practical reference for integrators who need to plan, document, and commission physical security networks. If the concepts feel familiar but your projects end up with address conflicts, overlapping subnets, or documentation that nobody can read a year later, this should help close those gaps.
Why the Physical Layer Starts at the IP Layer
Every device on a security network needs an address. Cameras, access control panels, door controllers, intercoms, recording servers, management workstations, switches, firewalls. All of it. The addresses need to be planned before the installation starts, not sorted out when you are already on site.
An unplanned addressing scheme creates problems that compound. Conflicts when devices come online. Subnets too small to accommodate the final device count. Ranges that overlap when you segment into VLANs later. Cameras that need to be re-addressed mid-installation because someone used the range you needed for something else. And a year down the road, when something breaks or needs to change, nobody knows what is at which address without tracing physical cables.
None of that is necessary. The planning takes maybe an hour on a mid-sized project. It saves considerably more than that when something goes wrong.
The Three Private Address Ranges
IP addresses used on internal networks come from three ranges defined in RFC 1918. They are called private address ranges because they are not routed on the public internet. You can use any of them on an internal network without conflict with anything outside your building.
| Range | From | To | CIDR | Addresses |
|---|---|---|---|---|
| Class A | 10.0.0.0 | 10.255.255.255 | /8 | 16,777,216 |
| Class B | 172.16.0.0 | 172.31.255.255 | /12 | 1,048,576 |
| Class C | 192.168.0.0 | 192.168.255.255 | /16 | 65,536 |
For any physical security deployment with more than a handful of devices, use the 10.0.0.0/8 range. It gives you the most flexibility. You can create hundreds of distinct subnets without running out of space, which matters as soon as you start segmenting into VLANs for cameras, access control, management, and systems.
The 192.168.x.x range is fine for home networks and small single-VLAN deployments. On anything with multiple segments, it becomes a constraint. The 172.16.x range is valid but frequently causes confusion – many people do not immediately recognize it as a private range, which causes problems when you are troubleshooting routing with someone who does not know what they are looking at.
Use 10.x.x.x. It is the right answer for this environment.
Subnet Masks and CIDR: The Practical Explanation
A subnet mask tells the network equipment which portion of an IP address identifies the network and which portion identifies the individual device. That is the whole job. Nothing more complicated than that.
CIDR notation counts the number of bits used for the network portion. The address 10.42.67.47/24 means 24 bits are the network, 8 bits identify the host. The breakdown looks like this:
The /24 mask gives you 254 usable addresses in a subnet. For most security VLANs on a single site, that is the right size. Large enough to accommodate cameras, servers, spares, and future growth. Simple enough to remember and document.
A /25 gives you two ranges of 126 hosts each. A /26 gives you four ranges of 62 hosts each. You can go smaller if you need to – a /29 gives you only 6 usable addresses and is appropriate for a management VLAN where only switches and infrastructure devices will live. Going smaller than /24 for production device VLANs is usually not worth the complexity on a physical security deployment.
One thing that catches people: the first and last address in every subnet are reserved. .0 is the network address. .255 is the broadcast address. Neither can be assigned to a device. Your 254 usable addresses run from .1 through .254.
An Addressing Scheme That Actually Holds Together
Here is the scheme I use on most mid-sized security deployments. It is not magic – it is just consistent.
Format: 10.<site>.<vlan>.<device>
The site octet is a number from 1 to 254. Each physical site gets its own number. If you only have one site, use 1. If you have ten sites, number them. The VLAN octet matches the VLAN ID, which ties your IP scheme directly to your network segmentation plan. The device octet is the individual address.
The readability of this scheme is the point. When you see 10.3.101.47 in a switch log, you know it is a camera at site 3 without looking anything up. When a device shows up in a Wireshark capture or a Genetec health monitor, the address tells you exactly what it is and where it lives.
Within each /24, reserve addresses by function:
- .254, Default gateway (the firewall or L3 switch interface for this VLAN)
- .253 descending, Network infrastructure (switch SVIs, management interfaces) (secondary switches, management interfaces)
- .11 through .50, Servers, recording systems, static infrastructure
- .50 through .99, Reserved for future growth
- .100 through .254, Cameras, panels, field devices
Static vs DHCP: The Security Network Position
Use static addresses for everything on a physical security network.
DHCP is convenient for user workstations where addresses change and the specific address does not matter. On a security network, you want to know exactly what is at every address. When a camera drops off at 3 AM and you are troubleshooting in the morning, you should be able to look up the address in your documentation and know which camera it is, where it is physically installed, and which switch port it connects to.
DHCP on a camera network means you might see a camera stop recording and not be able to cross-reference the device in your NVR with anything in your switch logs. The lease expired, the address changed, your documentation is now wrong, and you are tracing cables to figure out what is what.
DHCP reservations are an acceptable middle ground if you are forced to use a DHCP server. A reservation ties a specific MAC address to a specific IP address. The device always gets the same address, and the DHCP server is the management point. The downside is that reservations take about the same time to set up as static addressing on a large deployment, and they introduce a dependency on the DHCP server – if it is unavailable, newly connected or rebooted devices may not get addresses.
The documentation is as important as the address. A spreadsheet with every device, its address, its MAC address, its physical location, and its switch port assignment is not optional. It is how you service the system in two years when nobody on the current team is around to explain it.
Gateway Addressing
The gateway is the device that routes traffic between subnets – usually a firewall or a Layer 3 switch. Pick a convention for the gateway address and use it consistently across all subnets.
I use .254 for the gateway on every subnet. So:
10.1.99.254, Gateway for the management VLAN10.1.100.254, Gateway for the systems VLAN10.1.101.254, Gateway for the camera VLAN10.1.102.254, Gateway for the access control VLAN
Some engineers prefer .1. Either works. The important thing is that it is the same on every subnet so you are not looking it up every time you configure a device.
Common Mistakes
Using 192.168.1.x for everything. Works fine until you need a second VLAN. Then you either create confusing address ranges or you are re-addressing the whole site.
Not planning for growth. The client has 40 cameras today. The contract mentions potential future phases. A /24 gives you room. A /27 with 30 addresses does not.
Assigning .254 to a device. That is your gateway address. Reserve it. A camera at .254 and the Layer 3 switch interface trying to own .254 at the same time is a conflict you will troubleshoot at the worst possible moment.
Inconsistent documentation. The IP scheme is only useful if it is documented accurately and updated when things change. A spreadsheet that was accurate at commissioning and has not been touched since is a liability, not an asset. Make documentation part of the commissioning process, not an afterthought.
Segmenting the network without coordinating the IP scheme. Your addressing and your VLAN design should be planned together. If you know you will have four VLANs, allocate four subnets from the start. Retrofitting an addressing scheme after the VLANs are already up is avoidable extra work.
Where This Leads
IP addressing is the foundation. The next layer is segmentation – deciding which devices go on which network and why. A well-planned address scheme makes the segmentation work easier, because the addressing tells you at a glance what is what. The next post covers VLAN segmentation specifically: what it does, how to design a scheme for a physical security deployment, and how to explain it to a client who does not understand why they need it.
One consideration that comes up on larger camera deployments: multicast. When multiple operator workstations are watching the same live streams, multicast sends the stream once from the Archiver and replicates it at the network layer rather than sending individual unicast streams to each client. It reduces bandwidth significantly at scale but requires proper IGMP snooping and PIM configuration on the switching infrastructure. Worth planning for if your design includes more than a handful of simultaneous viewer seats.
If you have questions or want to talk through an addressing scheme for a specific project, reach out through the site.