Rod
We had a similar issue to your Checkpoint issue on a customer site last year 
with Nokia firewalls (possibly the same code I guess). With an incorrect 
community string the device stays green but no values are returned to snmp 
requests via OneClick views etc.

We took some wireshark traces and noticed that when the incorrect community 
string is used the device returns a get-response with error-status = 
authorizationError. While this appears to be a valid SNMP response it isn't the 
norm for most SNMP devices. Most devices will not respond to an invalid 
community string and that's what Spectrum is expecting.

So as regards contact status Spectrum takes the response as meaning that it's 
received an snmp response hence the device stays green. It would appear that 
Spectrum does not look at the error-status value in the get-response. Now you 
could argue that as the device is up and responding to SNMP then the green 
condition is valid. However as any request for SNMP data via OneClick views etc 
does not return any value then I think the green condition is not exactly 
correct. We have raised an enhancement request to create a new alarm for this 
situation.

Regards, John

-----Original Message-----
From: Olliver, Roderick [mailto:[email protected]] 
Sent: 08 April 2009 14:42
To: spectrum
Subject: RE: [spectrum] Spectrum handling for traps with "agent-addr 0.0.0.0"


Marcel, Bill,

We had a similar issue in recent weeks - apparently "SNMP Agent Address" is 
configurable on the Checkoints, but it defaults to 0.0.0.0

Another gotcha, that we have a ticket with CA open regarding, is when were 
polling the Checkpoint with a wrong SNMP read string, we didn't get a failure.  
If we polled the device manually, we received "<devicename> was successfully 
contacted via the management protocol (SNMP)" and the device remained green.  
In Mib-tools, it was green, but we wouldn't get any values returned.  

(We're on 8.1/sp2)

.....rod
RBC www.rbc.com

-----Original Message-----
From: Barnes, William [mailto:[email protected]]
Sent: 2009, April, 08 9:02 AM
To: spectrum
Subject: RE: [spectrum] Spectrum handling for traps with "agent-addr 0.0.0.0"

Spectrum drops them.

My suggestion is to kick the vendor and tell them fill out the agent address 
correctly in the trap.  We have been able to get all our vendors to fix that 
problem once they understood what it was for.

Spectrum uses that address to map what device model it should apply the trap 
to.  Since we don't have 0.0.0.0 in the IPAddress table on any device model, 
Spectrum will drop the trap.

This can actually be handy.  We have a management station that sends us traps 
based on the devices that it is monitoring.  Unlike other systems that put the 
management station in the agent-addr, it sticks the IP of the alarming device.  
This way we don't have to setup southbound gateway logic for processing those 
traps.

Bill Barnes

-----Original Message-----
From: Marcel Schulte [mailto:[email protected]]
Sent: Wednesday, April 08, 2009 4:17 AM
To: spectrum
Subject: [spectrum] Spectrum handling for traps with "agent-addr 0.0.0.0"

Hi list,

does anyone of you (or perhaps the CA people) know how Spectrum handles snmp 
traps which contain "agent-addr 0.0.0.0" instead of "agent-addr <trap-src-ip>"?

I think Spectrum simply does... nothing!

The question came up here because we did never generate any trap-events from 
our Checkpoint FWs. We traced snmp traffic and recognized the traps coming in 
with this 0.0.0.0 as agent-addr.
Spectrum didn't even generate events on VNM model for these traps...

Regarding this I wondered if there's any possibility to debug what happens if a 
trap comes in:
- trap comes in
- showing detected model(handle)
- showing used Alertmap
- showing used EventDisp

...do you know if this would be possible?

Many thanks in advance!

Regards,
Marcel

---
To unsubscribe from spectrum, send email to [email protected] with the
body: unsubscribe spectrum [email protected]

---
To unsubscribe from spectrum, send email to [email protected] with the body: 
unsubscribe spectrum [email protected] 
_______________________________________________________________________

This e-mail may be privileged and/or confidential, and the sender does not 
waive any related rights and obligations.
Any distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or 
otherwise) immediately.  

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce 
pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser 
immédiatement, par retour de courrier électronique ou par un autre moyen.


---
To unsubscribe from spectrum, send email to [email protected] with the body: 
unsubscribe spectrum [email protected]

---
To unsubscribe from spectrum, send email to [email protected] with the body: 
unsubscribe spectrum [email protected]

Reply via email to