Network Addressing Plan
I am in the process of restructuring the company network from a 10.x.x.x network to a 172.16.x.x network. I found a number of addressing plans on the internet that talk about phases and how to plan, but it would be pretty legit to find an actual plan out there so I can read what someone else did in their planning.
Does anyone know where I can see an actual network addressing plan or template?
Also, should voice be on an entirely different subnet, be placed on static, QoS, etc.?
Thanks in advance!
Does anyone know where I can see an actual network addressing plan or template?
Also, should voice be on an entirely different subnet, be placed on static, QoS, etc.?
Thanks in advance!
ASKER
@peralsea
Sooo... this is what I have so far:
172.16.x.x
255.255.128.0 -for servers
255.255.192.0 -for users
172.16.0.1 - 0.254 - hosts, servers, AP's, printers, etc.
172.16.1.1 - 2.254 -PC's
172.16.3.1 - 3.254 -Voice
172.16.4.1 - 4.254 - VPN users
Does that jive with you?
.... we feel it is best to leave the 10.x.x.x network because we have two companies that merged and they both use the primary 10.x.x.x but then they have different subnets that overlap, combined with firewall rules, combined with IP conflicts, etc, we just feel it'd be easier to build a new network on the side and then bring everyone into the new plan/scheme.
Sooo... this is what I have so far:
172.16.x.x
255.255.128.0 -for servers
255.255.192.0 -for users
172.16.0.1 - 0.254 - hosts, servers, AP's, printers, etc.
172.16.1.1 - 2.254 -PC's
172.16.3.1 - 3.254 -Voice
172.16.4.1 - 4.254 - VPN users
Does that jive with you?
.... we feel it is best to leave the 10.x.x.x network because we have two companies that merged and they both use the primary 10.x.x.x but then they have different subnets that overlap, combined with firewall rules, combined with IP conflicts, etc, we just feel it'd be easier to build a new network on the side and then bring everyone into the new plan/scheme.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@craigbeck
Sorry if I made my intentions confusing....
172.16.0.1 - 0.254 - "hosts" is meant to be the blades (physical server) that the VM's are housed on.... so my listing should have said: blades, VM servers, printers, etc.
Am I wrong in this thought?...
I want the core devices to be on a /17 subnet and the PC's on a /18 so there isn't a broadcast storm.
... or would just subnetting them out fix that? or just put servers and PC's in different VLANs?
Sorry if I made my intentions confusing....
172.16.0.1 - 0.254 - "hosts" is meant to be the blades (physical server) that the VM's are housed on.... so my listing should have said: blades, VM servers, printers, etc.
Am I wrong in this thought?...
I want the core devices to be on a /17 subnet and the PC's on a /18 so there isn't a broadcast storm.
... or would just subnetting them out fix that? or just put servers and PC's in different VLANs?
No problem :-)
VLANs and subnets are different things. You need VLANs to separate broadcast domains, and subnets to make best use of IP addressing within your IP scheme. Each VLAN would usually have a unique subnet. It's physically possible to put more than one subnet in a VLAN, but it's not advisable.
So, you would typically need separate VLANs for:
Servers
Phones
PCs
iSCSI
Management
...
...
I would put blade servers (the host machines for your VMs) in the management network for simplicity.
A /17 is a massive range. That would give you 32766 hosts on that single subnet.
Look at my previous example. Those subnet masks give you plenty of scope to adjust as required and are typical based upon some of the customers I've worked with in the past.
VLANs and subnets are different things. You need VLANs to separate broadcast domains, and subnets to make best use of IP addressing within your IP scheme. Each VLAN would usually have a unique subnet. It's physically possible to put more than one subnet in a VLAN, but it's not advisable.
So, you would typically need separate VLANs for:
Servers
Phones
PCs
iSCSI
Management
...
...
I would put blade servers (the host machines for your VMs) in the management network for simplicity.
A /17 is a massive range. That would give you 32766 hosts on that single subnet.
Look at my previous example. Those subnet masks give you plenty of scope to adjust as required and are typical based upon some of the customers I've worked with in the past.
ASKER
@craigbeck
Ok, so tell me if this jives with you (took your suggestions and personalized):
Management network.... Do you mean like on a management vlan or the same subnet as the vm servers?
I would put blade servers (the host machines for your VMs) in the management network for simplicity.
Ok, so tell me if this jives with you (took your suggestions and personalized):
Base IP: 172.16.0.0 / 255.255.0.0
Range: 172.16.0.0 - 172.16.255.255
172.16.0.0 / 255.255.255.0 - servers, blades, router, etc.
172.16.1.0 / 255.255.240.0 - PC's
172.16.50.0 / 255.255.255.0 - Phones
172.16.200.0 / 255.255.255.0 - VPN
Range: 172.16.0.0 - 172.16.255.255
172.16.0.0 / 255.255.255.0 - servers, blades, router, etc.
172.16.1.0 / 255.255.240.0 - PC's
172.16.50.0 / 255.255.255.0 - Phones
172.16.200.0 / 255.255.255.0 - VPN
Not bad, but 172.16.1.0 / 255.255.240.0 overlaps with the servers as it actually covers 172.16.0.0 - 172.16.15.255
So you'd be able to use 172.16.0.0 / 255.255.255.0 for servers then 172.16.16.0 255.255.240.0 for PCs.
So you'd be able to use 172.16.0.0 / 255.255.255.0 for servers then 172.16.16.0 255.255.240.0 for PCs.
Separating subnets makes management easier at the edge, as well from a visual monitoring perpective.
Not sure why you are moving or transitioning from your 10.x.x.x scheme to a 172.16.x.x scheme but okay...
voice = one or two subnets
servers = one or two subnets
management = one or two subnets
iSCSI - on it's own subnet
Clients on there own networks
so on and so forth...for my client networks I have broken it up by building or wing that also helps with management and troubleshooting...plus security boundaries.