RADIUS-Abrechnung für den Anwenderzugriff

Layer-3-Szenarien für den Großhandel

In einer Layer-3-Netzwerkumgebung für den Großhandel verwenden der Groß- und der Einzelhändler möglicherweise unterschiedliche RADIUS-Buchhaltungsserver, und beide möchten möglicherweise Buchhaltungsberichte erhalten. In dieser Situation können Sie die doppelte Berichterstellung für die RADIUS-Buchhaltung konfigurieren, die Berichte sowohl an den Großhändler als auch an die Buchhaltungsserver des Einzelhändlers sendet. Das Ziel, an das die doppelten Buchhaltungsdatensätze gesendet werden, muss sich in der Kombination aus Standard:Standard-logischem System:Routing-Instanz (LS:RI) befinden, die auch als Standard-VRF bezeichnet wird.

Tabelle 2 zeigt, wohin die Verwaltung der Anwender die Buchhaltungsberichte sendet, wenn Sie doppelte Berichte aktivieren. Die Abonnentenverwaltung sendet doppelte Berichte basierend auf dem Zugriffsprofil, in dem Sie die duplication Anweisung auf Hierarchieebene [edit access profile profile-name accounting] konfigurieren, wo sich der Anwender befindet und wie der Anwender authentifiziert wird.

Andere Szenarien

Für Szenarien, die sich nicht in einer Layer-3-Großhandels-Netzwerkumgebung befinden, möchten Sie möglicherweise doppelte Buchhaltungsdatensätze an eine andere Gruppe von RADIUS-Servern senden, die sich entweder im selben oder in einem anderen Routing-Kontext befinden. Anders als im Layer-3-Szenario für den Großhandel muss das Ziel für die doppelten RADIUS-Buchhaltungsdatensätze nicht das Standard-VRF sein. Sie können ein einzelnes nicht standardmäßiges VRF als die Kombination default:default LS:RI als Ziel angeben. Darüber hinaus können Sie bis zu fünf Zugriffsprofile im Ziel-VRF angeben, die die RADIUS-Accounting-Server auflisten, die die doppelten Berichte erhalten.

Beispielsweise könnte es ein Szenario für das rechtmäßige Abfangen geben, bei dem der Anwender in der Standarddomäne authentifiziert wird. Eine autorisierte Strafverfolgungsbehörde benötigt doppelte Buchhaltungsdatensätze für den Anwender, die an ein Vermittlungsgerät gesendet werden, das sich in der Netzwerkdomäne der Organisation befindet, die in einem nicht standardmäßigen VRF liegt.

Die Abonnentenverwaltung sendet doppelte Berichte an das VRF, das Sie mit der vrf-name Anweisung auf Hierarchieebene [edit access profile profile-name accounting duplication-vrf] angeben. Fügen Sie die access-profile-name Anweisung auf derselben Ebene ein, um die Zugriffsprofile festzulegen, die wiederum die RADIUS-Server angeben, die die doppelten Berichte empfangen.

Filter für doppelte Buchhaltungsberichte

Die Abonnentenverwaltung bietet eine Duplikatfilterfunktion, mit der Sie angeben können, welche Abrechnungsserver die Zwischenberichte für die RADIUS-Buchhaltung erhalten, wenn die doppelte Berichterstellung für die RADIUS-Buchhaltung aktiv ist. Sie konfigurieren die Filter im AAA-Zugriffsprofil, und der Router wendet die Filter dann auf Abonnenten an, die diesem Profil zugeordnet sind.

Die Abonnentenverwaltung unterstützt die folgende Filterung für doppelte Berichte für die doppelte Berichterstellung von RADIUS-Buchhaltung:

• Doppelte Buchhaltungszwischenmeldungen— Der Router filtert doppelte Buchhaltungsmeldungen. Die Accounting-Nachrichten werden nur an RADIUS-Accounting-Server im Zugriffsprofil des Anwenders gesendet.

• Zwischennachrichten für die ursprüngliche Kontoführung: Der Router filtert Kontoführungsmeldungen, die für ursprüngliche RADIUS-Buchhaltungsserver bestimmt sind, bei denen es sich im Zugriffsprofil des Anwenders um Kontoführungsserver handelt. Die Accounting-Nachrichten werden nur an Duplikations-Accounting-Server gesendet (Server in einem anderen Duplizierungs-Zugriffsprofil als das Zugriffsprofil des Anwenders).

• Ausgeschlossene RADIUS-Attribute – Der Router filtert die RADIUS-Attribute in den Buchhaltungsmeldungen basierend auf der exclude Anweisungskonfiguration im Zugriffsprofil unter dem Duplizierungskontext. Sie können den Ausschlussfilter allein oder mit den duplizierten oder ursprünglichen Buchhaltungsnachrichtenfiltern verwenden.

