date:20181203

[cisco-voip] 11.x Mixed mode back to Insecure

2018-12-03 Thread Jason Aarons (Americas)

   Anyone done a CUCM mixed mode back to Insecure via utils cmd? CUCM 11.x



Get Outlook for Android

This email and all contents are subject to the following disclaimer:

"http://www.dimensiondata.com/emaildisclaimer;
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 500 Series Headsets Saying Disabled

2018-12-03 Thread Lelio Fulgenzi

Thanks!

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 
2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 3, 2018, at 2:59 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:

Phone load

Get Outlook for iOS

Matthew Loraditch
Sr. Network Engineer

p: 443.541.1518


w: www.heliontechnologies.com|  
e: mloradi...@heliontechnologies.com
















From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Monday, December 3, 2018 2:49:04 PM
To: Matthew Loraditch
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] 500 Series Headsets Saying Disabled


CUCM or firmware 12.5?

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 3, 2018, at 2:22 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:

And I figured it out. I have the new 56X and they don’t work via USB until 12.5 
is out.


Matthew Loraditch
Sr. Network Engineer

p: 443.541.1518


w: www.heliontechnologies.com|  
e: mloradi...@heliontechnologies.com















From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Matthew Loraditch
Sent: Monday, December 3, 2018 2:13 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] 500 Series Headsets Saying Disabled

Got a set of the new Cisco 500 headsets, says it’s been disabled by admin.
USB is enabled on the phone and all USB classes are enabled in enterprise phone 
config.
Previously had a Bluetooth based plantronics connected. Phone is 8865 on 
12.1.1SR1 on CUCM 12.0SU1. All headset settings are enabled as well. Any ideas?


Matthew Loraditch

Sr. Network Engineer


p: 443.541.1518



w: www.heliontechnologies.com

 |

e: mloradi...@heliontechnologies.com





















___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 500 Series Headsets Saying Disabled

2018-12-03 Thread Matthew Loraditch

Phone load

Get Outlook for iOS


Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com
From: Lelio Fulgenzi 
Sent: Monday, December 3, 2018 2:49:04 PM
To: Matthew Loraditch
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] 500 Series Headsets Saying Disabled


CUCM or firmware 12.5?

-sent from mobile device-

Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

On Dec 3, 2018, at 2:22 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:

And I figured it out. I have the new 56X and they don’t work via USB until 12.5 
is out.


Matthew Loraditch
Sr. Network Engineer

p: 443.541.1518


w: www.heliontechnologies.com|  
e: mloradi...@heliontechnologies.com















From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Matthew Loraditch
Sent: Monday, December 3, 2018 2:13 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] 500 Series Headsets Saying Disabled

Got a set of the new Cisco 500 headsets, says it’s been disabled by admin.
USB is enabled on the phone and all USB classes are enabled in enterprise phone 
config.
Previously had a Bluetooth based plantronics connected. Phone is 8865 on 
12.1.1SR1 on CUCM 12.0SU1. All headset settings are enabled as well. Any ideas?


Matthew Loraditch

Sr. Network Engineer


p: 443.541.1518



w: www.heliontechnologies.com

 |

e: mloradi...@heliontechnologies.com





















___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] 500 Series Headsets Saying Disabled

2018-12-03 Thread Matthew Loraditch

And I figured it out. I have the new 56X and they don’t work via USB until 12.5 
is out.


Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com
From: cisco-voip  On Behalf Of Matthew 
Loraditch
Sent: Monday, December 3, 2018 2:13 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] 500 Series Headsets Saying Disabled

Got a set of the new Cisco 500 headsets, says it’s been disabled by admin.
USB is enabled on the phone and all USB classes are enabled in enterprise phone 
config.
Previously had a Bluetooth based plantronics connected. Phone is 8865 on 
12.1.1SR1 on CUCM 12.0SU1. All headset settings are enabled as well. Any ideas?


Matthew Loraditch

Sr. Network Engineer


p: 443.541.1518



w: www.heliontechnologies.com

 |

e: mloradi...@heliontechnologies.com


[cid:image001.png@01D48B13.5D65A910]


[Facebook]



[Twitter]


[LinkedIn]








___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] 500 Series Headsets Saying Disabled

2018-12-03 Thread Matthew Loraditch

