asked on
How to make several class C networks with the same gateway
I am not strong in subnets and am now in a bit of a pickle.
When I started here they were running 10.10.10.x with everything on this network. We have grown much larger and there was a lack of planning in the beginning.
We have a sonicwall that now has 3 interfaces on it, 10.10.10.x, 10.10.1.x and 10.10.2.x these are physically assigned, they all work, they all route.
I am now faced with 2-3 more subnets inside our network, perhaps more in the future.
SO....
It makes more sense to me to make a class B and then build some class Cs inside that. However I am not familiar on how to do this.
What would be nice, is to have a single gateway assigned to a physical interface on my sonicwall and just to adjust subnet mask and IP on the devices,
As an example.
All Switches and routers in 172.16.0.1-254
All Servers in 172.16.1.1-254
All Workstations in 172.16.2.1-254
I have to apologize, I have been an IT guy a very long time, but mostly in the small business arena and 95% of them run class C networks in the 192.168.0.x range off some type of Linksys box.
I have the ability to make a new interface on the sonicwall and migrate all the other stuff over to the new schema.
When I started here they were running 10.10.10.x with everything on this network. We have grown much larger and there was a lack of planning in the beginning.
We have a sonicwall that now has 3 interfaces on it, 10.10.10.x, 10.10.1.x and 10.10.2.x these are physically assigned, they all work, they all route.
I am now faced with 2-3 more subnets inside our network, perhaps more in the future.
SO....
It makes more sense to me to make a class B and then build some class Cs inside that. However I am not familiar on how to do this.
What would be nice, is to have a single gateway assigned to a physical interface on my sonicwall and just to adjust subnet mask and IP on the devices,
As an example.
All Switches and routers in 172.16.0.1-254
All Servers in 172.16.1.1-254
All Workstations in 172.16.2.1-254
I have to apologize, I have been an IT guy a very long time, but mostly in the small business arena and 95% of them run class C networks in the 192.168.0.x range off some type of Linksys box.
I have the ability to make a new interface on the sonicwall and migrate all the other stuff over to the new schema.
TCP/IPNetwork Architecture
Last Comment
wlacroix
ASKER
Segregation and broadcast storm protection.
The original idea to have the 10.10.2.x network was for wireless only, to limit their touching of our core network, then we flipped because we ran out of IP addresses on the 10.10.10.x network. Then we introduced VOIP which now runs on 10.10.1.x network and is vlanned off.
I need more networks and the sonicwall will eventually run out of interfaces to build class C networks on. It has 6 interfaces of which 4 are now in use. I have the need for another network right now, and could easily build it as a class C off of a sonicwall interface. But what happens in a year or two when I need another few networks?
There is already talk of 2-3 networks in our plant running different things.
The original idea to have the 10.10.2.x network was for wireless only, to limit their touching of our core network, then we flipped because we ran out of IP addresses on the 10.10.10.x network. Then we introduced VOIP which now runs on 10.10.1.x network and is vlanned off.
I need more networks and the sonicwall will eventually run out of interfaces to build class C networks on. It has 6 interfaces of which 4 are now in use. I have the need for another network right now, and could easily build it as a class C off of a sonicwall interface. But what happens in a year or two when I need another few networks?
There is already talk of 2-3 networks in our plant running different things.
ASKER
One of the issues is simply the number of nodes on a subnet, as an example our 10.10.10.x network runs all servers and workstations, but this is full.
I would love to pull servers out of that network onto their own network, and move all of the VMware\management of blades and what not onto their own network.
With that said, I am by far out of interfaces on the sonicwall
I would love to pull servers out of that network onto their own network, and move all of the VMware\management of blades and what not onto their own network.
With that said, I am by far out of interfaces on the sonicwall
ASKER
To boot, all of our branch networks are in the 10.10.x.x class C networks.
we run from 10.10.10.x to 10.10.110.x
we run from 10.10.10.x to 10.10.110.x
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Mugojava,
This is my understanding as well.
So I have 3 interfaces on my sonicwall configured as 10.10.1.x, 10.10.2.x and 10.10.10.x
With tihs 172.16.x.x with the subnet suggested 255.240.0.0
Can you show me what some of the network layouts would look like from the top down.
Say Sonicwall interface configured with 172.16.0.1 on 255.240.0.0
What would my networks look like?
Network 1 =
172.16.1.1 - 172.16.1.254? with a subnet of 255.240.0.0 and a gateway of 172.16.0.1?
Unfortunately 90% of this stuff is static, and it will take us a while to deal with it, but in the end, it should be much better.
This is my understanding as well.
So I have 3 interfaces on my sonicwall configured as 10.10.1.x, 10.10.2.x and 10.10.10.x
With tihs 172.16.x.x with the subnet suggested 255.240.0.0
Can you show me what some of the network layouts would look like from the top down.
Say Sonicwall interface configured with 172.16.0.1 on 255.240.0.0
What would my networks look like?
Network 1 =
172.16.1.1 - 172.16.1.254? with a subnet of 255.240.0.0 and a gateway of 172.16.0.1?
Unfortunately 90% of this stuff is static, and it will take us a while to deal with it, but in the end, it should be much better.
If you build VLANs, the L3 switch can be the gateway, having an IP of each VLAN. That way you can indeed segregate to full extend, and the switch using VLANs helps to keep the networks separated.
But on the other hand I do not see much issues with a /22 subnet.
But on the other hand I do not see much issues with a /22 subnet.
ASKER
Qlemo,
This is how we built our voice vlan, but it still has a physical interface on the sonicwall. I guess that is not required and you would point the devices to the IP that is assigned on the vlan inside the layer 3 switch correct?
I think vlan creates a complexity that is unrequired, but I am not as educated in this area as the two of you.
This is how we built our voice vlan, but it still has a physical interface on the sonicwall. I guess that is not required and you would point the devices to the IP that is assigned on the vlan inside the layer 3 switch correct?
I think vlan creates a complexity that is unrequired, but I am not as educated in this area as the two of you.
If your sonicwall is configured with 172.16.0.1 /16 (255.240.0.0), and this is your gateway interface for your Lan, then ANY Ip on any device connected, and with VLAN access to the ip block if applicable, that uses 172.16.0.1 as the gateway, has any 172.16.x.x IP assinged, and also has the 255.240.0.0 NW Mask (or it's /12 counterpart CIDR) will be able to talk to the gateway.
If you juggle class C's primarily, then it will also seem strange that, say, 172.16.1.0 is a usable host IP. Your only two non-usable IPs will be 172.16.0.0 (network marker) and 172.16.255.255 (broadcast). All others, from 172.16.0.1 to 172.16.255.254 are usable IPs, even those ending in .0 and .255. I find "Class C" guys have a little bit of trouble with that, as they are so use to .0 and .255 always being a network marker / BC address, respectively.
Other than a lot of legwork (and by legwork, I mean fingers flying), it's very straight forward, and does away with much routing. And, as you have stated, you can select certain ranges for equipment / switches, servers, workstations, wireless, etc.
If you juggle class C's primarily, then it will also seem strange that, say, 172.16.1.0 is a usable host IP. Your only two non-usable IPs will be 172.16.0.0 (network marker) and 172.16.255.255 (broadcast). All others, from 172.16.0.1 to 172.16.255.254 are usable IPs, even those ending in .0 and .255. I find "Class C" guys have a little bit of trouble with that, as they are so use to .0 and .255 always being a network marker / BC address, respectively.
Other than a lot of legwork (and by legwork, I mean fingers flying), it's very straight forward, and does away with much routing. And, as you have stated, you can select certain ranges for equipment / switches, servers, workstations, wireless, etc.
ASKER
Mugojava you are right is class c guys go HUH WHAT? hahhaa.
Ok Let me recap here, and regurgitate the info...
I will configure my sonicwall with 172.16.0.1 with a subnet of 255.240.0.0
Giving me all usable addresses from 172.16.0.2 (only cause I stole the first one for the gateway) to 172.16.255.254 leaving out the last .255 (broadcast)
Now from my understanding this is one giant subnet with NO broadcast storm protection, is this correct?
If say a device on 172.16.44.4 goes squirrely and starts chattering like a demon....then what?
Ok Let me recap here, and regurgitate the info...
I will configure my sonicwall with 172.16.0.1 with a subnet of 255.240.0.0
Giving me all usable addresses from 172.16.0.2 (only cause I stole the first one for the gateway) to 172.16.255.254 leaving out the last .255 (broadcast)
Now from my understanding this is one giant subnet with NO broadcast storm protection, is this correct?
If say a device on 172.16.44.4 goes squirrely and starts chattering like a demon....then what?
As I've said already, you can't use a gateway outside of your subnet.
To divide into subnets only logically won't have the desired effect. A L2 broadcast is still a broadcast, and the switch will send that out to all ports. Unless it knows better - by using VLANs. Or separate switches for each subnet.
Also, imagine you want to have traffic between Client CA (subnet 2) and Server SA (subnet 1). Because both subnets are not the same, traffic has to be routed - CA -> Router -> SA -> Router -> CA.
You are not reducing traffic, but increasing it instead that way, because all traffic is still on the same physical network.
To divide into subnets only logically won't have the desired effect. A L2 broadcast is still a broadcast, and the switch will send that out to all ports. Unless it knows better - by using VLANs. Or separate switches for each subnet.
Also, imagine you want to have traffic between Client CA (subnet 2) and Server SA (subnet 1). Because both subnets are not the same, traffic has to be routed - CA -> Router -> SA -> Router -> CA.
You are not reducing traffic, but increasing it instead that way, because all traffic is still on the same physical network.
The above said answers your last question too, but to put it straight - you are correct, no broadcast protection on that suggested setup.
ASKER
How do you deal with chatty devices, say PLC or VDL drives connected to an automated production line, the traffic in this case is massive, 10mbit sustained in my case.
Or lets say segregation of your VMware management network vs the rest of the network?
If you loose the network to a broadcast storm you could be in real trouble.
How do I build in protection in the scenario above vlans?
(THIS WAS ANSWERED IN YOUR POST SORRY)
My immediate thought is to use the scenario above for say workstations\printers\wire
Or lets say segregation of your VMware management network vs the rest of the network?
If you loose the network to a broadcast storm you could be in real trouble.
How do I build in protection in the scenario above vlans?
(THIS WAS ANSWERED IN YOUR POST SORRY)
My immediate thought is to use the scenario above for say workstations\printers\wire
As long as you have very few networks to segregate, doing it physically (and hence requiring multiple interfaces on device needing to have connection to more than one network) is the most easy solution. The firewall can also know about "interesting" traffic much better that way, and have appropriate firewall rules (e.g. for a DMZ, a high-protection closed server network, a more open WLAN network - different rules, different purposes, different restrictions).
As soon as you have a bigger network with video surveillance, access control devices, automated data aquisition, ERP, QA department, HR department, ... it gets interesting, and you need to consider VLANs very seriously.
As soon as you have a bigger network with video surveillance, access control devices, automated data aquisition, ERP, QA department, HR department, ... it gets interesting, and you need to consider VLANs very seriously.
Conceptually, you might create as many LANs / subnets as you need and route with no NAT each into another where the gateway resides. That way, each subnet would have its own gateway that would feed the single internet gateway.
Example: Internet gateway is 10.10.10.1 on "LAN1" at the "top level".
Subnet 10.10.1.0 would have a router with (e.g.) 10.10.1.1 on one side and (e.g.) 10.10.10.2 on the other side with a route to 0.0.0.0 pointing to 10.10.10.xxx and gateway 10.10.10.1.
Subnet 10.10.2.0 would have a router with (e.g.) 10.10.2.1 on one side and (e.g.) 10.10.10.3 on the other side with a route to 0.0.0.0 pointing to 10.10.10.xxx and gateway 10.10.10.1.
Then, if you want inter-subnet traffic you could add routes for those as well.
e.g.:
from 10.10.1.0 route 10.10.2.0 to 10.10.10.3
etc.
The router at 10.10.10.1 would have routes:
10.10.1.0 to 10.10.10.2
10.10.2.0 to 10.10.10.3
etc.
Now, if you have equipment that will do the same thing with VLANs then fine. But this seems a clean way to understand what's supposed to go on.
Example: Internet gateway is 10.10.10.1 on "LAN1" at the "top level".
Subnet 10.10.1.0 would have a router with (e.g.) 10.10.1.1 on one side and (e.g.) 10.10.10.2 on the other side with a route to 0.0.0.0 pointing to 10.10.10.xxx and gateway 10.10.10.1.
Subnet 10.10.2.0 would have a router with (e.g.) 10.10.2.1 on one side and (e.g.) 10.10.10.3 on the other side with a route to 0.0.0.0 pointing to 10.10.10.xxx and gateway 10.10.10.1.
Then, if you want inter-subnet traffic you could add routes for those as well.
e.g.:
from 10.10.1.0 route 10.10.2.0 to 10.10.10.3
etc.
The router at 10.10.10.1 would have routes:
10.10.1.0 to 10.10.10.2
10.10.2.0 to 10.10.10.3
etc.
Now, if you have equipment that will do the same thing with VLANs then fine. But this seems a clean way to understand what's supposed to go on.
ASKER
Sorry guys was out for a few days.
This does make some sense. Having a 172 (this gives me more than enough IPs inside my network to deal with) at the top and using vlans to deal with chatty stuff.
I don't think that said chatty stuff ever needs to go out to the internet per se (will have to check with the teams on this) and they could be on anything even a 192.168 network, vlanned off right at my core 5412zl.
Where the gateway of the devices on say the 192 network, would be the IP assigned to the vlan on the core switch correct.
On a side note, can I vlan off part of the 172 network? say for HR, instead of using a different "C" like a 192.168.x.x?
I am trying to put together a plan, that encompasses long term growth.
This does make some sense. Having a 172 (this gives me more than enough IPs inside my network to deal with) at the top and using vlans to deal with chatty stuff.
I don't think that said chatty stuff ever needs to go out to the internet per se (will have to check with the teams on this) and they could be on anything even a 192.168 network, vlanned off right at my core 5412zl.
Where the gateway of the devices on say the 192 network, would be the IP assigned to the vlan on the core switch correct.
On a side note, can I vlan off part of the 172 network? say for HR, instead of using a different "C" like a 192.168.x.x?
I am trying to put together a plan, that encompasses long term growth.
What do you think you gain by subnetting?