T.R | Title | User | Personal Name | Date | Lines |
---|
4356.1 | | NETCAD::MILLBRANDT | answer mam | Tue Apr 15 1997 12:06 | 16 |
| 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.2 | Still a problem without a solution. | CGOS01::DMARLOWE | Have you been HUBbed lately? | Wed Apr 16 1997 13:52 | 13 |
| 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.3 | | NETCAD::MILLBRANDT | answer mam | Wed Apr 16 1997 15:10 | 18 |
| > 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.4 | Blame it on Rio.. | PTOSS1::DANZAK | Pittsburgher � | Tue Apr 29 1997 23:21 | 15 |
| 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.
|