This Perl script is useful to extract system information for CTS logs files and send you an email with its details.
Main features:
- CTS version
- System model
- System errors
- Codec and Display Serial numbers
- Display model
- Uptime
- IP address information
- Check if your system is affected by latest Field Notices
- CTS Manager and CUCM information
I have found around 3 DDTS for 1 day of use, (Looking for more!)
Please suggest any feature request or any bug you find so I can fix it.
I attach the script for your personal use, this one requires couple of changes (HTTP Proxy and SMTP email address) and basic knowledge of Perl
This is a 0.X version so I'm working in improving run time and reduce duplicate code for secondary codecs once is more stable
Feedback is welcome
Please download script from here:
http://docs.google.com/leaf?id=0B47-vpuz_NefNmVhOTE2MmMtMmU5NC00OTczLWE5NGUtNTkwMmQ1NzczNDM2&hl=en
Friday, April 30, 2010
CTS System - Debugging with Cisco IP Phone
Always obtain an accurate problem description
- Phone model
- Current phone firmware
- CUCM version
- Sniffer capture (wireshark), CUCM SDI/SDL detailed traces
Create a ssh session to the phone using SSH using CUCM
Login with User and password provided in CUCM
Once you get login, second prompt use:
login:default
passwd:user
Enable debugs depending upon call features, as described below.
To use the debugsh either login in as debug/debug or login as default/user then start the debug shell via 'debugsh'. Type 'help' and '?' for more information.
Enable strace
At the prompt type
strace&
In order to see SIP debugs the JVM logging level must be set to Debug. Enter the debugsh and invoke the following command:
debugsh
jvm logging level DEBUG
The logging level will be saved across a reboot.
Save SIP debug settings across reboot
Use the following command in the debug shell to create a file that will be loaded once the JVM starts.
store sip-debugs
show dialplan
show config
debug remote-cc dialplan gsm fsm fim lsm vcm sip-messages sip-state sip-task kpml
Additional debugs based on features
Following are the additional debugs that should be enabled based on features
For Registration issue
show reg
debug sip-reg
For UI related issue
show reg
debug sip-adapter
To disable debugs
debugsh
jvm logging level NONE
login: default
password:
sh 3.0 (1.5)
%
% strace&
% debugsh
0013C3E248EA> jvm logging level DEBUG
0013C3E248EA> debug remote-cc dialplan gsm fsm fim lsm vcm sip-messages sip-state sip-task kpml
- Phone model
- Current phone firmware
- CUCM version
- Sniffer capture (wireshark), CUCM SDI/SDL detailed traces
- SSH into the Phone
Create a ssh session to the phone using SSH using CUCM
Login with User and password provided in CUCM
Once you get login, second prompt use:
login:default
passwd:user
- Debug Interface
Enable debugs depending upon call features, as described below.
To use the debugsh either login in as debug/debug or login as default/user then start the debug shell via 'debugsh'. Type 'help' and '?' for more information.
Enable strace
At the prompt type
strace&
- Enable JVM debugs
In order to see SIP debugs the JVM logging level must be set to Debug. Enter the debugsh and invoke the following command:
debugsh
jvm logging level DEBUG
The logging level will be saved across a reboot.
Save SIP debug settings across reboot
Use the following command in the debug shell to create a file that will be loaded once the JVM starts.
store sip-debugs
- Debugs for SIP phone features
show dialplan
show config
debug remote-cc dialplan gsm fsm fim lsm vcm sip-messages sip-state sip-task kpml
Additional debugs based on features
Following are the additional debugs that should be enabled based on features
For Registration issue
show reg
debug sip-reg
For UI related issue
show reg
debug sip-adapter
To disable debugs
debugsh
jvm logging level NONE
- Example
login: default
password:
sh 3.0 (1.5)
%
% strace&
% debugsh
0013C3E248EA> jvm logging level DEBUG
0013C3E248EA> debug remote-cc dialplan gsm fsm fim lsm vcm sip-messages sip-state sip-task kpml
CTS System - Phone Midlet debugging
The following article describe the steps needed to verify IP phone internal modules when Midlet is being loaded.
In cases with new versions and when configuration has been already verified, TAC and Engineering require deep debug levels to verify software behavior.
Requirements
- IP Phone load 8.3.4 and up
- CUCM Version 7.0 and up
- CTS 1.5.0(1879) and up
Supported Models
Model Display Navigation Touchscreen Notes
7921 Color 4-way plus Select No
7941/61 Grayscale 2-way (vertical) No
7942/62 Grayscale 2-way (vertical) No
7945/65 Color 4-way plus Select No
7970/71 Color 4-way Yes
7975 Color 4-way plus Select Yes
* Verify TelePresence documentation for supported models
IP Phone
- Collect via Web IP Phone console logs
- For more detail debugging we can collect logs via SSH
By default, System.out and System.err output does not get sent to the phone's default console output, so it won't show up on the phone's serial port or on SSH shell sessions unless
it is specifically enabled.
To enable Java output on the console for testing and debugging purposes, perform the following:
Connect to IP Phone using the procedure outlined here:
http://mytelepresence.blogspot.com/2010/04/telepresence-system-debugging-with.html
Enable following debugs:
debug auth
debug jvm ALL
debug jvm MIDP-MIDlet
debug jvm MIDP-MIDletSuite
debug jvm MIDP-IO
debug jvm Services
debug jvm Security
debug jvm XML
debug ui
In cases with new versions and when configuration has been already verified, TAC and Engineering require deep debug levels to verify software behavior.
Requirements
- IP Phone load 8.3.4 and up
- CUCM Version 7.0 and up
- CTS 1.5.0(1879) and up
Supported Models
Model Display Navigation Touchscreen Notes
7921 Color 4-way plus Select No
7941/61 Grayscale 2-way (vertical) No
7942/62 Grayscale 2-way (vertical) No
7945/65 Color 4-way plus Select No
7970/71 Color 4-way Yes
7975 Color 4-way plus Select Yes
* Verify TelePresence documentation for supported models
IP Phone
- Collect via Web IP Phone console logs
- For more detail debugging we can collect logs via SSH
By default, System.out and System.err output does not get sent to the phone's default console output, so it won't show up on the phone's serial port or on SSH shell sessions unless
it is specifically enabled.
To enable Java output on the console for testing and debugging purposes, perform the following:
Connect to IP Phone using the procedure outlined here:
http://mytelepresence.blogspot.com/2010/04/telepresence-system-debugging-with.html
Enable following debugs:
debug auth
debug jvm ALL
debug jvm MIDP-MIDlet
debug jvm MIDP-MIDletSuite
debug jvm MIDP-IO
debug jvm Services
debug jvm Security
debug jvm XML
debug ui
CTS System - Collect logs when GUI is down
When WebServer is not responding and logs need to be generated for CTS system please follow the next steps:
CTS gather log files when GUI is unavailable via regular SSH
1. Login via SSH with regular credentials
admin:utils logs generate other
Generating log files... this may take a while
0% preparing to get logs
10% add system state
15% add application state
35% add phone state
40% add application logs
60% add configuration files
65% add calendar files
70% add boot log files
75% add secondary logs
80% compress log files
100% get logs complete
2. Send logs to FTP server
admin:utils logs ftp gogasca cisco 10.82.246.189
Logs (logFiles_SEP0019AA043E58_2009.08.17.2110_tar.gz) sent successfully
3. In case new logs are not being generate, try with utils log abort command or verify with TAC if
files need to be removed from tmp directoy
In case you have root access:
1. Create remote account
admin:utils remote_account enable
Remote Support is now enabled
admin:
admin:utils remote_account create ciscotac 1
2. Login via SSH using remote account credentials
Checking when last Log files were generated:
CTS:>pwd
/var
CTS:>cat LastLogGenDate
1249951029
CTS:>cat LastLogGenDateFormatted
Mon Aug 10 17:37:09 PDT 2009
3. Go to /nv/logs directory
cd /nv/logs
4. Compress directories into a single file
tar -cvf filename.tar
With this format we will be able to extract this file using WinZip or any other common tool (7-zip, WinRAR, etc)
Example:
CTS:>tar -cvf logs.tar admingui apacheAccPipe apacheErrPipe apache_acc apache_err
admingui/
admingui/admingui.bin
admingui/admingui00000.log
admingui/admingui00001.log
admingui/admingui00002.log
admingui/admingui00003.log
apacheAccPipe
apacheErrPipe
apache_acc/
apache_acc/access.bin
apache_acc/access00000.log
apache_acc/access00001.log
apache_err/
apache_err/error.bin
apache_err/error00000.log
apache_err/error00001.log
apache_err/error00002.log
CTS:>ls -al l*
-rw-r-r- 1 root root 573440 Jul 1 15:45 logs.tar
Note* Dont create file from /nv/ since file wont be created and will generate an error, folders need to be entered one by one.
5. SFTP files to SFTP server (Minicore SFTP or FreeFTPd)
CTS:>ls -al l*
-rw-r-r- 1 root root 573440 Jul 1 15:45 logs.tar
CTS:>sftp cisco@171.69.55.109
Connecting to 171.69.55.109...
cisco@171.69.55.109's password:
sftp>
sftp> put logs.tar
Once in the sftp shell, you can run commands similar to those available on FTP,
such as cd, lcd, ls, chmod, chgrp, get, put, rename, and rmdir. You can end the session by typing exit at the prompt
CTS gather log files when GUI is unavailable via regular SSH
1. Login via SSH with regular credentials
admin:utils logs generate other
Generating log files... this may take a while
0% preparing to get logs
10% add system state
15% add application state
35% add phone state
40% add application logs
60% add configuration files
65% add calendar files
70% add boot log files
75% add secondary logs
80% compress log files
100% get logs complete
2. Send logs to FTP server
admin:utils logs ftp gogasca cisco 10.82.246.189
Logs (logFiles_SEP0019AA043E58_2009.08.17.2110_tar.gz) sent successfully
3. In case new logs are not being generate, try with utils log abort command or verify with TAC if
files need to be removed from tmp directoy
In case you have root access:
1. Create remote account
admin:utils remote_account enable
Remote Support is now enabled
admin:
admin:utils remote_account create ciscotac 1
2. Login via SSH using remote account credentials
Checking when last Log files were generated:
CTS:>pwd
/var
CTS:>cat LastLogGenDate
1249951029
CTS:>cat LastLogGenDateFormatted
Mon Aug 10 17:37:09 PDT 2009
3. Go to /nv/logs directory
cd /nv/logs
4. Compress directories into a single file
tar -cvf filename.tar
With this format we will be able to extract this file using WinZip or any other common tool (7-zip, WinRAR, etc)
Example:
CTS:>tar -cvf logs.tar admingui apacheAccPipe apacheErrPipe apache_acc apache_err
admingui/
admingui/admingui.bin
admingui/admingui00000.log
admingui/admingui00001.log
admingui/admingui00002.log
admingui/admingui00003.log
apacheAccPipe
apacheErrPipe
apache_acc/
apache_acc/access.bin
apache_acc/access00000.log
apache_acc/access00001.log
apache_err/
apache_err/error.bin
apache_err/error00000.log
apache_err/error00001.log
apache_err/error00002.log
CTS:>ls -al l*
-rw-r-r- 1 root root 573440 Jul 1 15:45 logs.tar
Note* Dont create file from /nv/ since file wont be created and will generate an error, folders need to be entered one by one.
5. SFTP files to SFTP server (Minicore SFTP or FreeFTPd)
CTS:>ls -al l*
-rw-r-r- 1 root root 573440 Jul 1 15:45 logs.tar
CTS:>sftp cisco@171.69.55.109
Connecting to 171.69.55.109...
cisco@171.69.55.109's password:
sftp>
sftp> put logs.tar
Once in the sftp shell, you can run commands similar to those available on FTP,
such as cd, lcd, ls, chmod, chgrp, get, put, rename, and rmdir. You can end the session by typing exit at the prompt
CTS Manager - Verify device associations in CUCM
We have received a few cases when customer have at least 2 CTS-Man servers active; as of now we only support 1. Both CTS Manager servers are pushing multiple notifications for same meeting causing CTS to dial incorrect meeting id when doing OBTP.
Unfortunately Cisco Unified Communication Manager Dependency Records does not have the option to verify which Application Users are associated to a particular Phone.
In order to do that, please verify the following:
1. Login via SSH to CUCM Publisher
2. Execute the following command:
run sql SELECT device.name, applicationuser.name FROM device INNER JOIN applicationuserdevicemap ON device.pkid = applicationuserdevicemap.fkdevice JOIN applicationuser ON applicationuser.pkid = applicationuserdevicemap.fkapplicationuser
WHERE device.name = 'SEPMACADDRESS'
Replace SEPMACADDRESS with your Device Name, you can use LIKE sentence as well (For reference verify SQL Documentation)
Query above will return DeviceName and All Application Users associated to the Device
Example:
admin:run sql SELECT device.name, applicationuser.name FROM device JOIN applicationuserdevicemap ON device.pkid = applicationuserdevicemap.fkdevice JOIN applicationuser ON applicationuser.pkid = applicationuserdevicemap.fkapplicationuser WHERE device.name = 'SEP0019AA043E58'
name name
=============== ==========
SEP0019AA043E58 CTMappuser
Unfortunately Cisco Unified Communication Manager Dependency Records does not have the option to verify which Application Users are associated to a particular Phone.
In order to do that, please verify the following:
1. Login via SSH to CUCM Publisher
2. Execute the following command:
run sql SELECT device.name, applicationuser.name FROM device INNER JOIN applicationuserdevicemap ON device.pkid = applicationuserdevicemap.fkdevice JOIN applicationuser ON applicationuser.pkid = applicationuserdevicemap.fkapplicationuser
WHERE device.name = 'SEPMACADDRESS'
Replace SEPMACADDRESS with your Device Name, you can use LIKE sentence as well (For reference verify SQL Documentation)
Query above will return DeviceName and All Application Users associated to the Device
Example:
admin:run sql SELECT device.name, applicationuser.name FROM device JOIN applicationuserdevicemap ON device.pkid = applicationuserdevicemap.fkdevice JOIN applicationuser ON applicationuser.pkid = applicationuserdevicemap.fkapplicationuser WHERE device.name = 'SEP0019AA043E58'
name name
=============== ==========
SEP0019AA043E58 CTMappuser
CTS Manager - OpenSSL and Exchange
Some customers running Exchange 2003 or 2007 require to enable HTTPS to establish a secure connection to Exchange servers
In case you want to use OpenSSL to generate certificate instead of Microsoft CA, please execute the following:
- Use IIS on your Windows machine to generate your IIS SSL certificate request file, which should be named certreq.txt by default.
You can use instructions described here:
http://www.digicert.com/csr-creation-microsoft-iis-5-6.htm
- Transfer this file to your Linux machine using whatever method you like.
- First, we need to generate a private key to sign the certificate with. Lets generate one that's 1024 bits. You'll need to enter a pass phrase too:
# openssl genrsa -des3 -out cakey.pem 1024
- Next, we'll need to create the CA certificate to sign with:
# openssl req -new -key cakey.pem -x509 -days 365 -out ca.cer
Finally, we'll need to sign the IIS certificate with our new CA:
# openssl x509 -req -days 365 -in certreq.txt -CA ca.cer -CAkey cakey.pem -CAcreateserial -out iis.cer
Your new, signed certificate is the file iis.cer.
In case you want to use OpenSSL to generate certificate instead of Microsoft CA, please execute the following:
- Use IIS on your Windows machine to generate your IIS SSL certificate request file, which should be named certreq.txt by default.
You can use instructions described here:
http://www.digicert.com/csr-creation-microsoft-iis-5-6.htm
- Transfer this file to your Linux machine using whatever method you like.
- First, we need to generate a private key to sign the certificate with. Lets generate one that's 1024 bits. You'll need to enter a pass phrase too:
# openssl genrsa -des3 -out cakey.pem 1024
- Next, we'll need to create the CA certificate to sign with:
# openssl req -new -key cakey.pem -x509 -days 365 -out ca.cer
Finally, we'll need to sign the IIS certificate with our new CA:
# openssl x509 -req -days 365 -in certreq.txt -CA ca.cer -CAkey cakey.pem -CAcreateserial -out iis.cer
Your new, signed certificate is the file iis.cer.
CTS System - Packet capture
Cisco CTS version 1.6 introduces utils network capture command, as you know this is a feature request for tcpdump to be accesible for users with no root access. (Available in 1.6.6)
In order to capture traffic from CTS when root access is available please execute the following:
1. Create remote account
admin:utils remote_account enable
Remote Support is now enabled
admin:
admin:utils remote_account create ciscotac 1
2. Login via SSH using remote account credentials
Login via SSH to Primary codec
3. Move to the following path
CTS:>pwd
/nv/log/
4. Create a new Directory to store our capture
CTS:>mkdir packet
* Creating the packet folder here may create a problem if we collect Logs from GUI afterwards, you may need to delete the folder after packet capture or creating the folder in different path
5. Start capture
CTS:>tcpdump -s 0 -i eth0 host 172.16.154.8 -w mycapture.pcap
* It is recommended to use filtering, if you plan to capture calls or other traffic which may generate big files, its recommended to span the switch port where CTS is connected
6. Reproduce the problem
7. Stop the capture
Type Control+C or add count limit to tcpdump command ( -c argument)
8. SFTP files to SFTP server (Minicore SFTP or FreeFTPd)
CTS:>sftp user@171.69.87.217
Connecting to 171.69.87.217...
The authenticity of host '171.69.87.21http://zed.cisco.com/confluence/pages/editpage.action?pageId=3552655977 (171.69.87.217)' can't be established.
RSA key fingerprint is 7c:3b:30:ff:6c:16:7b:03:c6:8c:95:9a:16:82:79:cb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '171.69.87.217' (RSA) to the list of known hosts.
gogasca@171.69.87.217's password:
Hello, I'm freeFTPd 1.0sftp>
sftp:> put mycapture.pcap
Uploading mycapture.pcap to /mycapture.pcap
mycapture.pcap 100% 772 0.8KB/s 00:00
sftp:>bye
8. If you are planning to collect files, make sure you delete the capture before you do that, since file is normally big*.
9. If no SFTP available collect capture file and rename it to be any log file already in the system (i.e nv/log/sysop/sysop00002.log in Sysop folder) be careful the file you select since can cause serious problems
Useful captures:
tcpdump -n -s 0 -i eth0 'udp and port 5060 and (host ip addr)' -vvvvvvv
tcpdump -s 0 -i eth0 host '( 172.16.154.8 and 172.16.181.39 )' -w mycapture.pcap -c 15000
tcpdump -s 0 -i eth0 'not port ssh and host 172.16.154.15' -w mycapture.pcap
* You may see packets 'dropped by kernel' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).
In order to capture traffic from CTS when root access is available please execute the following:
1. Create remote account
admin:utils remote_account enable
Remote Support is now enabled
admin:
admin:utils remote_account create ciscotac 1
2. Login via SSH using remote account credentials
Login via SSH to Primary codec
3. Move to the following path
CTS:>pwd
/nv/log/
4. Create a new Directory to store our capture
CTS:>mkdir packet
* Creating the packet folder here may create a problem if we collect Logs from GUI afterwards, you may need to delete the folder after packet capture or creating the folder in different path
5. Start capture
CTS:>tcpdump -s 0 -i eth0 host 172.16.154.8 -w mycapture.pcap
* It is recommended to use filtering, if you plan to capture calls or other traffic which may generate big files, its recommended to span the switch port where CTS is connected
6. Reproduce the problem
7. Stop the capture
Type Control+C or add count limit to tcpdump command ( -c argument)
8. SFTP files to SFTP server (Minicore SFTP or FreeFTPd)
CTS:>sftp user@171.69.87.217
Connecting to 171.69.87.217...
The authenticity of host '171.69.87.21http://zed.cisco.com/confluence/pages/editpage.action?pageId=3552655977 (171.69.87.217)' can't be established.
RSA key fingerprint is 7c:3b:30:ff:6c:16:7b:03:c6:8c:95:9a:16:82:79:cb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '171.69.87.217' (RSA) to the list of known hosts.
gogasca@171.69.87.217's password:
Hello, I'm freeFTPd 1.0sftp>
sftp:> put mycapture.pcap
Uploading mycapture.pcap to /mycapture.pcap
mycapture.pcap 100% 772 0.8KB/s 00:00
sftp:>bye
8. If you are planning to collect files, make sure you delete the capture before you do that, since file is normally big*.
9. If no SFTP available collect capture file and rename it to be any log file already in the system (i.e nv/log/sysop/sysop00002.log in Sysop folder) be careful the file you select since can cause serious problems
Useful captures:
tcpdump -n -s 0 -i eth0 'udp and port 5060 and (host ip addr)' -vvvvvvv
tcpdump -s 0 -i eth0 host '( 172.16.154.8 and 172.16.181.39 )' -w mycapture.pcap -c 15000
tcpdump -s 0 -i eth0 'not port ssh and host 172.16.154.15' -w mycapture.pcap
* You may see packets 'dropped by kernel' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0).
CTS System - MTR utility
MTR utility
mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool.
As mtr starts, it investigates the network connection between the host mtr runs on and HOSTNAME. by sending packets with purposly low TTLs. It continues to send packets with low TTL, noting the response time of the intervening routers. This allows mtr to print the response percentage and response times of the internet route to HOSTNAME. A sudden increase in packetloss or response time is often an indication of a bad (or simply overloaded) link.
Common values:
ef - EF dscp (101110) 46 - ToS (10111000) - 184
af31 - AF31 dscp (011010) 26 - ToS (01101000) - 104
cs3 - CS3 dscp (011000) 24 - ToS (01100000) - 96
cs4 - CS4 dscp (100000) 32 - ToS (10000000) - 128
cs5 - CS5 dscp (101000) 40 - ToS (10100000) - 160
af41 - AF41 dscp (100010) 34 - ToS (10001000) - 136
CTS regular CLI
utils network mtr 172.16.181.57 count 5 tos 104
Host - tos=0xB8 count=5 Last Avg Min Max
0 172.16.181.57 0.7 0.7 0.7 0.7
Linux MTR
mtr -r -c 100 172.16.181.57
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Drop Rcv Snt Last Best Avg Wrst StDev Gmean Jttr Javg Jmax Jint
1. 172.16.102.1 0.0% 32 0 32 32 0.9 0.8 1.0 6.2 0.9 0.9 0.1 0.4 5.3 6.7
2. 171.68.190.41 0.0% 32 0 32 32 1.0 0.9 1.0 1.5 0.1 1.0 0.5 0.1 0.5 2.1
3. 172.16.181.57 0.0% 31 0 31 31 1.1 1.0 1.1 1.2 0.0 1.1 0.0 0.0 0.1 0.7
Use Q command to set ToS field
mtr combines the functionality of the traceroute and ping programs in a single network diagnostic tool.
As mtr starts, it investigates the network connection between the host mtr runs on and HOSTNAME. by sending packets with purposly low TTLs. It continues to send packets with low TTL, noting the response time of the intervening routers. This allows mtr to print the response percentage and response times of the internet route to HOSTNAME. A sudden increase in packetloss or response time is often an indication of a bad (or simply overloaded) link.
Common values:
ef - EF dscp (101110) 46 - ToS (10111000) - 184
af31 - AF31 dscp (011010) 26 - ToS (01101000) - 104
cs3 - CS3 dscp (011000) 24 - ToS (01100000) - 96
cs4 - CS4 dscp (100000) 32 - ToS (10000000) - 128
cs5 - CS5 dscp (101000) 40 - ToS (10100000) - 160
af41 - AF41 dscp (100010) 34 - ToS (10001000) - 136
- Example:
CTS regular CLI
utils network mtr 172.16.181.57 count 5 tos 104
Host - tos=0xB8 count=5 Last Avg Min Max
0 172.16.181.57 0.7 0.7 0.7 0.7
Linux MTR
mtr -r -c 100 172.16.181.57
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Drop Rcv Snt Last Best Avg Wrst StDev Gmean Jttr Javg Jmax Jint
1. 172.16.102.1 0.0% 32 0 32 32 0.9 0.8 1.0 6.2 0.9 0.9 0.1 0.4 5.3 6.7
2. 171.68.190.41 0.0% 32 0 32 32 1.0 0.9 1.0 1.5 0.1 1.0 0.5 0.1 0.5 2.1
3. 172.16.181.57 0.0% 31 0 31 31 1.1 1.0 1.1 1.2 0.0 1.1 0.0 0.0 0.1 0.7
Use Q command to set ToS field
CTS System - SNMP Configuration
Configuring SNMP traps
- This is a summary of configuration needed to succesfully configure CTS system and CTS SNMP trap service to send alerts to a Linux server running net-snmp.
As of CTS version 1.6, the settings required to configure SNMP protocol in CTS are configured via CUCM Administration.
These settings include SNMP v2c/3 monitoring and system traps
In order to configure CTS system to send SNMP notifications (traps) in case specific events/errors occur in the system peripherals, is necessary to enable an specific OID:
ctpPeripheralErrorNotifyEnable = 1.3.6.1.4.1.9.9.643.1.1.1.0
This OID will cause CTS to send or not notifications
You will need snmpwalk and snmpset utilities which you can obtain from here:
Windows:
http://www.elifulkerson.com/articles/net-snmp-windows-binary-unofficial.php
Linux systems:
http://www.net-snmp.org/download.html
snmpset -m ALL -v2c -c readwrite_cts4 172.28.28.63 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
(Just change -A for the password configured in CUCM admin and change 172.16.181.57 for the CTS IP address)
Value 2, means that we are not going to send notifications (FALSE)
That's for the center codec
For left, right and presentation codecs:
In case value is not correct:
For center, left, right and presentation codecs:
snmpset -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
snmpset -n cts2 -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
snmpset -n cts3 -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
snmpset -n cts4 -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
Save SNMP change in each codec:
utils snmp save
- Obtain CTS server fixed content Engine OID (E)
TBOS 1.2 uses fixed context engine ID of 0x8000DEECAFE8111BEEFADE which is the one we are going to use to capture TRAPS
A) You can obtain CTS security engine OID (e) by logging in via CTS GUI and check SNMP settings
B) You can get root access and verify the following:
Look at the last line in /snmp/snmpd.conf.
So by entering the following command, we can obtain the security engine ID (e)
cat /snmp/snmpd.conf
Last line:
0x80001f88030019aa043e58
0x80001f8803001d4526e27a
SNMP client side (trap handler)
Reference:
http://www.net-snmp.org/wiki/index.php?title=TUT:Configuring_snmptrapd_to_receive_SNMPv3_notifications&printable=yes
1) Verify the system SNMP configuration path:
[root@asteriskvnt snmp]# net-snmp-config --snmpconfpath
/usr/local/etc/snmp:/usr/local/share/snmp:/usr/local/lib/snmp:/root/.snmp:/var/net-snmp
2) Edit snmptrapd.conf file (the path can be different)
vi /usr/local/etc/snmp/snmptrapd.conf
[root@asteriskvnt snmp]# cat snmptrapd.conf and add the fixed context engine (msgAuthoritativeEngineID)
the other security settings should match what is configured in CUCM
createUser -e 0x8000DEECAFE8111BEEFADE trapuser MD5 "C1sco123" DES
authuser log trapuser
Client
1) Start the SNMPtrapd daemon
snmptrapd -f -C -c /usr/local/etc/snmp/snmptrapd.conf -Le
[root@asteriskvnt snmp]# snmptrapd -f -C -c /usr/local/etc/snmp/snmptrapd.conf -Le
NET-SNMP version 5.5.rc1
2) Open a new window in same server to test the traps (use same engine ID in snmptrapd.conf)
snmptrap -v 3 -u trapuser -l authnoPriv -a MD5 -A C1sco123 -e 0x80001f88030019aa043e58 localhost 0 linkUp.0
For CTS:
Restart SNMP Service from CLI or generate trap
utils service restart SNMP_Srvr
check if trap is received from SNMP trap client
tcpdump -s 0 -i eth0 host 172.16.181.57 -vv
3) In client side you will see:
[root@asteriskvnt ~]# snmptrapd -f -C -c /usr/local/etc/snmp/snmptrapd.conf -Lo
NET-SNMP version 5.5.rc1
2009-09-11 18:50:10 [UDP: [172.16.181.57]:32780->[172.16.102.55]]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (43347) 0:07:13.47 SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-AGENT-MIB::nsNotifyShutdown SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-MIB::netSnmpNotificationPrefix
2009-09-11 18:50:19 [UDP: [172.16.181.57]:32781->[172.16.102.55]]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (89) 0:00:00.89 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
On either the server or the client side, enter:
tcpdump -s 0 -i eth0 host 172.16.181.57 -vv
tcpdump -s 0 -i eth0 udp port 162 -vvvv
In case you dont have root access of codec, use new utils network capture command (available in CTS 1.6) to examine any incoming packets.
On the server side, verify local traps are handled
snmptrap -v 3 -u trapuser -l authnoPriv -a MD5 -A C1sco123 -e 8000DEECAFE8111BEEFADE 0 linkUp.0
to see whether a field has been update or not.
Also on the server side,
ps -aef | grep snmp
to make sure SNMP daemon is alive.
- CTS system
- This is a summary of configuration needed to succesfully configure CTS system and CTS SNMP trap service to send alerts to a Linux server running net-snmp.
As of CTS version 1.6, the settings required to configure SNMP protocol in CTS are configured via CUCM Administration.
These settings include SNMP v2c/3 monitoring and system traps
In order to configure CTS system to send SNMP notifications (traps) in case specific events/errors occur in the system peripherals, is necessary to enable an specific OID:
ctpPeripheralErrorNotifyEnable = 1.3.6.1.4.1.9.9.643.1.1.1.0
This OID will cause CTS to send or not notifications
You will need snmpwalk and snmpset utilities which you can obtain from here:
Windows:
http://www.elifulkerson.com/articles/net-snmp-windows-binary-unofficial.php
Linux systems:
http://www.net-snmp.org/download.html
- If using SNMP v2c:
Please replace readwrite with the ReadWrite community string defined in CallManager
For left, right and presentation codecs:
snmpset -m ALL -v2c -c readwrite_cts2 172.28.28.63 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1 snmpset -m ALL -v2c -c readwrite_cts3 172.28.28.63 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1snmpset -m ALL -v2c -c readwrite_cts4 172.28.28.63 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
Use _cts4 for presentation codec (Note: that IP address is the same, we just added _cts2,3 or 4 to the string)
- If using SNMP v3:
snmpwalk -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0
SNMPv2-SMI::enterprises.9.9.643.1.1.1.0 = INTEGER: 2
(Just change -A for the password configured in CUCM admin and change 172.16.181.57 for the CTS IP address)
Value 2, means that we are not going to send notifications (FALSE)
That's for the center codec
For left, right and presentation codecs:
snmpwalk -v 3 -n cts2 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0
snmpwalk -v 3 -n cts3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0
snmpwalk -v 3 -n cts4 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0
In case value is not correct:
For center, left, right and presentation codecs:
snmpset -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
snmpset -n cts2 -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
snmpset -n cts3 -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
snmpset -n cts4 -v 3 -u admin -l authnoPriv -a MD5 -A C1sco123 -m ALL 172.16.181.57 1.3.6.1.4.1.9.9.643.1.1.1.0 i 1
Save SNMP change in each codec:
utils snmp save
- Trap server
ftp://ftp.cisco.com/pub/mibs/v2/CISCO-TELEPRESENCE-CALL-MIB.my
- Obtain CTS server fixed content Engine OID (E)
TBOS 1.2 uses fixed context engine ID of 0x8000DEECAFE8111BEEFADE which is the one we are going to use to capture TRAPS
A) You can obtain CTS security engine OID (e) by logging in via CTS GUI and check SNMP settings
B) You can get root access and verify the following:
Look at the last line in /snmp/snmpd.conf.
So by entering the following command, we can obtain the security engine ID (e)
cat /snmp/snmpd.conf
Last line:
0x80001f88030019aa043e58
0x80001f8803001d4526e27a
SNMP client side (trap handler)
Reference:
http://www.net-snmp.org/wiki/index.php?title=TUT:Configuring_snmptrapd_to_receive_SNMPv3_notifications&printable=yes
1) Verify the system SNMP configuration path:
[root@asteriskvnt snmp]# net-snmp-config --snmpconfpath
/usr/local/etc/snmp:/usr/local/share/snmp:/usr/local/lib/snmp:/root/.snmp:/var/net-snmp
2) Edit snmptrapd.conf file (the path can be different)
vi /usr/local/etc/snmp/snmptrapd.conf
[root@asteriskvnt snmp]# cat snmptrapd.conf and add the fixed context engine (msgAuthoritativeEngineID)
the other security settings should match what is configured in CUCM
createUser -e 0x8000DEECAFE8111BEEFADE trapuser MD5 "C1sco123" DES
authuser log trapuser
- Testing Traps
Client
1) Start the SNMPtrapd daemon
snmptrapd -f -C -c /usr/local/etc/snmp/snmptrapd.conf -Le
[root@asteriskvnt snmp]# snmptrapd -f -C -c /usr/local/etc/snmp/snmptrapd.conf -Le
NET-SNMP version 5.5.rc1
2) Open a new window in same server to test the traps (use same engine ID in snmptrapd.conf)
snmptrap -v 3 -u trapuser -l authnoPriv -a MD5 -A C1sco123 -e 0x80001f88030019aa043e58 localhost 0 linkUp.0
For CTS:
Restart SNMP Service from CLI or generate trap
utils service restart SNMP_Srvr
check if trap is received from SNMP trap client
tcpdump -s 0 -i eth0 host 172.16.181.57 -vv
3) In client side you will see:
[root@asteriskvnt ~]# snmptrapd -f -C -c /usr/local/etc/snmp/snmptrapd.conf -Lo
NET-SNMP version 5.5.rc1
2009-09-11 18:50:10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (43347) 0:07:13.47 SNMPv2-MIB::snmpTrapOID.0 = OID: NET-SNMP-AGENT-MIB::nsNotifyShutdown SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-MIB::netSnmpNotificationPrefix
2009-09-11 18:50:19
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (89) 0:00:00.89 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
Troubleshooting
On either the server or the client side, enter:
tcpdump -s 0 -i eth0 host 172.16.181.57 -vv
tcpdump -s 0 -i eth0 udp port 162 -vvvv
In case you dont have root access of codec, use new utils network capture command (available in CTS 1.6) to examine any incoming packets.
On the server side, verify local traps are handled
snmptrap -v 3 -u trapuser -l authnoPriv -a MD5 -A C1sco123 -e 8000DEECAFE8111BEEFADE
to see whether a field has been update or not.
Also on the server side,
ps -aef | grep snmp
to make sure SNMP daemon is alive.
Subscribe to:
Posts (Atom)