RE: End System PMTUD behavior question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: End System PMTUD behavior question
- To: Thomas Peterson <thomasp at iol.unh.edu>
- Subject: RE: End System PMTUD behavior question
- From: "Dunn, Jeffrey H." <jdunn at mitre.org>
- Date: Fri, 23 Jan 2009 09:54:41 -0500
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: "ipv6-bounces at ietf.org" <ipv6-bounces at ietf.org>, "Liou, Chern" <csliou at mitre.org>, "ipv6 at ietf.org" <ipv6 at ietf.org>, "Sherman, Kurt T." <ksherman at mitre.org>, "steve_eiserman at uscourts.gov" <steve_eiserman at uscourts.gov>, "Huang, Frank" <fhuang at mitre.org>, "v6ops at ops.ietf.org" <v6ops at ops.ietf.org>, "Grayeli, Parisa" <pgrayeli at mitre.org>
- Delivered-to: ietfarch-ipv6-archive at core3.amsl.com
- Delivered-to: ipv6 at core3.amsl.com
- In-reply-to: <18F8D12C-DAA0-4F30-B405-9F54C15EACB4 at iol.unh.edu>
- List-archive: <http://www.ietf.org/pipermail/ipv6>
- List-help: <mailto:ipv6-request@ietf.org?subject=help>
- List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
- List-post: <mailto:ipv6@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
- References: <3C6F21684E7C954193E6C7C4573B762701D3DD67DA at IMCMBX1.MITRE.ORG> <200901212133.30109.rdenis at simphalempin.com> <3C6F21684E7C954193E6C7C4573B762701D3DD687B at IMCMBX1.MITRE.ORG> <42A4D5E1-C552-434C-90E3-DA3EF4A78688 at iol.unh.edu> <3C6F21684E7C954193E6C7C4573B762701D3DD69D1 at IMCMBX1.MITRE.ORG> <18F8D12C-DAA0-4F30-B405-9F54C15EACB4 at iol.unh.edu>
- Sender: ipv6-bounces at ietf.org
- Thread-index: Acl80VYqdrLkaTMlRAetAiyxL5Cq/wAmQSxw
- Thread-topic: End System PMTUD behavior question
Many thanks for the information. Could you tell me the OS variants on the hosts and router? Also, do you have any tests involving applications? I will send you an off-line e-mail to discuss possible additional testing.
Best Regards,
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)
-----Original Message-----
From: Thomas Peterson [mailto:thomasp at iol.unh.edu]
Sent: Thursday, January 22, 2009 3:38 PM
To: Dunn, Jeffrey H.
Cc: Rémi Denis-Courmont; ipv6 at ietf.org; Huang, Frank; Sherman, Kurt T.; Liou, Chern; steve_eiserman at uscourts.gov; ipv6-bounces at ietf.org; v6ops at ops.ietf.org; Grayeli, Parisa
Subject: Re: End System PMTUD behavior question
Hi Jeffrey,
I have attached a picture which shows one of the topologies we use for
our PMTUD tests.
In this test case we transmit an Echo Request from REF-Host2 to TAR-
Host1 with a packet size of 1500 bytes. REF-Host2 fragments the Echo
Request it transmits. TAR-Host1 replies to this Echo Request with an
Echo Reply to REF-Host2 with a size of 1500 bytes that is not
fragmented. TAR-Router1 sends a Packet Too Big message in response as
this Echo Reply is too large to forward onto Network 2.
In all of the cases we have seen TAR-Host1 does fragment future Echo
Replies to REF-Host2, however, it does not retransmit any Echo Replies
for Echo Requests received prior to receiving the Packet Too Big
message from TAR-Router1.
Additionally from the tests we have performed in our lab if TAR-Host1
were to send an Echo Request with a packet size of 1500 bytes TAR-
Router1 would send a Packet Too Big message in response. In all cases
we have seen TAR-Host1 would not re-transmit this Echo Request and
this would be counted as packet loss in the ping command results.
If this does not ideally match your test scenario we'd be happy to
work together off-line to replicate your scenario.
Thanks,
Tom
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.