L2TP Anwenderzugriffsleitungen und Verbindungsgeschwindigkeiten

Weiterleitung von Informationen über die Zugriffsleitung

Wenn in der in Abbildung 1 dargestellten Netzwerktopologie ein Anwender eine Verbindung über das CPE initiiert, leitet der DSLAM die PPPoE-Sitzung des Anwenders an den als LAC konfigurierten Router weiter. Wenn der Router die PPPoE-Sitzung eingerichtet hat, initiiert der LAC einen L2TP-Tunnel, um die gekapselten PPP-Pakete des Anwenders an das Provider-Netzwerk weiterzuleiten.

Parallel zur PPPoE-Sitzung übermittelt eine ANCP-Verbindung zwischen dem DSLAM und dem ANCP-Agenten auf dem Router Informationen über die lokale Schleife des Anwenders sowie die Verbindungsgeschwindigkeiten der PPPoE-Sitzungen auf der lokalen Schleife. Der DSLAM sendet dem Router Agent Circuit Id (ACI) und Agent Remote Id (ARI) Zeichenfolgen, die die Empfangsschnittstelle des DSLAM eindeutig identifizieren. Diese Informationen werden in den ANCP-Port-Up- und Port-Down-Nachrichten als Access Line Identifying TLVs codiert. Die ANCP-Nachrichten können auch Leitungsattribute wie minimale, maximale und tatsächliche Netto-Upstream- und Downstream-Datenraten in der DSL-Leitungsattribute TLV enthalten. Der DSLAM kann die Zugriffsleitungsattribute auch in anbieterspezifischen Tags senden, die er in die PADI- und PADR-Nachrichten einfügt.

Abbildung 1: Beispiel für eine L2TP-Netzwerktopologie

Access Line Information AVPs

L2TP unterstützt die in Tabelle 1 aufgeführten AVPs, um diese Informationen zu übertragen. Die Informationen der Zugriffsleitung sind für die Initiierung der L2TP-Sitzung nicht erforderlich, und der Aufbau dieser Sitzung wird nicht verzögert, indem auf das Senden der Werte vom Zugriffsknoten gewartet wird. Der Inhalt der ICRQ-Nachricht variiert im Allgemeinen zwischen DSL-Zugangsleitungen und PON-Zugriffsleitungen. Die AVPs 1, 2, 3 und 6 werden zur Identifizierung der Zugriffsleitung sowohl für DSL als auch für PON verwendet. Wenn PON-Informationen über DSL-AVPs gemeldet werden, ist der Inhalt derselbe wie beim DSL-Zugriff.

Die von den AVPs in ICRQ-Nachrichten bereitgestellten Access-Line-Informationen werden in DSL Forum VSAs an RADIUS weitergeleitet. Es wird nicht zur Gestaltung der Datenverkehrsrate auf den Zugriffsleitungen der Anwender verwendet.

Updates der Verbindungsgeschwindigkeit in der LAC

Sie können die LAC so konfigurieren, dass das LNS benachrichtigt wird, wenn sich die Geschwindigkeit der Anwender Verbindung von den Werten ändert, die ursprünglich von AVP 24 (Übertragungsgeschwindigkeit) und AVP 38 (Empfangsgeschwindigkeit) in ICCN-Nachrichten (Incoming-Call-Connected) an das LNS übermittelt wurden. Wenn dies konfiguriert ist, informiert die LAC das LNS, dass es diese Updates senden kann, indem es die Connect Speed Update Enable AVP (98) in die ICRQ-Nachricht einschließt, wenn die L2TP-Sitzung gestartet wird. Das Fehlen der Option Connect Speed Update Enable AVP (98) in der ICRQ-Nachricht weist darauf hin, dass die LAC während der gesamten Sitzung keine Updates sendet.

Wenn sich die Verbindungsgeschwindigkeit ändert, benachrichtigt der DSLAM den ANCP-Agenten. Der ANCP-Agent benachrichtigt dann den LAC, und der LAC wiederum leitet diese Informationen an das LNS weiter, indem er eine Connect-Speed-Update-Notification (CSUN)-Nachricht sendet, die die aktualisierten Geschwindigkeiten in einem Connect Speed Update AVP (97) für jede Sitzung enthält. Der LAC sammelt Aktualisierungen der Verbindungsgeschwindigkeit und sendet sie in einem Batch, um sowohl den Performance-Overhead auf dem LAC als auch die Menge des durch diese Benachrichtigungen generierten Datenverkehrs zu minimieren.

Die Anfangsgeschwindigkeiten in den ICCN-Nachrichten und die aktualisierten Geschwindigkeiten in CSUN-Nachrichten werden von CoS verwendet, um die Datenverkehrsrate für die Zugriffsleitungen der Anwender zu gestalten.

Das Vorhandensein des Connect Speed Update Enable AVP (98) in der ICRQ-Nachricht informiert das LNS auch darüber, dass die LAC antwortet, wenn es eine Connect-Speed-Update-Request (CSURQ)-Nachricht von einem LNS empfängt.

Ein LNS eines Drittanbieters kann jederzeit während der Lebensdauer eines Tunnels eine CSURQ-Nachricht senden, um die aktuelle Sende- und Empfangsverbindungsgeschwindigkeit für eine oder mehrere L2TP-Sitzungen anzufordern. Der LNS schließt die Remote-Sitzungs-IDs (relativ zum LNS) in die CSURQ-Nachricht ein. Wenn die LAC zuvor das Connect Speed Update Enable AVP (98) für die angeforderten Sitzungen gesendet hat, antwortet sie auf die CSURQ mit einer CSUN-Nachricht, die das Connect Speed Update AVP (97) für jede Sitzung enthält. Wenn bis zu diesem Zeitpunkt keine Änderungen an den Verbindungsgeschwindigkeiten aufgetreten sind, enthält die LAC einfach die anfänglichen Werte für die Verbindungsgeschwindigkeit, die in AVP 24 und AVP 38 gemeldet wurden.

Wenn Sie Aktualisierungen der Verbindungsgeschwindigkeit entweder global oder für ein bestimmtes LNS aktivieren, sendet die LAC keine CSUN-Nachrichten, es sei denn, Sie haben die tx-connect-speed Anweisung auch als entweder ancp oder konfiguriert service-profile.

Updates der Verbindungsgeschwindigkeit im LNS

Ab Junos OS Version 17.4R1 kann ein als LNS konfigurierter Router der MX-Serie Informationen über die Zugriffsleitung von Anwendern und Aktualisierungen der Verbindungsgeschwindigkeit verarbeiten, die er von der LAC erhält. Der Router der MX-Serie kann keine CSURQ-Nachrichten senden, um Updates von der LAC anzufordern.

Die Anfangsgeschwindigkeiten in den ICCN-Nachrichten und die aktualisierten Geschwindigkeiten in CSUN-Nachrichten werden von CoS verwendet, um die Datenverkehrsrate für die Zugriffsleitungen der Anwender zu gestalten.

Interaktion zwischen globalen und Zielkonfigurationen

Sie können die LAC so konfigurieren, dass die Informationen der Zugriffsleitung in der ICRQ-Nachricht, die sie an das LNS sendet, weitergeleitet werden, und Sie können das LNS so konfigurieren, dass es diese Informationen empfängt und verarbeitet. Sie können dies global für alle Ziele (Endpunkte) oder für ein bestimmtes Ziel konfigurieren. Mit der Konfiguration pro Ziel können Sie die Übertragung an ein einzelnes LNS oder auf eine Reihe von LNS oder den Empfang von einer einzelnen LAC oder einer Gruppe von LACs einschränken. Dies ist nützlich, wenn Sie wissen, dass einige Remote-Gateways diese Funktion nicht unterstützen oder eine falsche Implementierung aufweisen.

Fügen Sie die access-line-information Anweisung auf einer oder beiden der folgenden Hierarchieebenen in die LAC bzw. LNS ein, um die LAC so zu konfigurieren, dass die Informationen der Zugriffsleitung in der ICRQ-Nachricht, die sie an das LNS sendet, weitergeleitet werden, oder um das LNS so zu konfigurieren, dass es diese Informationen empfängt und verarbeitet:

• [edit services l2tp]– Konfiguriert die globale Weiterleitung für alle Ziele.

• [edit services l2tp destination ip-address]– Konfiguriert die Weiterleitung für ein bestimmtes Ziel.

Um die LAC zum Senden von Aktualisierungen der Verbindungsgeschwindigkeit oder das LNS zum Empfangen und Verarbeiten der Aktualisierungen zu konfigurieren, fügen Sie die connection-speed-update Option mit der access-line-information Anweisung auf der entsprechenden Hierarchieebene in der LAC bzw. LNS ein.

Die globalen und die Einstellungen pro Ziel interagieren auf folgende Weise:

• Informationen zur Zugriffsleitung: Wenn die Weiterleitung durch die LAC oder die Verarbeitung durch das LNS global aktiviert ist, können Sie die globale Einstellung für ein bestimmtes Ziel nicht deaktivieren.

• Aktualisierungen der Verbindungsgeschwindigkeit – Wenn die Weiterleitung durch die LAC oder die Verarbeitung durch das LNS global aktiviert ist, können Sie die globale Einstellung für eine bestimmte Destination (LNS oder LAC) deaktivieren, indem Sie für das Ziel angeben access-line-information und weglassen connection-speed-update.

Methoden zur Ermittlung der an das LNS gemeldeten Geschwindigkeitswerte

Die an das LNS gemeldeten Werte können auf folgende Weise abgeleitet werden:

• Sie können eine Methode global für die LAC mit der tx-connect-speed-method Anweisung auf Hierarchieebene [edit services l2tp] konfigurieren. Sie können eine der folgenden Methoden angeben, um die Quelle für Verbindungsgeschwindigkeiten zu bestimmen:

  Hinweis:

  Ab Junos OS Version 13.3R1 variieren Verfügbarkeit und Unterstützung für Methoden je nach Junos OS-Version, wie in Tabelle 2 beschrieben. Die folgende Liste enthält alle historischen Methoden; Einige der Methoden werden in der von Ihnen verwendeten Softwareversion möglicherweise nicht unterstützt.

  • actual– Die Geschwindigkeit ist die tatsächliche Rate des Downstream-Datenverkehrs, der am Sitzungsplaner-Knoten basierend auf der lokalen Datenverkehrssteuerungsrichtlinie erzwungen wird. Bei dieser Methode ist nur die Übertragungsverbindungsgeschwindigkeit verfügbar, sodass die Empfangsübertragungsgeschwindigkeit durch das Fallbackschema bestimmt wird. Verwenden Sie die actual Methode, wenn der gemeldete Wert die Downstream-Geschwindigkeit sein soll, die von der lokalen CoS-Richtlinie erzwungen wird. Andere Methoden können von diesem erzwungenen Wert abweichen.

    Die actual Methode wird nur unterstützt, wenn die effective shaping-rate Anweisung auf Hierarchieebene [edit chassis] enthalten ist. Die CLI-Commit-Prüfung schlägt fehl, wenn actual sie konfiguriert ist, aber die effektive Shaping-Rate nicht konfiguriert ist.

    Wenn die Tunnel-Tx-Speed-Methode VSA (26-94) eingestellt ist, wird keine Commit-Prüfung durchgeführt, so dass in dieser Situation eine Systemprotokollmeldung erzeugt wird, die den Benutzer daran erinnert, die effektive Shaping-Rate zu konfigurieren.

  • ancp– Die Geschwindigkeit ist der angepasste ANCP-basierte Upstream- und Downstream-Wert, der sich aus einer konfigurierten prozentualen Korrektur der tatsächlichen ANCP-Werte ergibt. Die Anpassung wird pro DSL vorgenommen, um die Unterschiede in der ATM-Verkapselung zwischen der BNG und der Access-Loop sowie den Layer-1-Transport-Overhead zu berücksichtigen. Die anfängliche Rate, die an das LNS gesendet wird, ist der ANCP-Wert, der zum Zeitpunkt des Sendens des ICCN gemeldet wird. Alle nachfolgenden Änderungen werden als Aktualisierungen an das LNS in der CSUN-Nachricht gesendet.

  • none—Diese Option verhindert, dass die LAC entweder AVP 24 oder AVP 38 in der ICCN-Nachricht sendet; folglich werden auch keine CSUN-Nachrichten gesendet. Das LNS muss seine eigene Upstream- und Downstream-Politik festlegen, wenn diese Werte fehlen. Diese Option überschreibt die Juniper Networks RADIUS VSAs, Tx-Connect-Speed (26-162) und Rx-Connect-Speed (26-163) sowie alle anderen für die Verbindungsgeschwindigkeit konfigurierten Methoden.

  • pppoe-ia-tags– Die Geschwindigkeit wird aus dem Wert abgeleitet, der vom DSLAM an die LAC in den Point-to-Point Protocol over Ethernet (PPPoE) Intermediate Agent (IA)-Tags gesendet wird. Bei Ethernet-Schnittstellen ist die Geschwindigkeit ein nicht angepasster Wert; Bei ATM-Schnittstellen kann der Wert ein angepasster Wert sein, wenn das Tag das Attribut Encapsulation Overhead (0x90) enthält.

    Dieser Geschwindigkeitswert wird übertragen, wenn die L2TP-Sitzung aufgebaut wird. Obwohl sich der PPPoe IA-Tag-Wert während einer Sitzung nicht ändert, kann sich die an den LAC gemeldete Geschwindigkeit ändern. Angenommen, die konfigurierte Methode ist service-profile. Das Profil wird erst aktiviert, wenn der ICCN gesendet wird, und greift auf das PPPoE IA-Tag zurück, das in der ICCN-Nachricht gesendet wird. Wenn das Serviceprofil später aktiviert wird, werden die Serviceprofiltarife in einer Update-Nachricht gesendet (falls Updates konfiguriert sind).

  • service-profile– Abhängig von Ihrer Version von Junos OS gibt es zwei Möglichkeiten, Serviceprofile zum Bereitstellen von Verbindungsgeschwindigkeiten zu verwenden. Eine Methode verwendet die Geschwindigkeiten aus dem Dienstprofil nur in CSUN-Nachrichten, die andere Methode in ICCN-Nachrichten.

    • In CSUN-Nachrichten: Die Downstream-Geschwindigkeit (Tx) wird vom tatsächlichen CoS abgeleitet, der auf dem L3-Knoten basierend auf lokalen Richtlinien erzwungen wird. Die Upstream-Geschwindigkeit (Rx) wird aus dem konfigurierten Wert im Dienstprofil übernommen. Es wird keine Anpassung an diesen Wert vorgenommen.

      Standardmäßig werden Serviceprofile nicht aktiviert, bevor die Anwender Sitzung eingerichtet ist, sodass diese Methode auf eine andere Methode für die im ICCN gesendeten Werte zurückgreift. Wenn das Profil später aktiviert wird, werden diese Tarife in einer CSUN-Nachricht an das LNS gesendet, wenn Aktualisierungen aktiviert sind.

    • In ICCN-Nachrichten: Ab Junos OS Version 18.1R1 können Sie ein dynamisches Serviceprofil verwenden, um die in AVP 38 und AVP 24 enthaltenen Verbindungsgeschwindigkeiten in der ICCN-Nachricht bereitzustellen, wenn die L2TP-Sitzung ausgehandelt wird. Bei der Anmeldung des Anwenders ermittelt authd, ob der Dienstprofilname, der in der Juniper Networks Activate-Service VSA (26-65) in der RADIUS Access-Accept-Nachricht übermittelt wird, mit dem Dienstprofilnamen übereinstimmt, der mit der service-rate-limiter Anweisung auf Hierarchieebene [edit access] konfiguriert ist. Wenn die Namen übereinstimmen, werden die Geschwindigkeiten entweder aus den Standardwerten im Serviceprofil oder aus den vom VSA übergebenen Parametern abgeleitet. Weitere Informationen zu dieser Methode finden Sie unter Angeben eines Serviceprofils zur Ratenbegrenzung für L2TP-Verbindungsgeschwindigkeiten .

    Die service-profile Methode wird nur unterstützt, wenn die effective shaping-rate Anweisung auf Hierarchieebene [edit chassis] enthalten ist. Die CLI-Commit-Prüfung schlägt fehl, wenn service-profile sie konfiguriert ist, aber die effektive Shaping-Rate nicht konfiguriert ist.

    Wenn die Tunnel-Tx-Speed-Methode VSA (26-94) eingestellt ist, wird keine Commit-Prüfung durchgeführt, so dass in dieser Situation eine Systemprotokollmeldung erzeugt wird, die den Benutzer daran erinnert, die effektive Shaping-Rate zu konfigurieren.

    Optimale Vorgehensweise:

    Es wird empfohlen, nur ein Dienstprofil pro Anwendersitzung zu verwenden, um die Downstream-Shaping-Rate zu beeinflussen oder eine Upstream-Rate zu melden. Wenn mehr als ein dynamisches Serviceprofil auf die Anwender-Sitzung angewendet wird, sodass sich jedes auf die Downstream-Shaping-Rate auswirkt oder die Upstream-Rate meldet, werden die Werte des zuletzt angewendeten Profils von L2TP gemeldet. Die Deaktivierung des zuletzt angewendeten Services führt nicht dazu, dass L2TP die Upstream-Geschwindigkeit für ein vorhandenes (aktives) Serviceprofil meldet.

  • static– Diese Methode bewirkt, dass die LAC die Geschwindigkeit von der konfigurierten statischen Layer-2-Geschwindigkeit ableitet. Für Ethernet-VLANs ist dies die empfohlene (beratende) Shaping-Rate, die auf der logischen PPPoE-Schnittstelle konfiguriert ist, die der Anwender-Schnittstelle zugrunde liegt. Wenn die Advisory Shaping-Rate nicht auf der zugrunde liegenden Schnittstelle konfiguriert ist, wird die tatsächliche Geschwindigkeit des zugrunde liegenden physischen Ports verwendet.

