Unknown Protocol Drops incremented frequently on router's FastEt

vc.gundapaneni · ‎09-19-2011

Hi,

Very recently, we had up graded our Leased Line's B/W from Serial 2Mbps to FastEthernet 4Mbps. Router A is Cisco 3845 and Router B is Cisco 1841.

We had changed the HWIC's cards also to HWIC-2FE on both ends as per our requirement.IOS also upgraded.

Here, we observed frequently incremented unknown protocol drops on Router B's FastEthernet Interfaces (Both on WAN & LAN ports).

And RTO's also generated.With this we are unable access our LAN's vice versa. What is the best resolution for this? Please find out the below ping statistics and do the needful.

Pinging 10.1.1.20 with 32 bytes of data:

Reply from 10.1.1.20: bytes=32 time=268ms TTL=124

Reply from 10.1.1.20: bytes=32 time=232ms TTL=124

Request timed out.

Reply from 10.1.1.20: bytes=32 time=231ms TTL=124

Reply from 10.1.1.20: bytes=32 time=91ms TTL=124

Reply from 10.1.1.20: bytes=32 time=226ms TTL=124

Reply from 10.1.1.20: bytes=32 time=230ms TTL=124

Reply from 10.1.1.20: bytes=32 time=232ms TTL=124

Request timed out.

Reply from 10.1.1.20: bytes=32 time=209ms TTL=124

Reply from 10.1.1.20: bytes=32 time=219ms TTL=124

Reply from 10.1.1.20: bytes=32 time=251ms TTL=124

Reply from 10.1.1.20: bytes=32 time=174ms TTL=124

Reply from 10.1.1.20: bytes=32 time=223ms TTL=124

Reply from 10.1.1.20: bytes=32 time=218ms TTL=124

Reply from 10.1.1.20: bytes=32 time=221ms TTL=124

Reply from 10.1.1.20: bytes=32 time=179ms TTL=124

Reply from 10.1.1.20: bytes=32 time=240ms TTL=124

Reply from 10.1.1.20: bytes=32 time=193ms TTL=124

Reply from 10.1.1.20: bytes=32 time=240ms TTL=124

Reply from 10.1.1.20: bytes=32 time=191ms TTL=124

Reply from 10.1.1.20: bytes=32 time=203ms TTL=124

Reply from 10.1.1.20: bytes=32 time=209ms TTL=124

Reply from 10.1.1.20: bytes=32 time=236ms TTL=124

Reply from 10.1.1.20: bytes=32 time=128ms TTL=124

Reply from 10.1.1.20: bytes=32 time=234ms TTL=124

Reply from 10.1.1.20: bytes=32 time=268ms TTL=124

Reply from 10.1.1.20: bytes=32 time=212ms TTL=124

Reply from 10.1.1.20: bytes=32 time=144ms TTL=124

Request timed out.

Reply from 10.1.1.20: bytes=32 time=198ms TTL=124

Reply from 10.1.1.20: bytes=32 time=302ms TTL=124

Reply from 10.1.1.20: bytes=32 time=245ms TTL=124

Reply from 10.1.1.20: bytes=32 time=306ms TTL=124

Reply from 10.1.1.20: bytes=32 time=249ms TTL=124

Reply from 10.1.1.20: bytes=32 time=185ms TTL=124

Reply from 10.1.1.20: bytes=32 time=168ms TTL=124

Reply from 10.1.1.20: bytes=32 time=220ms TTL=124

Reply from 10.1.1.20: bytes=32 time=181ms TTL=124

Reply from 10.1.1.20: bytes=32 time=311ms TTL=124

Reply from 10.1.1.20: bytes=32 time=267ms TTL=124

Reply from 10.1.1.20: bytes=32 time=234ms TTL=124

Reply from 10.1.1.20: bytes=32 time=208ms TTL=124

Reply from 10.1.1.20: bytes=32 time=258ms TTL=124

Reply from 10.1.1.20: bytes=32 time=262ms TTL=124

Reply from 10.1.1.20: bytes=32 time=172ms TTL=124

Reply from 10.1.1.20: bytes=32 time=253ms TTL=124

Reply from 10.1.1.20: bytes=32 time=227ms TTL=124

Reply from 10.1.1.20: bytes=32 time=199ms TTL=124

Reply from 10.1.1.20: bytes=32 time=336ms TTL=124

Reply from 10.1.1.20: bytes=32 time=205ms TTL=124

Reply from 10.1.1.20: bytes=32 time=250ms TTL=124

Reply from 10.1.1.20: bytes=32 time=345ms TTL=124

