LogMatrix NerveCenter™ Technical Note | ||
ICMP Message Handling within NerveCenter February 2018 v2.0 |
LogMatrix NerveCenter™ is most commonly used to monitor enterprise networks through two protocols: SNMP and ICMP. Either of these traffic types can be replied to with an ICMP message. The reply message might be generated by the destination host or a gateway along the path taken by the datagram. NerveCenter, therefore, must be aware of ICMP messages and handle them appropriately.
This Technical Note looks at the range of defined ICMP messages and how they relate to NerveCenter. The first section, ICMP, presents the extant set of ICMP message types. Its Table 1 shows the defined set of ICMP request and reply messages. This information is assembled from the set of RFCs named in the table plus the assignment information regarding ICMP that is tracked by IANA. The following two tables build upon this by displaying which of these ICMP messages could be issued in response to either an ICMP or an SNMP request message.
The following section, NerveCenter, then shows how NerveCente handles ICMP response messages. Based on the information from the first section's tables, Table 3 and Table 4 reveal NerveCenter's handling for each of these ICMP message types. Note that some ICMP messages are historic or obsolete; therefore, no handling is required.
Table 1 shows the set of defined set of ICMP message types. Messages are encoded using Type and Code values as shown. While the Type field usually serves as the primary key for a particular group of ICMP messages, this is not always the case. The Echo or Echo Reply group, for example, uses two Type values: one for the request and one for the reply.
While some message groups form a response/reply set, other do not. The Destination Unreachable group, for example, can be issued in response to any IP-based message on the network; there is no explicit 'request' message for this group. On the other hand the Echo group has a clearly defined 'request' and 'reply' message pair. The same is true of the Timestamp and Information groups.
The table's Origin columns show which network nodes could generate such a message. Src Host is typically a management station, sending an ICMP or other IP-based request message to a specified Dest Host. An ICMP reply message is potentially generated either by the Dest Host or else by a gateway along the route taken by the request message.
Several of the groups can be considered Historic - meaning here that they are defined by their respective RFCs but are not known to have been implemented.i These are the groups Conversion Failed, Domain Name and Security Failures. For the sake of completeness, they are covered throughout this document; however, the likelihood of ever encountering them would be highly unlikely.
Message | Origin | Description | Reference | |||||
---|---|---|---|---|---|---|---|---|
Type | Code | src host |
gateway | dest host |
||||
# | Label | # | Label | |||||
3 | Destination Unreachable | 0 | net unreachable | - | yes | no | The specified network is unreachable. | RFC792 |
1 | host unreachable | - | yes | no | The specified host is unreachable. | RFC792 | ||
2 | protocol unreachable | - | no | yes | The indicated protocol module is not active. | RFC792 | ||
3 | port unreachable | - | no | yes | The indicated process port is not active. | RFC792 | ||
4 | fragmentation needed and DF set | - | yes | no | The datagram must be fragmented in order to be forwarded; however, the Don't Fragement flag is on. | RFC792 RFC1191 |
||
5 | source route failed | - | yes | no | Datagram cannot be route under current (transient) routing state | RFC792 | ||
6 | destination network unknown | - | yes | no | no route (include default route) is valid for this datagram's target | RFC1122 | ||
7 | destination host unknown | - | yes | no | no known host matches this datagram's target. | RFC1122 | ||
8 | source host isolated | - | no | yes | Source host isolated. | RFC1122 | ||
9 | communication with destination network is administratively prohibited | - | no | yes | (for use by end-to-end encryption devices used by U.S military agencies) | RFC1108 RFC1812 |
||
10 | communication with destination host is administratively prohibited | - | no | yes | (for use by end-to-end encryption devices used by U.S military agencies) | RFC1108 RFC1812 |
||
11 | destination network unreachable for Type of Service | - | yes | no | The TOS specified for a defined route is neither the default TOS nor the TOS of the datagram that the gateway is attempting to route. | RFC1122 | ||
12 | destination network unreachable for Type of Service | - | yes | no | The TOS specified for a directly connected host is neither the default TOS nor the TOS of the datagram that the gateway is attempting to route. | RFC1122 | ||
13 | communication administratively prohibited | - | yes | no | Administrative filtering prohibits gateway from forwarding datagram. | RFC1812 | ||
14 | host precedence violation | - | yes | no | The datagram's requested precedence is not permitted for the combination of source/destination host or network, upper layer protocol, and source/destination port. | RFC1812 | ||
15 | precedence cutoff in effect | - | yes | no | The datagram's requested precedence is below the administratively set required level for this operation. | RFC1812 | ||
11 | Time Exceeded | 0 | time to live exceeded in transit | - | yes | no | Datagram has time to live field set to 0 (zero) | RFC792 |
1 | fragment reassembly time exceeded | - | no | yes | A fragmented datagram cannot be reassembled with the host's time limit. | RFC792 | ||
12 | Parameter Problem | 0 | pointer indicates the error | - | yes | yes | A problem exists with the datagram's header parameters. | RFC792 |
1 | required option is missing | - | yes | yes | Datagram has no Basic Security Option option and this was required for receival on a given network port. | RFC1108 | ||
2 | bad length | - | yes | yes | bad length | IANA | ||
4 | Source Quench | 0 | pointer indicates the error | - | yes | yes | Datagram arrival is too fast for processing. | RFC792 |
5 | Redirect | 0 | redirect datagrams for the network | - | yes | no | Gateway advises the source host to send datagram instead to alternate gateway. | RFC792 |
1 | redirect datagrams for the host | - | yes | no | RFC792 | |||
2 | redirect datagrams for the Type of Service and Network | - | yes | no | RFC792 | |||
3 | redirect datagrams for the Type of Service and Host | - | yes | no | RFC792 | |||
8 | Echo or Echo Reply | 0 | echo | yes | - | - | echo | RFC792 |
0 | 0 | echo reply | - | yes | yes | echo reply | RFC792 | |
13 | Timestamp or Timestamp Reply | 0 | timestamp | - | - | - | timestamp | RFC792 |
14 | 0 | timestamp reply | - | yes | yes | timestamp reply | RFC792 | |
15 | Information Request or Information Reply | 0 | information request | - | - | - | information request (Obsolete) | RFC792 |
16 | 0 | information reply | - | no | yes | information reply (Obsolete) | RFC792 | |
17 | Address Mask | 0 | address mask request | yes | yes | - | Request for net mask information. | RFC950 |
18 | 0 | address mask reply | - | yes | yes | Reply containing net mask information. | RFC950 | |
9 | Router Discovery | 0 | router advertisement | - | yes | no | Announcement of IP address(es) of a given interface. | RFC1256 |
16 | does not route common traffic | - | yes | no | Mobility agent does not route common traffic. | RFC2002 | ||
10 | 0 | router solicitation | yes | no | no | Solicitation for a router advertisement. | RFC1256 | |
30 | Traceroute | 0 | outbound packet successfully forwarded | - | yes | no | Request has been forwarded. | RFC1393 |
1 | no route for outbound packet; packet discarded | - | yes | no | Request cannot be forwarded. | RFC1393 | ||
31 | Conversion Failed (Historic) |
0 | unknown/unspecified error | - | yes | yes | These ICMP Messages are in support of RFC1475's "TP/IX: The Next Internet" specification. This RFC, published in June 1993, proposed "IP version 7." | RFC1475 |
1 | don't convert option present | - | yes | yes | RFC1475 | |||
2 | unknown mandatory option present | - | yes | yes | RFC1475 | |||
3 | known unsupported option present | - | yes | yes | RFC1475 | |||
4 | unsupported transport protocol | - | yes | yes | RFC1475 | |||
5 | overall length exceeded | - | yes | yes | RFC1475 | |||
6 | IP header length exceeded | - | yes | yes | RFC1475 | |||
7 | transport protocol > 255 | - | yes | yes | RFC1475 | |||
8 | port conversion out of range | - | yes | yes | RFC1475 | |||
9 | transport header length exceeded | - | yes | yes | RFC1475 | |||
10 | 32 bit rollover missing and ACK set | - | yes | yes | RFC1475 | |||
11 | unknown mandatory transport option present | - | yes | yes | RFC1475 | |||
37 | Domain Name (Historic) |
0 | domain name request | yes | - | - | Domain Name request | RFC1788 |
38 | 0 | domain name reply | - | yes | yes | Domain Name reply | RFC1788 | |
40 | Security Failures (Historic) |
0 | bad SPI | - | yes | yes | RFC2521 | |
1 | authentication failed | - | yes | yes | RFC2521 | |||
2 | decompression failed | - | yes | yes | RFC2521 | |||
3 | decryption failed | - | yes | yes | RFC2521 | |||
4 | need authentication | - | yes | yes | RFC2521 | |||
5 | need authorization | - | yes | yes | RFC2521 |
Although the above table reveals that there is a large set of defined ICMP messages, a management application's usage of ICMP and SNMP limits the range that the application needs to handle. The context of the traffic issued by the management application defines the range of potential ICMP replies. Table 2a and Table 2b demonstrate this. Each shows the potential range of ICMP replies based on the communication context: an issued ICMP or SNMP request message.
The fields marked "yes" are possible replies to the request message. For example, an ICMP Echo request [Refer to the Olive colored row in the folowing table] issued by an application can only be responded to by one of the indicated ICMP message types. An Echo Reply is the "normal" response; yet, messages from the groups Destination Unreachable, Time Exceeded, Parameter Problem, Source Quence and Redirect are also possible. A Timestamp query or reply would not occur as a response; the messages defined in this group do not fit the context of an Echo request. However zero, one or more Traceroute messages might also be received if the Echo request also contained the traceroute option in its IP header. This is a deliberate action on the part of the sending application. These traceroute messages would arrive in addition to one of the already listed replies.
ICMP Request Message | Possible ICMP Responses (by group name) | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Destination Unreachable | Time Exceeded | Parameter Problem | Source Quench | Redirect | Echo Reply | Timestamp | Information | Address Mask | Router Discovery | Traceroute1 | Domain Name | ||
Notes:
|
|||||||||||||
Echo [8,0] | yes | yes | yes | yes | yes | yes | no | no | no | no | yes | no | |
Timestamp [8,0] | yes | yes | yes | yes | yes | no | yes | no | no | no | yes | no | |
Information Request [15,0] | yes | yes | yes | yes | yes | no | no | yes | no | no | yes | no | |
Address Mask Request [17,0] | yes | yes | yes | yes | yes | no | no | no | yes | no | yes | no | |
Router Solicitation [9,0] | yes | yes | yes | yes | yes | no | no | no | no | yes | yes | no | |
Domain Name Request [37,0] | yes | yes | yes | yes | yes | no | no | no | no | no | yes | yes |
For SNMP messages, the range of possible ICMP replies maps into the same set of error reporting as seen for ICMP messages. The "normal" SNMP reply is the Resonse PDU. Report PDUs and the marked range of ICMP replies all indicate various forms of error responses.ii
SNMP Request Message | Possible SNMP responses | Possible ICMP Responses (by group name) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Response1 | Report2 | Destination Unreachable | Time Exceeded | Parameter Problem | Source Quench | Redirect | Echo Reply | Timestamp | Information | Address Mask | Router Discovery | Traceroute3 | Domain Name | ||
Notes:
|
|||||||||||||||
SNMPv1 / SNMPv2c / SNMPv3 | |||||||||||||||
Get | yes | yes | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no | |
GetNext | yes | yes | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no | |
Set | yes | yes | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no | |
SNMPv2c / SNMPv3 only | |||||||||||||||
GetBulk | yes | yes | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no | |
Inform | yes | yes | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no | |
SNMPv2-Trap | no | no | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no | |
SNMPv1 only | |||||||||||||||
Trap | no | no | yes | yes | yes | yes | yes | no | no | no | no | no | yes | no |
LogMatrix NerveCenter monitors network devices with ICMP Echo (Ping) requests and SNMP Get, GetNext and Set requests. The set of employed request messages are marked with an olive coloring in Table 2a and Table 2b. NerveCenter never sets the IP header traceroute option. Using this information it is thus possible to list the set ICMP messages which NerveCenter must suppport. The following two sections review this support for NerveCenter3.7 and NerveCenter3.8 respectively.
NerveCenter 2 and 3 used a release of the Epilogue® SNMP Stack to encode and decode both SNMP and ICMP messages. This release of Epilogue, from 10/1998, was produced before the purchase of its developer, Integrated Systems, by Wind River Systems.
Table 3 shows NerveCenter3's handling of the above range of ICMP messages as well as some of the labels and output messages customers might see associated with them.
ICMP Message | Open NerveCenter™ Handling | |||||||
---|---|---|---|---|---|---|---|---|
Message | NerveCenter3.7 | |||||||
Type | Code | Epilogue® SNMP Stack | ncserver | |||||
# | Label | # | Label | Type | Code | Code/Label | Handling | |
Notes:
|
||||||||
3 | Destination Unreachable | 0 | net unreachable | ICMP_UNREACH | ICMP_UNREACH_NET | NC_NET_UNREACHABLE "... (network unreachable)" |
Error Response, Retry request1 |
|
1 | host unreachable | ICMP_UNREACH_HOST | NC_NODE_UNREACHABLE "... (node unreachable)" |
|||||
2 | protocol unreachable | ICMP_UNREACH_PROTOCOL | NC_ICMP_UNREACH_PROTOCOL "... (protocol unreachable)" | |||||
3 | port unreachable | ICMP_UNREACH_PORT | NC_PORT_UNREACHABLE "... (port unreachable)" |
|||||
4 | fragmentation needed and DF set | ICMP_UNREACH_NEEDFRAG | NC_ICMP_UNREACH_NEEDFRAG "... (needs fragmentation but "Don't Fragement" bit is set)" |
|||||
5 | source route failed | ICMP_UNREACH_SRCFAIL | NC_ICMP_UNREACH_SRCFAIL "... (source route has failed)" |
|||||
6 | destination network unknown | ICMP_UNREACH_NET_UNKNOWN | NC_ICMP_UNREACH_NET_UNKNOWN "... (destination net unknown)" |
|||||
7 | destination host unknown | ICMP_UNREACH_HOST_UNKNOWN | NC_ICMP_UNREACH_HOST_UNKNOWN "... (destination host unknown)" |
|||||
8 | source host isolated | ICMP_UNREACH_ISOLATED | NC_ICMP_UNREACH_ISOLATED "... (source isolated)" |
|||||
9 | communication with destination network is administratively prohibited | ICMP_UNREACH_NET_PROHIB | NC_ICMP_UNREACH_NET_PROHIB "... (net administratively prohibited)" |
|||||
10 | communication with destination host is administratively prohibited | ICMP_UNREACH_HOST_PROHIB | NC_ICMP_UNREACH_HOST_PROHIB "... (host administratively prohibited)" |
|||||
11 | destination network unreachable for Type of Service | ICMP_UNREACH_TOSNET | NC_ICMP_UNREACH_TOSNET "... (net unreachable for specific TOS)" |
|||||
12 | destination network unreachable for Type of Service | ICMP_UNREACH_TOSHOST | NC_ICMP_UNREACH_TOSHOST "... (host unreachable for specific TOS)" |
|||||
13 | communication administratively prohibited | ICMP_UNREACH_FILTER_PROHIB | NC_ICMP_UNREACH_FILTER_PROHIB "... (comm administratively prohibited by filtering)" |
|||||
14 | host precedence violation | ICMP_UNREACH_HOST_PRC_VIOLATED | NC_ICMP_UNREACH_HOST_PRC_VIOLATED "... (host precedence violation)" |
|||||
15 | precedence cutoff in effect | ICMP_UNREACH_PRC_CUTOFF | NC_ICMP_UNREACH_PRC_CUTOFF "... (precedence cutoff in effect)" |
|||||
11 | Time Exceeded | 0 | time to live exceeded in transit | ICMP_TIMXCEED | ICMP_TIMXCEED_INTRANS | NC_ICMP_TIMXCEED_INTRANS "... (TTL exceeded)" |
Error Response, Retry request |
|
1 | fragment reassembly time exceeded | ICMP_TIMXCEED_REASS | NC_ICMP_TIMXCEED_REASS "... (Fragment re-assembly time exceeded)" |
|||||
12 | Parameter Problem | 0 | pointer indicates the error | ICMP_PARAMPROB | none | NC_ICMP_PARAMPROB_ERROCCR "... (error in parameter)" |
Error Response, Retry request |
|
1 | required option is missing | ICMP_PARAMPROB_OPTABSENT | NC_ICMP_PARAMPROB_OPTABSENT "... (required option missing)" |
|||||
2 | bad length | none | none | |||||
4 | Source Quench | 0 | pointer indicates the error | ICMP_SOURCEQUENCH | - | NC_ICMP_SOURCEQUENCH "... (source quench)" |
Error Response, Retry request |
|
5 | Redirect | 0 | redirect datagrams for the network | ICMP_REDIRECT | NC_ICMP_REDIRECT_NET | ICMP_REDIRECT_NET "... (redirect datagrams for the net)" |
Retry Request | |
1 | redirect datagrams for the host | ICMP_REDIRECT_HOST | NC_ICMP_REDIRECT_HOST "... (redirect datagrams for the host)" |
|||||
2 | redirect datagrams for the Type of Service and Network | ICMP_REDIRECT_TOSNET | NC_ICMP_REDIRECT_TOSNET "... (redirect datagrams for the TOS & net)" |
|||||
3 | redirect datagrams for the Type of Service and Host | ICMP_REDIRECT_TOSHOST | NC_ICMP_REDIRECT_TOSHOST "... (redirect datagrams for the TOS & host)" |
|||||
8 | Echo or Echo Reply | 0 | echo | ICMP_ECHO | - | NC_ICMP_ECHO "... (echo)" |
Non-error reply, Mark this IP Address as "Up" |
|
0 | 0 | echo reply | ICMP_ECHOREPLY | - | NC_NO_ERROR | |||
13 | Timestamp or Timestamp Reply | 0 | timestamp | ICMP_TSTAMP | - | NerveCenter does not need to handle these ICMP messages. NerveCenter's use of ICMP and SNMP does not lead to a context where these messages could be encountered. | ||
14 | 0 | timestamp reply | ICMP_TSTAMPREPLY | - | ||||
15 | Information Request or Information Reply | 0 | information request | ICMP_IREQ | - | |||
16 | 0 | information reply | ICMP_IREQREPLY | - | ||||
17 | Address Mask | 0 | address mask request | ICMP_MASKREQ | - | |||
18 | 0 | address mask reply | ICMP_MASKREPLY | - | ||||
9 | Router Discovery | 0 | router advertisement | ICMP_ROUTERADVERT | - | |||
10 | 0 | router solicitation | ICMP_ROUTERSOLICIT | - | ||||
30 | Traceroute | 0 | outbound packet successfully forwarded | none | none | |||
1 | no route for outbound packet; packet discarded |
NerveCenter, from version 4 onward to the present version 8 releases, uses the SNMP Research BRASSTM SNMP Stack to encode and decode both SNMP and ICMP messages. Table 4 shows NerveCenter's handling of the range of ICMP messages as well as some of the labels and output messages customers might see associated with them.
As most of the query/request and response ICMP Messages are not related to the traffic types and NerveCenter issues, the BRASS SNMP Stack simplifies NerveCenter by filtering them out. Some, such as Source Quench and Redirect are handled internally by BRASS while others such as Address Mask request/reply messages can be ignored.
ICMP Message | NerveCenter™ Handling | |||||||
---|---|---|---|---|---|---|---|---|
Message | NerveCenter v4 - v8 | |||||||
Type | Code | BRASSTM SNMP Stack | ncserver | |||||
# | Label | # | Label | Tag | Code/Label | Handling | ||
3 | Destination Unreachable | 0 | net unreachable | RESP_DU_NET | NC_NET_UNREACHABLE "... (network unreachable)" |
Error Response, Retry request. |
||
1 | host unreachable | RESP_DU_HOST | NC_NODE_UNREACHABLE "... (node unreachable)" |
|||||
2 | protocol unreachable | RESP_DU_PROTO | NC_ICMP_UNREACH_PROTOCOL "... (protocol unreachable)" | |||||
3 | port unreachable | RESP_DU_PORT | NC_PORT_UNREACHABLE "... (port unreachable)" |
|||||
4 | fragmentation needed and DF set | RESP_DU_FRAG | NC_ICMP_UNREACH_NEEDFRAG "... (needs fragmentation but "Don't Fragement" bit is set)" |
|||||
5 | source route failed | RESP_DU_SRC_RT | NC_ICMP_UNREACH_SRCFAIL "... (source route has failed)" |
|||||
6 | destination network unknown | RESP_DU_NET_UNK | NC_ICMP_UNREACH_NET_UNKNOWN "... (destination net unknown)" |
|||||
7 | destination host unknown | RESP_DU_HOST_UNK | NC_ICMP_UNREACH_HOST_UNKNOWN "... (destination host unknown)" |
|||||
8 | source host isolated | RESP_DU_HOST_ISO | NC_ICMP_UNREACH_ISOLATED "... (source isolated)" |
|||||
9 | communication with destination network is administratively prohibited | RESP_DU_NET_ADM_PRO | NC_ICMP_UNREACH_NET_PROHIB "... (net administratively prohibited)" |
|||||
10 | communication with destination host is administratively prohibited | RESP_DU_HOST_ADM_PRO | NC_ICMP_UNREACH_HOST_PROHIB "... (host administratively prohibited)" |
|||||
11 | destination network unreachable for Type of Service | RESP_DU_NU_TOS | NC_ICMP_UNREACH_TOSNET "... (net unreachable for specific TOS)" |
|||||
12 | destination network unreachable for Type of Service | RESP_DU_HU_TOS | NC_ICMP_UNREACH_TOSHOST "... (host unreachable for specific TOS)" |
|||||
13 | communication administratively prohibited | RESP_DU_COM_ADM_PRO | NC_ICMP_UNREACH_FILTER_PROHIB "... (comm administratively prohibited by filtering)" |
|||||
14 | host precedence violation | RESP_DU_HOST_PREC | NC_ICMP_UNREACH_HOST_PRC_VIOLATED "... (host precedence violation)" |
|||||
15 | precedence cutoff in effect | RESP_DU_PREC_CUTOFF | NC_ICMP_UNREACH_PRC_CUTOFF "... (precedence cutoff in effect)" |
|||||
11 | Time Exceeded | 0 | time to live exceeded in transit | BRASS handles these returns internally by retrying the request that caused them. BRASS will not forward these messages to NerveCenter. |
NerveCenter does not need to handle these messages; BRASS handles them on behalf of NerveCenter. | |||
1 | fragment reassembly time exceeded | |||||||
12 | Parameter Problem | 0 | pointer indicates the error | |||||
1 | required option is missing | |||||||
2 | bad length | |||||||
4 | Source Quench | 0 | pointer indicates the error | |||||
5 | Redirect | 0 | redirect datagrams for the network | |||||
1 | redirect datagrams for the host | |||||||
2 | redirect datagrams for the Type of Service and Network | |||||||
3 | redirect datagrams for the Type of Service and Host | |||||||
8 | Echo or Echo Reply | 0 | echo | BRASS provides an API for handling these messages. | NC_ICMP_ECHO "... (echo)" |
Non-error reply, Mark this IP Address as "Up" |
||
0 | 0 | echo reply | NC_NO_ERROR | |||||
13 | Timestamp or Timestamp Reply | 0 | timestamp | BRASS handles these messages internally. Such messages are not likely to occur as BRASS does not generate these request messages and so should not have to handle any of the response message types. BRASS will not forward these messages to NerveCenter. |
NerveCenter does not need to handle these ICMP messages. NerveCenter's use of ICMP and SNMP does not lead to a context where these messages could be encountered. | |||
14 | 0 | timestamp reply | ||||||
15 | Information Request or Information Reply | 0 | information request | |||||
16 | 0 | information reply | ||||||
17 | Address Mask | 0 | address mask request | |||||
18 | 0 | address mask reply | ||||||
9 | Router Discovery | 0 | router advertisement | |||||
10 | 0 | router solicitation | ||||||
30 | Traceroute | 0 | outbound packet successfully forwarded | |||||
1 | no route for outbound packet; packet discarded |
Last modified: Fri Feb 23 17:19:02 EST 2018