• Ab Junos OS Version 15.1R1 können Sie die Geschwindigkeitswerte Tx-Connect-Speed (26-162) und Rx-Connect-Speed (26-163) direkt in den Juniper Networks VSAs konfigurieren. Diese VSAs können in der RADIUS Access-Accept-Nachricht zurückgegeben werden. Wenn nur einer der VSAs vorhanden ist, verwendet der LAC eine Verbindungsgeschwindigkeitsmethode, um den Wert für die andere Geschwindigkeit zu bestimmen. Um diese VSAs verwenden zu können, müssen Sie RADIUS gemäß der Dokumentation des RADIUS-Servers konfigurieren.

• Ab Junos OS Version 15.1R1 können Sie eine Methode konfigurieren, die in der VSA von Juniper Networks übertragen wird, Tunnel-Tx-Speed-Method (26-94). Wenn konfiguriert, wird dieser VSA in der RADIUS Access-Accept-Nachricht für einzelne Abonnenten zurückgegeben. Der VSA-Wert gilt global und nicht für einen bestimmten Tunnel. Die in dieser VSA konfigurierte Methode gibt die Ressource an, die die LAC zum Festlegen der Geschwindigkeit verwendet. Um diese VSA verwenden zu können, müssen Sie RADIUS gemäß der Dokumentation des RADIUS-Servers konfigurieren.