Reply from 10.1.1.20: bytes=32 time=199ms TTL=124

Reply from 10.1.1.20: bytes=32 time=197ms TTL=124

Reply from 10.1.1.20: bytes=32 time=205ms TTL=124

Reply from 10.1.1.20: bytes=32 time=194ms TTL=124

Reply from 10.1.1.20: bytes=32 time=190ms TTL=124

Reply from 10.1.1.20: bytes=32 time=230ms TTL=124

Reply from 10.1.1.20: bytes=32 time=195ms TTL=124

Reply from 10.1.1.20: bytes=32 time=223ms TTL=124

Reply from 10.1.1.20: bytes=32 time=258ms TTL=124

Reply from 10.1.1.20: bytes=32 time=204ms TTL=124

Reply from 10.1.1.20: bytes=32 time=268ms TTL=124

Reply from 10.1.1.20: bytes=32 time=271ms TTL=124

Reply from 10.1.1.20: bytes=32 time=215ms TTL=124

Reply from 10.1.1.20: bytes=32 time=178ms TTL=124

Reply from 10.1.1.20: bytes=32 time=244ms TTL=124

Reply from 10.1.1.20: bytes=32 time=229ms TTL=124

Reply from 10.1.1.20: bytes=32 time=242ms TTL=124

Reply from 10.1.1.20: bytes=32 time=278ms TTL=124

Reply from 10.1.1.20: bytes=32 time=294ms TTL=124

Reply from 10.1.1.20: bytes=32 time=214ms TTL=124

Reply from 10.1.1.20: bytes=32 time=217ms TTL=124

Reply from 10.1.1.20: bytes=32 time=363ms TTL=124

Reply from 10.1.1.20: bytes=32 time=252ms TTL=124

Reply from 10.1.1.20: bytes=32 time=254ms TTL=124

Reply from 10.1.1.20: bytes=32 time=256ms TTL=124

Reply from 10.1.1.20: bytes=32 time=268ms TTL=124

Reply from 10.1.1.20: bytes=32 time=229ms TTL=124

Reply from 10.1.1.20: bytes=32 time=161ms TTL=124

Reply from 10.1.1.20: bytes=32 time=166ms TTL=124

Reply from 10.1.1.20: bytes=32 time=234ms TTL=124

Request timed out.

Reply from 10.1.1.20: bytes=32 time=218ms TTL=124

Reply from 10.1.1.20: bytes=32 time=200ms TTL=124

Reply from 10.1.1.20: bytes=32 time=210ms TTL=124

Reply from 10.1.1.20: bytes=32 time=217ms TTL=124

Reply from 10.1.1.20: bytes=32 time=245ms TTL=124

Reply from 10.1.1.20: bytes=32 time=206ms TTL=124

Reply from 10.1.1.20: bytes=32 time=209ms TTL=124

Reply from 10.1.1.20: bytes=32 time=317ms TTL=124

Reply from 10.1.1.20: bytes=32 time=164ms TTL=124

Reply from 10.1.1.20: bytes=32 time=213ms TTL=124

Reply from 10.1.1.20: bytes=32 time=289ms TTL=124

Reply from 10.1.1.20: bytes=32 time=181ms TTL=124

Reply from 10.1.1.20: bytes=32 time=231ms TTL=124

Reply from 10.1.1.20: bytes=32 time=183ms TTL=124

Reply from 10.1.1.20: bytes=32 time=363ms TTL=124

Reply from 10.1.1.20: bytes=32 time=284ms TTL=124

Reply from 10.1.1.20: bytes=32 time=279ms TTL=124

Reply from 10.1.1.20: bytes=32 time=285ms TTL=124

Request timed out.

Reply from 10.1.1.20: bytes=32 time=167ms TTL=124

Reply from 10.1.1.20: bytes=32 time=182ms TTL=124

Reply from 10.1.1.20: bytes=32 time=190ms TTL=124

Reply from 10.1.1.20: bytes=32 time=316ms TTL=124

Reply from 10.1.1.20: bytes=32 time=196ms TTL=124

Reply from 10.1.1.20: bytes=32 time=130ms TTL=124

Reply from 10.1.1.20: bytes=32 time=212ms TTL=124

Reply from 10.1.1.20: bytes=32 time=152ms TTL=124

Reply from 10.1.1.20: bytes=32 time=208ms TTL=124

Reply from 10.1.1.20: bytes=32 time=92ms TTL=124

Reply from 10.1.1.20: bytes=32 time=177ms TTL=124

Reply from 10.1.1.20: bytes=32 time=211ms TTL=124

