Download WAP - ICMP - Extra Reading File

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

IEEE 802.1aq wikipedia , lookup

AppleTalk wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

Piggybacking (Internet access) wikipedia , lookup

Net bias wikipedia , lookup

Airborne Networking wikipedia , lookup

Distributed firewall wikipedia , lookup

Computer network wikipedia , lookup

Point-to-Point Protocol over Ethernet wikipedia , lookup

Network tap wikipedia , lookup

SIP extensions for the IP Multimedia Subsystem wikipedia , lookup

RapidIO wikipedia , lookup

TCP congestion control wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Internet protocol suite wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Deep packet inspection wikipedia , lookup

IEEE 1355 wikipedia , lookup

Packet switching wikipedia , lookup

UniPro protocol stack wikipedia , lookup

Wake-on-LAN wikipedia , lookup

Routing in delay-tolerant networking wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Real-Time Messaging Protocol wikipedia , lookup

Transcript
Ch. 8 TCP/IP Suite Error and
Control Messages (ICMP)
CCNA 1 version 3.0
Rick Graziani
Cabrillo College
Note to instructors
• If you have downloaded this presentation from the Cisco Networking
Academy Community FTP Center, this may not be my latest version of
this PowerPoint.
• For the latest PowerPoints for all my CCNA, CCNP, and Wireless
classes, please go to my web site:
http://www.cabrillo.cc.ca.us/~rgraziani/
• The username is cisco and the password is perlman for all of
my materials.
• If you have any questions on any of my materials or the curriculum,
please feel free to email me at [email protected] (I really don’t
mind helping.) Also, if you run across any typos or errors in my
presentations, please let me know.
• I will add “(Updated – date)” next to each presentation on my web site
that has been updated since these have been uploaded to the FTP
center.
Thanks! Rick
Rick Graziani [email protected]
2
Overview
•
•
Knowledge of ICMP control messages is an essential part
of network troubleshooting and is a key to a full
understanding of IP networks.
This module will:
– Describe ICMP
– Describe the ICMP message format
– Identify ICMP error message types
– Identify potential causes of specific ICMP error
messages
– Describe ICMP control messages
– Identify a variety of ICMP control messages used in
networks today
– Determine the causes for ICMP control messages
Rick Graziani [email protected]
3
Overview
IP is a best effort delivery system.
• Data may fail to reach its destination for a variety of reasons, such
as hardware failure, improper configuration or incorrect routing
information.
• IP does not have a built-in mechanism for sending error and control
messages.
• IP also lack a mechanism for host and management queries.
Internet Control Message Protocol (ICMP) was designed to handle
these issues.
Rick Graziani [email protected]
4
ICMP
•
•
ICMP messages can be divided into categories (depending
upon the author.
The Cisco curriculum divides it into:
– Error-Reporting Messages
– Suite Control Messages
Rick Graziani [email protected]
5
Internet Control Message Protocol (ICMP)
• IP is an unreliable method for delivery of network data.
• Nothing in its basic design allows IP to notify the sender that a data
•
•
•
transmission has failed.
Internet Control Message Protocol (ICMP) is the component of the
TCP/IP protocol stack that addresses this basic limitation of IP.
ICMP does not overcome the unreliability issues in IP.
Reliability must be provided by upper layer protocols (TCP or the
application) if it is needed. .
Rick Graziani [email protected]
6
Error reporting and error
correction
• When datagram delivery errors
occur, ICMP is used to report
these errors back to the source
of the datagram.
ICMP
msg
source
X
destination
Example
• Workstation 1 is sending a datagram to Workstation 6
• Fa0/0 on Router C goes down
• Router C then utilizes ICMP to send a message back to Workstation 1
indicating that the datagram could not be delivered.
• ICMP does not correct the encountered network problem.
• Router C knows only the source and destination IP addresses of the
datagram, not know about the exact path the datagram took to Router
C, therefore, Router C can only notify Workstation 1 of the failure
• ICMP reports on the status of the delivered packet only to the source
device.
Rick Graziani [email protected]
7
ICMP message delivery
• ICMP messages are encapsulated into datagrams in the same way any
•
•
•
•
other data is delivered using IP.
Subject to the same delivery failures as any IP packet.
This creates a scenario where error reports could generate more error
reports, causing increased congestion on an already ailing network.
For this reason, errors created by ICMP messages do not generate
their own ICMP messages.
It is thus possible to have a datagram delivery error that is never
reported back to the sender of the data.
Rick Graziani [email protected]
8
Format of an ICMP
Message
http://www.iana.org/assignments/icmp-parameters
Type Field
Type
---0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Name
------------------------Echo Reply
Unassigned
Unassigned
Destination Unreachable
Source Quench
Redirect
Alternate Host Address
Unassigned
Echo
Router Advertisement
Router Solicitation
Time Exceeded
Parameter Problem
Timestamp
Timestamp Reply
Information Request
Information Reply
Rick Graziani [email protected]
Type
---17
18
19
20-29
30
31
32
33
34
35
36
37
38
39
40
41-255
Name
------------------------Address Mask Request
Address Mask Reply
Reserved (for Security)
Reserved (for Robustness Experiment)
Traceroute
Datagram Conversion Error
Mobile Host Redirect
IPv6 Where-Are-You
IPv6 I-Am-Here
Mobile Registration Request
Mobile Registration Reply
Domain Name Request
Domain Name Reply
SKIP
Photuris
Reserved
9
Format of an ICMP
Message
http://www.iana.org/assignments/icmp-parameters
Code Field
Type 3: Destination Unreachable
Many of these ICMP types have a "code"
field.
Here are the assigned code fields for Type 3
Destination Unreachable.
Codes
Codes 2 and 3 are created only by the
0 Net Unreachable
Destination Host, all others are created only
1 Host Unreachable
by routers.
2 Protocol Unreachable
3 Port Unreachable
4 Fragmentation Needed and Don't Fragment was Set
5 Source Route Failed
6 Destination Network Unknown
7 Destination Host Unknown
8 Source Host Isolated
9 Communication with Destination Network is Administratively Prohibited
10 Communication with Destination Host is Administratively Prohibited
11 Destination Network Unreachable for Type of Service
12 Destination Host Unreachable for Type of Service
13 Communication Administratively Prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
Rick Graziani [email protected]
10
ICMP Error Messages
Unreachable
networks
Network communication depends upon certain basic conditions being
met:
• Sending and receiving devices must have the TCP/IP protocol stack
properly configured.
 proper configuration of IP address and subnet mask.
 A default gateway must also be configured if datagrams are to
travel outside of the local network.
• A router also must have the TCP/IP protocol properly configured on its
interfaces, and it must use an appropriate routing protocol.
If these conditions are not met, then network communication cannot take
place.
Rick Graziani [email protected]
12
Unreachable
networks
Examples of problems:
• Sending device may address the datagram to a non-existent IP
address
• Destination device that is disconnected from its network.
• Router’s connecting interface is down
• Router does not have the information necessary to find the destination
network.
Rick Graziani [email protected]
13
Destination unreachable message
ICMP Destination Unreachable
Type = 3
• If datagrams cannot always be forwarded to their destinations,
•
•
ICMP delivers back to the sender a destination unreachable
message indicating to the sender that the datagram could not be
properly forwarded.
A destination unreachable message may also be sent when packet
fragmentation is required in order to forward a packet.
– Fragmentation is usually necessary when a datagram is forwarded
from a Token-Ring network to an Ethernet network.
– If the datagram does not allow fragmentation, the packet cannot be
forwarded, so a destination unreachable message will be sent.
– More a little later on fragmentation and MTU Path Discovery!
Destination unreachable messages may also be generated if IP
related services such as FTP or Web services are unavailable.
Rick Graziani [email protected]
14
ICMP Echo (Request) and Echo Reply
Echo = Type 8
Echo Reply = Type 0
Ethernet Header
(Layer 2)
Ethernet
Destination
Address
(MAC)
Ethernet
Source
Address
(MAC)
Frame
Type
IP Header
(Layer 3)
ICMP Message
(Layer 3)
Source IP Add.
Dest. IP Add.
Protocol field
Type
0 or 8
Code
0
Ether.
Tr.
Checksum
ID
Seq.
Num.
Data
FCS
• IP Protocol Field = 1
• The echo request message is typically initiated using the ping
command .
Rick Graziani [email protected]
15
For more information on Ping
Here are two options for more information on Ping:
• See my PowerPoint presentation: ICMP – Understanding Ping and Trace
• Read the book: The Story About Ping
by Marjorie Flack, Kurt Wiese (See a Amazon.com customer review on next
slide – very funny!
Rick Graziani [email protected]
16
Review of Story of Ping on Amazon.com
(5 Stars) Ping! I love that duck!, January 25, 2000
Reviewer: A reader from El Segundo
PING! The magic duck!
Using deft allegory, the authors have provided an insightful and intuitive explanation of one of Unix's most
venerable networking utilities. Even more stunning is that they were clearly working with a very early beta
of the program, as their book first appeared in 1933, years (decades!) before the operating system and
network infrastructure were finalized.
The book describes networking in terms even a child could understand, choosing to anthropomorphize the
underlying packet structure. The ping packet is described as a duck, who, with other packets (more
ducks), spends a certain period of time on the host machine (the wise-eyed boat). At the same time each
day (I suspect this is scheduled under cron), the little packets (ducks) exit the host (boat) by way of a
bridge (a bridge). From the bridge, the packets travel onto the internet (here embodied by the Yangtze
River).
The title character -- er, packet, is called Ping. Ping meanders around the river before being received by
another host (another boat). He spends a brief time on the other boat, but eventually returns to his
original host machine (the wise-eyed boat) somewhat the worse for wear.
If you need a good, high-level overview of the ping utility, this is the book. I can't recommend it for most
managers, as the technical aspects may be too overwhelming and the basic concepts too daunting.
Problems With This Book
As good as it is, The Story About Ping is not without its faults. There is no index, and though the ping(8) man
pages cover the command line options well enough, some review of them seems to be in order. Likewise,
in a book solely about Ping, I would have expected a more detailed overview of the ICMP packet
structure.
But even with these problems, The Story About Ping has earned a place on my bookshelf, right between
Stevens' Advanced Programming in the Unix Environment, and my dog-eared copy of Dante's seminal
work on MS Windows, Inferno. Who can read that passage on the Windows API ("Obscure, profound it
was, and nebulous, So that by fixing on its depths my sight -- Nothing whatever I discerned therein."),
without shaking their head with deep understanding. But I digress. --This text refers to the School &
Library Binding edition.
Rick Graziani [email protected]
17
Detecting excessively long routes
IP Header
0
15 16
4-bit
Version
4-bit
Header
Length
8-bit Type Of
Service
(TOS)
16-bit Total Length (in bytes)
3-bit
Flags
16-bit Identification
8 bit Time To Live
TTL
31
8-bit Protocol
13-bit Fragment Offset
16-bit Header Checksum
32-bit Source IP Address
32-bit Destination IP Address
Options (if any)
ICMP Time Exceeded
Type = 11
Data
• A TTL value is defined in each datagram (IP packet).
• As each router processes the datagram, it decreases the TTL value by
•
•
one.
When the TTL of the datagram value reaches zero, the packet is
discarded.
ICMP uses a time exceeded message to notify the source device that
the TTL of the datagram has been exceeded.
Rick Graziani [email protected]
18
http://www.switch.ch/docs/ttl_default.html
TTL Overview - Disclaimer:
The following list is a best effort overview of some widely used TCP/IP stacks. The
information was provided by vendors and many helpful system administrators. We would
like to thank all these contributors for their precious help ! SWITCH cannot, however,
take any responsibility that the provided information is correct. Furthermore, SWITCH
cannot be made liable for any damage that may arise by the use of this information.
+--------------------+-------+---------+---------+
| OS Version
|"safe" | tcp_ttl | udp_ttl |
+--------------------+-------+---------+---------+
AIX
n
60
30
DEC Pathworks V5
n
30
30
FreeBSD 2.1R
y
64
64
HP/UX
9.0x
n
30
30
HP/UX
10.01
y
64
64
Irix 5.3
y
60
60
Irix 6.x
y
60
60
Linux
y
64
64
MacOS/MacTCP 2.0.x
y
60
60
OS/2 TCP/IP 3.0
y
64
64
OSF/1 V3.2A
n
60
30
Solaris 2.x
y
255
255
SunOS 4.1.3/4.1.4
y
60
60
Ultrix V4.1/V4.2A
n
60
30
VMS/Multinet
y
64
64
VMS/TCPware
y
60
64
VMS/Wollongong 1.1.1.1
n
128
30
VMS/UCX (latest rel.)
y
128
128
MS WfW
n
32
32
MS Windows 95
n
32
32
MS Windows NT 3.51
n
32
32
MS Windows NT 4.0
y
128
128
Rick Graziani [email protected]
Assigned Numbers (RFC
1700, J. Reynolds, J.
Postel, October 1994):
IP TIME TO LIVE
PARAMETER
The current
recommended default
time to live (TTL)
for the Internet
Protocol (IP) is 64.
Safe: TCP and UDP
initial TTL values
should be set to a
"safe" value of at
least 60 today.
19
IP Parameter Problem
ICMP Parameter Problem
Type = 12
• Devices that process datagrams may not be able to forward a
•
•
datagram due to some type of error in the header.
This error does not relate to the state of the destination host or
network but still prevents the datagram from being processed and
delivered.
An ICMP type 12 parameter problem message is sent to the source of
the datagram.
Rick Graziani [email protected]
20
ICMP Control Messages
Introduction to ICMP Control Messages
•
•
Unlike error messages, control messages are not the
results of lost packets or error conditions which occur
during packet transmission.
Instead, they are used to inform hosts of conditions such
as:
– Network congestion
– Existence of a better gateway to a remote network
Rick Graziani [email protected]
22
ICMP Redirect
3
ICMP Redirect
Type = 5 Code = 0 to 3
2
1
2
4
• ICMP Redirect messages can only be sent by routers
• Host H sends a packet to Host 10.1.1.1 on network 10.0.0.0/8.
• Since Host H is not directly connected to the same network, it forwards
•
•
•
the packet to its default gateway, Router R1 at 172.16.1.100.
Router R1 finds the correct route to network 10.0.0.0/8 by looking in its
route table.
It determines that the path to the network is back out the same
interface the request to forward the packet came from to Router R2 at
172.16.1.200.
R1 forwards the packet to R2 and sends an ICMP redirect/change
request to Host H telling it to use Router R2 at 172.16.1.100 as the
gateway to forward all future requests to network 10.0.0.0/8.
Rick Graziani [email protected]
23
ICMP Redirects
ICMP Redirect
Type = 5 Code = 0 to 3
• Default gateways only send ICMP redirect/change request messages if
the following conditions are met:
– The interface on which the packet comes into the router is the
same interface on which the packet gets routed out.
– The subnet/network of the source IP address is the same
subnet/network of the next-hop IP address of the routed packet.
– The datagram is not source-routed.
– The route for the redirect is not another ICMP redirect or a default
route.
– The router is configured to send redirects. (By default, Cisco
routers send ICMP redirects. The interface subcommand no ip
redirects will disable ICMP redirects.)
Rick Graziani [email protected]
24
Clock synchronization and transit time
estimation
Replaced by
ICMP Timestamp Request
Type = 13 or 14
• The TCP/IP protocol suite allows systems to connect to one another
•
•
•
•
•
over vast distances through multiple networks.
Each of these individual networks provides clock synchronization in its
own way.
As a result, hosts on different networks who are trying to
communicate using software that requires time synchronization
can sometimes encounter problems.
The ICMP timestamp message type is designed to help alleviate this
problem.
The ICMP timestamp request message allows a host to ask for the
current time according to the remote host.
The remote host uses an ICMP timestamp reply message to respond
to the request.
Rick Graziani [email protected]
25
Clock synchronization and transit time
estimation
Replaced by
ICMP Timestamp
Type = 13 or 14
• All ICMP timestamp reply messages contain the originate, receive and
•
•
•
•
•
transmit timestamps.
Using these three timestamps, the host can estimate transit time across
the network by subtracting the originate time from the transit time.
It is only an estimate however, as true transit time can vary widely based
on traffic and congestion on the network.
The host that originated the timestamp request can also estimate the
local time on the remote computer.
While ICMP timestamp messages provide a simple way to estimate time
on a remote host and total network transit time, this is not the best way
to obtain this information.
Instead, more robust protocols such as Network Time Protocol (NTP)
at the upper layers of the TCP/IP protocol stack perform clock
synchronization in a more reliable manner.
Rick Graziani [email protected]
26
Information requests and reply message
formats
ICMP Information Request/Reply
Type = 15 or 16
• The ICMP information requests and reply
•
•
Replaced by
messages were originally intended to
allow a host to determine its network
number.
This particular ICMP message type is
considered obsolete.
Other protocols such as BOOTP and
Dynamic Host Configuration Protocol
(DHCP) are now used to allow hosts to
obtain their network numbers.
Rick Graziani [email protected]
27
Address Masks
ICMP Address Mask Request/Reply
Type = 17 or 18
• This new subnet mask is crucial in
•
•
•
•
•
identifying network, subnet, and host bits in
an IP address.
If a host does not know the subnet mask,
it may send an address mask request to the
local router.
If the address of the router is known, this
request may be sent directly to the router.
Otherwise, the request will be broadcast.
When the router receives the request, it will
respond with an address mask reply.
Somewhat obsolete, was used with
diskless workstations that used RARP for
the IP address and ICMP for the subnet
mask.
Rick Graziani [email protected]
Replaced by
28
Router Solicitation and Advertisement
ICMP Router Solicitation
Type = 10
ICMP Router Advertisement
Type = 9
•
•
•
•
Replaced by
When a host on the network boots, and the host
has not been manually configured with a
default gateway, it can learn of available
routers through the process of router discovery.
This process begins with the host sending a
router solicitation message to all routers,
using the multicast address 224.0.0.2 as the
destination address. (May also be broadcast).
When a router that supports the discovery
process receives the router discovery
message, a router advertisement is sent in
return.
Routers may also periodically advertise router
advertisement messages.
Rick Graziani [email protected]
29
IRDP
•
•
•
•
Some newer IP hosts use ICMP Router Discovery Protocol
(IRDP) (RFC 1256 ) to find a new router when a route
becomes unavailable.
A host that runs IRDP listens for hello multicast messages
from its configured router and uses an alternate router
when it no longer receives those hello messages.
The default timer values of IRDP mean that it's not suitable
for detection of failure of the first hop.
The default advertisement rate is once every 7 to 10
minutes, and the default lifetime is 30 minutes.
Rick Graziani [email protected]
30
ICMP sourcequench messages
ICMP Source Quench
Type = 4
• Congestion can also occur for various reasons including when traffic
•
•
•
•
•
from a high speed LAN reaches a slower WAN connection.
Dropped packets occur when there is too much congestion on a
network.
ICMP source-quench messages are used to reduce the amount of data
lost.
The source-quench message asks senders to reduce the rate at which
they are transmitting packets.
In most cases, congestion will subside after a short period of time, and
the source will slowly increase the transmission rate as long as no
other source-quench messages are received.
Most Cisco routers do not send source-quench messages by
default, because the source-quench message may itself add to the
network congestion. (See TCP)
Rick Graziani [email protected]
31
ICMP sourcequench messages
ICMP Source Quench
Type = 4
• IP has no mechanism for flow control
• Some issues with ICMP Source Quench:
•
– A router or destination host (buffers full) will send one sourcequench message for each discarded packet.
– No mechanism to tell the source that the congestion has been
relieved and source can resume sending at previous rate.
Remember, TCP/IP uses TCP mechanisms for flow control and
reliability including sliding windows.
Rick Graziani [email protected]
32
ICMP Path MTU Discovery
Information from:
Marc Slemko
Path MTU Discovery and Filtering ICMP
http://alive.znep.com/~marcs/mtu/
and
Cisco Systems
Path Maximum Transfer Unit (MTU) Discovery
http://www.cisco.com/en/US/products/sw/iosswrel/ios_abcs_ios_the_abcs_
ip_version_60900aecd800c1126.html
Path MTU
Discovery
Problem:
• How path MTU discovery (PMTU-D) combined with filtering ICMP
messages can result in connectivity problems.
• Path MTU discovery allows a node to dynamically discover and adjust
to differences in the MTU size of every link along a given data path.
• In IPv4, the minimum link MTU size is 68 octets and the recommended
minimum is 576 octets, which is the minimum reassembly buffer size.
• So, any IPv4 packet must be at least 68 octets in length.
• (In IPv6, the minimum link MTU is 1280 octets, but the recommended MTU value for
IPv6 links is 1500 octets. The maximum packet size supported by the basic IPv6 header
is 64,000 octets. Larger packets called jumbograms could be handled using a hop-byhop extension header option.)
Rick Graziani [email protected]
34
Path MTU Discovery - Terms
• MTU: The maximum transmission unit is a link layer restriction on the
•
maximum number of bytes of data in a single transmission (ie. frame,
cell, packet, depending on the terminology).
– The table above shows some typical values for MTUs, taken from
RFC-1191.
Path MTU : The smallest MTU of any link on the current path between
two hosts.
– This may change over time since the route between two hosts,
especially on the Internet, may change over time.
– It is not necessarily symmetric and can even vary for different types
of traffic from the same host.
Rick Graziani [email protected]
35
Terms
•
Fragmentation: When a packet is too large to be sent across a link as a single
unit, a router can fragment the packet.
– This means that it splits it into multiple parts which contain enough
information for the receiver to glue them together again.
– Note that this is not done on a hop-by-hop basis, but once fragmented a
packet will not be put back together until it reaches its destination.
– Fragmentation is undesirable for numerous reasons, including:
• If any one fragment from a packet is dropped, the entire packet needs
to be retransmitted. This is a very significant problem.
• It imposes extra processing load on the routers that have to split the
packets.
• In some configuration, simpler firewalls will block all fragments
because they don't contain the header information for a higher layer
protocol (eg. TCP) needed for filtering.
Rick Graziani [email protected]
36
Terms
3
4
ICMP Destination Unreachable
Fragmentation needed, but DF Set
•
•
DF (Don't Fragment) bit: This is a bit in the IP header that can be set to
indicate that the packet should not be fragmented by routers.
– If the packet needs to be fragmented, an ICMP "can't fragment" error is
returned sent to the sender and the packet is dropped.
ICMP Can't Fragment Error:
– This error is a type 3 (destination unreachable), code 4 (fragmentation
needed but don't-fragment bit set)
– Returned by a router when it receives a packet that is too large for it to
forward and the DF bit is set.
– The packet is dropped and the ICMP error is sent back to the origin host.
– Normally, this tells the origin host that it needs to reduce the size of its
packets if it wants to get through.
– Recent systems also include the MTU of the next hop in the ICMP
message so the source knows how big its packets can be.
– Note that this error is only sent if the DF bit is set; otherwise, packets are
just fragmented and passed through.
Rick Graziani [email protected]
37
Terms
• MSS: The MSS is the maximum segment size.
– It can be announced during the establishment of a TCP
connection to indicate to the other end the largest
amount of data in one packet that should be sent by the
remote system.
– MSS is beyond the scope of this discussion.
Rick Graziani [email protected]
38
Path MTU Discovery (PMTU-D)
•
•
•
Now you know that Path MTUs vary.
You know that fragmentation is bad.
The solution?
– Well, one solution is Path MTU Discovery.
– The idea behind it is to send packets that are as large
as possible while still avoiding fragmentation.
Rick Graziani [email protected]
39
PMTU-D
• A host does this by starting by sending packets that have a maximum
•
•
•
size of the lesser of the local MTU or the MSS announced by the remote
system.
These packets are sent with the DF bit set.
If there is some MTU between the two hosts which is too small to pass
the packet successfully, then an ICMP can't fragment error will be sent
back to the source.
It will then know to lower the size; if the ICMP message includes the next
hop MTU, it can pick the correct size for that link immediately, otherwise
it has to guess.
Rick Graziani [email protected]
40
PMTU-D
http://www.dslreports.com
• The exact process that systems go through is somewhat more
•
•
•
complicated to account for special circumstances. See, RFC 1191.
A good indication of if a system is trying to do PMTU-D is to watch the
packets it is sending with something like tcpdump or snoop and see if
they have the DF bit set; if so, it is most likely trying to do PMTU-D.
Most Windows and Linux/Unix OS’s default to using PMTU-D.
Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun
Systems - http://www.cisco.com/warp/public/105/38.shtml
Rick Graziani [email protected]
41
The problem with ICMP filtering and PMTU-D
• Many network administrators have decided to filter ICMP at a router or
•
•
•
•
•
firewall.
There are valid (and many invalid) reasons for doing this, however it
can cause problems.
ICMP is an integral part of the Internet and can not be filtered without
due consideration for the effects.
In this case, if the ICMP can't fragment errors can not get back to the
source host due to a filter, the host will never know that the packets it is
sending are too large.
This means it will keep trying to send the same large packet, and it will
keep being dropped--silently dropped from the view of any system on
the other side of the filter.
While a small handful of systems that implement PMTU-D also
implement a way to detect such situations, most don't and even for
those that do it has a negative impact on performance and the network.
Rick Graziani [email protected]
42
The Symptoms
• If this is happening, typical symptoms include the ability for
•
small packets (eg. request a very small web page) to get
through, but larger ones (eg. a large web page) will simply
hang.
This situation can be confusing to the novice administrator
because they obviously have some connectivity to the
host, but it just stops working for no obvious reason on
certain transfers.
Rick Graziani [email protected]
43
The Fix
• There is one solution, and several workarounds, for this problem.
• The Fix:
• Fix your filters!
•
– The real problem here is filtering ICMP messages without
understanding the consequences.
– Many packet filters will allow you to setup filters to only allow
certain types of ICMP messages through.
– If you reconfigure them to let ICMP can't fragment (type 3, code 4)
messages through, the problem should disappear.
– If the filter is somewhere between you and the other end, contact
the administrator of that machine and try to convince them to fix the
problem.
We will learn how to do this on Router Access Control Lists (ACLs)
Rick Graziani [email protected]
44
The Workarounds
•
Reduce the MTU on the machines at one end or the other.
– This is a workaround and should not be done unless
necessary.
– If you reduce the MTU on the system trying to do path
MTU discovery to a point where it is less than or equal
to the former path MTU, it will no longer try sending
packets large enough to cause problems.
– Similarly, if you change the MTU on the system on the
other end, it will advertise a lower MSS so the sending
system will only send packets with data that fits into that
MSS.
Rick Graziani [email protected]
45
• Disable PMTU-D; if you control access to the machine that is trying to
do PMTU-D, and are unable to get the person administering the bogus
filter to fix it, disabling PMTU-D will fix the problem for data sent by that
machine.
– Data being received by the machine, however, can still run into the
problem.
– With the size that HTTP requests are growing to, this could start to
be a problem more and more; historically, HTTP requests have
nearly always been small enough to fit through links with small
MTUs in one packet.
– Disabling PMTU-D is simply a workaround, and should not
generally be done unless necessary or you know what you are
doing.
Rick Graziani
[email protected]
46
Recommended Reading
TCP/IP Illustrated, Vol. 1 W.
Richard Stevens Addison-Wesley
Pub Co ISBN: 0201633469
•
Although, published in 1994, written by the
late Richard Stevens, it is still regarded as
the definitive book on TCP/IP.
Rick Graziani [email protected]
Where Wizards Stay Up Late
Katie Hafner and Matthew Lyon
ISBN 0613181530

Very enjoyable reading and you
do not have to be a networking
geek to enjoy it!
 National Bestseller
47
Thanks to Mark Slemko
Rick Graziani [email protected]
48
Ch. 8 TCP/IP Suite Error and
Control Messages (ICMP)
CCNA 1 version 3.0
Rick Graziani
Cabrillo College