CISCO-IP-PROTOCOL-FILTER-MIB: View SNMP OID List / Download MIB

The MIB module is for management of information to support packet filtering on IP protocols. The cippfIpProfileTable allows users to create delete, and get information about filter profiles. Filter profiles are uniquely identified by the profile names. Filter profiles can either be of Simple or Extended usage types, and the usage type cannot be changed once it has been created. The cippfIfIpProfileTable applies the filtering profiles to device interfaces running IP. A filter profile can be applied to multiple interfaces. The cippfIpFilterTable contains ordered lists of IP filters for all the filtering profiles. Filters and profiles are related if they are of the same filter profile name. Filters can only be created if their associated filter profiles already exist in the cippfIpProfileTable. Filters of the same profile name belongs to a common profile. The cippfIfIpProfileTable can be configured with information independent from the other. However, if the name of a profile in the cippfIfIpProfileTable matches that of any profile in the cippfIpProfileTable and the profile name of any filter entry in the cippfIpFilterTable, the profile is 'active' and the filter entry is being applied to IP traffic passing through the attached device interfaces. Therefore, any change to the filters in the cippfIpFilterTable or the profile itself in the cippfIpProfileTable will affect all the attached interfaces.

This table lists all the existing IP protocol filter profiles. These filter profiles contain protocol filters used to filter IP traffic through the device interfaces. The IP protocol filters associated with these profiles are defined in the cippfIpFilterTable. For profiles to be associated with filters, the object value of the cippfIpProfileName of a profile must matches that of the cippfIpProfileName of a filter entry in the cippfIpFilterTable. Filters of the same profile name belong to a common filter profile and are of the same usage type of the profile. This table can only be used to create or delete filter profiles. Deleting any profile in this table will also delete all the associated filters in the cippfIpFilterTable and cause the state of the associated 'active' filter profile in the cippfIfIpProfileTable to be changed to 'notReady'. All of these deleted or changed entries are associated by virtue of the same profile name.

Each entry defines the type, state, and the last object index assigned to a filter of the filter profile.

This is the unique IP protocol filter profile identifier. If this value is the same as the cippfIpProfileName in the cippfIpFilterTable and the cippfIfIpProfileName in cippfIfIpFilterTable, they are all referring to the same filter profile.

This object determines the usage type this filter profile. This usage type cannot be changed after the profile has been created. The usage type simple(1) implies that the valid objects of each filter entry in the profile in the cippfIpFilterTable only include: cippfIpFilterIndex, cippfIpFilterOrderPosition, cippfIpFilterAction, cippfIpFilterAddressType, cippfIpFilterSrcAddress, cippfIpFilterSrcMask, cippfIpFilterLogEnabled, cippfIpFilterStatus. This means that only the above objects will be used to create the protocol filter, and all other objects will be ignored during filter creation. The usage extended(2) implies that all objects defined in the cippfIpFilterTable are valid for any filter entry in the corresponding profile. The usage extendedIPv6(3) implies that this is a IPv6 profile and all objects defined in the cippfIpFilterTable are valid for any filter entry in the corresponding profile. Enumeration: 'simple': 1, 'extendedIPv6': 3, 'extended': 2.

This value is the same as the last cippfIpFilterIndex value assigned to a filter of this profile.

This object controls and reflects the status of rows in this table. To create a filter profile of a particular usage type, the NMS must do a multivarbind set containing both cippfIpProfileStatus and cippfIpProfileType. Creation of rows must be done via 'createAndGo' for all profiles. When the agent successfully creates the filter profile, this object is set to 'active' by the agent. To delete a row, set this object value to 'destroy'.

