📄 rfc3231.txt
字号:
-- conformance information
schedCompliances OBJECT IDENTIFIER ::= { schedConformance 1 }
schedGroups OBJECT IDENTIFIER ::= { schedConformance 2 }
-- compliance statements
schedCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement
the scheduling MIB."
MODULE -- this module
MANDATORY-GROUPS {
schedGroup2, schedNotificationsGroup
}
GROUP schedCalendarGroup
DESCRIPTION
"The schedCalendarGroup is mandatory only for those
implementations that support calendar based schedules."
OBJECT schedType
DESCRIPTION
"The values calendar(2) or oneshot(3) are not valid for
implementations that do not implement the
schedCalendarGroup. Such an implementation must return
inconsistentValue error responses for attempts to set
schedAdminStatus to calendar(2) or oneshot(3)."
Levi & Schoenwaelder Standards Track [Page 18]
RFC 3231 Schedule MIB January 2002
::= { schedCompliances 2 }
schedGroup2 OBJECT-GROUP
OBJECTS {
schedDescr, schedInterval, schedContextName,
schedVariable, schedValue, schedType,
schedAdminStatus, schedOperStatus, schedFailures,
schedLastFailure, schedLastFailed, schedStorageType,
schedRowStatus, schedTriggers
}
STATUS current
DESCRIPTION
"A collection of objects providing scheduling capabilities."
::= { schedGroups 4 }
schedCalendarGroup OBJECT-GROUP
OBJECTS {
schedLocalTime, schedWeekDay, schedMonth,
schedDay, schedHour, schedMinute
}
STATUS current
DESCRIPTION
"A collection of objects providing calendar based schedules."
::= { schedGroups 2 }
schedNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
schedActionFailure
}
STATUS current
DESCRIPTION
"The notifications emitted by the scheduler."
::= { schedGroups 3 }
--
-- Deprecated compliance and conformance group definitions
-- from RFC 2591.
--
schedCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for SNMP entities which implement
the scheduling MIB."
MODULE -- this module
MANDATORY-GROUPS {
schedGroup, schedNotificationsGroup
}
Levi & Schoenwaelder Standards Track [Page 19]
RFC 3231 Schedule MIB January 2002
GROUP schedCalendarGroup
DESCRIPTION
"The schedCalendarGroup is mandatory only for those
implementations that support calendar based schedules."
OBJECT schedType
DESCRIPTION
"The values calendar(2) or oneshot(3) are not valid for
implementations that do not implement the
schedCalendarGroup. Such an implementation must return
inconsistentValue error responses for attempts to set
schedAdminStatus to calendar(2) or oneshot(3)."
::= { schedCompliances 1 }
schedGroup OBJECT-GROUP
OBJECTS {
schedDescr, schedInterval, schedContextName,
schedVariable, schedValue, schedType,
schedAdminStatus, schedOperStatus, schedFailures,
schedLastFailure, schedLastFailed, schedStorageType,
schedRowStatus
}
STATUS deprecated
DESCRIPTION
"A collection of objects providing scheduling capabilities."
::= { schedGroups 1 }
END
5. Usage Examples
This section presents some examples how the scheduling MIB can be
used to schedule scripts with the Script MIB [RFC3165] or to realize
on-duty/off-duty schedules by modifying status objects of other MIB
modules.
5.1. Starting a script to ping devices every 20 minutes
It is assumed that the schedule entry is owned by schedOwner = "joe"
and its name is schedName = "ping". The instance identifier for the
scheduling entry is therefore 3.106.111.101.4.112.105.110.103.
It is further assumed that the smLaunchTable entry is owned by
smLaunchOwner = "joe" and its name is smLaunchName = "ping-devs".
The complete object identifier for the smLaunchStart object is
therefore
smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115.
The script lives in the context identified by the string "engine1".
Levi & Schoenwaelder Standards Track [Page 20]
RFC 3231 Schedule MIB January 2002
The configuration of the scheduler entry which launches the script
every 20 minutes would look as follows:
schedInterval.3.106.111.101.4.112.105.110.103 = 1200
schedValue.3.106.111.101.4.112.105.110.103 = 0
schedContextName.3.106.111.101.4.112.105.110.103 = "engine1"
schedVariable.3.106.111.101.4.112.105.110.103 =
smLaunchStart.3.106.111.101.9.112.105.110.103.45.100.101.118.115
schedType.3.106.111.101.4.112.105.110.103 = periodic(1)
schedAdminStatus.3.106.111.101.4.112.105.110.103 = enabled(1)
schedStorageType.3.106.111.101.4.112.105.110.103 = nonVolatile(3)
schedRowStatus.3.106.111.101.4.112.105.110.103 = active(1)
All the remaining columns in the schedTable represent status
information and are not shown here.
5.2. Starting a script at the next Friday the 13th
It is assumed that the schedule entry is owned by schedOwner = "joe"
and its name is schedName = "13th". The instance identifier for the
scheduling entry is therefore 3.106.111.101.4.49.51.116.104.
It is further assumed that the smLaunchTable entry is owned by
smLaunchOwner = "joe" and its name is smLaunchName = "ghost". The
complete object identifier for the smLaunchStart object is therefore
smLaunchStart.3.106.111.101.5.103.104.111.115.116. The script lives
in the context identified by the string "engine1".
The configuration of the scheduler entry which launches the script on
the next Friday 13th at midnight would look as follows:
schedWeekDay.3.106.111.101.4.49.51.116.104 = { friday }
schedMonth.3.106.111.101.4.49.51.116.104 = {
january, february, march, april, may, june,
july, august, september, october, november, december
}
schedDay.3.106.111.101.4.49.51.116.104 = { d13 }
schedHour.3.106.111.101.4.49.51.116.104 = { h0 }
schedMinute.3.106.111.101.4.49.51.116.104 = { m0 }
schedValue.3.106.111.101.4.49.51.116.104 = 0
schedContextName.3.106.111.101.4.49.51.116.104 = "engine1"
schedVariable.3.106.111.101.4.49.51.116.104 =
smLaunchStart.3.106.111.101.5.103.104.111.115.116
Levi & Schoenwaelder Standards Track [Page 21]
RFC 3231 Schedule MIB January 2002
schedType.3.106.111.101.4.49.51.116.104 = oneshot(3)
schedAdminStatus.3.106.111.101.4.49.51.116.104 = enabled(2)
schedStorageType.3.106.111.101.4.49.51.116.104 = nonVolatile(3)
schedRowStatus.3.106.111.101.4.49.51.116.104 = active(1)
All the remaining columns in the schedTable represent status
information and are not shown here.
5.3. Turning an interface off during weekends
This example assumes that a network interface should be taken down
during weekends. The interface table (ifTable) of the IF-MIB
[RFC2863] is assumed to exist in the context identified by an empty
string and the index of the interface is ifIndex = 6.
The scheduling entry which brings the interface down on every Friday
evening at 20:30 (8:30 pm) is owned by schedOwner = "bob" and its
name is schedName = "if-off". The instance identifier for the
scheduling entry is therefore 3.98.111.98.6.105.102.45.111.102.102.
schedWeekDay.3.98.111.98.6.105.102.45.111.102.102 = { friday }
schedMonth.3.98.111.98.6.105.102.45.111.102.102 = {
january, february, march, april, may, june,
july, august, september, october, november, december
}
schedDay.3.98.111.98.6.105.102.45.111.102.102 = {
d1, d2, d3, d4, d5, d6, d7, d8, d9, d10,
d11, d12, d13, d14, d15, d16, d17, d18, d19, d20,
d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31
}
schedHour.3.98.111.98.6.105.102.45.111.102.102 = { h20 }
schedMinute.3.98.111.98.6.105.102.45.111.102.102 = { m30 }
schedValue.3.98.111.98.6.105.102.45.111.102.102 = down(2)
schedContextName.3.98.111.98.6.105.102.45.111.102.102 = ""
schedVariable.3.98.111.98.6.105.102.45.111.102.102 =
ifAdminStatus.6
schedType.3.98.111.98.6.105.102.45.111.102.102 = calendar(2)
schedAdminStatus.3.98.111.98.6.105.102.45.111.102.102 = enabled(1)
schedStorageType.3.98.111.98.6.105.102.45.111.102.102 =
nonVolatile(3)
schedRowStatus.3.98.111.98.6.105.102.45.111.102.102 = active(1)
The scheduling entry which brings the interface up on every Monday
morning at 5:30 is owned by schedOwner = "bob" and its name is
schedName = "if-on". The instance identifier for the scheduling
entry is therefore 3.98.111.98.5.105.102.45.111.110.
Levi & Schoenwaelder Standards Track [Page 22]
RFC 3231 Schedule MIB January 2002
The entry in the schedTable which brings the interface up again on
every Monday morning at 5:30 looks as follows:
schedWeekDay.3.98.111.98.5.105.102.45.111.110 = { monday }
schedMonth.3.98.111.98.5.105.102.45.111.110 = {
january, february, march, april, may, june,
july, august, september, october, november, december
}
schedDay.3.98.111.98.5.105.102.45.111.110 = {
d1, d2, d3, d4, d5, d6, d7, d8, d9, d10,
d11, d12, d13, d14, d15, d16, d17, d18, d19, d20,
d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31
}
schedHour.3.98.111.98.5.105.102.45.111.110 = { h5 }
schedMinute.3.98.111.98.5.105.102.45.111.110 = { m30 }
schedValue.3.98.111.98.5.105.102.45.111.110 = up(1)
schedContextName.3.98.111.98.5.105.102.45.111.110 = ""
schedVariable.3.98.111.98.5.105.102.45.111.110 = ifAdminStatus.6
schedType.3.98.111.98.5.105.102.45.111.110 = calendar(2)
schedAdminStatus.3.98.111.98.5.105.102.45.111.110 = enabled(1)
schedStorageType.3.98.111.98.5.105.102.45.111.110 = nonVolatile(3)
schedRowStatus.3.98.111.98.5.105.102.45.111.110 = active(1)
A similar configuration could be used to control other schedules.
For example, one could change the "if-on" and "if-off" schedules to
enable and disable the periodic scheduler defined in the first
example.
6. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementers consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [RFC2574] and the View-
based Access Control Model RFC 2575 [RFC2575] is recommended.
Levi & Schoenwaelder Standards Track [Page 23]
RFC 3231 Schedule MIB January 2002
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
Scheduled SNMP set operations must use the security credentials that
were present when the corresponding row in the scheduling entry was
created. An implementation must therefore record and maintain the
credentials for every scheduling entry.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -