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)
|