Dynamisches Servicemanagement mit RADIUS

Vorteile von Radius Dynamic Requests

Ermöglicht eine simplifizierte zentrale Verwaltung von Abonnentensitzungen durch das Senden unerwünschter Änderungen an Abonnentensitzungen, einschließlich Änderungen an Attributen, Dienstaktivierung, -deaktivierung und -beendigung.

CoA-Meldungen

Dank der Unterstützung dynamischer Anfragen kann der Router unerwünschte CoA-Nachrichten von externen RADIUS-Servern empfangen und verarbeiten. RADIUS-initiierte CoA-Nachrichten verwenden die folgenden Codes in Anforderungs- und Antwortnachrichten:

• CoA-Antrag (43)

• CoA-ACK (44)

• CoA-NAK (45)

Voraussetzungen für die Änderung der Zulassung

Um die Änderung der Berechtigung für einen Benutzer abzuschließen, geben Sie Identifikationsattribute und Sitzungsattribute an. Die Identifikationsattribute identifizieren den Abonnenten. Sitzungsattribute geben den Vorgang (Aktivierung oder Deaktivierung) an, der für die Sitzung des Abonnenten ausgeführt werden soll, und enthalten auch alle Clientattribute für die Sitzung (z. B. QoS-Attribute). Das AAA Service Framework verarbeitet die eigentliche Anforderung.

Tabelle 1 zeigt die Identifikationsattribute für CoA-Operationen.

Tabelle 2 zeigt die Sitzungsattribute für CoA-Vorgänge. Alle zusätzlichen Clientattribute, die Sie einschließen, hängen von Ihren jeweiligen Sitzungsanforderungen ab.

Nachrichtenaustausch

Der RADIUS-Server und das AAA Service Framework auf dem Router tauschen Nachrichten über UDP aus. Die vom RADIUS-Server gesendete CoA-Request-Nachricht hat das gleiche Format wie das Disconnect-Request-Paket, das für einen Trennungsvorgang gesendet wird.

Die Antwort ist entweder eine CoA-ACK- oder eine CoA-NAC-Nachricht:

• Wenn das AAA Service Framework die Autorisierung erfolgreich ändert, ist die Antwort ein Paket im RADIUS-Format mit einer CoA-ACK-Nachricht, und der Datenfilter wird auf die Sitzung angewendet.

• Wenn AAA Service Framework nicht erfolgreich ist, die Anforderung falsch formatiert ist oder Attribute fehlen, ist die Antwort ein Paket im RADIUS-Format mit einer CoA-NAC-Nachricht.

Massen-CoA-Transaktionen

Ab Junos OS Version 17.2R1 werden CoA-Massenanforderungen unterstützt, um die Verarbeitungseffizienz von RADIUS-basierten Abonnentenservices auf dem BNG zu verbessern. Die Bulk-CoA-Funktion ermöglicht die Anhäufung einer Reihe von CoA-Anfragen und führt automatisch einen Commit für alle zusammen in großen Mengen durch.

Alle Dienste in einer CoA-Massenanforderung müssen für dieselbe Abonnentensitzung gelten.

Massen-CoA-Transaktionen sind besonders wertvoll für Unternehmensdienstleistungen. RADIUS-basierte Abonnentenservices verwenden die Juniper Networks VSAs, Activate-Service (26-65) und Deactivate-Service (26-66). Die VSAs werden in RADIUS-Accept-Nachrichten während der Anmeldung oder in CoA-Anfragen nach der Anmeldung bereitgestellt.

Bei herkömmlichen, dynamischen, auf Dienstprofilen basierenden Services passen bis zu 12 Serviceaktivierungen problemlos in eine der beiden RADIUS-Nachrichten. Die von Unternehmen verwendeten Op-Script-basierten Dienste haben jedoch in der Regel Skalierungsanforderungen, die die Kapazität der beiden Nachrichten übersteigen. Dies bedeutet, dass die Angabe und Aktivierung aller Dienste, die in einer bestimmten Abonnentensitzung benötigt werden, möglicherweise die Verwendung einer Accept-Access-Nachricht und mehrerer CoA-Anforderungen erfordert.

Jede CoA-Anforderungsnachricht ist unabhängig von vorherigen und zukünftigen CoA-Anforderungen in derselben Abonnentensitzung. Alle Service-Aktivierungen und -Deaktivierungen in einer Nachricht werden verarbeitet, bevor eine CoA-Antwort angeboten wird. Die CoA-Anforderung bietet eine Möglichkeit, eine Abonnentensitzung inkrementell zu ändern, ohne vorhandene Dienste zu beeinträchtigen, die bereits vorhanden sind.

