An ordered list of filters or classifiers to apply to
IP traffic. Filter application is ordered by the filter
index, rather than by a best match algorithm (Note that
this implies that the filter table may have gaps in the
index values). Packets which match no filters will have
policy 0 in the docsDevFilterPolicyTable applied to them if
it exists. Otherwise, Packets which match no filters
are discarded or forwarded according to the setting of
docsDevFilterIpDefault.
Any IP packet can theoretically match multiple rows of
this table. When considering a packet, the table is
scanned in row index order (e.g. filter 10 is checked
before filter 20). If the packet matches that filter
(which means that it matches ALL criteria for that row),
actions appropriate to docsDevFilterIpControl and
docsDevFilterPolicyId are taken. If the packet was
discarded processing is complete. If
docsDevFilterIpContinue is set to true, the filter
comparison continues with the next row in the table
looking for additional matches.
If the packet matches no filter in the table, the packet
is accepted or dropped for further processing based on
the setting of docsDevFilterIpDefault. If the packet is
accepted, the actions specified by policy group 0
(e.g. the rows in docsDevFilterPolicyTable which have a
value of 0 for docsDevFilterPolicyId) are taken if that
policy group exists.
Logically, this table is consulted twice during the
processing of any IP packet - once upon its acceptance
from the L2 entity, and once upon its transmission to the
L2 entity. In actuality, for cable modems, IP filtering
is generally the only IP processing done for transit
traffic. This means that inbound and outbound filtering
can generally be done at the same time with one pass
through the filter table.
Parsed from file DOCS-CABLE-DEVICE-MIB.mib
Module: DOCS-CABLE-DEVICE-MIB
An ordered list of filters or classifiers to apply to
IP traffic. Filter application is ordered by the filter
index, rather than by a best match algorithm (note that
this implies that the filter table may have gaps in the
index values). Packets that match no filters will have
policy 0 in the docsDevFilterPolicyTable applied to
them, if it exists. Otherwise, Packets that match no
filters are discarded or forwarded according to the
setting of docsDevFilterIpDefault.
Any IP packet can theoretically match multiple rows of
this table. When considering a packet, the table is
scanned in row index order (e.g., filter 10 is checked
before filter 20). If the packet matches that filter
(which means that it matches ALL criteria for that row),
actions appropriate to docsDevFilterIpControl and
docsDevFilterPolicyId are taken. If the packet was
discarded processing is complete. If
docsDevFilterIpContinue is set to true, the filter
comparison continues with the next row in the table,
looking for additional matches.
If the packet matches no filter in the table, the packet
is accepted or dropped for further processing
according to the setting of docsDevFilterIpDefault.
If the packet is accepted, the actions specified by
policy group 0 (e.g., the rows in
docsDevFilterPolicyTable that have a value of 0 for
docsDevFilterPolicyId) are taken, if that policy
group exists.
Logically, this table is consulted twice during the
processing of any IP packet: once upon its acceptance
from the L2 entity, and once upon its transmission to
the L2 entity. In actuality, for cable modems, IP
filtering is generally the only IP processing done for
transit traffic. This means that inbound and outbound
filtering can generally be done at the same time with
one pass through the filter table.
The objects in this table are only accessible from cable
devices that are not operating in DiffServ MIB mode
(RFC 3289). See the conformance section for details.
Note that some devices are required by other
specifications (e.g., the DOCSIS OSSIv1.1 specification)
to support the legacy SNMPv1/v2c docsDevFilter mode
for backward compatibility.
Table entries MUST NOT persist across reboots for any
device.
This table is deprecated. Instead, use the DiffServ MIB
from RFC 3289.
docsDevFilterIpTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsDevFilterIpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An ordered list of filters or classifiers to apply to
IP traffic. Filter application is ordered by the filter
index, rather than by a best match algorithm (Note that
this implies that the filter table may have gaps in the
index values). Packets which match no filters will have
policy 0 in the docsDevFilterPolicyTable applied to them if
it exists. Otherwise, Packets which match no filters
are discarded or forwarded according to the setting of
docsDevFilterIpDefault.
Any IP packet can theoretically match multiple rows of
this table. When considering a packet, the table is
scanned in row index order (e.g. filter 10 is checked
before filter 20). If the packet matches that filter
(which means that it matches ALL criteria for that row),
actions appropriate to docsDevFilterIpControl and
docsDevFilterPolicyId are taken. If the packet was
discarded processing is complete. If
docsDevFilterIpContinue is set to true, the filter
comparison continues with the next row in the table
looking for additional matches.
If the packet matches no filter in the table, the packet
is accepted or dropped for further processing based on
the setting of docsDevFilterIpDefault. If the packet is
accepted, the actions specified by policy group 0
(e.g. the rows in docsDevFilterPolicyTable which have a
value of 0 for docsDevFilterPolicyId) are taken if that
policy group exists.
Logically, this table is consulted twice during the
processing of any IP packet - once upon its acceptance
from the L2 entity, and once upon its transmission to the
L2 entity. In actuality, for cable modems, IP filtering
is generally the only IP processing done for transit
traffic. This means that inbound and outbound filtering
can generally be done at the same time with one pass
through the filter table."
View at oid-info.com
An ordered list of filters or classifiers to apply to
IP traffic. Filter application is ordered by the filter
index, rather than by a best match algorithm (note that
this implies that the filter table may have gaps in the
index values). Packets that match no filters will have
policy 0 in the docsDevFilterPolicyTable applied to
them, if it exists. Otherwise, Packets that match no
filters are discarded or forwarded according to the
setting of docsDevFilterIpDefault.
Any IP packet can theoretically match multiple rows of
this table. When considering a packet, the table is
scanned in row index order (e.g., filter 10 is checked
before filter 20). If the packet matches that filter
(which means that it matches ALL criteria for that row),
actions appropriate to docsDevFilterIpControl and
docsDevFilterPolicyId are taken. If the packet was
discarded processing is complete. If
docsDevFilterIpContinue is set to true, the filter
comparison continues with the next row in the table,
looking for additional matches.
If the packet matches no filter in the table, the packet
is accepted or dropped for further processing
according to the setting of docsDevFilterIpDefault.
If the packet is accepted, the actions specified by
policy group 0 (e.g., the rows in
docsDevFilterPolicyTable that have a value of 0 for
docsDevFilterPolicyId) are taken, if that policy
group exists.
Logically, this table is consulted twice during the
processing of any IP packet: once upon its acceptance
from the L2 entity, and once upon its transmission to
the L2 entity. In actuality, for cable modems, IP
filtering is generally the only IP processing done for
transit traffic. This means that inbound and outbound
filtering can generally be done at the same time with
one pass through the filter table.
The objects in this table are only accessible from cable
devices that are not operating in DiffServ MIB mode
(RFC 3289). See the conformance section for details.
Note that some devices are required by other
specifications (e.g., the DOCSIS OSSIv1.1 specification)
to support the legacy SNMPv1/v2c docsDevFilter mode
for backward compatibility.
Table entries MUST NOT persist across reboots for any
device.
This table is deprecated. Instead, use the DiffServ MIB
from RFC 3289.
Parsed from file rfc4639-DOCSIS-Cable-Device.mib.txt
Company: None
Module: DOCS-CABLE-DEVICE-MIB
An ordered list of filters or classifiers to apply to
IP traffic. Filter application is ordered by the filter
index, rather than by a best match algorithm (note that
this implies that the filter table may have gaps in the
index values). Packets that match no filters will have
policy 0 in the docsDevFilterPolicyTable applied to
them, if it exists. Otherwise, Packets that match no
filters are discarded or forwarded according to the
setting of docsDevFilterIpDefault.
Any IP packet can theoretically match multiple rows of
this table. When considering a packet, the table is
scanned in row index order (e.g., filter 10 is checked
before filter 20). If the packet matches that filter
(which means that it matches ALL criteria for that row),
actions appropriate to docsDevFilterIpControl and
docsDevFilterPolicyId are taken. If the packet was
discarded processing is complete. If
docsDevFilterIpContinue is set to true, the filter
comparison continues with the next row in the table,
looking for additional matches.
If the packet matches no filter in the table, the packet
is accepted or dropped for further processing
according to the setting of docsDevFilterIpDefault.
If the packet is accepted, the actions specified by
policy group 0 (e.g., the rows in
docsDevFilterPolicyTable that have a value of 0 for
docsDevFilterPolicyId) are taken, if that policy
group exists.
Logically, this table is consulted twice during the
processing of any IP packet: once upon its acceptance
from the L2 entity, and once upon its transmission to
the L2 entity. In actuality, for cable modems, IP
filtering is generally the only IP processing done for
transit traffic. This means that inbound and outbound
filtering can generally be done at the same time with
one pass through the filter table.
The objects in this table are only accessible from cable
devices that are not operating in DiffServ MIB mode
(RFC 3289). See the conformance section for details.
Note that some devices are required by other
specifications (e.g., the DOCSIS OSSIv1.1 specification)
to support the legacy SNMPv1/v2c docsDevFilter mode
for backward compatibility.
Table entries MUST NOT persist across reboots for any
device.
This table is deprecated. Instead, use the DiffServ MIB
from RFC 3289.
docsDevFilterIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterIpEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An ordered list of filters or classifiers to apply to IP traffic. Filter application is ordered by the filter index, rather than by a best match algorithm (Note that this implies that the filter table may have gaps in the index values). Packets which match no filters will have policy 0 in the docsDevFilterPolicyTable applied to them if it exists. Otherwise, Packets which match no filters are discarded or forwarded according to the setting of docsDevFilterIpDefault. Any IP packet can theoretically match multiple rows of this table. When considering a packet, the table is scanned in row index order (e.g. filter 10 is checked before filter 20). If the packet matches that filter (which means that it matches ALL criteria for that row), actions appropriate to docsDevFilterIpControl and docsDevFilterPolicyId are taken. If the packet was discarded processing is complete. If docsDevFilterIpContinue is set to true, the filter comparison continues with the next row in the table looking for additional matches. If the packet matches no filter in the table, the packet is accepted or dropped for further processing based on the setting of docsDevFilterIpDefault. If the packet is accepted, the actions specified by policy group 0 (e.g. the rows in docsDevFilterPolicyTable which have a value of 0 for docsDevFilterPolicyId) are taken if that policy group exists. Logically, this table is consulted twice during the processing of any IP packet - once upon its acceptance from the L2 entity, and once upon its transmission to the L2 entity. In actuality, for cable modems, IP filtering is generally the only IP processing done for transit traffic. This means that inbound and outbound filtering can generally be done at the same time with one pass through the filter table." ::= { docsDevFilter 4 }
docsDevFilterIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterIpEntry ACCESS not-accessible STATUS deprecated DESCRIPTION "An ordered list of filters or classifiers to apply to IP traffic. Filter application is ordered by the filter index, rather than by a best match algorithm (note that this implies that the filter table may have gaps in the index values). Packets that match no filters will have policy 0 in the docsDevFilterPolicyTable applied to them, if it exists. Otherwise, Packets that match no filters are discarded or forwarded according to the setting of docsDevFilterIpDefault. Any IP packet can theoretically match multiple rows of this table. When considering a packet, the table is scanned in row index order (e.g., filter 10 is checked before filter 20). If the packet matches that filter (which means that it matches ALL criteria for that row), actions appropriate to docsDevFilterIpControl and docsDevFilterPolicyId are taken. If the packet was discarded processing is complete. If docsDevFilterIpContinue is set to true, the filter comparison continues with the next row in the table, looking for additional matches. If the packet matches no filter in the table, the packet is accepted or dropped for further processing according to the setting of docsDevFilterIpDefault. If the packet is accepted, the actions specified by policy group 0 (e.g., the rows in docsDevFilterPolicyTable that have a value of 0 for docsDevFilterPolicyId) are taken, if that policy group exists. Logically, this table is consulted twice during the processing of any IP packet: once upon its acceptance from the L2 entity, and once upon its transmission to the L2 entity. In actuality, for cable modems, IP filtering is generally the only IP processing done for transit traffic. This means that inbound and outbound filtering can generally be done at the same time with one pass through the filter table. The objects in this table are only accessible from cable devices that are not operating in DiffServ MIB mode (RFC 3289). See the conformance section for details. Note that some devices are required by other specifications (e.g., the DOCSIS OSSIv1.1 specification) to support the legacy SNMPv1/v2c docsDevFilter mode for backward compatibility. Table entries MUST NOT persist across reboots for any device. This table is deprecated. Instead, use the DiffServ MIB from RFC 3289." ::= { docsDevFilter 4 }
Automatically extracted from RFC2669
docsDevFilterIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterIpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An ordered list of filters or classifiers to apply to IP traffic. Filter application is ordered by the filter index, rather than by a best match algorithm (note that this implies that the filter table may have gaps in the index values). Packets that match no filters will have policy 0 in the docsDevFilterPolicyTable applied to them, if it exists. Otherwise, Packets that match no filters are discarded or forwarded according to the setting of docsDevFilterIpDefault. Any IP packet can theoretically match multiple rows of this table. When considering a packet, the table is scanned in row index order (e.g., filter 10 is checked before filter 20). If the packet matches that filter (which means that it matches ALL criteria for that row), actions appropriate to docsDevFilterIpControl and docsDevFilterPolicyId are taken. If the packet was discarded processing is complete. If docsDevFilterIpContinue is set to true, the filter comparison continues with the next row in the table, looking for additional matches. If the packet matches no filter in the table, the packet is accepted or dropped for further processing according to the setting of docsDevFilterIpDefault. If the packet is accepted, the actions specified by policy group 0 (e.g., the rows in docsDevFilterPolicyTable that have a value of 0 for docsDevFilterPolicyId) are taken, if that policy group exists. Logically, this table is consulted twice during the processing of any IP packet: once upon its acceptance from the L2 entity, and once upon its transmission to the L2 entity. In actuality, for cable modems, IP filtering is generally the only IP processing done for transit traffic. This means that inbound and outbound filtering can generally be done at the same time with one pass through the filter table. The objects in this table are only accessible from cable devices that are not operating in DiffServ MIB mode (RFC 3289). See the conformance section for details. Note that some devices are required by other specifications (e.g., the DOCSIS OSSIv1.1 specification) to support the legacy SNMPv1/v2c docsDevFilter mode for backward compatibility. Table entries MUST NOT persist across reboots for any device. This table is deprecated. Instead, use the DiffServ MIB from RFC 3289." ::= { docsDevFilter 4 }
docsDevFilterIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsDevFilterIpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "An ordered list of filters or classifiers to apply to IP traffic. Filter application is ordered by the filter index, rather than by a best match algorithm (note that this implies that the filter table may have gaps in the index values). Packets that match no filters will have policy 0 in the docsDevFilterPolicyTable applied to them, if it exists. Otherwise, Packets that match no filters are discarded or forwarded according to the setting of docsDevFilterIpDefault. Any IP packet can theoretically match multiple rows of this table. When considering a packet, the table is scanned in row index order (e.g., filter 10 is checked before filter 20). If the packet matches that filter (which means that it matches ALL criteria for that row), actions appropriate to docsDevFilterIpControl and docsDevFilterPolicyId are taken. If the packet was discarded processing is complete. If docsDevFilterIpContinue is set to true, the filter comparison continues with the next row in the table, looking for additional matches. If the packet matches no filter in the table, the packet is accepted or dropped for further processing according to the setting of docsDevFilterIpDefault. If the packet is accepted, the actions specified by policy group 0 (e.g., the rows in docsDevFilterPolicyTable that have a value of 0 for docsDevFilterPolicyId) are taken, if that policy group exists. Logically, this table is consulted twice during the processing of any IP packet: once upon its acceptance from the L2 entity, and once upon its transmission to the L2 entity. In actuality, for cable modems, IP filtering is generally the only IP processing done for transit traffic. This means that inbound and outbound filtering can generally be done at the same time with one pass through the filter table. The objects in this table are only accessible from cable devices that are not operating in DiffServ MIB mode (RFC 3289). See the conformance section for details. Note that some devices are required by other specifications (e.g., the DOCSIS OSSIv1.1 specification) to support the legacy SNMPv1/v2c docsDevFilter mode for backward compatibility. Table entries MUST NOT persist across reboots for any device. This table is deprecated. Instead, use the DiffServ MIB from RFC 3289." ::= { docsDevFilter 4 }
Internet Assigned Numbers Authority
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.2.1.69.1.6.4.1 | docsDevFilterIpEntry | 22 | 22 | Describes a filter to apply to IP traffic received on a specified interface. All identity objects in this table (e.g. source and… |
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.2.1.69.1.6.1 | docsDevFilterLLCUnmatchedAction | 1 | 1 | LLC (Link Level Control) filters can be defined on an inclusive or exclusive basis: CMs can be configured to forward only packets… |
| 1.3.6.1.2.1.69.1.6.2 | docsDevFilterLLCTable | 1 | 9 | A list of filters to apply to (bridged) LLC traffic. The filters in this table are applied to incoming traffic on the appropriate… |
| 1.3.6.1.2.1.69.1.6.3 | docsDevFilterIpDefault | 1 | 1 | The default behavior for (bridged) packets that do not match IP filters is defined by docsDevFilterIpDefault. If set to discard(1… |
| 1.3.6.1.2.1.69.1.6.5 | docsDevFilterPolicyTable | 1 | 7 | A Table which maps between a policy group ID and a set of policies to be applied. All rows with the same docsDevFilterPolicyId a… |
| 1.3.6.1.2.1.69.1.6.6 | docsDevFilterTosTable | 1 | 5 | Table used to describe Type of Service (TOS) bits processing. This table is an adjunct to the docsDevFilterIpTable, and the docsDe… |
| 1.3.6.1.2.1.69.1.6.7 | docsDevFilterIpV6AuxTable | 1 | 6 | This table augments docsDevIpFilterTable with objects that allow filtering of IPv6 packets. The objects in this table exactly mir… |