cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
14813
Views
4
Helpful
13
Replies

Cisco recommended subnet sizes for VLANS

miketennyson
Level 1
Level 1

I am having a hard time on Cisco's website finding any solid information on subnet sizes. For example, what is the best size for performance and minimizing broadcast storms? What is TOO large? 500? 1000?

1 Accepted Solution

Accepted Solutions

No link, but "Top Down Network Design" by priscilla oppenheimer (Cisco Press 1999) notes that pentium class pc's can be measurably affected by 100/second. That may be where I am remembering the number from, but re-reading that section refreshes an important point:

It is the number and frequency of the broadcasts vs the processing power and utilization of that processing power on the attached hosts that makes the final answer. That is probably why answers may vary so greatly. Last thing I found was the SRND for Unified communications recommended VLAN sized at 512 or less, but also states that this is at least in part due to the Call Manager server having an arp cache limitation of 1024 entries.

View solution in original post

13 Replies 13

Collin Clark
VIP Alumni
VIP Alumni

You'll never find that on Cisco's site. You probably can on the MS site though. Generally speaking a subnet with Windows devices should be no more than 250 or so, so a class C subnet. Linux subnets can be larger, but for sanity I would keep them the same.

Hope that helps.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Mike,

the best sizes to use are between /23 -/25

a /22 subnet is probably too big.

Our customer uses /24 and few /23 are used in server farms

By the way with the easy of vlan creation there are no reason to use bigger subnets: you don't need to pay a license for each vlan you create on switches.

Hope to help

Giuseppe

Thanks for the replies. Let me elaborate a little on what it is exactly I am doing. We are looking at going to the Cisco access routing model. When doing this, we have the option of either routing from each switch individually (max 48 devices in a subnet, so a /24) or routing from the "closet." If we route from the closet, we're looking at around 3 to 400 ports. A /23 would be perfect for this but I need to find some solid info that will either back my theory that a /23 won't kill performance or go to the routed per switch method. These are STRICTLY client PCs out at remote sites, no servers. All Windows based PCs.

Mike

There is nothing to stop you advertising a /23 from the closet but using /24's or 25's within the closet.

It's a little unclear though how you see this working. A routed access-layer usually involves one switch per vlan anyway simply because if they are client PC's there is no benefit from having dual switches with HSRP etc. as there is only 1 NIC on the client PC.

With windows PC's i would not go above /24 and in many places i have worked /25's are the norm although everybody's experiences are different.

Jon

I was thinking either using 3750s stacked as a single logical switch or possibly using 4506s. In both cases, I could have the port count per closet upwards of 400 devices.

I am concerned that going to a subnet per switch could get to be a management nightmare when we have over 800 switches throughout the network. Moving to closet subnets seems easier. I do not want to sacrifice performance for management though. If /24's is what would be best for the users, then that's where we need to go.

You also need to factor in management addresses for the switches. If you are treating them as Layer 3 devices i would use loopbacks for management addresses.

As for the management of the vlans, not sure where the difficulty is. Because the vlan is isolated to the switch or a 4500/3750 stack you are not actually having to manage STP or VTP at all because there is no need to propogate vlan information.

You other alternative is to use L2 uplinks and have all the vlans on the core/distro switches which at least centralises the vlan setup.

And if you did go with 4500/3750 stacks you could have 3 or 4 vlans per switch/stack and then advertise a /23 back into the distribution layer. As long as you allocate enough spare capacity in each vlan the admin overhead is not that bad.

Are there other types of management concerns you have ?

Jon

My sole concern is having 800 /24 subnets versus having 130 /23 subnets. Having never attempted anything like this before, I don't know how much work it is going to be. I do know that by breaking subnets up by individual switches, I run the risk of having multiple subnets per room, IE, people can no longer move their printers from one side of the room to the other.

Mike,

We have the same issues/concerns here. Particularly with users moving their devices without a change order to ensure it ends up in the same VLAN. I found a guideline on the website that said you wanted to keep your broadcasts to less than 100/second. Depending on the client PC behavior, you could have a variety of subnet sizes.