Reply from 10.1.1.20: bytes=32 time=196ms TTL=124

Reply from 10.1.1.20: bytes=32 time=281ms TTL=124

Reply from 10.1.1.20: bytes=32 time=347ms TTL=124

Reply from 10.1.1.20: bytes=32 time=248ms TTL=124

Reply from 10.1.1.20: bytes=32 time=193ms TTL=124

Reply from 10.1.1.20: bytes=32 time=182ms TTL=124

Reply from 10.1.1.20: bytes=32 time=219ms TTL=124

Reply from 10.1.1.20: bytes=32 time=253ms TTL=124

Reply from 10.1.1.20: bytes=32 time=210ms TTL=124

Reply from 10.1.1.20: bytes=32 time=138ms TTL=124

Reply from 10.1.1.20: bytes=32 time=232ms TTL=124

Reply from 10.1.1.20: bytes=32 time=177ms TTL=124

Reply from 10.1.1.20: bytes=32 time=325ms TTL=124

Reply from 10.1.1.20: bytes=32 time=242ms TTL=124

Reply from 10.1.1.20: bytes=32 time=170ms TTL=124

Reply from 10.1.1.20: bytes=32 time=184ms TTL=124

Reply from 10.1.1.20: bytes=32 time=164ms TTL=124

Reply from 10.1.1.20: bytes=32 time=196ms TTL=124

Request timed out.

Reply from 10.1.1.20: bytes=32 time=292ms TTL=124

Reply from 10.1.1.20: bytes=32 time=207ms TTL=124

Reply from 10.1.1.20: bytes=32 time=266ms TTL=124

Reply from 10.1.1.20: bytes=32 time=253ms TTL=124

Reply from 10.1.1.20: bytes=32 time=243ms TTL=124

Reply from 10.1.1.20: bytes=32 time=218ms TTL=124

Reply from 10.1.1.20: bytes=32 time=221ms TTL=124

Reply from 10.1.1.20: bytes=32 time=296ms TTL=124

Reply from 10.1.1.20: bytes=32 time=278ms TTL=124

Reply from 10.1.1.20: bytes=32 time=230ms TTL=124

Reply from 10.1.1.20: bytes=32 time=294ms TTL=124

Reply from 10.1.1.20: bytes=32 time=235ms TTL=124

Reply from 10.1.1.20: bytes=32 time=233ms TTL=124

Reply from 10.1.1.20: bytes=32 time=210ms TTL=124

Reply from 10.1.1.20: bytes=32 time=222ms TTL=124

Reply from 10.1.1.20: bytes=32 time=293ms TTL=124

Reply from 10.1.1.20: bytes=32 time=228ms TTL=124

Reply from 10.1.1.20: bytes=32 time=206ms TTL=124

Reply from 10.1.1.20: bytes=32 time=205ms TTL=124

Reply from 10.1.1.20: bytes=32 time=229ms TTL=124

Reply from 10.1.1.20: bytes=32 time=135ms TTL=124

Reply from 10.1.1.20: bytes=32 time=229ms TTL=124

Reply from 10.1.1.20: bytes=32 time=213ms TTL=124

Reply from 10.1.1.20: bytes=32 time=188ms TTL=124

Reply from 10.1.1.20: bytes=32 time=294ms TTL=124

Reply from 10.1.1.20: bytes=32 time=245ms TTL=124

Ping statistics for 10.1.1.20:

Packets: Sent = 163, Received = 155, Lost = 8 (4% loss),

Approximate round trip times in milli-seconds:

Minimum = 91ms, Maximum = 363ms, Average = 226ms

Thanks

VC Gundapaneni

Leo Laohoo · ‎09-19-2011

Can you please post the "sh interface FastEthernet" output of both sides?

Please post the configuration of both routers too.

gerald.suiza · ‎09-19-2011

do the unkown protocol drops increment by "1" every time you do a show interface? if it does it maybe related to a cosmetic bug. your timeouts maybe an entirely different problem.

vc.gundapaneni · ‎09-19-2011

Hi,

Thank you very much for your quick response. Please find them at below.

Router A:

FastEthernet0/1/1 is up, line protocol is up

Hardware is FastEthernet, address is 0024.1431.1fdb (bia 0024.1431.1fdb)

Description: << RELIANCE NEW - 4Mbps Link to Rudraram >>

Internet address is 10.0.0.17/30

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 11/255, rxload 9/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

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 1w1d

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 3748000 bits/sec, 947 packets/sec

5 minute output rate 4500000 bits/sec, 1042 packets/sec

290240596 packets input, 465454798 bytes

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog

0 input packets with dribble condition detected

335006452 packets output, 70223371 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 output buffer failures, 0 output buffers swapped out

Router B:

FastEthernet0/1/0 is up, line protocol is up

Hardware is FastEthernet, address is d0d0.fdd5.d854 (bia d0d0.fdd5.d854)

Description: << RELIANCE NEW - 4Mbps Link From Somajiguda Router >>

Internet address is 10.0.0.18/30

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 9/255, rxload 10/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

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 1w1d

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 3963000 bits/sec, 1011 packets/sec

5 minute output rate 3815000 bits/sec, 988 packets/sec

326838833 packets input, 2494842560 bytes

Received 694713 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog

0 input packets with dribble condition detected

293096605 packets output, 320413400 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

694713 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

Regards

VC Gundapaneni

Leo Laohoo · ‎09-19-2011

Get the provider to do a BER test on the Router B side.

vc.gundapaneni · ‎09-19-2011

Do we have any other problems to troubleshoot?

Leo Laohoo · ‎09-19-2011

Keep looking at Router B and the interface.

reliability 255/255, txload 11/255, rxload 9/255

If you look at the values highlighted and comes back with a value of <255 then you have a link issue.

Joseph W. Doherty · ‎09-20-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

As to your drops, I see the latency is also highly variable. My guess would be from time-to-time your link becomes congested. If true, something that might have changed when you moved from a serial interface to an Ethernet handoff was queuing changed from WFQ to FIFO. Additionally, your serial link would have likely been the congestion point that engaged queuing but your Ethernet interface might only be configured for port speed, i.e. congestion forms along the provider's path, often there too typically managed as FIFO.

Try something similar to:

policy-map shape4Mbps

class class-default

shape average 4000000

fair-queue

interface ?Ethernet#

service-policy shape4Mbps out

vc.gundapaneni · ‎09-20-2011

Dear Joseph,

Can we add this policy on both routers?

VC Gundapaneni

Joseph W. Doherty · ‎09-21-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Normally, yes, and often required to be effective.

vc.gundapaneni · ‎09-21-2011

I added the same policy on both end routers.Is it correct ? But, latency is reduced to 42ms. But, one thing i need is "how to get the best throughput from this 4Mbps WAN? What config. i required for this? Please do the needful.

Joseph W. Doherty · ‎09-21-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

If you're using what I've previously described, and your latency is now 42 ms vs. your prior average of 200+ ms, you're likely pretty close to "best". I assume when doing your ping tests you no longer see all the occasional drops.

What can, in some instances, increase "best" is to insure your interfaces have sufficient buffers for the BDP (bandwidth delay product). Using your 42 ms * 4 Mbps, BDP = 21,000 bytes or about 14 1500 bytes packets, which you likely exceed with defaults.

Beyond that, with CBWFQ, you can provide some traffic better performance at the expense of other traffic, but unless supporting very demanding application traffic, e.g. VoIP, FQ is often good enough.

vc.gundapaneni · ‎09-21-2011

Dear Joseph,

Thank you very much for your frequent replies against my queries.Still we are getting the high latency after i add the policy described by you.

Pinging 10.1.1.20 with 32 bytes of data:

Reply from 10.1.1.20: bytes=32 time=147ms TTL=124
Reply from 10.1.1.20: bytes=32 time=150ms TTL=124
Reply from 10.1.1.20: bytes=32 time=182ms TTL=124
Reply from 10.1.1.20: bytes=32 time=159ms TTL=124
Reply from 10.1.1.20: bytes=32 time=167ms TTL=124
Reply from 10.1.1.20: bytes=32 time=175ms TTL=124
Reply from 10.1.1.20: bytes=32 time=108ms TTL=124
Reply from 10.1.1.20: bytes=32 time=204ms TTL=124
Reply from 10.1.1.20: bytes=32 time=168ms TTL=124
Reply from 10.1.1.20: bytes=32 time=188ms TTL=124
Reply from 10.1.1.20: bytes=32 time=116ms TTL=124
Reply from 10.1.1.20: bytes=32 time=116ms TTL=124
Reply from 10.1.1.20: bytes=32 time=124ms TTL=124
Reply from 10.1.1.20: bytes=32 time=199ms TTL=124
Reply from 10.1.1.20: bytes=32 time=157ms TTL=124
Reply from 10.1.1.20: bytes=32 time=176ms TTL=124
Reply from 10.1.1.20: bytes=32 time=245ms TTL=124
Reply from 10.1.1.20: bytes=32 time=136ms TTL=124
Reply from 10.1.1.20: bytes=32 time=161ms TTL=124
Reply from 10.1.1.20: bytes=32 time=110ms TTL=124
Reply from 10.1.1.20: bytes=32 time=227ms TTL=124
Reply from 10.1.1.20: bytes=32 time=185ms TTL=124
Reply from 10.1.1.20: bytes=32 time=117ms TTL=124
Reply from 10.1.1.20: bytes=32 time=221ms TTL=124
Reply from 10.1.1.20: bytes=32 time=149ms TTL=124
Request timed out.
Reply from 10.1.1.20: bytes=32 time=202ms TTL=124
Reply from 10.1.1.20: bytes=32 time=128ms TTL=124
Reply from 10.1.1.20: bytes=32 time=143ms TTL=124
Reply from 10.1.1.20: bytes=32 time=185ms TTL=124
Reply from 10.1.1.20: bytes=32 time=185ms TTL=124
Reply from 10.1.1.20: bytes=32 time=181ms TTL=124
Request timed out.
Reply from 10.1.1.20: bytes=32 time=126ms TTL=124
Reply from 10.1.1.20: bytes=32 time=93ms TTL=124
Reply from 10.1.1.20: bytes=32 time=103ms TTL=124
Reply from 10.1.1.20: bytes=32 time=144ms TTL=124
Reply from 10.1.1.20: bytes=32 time=249ms TTL=124
Reply from 10.1.1.20: bytes=32 time=162ms TTL=124
Reply from 10.1.1.20: bytes=32 time=146ms TTL=124
Reply from 10.1.1.20: bytes=32 time=198ms TTL=124
Reply from 10.1.1.20: bytes=32 time=156ms TTL=124
Reply from 10.1.1.20: bytes=32 time=229ms TTL=124
Reply from 10.1.1.20: bytes=32 time=183ms TTL=124
Reply from 10.1.1.20: bytes=32 time=132ms TTL=124
Reply from 10.1.1.20: bytes=32 time=86ms TTL=124
Reply from 10.1.1.20: bytes=32 time=141ms TTL=124
Reply from 10.1.1.20: bytes=32 time=132ms TTL=124
Reply from 10.1.1.20: bytes=32 time=148ms TTL=124
Reply from 10.1.1.20: bytes=32 time=104ms TTL=124

Ping statistics for 10.1.1.20:
Packets: Sent = 50, Received = 48, Lost = 2 (4% loss),
Approximate round trip times in milli-seconds:
Minimum = 86ms, Maximum = 249ms, Average = 159ms

Thanks

VC Gundapaneni

Joseph W. Doherty · ‎09-22-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I misundstood when you noted ". . . latency is reduced to 42ms."

I believe we can do better. Your link is so congested, we need to further optimize your shaper, in this case allowing for L2 overhead which the shaper might not account for. Try setting the shaping value to 3500000. This might need further adjustment in 100000 increments or so. If ping average hits about 100ms, you might try bumping up. If ping average still high, try bumping down.

PS:

Looking at your posted Ethernet stats we can see:

5 minute input rate 3748000 bits/sec, 947 packets/sec

5 minute output rate 4500000 bits/sec, 1042 packets/sec

5 minute input rate 3963000 bits/sec, 1011 packets/sec

5 minute output rate 3815000 bits/sec, 988 packets/sec

So we have:

output rate 4500000 bits/sec, 1042 packets/sec ==>> input rate 3963000 bits/sec, 1011 packets/sec

and

output rate 3815000 bits/sec, 988 packets/sec ==>> input rate 3748000 bits/sec, 947 packets/sec

On a (logical) p2p link, one side's in should correspond to other side's out. Here we see in rate is not matching otherside's out rate. This would indicate dropped packets (seen in your ping tests) and available rate is about 4 Mbps, as seen by the two in rates.

Also, since this is a 5 minute average, this is a heavly congested link. Your highly variable pings also tells us there's queuing somewhere, and before the shaper, it could only be in the provider's path. (This isn't unusual as many providers provision deep queues to minimize dropping your packets, especially during bursts.)

vc.gundapaneni · ‎09-22-2011

Joseph,

After describing the policy on both routers, i observed many output drops on both sides interfaces. They are frequently incrementing. What i have to do know? History of our WAN Link (2Mbps) is works between two serial interfaces and now it is between two HWIC-2FE's after upgrading the bandwidth to 4Mbps. How to overcome this situation.Please do the needful.

VC Gundapaneni

Unknown Protocol Drops incremented frequently on router's FastEthernet Interfaces