This table lists all the IP protocol filter profiles being applied to IP traffic on the device interfaces. An IP protocol filter profile can be shared by multiple interfaces. The filter profiles are defined in the cippfIpProfileTable, and filters of these profiles are defined in the cippfIpFilterTable. Protocol filter profiles and their associated filters can be 'attached to' or 'removed from' in-bound or out-bound interfaces. Both existing and non-existing protocol filter profiles can be 'attached to' the interfaces. However, the cippfIfIpProfileStatus will only become 'active' if the filter profile exists in the cippfIpProfileTable, and the filters will then be applied to the IP traffic through the interface. Modification of any filters associated with a shared profile will affect all interfaces sharing that profile. Each interface can only be attached with one protocol filter profile on the in-bound direction and one on the out-bound direction.

Each entry attaches an IP traffic filter profile to a particular device interface and a specific traffic direction. The interface can be of any ifType supporting and running IP.

This object determines whether this filter profile is applied to inbound or outbound traffic of a particular interface. The possible value(s) are: inbound - inbound traffic. outbound - outbound traffic. inboundIPv6 - IPv6 inbound traffic. outboundIPv6 - IPv6 outbound traffic. Enumeration: 'inbound': 1, 'inboundIPv6': 3, 'outbound': 2, 'outboundIPv6': 4.

This is the unique IP protocol filter profile identifier. This value must be the same as one of the existing cippfIpProfileName object values in the cippfIpProfileTable for this profile and the cippfIfIpProfileStatus of value 'createAndGo' to become 'active'. If this object value does not match any existing cippfIpProfileName, an entry of this table can only be created with cippfIfIpProfileStatus in 'createAndWait' state. The entry can only be made 'active' by the agent when the corresponding cippfIpProfileName is added to the cippfIpProfileTable.

This object controls and reflects the status of rows in this table. To apply this filter profile or remove this filter profile, the NMS must do a multivarbind set containing both cippfIfIpProfileStatus and cippfIfIpProfileName. Creation of rows may be done via 'createAndGo' for profiles already exist in the cippfIpProfileTable, and the filter profile will only be effective when this object is set to 'active' by the agent. Creation of rows may also be done via 'createAndWait' for profiles do not exist in the cippfIpProfileTable. This object will be set by the agent to 'notReady', and the filter profile will not participate in IP filtering. This object will only be set to 'active' when there is a corresponding 'active' profile in the cippfIpProfileTable. To remove a row, set this object value to 'destroy'.

This table contains ordered lists of filters for all the IP protocol filter profiles. Device traffic filtering system applies filters of a filter profile according to the filter order position. IP packets matching any filter will be processed according to the matching action specified by the filter or they will be discarded if they do not match any filters. Any IP packet through an interface can theoretically match multiple filters or rows of this table of the same filter profile. When applying a filter to a packet, the cippfIfIpProfileTable is used to first identify the filter profile to use, then this table is scanned according to filter profile name and filter order position. If the packet matches all criteria for that row, the action defined in the cippfIpFilterAction object of the row will be taken. If the action for the matching filter is deny(1), the packet is discarded and the processing is completed. If the action for the matching filter is permit(2), the packet is accepted and permitted to be processed by the bridging or routing logic. If the packet matches no filter in this table, the packet is always deny(1) and will be dropped. To create a filter, the cippfIpProfileName must already exists in the cippfIpProfileTable. No filter can be created without an existing filter in the cippfIpProfileTable. If the filter profile is deleted from the cippfIpProfileTable, all the associated filters in this table will also be deleted.

Each entry is an IP Protocol traffic filter within an IP filter profile. Entries with the same cippfIpProfileName belong to the same IP filter profile.

This index uniquely identifies the IP protocol filters within this table and among all filter profiles. When a new filter is added and if this value is '0', the filter will be appended as the last entry for the corresponding profile in this table. For any set operation, the cippfIpFilterIndex value must match the index of an existing 'active' filter for the set operation to be successful.