• Wenn die Geschwindigkeiten nicht auf andere Weise bestimmt werden können, wird die Portgeschwindigkeit der Anwender-Schnittstelle verwendet.

Tabelle 2 listet die verfügbaren Methoden nach Release auf.

In den Junos OS-Versionen 15.1, 16.1, 16.2 und 17.1 (die die actual Methode unterstützen) sind die Geschwindigkeitswerte in AVP 24 und AVP 38 in der Regel nicht größer als der Wert, der von CoS auf der LAC-Seite des Netzwerks erzwungen wird. Jeder Unterschied zwischen der in diesen AVPs gemeldeten Geschwindigkeit und der von CoS erzwungenen Geschwindigkeit ist auf Unterschiede zwischen der CoS-Konfiguration (der Quelle, die zur Erzwingung einer Downstream-Geschwindigkeit verwendet wird) und der Tx-Verbindungsgeschwindigkeitsmethode zurückzuführen, die zum Einrichten dieser AVPs verwendet wird.

Bestimmen der anfänglichen Verbindungsgeschwindigkeiten

Bevor die LAC die ersten Sende- und Empfangsverbindungsgeschwindigkeiten in der ICCN-Nachricht an das LNS senden kann, muss sie Folgendes tun:

1. Wählen Sie die Methode aus, mit der die Geschwindigkeiten abgeleitet werden.

2. Bestimmen Sie die Geschwindigkeiten.

Der LAC wählt die Methode wie folgt aus:

1. Wenn die Tunnel-Tx-Speed-Methode VSA (26-94) vorhanden ist, verwenden Sie die durch den VSA-Wert angegebene Methode.

2. Andernfalls verwenden Sie die in der CLI konfigurierte Methode mit der tx-connect-speed-method Anweisung.

Die LAC bestimmt die Anfangsgeschwindigkeit wie folgt:

1. Wenn die ausgewählte Methode ist none, bezieht die LAC die Sende- und Empfangsgeschwindigkeiten nicht in das ICCN ein.

2. Wenn bei jeder anderen ausgewählten Methode die Werte in den VSAs "Tx-Connect-Speed" (26-162) und "Rx-Connect-Speed" (26-163) ungleich Null sind, sendet der LAC diese Werte im ICCN.

3. Wenn die VSA-Werte Null sind, verwenden Sie die ausgewählte Methode, um die zu sendenden Werte abzuleiten.

Betrachten Sie die folgenden Beispiele:

