Logging of Configuration Changes thru CCM/MGCP

[bnidacoc]

We have a number of IOS routers setup as VOIP gateways to the PSTN with PRIs.  The interfaces and the router is setup for mgcp.  We have found that configuration changes are being performed via CCM, I'm guessing through the mgcp hooks.  We see stuff like this;

1172798: May 14 11:02:49.628: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/0/1:23, TEI 0 changed to up

1172799: Jun 20 17:29:19.517: %CMAPP-6-CONFIG_DONE: Configuration by CCM is done

1172800: Jul 25 09:02:24.086: %LINK-3-UPDOWN: Interface Foreign Exchange Office 0/1/0, changed state to Administrative Shutdown

Apparently CCM can do something more than shut/no shut interfaces as none cycled in the logs pasted above.

and

1172848: Jul 25 09:02:24.550: %CMAPP-6-CONFIG_DONE: Configuration by CCM is done

1172849: Jul 25 09:02:24.802: %LINK-3-UPDOWN: Interface 0/0/0:23(1), changed state to Administrative Shutdown

1172850: Jul 25 09:02:24.802: %LINK-3-UPDOWN: Interface 0/0/0:23(2), changed state to Administrative Shutdown

Stuff goes up and down, configuration commands appear and disappear on interfaces.  Our in-house Cisco Call Manager people say they aren't changing anything, They report to management that they aren't changing anything, the network people are changing stuff and interupting the voip system.  Our ACS logs finds noone making configuration changes, yet CCM is in the logs with "%CMAPP-6-CONFIG_DONE: Configuration by CCM is done". 

Two questions?

1. Can the exact changes which the router is recieving from CCM (through mgcp) be logged in the local IOS device log, and ultimately sent to a syslog?

2. Is there some list of commands and capable changes that CCM (through mgcp) can potentially perform on an IOS router?

The VOIP team has in the past refused read only access to their CCM logs.

[George Thomas]

Every time you make a change to a route pattern/route list which involves resetting the gateway, UCM will push down configuration to the gateway and the above messages will be seen.  This could also happen if UCM loses connectivity to the gateway and UCM tries to reset the connection.

The above messages can be sent to syslog by turning on logging informational and setting the syslog destination.

You could remove the command: ccm-manager config to prevent CallManager from pushing down changes but any change in UCM will have to be manually down on the gateway.

If the above two dont work or you are unable to isolate the issue, you could convert the gateway to SIP/H323 which should be a little more robust.

Please rate useful posts.

[bnidacoc]

Thanks, but removing "ccm-manager config", isn't an option that management could tolerate at this time.  The Call Manager people are simply not doing CLI.  They've been sent to training, they have unrestricted CLI credentials to only our VOIP gateways, yet they will not work in CLI.  Our Call Manager people were never Cisco communications people, or have any other relatable data communications background.  They work with the CCM GUI.

Changes are being made to these voip devices and management gives us a strong impression that they've reported that we are altering necessary voip commands on the voip gateways. 

I find it incomprehensible that Cisco's IOS products will not generate a log about what is being changed.  How these devices pass regulatory or industry compliance requirements, I do not know.  Changes are being made, and there is no logging of them.

Is there any way that EVERY change pushed to the IOS gateway through CCM can be logged to the IOS gateway itself and/or sent to a syslog server?

Thanks.

[George Thomas]

Just to make sure we are on the same page, I think what you are seeing is something is being changed in CUCM which forces a reset of the gateway and generates these logs. The changes do not relate directly to the configuration on the gateway but something on the CUCM side which just happens to reset the gateway. Changes will be pushed down to the gateway  only if something is modified under the Gateway section in CUCM (eg. adding new PRI, changing switch-type etc). So in essence, if you reset the gateway, it just "refreshes" the configuration that is on the gateway, not change anything. In my opinion, in your case, you probably have to take a closer look at CUCM changes and see what could be triggering this. Usually when the gateway is about to be reset, a message pops-up warning you about the same.

With that being said, you can definitely log CLI changes. Please refer below:

http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_config-logger.html

Please rate useful posts.

[bnidacoc]

Thanks, we have that config logger, as well as ACS with TACACS+ and command accounting configured on the IOSdevice.  But what configuration changes performed via MGCP/CCM isn't logged on the IOS device, or TACACS+ or logged to a syslog IP configured on that IOS device. 

What our call manager staff are doing within call manager or doing to our IOS devices via mgcp, I have zero insight.

[George Thomas]

Hence the reason to convert to H323/SIP. Commands will need to be entered in the CLI and you have audit logging enabled. Since the CUCM guys dont do CLI, that I am guessing is also out of the question. Maybe someone else here has another idea.

Good luck!

Please rate useful posts.

[brmeade]

You could do audit logging in CUCM.  Just make sure every admin has separate login crodentials and you can track exactly what change was made at that time and by who.  That will track down the problem.

[Dennis Mink]

"Our Call Manager people were never Cisco communications people, or have any other relatable data communications background. " that would scare the ^&^(  out of me, maybe you would need to address your staffing issues, rather than trying to solve it with technology

Mate you are using MGCP, whic means part of your IOS gateways admin control is with CUCM, that is the reality of it. If you dont want this control, use H323.

Now in CUCM, you should check the audit logs via RTMT, to see what the various individuals have done in terms of config changes.

=============================
Please remember to rate useful posts, by clicking on the stars below.

=============================