<?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: F5 LB and MTU - ISE Roadmap in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513041#M517981</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;To be clear, the end host is responsible for fragmentation reassembly, and in the case of load balancing, the LTM is the end host of the UDP communication from the NADs point of view.&amp;nbsp; Furthermore, F5 MUST reassemble the packets in order to make a load balancing decision based on the complete packet which includes the RADIUS attributes.&amp;nbsp; I show the potential negative result of this in BRKSEC-3699 where only first packet containing RADIUS header is load balanced and remaining use default method which can disperse fragments.&amp;nbsp; Therefore, the LB must not only reassemble packets before sending to ISE PSN, they must also handle min fragment size.&amp;nbsp; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;LTM: tm.minipfragsize&amp;nbsp; &lt;/P&gt;&lt;P&gt;Pre-11.6: Default = 576 bytes&lt;/P&gt;&lt;P&gt;11.6.0+:&amp;nbsp; Default = 566 bytes&lt;/P&gt;&lt;P&gt;# tmsh modify sys db tm.minipfragsize value 1&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 09 Feb 2018 13:57:00 GMT</pubDate>
    <dc:creator>Craig Hyps</dc:creator>
    <dc:date>2018-02-09T13:57:00Z</dc:date>
    <item>
      <title>F5 LB and MTU - ISE Roadmap</title>
      <link>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513037#M517977</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;SPAN style="color: #000000; font-family: Calibri, sans-serif;"&gt;&lt;SPAN style="font-size: 14.666666984558105px;"&gt;Using&lt;/SPAN&gt;&lt;SPAN style="font-size: 11pt;"&gt; F5 load balancers.&amp;nbsp; Running into the issue with fragmented packets.&amp;nbsp; Changing the MTU size to 64.&amp;nbsp; &lt;/SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P style="font-size: 12pt; font-family: Calibri, sans-serif; color: #000000;"&gt;&lt;SPAN style="font-size: 11pt;"&gt;Adjusting the F5 Min Fragment size to 64 to accommodate the ISE fragmented packets on the F5.&amp;nbsp; That said… Engineering is nervous future software on switches or routers could change the size of fragmenting packets in the future and break this fix.&amp;nbsp; &lt;/SPAN&gt;&lt;/P&gt;&lt;P style="font-size: 12pt; font-family: Calibri, sans-serif; color: #000000;"&gt;&lt;SPAN style="font-size: 11pt;"&gt; &lt;/SPAN&gt;&lt;/P&gt;&lt;OL start="1" style="color: #000000; font-family: -webkit-standard;"&gt;&lt;LI&gt;&lt;SPAN style="font-size: 11pt;"&gt; Are there any plans/roadmap to have ISE use TCP?&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN style="font-size: 11pt;"&gt;Are there any plans/roadmap to have support for switches adjusting their MTU on a VLAN the source of ISE Packets might originate from(not currently supported)&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN style="font-size: 11pt;"&gt;Are there any plans/roadmap to have ISE packets source from a Loopback that you could adjust the MTU on(not currently supported)?&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN style="font-size: 11pt;"&gt;Any other possible solutions for ISE/Switches on a roadmap that would help resolve the issue of double fragmentation with overlay networks.&lt;/SPAN&gt;&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;Any help would be greatly appreciated.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Feb 2018 02:41:55 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513037#M517977</guid>
      <dc:creator>brewagne</dc:creator>
      <dc:date>2018-02-08T02:41:55Z</dc:date>
    </item>
    <item>
      <title>Re: F5 LB and MTU - ISE Roadmap</title>
      <link>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513038#M517978</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I have done this fix on probably 3-4 customers and haven't seen any issues.&amp;nbsp; This is a known issue with the F5s.&amp;nbsp; I honestly look at this as an F5 issue.&amp;nbsp; The UDP fragments are legal size packets that the F5 should handle.&amp;nbsp; &lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Feb 2018 06:00:43 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513038#M517978</guid>
      <dc:creator>paul</dc:creator>
      <dc:date>2018-02-08T06:00:43Z</dc:date>
    </item>
    <item>
      <title>Re: F5 LB and MTU - ISE Roadmap</title>
      <link>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513039#M517979</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I cover LB fragmentation in BRKSEC-3699 posted to CiscoLive.com: &lt;A href="https://www.ciscolive.com/global/on-demand-library/?search=BRKSEC-3699&amp;amp;search.event=ciscoliveus2017#/session/1485902284477001yyRN" title="https://www.ciscolive.com/global/on-demand-library/?search=BRKSEC-3699&amp;amp;search.event=ciscoliveus2017#/session/1485902284477001yyRN"&gt;On-Demand Library - Cisco Live Global Events&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Note that ISE is NOT the reason the packets are getting fragmented to these lower sizes, but some intermediate device in packet path.&amp;nbsp; Address the source of the fragmentation and you can revert the lower fragment size on LB.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;No current plans to implement loopback or DSR (Direct Server Return) in ISE.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As Paul noted, this is not an ISE problem, and not really an F5 problem, but an issue with intermediate device that is fragmenting to very low value.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Feb 2018 15:22:27 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513039#M517979</guid>
      <dc:creator>Craig Hyps</dc:creator>
      <dc:date>2018-02-08T15:22:27Z</dc:date>
    </item>
    <item>
      <title>Re: F5 LB and MTU - ISE Roadmap</title>
      <link>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513040#M517980</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Craig,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I look at it as an F5 issue because the network is doing normal fragmentation and putting out valid fragments, but the F5 can’t handle the small fragments unless you modify the settings.  They are still valid packets on the network.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The reason they network is fragmenting is an overlay.  PEAP is no problem but EAP-TLS can cause maximum size packets.  When DMVPN headers is added on top of that you exceed maximum packet size and the router fragments the packets into a max size UDP packet and put the remaining data into a small but still legal packet.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Paul Haferman&lt;/P&gt;&lt;P&gt;Office- 920.996.3011&lt;/P&gt;&lt;P&gt;Cell- 920.284.9250&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Feb 2018 16:44:44 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513040#M517980</guid>
      <dc:creator>paul</dc:creator>
      <dc:date>2018-02-08T16:44:44Z</dc:date>
    </item>
    <item>
      <title>Re: F5 LB and MTU - ISE Roadmap</title>
      <link>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513041#M517981</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;To be clear, the end host is responsible for fragmentation reassembly, and in the case of load balancing, the LTM is the end host of the UDP communication from the NADs point of view.&amp;nbsp; Furthermore, F5 MUST reassemble the packets in order to make a load balancing decision based on the complete packet which includes the RADIUS attributes.&amp;nbsp; I show the potential negative result of this in BRKSEC-3699 where only first packet containing RADIUS header is load balanced and remaining use default method which can disperse fragments.&amp;nbsp; Therefore, the LB must not only reassemble packets before sending to ISE PSN, they must also handle min fragment size.&amp;nbsp; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;LTM: tm.minipfragsize&amp;nbsp; &lt;/P&gt;&lt;P&gt;Pre-11.6: Default = 576 bytes&lt;/P&gt;&lt;P&gt;11.6.0+:&amp;nbsp; Default = 566 bytes&lt;/P&gt;&lt;P&gt;# tmsh modify sys db tm.minipfragsize value 1&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 09 Feb 2018 13:57:00 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/f5-lb-and-mtu-ise-roadmap/m-p/3513041#M517981</guid>
      <dc:creator>Craig Hyps</dc:creator>
      <dc:date>2018-02-09T13:57:00Z</dc:date>
    </item>
  </channel>
</rss>

