|To:||Tivoli NetView Discussions <firstname.lastname@example.org>|
|Subject:||Re: [NV-L] strange behaviour of brocade SAN switch in Netview|
|From:||Leslie Clark <email@example.com>|
|Date:||Thu, 21 Sep 2006 08:55:37 -0400|
|Delivery-date:||Thu, 21 Sep 2006 14:08:16 +0100|
|List-id:||Tivoli NetView Discussions <nv-l.lists.ca.ibm.com>|
|Reply-to:||Tivoli NetView Discussions <firstname.lastname@example.org>|
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.
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.
Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager
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.
Gmünder Ersatzkasse GEK
NV-L mailing list
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-Lemail@example.com http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to internal IBM'ers only)
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [NV-L] Smartset Issue, Leslie Clark|
|Next by Date:||Re: [NV-L] xnmcollect and thresholds, Leslie Clark|
|Previous by Thread:||[NV-L] strange behaviour of brocade SAN switch in Netview, Michael Seibold|
|Next by Thread:||[NV-L] Smartset Issue, mikemillion2000|
|Indexes:||[Date] [Thread] [Top] [All Lists]|
Archive operated by Skills 1st Ltd
See also: The NetView Web