This object is used to order the IP protocol filters within a filter profile. The filter with the lowest order position number is applied first, that is cippfIpFilterOrderPosition '1'. The order position number among all filters of a profile is always consecutive. The agent will automatically arrange the order position to a consecutive manner for the filter entries within the profile after each addition (when the created entry moves to 'active' state) and modification or deletion (when the active entry moves out from 'active' state) of any filter. For example, a new filter is added to an empty profile with the cippfIpFilterOrderPosition '2' , the filter will be actually positioned to cippfIpFilterOrderPosition '1' by the agent. Moreover, if there are 3 filters in the profile and their order positions are 1, 2, and 3. Adding a new filter with any cippfIpFilterOrderPosition greater than '3' will produce the same effect. The new filter will actually be in position '4' because the agent maintains the filters in consecutive order. When a filter is removed from a profile, the filters following this filter will be moved forward and decrement their order position numbers. For example, if there are 6 filters in the profile and their order positions are 1, 2, 3, 4, 5, 6. Deleting the filter of cippfIpFilterOrderPosition '4' will cause the existing filters of cippfIpFilterOrderPosition '5' and '6' to change to '4' and '5' respectively. When a filter is added to the order position of an existing filter of the same profile, the existing filter entry and all subsequent entries following it will increment their cippfIpFilterOrderPosition. This essentially move the existing filters towards the end of the filter profile. For example, if there are 6 filters in the profile, and their cippfIpFilterOrderPosition values are 1, 2, 3, 4, 5, 6. If the user would like to add a new one and specifies '4' to be the cippfIpFilterOrderPosition of the new filter, the existing filters of cippfIpFilterOrderPosition values 4, 5, 6 will become 5, 6, 7. The cippfIpFilterOrderPosition value '0' is a special number meaning to append the filter to the last filter of the profile. Continue with our previous example, if another new filter is added and the user specifies the cippfIpFilterOrderPosition to be '0'. The new filter will actually be created with cippfIpFilterOrderPosition equal to 8. Finally, moving a filter within a profile will have the same effect of first deleting and then adding the filter to the new position. For example, if the filter of cippfIpFilterOrderPosition 2 is moved to 4, the filters originally at the cippfIpFilterOrderPosition 3 and 4 will be moved forward to 2 and 3 respectively and filters of all other cippfIpFilterOrderPosition values will remain unchanged.

If it is set to deny(1), all packets matching this filter will be discarded and scanning of the remainder of the filter list will be aborted. If it is set to permit(2), all packets matching this filter will be allowed for further bridging or routing processing. Enumeration: 'deny': 1, 'permit': 2.

This is the IP address type of for the cippfIpFilterSrcAddress, cippfIpFilterSrcMask, cippfIpFilterDestAddress, and cippfIpFilterDestMask.

The source IP address to be matched for this filter. A value of zero causes all source address to match. The object value has to be consistent with the type specified in cippfIpFilterAddressType.

This is the wildcard mask for the cippfIpFilterSrcAddress bits that must match. 0 bits in the mask indicate the corresponding bits in the cippfIpFilterSrcAddress must match in order for the matching to be successful, and 1 bits are don't care bits in the matching. A value of zero causes only IP packets of source address the same as cippfIpFilterSrcAddress to match. This object value has to be consistent with the type specified in cippfIpFilterAddressType.

The destination IP address to be matched for this filter. A value of zero causes all source address to match. The object value has to be consistent with the type specified in cippfIpFilterAddressType.

This is the wildcard mask for the cippfIpFilterDestAddress bits that must match. 0 bits in the mask indicate the corresponding bits in the cippfIpFilterDestAddress must match in order for the matching to be successful, and 1 bits are don't care bits in the matching. A value of zero causes only IP packets of source address the same as cippfIpFilterSrcAddress to match. This object value has to be consistent with the type specified in cippfIpFilterAddressType.