Bei op-script-basierten Services werden die Servicesitzungen gemeinsam von den Prozessen authd und essmd erstellt, sodass der letzte Vorgang einen Commit initiiert, um alle resultierenden statischen logischen Geschäftsschnittstellen aus der CoA-Anforderung anzuwenden. Da die Commit-Zeit im Allgemeinen den größten Teil der Anwendung eines statischen Geschäftsdienstes ausmacht, ist es von Vorteil, so viele Dienstaktivierungen oder -deaktivierungen zu packen, wie in eine RADIUS-Nachricht passen, um das Commit-Fenster effizient zu nutzen. Solange der Commitvorgang nicht abgeschlossen ist, kann der BNG eine nachfolgende CoA-Anforderung zum Anwenden zusätzlicher Business-Services für dieselbe Abonnentensitzung nicht akzeptieren.

Bulk CoA verbessert die Effizienz der Commit-Verarbeitung durch die Verwendung einer einzigen Commit-Aktion für alle Services in der Massentransaktion. Die Massentransaktion hat den Effekt, dass eine Reihe von Anforderungen als einzelne Metaanforderung verwaltet wird. Die Commit-Verarbeitung wird verschoben, bis die endgültige CoA-Anforderung in der Massentransaktion empfangen wird.

Bulk-CoA erfordert, dass jede einzelne Anforderung eine einzige Instanz der Juniper Networks Bulk-CoA-Transaction-Id VSA (26–194) enthält. Dieser VSA identifiziert Anforderungen, die zur gleichen Massentransaktion gehören. 26–194 muss in allen CoA-Anforderungen in der Massenreihe den gleichen Wert haben. Jede aufeinanderfolgende Massentransaktion in der Sitzung muss einen anderen Bezeichner haben. Beispielsweise können drei aufeinanderfolgende Massentransaktionen die IDs 1, 2 und 1 haben, aber nicht die aufeinanderfolgenden IDs 1, 1 und 2. In der Praxis wird der Wert Bulk-CoA-Transaction-Id in der Regel für mehrere Massentransaktionen inkrementiert, dies ist jedoch nicht erforderlich. Ein ID-Wert, der in einer bestimmten Abonnentensitzung verwendet wird, kann auch in verschiedenen Abonnentensitzungen verwendet werden.

Jede CoA-Anforderung innerhalb einer Massentransaktion hat ihre eigene eindeutige Kennung, die von einer einzelnen Instanz des Bulk-CoA-Identifier VSA (26–195) in jedem CoA bereitgestellt wird. Eine zunehmende Reihe von Werten für die ID ist typisch, wird aber nicht erzwungen. Werte können innerhalb einer bestimmten Sitzung und zwischen Sitzungen wiederverwendet werden. Die letzte CoA-Anforderung in der Serie wird durch den Wert 0xFFFFFFFF für den Bulk-CoA-Identifier identifiziert.

Vorteile der Radius-initiierten Autorisierungsänderung

Ermöglicht das dynamische Pushen von Änderungen an Attributwerten an Abonnentensitzungen sowie die dynamische Aktivierung und Deaktivierung von Abonnentendiensten.

Trennen von Meldungen

Um die Trennung von RAS-Abonnenten zentral zu steuern, empfängt und verarbeitet die dynamische RADIUS-Anforderungsfunktion auf dem Router unerwünschte Nachrichten von RADIUS-Servern.

Die dynamische Anforderungsfunktion verwendet das vorhandene Format von RADIUS-Trennungsanforderungs- und -antwortnachrichten. Die von RADIUS initiierte Trennung verwendet die folgenden Codes in den RADIUS-Anforderungs- und Antwortnachrichten:

• Trennungs-Anfrage (40)

• Trennen-ACK (41)

• NAK trennen (42)

Voraussetzungen für die Unterbrechung der Verbindung

Damit das AAA Service Framework die Verbindung eines Benutzers trennen kann, muss die Disconnect-Request-Nachricht ein Attribut mit einer Kontoführungssitzungs-ID enthalten. Die Disconnect-Request-Nachricht kann ein Acct-Session-Id (44)-Attribut oder ein Acct-Multi-Session-Id (50)-Attribut für die Sitzungs-ID oder beides enthalten. Wenn sowohl die Attribute "Acct-Session-Id" als auch "Acct-Multi-Session-Id" in der Anforderung vorhanden sind, verwendet der Router beide Attribute. Wenn das Attribut User-Name (1) auch in der Anforderung vorhanden ist, werden der Benutzername und die Accounting-Sitzungs-ID verwendet, um die Verbindung zu trennen. Das AAA Service Framework verarbeitet die eigentliche Anforderung.

Nachrichtenaustausch

Der RADIUS-Server und das AAA Service Framework tauschen Nachrichten über UDP aus. Die vom RADIUS-Server gesendete Disconnect-Request-Nachricht hat das gleiche Format wie das CoA-Request-Paket, das für eine Änderung des Autorisierungsvorgangs gesendet wird.

