Wie stellt ein Cisco Switch mit IOS-XE die RADIUS-Verbindung zur ISE über DPLS erneut her?

**Wenn die RADIUS-Verbindung eines IOS-XE-Switches zur Cisco ISE „weg“ ist, stellst du sie in der Praxis nicht über einen speziellen „DPLS-Reset“ wieder her, sondern indem du den betroffenen RADIUS-Server bzw. die AAA-Session neu initialisierst und die Erreichbarkeit/Deadtime prüfst.** Cisco IOS-XE behandelt ISE dabei als normalen RADIUS-Server; entscheidend sind Server-Status, Source-Interface, Shared Secret und ggf. Deadtime/Timeout. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/sec-crypto/radius/radius-configuration-guide/radius.html)) ## Was du konkret machen kannst Auf dem Switch zuerst prüfen, ob der ISE-Server als „dead“ markiert ist: ```text show aaa servers show radius statistics show running-config | section radius show running-config | section aaa ping <ISE-IP> source <dein-radius-source-interface> test aaa group radius <aaa-gruppenname> <username> <password> new-code ``` Wenn der Server nur wegen Deadtime gesperrt ist, hilft oft bereits das manuelle Neuinitialisieren des RADIUS-Prozesses bzw. das erneute Aktivieren der Serverdefinition. Auf IOS-XE ist der saubere Weg meist: ```text clear aaa servers ``` oder – je nach Plattform/Release – gezielt die RADIUS-Statistiken/Sessions zu leeren und danach den Test erneut auszuführen. Cisco dokumentiert für IOS-XE die Serverdefinition, Dead-Criteria und Source-Interface als die entscheidenden Punkte für die Wiederaufnahme der Kommunikation. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/sec-crypto/radius/radius-configuration-guide/radius.html)) ## Der häufigste Grund, warum es nicht sofort wieder klappt Meist ist nicht „DPLS“ selbst das Problem, sondern einer dieser vier Punkte: - falsches oder nicht erreichbares `ip radius source-interface` - ISE-IP per Routing/VRF nicht erreichbar - Shared Secret stimmt nicht mehr - der Server wurde durch `dead-criteria`/`deadtime` als tot markiert und bleibt deshalb vorübergehend aus dem Auswahlprozess Gerade der letzte Punkt wird oft übersehen: Dann ist die ISE wieder erreichbar, aber der Switch nutzt sie noch nicht sofort wieder. Genau deshalb ist `show aaa servers` wichtiger als bloß ein Ping. Cisco empfiehlt außerdem passende Dead-Criteria und die korrekte Source-Interface-Konfiguration für ISE-Anbindungen. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_sw_cnfg.html)) ## Praxisvorgehen, das meist schneller zum Ziel führt 1. Erreichbarkeit zur ISE mit derselben Source-IP testen. 2. `show aaa servers` prüfen: steht der PSN auf dead/alive 3. Falls dead: `clear aaa servers` ausführen. 4. Danach mit `test aaa group radius ...` aktiv einen neuen Request erzeugen. 5. Wenn weiter keine Antwort kommt: Shared Secret, Ports 1812/1813 und VRF/ACL prüfen. Cisco beschreibt die Standardports und die typische IOS-XE-RADIUS-Definition genau so. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_sw_cnfg.html)) ## Wichtiger Unterschied Wenn du eigentlich **CoA / Device Administration / Posture** meinst, ist zusätzlich `aaa server radius dynamic-author` relevant. Das stellt aber nicht die normale RADIUS-Basisverbindung wieder her, sondern erlaubt ISE, CoA-Nachrichten an den Switch zu senden. Viele verwechseln das mit dem eigentlichen RADIUS-Reconnect. ([cisco.com](https://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_sw_cnfg.html)) Die klare Empfehlung ist deshalb: **nicht blind den ganzen Switch neu starten, sondern zuerst den AAA-Serverstatus leeren und einen echten RADIUS-Test mit der richtigen Source-IP auslösen.** Das behebt den Fehler deutlich gezielter und zeigt sofort, ob es ein Transport-, Konfigurations- oder ISE-Problem ist. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/sec-crypto/radius/radius-configuration-guide/radius.html))