Vorteile

• Erhöhte Flexibilität durch einzigartige Buchhaltungskonfigurationen für einzelne Services, die ein maßgeschneidertes Servicemanagement für unterschiedliche betriebliche Anforderungen ermöglichen.

• Die kontinuierliche Serviceverfügbarkeit über die Standard-Serviceaktivierung hält die Sitzungen der Anwender auch dann aufrecht, wenn externe Authentifizierungsserver ausgefallen sind.

• Ausfallsicherheit im Service-Management durch automatische Zuweisung eines lokalen Fallback-Serviceprofils, wodurch Serviceunterbrechungen bei Serverausfällen verhindert werden.

• Simplifizierte Netzwerkkonfiguration durch Integration von Updates in bestehende Systeme, Reduzierung der Komplexität bei der Implementierung ohne Beeinträchtigung der Systemstabilität.

• Betriebseffizienz ohne Einführung neuer Anwendungsprogrammierschnittstellen, SNMP-Änderungen oder Systemprotokollmeldungen, was eine einfache Einführung erleichtert und Herausforderungen bei der Integration minimiert.

Überblick

Die Implementierung von RADIUS Accounting Override pro Service ermöglicht die Anpassung von Accounting-Konfigurationen auf Servicebasis innerhalb einer Anwender-Sitzung. Geben Sie unterschiedliche RADIUS-Abrechnungsserver und -Intervalle für einzelne Services an, um die Granularität im Service-Management zu verbessern. Verwenden Sie die Konfigurationsoption accounting-server [<list-of-server-addresses>]; , um eindeutige Serverlisten für jeden Service zu definieren und die Buchhaltung an die spezifischen Betriebsanforderungen anzupassen. update-interval <n>; Ermöglicht außerdem die Anpassung der Aktualisierungsintervalle der Buchhaltung, wodurch eine Datenerfassung in optimalen Frequenzen sichergestellt wird, die den Serviceanforderungen entsprechen.

Die standardmäßige Serviceaktivierung gewährleistet die ununterbrochene Serviceverfügbarkeit durch Zuweisung eines lokalen Fallback-Serviceprofils, wenn externe RADIUS-Server nicht erreichbar sind. Ähnlich wie bei DHCP-Sitzungen dient es service-profile <service-name>; als Fallback für PPPoE-Sitzungen, um ein vordefiniertes lokales Serviceprofil zu aktivieren und den Zugriff auf wesentliche Services bei externen Serverausfällen aufrechtzuerhalten. default-service-local-only; Verfeinert die Funktionalität, indem die Standarddienstaktivierung auf lokale Authentifizierungsszenarien beschränkt wird und Fallbackdienste nur bei Bedarf in Anspruch genommen werden.

Diese Verbesserungen lassen sich nahtlos in bestehende Systeme integrieren, ohne die Hochverfügbarkeit oder die Sicherheitsprotokolle zu verändern. Sie nutzen vorhandene Konfigurationsstrukturen, um erweiterte Service-Management-Funktionen zu implementieren, die Einführung zu vereinfachen und die Komplexität der Integration zu minimieren, die betriebliche Effizienz aufrechtzuerhalten und gleichzeitig die Flexibilität und Zuverlässigkeit des Service-Managements zu erhöhen.

Konfigurieren von RADIUS Accounting-Überschreibungen für Services

Um einem Dienst einen bestimmten RADIUS-Abrechnungsserver zuzuweisen, fügen Sie die folgenden Anweisungen in die [edit access profile profile-name service] hierarchy level]

profile-name — Name des Zugriffsprofils.

service-name — Name des Dienstes.

server-address — IP-Adresse(n) des RADIUS-Abrechnungsservers

Um das Aktualisierungsintervall für die Kontohaltung für einen Dienst zu konfigurieren, schließen Sie die folgenden Anweisungen auf Hierarchieebene [edit access profile profile-name service] ein:

Wobei:

n — Aktualisierungsintervall in Sekunden.

Um ein lokales Dienstprofil anzugeben und die Dienstaktivierung auf rein lokale Szenarien zu beschränken, fügen Sie die folgenden Anweisungen auf der Hierarchieebene [edit access profile profile-name] ein:

Zweck

Zeigen Sie Informationen zu RADIUS-Accounting-Stoppmeldungen an, die zurückgehalten werden, weil der RADIUS-Accounting-Server nicht kontaktiert werden kann.

Aktion

Wenn Sie wissen möchten, ob sich die Anzahl der ausstehenden Kontostoppmeldungen dem Maximum nähert, können Sie eine einfache Anzahl ausstehender Anforderungen anzeigen:

