RADIUS Fragmentation and MTU

Objective

In this lesson you will learn how to identify and remediate RADIUS fragmentation problems caused by large EAP-TLS certificates, and how to configure MTU and jumbo-frame settings so the wireless controller sends RADIUS packets without losing fragments. This matters in production networks because failing to deliver a client certificate or EAP payload due to fragmentation will cause 802.1X / EAP-TLS authentication to fail, creating client disconnects and large help-desk impact. Real-world scenario: a campus using 802.1X with certificate-based authentication where client certs are 2–8 KB; without MTU/fragment control the WLC fragments packets and the RADIUS server never receives all fragments, causing client timeout and authentication failure.

Quick Recap

This lab continues from Lesson 1 topology. No new devices are added for this lesson — we will exercise the existing Wireless LAN Controller (WLC) SVI and the ISE/RADIUS server.

Device Table

Device	Role	Relevant IP / Interface
WLC (c9800)	Authenticator / RADIUS source	interface Vlan289 — 192.168.189.31
ISE / RADIUS	Authentication server	192.168.189.28

Topology (ASCII) — exact IPs shown on every interface

[WLC (SVI)]                      [ISE / RADIUS]
Device: c9800_40_new_1            Device: ISE_Server
Interface: Vlan289                Interface: eth0
IP: 192.168.189.31/24 ----------- 192.168.189.28/24

Key Concepts (theory + practical)

• MTU and Fragmentation — The MTU is the largest Layer 3 payload the interface will pass without fragmentation. Standard Ethernet MTU is 1500 bytes; if an EAP-TLS certificate (2–8 KB) is larger than the MTU, the packet will be fragmented. If any fragment is lost or not reassembled by the next-hop device, authentication fails.
  • Practical: On the WLC, RADIUS frames carrying EAP-TLS can exceed 1500 bytes, so you must ensure the path supports larger frames or configure the controller to adjust fragment size appropriately.
• Jumbo Frames for RADIUS — When the WLC SVI MTU/IP MTU is increased (example 9100/9000), the WLC will send RADIUS frames as jumbo frames and avoid intra-host fragmentation.
  • Practical: Use jumbo MTU only where the network path supports it (switches, physical links) because jumbo frames are only supported for RADIUS frames on the WLC in this code family.
• RADIUS Fragment Behavior — EAP inside RADIUS often requires multiple RADIUS Access-Challenge / Access-Request exchanges (phase 1/2/3/4). Large client certificates are split; typically the first fragment for the certificate payload will be near 1480 bytes of data (1480B data + 20B IP + 14B Ethernet = 1514B frame). Subsequent smaller Access-Request messages (example 538B data + headers = 572B total) may follow. If any fragment never arrives at the RADIUS server, the session will time out.
  • Practical: Viewing packet sizes in captures or studying controller logs helps identify which fragment is missing.
• Authentication Workflow (EAP-TLS) — The WLC acts as the RADIUS client and proxy for EAP between supplicant and ISE. If the WLC cannot send/receive the full EAP payload to/from the RADIUS server due to MTU/fragment issues, the EAP exchange stalls and switches to authentication failure or client deletion.
  • Practical: Fixes can be either increasing MTU (jumbo frames) or adjusting the fragment size that the RADIUS client uses (if available).

Tip: Think of MTU like the width of a tunnel: if your shipment (certificate) is wider than the tunnel, you must either break it into smaller loads (fragment) or widen the tunnel (jumbo frames). In production, widening the tunnel is preferred for RADIUS if the entire path supports it.

---

Step-by-step configuration

Step 1: Configure the RADIUS server object on the controller

What we are doing: Create the RADIUS server definition that the WLC will use to reach the ISE server. This tells the WLC where to send Access-Request / Access-Challenge packets and what shared secret to use. This matters because if the RADIUS server is misconfigured the controller cannot communicate with ISE and 802.1X will fail.

configure terminal
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123
exit
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
exit
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group
exit

What just happened:

• radius server J_ISE created a RADIUS server object named J_ISE and set the ISE IP and ports.
• key Lab@123 sets the RADIUS shared secret (Lab@123 per lab standard). The WLC will use this secret to authenticate RADIUS packets with ISE.
• aaa group server radius groups the RADIUS server object so authentication methods can reference a group.
• aaa authentication dot1x maps the dot1x authentication method name to the RADIUS server group the WLAN will later reference.

Real-world note: In production, management platforms sometimes auto-populate the source interface for server groups — verify what source IP your WLC uses for RADIUS to avoid asymmetric routing.

Verify:

show running-config | section radius
!
radius server J_ISE
 address ipv4 192.168.189.28 auth-port 1812 acct-port 1813
 key Lab@123
!
aaa group server radius Cisco_Live_Radius_Group
 server name J_ISE
!
aaa authentication dot1x Cisco_Live_AuthC group Cisco_Live_Radius_Group
!

---

Step 2: Configure the WLAN to use 802.1X and map the authentication list

What we are doing: Ensure the WLAN is configured to use 802.1X and points to the authentication list we created. This connects the SSID to the AAA configuration so the controller knows to send EAP traffic to the RADIUS group.

configure terminal
wlan Cisco_Live_Dot1x
 radio policy dot11 24ghz
 radio policy dot11 5ghz
 security dot1x authentication-list Cisco_Live_AuthC
exit

What just happened:

• The wlan configuration created/edited the SSID named Cisco_Live_Dot1x and set the radio policies (2.4/5 GHz).
• security dot1x authentication-list Cisco_Live_AuthC instructs the WLAN to use the previously created AAA authentication method list so EAP frames will be proxied to the RADIUS group.

Real-world note: Mapping the WLAN to the correct authentication list is a common source of error — if the WLAN uses a different auth list, RADIUS traffic might never be triggered.

Verify:

show running-config | section wlan
wlan Cisco_Live_Dot1x
 radio policy dot11 24ghz
 radio policy dot11 5ghz
 security dot1x authentication-list Cisco_Live_AuthC

---

Step 3: Configure the SVI MTU and IP MTU to enable jumbo frames for RADIUS

What we are doing: Increase the SVI MTU and the IP MTU on the WLC so the controller can send jumbo RADIUS frames instead of fragmenting. This directly addresses the problem where EAP-TLS certificates create packets larger than the standard MTU.

configure terminal
interface Vlan289
 mtu 9100
 ip address 192.168.189.31 255.255.255.0
 no ip proxy-arp
 ip mtu 9000
exit
end

What just happened:

• interface Vlan289 entered the SVI configuration.
• mtu 9100 increased the Layer 2 MTU of the SVI to 9100 bytes — this config allows jumbo frames on that SVI.
• ip mtu 9000 sets the IP-level MTU to 9000 bytes (must be equal or smaller than the interface MTU).
• With these settings the controller can now send RADIUS packets up to 9000 bytes without fragmentation. This eliminates the need for the controller to split large EAP-TLS payloads into 1500-byte fragments, assuming the network path supports these jumbo frames.

Real-world note: Before enabling jumbo frames, make sure switches and physical links between WLC and RADIUS support jumbo MTU; otherwise you may create black holes where jumbo frames are dropped.

Verify:

show running-config interface Vlan289
Current configuration : 106 bytes
!
interface Vlan289
 mtu 9100
 ip address 192.168.189.31 255.255.255.0
 no ip proxy-arp
 ip mtu 9000
end
!

show interface Vlan289
Vlan289 is up, line protocol is down , Autostate Enabled
Hardware is Ethernet SVI, address is ffff.ffff.fff (bia ffff.ffff.ffff )
Internet address is 192.168.189.31/24
MTU 9100 bytes , BW 1000000 Kbit/sec, DLY 10 usec

---

Step 4: Observe the fragmentation behavior and confirm jumbo frames remove fragmentation

What we are doing: Explain and validate how the EAP-TLS payload fragments before the change and how jumbo frames remove that fragmentation. This step ties the configuration to protocol behavior so you can interpret packet captures or controller logs.

! (No new config — verification and analysis only)

What just happened:

• Before the MTU increase, large client certificate payloads were broken into fragments by the WLC. Example fragment sizes observed in controller captures and PCAP analysis:
  • Client Certificate 1st fragment: 1480 bytes of data + 20 bytes IPv4 + 14 bytes Ethernet header = 1514 bytes (exceeds standard Ethernet payload, requires fragmentation).
  • Access-Request for session exchange: 538 bytes of data + 20B IPv4 + 14B Ethernet = 572 bytes total.
