[c-nsp] Quick question regarding BGP route churn & PRP-2

[Sigurbjörn Birkir Lárusson]

Certainly doesn't solve the problem, but can you extend the snmp timeout
and failure count allowed for the device in your monitoring applications?
If your only problem are false errors in the monitoring system (i.e. there
are no operating problems with the high CPU usage), perhaps that's enough
to sustain you until you can replace it

Kind regards,
Sibbi

On 7.3.2013 13:20, "Drew Weaver" <drew.weaver at thenap.com> wrote:

>Howdy,
>
>One of our routers in a smaller facility is still rocking a pair of
>PRP-2s and we've been getting notices lately that it has been failing to
>respond to SNMP queries.
>
>Makes sense, as my cell phone likely has a better CPU than the PRP-2 but
>I wanted to see if there was any way to extend the life of this thing
>just a little longer.
>
>I tracked the CPU usage and it appears that the BGP ROUTER process is
>what is eating all of the CPU time when this issue happens.
>
>There seems to be a constant deadly drip of routing updates coming in
>from one of the upstream providers attached to this router:
>
>The below were taken just 1 second apart:
>
>Neighbor        V           AS MsgRcvd     MsgSent   TblVer        InQ
>OutQ Up/Down  State/PfxRcd
>x.x.x.13          4        3356 164983466 1610722 334466344   13    0
>       4w2d       434626
>
>Neighbor        V           AS MsgRcvd     MsgSent   TblVer        inQ
>OutQ Up/Down  State/PfxRcd
>x.x.x.13          4        3356 164983671 1610725 334466843    0     0
>         4w2d       434664
>
>Neighbor        V           AS MsgRcvd     MsgSent   TblVer        InQ
>OutQ Up/Down  State/PfxRcd
>x.x.x.13          4        3356 164983700 1610725 334466843    0    0
>         4w2d       434674
>
>We have only been getting the notices that SNMP is failing 2-3 times a
>day out of 480 pollings but it's enough to cause alerts and operational
>events to be created, etc.
>
>Awhile back we had a problem with another upstream where it would take an
>hour sometimes to download the full table from them so we implemented
>PMTUD which helped in that scenario; the max data segment size on this
>particular neighbor appears to be 1460 bytes.
>
>Does anyone have any tips or tricks on ways to lessen the impact of the
>constant route churn aside from either "Don't use a PRP-2 because it
>sucks" or "don't import a full table".
>
>We're already scheduled to be upgrading to ASR9000s with RSP440s fairly
>soon but like I said I do need to squeeze out just a few more months on
>this beastie.
>
>This particular router is still running IOS and hasn't been upgraded to
>XR.
>
>Thanks!
>-Drew
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/