Die Disconnect-Antwort ist entweder eine Disconnect-ACK- oder eine Disconnect-NAK-Nachricht:

• Wenn das AAA Service Framework den Benutzer erfolgreich trennt, ist die Antwort ein Paket im RADIUS-Format mit einer Disconnect-ACK-Meldung.

• Wenn das AAA-Service-Framework den Benutzer nicht trennen kann, die Anforderung falsch formatiert ist oder Attribute in der Anforderung fehlen, ist die Antwort ein Paket im RADIUS-Format mit einer Disconnect-NAC-Meldung.

Vorteile von Radius-initiierten Trennungen

Ermöglicht einem RADIUS-Server das dynamische Beenden von Abonnentensitzungen. Diese zentrale Teilnehmerverwaltungsfunktion vereinfacht den Umgang mit einer großen Anzahl von Teilnehmern, da die Kündigung durch den Betreiber andernfalls Maßnahmen am Router erfordern würde.

Aktivierungsprozess der Service- und Netzwerkfamilie

Wenn sich ein Teilnehmer anmeldet, muss authd die entsprechende Adressfamilie aktivieren, nachdem der Teilnehmer authentifiziert wurde. Die Clientanwendung, z. B. DHCP oder PPP, kann die Aktivierung einer einzelnen Netzwerkfamilie (IPv4 oder IPv6) oder nacheinander die Aktivierung beider Produktfamilien anfordern. Eine erfolgreiche Aktivierung der Netzwerkfamilie hängt mit der Aktivierung der zugehörigen Services zusammen. In den folgenden Schritten wird der Prozess beschrieben, wenn authd für die Verwendung von RADIUS für die Authentifizierung konfiguriert ist:

1. Ein Abonnent versucht, sich anzumelden.

   1. Die Clientanwendung fordert die Authentifizierung von authd an.

   2. authd sendet eine Access-Request-Nachricht an den RADIUS-Server.

   3. Der RADIUS-Server sendet eine Access-Accept-Nachricht an authd, die den RADIUS Activate-Service VSA (26-65) enthält.

   4. authd speichert die Dienstaktivierungsattribute im Cache und sendet eine Gewährung an die Clientanwendung.

2. Die Clientanwendung sendet die erste Network-Family-Activate-Anforderung für die IPv4- oder IPv6-Adressfamilie. Diese Anforderung wird manchmal auch als Clientaktivierungsanforderung bezeichnet.

3. authd überprüft die zwischengespeicherten Dienstaktivierungsattribute und sendet eine Aktivierungsanforderung für die entsprechenden Dienste an die Abonnentenverwaltungsinfrastruktur (SMI). Wenn sich die Anforderung beispielsweise auf die IPv4-Familie bezieht, wird nur die Aktivierung der IPv4-Dienste angefordert. Im Gegenzug sendet der SMI Anforderungen an die Server-Daemons, die dem Dienst zugeordnet sind, z. B. cosd oder filterd.

4. Was authd als nächstes tut, hängt davon ab, ob die Dienstaktivierungsanforderung fehlschlägt und ob der Dienst optional oder erforderlich ist.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst optional ist:

     1. authd löscht die zwischengespeicherten Dienstaktivierungsattribute für den Dienst.

        Anmerkung:

        Durch diese Löschung können Sie die Serviceanforderung mithilfe einer RADIUS-CoA-Anforderung (Change of Authorization) oder eines CLI-Befehls erneut ausstellen, ohne dass der fehlgeschlagene Service beeinträchtigt wird.

     2. authd sendet eine ACK als Antwort auf die Familienaktivierungsanfrage und die Familie wird aktiviert.

     3. Die Anmeldung des Abonnenten wird fortgesetzt.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst erforderlich ist:

     1. authd löscht die zwischengespeicherten Dienstaktivierungsattribute für den Dienst.

        Anmerkung:

        Durch diese Löschung können Sie die Serviceanforderung mithilfe einer RADIUS-CoA-Anforderung (Change of Authorization) oder eines CLI-Befehls erneut ausstellen, ohne dass der fehlgeschlagene Service beeinträchtigt wird.

     2. authd sendet als Antwort auf die Familienaktivierung einen NACK, der dazu führt, dass die Clientanwendung die Anmeldung des Abonnenten beendet.

   • Wenn die Dienstaktivierung aufgrund eines Nichtkonfigurationsfehlers fehlschlägt und der Dienst entweder optional oder erforderlich ist:

     1. authd löscht die zwischengespeicherten Dienstaktivierungsattribute für den Dienst.

        Anmerkung:

        Durch diese Löschung können Sie die Serviceanforderung mithilfe einer RADIUS-CoA-Anforderung (Change of Authorization) oder eines CLI-Befehls erneut ausstellen, ohne dass der fehlgeschlagene Service beeinträchtigt wird.

     2. authd sendet als Antwort auf die Familienaktivierung einen NACK, der dazu führt, dass die Clientanwendung die Anmeldung des Abonnenten beendet.

   • Wenn die Dienstaktivierung erfolgreich ist:

     1. authd aktiviert den Dienst.

     2. authd sendet eine ACK als Antwort auf die Familienaktivierungsanfrage und die Familie wird aktiviert.

     3. Die Anmeldung des Abonnenten wird fortgesetzt.