This filter protocol object matches the Internet Protocol Number in the packets. These IP numbers are defined in the Network Working Group Request for Comments (RFC) documents. For example, Cisco commonly used protocol includes: 1 - Internet Control Message Protocol 2 - Internet Gateway Message Protocol 4 - IP in IP tunneling 6 - Transmission Control Protocol 9 - Cisco's IGRP routing protocol 17 - User Datagram Protocol 47 - Cisco's GRE tunneling 50 - Encapsulation Security Payload 51 - Authentication Header Protocol 88 - Cisco's EIGRP routing protocol 89 - OSPF routing protocol 94 - KA9Q NOS compatible IP over IP tunneling 103 - Protocol Independent Multicast 108 - Payload Compression Protocol Setting this object to '-1' will make the filtering match any IP number.

If cippfIpFilterProtocol is udp or tcp, this is the inclusive lower bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or less than the value specified for this entry in cippfIpFilterSrcPortHigh.

If cippfIpFilterProtocol is udp or tcp, this is the inclusive upper bound of the transport-layer source port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or greater than the value specified for this entry in cippfIpFilterSrcPortLow. If this value is '0', the udp or tcp port number is ignored during matching.

If cippfIpFilterProtocol is udp or tcp, this is the inclusive lower bound of the transport-layer destination port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or less than the value specified for this entry in cippfIpFilterDestPortHigh.

If cippfIpFilterProtocol is udp or tcp, this is the inclusive upper bound of the transport-layer destination port range that is to be matched, otherwise it is ignored during matching. This value must be equal to or greater than the value specified for this entry in cippfIpFilterDestPortLow. If this value is '0', the udp or tcp port number is ignored during matching.

The IP traffic precedence parameters in each packet are used to guide the selection of the actual service parameters when transmitting a datagram through a particular network. Most network treats high precedence traffic as more important than other traffic. The IP Precedence value ranges from '0' to '7', with '7' the highest precedence and '0' the lowest precedence. This object sets criteria for matching the IP packet precedence parameter. The object value '-1' means to match packets of any IP precedence. In other words, the IP precedence parameter will not to checked if this object is '-1'. The precedence level are: routine(0) - Routine traffic precedence priority(1) - Priority traffic precedence immediate(2) - Immediate traffic precedence flash(3) - Flash traffic precedence flashOverride(4) - Flash-override traffic precedence critical(5) - Critical precedence internet(6) - Internetwork control traffic precedence network(7) - Network control traffic precedence. Enumeration: 'network': 7, 'flash': 3, 'internet': 6, 'immediate': 2, 'priority': 1, 'critical': 5, 'routine': 0, 'flashOverride': 4, 'any': -1.

This is the value to match to the Type of Service (TOS) of the packet. The TOS values ranges from '0' to '15'. The value '-1' matches any TOS value.

This object specifies whether filtered packets will be logged by the filtering subsystem or not. If it is true(1), then all packets will be logged. If it is false(2), then no packet will be logged.

This object controls and reflects the status of rows in this table. Creation of rows must be done via 'createAndGo' and this object will become 'active' if the NMS performs a multivarbind set containing this object and the cippfIpFilterOrderPosition. The default matching action of a new filter is deny(1). Any object in a row can be modified any time when the row is in the 'active' state. Removal of a row can be done via setting this object to 'destroy'.

This filter specifies the ICMP message type to be matched. Setting this object to '-1' will make the filtering match any ICMP message type.

This filter if 'true' specifies that for TCP protocol, in an established connection, a match occurs if the TCP datagram has the ACK,FIN,PSH,RST,SYN or URG control bits set. If 'false' a match will occur for any TCP datagram.

If 'true', this filter applies only to the second and further fragments of fragmented packets. If 'false', the filter will only match head fragments or unfragmented packets. Note: Second and subsequent fragments do not contain source or destination ports info, therefore cannot be filtered on that basis.

This filter specifies the ICMP message code to be matched. Setting this object to '-1' will make the filtering match any ICMP code.

This object identifies the filter group containing information about source IP addresses and masks that need to be matched for this filter. This value must match an entry in cfgFilterGroupTable whose cfgFilterGroupType value is set to 'network' and must match an entry in cfgFilterNetworkGroupTable. This object cannot be set if any of the following objects are set: cippfIpFilterSrcAddress cippfIpFilterSrcMask. This object is not instantiated if not applicable.

