What is best practice to use subnetting vs vlans and trunking? For a smaller network with approx 30-40 servers and 7subnets, is it a better topology to use a layer 3 switch with trunking to segment the network or subnet thru the fw or switch and run layer 2 swiches to each subnet?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Subnetting vs. vlans best practice
- Thread starter Jasonlees
- Start date
VinceWhirlwind
Technical User
Using VLANs for "security" was an old talking-point you probably still find in the textbooks where they used to display a network diagram segmented into "Sales", "Accounting", etc....
This model was in fact made obsolete when Windows NT came out and offered much better ways of controlling access to network resources. And since AD it is even less relevant to talk about VLANs in terms of "security".
Nowadays, you are advised to *not* span the same VLAN widely around your network. In fact, spanning multiple VLANs across multiple switches is (according to the new-fangled textbooks) an excellent way to facilitate "VLAN-hopping".
So I would tend to agree that VLANs are not there for "security". If I have networks at different security classifications, I separate them physically, with a proper firewall between.
If VLAN separation gives me added security, that's a bonus and a secondary consideration.
This model was in fact made obsolete when Windows NT came out and offered much better ways of controlling access to network resources. And since AD it is even less relevant to talk about VLANs in terms of "security".
Nowadays, you are advised to *not* span the same VLAN widely around your network. In fact, spanning multiple VLANs across multiple switches is (according to the new-fangled textbooks) an excellent way to facilitate "VLAN-hopping".
So I would tend to agree that VLANs are not there for "security". If I have networks at different security classifications, I separate them physically, with a proper firewall between.
If VLAN separation gives me added security, that's a bonus and a secondary consideration.
Vince,
good point. What would you (or the other guys) advice in our situation:
We use mulitple vlans in our core and workgroupswitches.
Mainly for reducing broadcasts.
But the point is: we also have a DMZ. Would you advice to connect the servers within that DMZ on a second, seperate, switch which is directly connected on the dmz port of the firewall?
Or is it save to use a non-routable vlan on the core, as the dmz vlan. (For us that would be the best way, less equipment and uniform administration).
But what do the experts say?
good point. What would you (or the other guys) advice in our situation:
We use mulitple vlans in our core and workgroupswitches.
Mainly for reducing broadcasts.
But the point is: we also have a DMZ. Would you advice to connect the servers within that DMZ on a second, seperate, switch which is directly connected on the dmz port of the firewall?
Or is it save to use a non-routable vlan on the core, as the dmz vlan. (For us that would be the best way, less equipment and uniform administration).
But what do the experts say?
Good point on VLAN hoping. Due to a new core firewall requirement I'm hoping to grab the oppertunity to tweak the network a bit. All this input is useful I've already got a plan in mind.
meneerB - Your non-routable VLAN is similar to how I am setup atm (only accessible via the FW) I guess. I'm doing a gear check to see if I can physically seperate them as an extra bit of work for the above reason. I do enjoy playing around with the design bit
.
meneerB - Your non-routable VLAN is similar to how I am setup atm (only accessible via the FW) I guess. I'm doing a gear check to see if I can physically seperate them as an extra bit of work for the above reason. I do enjoy playing around with the design bit
.
VinceWhirlwind
Technical User
A DMZ is an excellent example of a network which should be *physically* separated from your internal LANs.
If you absolutely *must* use the same physical network to carry DMZ and internal LANs, then I would at least keep the DMZ VLAN off your L3 switches - DMZ should have its own L3 device (a firewall).
If you absolutely *must* use the same physical network to carry DMZ and internal LANs, then I would at least keep the DMZ VLAN off your L3 switches - DMZ should have its own L3 device (a firewall).
Vince, I'm confused: a DMZ does not need a L3 switch, it needs a layer 2 switch and a firewall for the fw-rules and routing.
So the question is: if you use the internal L3 LAN switch for internal traphic and an isolated vlan for the DMZ, what problem is there?
(besides making a mistake configuring a dmz vlan on a wrong interface)
So the question is: if you use the internal L3 LAN switch for internal traphic and an isolated vlan for the DMZ, what problem is there?
(besides making a mistake configuring a dmz vlan on a wrong interface)
HungryHouse
Vendor
MeneerB,
We have had several customers who have used one Layer 2 switch with correct VLAN segmentation to carve up public, private and DMZ traffic by merely making access VLANs for the convenience of not having to purchase, find room for, and manage more hardware...especially given the fact that the number of interfaces on todays 1U/2U switches are so plentiful, it seems like a waste not to use them.
From a security and fault tolerance perspective however, this is not a wise idea in my humble opinion.
1-If your switch is compromised, you will have a mess on your hands.
2-If your switch is misconfigured you will have a mess on your hands.
3-The largest problem in this design is the switch becomes a single point of failure. The common scenario of the switch going down leaves you with no outbound or inbound Internet services. This did happen with one of our customers in a campus envrionment, and of course, he did not have a backup config saved, so we had to recreate on another switch on the fly (yeah that was a fun one since he had 3 different ISPs!! woohoo...party time at midnight to 3AM!). This was a disaster.
My recommendation is although it can be done, stay away from it, as each zone...DMZ, PUBLIC and PRIVATE should be kept truly separate (including the hardware off of each zone..the switch included).
It is preferred to have direct interfaces on the firewall for this purpose, and if that's not feasible, then use a separate switch for your DMZ traffic..keeping a spare handy and closeby!
It is tempting and has become too common, however, the "convenience" of carving up a switch for this purpose is not worth it in the end because the risk is too great.
Not best practice.
Real trouble call:
Customer: "I have a huge problem. A friend has put a screensaver on my computer, but every time I move the mouse, it disappears!"
We have had several customers who have used one Layer 2 switch with correct VLAN segmentation to carve up public, private and DMZ traffic by merely making access VLANs for the convenience of not having to purchase, find room for, and manage more hardware...especially given the fact that the number of interfaces on todays 1U/2U switches are so plentiful, it seems like a waste not to use them.
From a security and fault tolerance perspective however, this is not a wise idea in my humble opinion.
1-If your switch is compromised, you will have a mess on your hands.
2-If your switch is misconfigured you will have a mess on your hands.
3-The largest problem in this design is the switch becomes a single point of failure. The common scenario of the switch going down leaves you with no outbound or inbound Internet services. This did happen with one of our customers in a campus envrionment, and of course, he did not have a backup config saved, so we had to recreate on another switch on the fly (yeah that was a fun one since he had 3 different ISPs!! woohoo...party time at midnight to 3AM!). This was a disaster.
My recommendation is although it can be done, stay away from it, as each zone...DMZ, PUBLIC and PRIVATE should be kept truly separate (including the hardware off of each zone..the switch included).
It is preferred to have direct interfaces on the firewall for this purpose, and if that's not feasible, then use a separate switch for your DMZ traffic..keeping a spare handy and closeby!
It is tempting and has become too common, however, the "convenience" of carving up a switch for this purpose is not worth it in the end because the risk is too great.
Not best practice.
Real trouble call:
Customer: "I have a huge problem. A friend has put a screensaver on my computer, but every time I move the mouse, it disappears!"
HungryHouse,
thanks for your comment. You are absolutely right about those points. I allways like to look at things from several angles. And the easiest way is to comment on all your points.
Lets see where the ship will sink (thats what we say overhere BTW
1- thats something I cannot argue.
We have several internal DMZs, a public DMZ, a private lan and no public lan.
As long as we have a Public DMZ, I agree about this point. But... (see Checkpoint comment below)
2. I agree
3. Backup and redundancy is our primairy concern.
So I have a schedule to daily backup the config of all switches. Now I don't have to come out of my bed in the middle of the night..
Secondly, our core has 2 supervisor blades.
This box is to be replaced. We are thinking about a new one with 2 hotstandby supervisors or 2 smaller chassis.
All our important servers and internetaccess routers have 2 uplinks to the core.
That leaves us at the moment to one FW and a the single switchblades.
So, if something fales, it's no disaster...
Firewalls: faster troughput is needed (not 100mb ports, but gb)
So we could buy a gigabit fw, or a Checkpoint applicance.
We use VMWare ESX more and more. We have a cluster and a SAN. Fully redundant.
And now Checkpoint does have a FW applicance for ESX...
Hmm, isn't this a complete end of the disscussion and trow any comments in the trashcan?
(I must say, I love the idea)
thanks for your comment. You are absolutely right about those points. I allways like to look at things from several angles. And the easiest way is to comment on all your points.
Lets see where the ship will sink (thats what we say overhere BTW
1- thats something I cannot argue.
We have several internal DMZs, a public DMZ, a private lan and no public lan.
As long as we have a Public DMZ, I agree about this point. But... (see Checkpoint comment below)
2. I agree
3. Backup and redundancy is our primairy concern.
So I have a schedule to daily backup the config of all switches. Now I don't have to come out of my bed in the middle of the night..
Secondly, our core has 2 supervisor blades.
This box is to be replaced. We are thinking about a new one with 2 hotstandby supervisors or 2 smaller chassis.
All our important servers and internetaccess routers have 2 uplinks to the core.
That leaves us at the moment to one FW and a the single switchblades.
So, if something fales, it's no disaster...
Firewalls: faster troughput is needed (not 100mb ports, but gb)
So we could buy a gigabit fw, or a Checkpoint applicance.
We use VMWare ESX more and more. We have a cluster and a SAN. Fully redundant.
And now Checkpoint does have a FW applicance for ESX...
Hmm, isn't this a complete end of the disscussion and trow any comments in the trashcan?
(I must say, I love the idea)
I have run into these problems in my own environment. Specifically the DMZ on the L3 core switch. DMZ comes off a spare interface on our FW into a dedicated vlan on our L3 switch. Currently only 2 ports in that vlan for 2 wireless AP's. Whats the point in having a 8 port switch in the rack for just those 2 interfaces?
- Status
Similar threads
- Locked
- Question