Hi,
I have implemented a number of fully layer 3 campus network architectures.
The basic principle is to make use of the layer 3 performance of todays enterprise class switches. These days we can route as fast as we can switch. So you can ask yourself what is the advantage to deploying 'application based vlans' ? as long as you dont have servers which rely on broadcasting to their hosts (vary rare).
Obviously the flexibility to deploy vlans across campus is not without merits, but the disadvantages can outweigh these.
For a start, extending vlans beyond the core of the network is generally not a good idea because of the effects of broadcast storms and the like. As we know each switch on a vlan must examine every broadcast even if its just to find out that it is not interested in it, This obviously means every port on that vlan. In effect a broadcast storm could cause each switch carrying that vlan to slow down, or even crash, that includes your core. So a problem on one vlan could cause your entire network to fall into a heap.
In contrast, the first thing a router does with a broadcast is drop it. Therefore the router provides a barrier against these kind of issues and contains broadcast issues to the affected vlan.
Secondly, as a design goal, its a good idea to design spanning tree out of the network if you can. You can still provide (a better method in my opinion) failover via HSRP.
In the end, how important is it that your vlans are available everywhere ? In fact its not important at all. Why not decide that each 'area' of your campus network can have a specific number of unique vlans with corresponding ip subnets and allow your wire speed routers to do what they do best...Route traffic around your campus. In the end the ip address a host uses is irrelevent, they are only numbers after all ! and you can use DHCP to make the whole thing invisible to your users.
If you decide to go full layer 3 you can still extend vlans beyond your core if you want but its not recommended because it dilutes some of the best effects of the fully routed archetecture.
This link might help, its over-eggs the pudding a little bit but does explain the principles quite well.
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns656/c649/cdccont_0900aecd804ab689.pdf
The Cat 6500 Sup2/pfc2 (i think the sup32 is the same, but i stand to be corrected) has 2 ingress queues (1 priority, 1 standard) and 4 egress queues (1 priority, 3 standard) so there is no reason why you cant run sucessfull qos even with a layer 2 campus design.
If you are using Cisco phones, they mark the traffic for you, but if i recall correctly, you cant apply a policy map to an inbound interface on a cat6k, so you cant really trap your scavenger traffic here, you can however do it on a a 3700 for example. So one method may be to run a policy map on the ingess interfaces of each edge switch and just trust the qos marking presented to your 6500.
In this case, i cant see how the qos can be a problem. Having said that, im not familiar with the sup32 but i dont think its that radically different from other cat6k supervisors.
Hope this helps
Cheers
Shaun