Hey Rob, would you happen to have a link? That's exactly what I am looking for.

No link, but "Top Down Network Design" by priscilla oppenheimer (Cisco Press 1999) notes that pentium class pc's can be measurably affected by 100/second. That may be where I am remembering the number from, but re-reading that section refreshes an important point:

It is the number and frequency of the broadcasts vs the processing power and utilization of that processing power on the attached hosts that makes the final answer. That is probably why answers may vary so greatly. Last thing I found was the SRND for Unified communications recommended VLAN sized at 512 or less, but also states that this is at least in part due to the Call Manager server having an arp cache limitation of 1024 entries.

As Robert notes, it's the impact of traffic, not directed explictly to the host systems, that dictates the reasonable size of subnets. Broadcast is the most critical, but not the only issue.

When considering the impact of traffic to a host, there are 3 levels of impact. First, consumption of bandwidth available to the host. Second, consumption of additional NIC processing. Third, consumption of additional host resources.

The first level, bandwidth consumption, was the major concern with shared Ethernet. All host's had to share the wire's bandwidth. More hosts, generally less available bandwidth per host, so smaller subnets could improve host performance. Although this issue was almost eliminated by early gen Ethernet switching, it was still an issue with multicast. With the introduction of multicast suppression, e.g. IGMP snooping, the issue is much improved.

The second level is still related to multicast. Hosts can declare what multicast they want, but Ethernet mutlicast maps multiple blocks of IP multicast traffic into the same group, so its possible, although not common, a host's NIC accepts multicast that it doesn't want. In theory, if might be possible for a the NIC to look at the IP multicast address and not forward it up the host stack if it's not wanted. This saves the host from that processing, but the NIC is still doing it (and you're also still consuming bandwidth).

At the third level, the system itself becomes involved. This might be related to multicast traffic that the NIC couldn't filter or it could be broadcast traffic. Broadcast traffic is directed to all hosts but it's up to the receiving host to decide whether its important. As before, this consumes bandwidth, it consumes NIC processing, and it consumes system processing.

Switched Ethernet precludes issues with unicast. Later gen switched Ethernet with multicast suppression and good allocation of multicast addresses precludes its issues. But the only really effective method to help manage broadcast issues is limit the size of the shared broadcast segment. (There's also broadcast storm control, but that's for dealing with run away broadcast situations.)

Given all the above, how does that translate into proper subnet selection, well "it depends". What will the hosts be doing? When will broadcasts be used? IP, and IP applications, attempt to use broadcast as little as possible. For example, broadcast (ARP) is used for IP to MAC address resolution, although with an ARP cache to minimize re-broadcasting. A host file or DNS used for host name to IP resolution. Some routing protocol and virtual gateways use multicast. Windows networks, originally using NetBIOS, were designed to broadcast for much more than IP. With their later "layering" of IP, their design has been improved, but still you might note there are different "modes" for host resolution which will determine whether to try a broadcast first, or whether to try broadcast if name server doesn't have a match.

Without knowing exactly what the hosts will be doing, you can try what usually works, which is /24 or /23 for a maximum, but larger might work just fine, or smaller might be required.

PS:

On the issue of moving printers, if they are using DHCP and name resolution, in theory, they should still function if you move them to another subnet. If they are bound to an IP, then you'll have a problem.

tcdss
Level 1
Level 1

In our network, we use /23 by default. We have mostly Windows XP hosts. We use 6500s (6509 or 6513 in most cases) as the access switch and route at the distribution layer. If you have ~400 hosts in a closet (or as few as 150), you may want to price out the 6500 platform. We find the 6500 to be less expensive in a large closet and very reliable. We have other reasons for using the 6500, but that is a different discussion (and I am not a Cisco SE or AM...or reseller for that matter...).

chestes
Level 1
Level 1

Can you please send me a link to the SRND for Unified communications recommended VLAN sized at 512 or less?

Christian J. Estes, cwne #85, cciew #42615
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: