1: I tried increasing the input-queue from the default 75 to 1000, 2000 and then 4096 but that still did not stop the drops/flushes. This does work from occasion but it depends on the input rate of the data.
hold−queue <
is 75).value> command for each interface (the queue length value can be 0 − 4096. The default value
Each interface owns an input queue onto which incoming packets are placed to await processing by the Routing Processor (RP). Frequently, the rate of incoming packets placed on the input queue exceeds the rate at which the RP can process the packets.
http://www.cisco.com/en/US/products/hw/modules/ps2643/products_tech_note09186a0080094a8c.shtml
6509E#show int gi 4/7
GigabitEthernet4/7 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0017.0f9b.0800 (bia 0017.0f9b.0800)
Description: multicast-unicast
Internet address is 192.168.7.94/31
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseT
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:20:24
Input queue: 0/2000/5/5 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 6004000 bits/sec, 3614 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 480 pkt, 33840 bytes - mcast: 145 pkt, 13669 bytes
L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 7135671 pkt, 1481502786 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
7064317 packets input, 1466661500 bytes, 0 no buffer
Received 7063839 broadcasts (6970308 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
1296 packets output, 93739 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
6509E#
6509E#show int gi 4/7 switching
GigabitEthernet4/7 multicast-unicast
Throttle count 0
Drops RP 5 SP 0
SPD Flushes Fast 5 SSE 0
SPD Aggress Fast 0
SPD Priority Inputs 84 Drops 0
Protocol Path Pkts In Chars In Pkts Out Chars Out
Other Process 2682 210124 0 0
Cache misses 0
Fast 0 0 0 0
Auton/SSE 0 0 0 0
IP Process 716508 63616061 713076 92495576
Cache misses 0
Fast 32778336 5720227032 0 0
Auton/SSE 564492684 102883224482 5 390
6509E#
Selective Packet Discard (SPD) is a mechanism to manage the process level input queues on the Route Processor (RP). The goal of SPD is to provide priority to routing protocol packets and other important traffic control Layer 2 keepalives during periods of process level queue congestion.
http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a008012fb87.shtml
In order to stop the interface from being oversubscribed by the multicast traffic, I need a way to filter all the traffic coming into the interface.
3: Implementing a multicast boundary list, you need to set this up on both sides of the interface. If you only set this up one side, the receiving end the transmitting end will still push unnecessary data onto the receiving device. In order to setup a multicast boundary, issue the below commands.
Creating a multicast boundary and applying it:
ip access-list standard name_acl
permit x.x.x.x
or
permit x.x.x.x 0.0.0.255
exit
!
interface gi 4/7
ip multicast boundary name_acl
end
!
WR
!
Now you are filtering multicast coming in and out of this port. This resolved my issue. I also recommend you read http://www.frameip.com/dos-cisco/queue_drops.pdf
Input queue drops are counted by the system if the number of packet buffers allocated to the interface is
exhausted or reaches its maximum threshold. The maximum queue value can be increased by using the
No comments:
Post a Comment