| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4320.1 | | 2582::YAHEY::BOSE | | Tue Dec 29 1992 17:52 | 10 |
|
One thing you should keep in mind is that you cannot have two
versions of a mib loaded simultaneously in the DECmcc dictionary.
Even if you choose the augment option in MTU, the mib you load later
will overwrite the common objects already residing in the dictionary.
The correct action would be to replace the old version in the
dictionary with the new one, and at the same time upgrade all
the cisco agents to the newer version.
/rb
|
| 4320.2 | | CSOADM::ROTH | You like it, it likes you! | Wed Dec 30 1992 11:19 | 34 |
| > The correct action would be to replace the old version in the
> dictionary with the new one, and at the same time upgrade all
> the cisco agents to the newer version.
Well, things are going to get a bit hairy then.
In the case of Cisco software, each revision (8.3.x, 9.0.x, 9.1.x)
represents added functionality within the software. At my customer site
(and others as well) we will not be upgrading all network boxes to the
9.1.x version due to the fact that some boxes do not have the memory capacity
or CPU performace to properly sustain the traffic load. Thus, there will
exist multiple versions in the network.
Now... what is the correct course of action:
Option 1:
Load the mib that is the 'least common denominator', i.e. the Mib for my
lowest version of software that I have in the Cisco boxes (8.3) and thus
cannot pull some info from the boxes running the newer software...
Option 2:
Load the latest and largest Cisco Mib (for 9.1) and see what happens?
----------
What happens if I load a Mib that has more definitions that the SNMP target
can return? Will I be unable to access *ANY* info from the target box
or just the items that are in the Mib but not in the SNMP agent in the box?
Thanks,
Lee (the Mib rookie)
|
| 4320.3 | | VCSESU::WADE | Bill Wade, VAXc Systems & Support Eng | Wed Dec 30 1992 15:26 | 8 |
|
I'd talk to Cisco first but would guess that loading the latest and
greatest version of the MIB would not cause the director to be unable
to communicate with earlier versions of the agent. If the agent does
not support an object that exists in the newer MIB you should get an
"attribute not available" returned.
|
| 4320.4 | | CSOADM::ROTH | You like it, it likes you! | Wed Dec 30 1992 15:52 | 8 |
| Re: .3
That is what I suspected/expected, but haven't the experience base to work
from.
Thanks-
Lee
|
| 4320.5 | | 2582::YAHEY::BOSE | | Wed Dec 30 1992 17:59 | 15 |
|
If the newer version is a proper superset of the older version,
then you should be able to load the latest mib and still have
all the objects in the old mib accessible. Most agents should not
break in these situations and should return noSuchName errors for
the objects they do not support (as Bill mentioned).
However, the situation gets really sticky when the newer version
of the mib excludes objects which were present in the older mib.
In such situation the only (ugly) solution is to have multiple
copies of the dictionary loaded with the different versions of
the mib, and point to the appropriate dictionary through the
MCC_SYSTEM and MCC_DICT_NAME logicals.
Rahul.
|
| 4320.6 | Siskel & Ebert give two thumbs up | CSOADM::ROTH | You like it, it likes you! | Thu Dec 31 1992 08:15 | 7 |
| My examination of the MIBs (and the output from MTU) would suggest that
the newer MIBs merely have built on previous foundations without changing
them. Looks like I might win this time... (maybe).
Thanks-
Lee
|