BMC Atrium Discovery Community Forum

This forum is now closed. Please check sticky posts and announcements for further information.

Links to new community:

forgot password?
   
1 of 3
1
Scanning continues though it does not respond to a ping
Posted: 25 January 2013 01:47 PM   [ Ignore ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

I scanned a couple of subnets (510 IPs) and I currently have the setting for ping first set to yes and I got a lot of IPs showing skipped. I know for a fact that there are only 17 devices across the 510 IPs I scanned. For some reason ADDM is continuing to process though these IPS do not respond to a ping (I tested through the CLI in order to make sure.) I am using ADDM 9.0. Has anyone else seen this or knows a way to fix it? It is throwing off my list that I give to the provisioning team for them to make sure my credentials are on all devices in our company.

Profile
 
 
Posted: 25 January 2013 06:35 PM   [ Ignore ]   [ # 1 ]  
BMC ADDM Staff
RankRankRankRank
Administrator
Total Posts:  2089
Joined:  2008-02-12

I don’t see that in our test or internal environment.

Profile
 
 
Posted: 25 January 2013 06:54 PM   [ Ignore ]   [ # 2 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

I can give you screenshots if you would like. I’m not sure my company will allow me to do a record. I was wondering if it could be a firewall issue, but I do not know what would make a false positive like that. Does ADDM use a standard ICMP ping or does it do a different type example: specific to a port or does it could nmap as its ‘ping’?

Profile
 
 
Posted: 28 January 2013 08:04 AM   [ Ignore ]   [ # 3 ]  
BMC ADDM Staff
RankRankRankRank
Administrator
Total Posts:  2089
Joined:  2008-02-12

nmap is used to ping machines so it will use more than a simple ICMP ping.

Profile
 
 
Posted: 28 January 2013 11:04 AM   [ Ignore ]   [ # 4 ]  
RankRankRankRank
Guru
Total Posts:  93
Joined:  2011-07-08

Hi,

I am also facing the same issue and in the same subnet where ADDM is located(IPs are not live but going into skipped)

Profile
 
 
Posted: 28 January 2013 12:04 PM   [ Ignore ]   [ # 5 ]  
RankRankRankRank
Guru
Total Posts:  169
Joined:  2012-11-09

Did brief scan from ADDM 9.0 of an /22 subnet.
Got 10 success, 10 no access, 768 no response and 234 skipped, from those 234 some also not respond to PING.
There could be just ICMP blocking and also different credentials to access(even thought we got an admin level credentials for whole subnet).

[ Edited: 28 January 2013 12:39 PM by Andrey Andreev]
Profile
 
 
Posted: 28 January 2013 02:02 PM   [ Ignore ]   [ # 6 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

Her eis a screenshot of a test from the scanner that shows so many skipped IPs, though they cannot be pinged.

If BMC would like, I will reaise a ticket for this and provide more data (if my company allows). Please let me know how you want to handle this. it looks like I might not be alone. getDeviceInfo succeeds, but it looks like it takes the info from nmap as real data.

I figured I’d put this screenshot out there as well. ADDM is thinking that x.x.x.0 IP address is responding to a ping as well and therefore marks it as skipped. I need to know how to fix this, or at least what I should tell my teams to look at.

[ Edited: 28 January 2013 09:02 PM by Timothy Onyskin]
Image Attachments
Skipped.jpgIP.jpg
Profile
 
 
Posted: 31 January 2013 07:14 PM   [ Ignore ]   [ # 7 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

UPDATE: We found that if we turn OFF the “ping before discovery” setting, most of the endpoints now show up as NoResponse where as with it ON it showed Skipped. We’re not sure why, but it seems like when we scan through a firewall, ADDM acts the exact opposite as we would expect (doesn’t ping = discovery stops where ping = discovery continues).

For some reason we still see that x.x.x.0 is detected and scanned, but now it is Opting it to a network switch. I did not think ADDM would even look at a x.x.x.0 IP address in the old version and it looks like it is now. I think it is about time to open a support case as the number of Skipped IPs filled up our datastore and made it crash… and without the online compact, we had to blank the datastore in order to get ADDM back up and running. I think BMC should put the online compact (or something like it) back in the next version since many customers (OUR users) cannot be down for hours/days while we compact a datastore.

[ Edited: 31 January 2013 09:03 PM by Timothy Onyskin]
Profile
 
 
Posted: 19 February 2013 05:20 PM   [ Ignore ]   [ # 8 ]  
RankRank
Member
Total Posts:  31
Joined:  2012-12-07

Is there any variable that stores the Success or failure (Up/Down) state of the initial Ping test? If discovery access is configured to do “Ping before Scanning”, there must be some place this flag is set or stored.

I am using ADDM 9.0. Not sure if I am facing the same problem as being discussed.It would be nice to pull a report with Ping status of corresponding Hostnames. This can make the trouble shooting easier.

Profile
 
 
Posted: 19 February 2013 05:30 PM   [ Ignore ]   [ # 9 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

I’m not sure. So far my Communication Services group have found this when looking at a tcpdump:

“The conversation had two packets one from your server to the endpoint, and the other was from the local Cisco switch back to your server. The Cisco switch sent a reset packet back to your server. The Cisco switch does not have a route to that subnet, so it sent back the proper response to your server, a reset packet.”

ADDM seems to have interpted this as a “valid response” and continued scanning the endpoint.

It sounds like I need to open a support ticket or is this something that is not related to ADDM?

Profile
 
 
Posted: 20 February 2013 06:27 PM   [ Ignore ]   [ # 10 ]  
BMC ADDM Staff
RankRankRankRank
Administrator
Total Posts:  2089
Joined:  2008-02-12

Can you try adding —send-ip to your list of nmap options to see if that produces a different result?

Profile
 
 
Posted: 20 February 2013 06:53 PM   [ Ignore ]   [ # 11 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

Same results. If I add the -PE arg it makes it work right.

Profile
 
 
Posted: 20 February 2013 07:02 PM   [ Ignore ]   [ # 12 ]  
RankRank
Member
Total Posts:  31
Joined:  2012-12-07
Kaustubh - 19 February 2013 05:20 PM
Is there any variable that stores the Success or failure (Up/Down) state of the initial Ping test? If discovery access is configured to do “Ping before Scanning”, there must be some place this flag is set or stored. I am using ADDM 9.0. Not sure if I am facing the same problem as being discussed.It would be nice to pull a report with Ping status of corresponding Hostnames. This can make the trouble shooting easier.

I’ll need a ping status variable to work with.. Any suggestions..

Profile
 
 
Posted: 20 February 2013 07:18 PM   [ Ignore ]   [ # 13 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

I would assume that all “NoResponse” would mean that the ping failed (or was blocked by a firewall) and therefore “Down” in ADDM’s eyes & everything else is “Up”.

Profile
 
 
Posted: 20 February 2013 08:28 PM   [ Ignore ]   [ # 14 ]  
BMC ADDM Staff
RankRankRankRank
Administrator
Total Posts:  2089
Joined:  2008-02-12

Could you run nmap with -d3 to see what it is doing.

Profile
 
 
Posted: 20 February 2013 08:39 PM   [ Ignore ]   [ # 15 ]  
RankRankRankRank
Guru
Total Posts:  597
Joined:  2011-03-16

Is there a way to modify the nmap command that ADDM uses during discovery?

I got:

Host is upreceived reset (0.00021s latency).
Scanned at 2013-02-20 15:40:31 EST for 1s
PORT     STATE         SERVICE        REASON
21
/tcp   filtered      ftp            no-response
22
/tcp   filtered      ssh            no-response
23
/tcp   filtered      telnet         no-response
80
/tcp   filtered      http           no-response
135
/tcp  filtered      msrpc          no-response
443
/tcp  filtered      https          no-response
513
/tcp  filtered      login          no-response
902
/tcp  filtered      iss-realsecure no-response
3940
/tcp filtered      xecp-node      no-response
161
/udp  open|filtered snmp           no-response
Final times for hostsrtt207 rttvar5000  to100000

Read from 
/usr/bin/../share/nmapnmap-payloads nmap-services.
Nmap done1 IP address (1 host upscanned in 1.55 seconds
           Raw packets sent
(328B) | Rcvd(40B

[ Edited: 20 February 2013 08:41 PM by Timothy Onyskin]
Profile
 
 
   
1 of 3
1