Conference netcad::hub_mgnt

Hi Luis,

I wrote the SNMP agent end of things.  I need to talk with some
HUBwatch folks about this before I can answer your questions.
In the mean time, maybe you can help clarify some things.

>    I changed community names using DECmcc and MIB variables under
>    pcomSnmpAuth to XXX and YYY
>    
>    Now hubwatch only works in the main screen. If I try to double-click on
>    a module, it complains about "agent not responding". Hubwatch is using
>    XXX and YYY as the community name for *all* modules.

Can you tell me more about the order in which you did things?  For example,
did you invoke HUBwatch, change communities, and try to manage modules,
or did you re-invoke HUBwatch somewhere in the middle?

How do you know HUBwatch is using XXX and YYY as the community name for all
modules?

Also, what version of HUBwatch are you using?
 
>    I have tried to go back to the initial situation. It does not work. I
>    changed community names setting pcomSnmpAuth back to PUBLIC, but now
>    all chassis entities have community names PUBLIC (not PUBLIC_n).
>    Hubwatch still does not work.
 
Could you please double check this?  There should be entries in the entity
table which have community "public-n" and the MAM's IP address.  If the 
module have their own IP address then they will also report communities 
"public" with the module's IP address.

						Thanks,
						-Shawn

    Thanks for your quick reply Shawn. I am at the moment at a customer
    site, and everybody here is a bit nervous.
    
    I'll try to summarize the steps.
    
    I found Hubwatch 3.0 (VMS) installed and configured in a VAXstation.
    DECsite people had installed and configured several hubs.
    
    Hubwatch agent table had all hubs, fddi concentrators, fddi bridges and
    repeaters, using community "public", and worked OK.
    
    I installed DECmcc, MIB extensions and so on. Since I had never used
    DEChub MIBS, I checked the variables for some of the hubs. At that
    time there were 3 chassis entities for each slot (as expected). The
    community names were "public_n" for all of them (as expected).
    
    I started setting a community name for RW for all the hubs, by setting
    the corresponding variable pcomSnmpAuth. This was done successfully,
    since now I need to use this community name if I want to see the RW
    chassis entities. BUT, looking at those entities, I noticed that all RW
    entities were set to the same value (say "dummy"), and not to dummy_n.
    I checked with Hubwatch and it worked OK, since it was using community
    "public" for the hubs
    
    Then I set a new community name for RO for a hub, in the same way as
    above. After that, Hubwatch does not work. I tried to set up this value
    back to "public", but RO community names for chassis entities are set
    to "public" (no to "public_n"). In fact I have not the faintest idea of
    how to set it back to the original setting.
    
    By the way, Hubwatch crashes when double-clicking one of the modules (a
    FDDI bridge), with an ACCVIO, reason mask=4, PC=1C6AEC0, PSL=03C00005
    
>>Could you please double check this?  There should be entries in the entity
>>table which have community "public-n" and the MAM's IP address.  If the 
>>module have their own IP address then they will also report communities 
>>"public" with the module's IP address.

    I have checked it. Actually there are NO entries like that. Using the
    new RW community name "dummy" I can see chassis entities
    1-3,7-15,49-57,61-63,70-72. I wonder if the gaps in between are the
    ones you say. All entities I can see have the IP address of the hub
    agent (7.0.254.1). By the way, the trap community names are still OK (I
    have not changed it anywhere).
    
    I have not changed any more hub until I find a way of safely going
    ahead.
    
    
    Hope this helps ..
    
    Luis

    
    It sounds to me like you may be operating at too low a level of detail.
    
    What you want to do, I think, is change the read/write community used
    by MCC to manage hub devices, correct?
    
    The easy way to do that is to change the read/write community for the
    hub and reset it; the modules will then (by default) inherit the
    change; so if you change the read/write community of the hub to
    'master', then each slot will become 'master-N' (where N is the slot
    number).  You don't need to manipulate the individual slot communities. 
    
    The phenomenon you saw where there are missing communities (gaps in the
    numbering of the entity table) can happen because communities change -
    the table doesn't 'garbage collect', or can result from reading the
    table with a read-only community - it won't let you read the read/write
    communities with that (security feature :-).
    

    >What you want to do, I think, is change the read/write community used
    >by MCC to manage hub devices, correct?
    
    Correct
    
    >The easy way to do that is to change the read/write community for the
    >hub and reset it; the modules will then (by default) inherit the
    >change; so if you change the read/write community of the hub to
    >'master', then each slot will become 'master-N' (where N is the slot
    >number).  You don't need to manipulate the individual slot communities. 
    
    You mean by accesing the hub console port ?    I will try it.
    Is there any side effect in resetting the hub, losing any config. or
    something ?
    
    Anyway I don't think I was actually manipulating individual slot
    communities. In my little knowledge of the hub MIBs (the documentation
    is *really* tough :-)  I assume that MIB variables under pcomSnmpAuth
    apply (or I'd rather say should apply) to the whole hub, and its
    modules, so changing them should cause the same "inheriting" effect as
    the reset. In fact if there was any means of changing individual slot
    communities using SNMP, I guess the problem could be solved quite
    easily.
    
    
    
    Luis

Performing a reset to the DEChub 900 manager does not lose config data.  It 
also will not affect any of the modules in the hub.  Users connected to ports
will not be affected. 

You can do it either thru the set-up port or thru HUBwatch.

Do not do a factory reset, or you will lose everything.

Tom Hood
HUBwatch

Luis,

I was able to repeat the problem you describe (not that I doubted you ;-).

You've found a bug.  It will be fixed in the next base-level.

Things work as Scott describes in .3.  That is, the way to change the
read-write community is to set pcomSnmpAuthReadWriteCommunity and then
reset the Management Agent Module (MAM).  Ditto for changing the read-only 
community.  You can reset the MAM via the console.  You can also reset the 
MAM remotely by setting pcomAdminStatus to 'reset(3)'.

Currently, after changing the community the entity table reflects incorrect
community information and HUBwatch will be unable to manage the line cards 
after it re-reads the entity table.  HUBwatch reads the entity table:

	- upon initialization,
	- when polling is enabled and any of several events occur, and
	- when you do a "refresh".

Once HUBwatch re-reads the entity table the only way to clear things up
is to reset the MAM.

In the next release you should probably still reset the MAM after changing 
the read-only or read-write communities in order to have the "inherited"
communities take affect.  However, things won't break if you decide not
to reset the MAM.

Thanks for finding the bug!
						-Shawn

    Well, that solved the problem. Thanks a lot to everyone for your help.
    
    BTW, I think I've read somebody reporting this other minor problem
    already in a previous note, but just in case ... The Hubwatch screen
    that you see after selecting "Manage current" shows "read/write" no
    matter if you use RO or RW community strings.
    
    Regards
    
    Luis Gonzalez

The variable to cause a Reset is different.
It is chasSlotModuleAdminStatus e.g 
.1.3.6.1.4.1.36.2.18.11.1.1.1.1.6.1.9.9
where the last 9 is the slot number
1-8 = slot, 9=MAM.

for those who do not have the MIB handy
the next reply will have three pages of
screen shots with setting communities
and resetting the DH900 and also the DA90.

Wolfgang

--      iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).
--          dec(36).ema(2).decMIBextension(18).decHub900(11)
--
--  or, 1.3.6.1.4.1.36.2.18.11.
--
--  Object Name                               Object Id         Non-vol
--
--        pcomSnmpAuthReadOnlyCommunity       p.2.5.2.1.0        Yes
--        pcomSnmpAuthReadWriteCommunity      p.2.5.3.1.0        Yes
--        pcomSnmpAuthTrapCommunity           p.2.5.1.1.0        Yes

pcomSnmpAuthReadOnlyCommunity OBJECT-TYPE
    SYNTAX  OCTET STRING (SIZE (4..31))
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
        "The community string used to identify an SNMP community
         with access rights of read-only.  This value is initially
         'public'."
    ::= { pcomSnmpAuthReadOnly 1 }

pcomSnmpAuthReadWriteCommunity OBJECT-TYPE
    SYNTAX  OCTET STRING (SIZE (4..31))
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
        "The community string used to identify an SNMP community
         with access rights of Read-Write.

         Note, this object may only be read or written using the
         read-write community.  Read-only access to this object
         is denied."
    ::= { pcomSnmpAuthReadWrite 1 }

pcomSnmpAuthTrapCommunity OBJECT-TYPE
    SYNTAX  OCTET STRING (SIZE (4..31))
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
        "The community string used in SNMP Trap PDUs.  This value
         is initially 'public'."
    ::= { pcomSnmpAuthTrap 1 }



chasSlotModuleAdminStatus OBJECT-TYPE
    SYNTAX  INTEGER {
                unknown(1),  -- none of the following
                enabled(2),
                disabled(3),
                reset(4),
                restore-to-defaults(5)
                }
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
        "Provides the administratively desired state of
         the given module.

         A disabled module is activated by writing a value of
         enable(2).

         A slot may be de-activated by writing a value
         of disable(3).  A disabled slot is available for
         subsequent activation.

         Writing a value of reset(4) specifies that the model
         initiate a reset sequence.

         Writing a value of restore-to-defaults(5) specifies that
         the module restore all of its non-volatile parameters
         to their factory default state and reset the module.

         Agent support of the writing of any of the values
         of this object is implementation-specific.  For
         example, this object might be read only for
         slots that disabling would compromise the
         integrity of the chassis."
    ::= { chasSlotEntry 9 }

         Note:  Some devices may not send a getResponse to a PDU
         which commands the device to reset.  Setting this object
         to reset, restoreToDefaults, or enable may cause the device
         to reset."

# /kits/snmpw/snmpset 2.0.1.150 dec.ema.18.11.1.1.1.1.6.1.9.9 integer 4
snmpset: No response arrived before timeout.
# /kits/snmpw/snmpget 2.0.1.150 .1.3.6.1.4.1.36.2.18.11.1.1.1.1.6.1.9.9
dec.ema.decMIBextension.decHub900.1.1.1.1.6.1.9.9 : INTEGER: 2


# /kits/snmpw/snmpget 2.0.1.150 .1.3.6.1.4.1.36.2.18.11.2.5.3.1.0
dec.ema.decMIBextension.decHub900.pubCommon.pcomSnmpAuth.pcomSnmpAuthReadWrite.p
comSnmpAuthReadWriteCommunity.0 : OCTET STRING- (ascii):        public


# /kits/snmpw/snmpget 2.0.1.150 .1.3.6.1.4.1.36.2.18.11.2.5.2.1.0
dec.ema.decMIBextension.decHub900.pubCommon.pcomSnmpAuth.pcomSnmpAuthReadOnly.pc
omSnmpAuthReadOnlyCommunity.0 : OCTET STRING- (ascii):  public
#


DA90
==================================
# /kits/snmpw/snmpget 2.0.1.147 dec.2.18.10.2.2.0
dec.ema.decMIBextension.dechub90.da90.da90Maintenance.0 : INTEGER: ready

# /kits/snmpw/snmpset 2.0.1.147 .1.3.6.1.4.1.36.2.18.10.2.2.0 integer 3
snmpset: No response arrived before timeout.
# /kits/snmpw/snmpget 2.0.1.147 .1.3.6.1.4.1.36.2.18.10.2.2.0
dec.ema.decMIBextension.dechub90.da90.da90Maintenance.0 : INTEGER: ready

da90Maintenance OBJECT-TYPE
    SYNTAX  INTEGER {
                ready(1),
                setsDisabled(2),
                reset(3),
                resetToFactory(4)
            }
    ACCESS  read-write
    STATUS  mandatory
    DESCRIPTION
        "A control variable to perform reset functions on
        a DECagent 90.  In response to a get-request or
        a get-next-request, the agent returns ready(1)
        if SNMP sets are enabled, or setsDisabled(2) if
        they are disabled.  Setting this value to setsDisabled(2)
        causes SNMP Sets to be disabled.  Note, however, that
        you cannot re-enable SNMP Sets via this mechanism.
        SNMP sets can only be re-enabled via the console interface,
        or by restoring factory settings.  Setting this value to
        reset(3) causes the entire module to be reset.  Setting
        this value to resetToFactory(4) causes the entire
        device to be reset to the original factory settings.
        Setting either reset(3) and resetToFactory(4) results in
        an immediate reset with no response PDU being issued."
    ::= { da90 2 }
 

# /kits/snmpw/snmpget 2.0.1.147 .1.3.6.1.4.1.36.2.18.10.1.5.1.16.7
dec.ema.decMIBextension.dechub90.dh90.dh90SlotTable.dh90SlotEntry.dh90SlotCommun
ityString.7 : OCTET STRING- (ascii):    public

# /kits/snmpw/snmpget 2.0.1.147 .1.3.6.1.4.1.36.2.18.10.2.4.1.3.1
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityROString.1 : OCTET STRING- (ascii):    public

# /kits/snmpw/snmpget 2.0.1.147 .1.3.6.1.4.1.36.2.18.10.2.4.1.4.1
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityRWString.1 : OCTET STRING- (ascii):    public

after setting community to private using public:

# /kits/snmpw/snmpwalk -c private 2.0.1.147 |grep -i community
..
dec.ema.decMIBextension.dechub90.dh90.dh90SlotTable.dh90SlotEntry.dh90SlotCommun
ityString.7 : OCTET STRING- (ascii):    private
..
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityROString.1 : OCTET STRING- (ascii):    public
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityRWString.1 : OCTET STRING- (ascii):    private
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityTrapString.1 : OCTET STRING- (ascii):
#
# /kits/snmpw/snmpwalk -c public 2.0.1.147 |grep -i community
..
dec.ema.decMIBextension.dechub90.dh90.dh90SlotTable.dh90SlotEntry.dh90SlotCommun
ityString.7 : OCTET STRING- (ascii):    public
..
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityROString.1 : OCTET STRING- (ascii):    public
dec.ema.decMIBextension.dechub90.da90.da90CommunityTable.da90CommunityEntry.da90
CommunityTrapString.1 : OCTET STRING- (ascii):