My company, like many others, replacing our legacy PBX with Cisco Call manager. My question stems from setting up our new 6509's with Sup32 (IOS) with QOS at the ingress ports. We are setting priority for the obvsious stuff like RTP, control traffic, and default. We are also implementing scavenger class for worm/dos mitigation. What it comes down to is according to TAC we implemented to much QOS at the ingress it only has 1023hardware queues. TAC suggested going fully routed architecture. I've read some white papers but my biggest dilemna is using layer vlan extension accross my campus network. The mobility of having all vlans at my disposal for transport is huge to my organization.
Sorry for the long disertation but I think the background helps tell the complete story.
Has anybody implemented this? Is there layer 2 lan extension possible? Are the more white papers/guides on it outside of the srnd from networkers 2005?
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.
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.
You can do it by turning your routed link into a trunk, then you will need to move the ip addresses you were using on that routed link onto a vlan, and make that vlan non passive in terms of dynamic routing, add this vlan to the trunk,this will maintain your routed link. Then add any additional layer 2 vlans you need to the trunk alongside the 'routed link vlan'.
It works, and you can use it to get you out of a hole, but the best practice advice is not to do it if you can in any way avoid it. It negates most of the advantages of having a layer 3 core.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...