CISCO-VISM-CONN-MIB :: vismChanLockingState

MIB Reference — IPNetwork Monitor · Updated September 14, 2026

All MIBsCISCO-VISM-CONN-MIBvismChanLockingState

vismChanLockingState

Module: CISCO-VISM-CONN-MIB

OID (symbolic): CISCO-VISM-CONN-MIB::vismChanLockingState

OID (numeric): 1.3.6.1.4.1.351.110.5.5.3.1.1.1.29

Node type: OBJECT-TYPE

Type: INTEGER

Access: read-write

Description: This object is used to control the switchover of protected channels.

'unlock (1)' : Transition state to unlock. A channel which is in lock state has to be brought to 'unlock (1)' state for it to be available for switchover.

Whether a switchover to a channel is allowed or not is dependent on both vismChanActivityState and vismChanLockingState. A switchover is allowed if its vismChanActivityState is standby and its vismChanLockingState is unlock.

Changing the vismChanLockingState to unlock does not cause a change in the vismChanActivityState.

A channel which is in unlock state may carry traffic depending on its activity state (active or standby).

'lock (2)' : Transition state to 'lock (2)'. If the activity state is active, it transitions to standby and a switchover occurs to another channel which is standby and 'unlocked (1)'.

When a channel is in 'lock (2)' state, switchover to this channel is not allowed.

A channel which is in 'lock (2)' state, is always in either standby or failed state. Hence it will not carry any traffic.

Switchover to a channel which is in 'lock (2)' state is not allowed.

This object can be set to 'locked (2)' to force a switchover and/or to perform maintenance operations related to that channel.

A channel that is 'unprotected' will always be in 'unlock (1)' state. It can not be set to 'lock (2)' state.

What is vismChanLockingState?

This read-write INTEGER object controls switchover of protected channels: unlock (the transition state a locked channel must be brought to before it's eligible for switchover) or lock, with actual switchover eligibility depending on both this object and vismChanActivityState together. This gives an admin explicit manual control over whether a protected channel is allowed to take over traffic during a switchover event. An engineer performing planned maintenance on the active PVC in a protection pair would first confirm the standby PVC is unlocked to ensure it's eligible to take over traffic during the switchover.

Examples

Walk all instances (SNMPv2c):

snmpwalk -v2c -c public <target> 1.3.6.1.4.1.351.110.5.5.3.1.1.1.29
snmpwalk -v2c -c public <target> CISCO-VISM-CONN-MIB::vismChanLockingState

Get a specific instance (index 1):

snmpget -v2c -c public <target> 1.3.6.1.4.1.351.110.5.5.3.1.1.1.29.1
snmpget -v2c -c public <target> CISCO-VISM-CONN-MIB::vismChanLockingState.1

Set instance 1 (SNMPv2c):

snmpset -v2c -c private <target> 1.3.6.1.4.1.351.110.5.5.3.1.1.1.29.1 i <value>

Start monitoring Cisco VISM (Voice Interworking Service Module) card, MGX platform (legacy) with a free 30-day trial of IPNetwork Monitor. Create custom SNMP monitor using the CISCO-VISM-CONN-MIB::vismChanLockingState OID value, configure state conditions and alerts, and monitor any Cisco VISM (Voice Interworking Service Module) card, MGX platform (legacy) from a single console.

OID Breakdown

Upper-level ancestors (12 from the standard OID tree / other modules)
Numeric OIDNameModule
1isoLANART-AGENT
1.3orgAirPair-MIB
1.3.6dodAirPair-MIB
1.3.6.1internetAirPair-MIB
1.3.6.1.4privateAirPair-MIB
1.3.6.1.4.1enterprisesAirPair-MIB
1.3.6.1.4.1.351stratacomCISCOWAN-SMI
1.3.6.1.4.1.351.110basisBASIS-MIB
1.3.6.1.4.1.351.110.5basisServicesBASIS-MIB
1.3.6.1.4.1.351.110.5.5voiceBASIS-MIB
1.3.6.1.4.1.351.110.5.5.3vismChanGrpBASIS-MIB
1.3.6.1.4.1.351.110.5.5.3.1vismChanCnfGrpBASIS-MIB
Numeric OIDNameModule
1.3.6.1.4.1.351.110.5.5.3.1.1vismChanCnfGrpTableCISCO-VISM-CONN-MIB
1.3.6.1.4.1.351.110.5.5.3.1.1.1vismChanCnfGrpEntryCISCO-VISM-CONN-MIB
1.3.6.1.4.1.351.110.5.5.3.1.1.1.29vismChanLockingStateCISCO-VISM-CONN-MIB