Best Practice for CUBE Monitoring

[Nico B.]

Hello,

we're using CUBE to connect to our ITSP.

It's an ASR 1001-X.

I'm a little bit unhappy with the logging / monitoring of the CUBE. With CUCM you can collect files via RTMT for one or two days in the past.

But CUBE is a black box.

Today, when a user reports a Problem, we say: "Okay, we'll enable the SIP Debug. Call us again if your problem reoccurs".

Then the user calls again: "the problem reoccurs 5 hours ago". And we say: "ah, sorry, you are too late. The logs are overwritten".

That's not cool.

Today we are using the Logging Buffer mit 100MB for Debugging.

You can increase the logging buffer to 2GB, but is this a good idea?

Is it a good idea to run the "debug ccsip message" command the whole time?

We use a syslog Server, too. But it's a central logging appliance. I can't flood it with debug logs.

we have PCA, but...

Is there a best practice how to monitor Cisco UBE?

Kind regards

Nico 

[Mike_Brezicky]

Fore reactive logs, sending to a syslog as you have mentioned would be the ideal method.

On the CUBE if you set the following, you can get all the SIP signaling messages to the syslog.
no logging console
no logging monitor
logging trap debugging
debug ccsip messages

Its really the job of a syslog server to have a stream of messages sent to it, so if you are looking to capture SIP traffic for all calls through the device, this is the simplest method

Afterwards, you can pull the debug logs and paste them into a too called TranslatorX - https://translatorx.org/ - for a clean view of the SIP trace.

At my core call center, I leave the debug up 100% of the time and router has been online for almost 2 years now.

[Shrek5950]

Hi 

Can i do Truncated logs that over write every 24 Hours ?