Got a set of the new Cisco 500 headsets, says it's been disabled by admin.
USB is enabled on the phone and all USB classes are enabled in enterprise phone 
config.
Previously had a Bluetooth based plantronics connected. Phone is 8865 on 
12.1.1SR1 on CUCM 12.0SU1. All headset settings are enabled as well. Any ideas?

Matthew Loraditch
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com | e: mloradi...@heliontechnologies.com
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

2018-12-03 Thread Nilson Costa

Thanks Ryan, I´ll check it out

Em seg, 3 de dez de 2018 às 15:22, Ryan Ratliff (rratliff) <
rratl...@cisco.com> escreveu:

> There most certainly will be, but what it is depends on the hardware. It’s
> a server so there will be some type of management agent that has probably
> been trying to get somebody’s attention for a few weeks.
>
> I wouldn’t be surprised if there is a non-green led or two if you look at
> the disks themselves.
>
> -Ryan
>
> On Dec 3, 2018, at 12:18 PM, Nilson Costa  wrote:
>
> Is there anyway to troubleshoot the disks to see which one is on defect?
>
> Regards
>
> Em seg, 3 de dez de 2018 às 15:08, Ryan Ratliff (rratliff) <
> rratl...@cisco.com> escreveu:
>
>> #1  0x044a9935 in raise () from /lib/tls/libc.so.6
>> #2  0x044ab399 in abort () from /lib/tls/libc.so.6
>> #3  0x0842e457 in preabort () at ProcessCMProcMon.cpp:80
>> #4  0x0842fe7c in CMProcMon::verifySdlRouterServices () at
>> ProcessCMProcMon.cpp:720
>>
>>
>> The ccm process is killing itself because it isn’t getting enough
>> resources.
>>
>> Nov 29 17:26:12 CMBL-03-01 local7 2 : 1: CMBL-03-01.localdomain: Nov 29
>> 2018 19:26:12.340 UTC :  %UC_CALLMANAGER-2-CallManagerFailure:
>> %[HostName=CMBL-03-01][IPAddress=192.168.183.3][Reason=4][Text=CCM
>> Intentional Abort: SignalName: SIPSetupInd, DestPID:
>> SIPD[1:100:67:7]][AppID=Cisco
>> CallManager][ClusterID=StandAloneCluster][NodeID=CMBL-03-01]: Indicates an
>> internal failure in Unified CM
>>
>>
>> So much good info in the syslog.
>> Here’s a super-useful tidbit.
>>
>> Nov 28 03:59:23 CMBL-03-01 local7 2 : 1543: CMBL-03-01.localdomain: Nov
>> 28 2018 05:59:23.840 UTC :  %UC_RTMT-2-RTMT_ALERT: 
>> %[AlertName=CallProcessingNodeCpuPegging][AlertDetail=
>> Processor load over configured threshold for configured duration of time .
>>  Configured high threshold is 90 % tomcat (2 percent) uses most of the
>> CPU.
>>  Processor_Info:
>>
>>  For processor instance 1: %CPU= 99, %User= 2, %System= 2, %Nice= 0,
>> %Idle= 0, %IOWait= 97, %softirq= 0, %irq= 0.
>>
>>  For processor instance _Total: %CPU= 93, %User= 2, %System= 1, %Nice= 0,
>> %Idle= 7, %IOWait= 90, %softirq= 0, %irq= 0.
>>
>>  For processor instance 0: %CPU= 86, %User= 2, %System= 1, %Nice= 0,
>> %Idle= 14, %IOWait= 83, %softirq= 0, %irq= 0.
>>
>>  For processor instance 3: %CPU= 87, %User= 2, %System= 2, %Nice= 0,
>> %Idle= 13, %IOWait= 83, %softirq= 0, %irq= 0.
>>
>>  For processor instance 2: %CPU= 99, %User= 4, %System= 1, %Nice= 0,
>> %Idle= 0, %IOWait= 96, %softirq= 0, %irq= 0.
>>  ][AppID=Cisco AMC Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert
>>
>>
>> Looking back just a bit further, and there are a TON of these.
>>
>> Nov 15 21:22:00 CMBL-03-01 local7 2 : 582: CMBL-03-01.localdomain: Nov 15
>> 2018 23:22:00.256 UTC :  %UC_RTMT-2-RTMT_ALERT: %[
>> AlertName=HardwareFailure][AlertDetail= At Thu Nov 15 21:22:00 BRST
>> 2018 on node 192.168.183.3, the following HardwareFailure events generated:
>>  hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4 Director Agent: 
>> LSIESG_DiskDrive_Modified
>> 500605B0027C6D50 Command timeout on PD 01(e0xfc/s1) Path
>> 50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00 Sev: 3. AppID : Cisco
>> Syslog Agent ClusterID :  NodeID : CMBL-03-01  TimeStamp : Thu Nov 15
>> 21:21:26 BRST 2018   hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4
>> Director Agent: LSIESG_AlertIndication 500605B0027C6D50 Command timeout on
>> PD 01(e0xfc/s1) Path 50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00
>> Sev: 3. AppID : Cisco Syslog Agent ClusterID :  NodeID : CMBL-03-01
>>  TimeStamp : Thu Nov 15 21:21:27 BRST 2018   hwStringMatch : Nov 15
>> 21:21:26 CMBL-03-01][AppID=Cisco AMC
>> Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert
>>
>>
>> You’ve lost or are in the middle of losing at least one disk drive. It
>> probably lost them all at the same time on the 13th and the OS marked the
>> entire filesystem readonly.
>>
>> -Ryan
>>
>> On Dec 3, 2018, at 9:28 AM, Nilson Costa  wrote:
>>
>> Hello All,
>>
>> I´m deploying a new CUCM on a customer that has an old one working just
>> as call routing for a Genesys system for call center.
>>
>> As you can see the picture below, they have some MGCP Gateways connected
>> to this CUCM where the calls come in and via some CTI route points,
>> controlled by Genesys, route the call to to 2 Avaya PBX or to a another CUCM
>>
>> 
>> On november 13th they lost access to Tomcat on the Publisher, when we
>> looked at the server several services were restarting including Cisco
>> CallManager, just on the Publisher.
>> We decided to reboot the whole cluster, but after the reboot we are
>> facing some wierd issues that are not that relevant, I think, but there is
>> one which we are really worried
>>
>> The Cisco CallManager process are still restarting ramdomly and
>> generating some coredumps I´m attaching this logs here also I´m attaching
>> the syslogs from the publisher.
>>
>> Can anybody here on the group help me finding out what is

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

2018-12-03 Thread Ryan Ratliff (rratliff) via cisco-voip

There most certainly will be, but what it is depends on the hardware. It’s a 
server so there will be some type of management agent that has probably been 
trying to get somebody’s attention for a few weeks.

I wouldn’t be surprised if there is a non-green led or two if you look at the 
disks themselves.

-Ryan

On Dec 3, 2018, at 12:18 PM, Nilson Costa 
mailto:nilsonl...@gmail.com>> wrote:

Is there anyway to troubleshoot the disks to see which one is on defect?

Regards

Em seg, 3 de dez de 2018 às 15:08, Ryan Ratliff (rratliff) 
mailto:rratl...@cisco.com>> escreveu:
#1  0x044a9935 in raise () from /lib/tls/libc.so.6
#2  0x044ab399 in abort () from /lib/tls/libc.so.6
#3  0x0842e457 in preabort () at ProcessCMProcMon.cpp:80
#4  0x0842fe7c in CMProcMon::verifySdlRouterServices () at 
ProcessCMProcMon.cpp:720

The ccm process is killing itself because it isn’t getting enough resources.

Nov 29 17:26:12 CMBL-03-01 local7 2 : 1: CMBL-03-01.localdomain: Nov 29 2018 
19:26:12.340 UTC :  %UC_CALLMANAGER-2-CallManagerFailure: 
%[HostName=CMBL-03-01][IPAddress=192.168.183.3][Reason=4][Text=CCM Intentional 
Abort: SignalName: SIPSetupInd, DestPID: SIPD[1:100:67:7]][AppID=Cisco 
CallManager][ClusterID=StandAloneCluster][NodeID=CMBL-03-01]: Indicates an 
internal failure in Unified CM

So much good info in the syslog.
Here’s a super-useful tidbit.

Nov 28 03:59:23 CMBL-03-01 local7 2 : 1543: CMBL-03-01.localdomain: Nov 28 2018 
05:59:23.840 UTC :  %UC_RTMT-2-RTMT_ALERT: 
%[AlertName=CallProcessingNodeCpuPegging][AlertDetail= Processor load over 
configured threshold for configured duration of time . Configured high 
threshold is 90 % tomcat (2 percent) uses most of the CPU.
 Processor_Info:

 For processor instance 1: %CPU= 99, %User= 2, %System= 2, %Nice= 0, %Idle= 0, 
%IOWait= 97, %softirq= 0, %irq= 0.

 For processor instance _Total: %CPU= 93, %User= 2, %System= 1, %Nice= 0, 
%Idle= 7, %IOWait= 90, %softirq= 0, %irq= 0.

 For processor instance 0: %CPU= 86, %User= 2, %System= 1, %Nice= 0, %Idle= 14, 
%IOWait= 83, %softirq= 0, %irq= 0.

 For processor instance 3: %CPU= 87, %User= 2, %System= 2, %Nice= 0, %Idle= 13, 
%IOWait= 83, %softirq= 0, %irq= 0.

 For processor instance 2: %CPU= 99, %User= 4, %System= 1, %Nice= 0, %Idle= 0, 
%IOWait= 96, %softirq= 0, %irq= 0.
 ][AppID=Cisco AMC Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert

Looking back just a bit further, and there are a TON of these.

Nov 15 21:22:00 CMBL-03-01 local7 2 : 582: CMBL-03-01.localdomain: Nov 15 2018 
23:22:00.256 UTC :  %UC_RTMT-2-RTMT_ALERT: 
%[AlertName=HardwareFailure][AlertDetail= At Thu Nov 15 21:22:00 BRST 2018 
on node 192.168.183.3, the following HardwareFailure events generated:  
hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4 Director Agent: 
LSIESG_DiskDrive_Modified 500605B0027C6D50 Command timeout on PD 01(e0xfc/s1) 
Path 50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00 Sev: 3. AppID : Cisco 
Syslog Agent ClusterID :  NodeID : CMBL-03-01  TimeStamp : Thu Nov 15 21:21:26 
BRST 2018   hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4 Director Agent: 
LSIESG_AlertIndication 500605B0027C6D50 Command timeout on PD 01(e0xfc/s1) Path 
50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00 Sev: 3. AppID : Cisco 
Syslog Agent ClusterID :  NodeID : CMBL-03-01  TimeStamp : Thu Nov 15 21:21:27 
BRST 2018   hwStringMatch : Nov 15 21:21:26 CMBL-03-01][AppID=Cisco AMC 
Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert

You’ve lost or are in the middle of losing at least one disk drive. It probably 
lost them all at the same time on the 13th and the OS marked the entire 
filesystem readonly.

-Ryan

On Dec 3, 2018, at 9:28 AM, Nilson Costa 
mailto:nilsonl...@gmail.com>> wrote:

Hello All,

I´m deploying a new CUCM on a customer that has an old one working just as call 
routing for a Genesys system for call center.

As you can see the picture below, they have some MGCP Gateways connected to 
this CUCM where the calls come in and via some CTI route points, controlled by 
Genesys, route the call to to 2 Avaya PBX or to a another CUCM


On november 13th they lost access to Tomcat on the Publisher, when we looked at 
the server several services were restarting including Cisco CallManager, just 
on the Publisher.
We decided to reboot the whole cluster, but after the reboot we are facing some 
wierd issues that are not that relevant, I think, but there is one which we are 
really worried

The Cisco CallManager process are still restarting ramdomly and generating some 
coredumps I´m attaching this logs here also I´m attaching the syslogs from the 
publisher.

Can anybody here on the group help me finding out what is triggering the Cisco 
CallManager restart?

--
Nilson Lino da Costa Junior
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



--
Nilson Lino da Costa Junior

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

2018-12-03 Thread Nilson Costa

Is there anyway to troubleshoot the disks to see which one is on defect?

Regards

Em seg, 3 de dez de 2018 às 15:08, Ryan Ratliff (rratliff) <
rratl...@cisco.com> escreveu:

> #1  0x044a9935 in raise () from /lib/tls/libc.so.6
> #2  0x044ab399 in abort () from /lib/tls/libc.so.6
> #3  0x0842e457 in preabort () at ProcessCMProcMon.cpp:80
> #4  0x0842fe7c in CMProcMon::verifySdlRouterServices () at
> ProcessCMProcMon.cpp:720
>
>
> The ccm process is killing itself because it isn’t getting enough
> resources.
>
> Nov 29 17:26:12 CMBL-03-01 local7 2 : 1: CMBL-03-01.localdomain: Nov 29
> 2018 19:26:12.340 UTC :  %UC_CALLMANAGER-2-CallManagerFailure:
> %[HostName=CMBL-03-01][IPAddress=192.168.183.3][Reason=4][Text=CCM
> Intentional Abort: SignalName: SIPSetupInd, DestPID:
> SIPD[1:100:67:7]][AppID=Cisco
> CallManager][ClusterID=StandAloneCluster][NodeID=CMBL-03-01]: Indicates an
> internal failure in Unified CM
>
>
> So much good info in the syslog.
> Here’s a super-useful tidbit.
>
> Nov 28 03:59:23 CMBL-03-01 local7 2 : 1543: CMBL-03-01.localdomain: Nov 28
> 2018 05:59:23.840 UTC :  %UC_RTMT-2-RTMT_ALERT: 
> %[AlertName=CallProcessingNodeCpuPegging][AlertDetail=
> Processor load over configured threshold for configured duration of time .
> Configured high threshold is 90 % tomcat (2 percent) uses most of the CPU.
>
>  Processor_Info:
>
>  For processor instance 1: %CPU= 99, %User= 2, %System= 2, %Nice= 0,
> %Idle= 0, %IOWait= 97, %softirq= 0, %irq= 0.
>
>  For processor instance _Total: %CPU= 93, %User= 2, %System= 1, %Nice= 0,
> %Idle= 7, %IOWait= 90, %softirq= 0, %irq= 0.
>
>  For processor instance 0: %CPU= 86, %User= 2, %System= 1, %Nice= 0,
> %Idle= 14, %IOWait= 83, %softirq= 0, %irq= 0.
>
>  For processor instance 3: %CPU= 87, %User= 2, %System= 2, %Nice= 0,
> %Idle= 13, %IOWait= 83, %softirq= 0, %irq= 0.
>
>  For processor instance 2: %CPU= 99, %User= 4, %System= 1, %Nice= 0,
> %Idle= 0, %IOWait= 96, %softirq= 0, %irq= 0.
>  ][AppID=Cisco AMC Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert
>
>
> Looking back just a bit further, and there are a TON of these.
>
> Nov 15 21:22:00 CMBL-03-01 local7 2 : 582: CMBL-03-01.localdomain: Nov 15
> 2018 23:22:00.256 UTC :  %UC_RTMT-2-RTMT_ALERT: %[
> AlertName=HardwareFailure][AlertDetail= At Thu Nov 15 21:22:00 BRST
> 2018 on node 192.168.183.3, the following HardwareFailure events generated:
>  hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4 Director Agent: 
> LSIESG_DiskDrive_Modified
> 500605B0027C6D50 Command timeout on PD 01(e0xfc/s1) Path
> 50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00 Sev: 3. AppID : Cisco
> Syslog Agent ClusterID :  NodeID : CMBL-03-01  TimeStamp : Thu Nov 15
> 21:21:26 BRST 2018   hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4
> Director Agent: LSIESG_AlertIndication 500605B0027C6D50 Command timeout on
> PD 01(e0xfc/s1) Path 50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00
> Sev: 3. AppID : Cisco Syslog Agent ClusterID :  NodeID : CMBL-03-01
>  TimeStamp : Thu Nov 15 21:21:27 BRST 2018   hwStringMatch : Nov 15
> 21:21:26 CMBL-03-01][AppID=Cisco AMC
> Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert
>
>
> You’ve lost or are in the middle of losing at least one disk drive. It
> probably lost them all at the same time on the 13th and the OS marked the
> entire filesystem readonly.
>
> -Ryan
>
> On Dec 3, 2018, at 9:28 AM, Nilson Costa  wrote:
>
> Hello All,
>
> I´m deploying a new CUCM on a customer that has an old one working just as
> call routing for a Genesys system for call center.
>
> As you can see the picture below, they have some MGCP Gateways connected
> to this CUCM where the calls come in and via some CTI route points,
> controlled by Genesys, route the call to to 2 Avaya PBX or to a another CUCM
>
> 
> On november 13th they lost access to Tomcat on the Publisher, when we
> looked at the server several services were restarting including Cisco
> CallManager, just on the Publisher.
> We decided to reboot the whole cluster, but after the reboot we are facing
> some wierd issues that are not that relevant, I think, but there is one
> which we are really worried
>
> The Cisco CallManager process are still restarting ramdomly and generating
> some coredumps I´m attaching this logs here also I´m attaching the syslogs
> from the publisher.
>
> Can anybody here on the group help me finding out what is triggering the
> Cisco CallManager restart?
>
> --
> Nilson Lino da Costa Junior
> 
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>

-- 
Nilson Lino da Costa Junior
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

2018-12-03 Thread Ryan Ratliff (rratliff) via cisco-voip

#1  0x044a9935 in raise () from /lib/tls/libc.so.6
#2  0x044ab399 in abort () from /lib/tls/libc.so.6
#3  0x0842e457 in preabort () at ProcessCMProcMon.cpp:80
#4  0x0842fe7c in CMProcMon::verifySdlRouterServices () at 
ProcessCMProcMon.cpp:720

The ccm process is killing itself because it isn’t getting enough resources.

Nov 29 17:26:12 CMBL-03-01 local7 2 : 1: CMBL-03-01.localdomain: Nov 29 2018 
19:26:12.340 UTC :  %UC_CALLMANAGER-2-CallManagerFailure: 
%[HostName=CMBL-03-01][IPAddress=192.168.183.3][Reason=4][Text=CCM Intentional 
Abort: SignalName: SIPSetupInd, DestPID: SIPD[1:100:67:7]][AppID=Cisco 
CallManager][ClusterID=StandAloneCluster][NodeID=CMBL-03-01]: Indicates an 
internal failure in Unified CM

So much good info in the syslog.
Here’s a super-useful tidbit.

Nov 28 03:59:23 CMBL-03-01 local7 2 : 1543: CMBL-03-01.localdomain: Nov 28 2018 
05:59:23.840 UTC :  %UC_RTMT-2-RTMT_ALERT: 
%[AlertName=CallProcessingNodeCpuPegging][AlertDetail= Processor load over 
configured threshold for configured duration of time . Configured high 
threshold is 90 % tomcat (2 percent) uses most of the CPU.
 Processor_Info:

 For processor instance 1: %CPU= 99, %User= 2, %System= 2, %Nice= 0, %Idle= 0, 
%IOWait= 97, %softirq= 0, %irq= 0.

 For processor instance _Total: %CPU= 93, %User= 2, %System= 1, %Nice= 0, 
%Idle= 7, %IOWait= 90, %softirq= 0, %irq= 0.

 For processor instance 0: %CPU= 86, %User= 2, %System= 1, %Nice= 0, %Idle= 14, 
%IOWait= 83, %softirq= 0, %irq= 0.

 For processor instance 3: %CPU= 87, %User= 2, %System= 2, %Nice= 0, %Idle= 13, 
%IOWait= 83, %softirq= 0, %irq= 0.

 For processor instance 2: %CPU= 99, %User= 4, %System= 1, %Nice= 0, %Idle= 0, 
%IOWait= 96, %softirq= 0, %irq= 0.
 ][AppID=Cisco AMC Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert

Looking back just a bit further, and there are a TON of these.

Nov 15 21:22:00 CMBL-03-01 local7 2 : 582: CMBL-03-01.localdomain: Nov 15 2018 
23:22:00.256 UTC :  %UC_RTMT-2-RTMT_ALERT: 
%[AlertName=HardwareFailure][AlertDetail= At Thu Nov 15 21:22:00 BRST 2018 
on node 192.168.183.3, the following HardwareFailure events generated:  
hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4 Director Agent: 
LSIESG_DiskDrive_Modified 500605B0027C6D50 Command timeout on PD 01(e0xfc/s1) 
Path 50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00 Sev: 3. AppID : Cisco 
Syslog Agent ClusterID :  NodeID : CMBL-03-01  TimeStamp : Thu Nov 15 21:21:26 
BRST 2018   hwStringMatch : Nov 15 21:21:26 CMBL-03-01 daemon 4 Director Agent: 
LSIESG_AlertIndication 500605B0027C6D50 Command timeout on PD 01(e0xfc/s1) Path 
50e116ac4ce2, CDB: 2a 00 10 98 b9 9d 00 00 08 00 Sev: 3. AppID : Cisco 
Syslog Agent ClusterID :  NodeID : CMBL-03-01  TimeStamp : Thu Nov 15 21:21:27 
BRST 2018   hwStringMatch : Nov 15 21:21:26 CMBL-03-01][AppID=Cisco AMC 
Service][ClusterID=][NodeID=CMBL-03-01]: RTMT Alert

You’ve lost or are in the middle of losing at least one disk drive. It probably 
lost them all at the same time on the 13th and the OS marked the entire 
filesystem readonly.

-Ryan

On Dec 3, 2018, at 9:28 AM, Nilson Costa 
mailto:nilsonl...@gmail.com>> wrote:

Hello All,

I´m deploying a new CUCM on a customer that has an old one working just as call 
routing for a Genesys system for call center.

As you can see the picture below, they have some MGCP Gateways connected to 
this CUCM where the calls come in and via some CTI route points, controlled by 
Genesys, route the call to to 2 Avaya PBX or to a another CUCM


On november 13th they lost access to Tomcat on the Publisher, when we looked at 
the server several services were restarting including Cisco CallManager, just 
on the Publisher.
We decided to reboot the whole cluster, but after the reboot we are facing some 
wierd issues that are not that relevant, I think, but there is one which we are 
really worried

The Cisco CallManager process are still restarting ramdomly and generating some 
coredumps I´m attaching this logs here also I´m attaching the syslogs from the 
publisher.

Can anybody here on the group help me finding out what is triggering the Cisco 
CallManager restart?

--
Nilson Lino da Costa Junior
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Telepresence DX 80 CE 8.x to 9.5 and CTL vs ITL

2018-12-03 Thread Ryan Ratliff (rratliff) via cisco-voip

CTS is immersive endpoints, TX, CTS, IX, and the like.

TC and CE both have supported ITL and CTL for quite some time. There was 
probably just a bug in 8.2 that was fixed in 9.5.

I know for sure TVS was pretty broken before a recent 9.x version.

-Ryan

On Nov 30, 2018, at 7:24 PM, Jason Aarons (Americas) 
mailto:jason.aar...@dimensiondata.com>> wrote:



Found the problem, appears CTS only used CTL and not ITL.  Did that change with 
CE 9.5 ?
https://community.cisco.com/t5/telepresence-and-video/telepresence-endpoints-itl-security-by-default/td-p/2702643


Pubs and subs have CTL, but not new subs.
admin:show ctl
Length of CTL file: 0
CTL File not found. Please run CTLClient plugin or run the CLI - utils ctl.. to 
generate the CTL file.
Error parsing the CTL File.


Looks like they ran a USB hardware eToken on the cluster,  I’d rather do a 
“utils ctl set-cluster non-secure-mode” and reboot cluster then convert to 
Tokenless CTL.

Jason Aarons, CCIEx2 No. 38564
Advanced Technology Consultant
Dimension Data
904-338-3245

From: Jason Aarons (Americas)
Sent: Friday, November 30, 2018 6:23 PM
To: cisco-voip (cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Telepresence DX 80 CE 8.x to 9.5 and CTL vs ITL

Anyone familiar about changes in CE endpoints going from 8.2 to 9.5 ?  Did 
older video endpoints use CTL and maybe change to ITL?



I added some new subscribers and TFTP server (realized now without running the 
capf utility) , and noticed the DX80s have issues talking to new subs/tftp (we 
are in Mixed Mode) but if I upgrade 9.5+ CE they work fine.  Maybe the upgrade 
is resetting security settings?  Kind of stumped why upgrade fixes problem.  
Also think I need to run a “tils ctl set-cluster non-secure-mode” and reboot 
cluster.  Don’t really need mixed-mode.






Jason Aarons, CCIEx2 No. 38564
Advanced Technology Consultant
Dimension Data
904-338-3245



This email and all contents are subject to the following disclaimer:
"http://www.dimensiondata.com/emaildisclaimer;
 ___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] 11.x Mixed mode back to Insecure

Re: [cisco-voip] 500 Series Headsets Saying Disabled

Re: [cisco-voip] 500 Series Headsets Saying Disabled

Re: [cisco-voip] 500 Series Headsets Saying Disabled

[cisco-voip] 500 Series Headsets Saying Disabled

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

Re: [cisco-voip] CallManager Process being restarted (8.5(1))

Re: [cisco-voip] Telepresence DX 80 CE 8.x to 9.5 and CTL vs ITL

10 matches

Site Navigation

Mail list logo

Footer information