• VSA 26-94 wird mit ancp konfiguriert als Methode empfangen. Die CLI-Methode ist als nonekonfiguriert. Die LAC wählt den VSA 26-94-Wert, die ancp Methode.

  VSA 26-162 und VSA 26-163 werden mit Werten ungleich Null empfangen. Die LAC sendet diese VSA-Werte im ICCN.

• VSA 26-94 wird mit ancp konfiguriert als Methode empfangen. Die CLI-Methode ist als nonekonfiguriert. Die LAC wählt den VSA 26-94-Wert, die ancp Methode.

  VSA 26-162 und VSA 26-163 werden mit Nullwerten empfangen. Die LAC verwendet die ancp Methode, um die Werte abzuleiten, die in die ICCN gesendet werden sollen.

• VSA 26-94 wird mit none konfiguriert als Methode empfangen. Die CLI-Methode ist als ancpkonfiguriert. Der LAC wählt den VSA 26-94-Wert noneaus und sendet keine Verbindungsgeschwindigkeiten im ICCN.

• VSA 26-94 ist nicht eingegangen. Die CLI-Methode ist als nonekonfiguriert. Die LAC sendet keine Verbindungsgeschwindigkeiten im ICCN.

Fallback-Mechanismus für Werte für Verbindungsgeschwindigkeit

Wenn der LAC eine Methode zum Ableiten der Verbindungsgeschwindigkeiten ausgewählt hat, greift er unter den folgenden Umständen auf eine andere Methode zurück:

• Einer oder beide Werte für die Verbindungsgeschwindigkeit wurden nicht durch die ausgewählte Methode (VSA 26-94 oder die CLI) festgelegt.

• Der Wert für die Verbindungsgeschwindigkeit ist Null.

Wenn ein Wert verfügbar und ungleich Null ist, der andere jedoch nicht, wird nur der nicht festgelegte Wert auf eine andere Methode zurückgesetzt. Es gibt keinen Fallback, wenn die ausgewählte Methode ist none, da diese Methode verhindert, dass die LAC die Verbindungsgeschwindigkeiten meldet. Das Fallback-Verfahren kann je nach Version von Junos OS variieren.

Betrachten Sie die folgenden Beispiele:

• Die ausgewählte Methode ist ANCP. Der ANCP-Wert für die Empfangsgeschwindigkeit ist Null. Die LAC sendet den ANCP-Wert für die Übertragungsgeschwindigkeit, aber der Empfangswert fällt auf die PPPoE IA-Tag-Methode zurück. Der LAC sendet den IA-Tag-Wert für die Empfangsgeschwindigkeit.

• Die ausgewählte Methode ist ANCP. Der ANCP-Wert für die Empfangsgeschwindigkeit ist Null. Die LAC sendet den ANCP-Wert für die Übertragungsgeschwindigkeit, aber der Empfangswert fällt auf die PPPoE IA-Tag-Methode zurück. Der IA-Tag-Wert für die Empfangsgeschwindigkeit ist ebenfalls Null, sodass auf die statische Layer-2-Methode zurückgegriffen wird. Dies ist verfügbar, sodass der LAC den statischen Layer-2-Wert für die Empfangsgeschwindigkeit sendet.

• Die ausgewählte Methode ist das Serviceprofil. Das Serviceprofil wird erst aktiviert, bevor die ICCN gesendet wird, sodass die LAC auf die ANCP-Methode zurückgreift. Sowohl Sende- als auch Empfangs-ANCP-Werte sind verfügbar und ungleich Null, sodass die LAC diese Werte im ICCN sendet.

  Das Serviceprofil wird durch eine Autorisierungsänderung (Change of Authorization, CoA) zu einem späteren Zeitpunkt für die Sitzung aktiviert. Wenn Updates aktiviert sind, sendet der LAC die Serviceprofilwerte in einer CSUN-Nachricht an das LNS. Wenn Updates nicht aktiviert sind, werden die Serviceprofilwerte nicht an das LNS gemeldet.

  Beachten Sie, dass Updates erfordern, dass die Methode in der CLI konfiguriert wird. Folglich darf VSA 26-94 nicht konfiguriert oder empfangen werden, sodass die Dienstprofilmethode aus der CLI-Konfiguration ausgewählt wird.

Ab Junos OS Version 17.2R1 ist das LAC-Fallback-Verfahren wie in Tabelle 3 beschrieben.

Ab Junos OS Version 15.1R1 ist das LAC-Fallback-Verfahren wie in Tabelle 4 beschrieben.

Ab Junos OS Version 13.3R1 ist das LAC-Fallbackverfahren wie in Tabelle 5 beschrieben.