I'm in the process of converting a flat network (approx 2000 users) to a more layered approach using VLANS. We have 2x Cisco 6509 switches with Sup720's configured as a HSRP core, linked with a l3 etherchannel, and an l2 etherchannel.
Each closet will comprise 3 vlans - one for voice, one for data and VLAN1 for management.
I would like to know how the addition of vlans is affecting the overall network - i.e as areas come off vlan1 for user traffic and get moved to their respective vlan how the overall network performance is hopefully improving, and I'm looking for any information that would help me measure this, or indeed any aspect of the network which I should be measuring. The idea is to be able to show how the vlan introduction is helping the site.
To be honest, you shouldn't see much benefit or disadvantage to the change in architecture. Presuming your old config was a single vlan, the only traffic that will be greatly reduced is broadcast traffic...but for 2000 nodes.....not a big deal on a gig or multi-gig network. In the old config, nodes off closet 1 would broadcast for any of the other 2000 nodes, but the traffic itself would only go between source and destination (within the closet or to another closet, etc). Now the nodes will only arp within the same closet, greatly reducing broadcasts across the core. To be honest, all you are doing is enabling the routing on the 6500s which will now control traffic between vlans, when before, they probably only controlled ingress/egress to the single vlan. So you are definitely doing the right thing in terms of scalability, but I doubt you will see any major performance increase...unless you had slower links or some major load that would drive broadcasts...but arp/cam timers should limit that impact.
As Trendkill says, the major change would be to limit the broadcast domain, and that is likely to have mnimal effect on the overall performance during "normal" operation.
It can have a major benefit from a fault/troubleshooting point of view, however even that depends on what type of access switches you were using (which you dont say). If your access switches are older
1900 series then yes, you should see an improvement in overall performance, however if they are 2950's or more recent/better, then the affect might be minimal (except for troubleshooting).
And to answer your analysis question, the only real way is to watch the utilization on the uplinks and the core switches/routers. I'm not sure what type of problems you were having before, but hopefully you got some snmp polling on the uplinks to the closets, or at least some show proc cpu and show port data. Now you can do the same and see if the increase in bandwidth helped (that probably helped more than splitting the vlans, although splitting will help your voice). Bottom line is to watch the links and processes, but generally have to have something to compare it to from before. Else the data doesn't show much.....
Best practice is to not use VLAN1 for anything and you should do your management on the data vlan. First, this simplifies the configurtion. You already need to create a data VLAN anyway, and second using it for management means that if you are monitoring the equipment and you can't get to the data VLAN you have a problem. By having a separate management VLAN you need to monitor the magement VLAN, the data VLAN and the voice VLAN. The number 1 rule for designing networks is KEEP IT SIMPLE, and creating a separate management VLAN violates this rule when it isn't necessary.
And to answer your analysis question, the only real way is to watch the utilization on the uplinks and the core switches/routers. I'm not sure what type of problems you were having before, but hopefully you got some snmp polling on the uplinks to the closets, or at least some show proc cpu and show port data. Now you can do the same and see if the increase in bandwidth helped (that probably helped more than splitting the vlans, although splitting will help your voice). Bottom line is to watch the links and processes, but generally have to have something to compare it to from before. Else the data doesn't show much.....
Use a tool. such as solar winds to measure traffic however we have had no end of trouble trying to get throughput stats on trunk ports for a particular vlan from cisco switches (using various tools). better to poll the physical interface as another poster said. I also agree that VLAN 1 should never be used especially not for management. all i need to do is find an unconfigured switchport somewhere on your network and im automatically in the management vlan.
As already mentioned there may or there may not be any performance change.
To measure network throughput you can consider iperf or if you want to get more serious, iometer (intel) - all are free. The latter allows a central management station to control multiple traffic streams between multiple hosts. It does though take a bit of figuring out. There are also commercial tools e.g. Smartbits; but costs are not low.
Performance test results are not always easy to interpret.
The best thing you can do for ethernet performance is to make sure that you have no duplex missmatches. Set everything to auto until it is proven that some particular device is not happy. The only things that I have seen within the last decade that are unhappy with Auto are UK delivered WAN ethernet services and Checkpoint firewalls.
Both are by design - and I don't agree with the Checkpoint case for sure. I guess it is arguable in the WAN ethernet case that access difficulties or remoteness might make it acceptable.
Check for port errors and assume duplex missmatch if there are more than a few until proved otherwise.
i prefer to minimise the scope of VLANs, since most campus hassles seem to come down to misconfigured devices or L2 problems such as spanning tree loops.
See if you can confine a spanning tree to an individual switch - ie the Cat 6509s have routed only interfaces, (or no VLAN connects to more than 1 physical port).
Ideally spanning tree is there to protect against misconfig, but isnt actually needed in normal operation, as there are no L2 loops.
Oh - and turn off VTP......
there are some cisco docs about tweaking campus designs that may help
formatting link
VLAN1 carries a bunch of "wierd stuff" in cisco land - you might be better off with management access away from vlan 1 in a set of routed domains / subnets.
It also pays to keep everything you can off VLAN1 since that is where an unconfigured device will put all its traffic - if VLAN 1 is not routed to servers etc the installer has to sort it out properly rather than walking away because it just works.
If you move all the "new config" traffic off VLAN 1 you can compare old and new at any point in the process.
however, as with the other posters i would not expect major changes apart from broadcast reduction in normal operation - unless you use something that misbehaves with a flat network such as multicast.
The major advantage with routing in the core is you get better fault isolation, and your campus gets more resistant to various kinds of degraded operation.
The flip side is you need more planning, a good address plan, and the configs need to be consistent with the design on the core switches at a minimum.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.