300 likes | 323 Views
Learn about Internet Control Message Protocol (ICMP) for error reporting and network troubleshooting. ICMP messages inform about delivery problems and request action from the original source. Explore ICMP message delivery, formats, and common message types such as Echo Reply, Unreachable Destination, Source Quench, and Redirect. Dive into ICMP's vital role in maintaining reliable internet communication.
E N D
Internet Protocol: Error and Control Messages (ICMP) Chapter 8
We have • Unreliable • Connectionless datagram delivery… • Need a way to inform original source if: • Router cannot forward or deliver a datagram • Router detects unusual condition affecting the ability to forward a datagram • Original source will need to avoid or correct the problem
Internet Control Message Protocol • Routers operate autonomously • If everything works correctly, all ok. But: • Communication lines fail • Processors fail • Destination machines get disconnected from the network • TTL counters expire • Intermediate routers get congested
In an internet, no special hardware mechanisms to inform hosts of problems • Don’t know if failure is local or remote problem • Debugging is difficult • IP has nothing itself to help out • Added special-purpose message mechanism • Internet Control Message Protocol (ICMP) • Considered a required part of IP
ICMP messages travel in data portion of IP datagrams • ICMP: • Allows sending of error or control messages to other routers or hosts • Provides communication between IP software on one machine and IP software on another • ICMP module handles ICMP messages • Any machine can send an ICMP message
Error Reporting vs Correction • ICMP is technically a reporting mechanism • ICMP only reports error condition to source • Source must relate error to a specific application program or take other action • Most errors stem from original source • Some do not • ICMP only informs original source • Source may not be able to determine problem
Have to restrict communication to original source: • Datagrams don’t usually record complete route • Can’t know path taken to a given router • So cannot inform intermediate routers • Inform original source • Hope host administrators and network administrators will cooperate to solve problem
ICMP Message Delivery • ICMP uses two levels of encapsulation • ICMP message in datagram data portion • Datagram in frame data portion • Datagrams carrying ICMP messages: • Are forwarded the same way as others • May themselves get lost or discarded • May cause further congestion
Exception for error messages • ICMP messages not generated if error results from datagram carrying ICMP error message • ICMP not a higher-level protocol • It is a required part of IP • IP used to carry because messages may have to travel across several networks • Cannot be delivered by physical transport alone
ICMP Message Format • Each ICMP message has own format • But, all begin with three fields: • 8-bit integer message TYPE • 8-bit CODE field • 16-bit CHECKSUM • Also includes first 64 data bits of datagram causing the problem
Echo Reply and Request (0 & 8) • Command on many systems is ping • Sends echo request to a machine • Receiver sends echo reply to sender • Tests if destination is reachable & responding • Verifies source, outbound path, destination, and return path • Sophisticated versions send a series of requests and provide statistics about datagram loss
C:\>ping google.com Pinging google.com [64.233.187.99] with 32 bytes of data: Reply from 64.233.187.99: bytes=32 time=31ms TTL=239 Reply from 64.233.187.99: bytes=32 time=32ms TTL=239 Reply from 64.233.187.99: bytes=32 time=31ms TTL=239 Reply from 64.233.187.99: bytes=32 time=30ms TTL=239 Ping statistics for 64.233.187.99: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 30ms, Maximum = 32ms, Average = 31ms C:\>
Unreachable Destination (3) • Sent when router cannot forward or deliver a datagram
Discarding datagrams not taken lightly • Messages sent when router determines destination unreachable • Network unreachable: usually forwarding failure • Host unreachable: usually delivery failure • 13 types possible; specified in CODE field • However, routers cannot know all delivery failures • Destination on Ethernet • Network HW doesn’t provide acknowledgements
Source Quench (4) • Congestion: routers overrun with traffic • Can happen for two reasons: • High-speed computer generate traffic too fast for network to handle • Many computers sending thru same router • Datagrams buffered if arrive too fast • Helps with small burst • If continues, memory gets exhausted
Source quench used to report congestion • Requests source to reduce rate of transmission • Usually one message per discarded datagram • May be more sophisticated • Quench source with highest transmission rate • Avoid congestion by sending before overflow
Redirect (Route Change)(5) • Routers are assumed to know correct routes • Hosts begin with minimal forwarding info • Usually know the address of single router • Learn new routes from routers • One way is the ICMP redirect message • Router detects host using a non-optimal route • Redirect requests the host change its route • Host routing table stays small but optimal
Limitation: • Only have interactions between directly connected host and router • Later routers cannot send ICMP redirect • Don’t know non-directly connected router’s address • Redirect not used to solve general problem of propagating routing information Code 0: redirect for net Code 2: redirect for TOS and net Code 1: redirect for host Code 3: redirect for TOS and host
Time Exceeded (11) • Can get routing cycles • R1 sends datagrams for D to R2 • R2 sends datagrams for D to R1 • TTL (hop count) timer used to stop circle • ICMP time exceededmessage: • Sent when datagram discarded due to TTL=0 • Or, when timed out waiting for datagram fragments
Code 0: TTL count exceeded Code 1: Fragment reassembly time exceeded
Parameter Problem (12) • Problem exists with a datagram • Severe enough to cause it to be discarded • Uses pointer to ID octet that caused the problem Code 1: required option is missing (pointer field not used)
Timestamp Request & Reply (13 or 14) • Can have clock synchronization problem • Widely different clocks can confuse operations • Several protocols exist to synchronize clocks • One of simplest: • Machine sends ICMP timestamp request message • Receiver returns a timestamp reply
From originate time: - can compute total time From receive & transmit times: - can compute network transit time Then estimate differences in clocks
Information Request and Reply (15 or 16)*OBSOLETE* • Intended to allow hosts to discover internet address at startup • Made obsolete by DHCP
Address Mask Request & Reply (17 or 18)*OBSOLETE* • Chap 9 – motivation for subnets • Understand for now: • Some bits in hostid identify a physical network • Host needs to know: • Which bits correspond to the physical network • Which bits correspond to the host identifiers • Subnet mask: • 32-bit quantity allowing address interpretation • Intended to allow host to obtain the address mask used on the local network • Made obsolete by DHCP
Router Solicitation & Advertisement*OBSOLETE* • Intended to allow a host to discover routers available on the local network • Made obsolete by DHCP • Two differences from DHCP: • Host got info directly from router • Prevented hosts from retaining routes after a router crashes (soft state technique) • Routers advertise their information periodically • Host discards route when timer for it expires
Summary • Routers may need to communicate with network software on a particular host • Report abnormal condition • Send control information • Internet Control Message Protocol is used • Travels in data area of IP datagram • Three fixed-length fields at the beginning • Message type determines rest of format