Re: [NV-L] strange behaviour of brocade SAN switch in Netview

Netview uses that type of ping to detect the address mask on devices it cannot get snmp to. On alternate pings it will try to get it. But if a firewall is blocking that protocol, you end up with the Christmas Tree effect. (If you are fowarding to TEC, you get a perpetual motion machine as the tec sends back the acknowledge requests resulting in more pings).

There is an option you can set in /usr/OV/conf/netmon.conf to suppress the subsequent requests for the address mask:

#Set to TRUE to turn off reporting ICMP error codes.
#NV_NETMON_ICMP_ERROR_OFF=FALSE

Uncomment that line, and change it to true. Don't think about the logic too much or it will hurt your head.

The alternative is to talk to the firewall guys and get that ping type allowed.

Cordially,

Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager

"Michael Seibold" <Michael.Seibold AT gek DOT de>
Sent by: nv-l-bounces AT lists.ca.ibm DOT com

09/21/2006 04:11 AM

Please respond to
Tivoli NetView Discussions <nv-l AT lists.ca.ibm DOT com>

To	<nv-l AT lists.ca.ibm DOT com>
cc
Subject	[NV-L] strange behaviour of brocade SAN switch in Netview

For your information: We added some additional brocade SAN switches to our already existing SAN (all brocade switches). Using Netview 7.1.3 on a solaris box the new boxes were discovered by Netview, initially green, but after a few seconds went red. A manually submitted Netview-ping turned them green again, but obviously at the next netmon ping they went red again. The network trace shows that netview ist submitting "ICMP type 17: Address Mask Request" to the san-switches, they respond with "ICMP Type: 3 (Destination unreachable), Code: 3 (Port unreachable)". At this point the boxes turn red in Netview. As we got no solution from brocade I searched my archive of the mailing list and found some hints from James Shanks which leaded me to the trick: at the beginning those switches had no snmp community and netview discovered them as "non snmp" devices, showing the behaviour described above. After the san-guys added the correct community netview didn't try to get the configuration from the boxes per snmp, either because they were already marked as "non snmp" in the database or because they were most of the time "down" due to the ICMP-problem. Now we tried "demand poll" and from this moment on the switches were displayed as expected - always "up". Strange thing, I never have seen this "ICMP type 17: Address Mask Request" bevore. It's described in RFC 1122 for Hosts and RFC 1812 for Routers, and obviously Netview (resp. netmon) uses it to get the network mask of a non-snmp box. I still think the brocade boxes shouldn't answer with "Destination unreachable", but as everything works now we won't follow this problem. Cheers Michael Seibold Gmünder Ersatzkasse GEK Germany _______________________________________________ NV-L mailing list NV-L AT lists.ca.ibm DOT com Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only)

_______________________________________________
NV-L mailing list
NV-L AT lists.ca.ibm DOT com
Unsubscribe:NV-L-leave AT lists.ca.ibm DOT com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to 
internal IBM'ers only)