<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Packets gets dropped, dont defragmnet bit ?? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/packets-gets-dropped-dont-defragmnet-bit/m-p/2916018#M933962</link>
    <description>It looks like on one of the HPUX machine, all the datagrams are coming across with the DF(don't fragment bit) set. So when a large ping comes across from that system it has the DF MF bits set, this is invalid and the packet is dropped from the mainframe side. &lt;BR /&gt;&lt;BR /&gt;Is there any parameter which can change this behaviour ?</description>
    <pubDate>Fri, 28 Feb 2003 17:26:54 GMT</pubDate>
    <dc:creator>Q4you</dc:creator>
    <dc:date>2003-02-28T17:26:54Z</dc:date>
    <item>
      <title>Packets gets dropped, dont defragmnet bit ??</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/packets-gets-dropped-dont-defragmnet-bit/m-p/2916018#M933962</link>
      <description>It looks like on one of the HPUX machine, all the datagrams are coming across with the DF(don't fragment bit) set. So when a large ping comes across from that system it has the DF MF bits set, this is invalid and the packet is dropped from the mainframe side. &lt;BR /&gt;&lt;BR /&gt;Is there any parameter which can change this behaviour ?</description>
      <pubDate>Fri, 28 Feb 2003 17:26:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/packets-gets-dropped-dont-defragmnet-bit/m-p/2916018#M933962</guid>
      <dc:creator>Q4you</dc:creator>
      <dc:date>2003-02-28T17:26:54Z</dc:date>
    </item>
    <item>
      <title>Re: Packets gets dropped, dont defragmnet bit ??</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/packets-gets-dropped-dont-defragmnet-bit/m-p/2916019#M933963</link>
      <description>Sounds like you may need to alter the ip_pmtu_strategy on your server.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&amp;gt; ndd -h ip_pmtu_strategy&lt;BR /&gt;&lt;BR /&gt;ip_pmtu_strategy:&lt;BR /&gt;&lt;BR /&gt;    Set the Path MTU Discovery strategy: 0 disables Path MTU Discovery; 1 enables Strategy 1; 2 enables Strategy 2.&lt;BR /&gt;&lt;BR /&gt;    Because of problems encountered with some firewalls, hosts, and low-end routers, IP provides for selection of either of two discovery strategies, or for completely disabling the algorithm. The tunable parameter ip_pmtu_strategy controls the selection.&lt;BR /&gt;&lt;BR /&gt;    Strategy 1: All outbound datagrams have the "Don't Fragment" bit set. This should result in notification from any intervening gateway that needs to forward a datagram down a path that would require additional fragmentation. When the ICMP "Fragmentation Needed" message is received, IP updates its MTU for the remote&lt;BR /&gt; host. If the responding gateway implements the recommendations for gateways in RFC??1191, then the next hop MTU will be included in the "Fragmentation Needed" message, and IP will use it.&lt;BR /&gt;    If the gateway does not provide next hop information, then IP will reduce the MTU to the next lower value taken from a table of "popular" media MTUs.&lt;BR /&gt;&lt;BR /&gt;    Strategy 2: When a new routing table entry is created for a destination on a locally connected subnet, the "Don't Fragment" bit is never turned on. When a new routing table entry for a&lt;BR /&gt;    non-local destination is created, the "Don't Fragment" bit is not immediately turned on. Instead,&lt;BR /&gt;&lt;BR /&gt;    o  An ICMP "Echo Request" of full MTU size is generated and sent out with the "Don't Fragment" bit on.&lt;BR /&gt;&lt;BR /&gt;    o  The datagram that initiated creation of the routing table entry is sent out immediately, without the "Don't Fragment" bit. Traffic is not held up waiting for a response to the&lt;BR /&gt; "Echo Request".&lt;BR /&gt;&lt;BR /&gt;    o  If no response to the "Echo Request" is received, the "Don't Fragment" bit is never turned on for that route;&lt;BR /&gt;       IP won't time-out or retry the ping. If an ICMP "Fragmentation Needed" message is received in response to the "Echo Request", the Path MTU is reduced accordingly, and a new "Echo Request" is sent out using the updated Path MTU. This step repeats as needed.&lt;BR /&gt;&lt;BR /&gt;    o  If a response to the "Echo Request" is received, the "Don't Fragment" bit is turned on for all further packets for the destination, and Path MTU discovery proceeds as for Strategy 1.&lt;BR /&gt;&lt;BR /&gt;    Assuming that all routers properly implement Path MTU Discovery,Strategy 1 is generally better - there is no extra overhead for the&lt;BR /&gt;    ICMP "Echo Request" and response. Strategy 2 is available only because some routers, or firewalls, or end hosts have been observed simply to drop packets that have the DF bit on without&lt;BR /&gt;issuing the "Fragmentation Needed" message. Strategy 2 is more conservative in that IP will never fail to communicate when using it. [0,2] Default: Strategy 2</description>
      <pubDate>Sat, 01 Mar 2003 03:05:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/packets-gets-dropped-dont-defragmnet-bit/m-p/2916019#M933963</guid>
      <dc:creator>James A. Donovan</dc:creator>
      <dc:date>2003-03-01T03:05:35Z</dc:date>
    </item>
  </channel>
</rss>

