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)