Re: OT:CME Problem (Phones keep restarting)

From: Radioactive Frog <pbhatkoti_at_gmail.com>
Date: Mon, 20 Sep 2010 01:12:45 +1000

Also if you've spare port on the router, try changing it to another one.
So change switch port first then router. May be you can't do it during
production hour.

On Mon, Sep 20, 2010 at 12:18 AM, Farrukh Haroon <farrukhharoon_at_gmail.com>wrote:

> Dear Karim
>
> Use the 'sh ip virtual-reassembly' command to see which interface is
> actually causing the VFR overflow, the overflow is occurring because of too
> many fragmented packets; which should not be there in any case.
>
> So try to troubleshot the MSS/MTU issues on the network instead of
> increasing the VFR values. A packet capture would help as well.
>
> Regards
>
> Farrukh
>
>
> On Sun, Sep 19, 2010 at 5:03 PM, karim jamali <karim.jamali_at_gmail.com>wrote:
>
>> Dear Gents,
>>
>> Please if anyone could help it will be great. These are the exact logs of
>> the router:
>>
>> Sep 19 13:53:12.913: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:53:42.921: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:54:12.925: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:54:54.965: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:55:24.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:55:54.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:56:15.297: %CRYPTO-4-IKMP_NO_SA: IKE message from 78.93.253.56
>> has no SA and is not an initialization offer
>> *Sep 19 13:56:24.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:56:54.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:57:00.213: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (96/100).
>> Call (callID=1234) is rejected.
>>
>> *Sep 19 13:57:02.381: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (96/100).
>> Call (callID=1235) is rejected.
>>
>> *Sep 19 13:57:10.541: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (96/100).
>> Call (callID=1236) is rejected.
>>
>> *Sep 19 13:57:24.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:57:54.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:58:24.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:58:54.969: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:59:03.721: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (99/100).
>> Call (callID=1237) is rejected.
>>
>> *Sep 19 13:59:09.617: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (99/100).
>> Call (callID=1238) is rejected.
>>
>> *Sep 19 13:59:11.073: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
>> state to down
>> *Sep 19 13:59:24.973: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:59:29.673: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100).
>> Call (callID=1239) is rejected.
>>
>> *Sep 19 13:59:33.745: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
>> state to up
>> *Sep 19 13:59:47.881: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100).
>> Call (callID=1240) is rejected.
>>
>> *Sep 19 13:59:49.177: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100).
>> Call (callID=1241) is rejected.
>>
>> *Sep 19 13:59:52.489: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100).
>> Call (callID=1242) is rejected.
>>
>> *Sep 19 13:59:52.489: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100).
>> Call (callID=1243) is rejected.
>>
>> *Sep 19 13:59:54.973: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> the
>> fragment table has reached its maximum threshold 16
>> *Sep 19 13:59:55.169: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100).
>> Call (callID=1244) is rejected.
>>
>> *Sep 19 13:59:59.269: %IVR-3-LOW_CPU_RESOURCE: IVR: System experiencing
>> high
>> cpu utilization (98/100
>>
>> Thanks
>>
>> On Sun, Sep 19, 2010 at 2:05 PM, karim jamali <karim.jamali_at_gmail.com
>> >wrote:
>>
>> > Dears,
>> >
>> > One of the messages I am continuously getting is
>> > *Sep 19 09:28:12.402: %IP_VFR-4-FRAG_TABLE_OVERFLOW: GigabitEthernet0/1:
>> > the fragment table has reached its maximum threshold 16
>> >
>> > I tried to use the command
>> > ip virtual-reassembly max-fragments 32
>> >
>> > can anyone help?
>> >
>> >
>> > Thanks
>> >
>> >
>> > On Sun, Sep 19, 2010 at 12:57 PM, Radioactive Frog <pbhatkoti_at_gmail.com
>> >wrote:
>> >
>> >> Check the logs and dig on what is causing high CPU utilization.
>> >> Could be network based virus generating too much traffic.
>> >>
>> >> Thin down the issue first.
>> >>
>> >>
>> >> On Sun, Sep 19, 2010 at 4:51 PM, karim jamali <karim.jamali_at_gmail.com
>> >wrote:
>> >>
>> >>> Dear Gents,
>> >>>
>> >>> I have a problem that a customer every now and then has the phones
>> >>> restarting
>> >>>
>> >>> %IVR-3-LOW_CPU_RESOURCE : IVR: System experiencing high cpu
>> utilization
>> >>> ([dec]/100). Call (callID=[dec]) is rejected.
>> >>>
>> >>> Explanation System does not have enough CPU resources available to
>> >>> accept
>> >>> a new call
>> >>>
>> >>> Recommended Action Ensure that the call setup rate is within the
>> >>> supported capacity of this gateway.
>> >>> When checking the logs this is the message I am receiving and I
>> checked
>> >>> its
>> >>> explanation from Cisco.
>> >>>
>> >>> When checking the CPU, this is what I notice. Can someone advise
>> please?
>> >>>
>> >>> 9 999990
>> >>> 6596649565789989990
>> >>> 100 * ******
>> >>> 90 * ******
>> >>> 80 * ******
>> >>> 70 * ******
>> >>> 60 * ******
>> >>> 50 * ******
>> >>> 40 * ***#**
>> >>> 30 * ***#**
>> >>> 20 # #**##*
>> >>> 10 **#** *******######
>> >>>
>> >>>
>> 0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
>> >>> 0 5 0 5 0 5 0 5 0 5 0 5
>> 0
>> >>> CPU% per hour (last 72 hours)
>> >>> * = maximum CPU% # = average CPU%
>> >>>
>> >>>
>> >>> Thanks
>> >>> --
>> >>> KJ
>> >>>
>> >>>
>> >>> Blogs and organic groups at http://www.ccie.net
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> Subscription information may be found at:
>> >>> http://www.groupstudy.com/list/CCIELab.html
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> > --
>> > KJ
>> >
>>
>>
>>
>> --
>> KJ
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Sep 20 2010 - 01:12:45 ART

This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:05 ART