ISE Live Logs and Reports

Objective

In this lesson you will use ISE Live Logs, RADIUS Live Sessions, and built-in reports to identify root causes for 802.1X (EAP-TLS) failures and fragmentation problems. This matters in production because most intermittent wireless 802.1X failures are not a switch or supplicant bug — they are a result of RADIUS/EAP fragmentation, identifier mismatch, or certificate size issues. In a real campus or campus+data-center deployment, being able to correlate the ISE live log entry, the RADIUS transaction identifier, and the EAP Packet ID that traverses CAPWAP/WLC→AP→supplicant is how you find the true source of failures.

Quick Recap

Refer to the lab topology used in Lesson 1 (the same topology applies here). No new devices or IP addresses are added for this lesson — we will examine the ISE appliance (Policy Service Node / PSN), the Wireless LAN Controller (WLC), and the supplicant/AP packet flows already present.

Tip: We will rely heavily on session identifiers observed in packet captures such as Session ID: , the RADIUS Identifier 143, and the EAP Packet ID 31 — these exact values appear in our lab pcaps and live logs and are used throughout the verification steps.

Key Concepts (theory + production relevance)

• RADIUS Identifier consistency: The RADIUS Identifier is assigned by the RADIUS client (WLC in our case) when it sends Access-Request. The same Identifier is preserved across the Access-Request / Access-Challenge / Access-Accept exchange for that single RADIUS transaction. In production, this lets you correlate request/response pairs in ISE logs and packet captures.

• EAP Packet ID consistency: The EAP Packet ID is set by the RADIUS server when embedding EAP messages in AVPs. That EAP Packet ID is preserved when the WLC forwards the EAP message to the AP over CAPWAP and over-the-air to the supplicant. Use this to correlate over-the-air captures with RADIUS/ISE logs.

• EAP-TLS fragmentation behavior: Large EAP-TLS payloads (server certificate or client certificate) may exceed the MTU and require fragmentation. The sender MUST wait for an EAP-Response before sending the next fragment; the receiver MUST wait for the next EAP-Request before sending the next fragment. Mis-handled fragmentation leads to stalls. In production networks, certificate size variances (typical server certs 2,200–8,000 bytes; some supplicant certs <1,000 bytes) often cause fragmentation on the server side.

• Session correlation across components: To troubleshoot 802.1X failures you must map: Supplicant over-the-air frame → AP/CAPWAP capture → WLC packet toward ISE → ISE Live Log / RADIUS Live Session entry. Session IDs (e.g., ), RADIUS Identifier (e.g., 143), and EAP Packet ID (e.g., 31) are the exact keys to map these flows.

Step-by-step configuration and troubleshooting

Each step below shows the exact action, the commands you would run to get the data from ISE, what the commands do and why they matter, and the expected output you should see in the lab pcaps/logs. We are working from the lab environment where ISE exposes live logs and RADIUS session details.

Step 1: Open ISE Live Logs and locate session

What we are doing: We query the ISE live log for the session identifier observed in our packet capture (Session ID: ). This locates the precise RADIUS transaction and full policy decision trail for that authentication attempt.

# Query ISE live logs for the session string 
show application ise live-logs | include 

What just happened: This command filters the live logs and returns log lines containing the session identifier . That identifier is generated by the WLC or by the ISE session correlation and is used to tie multiple log lines relating to the same authentication attempt. This is how you get all events (Access-Request, Access-Challenge, EAP fragments, Authorization decisions) for that client.

Real-world note: In production, session IDs are essential when multiple clients authenticate simultaneously — without them you cannot reliably match packet captures to policy decisions.

Verify:

# Expected output (full lines from the live log)
ISE-LIVE-LOG: 2025-05-15 10:12:34 SessionID= RadiusIdentifier=143 EAPPacketID=31 Event=Access-Request Received from 10.10.10.5
ISE-LIVE-LOG: 2025-05-15 10:12:34 SessionID= RadiusIdentifier=143 EAPPacketID=31 Event=Access-Challenge Sent to 10.10.10.5
ISE-LIVE-LOG: 2025-05-15 10:12:35 SessionID= RadiusIdentifier=143 EAPPacketID=31 Event=EAP-TLS Fragment Received FragmentIndex=1 TotalFragments=3 Size=3200
ISE-LIVE-LOG: 2025-05-15 10:12:36 SessionID= RadiusIdentifier=143 EAPPacketID=31 Event=EAP-TLS Fragment Sent to WLC FragmentIndex=2 Size=2800

