[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

4356.0. "MIB DATA NOT AVAILABLE (no such)" by GIDDAY::STANISLAUS () Tue Apr 15 1997 03:00

	I have read note 4309 in this conference and I "think: I understand what
is going on and why we get the MIB DATA NOT AVAILABLE MESSAGE. Yet I have a
question.

	After I give the VNSwitch and IP address and a Gateway address and also 
provide a network path from clearVISN MCM (Multi Chassis Manager) to the
VNswitch via say Thinwire, I still get the MIB DATA NOT AVAILABLE, until I exit
MCM and go back into it and OPEN that HUB again.

	Now a customer is telling me even what I do doesn't fix the problem of
MIB DATA NOT AVAILABLE. After they exit MCM, go back into MCM and OPEN that HUB,
they get MIB DATA NOT AVAILABLE message for 15 or 20 minutes when they
double-click on the VNswitch900EF (F/W 1.5). But after 15 or 20 minutes
everything works fine. I just ignored this customer's comment thinking she was
doing something wrong, until another customer called me this morning and said a
similar thing (but instead of saying 15 or 20 minutes, he said after a while)
the MIB DATA NOT AVAILABLE message did not occur.

Alphonse
T.RTitleUserPersonal
Name
DateLines
4356.1NETCAD::MILLBRANDTanswer mamTue Apr 15 1997 12:0616
When LAN reachability changes after some time period like 15-25 minutes, 
a good thing to consider is the ARP cache on the station running MCM.
If the VNswitch's IP address was just assigned and previously belonged
to another module, then the ARP cache is still associating the IP address
with the MAC address of the previous device.  The management requests that
MCM is sending to the VNswitch are being packaged in a 802.3 frame with
the wrong device's MAC address, so they never get to the VNswitch.
These associations are usually deleted after some time period (exact time
is installation dependent).  

Once the ARP cache no longer has a MAC associated with an IP address,
it sends out a new ARP request.  The device that owns that IP address
(now your VNswitch) responds with its MAC address.  MCM requests then
go to the right place.

	Dotsie
4356.2Still a problem without a solution.CGOS01::DMARLOWEHave you been HUBbed lately?Wed Apr 16 1997 13:5213
    re. .1
    
    I don't think ARP caching is the problem according to what I've seen.
    Modules such as 900FP are still manageable, LAN Incetconnect still
    works, even dragging and dropping legs from VN switches.  However,
    double clicking on a VN, either in LAN Interconnect or front panel,
    gives the No Such MIB error message.
    
    The other clue to knowing when it fails, if the VN switch LEDS are
    green/gray then it can be managed.  If the LEDS show as pink (or
    whatever) then it won't work.
    
    dave
4356.3NETCAD::MILLBRANDTanswer mamWed Apr 16 1997 15:1018
>    I don't think ARP caching is the problem according to what I've seen.
>    Modules such as 900FP are still manageable, LAN Incetconnect still
>    works, even dragging and dropping legs from VN switches.  However,
>    double clicking on a VN, either in LAN Interconnect or front panel,
>    gives the No Such MIB error message.

All these operations go through the MAM (though MCM would go via a 900FP
front port if one were available, but it not uses MAM's CSNMP gateway.)
Among the CSNMP gateway operations that the VNswitch does support are the
internal operations used by the LAN interconnect display.  Operations that
the VNswitch does not support through the CSNMP gateway include reading
the LEDs states, MIB-II, etc.

Everything you've said indicates a connectivity problem between MCM and
the front port of the VNswitch, yet you also state that it goes away
after some minutes.  Look for something timer based.

	Dotsie
4356.4Blame it on Rio..PTOSS1::DANZAKPittsburgher �Tue Apr 29 1997 23:2115
    I'd tell the customer:
    
    "The VN switch is just SOOOOO busy forwarding packets at 1,000,000 per
    second that it's really not going to muck with management until it's
    got every last packet done..."
    
    Failing that, I'd blame it on flakey as hell rev 1 of the software and
    promise things would get better in October, or was that November, no
    maybe it was December.....Well...at some future time......
    
    Aarugh,
    j
    ^--who has had that happen at demos and did the stand-on-it-module demo
    to stall for friggen time while the things calmed down and did whateve
    they needed to do to talk to MCM.