Sie können andere Befehle verwenden, um weitere Informationen zu den Buchhaltungsmeldungen anzuzeigen. Im nächsten Beispiel werden Informationen für alle Services in der Buchhaltungssitzung für den Benutzer vjshah29@example.com angezeigt. Obwohl in diesem Beispiel nur ein Benutzer angezeigt wird, werden mit diesem Befehl die Informationen für alle Abonnenten angezeigt, für die die Buchhaltung gesichert wird.

Sie können zusammenfassende Informationen für alle Benutzer mit einem bestimmten Zugriffsprofil anzeigen. Im folgenden Beispiel verfügt nur ein einzelner Benutzer, vjshah29@example.com, über das angegebene Zugriffsprofil ce-ppp-profile:

Sie können auch zusammenfassende Informationen für alle Abonnenten anzeigen, für die Accounting-Stop-Nachrichten ausstehen, unabhängig vom Zugriffsprofil. Im nächsten Beispiel werden Informationen für zwei Benutzer angezeigt. Da der Anwender larry@example.com im vorherigen Beispiel nicht dargestellt wird, muss er ein anderes Zugriffsprofil als vjshah29@example.com haben, obwohl er die gleichen Dienste erhalten hat.

Abfolge von Ereignissen während der Aussetzung, des Baselinings und der Wiederaufnahme der Buchhaltung

Die folgende Abfolge von Ereignissen tritt auf, wenn Sie die Buchhaltung anhalten, eine Baseline generieren und Buchhaltungsprozesse neu starten:

1. Geben Sie den request network-access aaa accounting suspend Befehl zum Anhalten der Buchhaltung ein.

   1. Es wird eine Systemprotokollierungsmeldung generiert, die angibt, dass die Buchhaltung ausgesetzt wurde.

   2. Die gesamte Buchhaltung, einschließlich der Optionen für die Kontosicherung, wird für alle Buchhaltungsserver in allen Routingkontexten angehalten.

2. Geben Sie den request network-access aaa accounting baseline Befehl ein, um eine Baseline zu generieren.

   1. Es wird eine Systemprotokollierungsmeldung generiert, die angibt, dass das Baselining für Buchhaltungsstatistiken gestartet wurde.

   2. Zeit- und Volumenstatistiken für jeden Anwender werden auf den Basiswert festgelegt. Die Zeit, die zum Abschließen des Basisprozesses benötigt wird, ist abhängig von der Anzahl der statistischen Details unbestimmt.

   3. Es wird eine Systemprotokollierungsmeldung generiert, die angibt, dass das Baselining abgeschlossen ist.

3. Geben Sie den request network-access aaa accounting resume Befehl ein, wenn das Baselining abgeschlossen ist, um die Buchhaltungsprozesse neu zu starten.

   1. Es wird eine Systemprotokollierungsmeldung generiert, die angibt, dass die Buchhaltung wieder aufgenommen wurde.

   2. Alle zuvor konfigurierten Kontoführungsoptionen werden wieder aktiviert.

Der Baselinevorgang versucht, die Zeit- und Volumenzähler für jeden Anwender zu ermitteln. Abonnentenzähler werden nur dann auf Basiswerte gesetzt, wenn die Zwischenabrechnung für den Anwender mithilfe der set update-interval minutes Anweisung auf Hierarchieebene [edit access profile profile-name accounting] aktiviert ist. Wenn die Zwischenabrechnung für einen Anwender nicht aktiviert ist, werden die Leistungsindikatoren dieses entsprechenden Anwenders nicht den Basiswerten zugeordnet.

Nachdem die Baselineanforderung ausgeführt wurde, vergeht ein nicht spezifizierter Zeitraum, um alle Anwenderdatensätze als Baseline zu erstellen. Während dieses Intervalls können sich Statistiken für einen Anwender ansammeln, wenn die statistischen Informationen eines anderen Anwenders als Baseline verwendet werden. Manchmal können die Zähler für einige Services nach dem Start des Baselinings ungenau und inkonsistent sein, da Datenverkehr an einen Anwender geliefert wird, während die Zähler dieses Anwenders als Baseline festgelegt sind. Wenn der Baselinebefehl ausgeführt wurde, kann die Buchhaltung erst fortgesetzt werden, wenn die Baseline abgeschlossen ist. Wenn Sie den Befehl ausgeben, während die Buchhaltung nicht angehalten wird oder das Baselining ausgeführt wird, schlägt der Befehl fehl. Der Befehl meldet einen Fehler, wenn die Buchhaltungslizenz nicht installiert ist.

Richtlinien für die Aussetzung der Rechnungslegung und das Baselining von Statistiken

Beachten Sie die folgenden Punkte, wenn Sie die Buchhaltung aussetzen und eine Baseline für Statistiken angeben:

