Questions about L2 discards:
1) What can I do about output discards at L2 between ports connecting switches (6509s ? CatOS)? They are autonegotiating at 1000/Full. I read that Flowcontrol should not be enabled on trunks, and understand WRED and other congestion avoidance only in the context of router interfaces. Is there anything I can do to mitigate the drops?
2) I?m getting a lot of In-Discards on my 6509 (CatOS) Etherchannel ports. Should I turn Flowcontrol off on these? Is there anything else I can do to tune the Etherchannel?
Thank you for any suggestions.
Mod Slot Ports Module-Type Model Sub Status
--- ---- ----- ------------------------- ------------------- --- --------
1 1 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes ok
15 1 1 Multilayer Switch Feature WS-F6K-MSFC2 no ok
3 3 3 Network Analysis Module WS-SVC-NAM-1 no ok
4 4 8 1000BaseX Ethernet WS-X6408A-GBIC no ok
5 5 48 10/100/1000BaseT Ethernet WS-X6148-GE-TX no ok
6 6 48 10/100/1000BaseT Ethernet WS-X6148-GE-TX no ok
7 7 48 10/100BaseTX Ethernet WS-X6348-RJ-45 yes ok
8 8 48 10/100/1000BaseT Ethernet WS-X6148-GE-TX no ok
Mod Sub-Type Sub-Model Sub-Serial Sub-Hw Sub-Sw
--- ----------------------- ------------------- ----------- ------ ------
1 L3 Switching Engine WS-F6K-PFC SAL0542DB1F 1.1
7 Inline Power Module WS-F6K-VPWR 1.0 1.0
Can you see if you are affected by this Field Notice ?
Thank you for the link. Unfortunately, the 6148s on each Core do not fit into the problem category. The "show asicreg" command also yielded no problem results.
WRED is not an option with this CatOS, or else I might considerate (wisely or not) for the non-trunk output discards. Not sure what I can do beyond that.
For the Etherchannels, my next step would be to disable the FlowControl, but suspect that it won't help much.
Thanks for checking.
I'm afraid you have a hardware limitation. You are injecting more traffic than the classic cards can support. You are using a shared bus for all this kind of traffic. For a 6509, to work at its best on a server farm environment (I'm assuming that's where this box is currently running), you need Sup720 and 67xx line cards - in order to take advantage of the full fabric design.
Queuing on Catalysts is completely different than queuing on a router. There are no policy maps or such stuff. It all depends on the type of your Linecards. Basically you can assign packets based on the COS value to a queue and wred threshold on your port. With "show port capa" you can see what queuing system (2Q2T or 1P2Q2T or ....) your Linecards support. The queues have normally one or more configurable WRED thresholds and are served by a WRR algorithm. Output discards happen when there is a burst of traffic to big to serialize out the port and also to big to be kept in the buffer. The best thing for not enough bandwidth is more bandwidth :-) You can play with some queuing to priorize some packets over other, but you will still have some drops. And you right, flow control should be disabled on interswitch links.
What made me look up in you setup was the NAM Module, be careful with RSPAN sessions they can consume a lot of bandwidth! Cut the RSPAN VLANs off all the trunks where you don't need it (I had a similar problem).
About your second question I can not help you, I have never encountered In-Discards. Input Packet Drops means that the switching backplane is not fast enough to transport all the packets away from the ports, which is rather unnormal. Probably the Sup 1 is just not fast enough for server agregation (15 Mpps compared to a possible 400 Mpps with a Sup 720 and corresponding Linecards)
You?re right. I see now that I can configure WRED (and WRR) through the CatOS, and it is different than a router interface configuration. From what I understand, a router applies WRED to traffic and then passes it to one software queue, whereas a switch seems to apply WRED to traffic entering each queue. Since I?m not classifying or marking traffic anywhere on the network, I assume I?d just configure the standard queues (or whichever standard queue is for unclassified traffic), and make the WRED effectively behave like RED. This of course, will hopefully mitigate output drops at ports connecting to other switches.
For the input discards happening on Etherchannels that connect the redundant 6509s, maybe I can configure WRED on those ports, so that the packets get randomly dropped on their way out, rather than at the other side (where they are getting dropped now). This assumes that WRED is OK for Etherchannels ? haven?t looked into this yet.
Regarding the input discards, I tend to trust the assessment of EdisonOrtiz and yourself -- an upgrade of the Sup and linecards may be the best answer. But if the problem is too much traffic hitting the router, wouldn?t there be cache misses showing up in the ?sh interfaces vlan 100 switching ?output? (input discards currently show up at L2, and input drops show up at the L3 vlan interfaces). As it is, there are no cache misses, and all traffic seems to be intended for the router (?show ip stat? showing excessive Processed traffic). Could this be due to unicast flooding at L2, or SNMP (?) traffic related to the NAM as you suggest. (no RSPANs currently). ?Show proc cpu? shows a lot of SNMP, as well as a lot of ARP Input, which itself is a little puzzling. In any case, there seems to be a lot of traffic destined for the router itself, as opposed to that headed elsewhere.
Thank you both for your help.
You can not configure RED, you have to assign COS Values to Queues and thresholds. But, if you don't classify traffic in your network, most of your traffic will be marked as COS 0, which is also a valid marking to be assigned to queues and thresholds. So that way you configure something like RED.
Queuing is something close to the hardware, so you don't configure it on etherchannels but on the ports themselves. So there is no difference for ports with or without etherchannels.
I don't know exactly about the "cache misses" I think that has something to do with CEF, or other forwarding methods, if the router cannot find an entry in the forwarding cache. Maybe you can use your NAM to capture and analyze a few seconds of traffic hammering into you Cat6K.