<?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 Re: ISE silently dropping packet in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3803293#M485221</link>
    <description>&lt;P&gt;Adding to what said&amp;nbsp;&lt;A href="https://community.cisco.com/t5/user/viewprofilepage/user-id/320219" target="_blank"&gt;Damien Miller&lt;/A&gt; and &lt;A href="https://community.cisco.com/t5/user/viewprofilepage/user-id/192011" target="_blank"&gt;paul&lt;/A&gt;,&lt;/P&gt;
&lt;P&gt;I believe ISE will drop the 2nd packets if DF bit set.&lt;/P&gt;</description>
    <pubDate>Sat, 16 Feb 2019 17:35:21 GMT</pubDate>
    <dc:creator>hslai</dc:creator>
    <dc:date>2019-02-16T17:35:21Z</dc:date>
    <item>
      <title>ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800053#M485215</link>
      <description>&lt;P&gt;ISE 2.3 patch 5&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;I'm hitting this weird issue with ISE trying to get EAP-TLS with machine authentication working.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;During the initial eap-tls flow, ISE receives the client hello access-request packet from the NAD, then responds with the access-challenge that contains the server hello/certificate/server key exchange/etc. This is over 5 eap-tls fragments (5 IP packets). The NAD acknowledges these with access-requests without issue. Next the NAD sends an access-request with its certificate/client key exchange/change cipher spec/etc. At a radius level the access-request looks to be fragmented over multiple packets,&amp;nbsp;but the first fragment is fragmented at IP level as well with 1518 bytes on wire and another 419 bytes on the wire - this makes up the first access-request. Packet capture on the upstream device from ISE shows it forwarding both these packets, however packet capture on the ISE shows only the first Fragmented&amp;nbsp;IP protocol packet. The remaining 419 byte packet needed to reassemble&amp;nbsp;to get the&amp;nbsp;access-request is not seen in the capture. Looks like the ISE is silently dropping this? Hence eap-tls times out and fails.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The first fragment of the access-request is more than 1500 bytes, is this the issue? It funny that&amp;nbsp;the larger fragmented packet is received but the following 419 byte one is not.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The data portion (radius stuff) of the first fragment is 1480 bytes. Now when you add the IP and ethernet headers it will be at least 1514 bytes. Not sure why the NAD will send it this big when the MTU on the interface and globally is set to 1500 bytes.&lt;/P&gt;</description>
      <pubDate>Tue, 12 Feb 2019 13:25:06 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800053#M485215</guid>
      <dc:creator>Madura Malwatte</dc:creator>
      <dc:date>2019-02-12T13:25:06Z</dc:date>
    </item>
    <item>
      <title>Re: ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800058#M485216</link>
      <description>&lt;P&gt;Are the PSNs behind an F5 load balancer?&amp;nbsp; If so this is a known issue with the F5s.&amp;nbsp; The F5s will drop packet fragments if they are too small.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 12 Feb 2019 13:28:07 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800058#M485216</guid>
      <dc:creator>paul</dc:creator>
      <dc:date>2019-02-12T13:28:07Z</dc:date>
    </item>
    <item>
      <title>Re: ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800075#M485217</link>
      <description>&lt;P&gt;No they are not. I took a capture right in front of the PSN's on ACI EPG where the PSN VM's reside. And that capture shows both fragmented packets being&amp;nbsp;forwarded, but PSN never gets the 2nd fragment.&lt;/P&gt;</description>
      <pubDate>Tue, 12 Feb 2019 13:39:48 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800075#M485217</guid>
      <dc:creator>Madura Malwatte</dc:creator>
      <dc:date>2019-02-12T13:39:48Z</dc:date>
    </item>
    <item>
      <title>Re: ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800273#M485218</link>
      <description>Your packet capture appears standard, you have a 1500 byte packet encapsulated with 14 bytes of header and a 4 byte CRC.  The 1518 (or 1514 without CRC captured) bytes is the frame you expect to see in a capture if you are adhering to traditional ethernet and not adding vlan, trustsec, or macsec information.  This is not an issue.  &lt;BR /&gt;&lt;BR /&gt;I have not run 2.3 myself, but I know with 2.1, 2.2 and 2.4 that we received eap-tls fragments, I do not recall having the issue you are facing. Relevant reading material for fragmented eap with packet capture examples, give it a read and see if anything helps.  &lt;BR /&gt;&lt;A href="https://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/118634-technote-eap-00.html" target="_blank"&gt;https://www.cisco.com/c/en/us/support/docs/lan-switching/8021x/118634-technote-eap-00.html&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 12 Feb 2019 16:52:27 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800273#M485218</guid>
      <dc:creator>Damien Miller</dc:creator>
      <dc:date>2019-02-12T16:52:27Z</dc:date>
    </item>
    <item>
      <title>Re: ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800311#M485220</link>
      <description>Usually I see fragmentation when EAP-TLS packets are traversing DMVPN/GRE encapsulated  links.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Tue, 12 Feb 2019 17:38:57 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3800311#M485220</guid>
      <dc:creator>paul</dc:creator>
      <dc:date>2019-02-12T17:38:57Z</dc:date>
    </item>
    <item>
      <title>Re: ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3803293#M485221</link>
      <description>&lt;P&gt;Adding to what said&amp;nbsp;&lt;A href="https://community.cisco.com/t5/user/viewprofilepage/user-id/320219" target="_blank"&gt;Damien Miller&lt;/A&gt; and &lt;A href="https://community.cisco.com/t5/user/viewprofilepage/user-id/192011" target="_blank"&gt;paul&lt;/A&gt;,&lt;/P&gt;
&lt;P&gt;I believe ISE will drop the 2nd packets if DF bit set.&lt;/P&gt;</description>
      <pubDate>Sat, 16 Feb 2019 17:35:21 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/3803293#M485221</guid>
      <dc:creator>hslai</dc:creator>
      <dc:date>2019-02-16T17:35:21Z</dc:date>
    </item>
    <item>
      <title>Re: ISE silently dropping packet</title>
      <link>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/4528957#M572111</link>
      <description>&lt;P&gt;Hi, and sorry for asking this, but did you configure "IP MTU" on the SVI that is used as source-interface for RADIUS?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I had the same issue and this was fixed in 5 minutes with this command.&lt;/P&gt;</description>
      <pubDate>Mon, 10 Jan 2022 16:46:01 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/ise-silently-dropping-packet/m-p/4528957#M572111</guid>
      <dc:creator>mile.ljepojevic</dc:creator>
      <dc:date>2022-01-10T16:46:01Z</dc:date>
    </item>
  </channel>
</rss>

