cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
853
Views
0
Helpful
5
Replies

GigE line card dropping allot of packets in the input queue trunk to backbone switch

rugman66
Level 1
Level 1

Hello,

 

I have a 3845 router running a GigE uplink, with a NM-16ESW-1GIG line card running a GigE trunk to the backbone GigE switch. The issue is that the line card GigE trunk is dropping allot of packets in the input queue and thus very poor throughput. I have confirmed both the line card and switch trunks are running full duplex, 802.1q non negotiation. Global CEF is enabled on the router, but the option to enable ip route-cache is not available for the line card port. How can I get the line card trunk to stop process switching and use CEF?

 

Regards

5 Replies 5

jbeaulau
Cisco Employee
Cisco Employee
 

Running the following show command shows CEF and fast switching enabled. So what could be some causes for high rate of dropped input queue packets?

 

0#sh cef interface gigabitEthernet 1/0 internal
GigabitEthernet1/0 is up (if_number 20) ['0]
  Corresponding hwidb fast_if_number 20
  Corresponding hwidb firstsw->if_number 20
  Internet Protocol processing disabled
  Suppressed input features: MCI Check
  Hardware idb is GigabitEthernet1/0
  Fast switching type 1, interface type 146
  IP CEF switching enabled
  IP CEF switching turbo vector
  IP prefix lookup IPv4 mtrie 8-8-8-8 optimized
  Flags 0x26000, hardware flags 0x5
  Input fast flags 0x0, Output fast flags 0x0
  ifindex 20(20) ['0]
  Slot  Slot unit 0 VC -1
  IP MTU 0
 Status flags:
  hwidb    status 10040 status2 20001A status3 0 status4 0
  fibhwidb status 10040 status2 20001A status3 0 status4 0
 Subblocks:
  No subblocks present

Leo Laohoo
Hall of Fame
Hall of Fame
Can you post the complete output to the command "sh int Gi1/0"?

Sure Leo, thanks

 

0#sh int gig
englrn-hackshare-gw2-rack-10#sh int gigabitEthernet 1/0
GigabitEthernet1/0 is up, line protocol is up
  Hardware is Gigabit Ethernet, address is c471.fe4a.9b4b (bia c471.fe4a.9b4b)
  Description: Trunk to 4948_left
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  output flow-control is off, input flow-control is off
  0 pause input, 0 pause output
  Full-duplex, 1000Mb/s
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:04, output never, output hang never
  Last clearing of "show interface" counters 1d22h
  Input queue: 0/500/7234/0 (size/max/drops/flushes); Total output drops: 16
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 320000 bits/sec, 160 packets/sec
  5 minute output rate 1126000 bits/sec, 173 packets/sec
     38721157 packets input, 1593085784 bytes, 0 no buffer
     Received 67449 broadcasts (0 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
     43793359 packets output, 2740511423 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     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

The counters were cleared almost 48 hours ago.
However, I can see that at that time, the input and output packets are high. Looks like a QoS issue to me.