We have a medium sized network of around 200 nodes and are currently in the process of replacing old daisy chained switches with stack-able or chassis style switches. Right now our network is broken up via subnet; production, management, IP, etc each on a separate subnet. Does anyone have an opinion on whether creating Vlan's instead of subnets would be more beneficial? Our general goal is to prevent bottlenecks, separate traffic for security, and to manage traffic with more ease.

VLAN 10, you may have the subnet 192.168.54.x/24
VLAN 11, you may have the subnet 192.168.55.x/24

And so on

This would require that you have a router within your network, though

It's kind of up to you what route you go down (You know your network better than I ever will). If you think that the size of your broadcast domain will be some kind of issue, then use VLANs. If you think that the size of your network management domains (for instance, your management network) then possibly use a network closer to a /16 over a /24

Your 200 nodes will fit into a /24, but that obviously doesn't give you much scope for growth

By the sound of it, you're already using different subnets for different device types. So, why not stick with that? You could, if you wanted, tie each subnet to a VLAN. Layer 2 segmentation will result in the behaviour of your network changing from how it behaves currently though

+1 - Said almost everything I wanted to. If you were going to scrap the current subnetting design you have, my only additional suggestion would be to explore setting up an address space using a /22 or /23. Possibly "remove" bits if you find you need more subnets. After all, we're not just limited to /16 or /24 anymore. Then, put each subnet in its own VLAN to cut down on broadcast traffic.
–
romandasAug 14 '09 at 21:59

(I've been on the road all day and missed jumping on this one... Still, late to the game I'll see what I can do.)

Typically you create VLANs in Ethernet and map IP subnets 1-to-1 onto them. There are ways not to do this, but sticking in a strictly "plain vanilla" world you'd create a VLAN, think up an IP subnet to use in the VLAN, assign some router an IP address in that VLAN, attach that router to the VLAN (either with a physical interface or a virtual subinterface on the router), connect some hosts to the VLAN and assign them IP addresses in the subnet you defined, and route their traffic in and out of the VLAN.

You shouldn't start subnetting an Ethernet LAN unless you have good reasons to do it. The best two reasons are:

Mitigating performance problems. Ethernet LANs can't scale indefinitely. Excessive broadcasts or flooding of frames to unknown destinations will limit their scale. Either of these conditions can be caused by making a single broadcast domain in an Ethernet LAN too big. Broadcast traffic is easy to understand, but flooding of frames to unknown destinations is a bit more obscure. If you get so many devices that your switch MAC tables are overflowing switches will be forced to flood non-broadcast frames out all ports if the destination of the frame doesn't match any entries in the MAC table. If you have a large enough single broadcast domain in an Ethernet LAN with a traffic profile that hosts talk infrequently (that is, infrequently enough that their entries have aged out of the MAC tables on your switches) then you can also get excessive flooding of frames.

A desire to limit / control traffic moving between hosts at layer 3 or above. You can do some hackery examining traffic at layer 2 (ala Linux ebtables) but this is difficult to manage (because rules are tied to MAC addresses and changing out NICs necessitates rule changes) can cause what appear to be really, really strange behaviors (doing transparent proxying of HTTP at layer 2, for example, is freaky and fun, but is utterly un-natural and can be very non-intuitive to troubleshoot), and is generally difficult to do at lower layers (because layer 2 tools are like sticks and rocks at dealing with layer 3+ concerns). If you want to control IP (or TCP, or UDP, etc) traffic between hosts, rather than attacking the problem at layer 2, you should subnet and stick firewalls / routers with ACLs between the subnets.