• After configuring mtu 9100 and ip mtu 9000, the WLC can send the entire certificate-bearing RADIUS packet in a single jumbo frame (no fragmentation required) — this resolves missing-fragment problems seen when the RADIUS server never received the full EAP payload.

Real-world note: In packet captures you’ll see that with standard MTU the certificate portion is split across several RADIUS packets or Ethernet frames; after jumbo MTU it appears as a single larger RADIUS packet.

Verify: (Use the previously shown outputs to confirm MTU; then in a live environment you would confirm via packet capture or logs)

show interface Vlan289
Vlan289 is up, line protocol is down , Autostate Enabled
Hardware is Ethernet SVI, address is ffff.ffff.fff (bia ffff.ffff.ffff )
Internet address is 192.168.189.31/24
MTU 9100 bytes , BW 1000000 Kbit/sec, DLY 10 usec

Expected behavioral verification (explain what to look for in captures/logs):

• Before fix: controller logs or PCAP show EAP fragments and occasional client delete reason messages such as AAA server unavailable or EAP timeout because a fragment did not arrive/reassemble.
• After fix: RADIUS exchange completes without fragment-related timeouts; EAP-TLS completes (Access-Accept) and client is authenticated.

---

Verification Checklist

• Check 1: RADIUS server object present — verify with show running-config | section radius and confirm 192.168.189.28 is configured as the auth/acct server.
• Check 2: WLAN mapped to 802.1X method — verify with show running-config | section wlan to confirm security dot1x authentication-list Cisco_Live_AuthC.
• Check 3: SVI MTU and IP MTU updated — verify with show running-config interface Vlan289 and show interface Vlan289 to confirm MTU 9100 and ip mtu 9000.
• Check 4: Packet capture or WLC logs show no RADIUS fragment loss — observe that certificate payloads are sent as single large frames (no missing fragments) and the RADIUS server receives the full EAP payload leading to successful EAP-TLS completion.

Common Mistakes

Symptom	Cause	Fix
Clients fail 802.1X with timeouts or immediate delete	WLC fragments large EAP-TLS packets and one or more fragments are dropped or never reassembled by RADIUS	Increase SVI MTU and IP MTU on the controller (example mtu 9100 / ip mtu 9000) or ensure fragment control is configured in supported code.
RADIUS secret mismatch / no RADIUS responses	Wrong shared secret in RADIUS server object	Reconfigure the key on the radius server to match the server (use Lab@123 in lab).
WLAN not sending EAP to RADIUS	WLAN not mapped to correct auth list	Verify security dot1x authentication-list Cisco_Live_AuthC under the appropriate wlan stanza.
Jumbo MTU configured on WLC but packets are dropped on path	Intermediate switches or physical links do not support jumbo frames	Ensure switches and trunk ports between WLC and RADIUS path are configured for jumbo MTU; otherwise use fragment control or adjust network path.
Misaligned source IP for RADIUS	WLC uses a different source interface than expected; return path to RADIUS is asymmetric	Verify which source IP the WLC uses for RADIUS and ensure routing/backbone accepts that IP; update server-group/source-interface if needed.

Key Takeaways

• MTU matters for 802.1X EAP-TLS: large certificate payloads frequently exceed 1500 bytes and will be fragmented. If fragments are lost, authentication fails.
• Jumbo frames (SVI MTU / IP MTU) on the WLC eliminate fragmentation for RADIUS traffic when the underlying network supports them (example configuration: mtu 9100 and ip mtu 9000 on the SVI).
• Always verify both configuration and path support: configure the controller, but also confirm switches and links in the path accept jumbo frames — otherwise you have simply moved the problem.
• When troubleshooting, correlate controller logs and PCAPs: look for fragment sizes (1480B fragment examples) and for client deletion reasons such as AAA server unavailable or EAP timeout; increasing MTU frequently resolves missing-fragment symptoms.

Final practical note: This feature was introduced in the WLC code referenced here and is intended specifically to improve RADIUS/EAP behavior for large certificate sizes. In production, test changes in a maintenance window and verify end-to-end with packet captures to ensure no intermediate device drops jumbo frames.