5. Sofern die Dienstaktivierung nicht erforderlich war und ein Fehler aufgetreten ist, wodurch die Familienaktivierung bei der ersten Anforderung fehlgeschlagen ist, kann die Clientanwendung eine zweite Anforderung senden, jedoch nur für die Familie, die beim ersten Mal nicht angefordert wurde. Wenn die erste Anforderung für IPv4 war, kann die zweite Anforderung nur für IPv6 erfolgen. Wenn die erste Anforderung für IPv6 war, kann die zweite Anforderung nur für IPv4 erfolgen.

6. AUTHD überprüft die zwischengespeicherten Aktivierungsattribute des Dienstes und fordert die Aktivierung für die Dienste an, die der angeforderten Adressfamilie zugeordnet sind.

7. Was authd als nächstes tut, hängt davon ab, ob die Dienstaktivierungsanforderung fehlschlägt und ob der Dienst optional oder erforderlich ist.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst optional ist:

     1. authd löscht die zwischengespeicherten Dienstaktivierungsattribute für den Dienst.

        Anmerkung:

        Durch diese Löschung können Sie die Serviceanforderung mithilfe einer RADIUS-CoA-Anforderung (Change of Authorization) oder eines CLI-Befehls erneut ausstellen, ohne dass der fehlgeschlagene Service beeinträchtigt wird.

     2. authd sendet eine ACK als Antwort auf die Familienaktivierungsanfrage und die Familie wird aktiviert.

     3. Die Anmeldung des Abonnenten wird fortgesetzt.

   • Wenn die Dienstaktivierung aufgrund eines Konfigurationsfehlers fehlschlägt und der Dienst erforderlich ist:

     1. authd löscht die zwischengespeicherten Dienstaktivierungsattribute für den Dienst.

        Anmerkung:

        Durch diese Löschung können Sie die Serviceanforderung mithilfe einer RADIUS-CoA-Anforderung (Change of Authorization) oder eines CLI-Befehls erneut ausstellen, ohne dass der fehlgeschlagene Service beeinträchtigt wird.

     2. authd sendet einen NACK als Antwort auf die Familienaktivierung. Da es sich hierbei um die zweite Familienaktivierungsanforderung handelt, bestimmt das Ergebnis der ersten Familienaktivierung, was als nächstes geschieht:

        • Wenn die erste Familienaktivierung erfolgreich war und sich dieser Abonnent angemeldet hat, wird die aktuelle Abonnentenanmeldung nicht gestoppt, wenn die zweite Anforderung fehlschlägt. Dieses Ereignis führt auch nicht dazu, dass authd den vorherigen Abonnenten (erste Anfrage) abmeldet.

        • Wenn die erste Familienaktivierung nicht erfolgreich war, führt ein Fehler bei der zweiten Anforderung dazu, dass die Clientanwendung die aktuelle Abonnentenanmeldung beendet.

   • Wenn die Dienstaktivierung aufgrund eines Nichtkonfigurationsfehlers fehlschlägt und der Dienst entweder optional oder erforderlich ist:

     1. authd löscht die zwischengespeicherten Dienstaktivierungsattribute für den Dienst.

        Anmerkung:

        Durch diese Löschung können Sie die Serviceanforderung mithilfe einer RADIUS-CoA-Anforderung (Change of Authorization) oder eines CLI-Befehls erneut ausstellen, ohne dass der fehlgeschlagene Service beeinträchtigt wird.

     2. authd sendet als Antwort auf die Familienaktivierung einen NACK, der dazu führt, dass die Clientanwendung die Anmeldung des Abonnenten beendet.

   • Wenn die Dienstaktivierung erfolgreich ist:

     1. authd aktiviert den Dienst.

     2. authd sendet eine ACK als Antwort auf die Familienaktivierungsanfrage und die Familie wird aktiviert.

     3. Die Anmeldung des Abonnenten wird fortgesetzt.

Zweck

Zeigen Sie dynamische RADIUS-Anforderungsstatistiken und -informationen an.

Aktion

• So zeigen Sie dynamische RADIUS-Anforderungsstatistiken an: