XEDIA-TRAFFIC-MGMT-MIB
AI MIB Summary
The XEDIA-TRAFFIC-MGMT-MIB enables SNMP-based monitoring and configuration of Xedia proprietary Class-Based Queueing (CBQ) policies to manage interface bandwidth allocation. It exposes management objects for defining traffic classes, setting bandwidth shares, and enforcing administrator-defined quality-of-service (QoS) policies on Xedia hardware.
This module defines objects for the management of Xedia's proprietary Traffic Management capability. This capability is based on Class-Based Queueing (CBQ).
The purpose of the Xedia Traffic Management (xtm) function is to share access to an interface's bandwidth based on policies set up by the administrator.
Main OID:
xediaTrafficMgmtMIB.1.3.6.1.4.1.838.3.2
16
Objects
Active
Status
5
Dependencies
Imported Objects
Objects
16 total| Object Name |
|---|
xediaTrafficMgmtMIBThis module defines objects for the management of Xedia's
proprietary Traffic Management capability. This capability is
based on Class-Based Queueing (CBQ).
The purpose of the Xedia Traffic Management (xtm) function is
to share access to an interface's bandwidth based on policies
set up by the administrator. MODULE-IDENTITY .1.3.6.1.4.1.838.3.2 |
xtmObjects OBJECT IDENTIFIER .1.3.6.1.4.1.838.3.2.1 |
xtmIfInfoTableA table of the traffic management interfaces (CBQ interfaces)
in the system. CBQ interfaces are stacked on top of the
datalink layer interface (e.g., T3 or Ethernet) that they are
managing the traffic for. SEQUENCE OF XtmIfInfoEntry .1.3.6.1.4.1.838.3.2.1.1 |
xtmIfInfoEntryTraffic management information for a given CBQ interface. XtmIfInfoEntry .1.3.6.1.4.1.838.3.2.1.1.1 |
xtmIfInfoHistoryAdminThe CBQ wide object to update the History Admin Status of all
class entries under this CBQ layer to either 'enabled' or 'disabled'.
CBQ History collection consists of rapidly moving the Class statistics
to a fixed length History Ring for collection by a manager.rw Enumeration .1.3.6.1.4.1.838.3.2.1.1.1.1 |
xtmIfInfoHistoryTimerThe interval in milliseconds to wait between moving the CBQ Class
statistics to the History Ring. The range of acceptable interval
values is 20 milliseconds to 20 hours. Modification of this variable
while history collection is running may result in the immediate
clearing of all older data for all classes.rw Unsigned32 .1.3.6.1.4.1.838.3.2.1.1.1.2 |
xtmIfInfoHistoryQDepthThe number of entries in the History Ring for each class
defined under the specified interface, that is doing a
history collection. This number represents how many
of the entries will be saved before the older entries are
overwritten. Modification of this variable while history
collection is running may result in the immediate clearing
of all older data for all classes.rw Unsigned32 .1.3.6.1.4.1.838.3.2.1.1.1.3 |
xtmIfInfoFilteredPktsThe number of packets that were dropped on this interface
because they did not match any traffic class (and therefore
implicitly had a bandwidth allocation of 0) or that were
explicitly filtered by a (bounded) class with a rate of 0
bits/second. This value will be a fraction of the
ifOutDiscards object for this interface.ro Counter32 .1.3.6.1.4.1.838.3.2.1.1.1.4 |
xtmIfInfoTimeLastModificationThe sysUpTime value in seconds the last time a configuration change
occurred, or an AutoClass was added to the system automatically as a
result of flow detection. Note that the value of this object is not
saved to non-volatile storage. A value of zero indicates that no
configuration changes have occurred, nor have AutoClasses been created
since the router was reset.ro Unsigned32 .1.3.6.1.4.1.838.3.2.1.1.1.5 |
xtmIfInfoMaxClassesThe maximum number of classes that may be added to this interface,
including classes added by operators at the command line console or
browser, and classes added to the system automatically, as a result
of flow detection. After the number of classes present on the interface
matches the value that this object has been set to, no more classes
can be created.
The value of this object can not be set below the current number
of classes. For example, if you currently have 100 classes on
cbq.1 and you with to have a maximum of 50 classes you must delete
50 classes before setting this object to 50.rw Unsigned32 .1.3.6.1.4.1.838.3.2.1.1.1.6 |
xtmIfInfoAutoClassAgeOutIndicates if auto-classes are to deleted if no activity is seen
over a given time period.
A value of 'doNotAge(1)' incicates that auto-classes are not to
be deleted based upon thier activity.
A value of 'ageOnce(2)' indicates that auto-classes which are not
active over the next xtmIfInfoAutoClassAgeTime period are to
be deleted. When read, the value of 'ageOnce(2) is returned for
approximately xtmIfInfoAutoClassAgeTime seconds, then is set by
the system back to a value of 'doNotAge(1)'.
A value of 'agePeriodically(3) indicates that auto-classes which
are not active over any xtmIfInfoAutoClassAgeTime period are to
be deleted.rw Enumeration .1.3.6.1.4.1.838.3.2.1.1.1.7 |
xtmIfInfoAutoClassAgeTimeThe number of seconds between aging auto-classes. This value
is only affective when xtmIfInfoAutoClassAgeOut has a value
other than 'doNotAge(1)'. Acceptable values range from 10
seconds to 10 hours.rw INTEGER .1.3.6.1.4.1.838.3.2.1.1.1.8 |
xtmIfInfoNumberOfClassesThe aggregate number of configured classes and AutoClasses on this
interface.ro Counter32 .1.3.6.1.4.1.838.3.2.1.1.1.9 |
xtmNotifications OBJECT IDENTIFIER .1.3.6.1.4.1.838.3.2.2 |
xtmConformance OBJECT IDENTIFIER .1.3.6.1.4.1.838.3.2.3 |
xtmClassTableThis table is a 'flattened' version of a hierarchical class
trees that specify the bandwidth allocation for the CBQ
interfaces of the system.
Each tree is rooted at an interface. A class may either be a
leaf, meaning it has no children, or it may be an interior
class which has children. As packets are forwarded out an
interface, they are compared to the 'flow definition' of each
class down the tree until a matching leaf is found or until
all classes are traversed. Once a matching class is found, the
packet is transmitted or not based on the constraints
configured for the class, most importantly the allocated
bandwidth as identified by xtmClassRate. If no matching class
is found, the packet is dropped.
The 'flow definition' for a class can be defined based on
inclusive ranges of the following packet fields:
o Source IP Address (or a domain name)
o Destination IP Address (or a domain name)
o Protocol above layer 3 (e.g., UDP, TCP, ICMP, etc.)
o Source Port (which identifies service, e.g., FTP,
Telnet, SMTP, etc.)
o Destination Port
It is important that packets only match zero or one traffic
class. In order for this to be true, certain rules must be
enforced when classes are defined. Specifically, all 'sibling'
classes must be defined using the same criteria. Also,
children must use criteria not already specified by one of
their ancestors or they must specify a subrange of an already
specified criteria. Therefore, this tree would be legal:
interface 1
subnet A
protocol UDP
port SNMP
protocol TCP
subnet B
But this tree would be illegal:
interface 2
subnet A
subnet B (illegal
protocol TCP (illegal
::= { xtmObjects 2 }
xtmClassEntry OBJECT-TYPE
SYNTAX XtmClassEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION SEQUENCE OF XtmClassEntry .xtmGroups.2 |