Bandwidth exhaustion problems (unless they're being caused by broadcast packets or flooding of frames) are not solved with VLANs and subnetting typically. They happen because of a lack of physical connectivity (too few NICs on a server, too few ports in an aggregation group, the need to move up to a faster port speed) and can't be solved by subnetting or deploying VLANs since that won't increase the amount of bandwidth available.

If you don't have even something simple like MRTG running graphing per-port traffic statistics on your switches that's really your first order of business before you start potentially introducing bottlenecks with well-intentioned but uninformed subnetting. Raw byte counts are a good start, but you should follow it up with targeted sniffing to get more details about the traffic profiles.

Once you know how traffic moves around on your LAN you can begin to think about subnetting for performance reasons.

As far as "security" goes you're going to need to know a lot about your application software and how it talks before you can proceed.

I did a design for a resonably sized LAN/WAN for a medcial Customer a few years ago and I was asked to put access lists on the layer 3 entity (a Cisco Catalyst 6509 supervisor module) to control traffic moving between the subnets by an "engineer" who had little understanding of what kind of legwork it would actually require but was very interested in "security". When I came back with a proposal to study each application to determine the necessary TCP/UDP ports and destination hosts I got a shocked response from the "engineer" stating that it shouldn't be that difficult. The last that I heard they're running the layer 3 entity with no access lists because they couldn't get all their software working reliably.

The moral: If you're really going to try and button down packet and stream-level access between VLANs be prepared to do a lot of legwork with application software and learning / reverse-engineering how it talks over the wire. Limiting access by hosts to servers can often be accomplished with filtering functionality on the servers. Limiting access on the wire can provide a false sense of security and lull administrators into a complacency where they think "Well, I don't need to configure the app. securely because the hosts that can talk to the app. are limited by 'the network'." I'd encourage you to audit the security of your server configuration before I'd start limiting host-to-host communication on the wire.

i'm glad to see some voice of reason after answers advising to go /16.
–
pQdAug 15 '09 at 10:50

3

You can subnet into arbitrarily large or small subnets. The number of hosts in the subnet / broadcast domain is what matters, not the number of possible hosts (so long as you have enough address space). What's the expression-- it's not the size of your subnet that matters, but rather how you use it? >smile<
–
Evan AndersonAug 15 '09 at 13:29

@Evan Anderson: i do know that. but you have to admit that 64k is too much, probably will never be utilised and can lead to problem when routing needs to be introduced [ eg to connect remote DC / offices / etc ].
–
pQdAug 15 '09 at 16:04

-1 - VLANs split up broadcast domains. Collision domains are split up by bridges or multi-port bridges more commonly known as switches. IP subnets and broadcast / collision domains have nothing to do with each other in the general case. In the specific case of IP over Ethernet it's common for an IP subnet to be mapped to a single broadcast domain (because ARP, the protocol used to resolve IP addresses to Ethernet hardware addresses is broadcast based), but's possible to use clever trickery with proxy ARP to have a subnet span multiple broadcast domains.
–
Evan AndersonAug 15 '09 at 2:50

@Evan: good point - that'll teach me to write answers in the wee hours of the morning. :) I stand by the remaining points though; having multiple subnets in the same VLAN will cause your L2 broadcast traffic to span multiple subnets; having multiple VLANs for same subnet will work, but proxy ARP really isn't something you should use if you can avoid it.
–
Murali SuriarAug 15 '09 at 12:27

-1 removed - Everything else you said is certainly accurate. I agree, too, re: proxy ARP-- I wouldn't use it in the "real world" unless I had some very strong compelling reason.
–
Evan AndersonAug 15 '09 at 13:32

"IP subnets and broadcast / collision domains have nothing to do with each other in the general case." No, they most certainly do in the general case. Each subnet has a network number and an associated broadcast address. Apart from ARP, you have other broadcast packets. It would be wrong to make this statement not knowing if they have multicast traffic on their network. DHCP clients uses IP broadcasting to learn of DHCP servers.
–
KiloAug 18 '10 at 13:53

@Evan Anderson What did I miss here. You withdraw your -1. Collision domains are spilt up by switches ports. Saying 2 or subnets in a collision domain is nonsense. I think he means 2 or more subnet in a broadcast domain.
–
JamesBarnettJan 15 '11 at 19:33

That sounds like a nightmare to deal with!
–
Evan AndersonAug 15 '09 at 2:51

-1 You didn't say how large of a network you maintaining, enless you are talking about a research project, I can't for the life of me think of a reason to use that kind of configuration. By definition subnets are "IP ranges" used for grouping. It sounds like you are reinventing layer 3 by using a Linux box to do your routing at layer 2. It is likely to create problems that are hidden by the unneeded complexity. This creates something that will be difficult for anyone else to figure out let alone troubleshoot.
–
Rik SchneiderAug 16 '09 at 6:06