Hi Leslie,
thanks for that explanation! As we don't have a firewall between the netview
box and the SAN-Switches it must have been something else.
I added the SAN-devices (including snmp-Communities) when they were reachable
in the network, but the SAN-guys hadn't configured the snmp communities. I
suppose Netview added the devices, tried snmp and failed, then started to try
with alternate pings -like you described- to test availability and to get the
adress mask.
After I did the demandpoll, netview recognized the netmask it got per snmp
(SAN-Devices now configured with communities) and since then everything works.
With the knowledge of the behaviour you explained below everything seems to be
logical.
Thanks again
Michael Seibold
Gmünder Ersatzkasse GEK
Germany
>>> Leslie Clark <lclark@us.ibm.com> 21.09.2006 14:55 >>>
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)
|