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

[Leslie Clark <lclark@us.ibm.com>]

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@gek.de>
Sent by: nv-l-bounces@lists.ca.ibm.com

09/21/2006 04:11 AM

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

To	<nv-l@lists.ca.ibm.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@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)

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