• Die Aussetzung der Rechnungslegung in einer Umgebung, in der Schwellenwerte (oder Kontingente) gelten, wird nicht unterstützt. Dazu gehören Umgebungen, in denen Schwellenwerte für Gx-Plus und Juniper Networks Session and Resource Control (SRC) oder RADIUS-Sitzungsvolumenkontingente für jeden Anwender gelten. Die Anforderung zum Aussetzen der Buchhaltung schlägt fehl, wenn ein Anwender über Schwellenwerte oder Kontingente verfügt.

• Die Aktivierung für Schwellenwert- (oder Kontingent-) Services ist nicht zulässig, während die Buchhaltung ausgesetzt ist.

• Die Buchhaltungsbaseline wird nicht unterstützt, wenn die Buchhaltung nicht ausgesetzt ist.

• Sie können während einer Buchhaltungssperre nicht mehr als eine Baselineanforderung angeben.

• Baselining für Abonnenten, die nicht mit Zwischenabrechnung konfiguriert sind, wird nicht unterstützt.

• Die Zeit, die für den Abschluss des Basisvorgangs benötigt wird, ist unbestimmt. Sie hängt von der Menge und Tiefe der erfassten Statistiken ab und ist proportional zur Anzahl der Anwender und Servicesitzungen, die zum Zeitpunkt des Starts der Baseline aktiv sind. Der Befehl schlägt fehl, wenn Sie versuchen, die Buchhaltung fortzusetzen, während das Baselining noch ausgeführt wird.

• Sie können die Befehle nicht verwenden, um die Abrechnung während eines einheitlichen ISSU-Prozesses anzuhalten, zu optimieren oder fortzusetzen. Wenn Sie versuchen, eine vereinheitlichte ISSU durchzuführen, während die Baseline ausgeführt wird, und sich der Zustand des Chassis-Daemons in den DAEMON_ISSU_PREPARE-Zustand ändert, unterbrechen die Authentifizierung- und Packet Forwarding Engine-Prozesse das Baselining an einer Sitzungsgrenze und setzen sie nach dem Routing-Engine-Switchover auf die Version fort, auf die das Gerät aktualisiert wird.

• Wenn ein Graceful Routing-Engine-Switchover (GRES) auftritt, während die Buchhaltung angehalten ist oder Baselining ausgeführt wird, wird der Status der Ansetzung oder des Baselinings nach dem Neustart des Routers beibehalten. In einem solchen Szenario wird die Abrechnung nach dem Neustart des Routers angehalten, und die Abonnenten, für die noch Zähler erstellt werden müssen, erhalten eine Baseline, nachdem der Router online ist.

Beispielszenarien für die Aussetzung und das Baselining der Abonnentenbuchhaltung

Stellen Sie sich folgendes Szenario vor:

1. Die Zwischenabrechnung ist für Anwender X konfiguriert. Sie ist nicht für die Abonnenten Y und Z konfiguriert.

2. Der letzte vor der Aussetzung der Rechnungslegung gesendete Antrag auf vorläufige Buchhaltung enthält Statistiken für Anwender X; 50.000 Oktette Datenverkehr wurden bisher für diesen Anwender gesendet. Obwohl 20.000 Oktette für Anwender Y und 10.000 Oktette für Anwender Z gesendet wurden, wurden diese Informationen noch nicht gemeldet, da sie keine vorläufige Buchhaltung konfiguriert haben.

3. Die Buchhaltung wird ausgesetzt.

4. Das Baselining beginnt. Die aktuelle Anzahl für Anwender X beträgt 50.000 Oktette. Dies wird zum Basiswert für den Anwender. Für die Abonnenten X und Y wird kein Basiswert festgelegt, da für sie keine Zwischenabrechnung konfiguriert ist.

5. Während das Baselining ausgeführt wird, wird weiterhin Datenverkehr für die drei Abonnenten gesendet: 150.000 Oktette für Anwender X, 80.000 Oktette für Anwender Y und 20.000 Oktette für Anwender Z.

6. Teilnehmer Z meldet sich ab. Es wird keine Acct-Stop-Anforderung gesendet, da die Buchhaltung ausgesetzt ist. Folglich gehen die endgültigen Buchhaltungsstatistiken für diesen Anwender verloren.

7. Das Baselining ist abgeschlossen.

8. Die Buchhaltung nimmt ihre Arbeit wieder auf.

9. Teilnehmer X meldet sich ab. Obwohl insgesamt 200.000 Oktette für Anwender X gesendet wurden, meldet der Acct-Stop-Datensatz nur 150.000 Oktette: 200.000 Oktette insgesamt abzüglich der 50.000 Oktett-Basislinie.

10. Teilnehmer Y meldet sich ab. Da insgesamt 100.000 Oktette für Anwender Y gesendet wurden und kein Basiswert vorhanden ist, meldet der Acct-Stop-Datensatz die Gesamtzahl von 100.000 Oktetten.

Tabelle 7 fasst dieses Szenario zusammen.