Vendor: Xedia Corporation
Module: XEDIA-TRAFFIC-MGMT-MIB
[Automatically extracted from oidview.com]
xtmClassTable OBJECT-TYPE SYNTAX SEQUENCE OF XtmClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This 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 }
xtmClassTable OBJECT-TYPE SYNTAX SEQUENCE OF XtmClassEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This 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 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.838.3.2.1.2.1 | xtmClassEntry | 72 | 72 | Information about a single traffic class. Traffic classes are identified by their associated interface's ifIndex and their name. … |
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.838.3.2.1.1 | xtmIfInfoTable | 1 | 10 | A table of the traffic management interfaces (CBQ interfaces) in the system. CBQ interfaces are stacked on top of the datalink la… |
| 1.3.6.1.4.1.838.3.2.1.3 | xtmClassStatsTable | 1 | 18 | This table augments the basic class table to add statistics. |
| 1.3.6.1.4.1.838.3.2.1.4 | xtmClassHistoryTable | 1 | 16 | This table augments the basic class table to add statistics. |
| 1.3.6.1.4.1.838.3.2.1.5 | xtmClassDisplayTable | 1 | 3 | This table contains a read-only display of the traffic management class hierarchy in indented format. For each CBQ interface in t… |
| 1.3.6.1.4.1.838.3.2.1.6 | xtmApplicationInitialTimeout | 1 | 1 | The amount of time, in seconds, after opening a hole in the firewall in which to wait for a response before timing out an Applica… |
| 1.3.6.1.4.1.838.3.2.1.7 | xtmApplicationFinRstTimeout | 1 | 1 | The amount of time, in seconds, after receiving a FIN or RST in which to wait before timing out an Application Established protoc… |
| 1.3.6.1.4.1.838.3.2.1.8 | xtmApplicationTimeoutTable | 1 | 5 | This table is used to specify timeout values for application classes. Application classes are class whose flow definition includ… |
| 1.3.6.1.4.1.838.3.2.1.9 | xtmFragmentControl | 2 | 25 | None |
| 1.3.6.1.4.1.838.3.2.1.10 | xtmConnectionsGlobal | 11 | 22 | None |
| 1.3.6.1.4.1.838.3.2.1.11 | xtmConnectionTable | 1 | 19 | A table containing information about connections going through the Acess Point. Connections only appear within this table when a… |
| 1.3.6.1.4.1.838.3.2.1.12 | xtmClassConnectionTable | 1 | 13 | This table contains information about connections going through a class. This information is only available for classes which us… |
| 1.3.6.1.4.1.838.3.2.1.13 | xtmConnectionTimeTable | 1 | 22 | A table containing information about connections going through the Acess Point. Connections only appear within this table when a… |