This object identifies the filter group containing information about destination IP addresses and masks that need to be matched for this filter. This value must match an entry in cfgFilterGroupTable whose cfgFilterGroupType value is set to 'network' and must match an entry in cfgFilterNetworkGroupTable. This object cannot be set if any of the following objects are set: cippfIpFilterDestAddress cippfIpFilterDestMask. This object is not instantiated if not applicable.

This object identifies the filter group containing information about internet protocol numbers. This value must match an entry in cfgFilterGroupTable whose cfgFilterGroupType value is set to 'service' and must match an entry in cfgFilterServiceGroupTable. This object cannot be set if any of the following objects are set: cippfIpFilterProtocol. This object is not instantiated if not applicable.

This object identifies the filter group containing information about port(TCP/UDP) numbers. This value must match an entry in cfgFilterGroupTable whose cfgFilterGroupType value is set to 'service' and must match an entry in cfgFilterServiceGroupTable. This object cannot be set if any of the following objects are set: cippfIpFilterSrcPortLow cippfIpFilterSrcPortHigh This object is not instantiated if not applicable.

This object identifies the filter group containing information about port(TCP/UDP) numbers. This value must match an entry in cfgFilterGroupTable whose cfgFilterGroupType value is set to 'service' and must match an entry in cfgFilterServiceGroupTable. This object cannot be set if any of the following objects are set: cippfIpFilterDestPortLow cippfIpFilterDestPortHigh This object is not instantiated if not applicable.

This object identifies the filter group containing information about ICMP message. This value must match an entry in cfgFilterGroupTable whose cfgFilterGroupType value is set to 'icmp' and must match an entry in cfgFilterICMPGroupTable. This object cannot be set if any of the following objects are set: cippfIpFilterICMPType cippfIpFilterICMPCode. This object is not instantiated if not applicable.

This table is an extension to cippfIpFilterTable. This table is used for configuring the objects that are used for reporting the information about filters and reporting the logs. These objects do not change the match criteria for the filter but assist in troubleshooting the matched criteria.

An entry in filter extension table. Each entry contains information on the description of the filter and logging related objects.

This object is used for configuring description of the filter.

This object is used for specifying the log level (severity) used in syslog for this filter.

This object is used for configuring the time interval at which the syslog message for this filter to be generated.

This table defines a set of statistics related to packet filter. The statistics related to matched filters are available here.

An entry in IP Filter stats table. An entry exists in this table for every entry in cippfIpFilterTable.

This object specifies the number of packets that are matched the packet filter configuration in cippfIpFilterTable.

The compliance statement for entities implementing the Cisco IP Protocol Filter MIB. OBJECT cippfIpFilterAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION An implementation is only required to support IPv4 addresses. OBJECT cippfIpFilterSrcAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION An implementation is only required to support IPv4 addresses. OBJECT cippfIpFilterDestAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION An implementation is only required to support IPv4 addresses.

The compliance statement for entities implementing the Cisco IP Protocol Filter MIB. OBJECT cippfIpFilterAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION An implementation is only required to support IPv4 addresses. OBJECT cippfIpFilterSrcAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION An implementation is only required to support IPv4 addresses. OBJECT cippfIpFilterDestAddress SYNTAX InetAddress (SIZE(4)) DESCRIPTION An implementation is only required to support IPv4 addresses. OBJECT cippfIpFilterOrderPosition MIN-ACCESS read-only DESCRIPTION Write access is not required. OBJECT cippfIpProfileType MIN-ACCESS read-only DESCRIPTION Write access is not required.

The compliance statement for entities implementing the Cisco IP Protocol Filter MIB.

Configuration parameters for IP Protocol filters.

Configuration parameters for IP Protocol filters.

Configuration parameters for logging packet filters.

Configuration parameters for filter groups in a protocol filter.

This is a group containing objects related to packet filter.