How to prevent logging of this message

[robert_dantes]

Hi,

Need a guide that will help me prevent the message "Memory full, run clear telephony-service ephone-attempted-registrations to refresh the storage" from being logged into the 2911 logs. When we do a sh log, that is the only message we get to see and any debugs that we had set to troubleshoot a 1 ring abandon issue is overwritten we try to gather the debugs the following day. Don’t want to increase the memory size of the log as it may cause memory shortage issues, as we are already doing debugs.

Just need to disable this message from logging into the VG, don’t need to troubleshoot the cause of it. We already know what it is and its ok that it keeps trying to register and we don’t want it to register.

Regards,

Rob

[William Bell · Accepted solution]

Rob,

Since you are logging debug level messages (level 7), the system will log messages at that level and below. So, any error or warning messages will be included. I am not sure if there is a way to tell the system to filter out this one warning. Given the constraints you provided, I am inclined to recommend the following:

1. Use a terminal program that allows logging to a local file. Most modern (free or paid) terminal apps allow logging. I use Zoc myself (which logs to a file automatically). SecureCRT, Putty, etc. have a logging mechanism.

2. Telnet/SSH to your router

3. Enable your debug

4. Enable logging to the session (terminal monitor)

Using this approach you will get all of the debug information (along with other messages). So, you still have the "line noise" but you also have the data you want to see.

I suppose another tact would be to use an ACL to filter IP packets from the device(s) you know are trying to register but don't want to fix directly. Apply the ACL on the interface that faces the source of the unwanted registration traffic. The idea is that if the device can't communicate with the telephony service then it will never attempt to register (erroneously or otherwise). Of course, if you apply an ACL make sure you account for the implicit deny all.

Example: Assume the device trying to register has the ip address 10.10.10.10. You could use the following ACL:

ip access-list standard 86

deny host 10.10.10.10

permit any

!

Then use the ip access-group 86 in on the appropriate interface.

HTH.

-Bill (@ucguerrilla)

[robert_dantes]

Bill,

Thank you for the quick response. I am working on this case remotely as a 3rd party provider for the client, passing thru VPN and firewalls so implementing a terminal program would require tedious approval process. 

I am inclined to go with the ACL route, but would want to go with an extended ACL that would only prevent that specific port associated with the SCCP registration process for that IP. Would you happen to know the ports that I would need to block and yet still allow other traffic from that source?

Regards,

Rob

[William Bell · Accepted solution]

Rob,

Wow. It is fairly difficult to remotely troubleshoot a problem when you can't telnet/ssh to the device. But that is what it is.

To answer your question, SCCP uses TCP 2000. I'd also block TFTP from that host if you want to be thorough (UDP 69 is how TFTP session starts, but there are other ports).

HTH

-Bill (@ucguerrilla)

Remember to rate helpful posts

[robert_dantes]

Bill,

Thank you