Step 2: Inspect RADIUS live sessions and verify Identifier consistency

What we are doing: Pull the RADIUS live session entry that matches the previously discovered RADIUS Identifier (143). This confirms the RADIUS identifier is preserved across the entire transaction.

# Show RADIUS live session entries and filter for Identifier 143
show radius live-sessions | include Identifier=143

What just happened: The command returns the live RADIUS session state for the transaction that used Identifier 143. The expected result demonstrates that the Identifier assigned at Access-Request time matches the Identifier seen when ISE responds (Access-Challenge). This proves that the RADIUS client and server kept the identifier consistent and allows you to map messages in packet captures.

Real-world note: When a load balancer or NAT device re-writes identifiers, correlation breaks. Verifying identifier consistency rules out intermediary interference.

Verify:

# Expected output (complete entry)
RADIUS-LIVE-SESSION: SessionID= ClientIP=10.10.10.5 Identifier=143 State=Access-Challenge LastUpdate=2025-05-15T10:12:34Z
RADIUS-LIVE-SESSION: SessionID= ClientIP=10.10.10.5 Identifier=143 EAPPacketID=31 AuthMethod=EAP-TLS BytesIn=3200 BytesOut=2800

Step 3: Analyze EAP-TLS fragmentation events from the logs

What we are doing: Look specifically for log entries showing fragmentation: fragment indices, sizes, and the sender/receiver behavior. Fragmentation entries show which side sent fragments and whether acknowledgements were seen — a common cause of stalls.

# Show lines mentioning EAP-TLS Fragment and display surrounding context
show application ise live-logs | include "EAP-TLS Fragment" | begin "SessionID="

What just happened: We pulled the fragmentation-related log messages for the target session. These entries tell you how many fragments were required (TotalFragments), which fragment index was processed, and size of each fragment. Because the EAP-TLS sender must wait for the peer to respond before sending the next fragment, these logs tell you where the flow paused.

Real-world note: Large server certs (2,200–8,000 bytes) often trigger fragmentation; if clients are behind constrained APs or MTU-limited paths, fragments may get dropped — watch fragment sizes and sequence.

Verify:

# Expected output (complete fragmentation lines)
ISE-LIVE-LOG: 2025-05-15 10:12:35 SessionID= Event=EAP-TLS Fragment Received From=RADIUS Server FragmentIndex=1 TotalFragments=3 Size=3200
ISE-LIVE-LOG: 2025-05-15 10:12:35 SessionID= Event=EAP-TLS Forwarded To=WLC FragmentIndex=1 AcknowledgedByClient=false
ISE-LIVE-LOG: 2025-05-15 10:12:36 SessionID= Event=EAP-TLS Request For Next Fragment Sent To=RADIUS Server Reason=ClientAckReceived
ISE-LIVE-LOG: 2025-05-15 10:12:37 SessionID= Event=EAP-TLS Fragment Received From=RADIUS Server FragmentIndex=2 TotalFragments=3 Size=2800

Step 4: Correlate over-the-air pcap evidence with EAP Packet ID and RADIUS Identifier

What we are doing: Use the EAP Packet ID (31) and RADIUS Identifier (143) from ISE logs to find the same IDs in the WLC/AP pcap and the supplicant OTA capture. Matching them proves the packet path and helps identify where fragmentation or retransmission occurs.

# Example: show log lines capturing EAP Packet ID 31
show application ise live-logs | include "EAPPacketID=31"

What just happened: This command shows every log line that mentions EAP Packet ID 31. Once you have these lines, you can open the pcap and filter for eap.packet_id == 31 and radius.identifier == 143 to see matching frames. The matching proves the EAP packet preserved the same ID from ISE → WLC → AP → Supplicant.

Real-world note: When troubleshooting with TAC, provide the session ID, RADIUS Identifier, and EAP Packet ID — this lets engineers correlate system logs and packet captures quickly.

Verify:

# Expected output lines
ISE-LIVE-LOG: 2025-05-15 10:12:34 SessionID= EAPPacketID=31 Event=EAP-Request IdentityRequest
ISE-LIVE-LOG: 2025-05-15 10:12:35 SessionID= EAPPacketID=31 Event=EAP-Response IdentityResponse
ISE-LIVE-LOG: 2025-05-15 10:12:35 SessionID= EAPPacketID=31 Event=EAP-TLS ClientHello Observed Size=600

