04-22-2013 12:43 PM
Hello,
I have tried to deploy 1040 sensors in a lab environment and the sensors are not registering with the Assurance server. I see a packet received on port 2000 of the server but the server isn't responding. The sensor shows "Not communicating with the receiver". I've tried restarting the services and rebooting the entire VM with the same results.
Below is the information displayed on the 1040 sensor when viewed from the web browser:
Device Information:
ID | B4E9B08CA4A3 |
MAC Address | B4E9B08CA4A3 |
Time stamp | 00:01:48 01/01/1970 |
Status | not communicating with receiver |
Current Service Monitor | |
TFTP IP Address | 10.1.24.10 |
Switch IP Address | 10.1.24.51 |
Switch Port | GigabitEthernet0/2 |
Software Version | SvcMonAB2_102 |
Last Updated | 4_23_2013-8_49_43.379 |
Communication:
Retrieve QOVB4E9B08CA4A3.CNF from 10.1.24.10 successfully | |
Configuration file | QOVB4E9B08CA4A3.CNF |
Receiver=10.1.60.108;10.1.60.108; ID=B4E9B08CA4A3 Image=SvcMonAB2_102.img LastUpdated=4_23_2013-8_49_43.379 CDPGlobalRunState=true SyslogPort=UDP:5666 SkinnyPort=TCP:2000 |
Diagnostics:
Current Time | 00:05:07 01/01/1970 |
Clock Drift | ? second(s) |
Last Analysis Time | |
Streams Analyzed | 0 |
Last Communication | |
Last Successful Report Time | |
Report Destination | |
Report Length (bytes) | |
Received Packets | 0 |
Receive Errors | 0 |
Packets Dropped | 0 |
Buffer overruns | 0 |
Framing errors | 0 |
Interface promiscuous | yes |
A tcpdump via root on the server shows the following incoming packet to the server but no response is sent:
18:31:02.349972 IP 10.1.24.105.1024 > LACPCA1.2000: S 39146440:39146440(0) win 5840 <mss 1460,sackOK,timestamp 2265 0,nop,wscale 0>
A "show ports" from the server shows tcp port 2000 opened by the QOVR process:
Process : CSCO.QOVR (23896)
tcp: :::5665, :::5666, :::5667, :::5668, :::5669, :::5670, :::5671, :::5672
, :::5673, :::5674, :::5675, :::5676, :::5677, :::5678, :::5679, :::5680, :::2000, :::5681, :::5682, :::5683, :::5684
udp: :::5666
I attempted to stop the process using the "pdterm QOVR" command and waited 5 minutes and then issued the "pdexec QOVR" command. I also tried "application stop cpcm" and then the "application start cpcm". I added a second 1040 sensor with the same results.
Thanks,
Pat Devaney
Solved! Go to Solution.
04-26-2013 07:49 AM
Hi Patrick
can you try the following and let us know if this resolves your issue . there was a bug on the 1040 registration for which the workaround is below
Run following commands from teh cli after logging in as root via ssh. Use port 26 for ssh on the assurance server
/sbin/iptables -A INPUT -p tcp --dport 2000 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 5666 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 69 -j ACCEPT
Then reset the 1040 from the
System Setup > 1040 Sensors > Management
link in the UI
thx
PRem
04-26-2013 07:49 AM
Hi Patrick
can you try the following and let us know if this resolves your issue . there was a bug on the 1040 registration for which the workaround is below
Run following commands from teh cli after logging in as root via ssh. Use port 26 for ssh on the assurance server
/sbin/iptables -A INPUT -p tcp --dport 2000 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 5666 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 69 -j ACCEPT
Then reset the 1040 from the
System Setup > 1040 Sensors > Management
link in the UI
thx
PRem
04-29-2013 08:27 AM
Hi Prem,
That took care of the registration issue.
Thanks,
Pat
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: