What is oversubscription?When selecting a 16 port 10 gig blade for cisco 6500 , it says oversubscription as 4:1. What will happen if I populate all 16 ports, will some ports be blocking or dropping packet?
Cisco – Oversubscription in cisco 6500
ciscocisco-6500oversubscription
Related Solutions
You definitely should enable MLS QoS. It is also prerequisite for CoPP, which you should add in your TODO list to implement.
Enabling 'mls qos' without other config is extremely bad idea in low-end cats, like 3560/3750, due to unexpected default scheduling and due to heavily reduced buffers causing more microbursting.
On 7600/6500 it's comparatively safe to enable, but of course you can crash your router with 'show run'. I would feel comfortable enough to enable it during production hours.
You should monitor 'show queueing interface X' after enabling to see that you're not dropping anything. Long term, you should design QoS policy and implement it, I recommend using as few queues as possible (and assign 100% of buffer to those few queues). Example of possible QoS policy in WS-X6704-10GE:
interface TenGigabitEthernet4/1
wrr-queue bandwidth percent 30 40 30 0 0 0 0 ## allocate 3 queues (+implied strictpriority) share buffer 30% 40% 30% on thos three queues
wrr-queue cos-map 1 1 0 7 # map cos values to queues
wrr-queue cos-map 2 2 3
wrr-queue cos-map 3 1 4
wrr-queue cos-map 3 2 6
For advanced config, you may want to supplement that with 'wrr-queue random-detect' with RED curve per queue+threshold. Be sure to mark your traffic correctly when it enters your network.
First, like the others have mentioned you have no bridging loop here due to running a Portchannel. That said, running STP is still fine. Let me clear some confusions on how these commands work on Cisco switches.
spanning-tree portfast trunk
This command is supposed to be run on trunk ports towards non bridging devices, such as a server with multiple VLANs or a router. This command should not be run on trunks towards switches because the port will bypass the listening and learning phase which could potentially create a bridging loop.
If you have an interface configured like this:
interface x/x
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
BPDU guard will never kick in because BPDU filter is filtering both the outgoing and incoming BPDUs. This also means that the port can never lose its Portfast status which it would normally do if BPDUs were received inbound. If you remove the filter then BPDU guard will kick in and shutdown the port if a BPDU is received. This is done before the port can lose its Portfast operatational state so basically the port will always operate in Porfast operational mode.
If you apply the commands globally instead:
spanning-tree portfast default
spanning-tree portfast bpdufilter default
spanning-tree portfast bpduguard default
The first command enables Portfast on all access ports.
When BPDU filter is applied globally, the difference is that it sends out 11 BPDUs before going silent. Because normally one BPDU is sent out every 2 seconds and the default MaxAge is 20 seconds that means that if there is a device at the other end that can process BPDUs, at least one BPDU would be received when the old BPDU (if there was one) has expired.
If a BPDU is received inbound when BPDU filter is applied globally then the port stops filtering and it will lose its Portfast status.
The BPDU guard default command will only apply to ports that are in a Portfast operational state.
If you combine these three commands together then what will happen is that when a BPDU is received the port loses its BPDU filter, BPDU guard can then kick in. The port will never lose its Portfast operational state because the port is shutdown before.
So you see when applied to the interface BPDU guard can never kick in but if you apply it globally it can.
If you run just Portfast globally and BPDU filter globally then if a BPDU comes in, the port loses the filter and loses the Portfast operational state and will operate as a normal port.
Best Answer
It sounds like you're talking about the WS-X6716-10GE. Over-subscription in this context means you have a 16 x 10GE ports on the front of the LC and no more than 4x10GE at the fabric connection to the rest of the chassis.
Over-subscription will not matter if you locally switch traffic within the same linecard; however, you will only be able to send up to your fabric connection (i.e. 40Gbps) to other linecards in the same chassis. So it's possible to get blocking or drops if your links congest the fabric connections.