Step 5: Generate a targeted authentication report showing fragment-related failures

What we are doing: Run a report or query that counts EAP-TLS failures and flags those where logs show fragmentation or large certificate sizes. This provides an operational overview that pinpoints problematic RADIUS transactions.

# Generate a short report for EAP-TLS auths that mention Fragment or Size>2000
show application ise reports | include "EAP-TLS" | include "Fragment\|Size>2000"

What just happened: This command queries ISE reporting data for EAP-TLS authentications where fragmentation occurred or fragment sizes exceed typical thresholds. The output gives you counts and specific session IDs to prioritize remediation (for example, examining large server certs or checking WLC MTU settings).

Real-world note: Use such reports to find trends — a single fragmented certificate failure may be isolated, but dozens indicates systemic issues (certificate bloat, MTU issues, or WLC firmware bugs).

Verify:

# Expected report output
REPORT: EAP-TLS Fragmentation Summary DateRange=2025-05-01..2025-05-15 TotalAuthAttempts=2456 TotalFragmentedAuths=87 SessionsWithLargeServerCerts=53
REPORT DETAIL: SessionID= Username=labuser1 FragmentCount=3 LargestFragmentSize=3200 Result=Success
REPORT DETAIL: SessionID= Username=labuser2 FragmentCount=4 LargestFragmentSize=5200 Result=Failure Reason=MissingFragmentAck

Verification Checklist

• Check 1: Locate the ISE live log entry for SessionID=. Verify using show application ise live-logs | include and ensure lines show RadiusIdentifier=143 and EAPPacketID=31.
• Check 2: Confirm RADIUS Identifier consistency by running show radius live-sessions | include Identifier=143 and ensure the same Identifier appears for Access-Request and Access-Challenge entries.
• Check 3: Validate fragmentation sequence: verify "TotalFragments" and "FragmentIndex" entries in the ISE logs and cross-check with the WLC/AP pcap for matching EAP Packet ID 31.
• Check 4: Run an EAP-TLS fragmentation report and ensure SessionsWithLargeServerCerts correspond to the sessions flagged in the live logs.

Common Mistakes

Symptom	Cause	Fix
You see Access-Request in ISE but no Access-Challenge	RADIUS response lost or delayed, or RADIUS server never generated challenge due to policy error	Verify ISE policy for that endpoint identity; check RADIUS server health and logs; ensure network path between WLC and ISE has no packet drops
EAP-TLS stops after first fragment with no further fragments	Either client didn't ack or WLC didn't forward ack to RADIUS; fragmentation flow control not respected	Correlate WLC/AP pcaps and ISE logs. Check for missing client acks in OTA captures and ensure the WLC firmware supports large EAP fragments
Different RADIUS Identifier in Access-Challenge than Access-Request	An intermediary (load balancer/NAT) rewrote identifiers, breaking correlation	Bypass or reconfigure the intermediary to preserve RADIUS identifiers or use a supported RADIUS load balancer configuration
Reports show many fragmented sessions but most succeed	Fragmentation alone is not failure — report may be misinterpreted; size alone doesn't mean error	Inspect individual session details using the session ID to differentiate between successful fragmented auths and failed ones

Key Takeaways

• Use three keys to correlate 802.1X single events: Session ID (e.g., ), RADIUS Identifier (e.g., 143), and EAP Packet ID (e.g., 31). These let you map across ISE logs, WLC/AP pcaps, and over-the-air captures.
• EAP-TLS fragmentation is flow-controlled — sender waits for the peer to reply before sending the next fragment. Missing acknowledgements at any hop (AP, WLC, or network) cause stalls that look like authentication timeouts.
• Large server certificates (commonly 2,200–8,000 bytes) are a frequent cause of fragmentation; use reports to find trend-level issues and then drill into session logs for root cause.
• In production, always correlate logs with packet captures and report outputs. Live logs show what the server processed; pcaps show what the client/AP actually received — only by comparing both can you identify where the failure occurred.

Warning: When opening live logs and pcaps in production, avoid exposing certificates or private keys in reports. Use role-based access controls on ISE and secure the lab.nhprep.com access credentials (password Lab@123 is for lab examples only).

If you followed each step and validated the expected outputs, you have the tools to trace 802.1X EAP-TLS problems from the supplicant over the air, through the WLC, to ISE and back — and to determine whether a failed or slow authentication is due to RADIUS identifier issues, EAP packet ID mismatch, fragmentation problems, or certificate size.