Differences

This shows you the differences between two versions of the page.

--- public:how_to_deal_with_fragmentation_of_eap_packets [2022/12/06 10:46] – admin
+++ public:how_to_deal_with_fragmentation_of_eap_packets [2022/12/06 11:02] (current) – [Solutions] admin
@@ Line 34: / Line 34: @@
 The last option is somewhat of a last resort because it's not universally respected by RADIUS servers. However, what it does do is to pass a hint to a RADIUS server to request that the RADIUS server use a maximum of 1100 bytes for the RADIUS packet. This would mean that, with the additional headers provided by the TCP stack that the packets should never be fragmented.
-The caveat is, as stated, that different RADIUS servers react differently to seeing Framed-MTU and all equipment (routers, servers, firewalls) in the path would have to respect it. It certainly can't be relied on as the solution.
+The caveat is, as stated, that different RADIUS servers react differently to seeing Framed-MTU and all servers in the path would have to respect it. It certainly can't be relied on as the solution.
+Cisco ISE has a maximum MTU size of 1002 bytes, this can not be changed and ISE doesn't take any notice of the Framed-MTU attribute.
+Aruba Clearpass has a default maximum MTU size of 1100, which should be fine. The value can be changed. Clearpass will send a Framed-MTU attribute out to authentication servers.
+Microsoft NPS has a default MTU size of 1500, which is too big, and does not respond to the Framed-MTU if it receives it. You can add a Framed-MTU attribute and set its value via the Network Policy that is handling the authentication of your users - and that Framed-MTU will be used by NPS to manage the size of the packets sent back to your remote user. We suggest setting it to 1100.