AUF DIESER SEITE
Handhabung von Teilnehmerzugangsleitungen durch das LAC und LNS Übersicht
Übertragung von Tx- und Rx-Verbindungsgeschwindigkeiten von LAC zu LNS
Konfigurieren der Methode zum Ableiten der an das LNS gesendeten LAC-Verbindungsgeschwindigkeiten
Konfigurieren der Berichterstellung und Verarbeitung von Teilnehmerzugangsleitungsinformationen
Verhindern, dass die LAC die Rufnummer AVP 22 an das LNS sendet
Überschreiben Sie das Calling-Station-ID-Format für die AVP der anrufenden Nummer
Festlegen eines ratenbegrenzenden Dienstprofils für L2TP-Verbindungsgeschwindigkeiten
L2TP-Teilnehmerzugangsleitungen und Verbindungsgeschwindigkeiten
Handhabung von Teilnehmerzugangsleitungen durch das LAC und LNS Übersicht
Ab Junos OS Version 14.1 unterstützt L2TP eine Reihe von AVPs, die Informationen über Teilnehmerzugriffsleitungen vom LAC zum LNS übermitteln. Die Informationen stammen von einem ANCP-Zugriffsknoten (DSLAM) und werden entweder über DSL-Forum-VSAs in ANCP-Nachrichten oder über PPPoE-Intermediate Agent-Tags, die in den PPPoE-PADI- und PADR-Nachrichten enthalten sind, an die LAC verteilt. Bei dem Zugriffsknoten handelt es sich in der Regel um einen DSLAM für DSL-Zugriffsnetzwerke oder, ab Junos OS Version 19.3R1, um einen ONT/ONU für PON-Zugriffsnetzwerke. Weitere Informationen zu DSL-Forum-VSAs und L2TP-AVPs finden Sie in den folgenden Referenzen:
RFC 4679, DSL-Forum Herstellerspezifische RADIUS-Attribute
RFC 5515, Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions
RFC 6320, Protokoll für Access Node Control Mechanism in Breitbandnetzwerken
RFC 6320 Draft Extension, Access Extensions für das Access Node Control Protocol
Technischer Bericht des Breitbandforums TR-101, Migration to Ethernet-Based Broadband Aggregation (Migration zu Ethernet-basierter Breitbandaggregation)
- Weiterleitung von Zugangsleitungsinformationen
- Informationen zu Access Line AVPs
- Aktualisierungen der Verbindungsgeschwindigkeit auf der LAC
- Aktualisierungen der Verbindungsgeschwindigkeit auf dem LNS
- Interaktion zwischen globalen und zielspezifischen Konfigurationen
Weiterleitung von Zugangsleitungsinformationen
Wenn in der in Abbildung 1 dargestellten Netzwerktopologie ein Teilnehmer eine Verbindung über das CPE initiiert, leitet der DSLAM die PPPoE-Sitzung des Teilnehmers an den als LAC konfigurierten Router weiter. Wenn der Router die PPPoE-Sitzung aufgebaut hat, initiiert der LAC einen L2TP-Tunnel, um die gekapselten PPP-Pakete des Teilnehmers 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 Teilnehmer-Teilnehmer-Teilnehmeranschlussleitung sowie die Verbindungsgeschwindigkeiten der PPPoE-Sitzungen auf der Teilnehmeranschlussleitung. Der DSLAM sendet dem Router Zeichenfolgen Agent Circuit Id (ACI) und Agent Remote Id (ARI), 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 im DSL-Leitungsattribute-TLV enthalten. Der DSLAM kann die Attribute der Zugriffsleitung auch in herstellerspezifischen Tags senden, die er in die PADI- und PADR-Nachrichten einfügt.
Ab Junos OS Version 19.3R1 werden in demselben Szenario zusätzlich zu den zuvor unterstützten DSL-Zugriffsknoten die Zugriffsknoten für PON-Teilnehmerzugriffsleitungen (z. B. ONTs und ONUs) unterstützt.

Informationen zu Access Line AVPs
L2TP unterstützt die in Tabelle 1 aufgeführten AVPs, um diese Informationen zu übertragen. Die Zugriffsleitungsinformationen sind für die Initiierung der L2TP-Sitzung nicht erforderlich, und der Aufbau dieser Sitzung wird nicht verzögert, indem darauf gewartet wird, dass die Werte vom Zugriffsknoten gesendet werden. Der Inhalt der ICRQ-Nachricht variiert im Allgemeinen zwischen DSL-Zugangsleitungen und PON-Zugangsleitungen. Die AVPs 1, 2, 3 und 6 werden für die Zugriffsleitungsidentifikation 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 Zugangsleitungsinformationen werden an RADIUS in DSL-Forum-VSAs weitergeleitet. Sie wird nicht für die Gestaltung der Datenverkehrsrate auf den Teilnehmerzugangsleitungen verwendet.
L2TP AVP-Typ L2TP AVP-Name |
Beschreibung |
L2TP-Nachrichtentyp Access Line Support |
KorrespondierendesDSL-Forum VSA |
---|---|---|---|
1 Agent-Circuit-ID |
Bezeichner für die Abonnenten-Agent-Verbindungs-ID (Subscriber Agent Circuit ID, ACI), die der Zugriffsknotenschnittstelle entspricht, von der aus Abonnentenanforderungen initiiert werden. 2-63 Oktett Saite |
IKRK DSL, PON |
26-3561-1 |
2 Agent-Remote-ID |
Eindeutiger Bezeichner für den Abonnenten, der der Zugriffsknotenschnittstelle zugeordnet ist, von der aus Anforderungen initiiert werden. 2-63 Oktett Saite |
IKRK DSL, PON |
26-3561-2 |
3 Zugriffs-Aggregation-Schaltkreis-ID-ASCII |
ASCII-Kennung für die Teilnehmerzugangsleitung, basierend auf ihrem logischen Erscheinungsbild zum Netzwerk Wenn die Zeichenfolge mit einem #-Zeichen beginnt, stellt der Rest der Zeichenfolge einen logischen Zwischenknoten (DPU-C oder PON-Struktur) in dem Zugriffsnetzwerk dar, mit dem der Teilnehmer verbunden ist. Die Zeichenfolge wird als Name eines CoS Level 2-Schnittstellensatzes verwendet, der Abonnenten gruppiert. |
IKRK DSL, PON |
26–3561-3 |
6 Zugriffs-Aggregation-Schaltkreis-ID-Binärdatei |
Binärer Bezeichner für die Teilnehmerzugangsleitung 32-Bit- oder 64-Bit-Zeichenfolge |
IKRK DSL, PON |
26–3561-6 |
97 Connect-Speed-Update |
Datenstruktur, die die Remote-Sitzungs-ID und die aktuellen Sende- und Empfangsgeschwindigkeiten in Bit pro Sekunde auflistet. |
CSUN, CSURQ |
(keine) |
98 Connect-Speed-Update-Enable |
Wert spielt keine Rolle: Präsenz gibt Unterstützung für CSUN- und CSURQ-Nachrichtentypen für diese Sitzung an. |
IKRK |
(keine) |
129 Ist-Datenrate-Upstream |
Tatsächliche Upstream-Datenrate der synchronisierten DSL-Verbindung des Teilnehmers, in Bps 64-Bit-Ganzzahl ohne Vorzeichen; Datenrate in Bit pro Sekunde |
IKRK DSL |
26-3561-129 |
130 Ist-Datenrate-Downstream |
Tatsächliche Downstream-Datenrate der synchronisierten DSL-Verbindung des Teilnehmers, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-130 |
131 Minimum-Data-Rate-Upstream |
Für den Abonnenten konfigurierte minimale Upstream-Datenrate in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-131 |
132 Minimum-Data-Rate-Downstream |
Für den Abonnenten konfigurierte minimale Downstream-Datenrate in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-132 |
133 Erreichbare-Datenrate-Upstream |
Upstream-Datenrate, die der Teilnehmer erreichen kann, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-133 |
134 Erreichbare-Datenrate-Downstream |
Downstream-Datenrate, die der Teilnehmer erreichen kann, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-134 |
135 Maximum-Data-Rate-Upstream |
Maximale für den Abonnenten konfigurierte Upstream-Datenrate in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-135 |
136 Maximum-Data-Rate-Downstream |
Maximale für den Teilnehmer konfigurierte Downstream-Datenrate in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-136 |
137 Minimale-Datenrate-Upstream-Low-Power |
Minimale Upstream-Datenrate im Energiesparzustand, konfiguriert für den Abonnenten, in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-137 |
138 Minimale-Datenrate-Downstream-Low-Power |
Minimale Downstream-Datenrate im Energiesparzustand, konfiguriert für den Teilnehmer, in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-138 |
139 Maximum-Interleaving-Delay-Upstream |
Maximale für den Teilnehmer konfigurierte einseitige Upstream-Interleaving-Verzögerung in Millisekunden 32-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-139 |
140 Actual-Interleaving-Delay-Upstream |
Tatsächliche einseitige Upstream-Interleaving-Verzögerung des Teilnehmers in Millisekunden 32-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-140 |
141 Maximum-Interleaving-Delay-Downstream |
Maximale für den Teilnehmer konfigurierte einseitige Downstream-Interleaving-Verzögerung in Millisekunden 32-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-141 |
142 Ist-Interleaving-Verzögerung-Downstream |
Tatsächliche einseitige Downstream-Interleaving-Verzögerung des Teilnehmers in Millisekunden 32-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL |
26-3561-142 |
144 Access-Loop-Kapselung |
Kapselung, die von dem Abonnenten verwendet wird, der der Zugriffsknotenschnittstelle zugeordnet ist, von der aus Anforderungen initiiert werden Drei Ein-Oktett-Codierungen für Datenverbindung, Kapselung 1 und Kapselung 2. |
IKRK DSL |
26-3561-144 |
145 ANCP-Zugriffsleitungstyp (Dies entspricht der ANCP DSL-Type TLV.) |
Ein Oktett für den Übertragungssystemtyp, gefolgt von drei MBZ-Oktetten (muss null sein) (insgesamt 4 Byte). Dieser Wert wird im ICRQ nicht angegeben, wenn die Zugangsleitungsparameter aus PPPoE-IA stammen, da die ANCP-bezogenen Informationen möglicherweise nicht sofort verfügbar sind. Ab Junos OS Version 18.1R1 ist dieses AVP auch dann enthalten, wenn der Leitungstyp für ANDERE Zugriffsleitungstypen 0 ist. |
IKRK DSL |
26-3561-145 |
146 PON-Zugriffs-Typ |
Art der verwendeten PON-Zugangsleitung:
32-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–146 |
147 ONT/ONU-Average-Data-Rate-Downstream |
Durchschnittliche Downstream-Datenrate für ONT/ONU, in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–147 |
148 ONT/ONU-Peak-Data-Rate-Downstream |
Spitzen-Downstream-Datenrate für ONT/ONU, in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–148 |
149 ONT/ONU-Maximum-Data-Rate-Upstream |
Maximale Upstream-Datenrate für ONT/ONU, in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–149 |
150 ONT/ONU-Assured-Data-Rate-Upstream |
Gesicherte Upstream-Datenrate für ONT/ONU, in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–150 |
151 PON-Tree-Maximum-Data-Rate-Upstream |
Maximale Upstream-Datenrate für den PON-Baum in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–151 |
152 PON-Tree-Maximum-Data-Rate-Downstream |
Maximale Downstream-Datenrate für den PON-Baum in bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK PON |
26–3561–152 |
155 Upstream mit erwartetem Durchsatz |
Erwarteter Upstream-Durchsatz, d. h. die Nettodatenrate abzüglich des erwarteten Ratenverlusts, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–155 |
156 Downstream mit erwartetem Durchsatz DSL |
Erwarteter Upstream-Durchsatz, d. h. die Nettodatenrate abzüglich des erwarteten Ratenverlusts, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–156 |
157 Erreichbarer-erwarteter-Durchsatz-Upstream |
Maximal erreichbarer erwarteter Upstream-Durchsatz in Kbit/s 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–157 |
158 Erreichbarer-erwarteter-Durchsatz-Downstream |
Maximal erreichbarer erwarteter Downstream-Durchsatz in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–158 |
159 Gamma-Datenrate-Upstream |
Tatsächliche Upstream-Datenrate (Nettodatenrate) für die Teilnehmeranschlussleitung, angepasst um etwaige Einschränkungen der Durchsatzfähigkeit, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–159 |
160 Gamma-Datenrate-Downstream |
Tatsächliche Downstream-Datenrate (Nettodatenrate) für die Teilnehmeranschlussleitung, angepasst um etwaige Einschränkungen der Durchsatzfähigkeit, in Kbit/s 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–160 |
161 Erreichbare-Gamma-Datenrate-Upstream |
Maximal erreichbare Upstream-Datenrate (Nettodatenrate) für die Teilnehmeranschlussleitung, angepasst um etwaige Einschränkungen der Durchsatzfähigkeit, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–161 |
162 Erreichbare-Gamma-Datenrate-Downstream |
Maximal erreichbare Downstream-Datenrate (Nettodatenrate) für die Teilnehmeranschlussleitung, angepasst um etwaige Einschränkungen der Durchsatzfähigkeit, in Bps 64-Bit-Ganzzahl ohne Vorzeichen |
IKRK DSL (G.fast) |
26–3561–162 |
254 IWF-Sitzung |
Vier-Oktett-Feld, das angibt, ob die Internetworking-Funktion für die PPPoA-over-PPPoE-Sitzung des Abonnenten ausgeführt wurde oder nicht |
IKRK DSL |
26-3561–254 |
Aktualisierungen der Verbindungsgeschwindigkeit auf der LAC
Sie können die LAC so konfigurieren, dass das LNS benachrichtigt wird, wenn sich die Geschwindigkeit der Teilnehmerverbindung 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 der LAC entsprechend konfiguriert ist, informiert er das LNS, dass er diese Updates senden kann, indem er beim Start der L2TP-Sitzung die Option Connect Speed Update Enable AVP (98) in die ICRQ-Nachricht einfügt. Das Fehlen von Connect Speed Update Enable AVP (98) in der ICRQ-Meldung weist darauf hin, dass die LAC während der gesamten Lebensdauer der 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 leitet diese Informationen wiederum an das LNS weiter, indem er eine CSUN-Nachricht (Connect-Speed-Update-Notification) sendet, die die aktualisierten Geschwindigkeiten in einem Connect Speed Update AVP (97) für jede Sitzung enthält. Die LAC sammelt Aktualisierungen der Verbindungsgeschwindigkeit und sendet sie in einem Batch, um sowohl den Leistungsaufwand auf der LAC als auch die Menge des durch diese Benachrichtigungen generierten Datenverkehrs zu minimieren.
Die anfänglichen Geschwindigkeiten in den ICCN-Nachrichten und die aktualisierten Geschwindigkeiten in CSUN-Nachrichten werden von CoS verwendet, um die Datenverkehrsrate für Teilnehmerzugangsleitungen zu bestimmen.
Das Vorhandensein von Connect Speed Update Enable AVP (98) in der ICRQ-Nachricht informiert das LNS auch darüber, dass der LAC reagiert, wenn er eine CSURQ-Nachricht (Connect-Speed-Update-Request) von einem LNS empfängt.
Das Junos-Betriebssystem unterstützt derzeit nicht das Senden von CSURQ-Nachrichten durch Router der MX-Serie, die als LNS konfiguriert sind. Bei allen Diskussionen über CSURQ-Nachrichten geht es ausschließlich darum, wie ein LAC der MX-Serie auf einen CSURQ reagiert, den er von einem LNS eines Drittanbieters empfängt.
Ein LNS eines Drittanbieters kann während der Lebensdauer eines Tunnels jederzeit eine CSURQ-Nachricht senden, um die aktuelle Übertragungs- und Empfangsverbindungsgeschwindigkeit für eine oder mehrere L2TP-Sitzungen anzufordern. Das LNS enthält die Remote-Sitzungs-IDs (relativ zum LNS) in der CSURQ-Nachricht. Wenn der LAC zuvor das Connect Speed Update Enable AVP (98) für die angeforderten Sitzungen gesendet hat, antwortet es auf den CSURQ mit einer CSURQ-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 Verbindungsgeschwindigkeitswerte, die in AVP 24 und AVP 38 gemeldet wurden.
Wenn Sie die Aktualisierung der Verbindungsgeschwindigkeit entweder global oder für ein bestimmtes LNS aktivieren, sendet die LAC keine CSUN-Meldungen, es sei denn, Sie haben die tx-connect-speed
Anweisung auch ancp
als entweder oder service-profile
konfiguriert.
Aktualisierungen der Verbindungsgeschwindigkeit auf dem LNS
Ab Junos OS Version 17.4R1 kann ein Router der MX-Serie, der als LNS konfiguriert ist, Informationen zur Teilnehmerzugriffsleitung und Aktualisierungen der Verbindungsgeschwindigkeit verarbeiten, die er von der LAC empfängt. Der Router der MX-Serie kann keine CSURQ-Nachrichten senden, um Updates von der LAC anzufordern.
Die anfänglichen Geschwindigkeiten in den ICCN-Nachrichten und die aktualisierten Geschwindigkeiten in CSUN-Nachrichten werden von CoS verwendet, um die Datenverkehrsrate für Teilnehmerzugangsleitungen zu bestimmen.
Interaktion zwischen globalen und zielspezifischen Konfigurationen
Sie können die LAC so konfigurieren, dass sie die Zugriffsleitungsinformationen in der ICRQ-Nachricht weiterleitet, die sie an das LNS sendet, 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. Die Konfiguration pro Ziel ermöglicht es Ihnen, die Übertragung auf ein einzelnes LNS oder auf eine Gruppe von LNS oder den Empfang von einer einzelnen LAC oder einer Gruppe von LACs zu beschrä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 Anweisung auf einer oder beiden der folgenden Hierarchieebenen auf dem LAC bzw. LNS ein, um den LAC so zu konfigurieren, dass er die Zugriffsleitungsinformationen in der ICRQ-Nachricht, die access-line-information
er an das LNS sendet, weiterleitet, oder um das LNS so zu konfigurieren, dass es diese Informationen empfängt und verarbeitet:
[edit services l2tp]
– Konfiguriert die Weiterleitung global für alle Ziele.[edit services l2tp destination ip-address]
– Konfiguriert die Weiterleitung für ein bestimmtes Ziel.
Um die LAC so zu konfigurieren, dass Aktualisierungen der Verbindungsgeschwindigkeit gesendet werden, oder das LNS, um die Aktualisierungen zu empfangen und zu verarbeiten, fügen Sie die connection-speed-update
Option mit der Anweisung auf der entsprechenden Hierarchieebene auf der access-line-information
LAC bzw. LNS ein.
Die globalen Einstellungen und die Einstellungen pro Ziel interagieren wie folgt:
Zugangsleitungsinformationen: 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 ein bestimmtes Ziel (LNS oder LAC) deaktivieren, indem Sie für das Ziel angeben
access-line-information
und weglassenconnection-speed-update
.
Übertragung von Tx- und Rx-Verbindungsgeschwindigkeiten von LAC zu LNS
Ein L2TP-Zugriffskonzentrator (LAC) verwendet ICCN-Nachrichten (Incoming-Call-Connected) während des Aufbaus einer L2TP-Tunnelsitzung, um Attribut-Wert-Paare (AVP) zu senden, die die Verbindungsgeschwindigkeit der Teilnehmersitzung an den L2TP-Netzwerkserver (LNS) übermitteln. AVP 24 enthält die Sendegeschwindigkeit (Tx) und AVP 38 die Empfangsgeschwindigkeit (Rx).
Die L2TP-Übertragungsverbindungsgeschwindigkeit ist die Übertragungsverbindungsgeschwindigkeit in Bits pro Sekunde (bps) der Zugangsschnittstelle des Teilnehmers. Das heißt, sie stellt die Geschwindigkeit der Verbindung dar, die dem LAC vom LAC zum Teilnehmer nachgeschaltet ist, aus der Perspektive des LAC.
Die L2TP-Empfangsverbindungsgeschwindigkeit ist die Geschwindigkeit in Bit/s der Verbindung stromaufwärts vom Teilnehmer zur LAC, wiederum aus der Perspektive der LAC. Wenn die Empfangsverbindungsgeschwindigkeit von der Übertragungsverbindungsgeschwindigkeit abweicht, ist AVP 38 im ICCN enthalten, um die Empfangsverbindungsgeschwindigkeit zu übertragen.
Wenn die Verbindungsgeschwindigkeit in beide Richtungen gleich ist, verwendet das LNS den Wert in AVP 24 sowohl für die Sende- als auch für die Empfangsverbindungsgeschwindigkeit. In diesem Fall sendet die LAC kein AVP 38. Sie können dieses Standardverhalten außer Kraft setzen, indem Sie die Anweisung einschließen, die bewirkt, dass die LAC AVP 38 sendet, auch wenn die
rx-connect-speed-when-equal
Übertragungs- und Verbindungsgeschwindigkeiten gleich sind. Siehe Übertragung der Empfangsverbindungsgeschwindigkeit AVP, wenn Sende- und Empfangsverbindungsgeschwindigkeiten gleich sind.Die in der ICCN-Nachricht gesendeten Tx- und Rx-Verbindungsgeschwindigkeiten werden von der Methode abgeleitet, die durch das LAC-Fallback-Verfahren bestimmt wird. Da die Dienstaktivierung erst nach dem Senden der ICCN erfolgt, greift die LAC immer auf die nächste Methode zurück, wenn
service-profile
diese als Methode konfiguriert ist. Bei späterer Aktivierung des Serviceprofils werden entsprechende Geschwindigkeitsänderungen in Update-Meldungen an das LNS gesendet.Nachdem die L2TP-Sitzung eingerichtet wurde, können sich die Tx- und Rx-Verbindungsgeschwindigkeiten jederzeit ändern. Wenn dies konfiguriert ist, sendet die LAC die aktualisierten Werte für jede Sitzung in CSUN-Nachrichten (Connect-Speed-Update-Notification) an das LNS. Die aktualisierten Geschwindigkeiten werden im Connect Speed Update AVP (97) übermittelt.
- Methoden zur Ermittlung der an das LNS gemeldeten Geschwindigkeitswerte
- Bestimmen der anfänglichen Verbindungsgeschwindigkeiten
- Fallback-Mechanismus für Verbindungsgeschwindigkeitswerte
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 die Verfügbarkeit und Unterstützung der 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 Sitzungsplanerknoten basierend auf der lokalen Datenverkehrssteuerungsrichtlinie erzwungen wird. Bei dieser Methode ist nur die Übertragungsverbindungsgeschwindigkeit verfügbar, sodass die Empfangsübertragungsgeschwindigkeit durch das Fallback-Schema bestimmt wird. Verwenden Sie dieseactual
Methode, wenn der gemeldete Wert der Downstreamgeschwindigkeit entsprechen 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 dieeffective shaping-rate
Anweisung auf Hierarchieebene[edit chassis]
enthalten ist. Die CLI-Commit-Prüfung schlägt fehl, wenn sie konfiguriert ist,actual
aber die effektive Shaping-Rate nicht konfiguriert ist.Wenn die Tunnel-Tx-Speed-Methode VSA (26-94) gesetzt ist, wird keine Commit-Prüfung durchgeführt, so dass in dieser Situation eine Systemprotokollmeldung generiert wird, um den Benutzer daran zu erinnern, die effektive Shaping-Rate zu konfigurieren.
ancp
—Die Geschwindigkeit ist der angepasste vor- und nachgelagerte ANCP-Wert, der sich aus einer konfigurierten prozentualen Korrektur der tatsächlichen ANCP-Werte ergibt. Die Anpassung wird pro DSL angewendet, um Unterschiede bei der ATM-Kapselung zwischen dem BNG und der Zugangsschleife 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 der 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. In Ermangelung dieser Werte muss das LNS seine eigene vor- und nachgelagerte Richtlinie festlegen. Diese Option hat Vorrang vor den Juniper Networks RADIUS VSAs, Tx-Connect-Speed (26-162) und Rx-Connect-Speed (26-163) sowie allen anderen Methoden, die für die Verbindungsgeschwindigkeit konfiguriert sind.pppoe-ia-tags
—Die Geschwindigkeit ergibt sich aus dem Wert, 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 es sich bei dem Wert um einen angepassten Wert handeln, wenn das Tag das Encapsulation Overhead-Attribut (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 die LAC gemeldete Geschwindigkeit ändern. Angenommen, die konfigurierte Methode ist
service-profile
. Das Profil wird nicht aktiviert, bevor die ICCN gesendet wird, und greift auf das PPPoE-IA-Tag zurück, das in der ICCN-Nachricht gesendet wird. Wenn das Dienstprofil zu einem späteren Zeitpunkt aktiviert wird, werden die Dienstprofiltarife in einer Aktualisierungsnachricht gesendet (sofern Aktualisierungen konfiguriert sind).service-profile
—Abhängig von Ihrer Junos OS-Version gibt es zwei Möglichkeiten, Dienstprofile 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, das auf dem L3-Knoten basierend auf der lokalen Richtlinie erzwungen wird. Die Upstream-Geschwindigkeit (Rx-Geschwindigkeit) wird aus dem konfigurierten Wert im Dienstprofil übernommen. Dieser Wert wird nicht angepasst.
Standardmäßig werden Dienstprofile nicht aktiviert, bevor die Abonnentensitzung eingerichtet wird, sodass diese Methode für die im ICCN gesendeten Werte auf eine andere Methode 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 anzugeben, wenn die L2TP-Sitzung ausgehandelt wird. Bei der Anmeldung des Abonnenten bestimmt authd, ob der in der Juniper Networks Activate-Service VSA (26-65) in der RADIUS Access-Accept-Nachricht übermittelte Dienstprofilname mit dem Dienstprofilnamen übereinstimmt, der mit der
service-rate-limiter
Anweisung auf Hierarchieebene[edit access]
konfiguriert wurde. Wenn die Namen übereinstimmen, werden die Geschwindigkeiten entweder aus den Standardwerten im Dienstprofil oder aus den vom VSA übergebenen Parametern abgeleitet. Weitere Informationen zu dieser Methode finden Sie unter Angeben eines ratenbegrenzenden Dienstprofils für L2TP-Verbindungsgeschwindigkeiten .
Die
service-profile
Methode wird nur unterstützt, wenn dieeffective shaping-rate
Anweisung auf Hierarchieebene[edit chassis]
enthalten ist. Die CLI-Commit-Prüfung schlägt fehl, wenn sie konfiguriert ist,service-profile
aber die effektive Shaping-Rate nicht konfiguriert ist.Wenn die Tunnel-Tx-Speed-Methode VSA (26-94) gesetzt ist, wird keine Commit-Prüfung durchgeführt, so dass in dieser Situation eine Systemprotokollmeldung generiert wird, um den Benutzer daran zu erinnern, die effektive Shaping-Rate zu konfigurieren.
Bewährte Methode:Es wird empfohlen, nur ein Dienstprofil pro Abonnentensitzung zu verwenden, um die Downstream-Shaping-Rate zu beeinflussen oder eine Upstream-Rate zu melden. Wenn mehr als ein dynamisches Dienstprofil auf die Abonnentensitzung angewendet wird, sodass sich jedes Profil auf die Downstream-Shaping-Rate auswirkt oder die Upstream-Rate meldet, werden die Werte aus dem zuletzt angewendeten Profil von L2TP gemeldet. Die Deaktivierung des zuletzt angewendeten Dienstes führt nicht dazu, dass L2TP die Upstream-Geschwindigkeit für ein bestehendes (aktives) Dienstprofil meldet.
static
—Diese Methode bewirkt, dass die LAC die Geschwindigkeit von der konfigurierten statischen Layer-2-Geschwindigkeit ableitet. Bei Ethernet-VLANs ist dies die empfohlene (empfohlene) Shaping-Rate, die auf der logischen PPPoE-Schnittstelle konfiguriert ist, die der Teilnehmerschnittstelle zugrunde liegt. Wenn die Advisory-Shaping-Rate auf der zugrunde liegenden Schnittstelle nicht konfiguriert ist, wird die tatsächliche Geschwindigkeit des zugrunde liegenden physischen Ports verwendet.
Ab Junos OS Version 15.1R1 können Sie Geschwindigkeitswerte direkt in den Juniper Networks VSAs, Tx-Connect-Speed (26-162) und Rx-Connect-Speed (26-163) konfigurieren. Diese VSAs können in der RADIUS Access-Accept-Meldung 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 Ihres RADIUS-Servers konfigurieren.
Ab Junos OS Version 15.1R1 können Sie eine Methode konfigurieren, die in der VSA von Juniper Networks übermittelt wird, Tunnel-Tx-Speed-Method (26-94). Falls 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 diesem VSA konfigurierte Methode gibt die Ressource an, die die LAC zum Festlegen der Geschwindigkeit verwendet. Um diesen VSA verwenden zu können, müssen Sie RADIUS gemäß der Dokumentation Ihres RADIUS-Servers konfigurieren.
Wenn die Geschwindigkeiten nicht auf andere Weise bestimmt werden können, wird die Portgeschwindigkeit der Teilnehmerschnittstelle verwendet.
Tabelle 2 listet die verfügbaren Methoden nach Release auf.
Einige Methoden, die in VSA 26-94 verfügbar sind, sind in der CLI nicht verfügbar. Wenn eine dieser Methoden in der VSA empfangen wird, wird sie in eine unterstützte Methode übersetzt, anstatt zurückgewiesen zu werden, oder sie greift auf eine andere Methode zurück.
Junos OS – Versionsnummer |
CLI ( |
VSA 26–94 (Tunnel-Tx-Speed-Methode) |
---|---|---|
17.2 und höher |
|
|
15.1, 16.1, 16.2, 17.1 |
|
|
13.3, 14.1, 14.2 |
|
k.A. |
Das Ändern der Verbindungsgeschwindigkeitsmethode in VSA 26-94 oder in der CLI-Konfiguration hat keine Auswirkungen auf vorhandene L2TP-Sitzungen, in denen die ICCN bereits gesendet wurde. Für alle L2TP-Sitzungsverhandlungen nach der Methodenänderung wird die neue Einstellung verwendet.
In den Junos OS-Versionen 15.1, 16.1, 16.2 und 17.1 (die diese 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. Jede Differenz zwischen der in diesen AVPs gemeldeten 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, die zur Einrichtung dieser AVPs verwendet wird, zurückzuführen.
Bestimmen der anfänglichen Verbindungsgeschwindigkeiten
Bevor die LAC anfängliche Sende- und Empfangsverbindungsgeschwindigkeiten in der ICCN-Nachricht an das LNS senden kann, muss sie Folgendes tun:
Wählen Sie die Methode aus, mit der die Geschwindigkeiten abgeleitet werden.
Bestimmen Sie die Geschwindigkeiten.
Die LAC wählt die Methode wie folgt aus:
Wenn die Tunnel-Tx-Speed-Methode VSA (26-94) vorhanden ist, verwenden Sie die Methode, die durch den VSA-Wert angegeben wird.
Verwenden Sie andernfalls die in der CLI konfigurierte Methode mit der
tx-connect-speed-method
Anweisung.
Der LAC bestimmt die Anfangsgeschwindigkeit wie folgt:
Wenn die gewählte Methode ist
none
, enthält die LAC die Sende- und Empfangsgeschwindigkeiten nicht im ICCN.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 die LAC diese Werte an die ICCN.
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
configured als Methode empfangen. Die CLI-Methode ist alsnone
konfiguriert. Die LAC wählt den VSA 26-94-Wert, dieancp
Methode.VSA 26-162 und VSA 26-163 werden mit Werten ungleich Null empfangen. Die LAC sendet diese VSA-Werte an das ICCN.
VSA 26-94 wird mit
ancp
configured als Methode empfangen. Die CLI-Methode ist alsnone
konfiguriert. Die LAC wählt den VSA 26-94-Wert, dieancp
Methode.VSA 26-162 und VSA 26-163 werden mit Nullwerten empfangen. Die LAC verwendet die Methode, um die Werte abzuleiten, die an die
ancp
ICCN gesendet werden sollen.VSA 26-94 wird mit
none
configured als Methode empfangen. Die CLI-Methode ist alsancp
konfiguriert. Der LAC wählt den VSA-Wertnone
26-94 aus und sendet keine Verbindungsgeschwindigkeiten im ICCN.VSA 26-94 wird nicht empfangen. Die CLI-Methode ist als
none
konfiguriert. Die LAC sendet keine Verbindungsgeschwindigkeiten im ICCN.
Fallback-Mechanismus für Verbindungsgeschwindigkeitswerte
Wenn die LAC eine Methode zum Ableiten der Verbindungsgeschwindigkeiten ausgewählt hat, greift sie unter einer der folgenden Umstände auf eine andere Methode zurück:
Einer oder beide Werte für die Verbindungsgeschwindigkeit wurden von der ausgewählten Methode (VSA 26-94 oder CLI) nicht 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ückgegriffen. Es gibt kein 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 wird als Null befunden. Die LAC sendet den ANCP-Wert für die Übertragungsgeschwindigkeit, aber der Empfangswert fällt auf die PPPoE-IA-Tag-Methode zurück. Die LAC sendet den IA-Tag-Wert für die Empfangsgeschwindigkeit.
Die ausgewählte Methode ist ANCP. Der ANCP-Wert für die Empfangsgeschwindigkeit wird als Null befunden. 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 wird ebenfalls als Null befunden, sodass auf die statische Layer-2-Methode zurückgegriffen wird. Dies ist verfügbar, so dass die LAC den statischen Layer-2-Wert für die Empfangsgeschwindigkeit sendet.
Die ausgewählte Methode ist das Dienstprofil. Das Dienstprofil wird nicht 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 an das ICCN sendet.
Das Serviceprofil wird durch eine Änderung der Autorisierung (Change of Authorization, CoA) zu einem späteren Zeitpunkt für die Sitzung aktiviert. Wenn Updates aktiviert sind, sendet die LAC die Serviceprofilwerte in einer CSUN-Nachricht an das LNS. Wenn Aktualisierungen 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 so konfiguriert oder empfangen werden, dass die Dienstprofilmethode aus der CLI-Konfiguration ausgewählt wird.
Ab Junos OS Version 17.2R1 wird das LAC-Fallbackverfahren wie in Tabelle 3 beschrieben.
Methode |
Sende- und Empfangsgeschwindigkeit nicht eingestellt |
Übertragungsgeschwindigkeit nicht eingestellt |
Empfangsgeschwindigkeit nicht eingestellt |
---|---|---|---|
Nichts |
Kein Fallback. |
Kein Fallback. |
Kein Fallback. |
Leistungsprofil |
Beide greifen auf die ANCP-Methode zurück. |
Die Übertragungsgeschwindigkeit fällt auf die ANCP-Methode zurück. |
Die Empfangsgeschwindigkeit wird auf die ANCP-Methode zurückgesetzt. |
ANCP |
Beide greifen auf die PPPoE-IA-Tags-Methode zurück. |
Die Übertragungsgeschwindigkeit fällt auf die PPPoE-IA-Tag-Methode zurück. |
Die Empfangsgeschwindigkeit greift auf die PPPoE-IA-Tag-Methode zurück. |
PPPoE IA-Tags |
Beide greifen auf die statische Layer-2-Methode zurück. |
Die Übertragungsgeschwindigkeit fällt auf die statische Layer-2-Methode zurück. |
Die Empfangsgeschwindigkeit fällt auf die statische Layer-2-Methode zurück. |
Statische Schicht 2 |
Beide fallen auf Port-Geschwindigkeit zurück. |
Die Übertragungsgeschwindigkeit fällt auf die Portgeschwindigkeit zurück. |
Die Empfangsgeschwindigkeit wird auf die Übertragungsgeschwindigkeit zurückgesetzt. |
Ab Junos OS Version 15.1R1 wird das LAC-Fallbackverfahren wie in Tabelle 4 beschrieben.
Methode |
Sende- und Empfangsgeschwindigkeit nicht eingestellt |
Übertragungsgeschwindigkeit nicht eingestellt |
Empfangsgeschwindigkeit nicht eingestellt |
---|---|---|---|
Nichts |
Kein Fallback. |
Kein Fallback. |
Kein Fallback. |
Aktuell |
Beide greifen auf die ANCP-Methode zurück. |
Die Übertragungsgeschwindigkeit fällt auf die ANCP-Methode zurück. |
Die Empfangsgeschwindigkeit wird auf die ANCP-Methode zurückgesetzt. |
ANCP |
Beide greifen auf die PPPoE-IA-Tags-Methode zurück. |
Wenn PPPoE IA-Tags für beide verfügbar sind, greifen beide auf die PPPoE IA-Tags-Methode zurück. Andernfalls fällt die Übertragungsgeschwindigkeit auf die PPPoE-IA-Tag-Methode zurück. |
Wenn PPPoE IA-Tags für beide verfügbar sind, greifen beide auf die PPPoE IA-Tags-Methode zurück. Andernfalls wird die Empfangsgeschwindigkeit auf die PPPoE-IA-Tag-Methode zurückgegriffen. |
PPPoE IA-Tags |
Beide fallen auf Port-Geschwindigkeit zurück. |
Die Übertragungsgeschwindigkeit fällt auf die Portgeschwindigkeit zurück. |
Die Empfangsgeschwindigkeit wird auf die Portgeschwindigkeit zurückgesetzt. |
Ab Junos OS Version 13.3R1 wird das LAC-Fallback-Verfahren wie in Tabelle 5 beschrieben.
Methode |
Sende- und Empfangsgeschwindigkeit nicht eingestellt |
Übertragungsgeschwindigkeit nicht eingestellt |
Empfangsgeschwindigkeit nicht eingestellt |
---|---|---|---|
Nichts |
Kein Fallback. |
Kein Fallback. |
Kein Fallback. |
ANCP |
Beide greifen auf die PPPoE-IA-Tags-Methode zurück. |
Wenn PPPoE IA-Tags für beide verfügbar sind, greifen beide auf die PPPoE IA-Tags-Methode zurück. Andernfalls fällt die Übertragungsgeschwindigkeit auf die PPPoE-IA-Tag-Methode zurück. |
Wenn PPPoE IA-Tags für beide verfügbar sind, greifen beide auf die PPPoE IA-Tags-Methode zurück. Andernfalls wird die Empfangsgeschwindigkeit auf die PPPoE-IA-Tag-Methode zurückgegriffen. |
PPPoE IA-Tags |
Beide greifen auf die statische Layer-2-Methode zurück. |
Die Übertragungsgeschwindigkeit fällt auf die statische Layer-2-Methode zurück. |
Die Empfangsgeschwindigkeit fällt auf die statische Layer-2-Methode zurück. |
Statische Schicht 2 |
Beide fallen auf Port-Geschwindigkeit zurück. |
Die Übertragungsgeschwindigkeit fällt auf die Portgeschwindigkeit zurück. |
Die Empfangsgeschwindigkeit wird auf die Übertragungsgeschwindigkeit zurückgesetzt. |
Sowohl für Gigabit-Ethernet- (ge) als auch für 10-Gigabit-Ethernet-Schnittstellen (xe) ist der Wert für die Portgeschwindigkeit auf 1.000.000.000 festgelegt. Bei aggregierten Ethernet-Schnittstellen (ae) wird der Wert für die Portgeschwindigkeit auf 0 festgelegt. Der Wert für die Portgeschwindigkeit für alle diese Schnittstellentypen wird sowohl in AVP 24 als auch in AVP 38 angegeben.
Übertragung der Empfangsverbindungsgeschwindigkeit AVP, wenn die Übertragungs- und Empfangsverbindungsgeschwindigkeiten gleich sind
Das L2TP Rx Connect Speed (in Bit pro Sekunde) AVP, das durch AVP 38 dargestellt wird, ist in der ICCN-Nachricht enthalten, wenn die Empfangsverbindungsgeschwindigkeit von der Übertragungsverbindungsgeschwindigkeit abweicht. Wenn die Verbindungsgeschwindigkeit in beide Richtungen gleich ist, wird AVP 38 standardmäßig nicht gesendet. Das LNS verwendet den Wert in AVP 24 sowohl für Sende- als auch für Empfangsverbindungsgeschwindigkeiten.
AVP 38 wird generiert, wenn die Empfangsverbindungsgeschwindigkeit der Zugriffsschnittstelle gleich der berechneten Übertragungsverbindungsgeschwindigkeit gesetzt wird, indem die rx-connect-speed-when-equal
Anweisung auf Hierarchieebene [edit services l2tp]
ausgegeben wird. In diesem Szenario überträgt die LAC denselben Wert für die Übertragungs- und Empfangsverbindungsgeschwindigkeiten, die über AVP 24 und AVP 38 in der ICCN-Nachricht an das LNS gesendet werden.
So konfigurieren Sie das Senden von AVP 38, wenn die Verbindungsgeschwindigkeiten sowohl in Downstream- als auch in Upstream-Richtung gleich sind:
Konfigurieren Sie die Übertragung der Empfangsverbindungsgeschwindigkeit AVP 38, wenn die Empfangsverbindungsgeschwindigkeit gleich der berechneten Sendeverbindungsgeschwindigkeit eingestellt ist.
[edit services l2tp] user@host# set rx-connect-speed-when-equal
Konfigurieren der Methode zum Ableiten der an das LNS gesendeten LAC-Verbindungsgeschwindigkeiten
Die LAC-Verbindungsgeschwindigkeiten werden auf verschiedene Arten bestimmt:
Die VSAs von Juniper Networks, Tx-Connect-Speed (26-162) und Rx-Connect-Speed (26-163).
Juniper Networks VSA, Tunnel-Tx-Speed-Methode (26-94).
Die CLI-Konfiguration.
Die Portgeschwindigkeit der Teilnehmerzugriffsschnittstelle.
Sie können die Anweisung auf Hierarchieebene [edit services l2tp]
einschließen, um eine Methode zu konfigurieren, die die Ressource angibt, die die LAC zum Festlegen dieser Geschwindigkeiten verwendet, wenn die tx-connect-speed-method
VSAs von Juniper Networks nicht für den Abonnenten zurückgegeben werden.
Ab Junos OS Version 17.2R1 müssen Sie die entsprechende Anweisung einschließen, wenn Sie Updates für die Verbindungsgeschwindigkeit für die tx-connect-speed-method
LAC aktivieren. Sie müssen auch entweder ancp
oder service-profile
als Methode angeben, andernfalls sendet die LAC keine CSUN-Nachrichten.
Das Ändern der Verbindungsgeschwindigkeitsmethode in der CLI-Konfiguration oder in VSA 26-94 hat keine Auswirkungen auf vorhandene L2TP-Sitzungen, in denen die ICCN bereits gesendet wurde. Für alle L2TP-Sitzungsverhandlungen nach der Methodenänderung wird die neue Einstellung verwendet.
Ab Junos OS Version 13.3R1 variieren Verfügbarkeit und Unterstützung für Methoden je nach Junos OS-Version. In der folgenden Prozedur werden alle historischen Methoden aufgelistet. Einige der Methoden werden in der von Ihnen verwendeten Softwareversion möglicherweise nicht unterstützt. Unter Übertragung von Tx- und Rx-Verbindungsgeschwindigkeiten von LAC zu LNS finden Sie eine Tabelle der Unterstützung nach Freigabe.
So legen Sie die Methode zur Berechnung der Übertragungsverbindungsgeschwindigkeit fest:
(Optional) Konfigurieren Sie die LAC so, dass die effektiven Shaping-Raten der Serviceklasse verwendet werden.
[edit services l2tp] user@host# set tx-connect-speed-method actual
Hinweis:Diese Methode erfordert, dass die
effective shaping rate
Anweisung auf Hierarchieebene[edit chassis]
konfiguriert wird. Wenn dies nicht der Fall ist, schlägt das Ausführen dieses Commits fehl. Wenn die Methode jedoch von RADIUS in VSA 26-94 empfangen wird, wird stattdessen eine Systemprotokollmeldung generiert, da in diesem Fall keine Commit-Prüfung durchgeführt wird.(Optional) Konfigurieren Sie die LAC so, dass sie die Werte verwendet, die von dem ANCP-Wert abgeleitet sind, der auf der PPPoE-Schnittstelle konfiguriert ist, die der Abonnentenschnittstelle zugrunde liegt.
[edit services l2tp] user@host# set tx-connect-speed-method ancp
(Optional) Konfigurieren Sie die LAC so, dass die Werte verwendet werden, die in den vom DSLAM empfangenen PPPoE-IA-Tags bereitgestellt werden.
[edit services l2tp] user@host# set tx-connect-speed-method pppoe-ia-tags
In diesem Fall wird der Wert von Actual-Data-Rate-Downstream (VSA 26-129) für AVP 24 verwendet. Der Wert von Actual-Data-Rate-Upstream (VSA 26-130) wird für AVP 38 verwendet und nur gesendet, wenn sich die VSA-Werte unterscheiden.
Hinweis:Diese von den IA-Tags abgeleitete Geschwindigkeit gilt nicht für Abonnenten, die bereits angemeldet sind. Sie ist nur für Abonnenten wirksam, die sich anmelden, nachdem diese Einstellung gespeichert wurde.
(Optional) Konfigurieren Sie die LAC so, dass sie Folgendes verwendet:
Downstream-Geschwindigkeit (Tx): Die tatsächliche CoS-Rate, die auf dem Level-3-Knoten basierend auf der lokalen Richtlinie erzwungen wird
Upstream-Geschwindigkeit (Rx): Der im dynamischen Serviceprofil konfigurierte Wert.
Geben Sie die
service-profile
Methode an.[edit services l2tp] user@host# set tx-connect-speed-method service-profile
Konfigurieren Sie im dynamischen Dienstprofil die Eingangsformungsrate von CoS, die von der LAC verwendet werden soll, um an das LNS die Rx-Verbindungsgeschwindigkeit zu melden.
[edit dynamic-profiles profile-name class-of-service interfaces interface-name unit logical-unit-number] user@host# set report-ingress-shaping-rate bps
Hinweis:Die
service-profile
Methode erfordert, dass dieeffective shaping rate
Anweisung auf Hierarchieebene[edit chassis]
konfiguriert wird. Ist dies nicht der Fall, schlägt die Commit-Prüfung fehl. Wenn dieservice-profile
Methode jedoch von RADIUS in VSA 26-94 empfangen wird, wird stattdessen eine Systemprotokollmeldung generiert, da in diesem Fall keine Commit-Prüfung durchgeführt wird.Hinweis:Eine weitere Methode zur Verwendung von Dienstprofilen zum Bereitstellen der Verbindungsgeschwindigkeiten finden Sie unter Angeben eines ratenbegrenzenden Dienstprofils für L2TP-Verbindungsgeschwindigkeiten.
(Optional) Konfigurieren Sie die LAC so, dass die empfohlene (empfohlene) Downstream-Shaping-Rate der zugrunde liegenden Schnittstelle für AVP 24 und die empfohlene Upstream-Shaping-Rate für AVP 38 verwendet wird. Dies wird auch als statische Layer-2-Shaping-Rate bezeichnet.
[edit services l2tp] user@host# set tx-connect-speed-method static
Sie konfigurieren die Beratungsraten unter der logischen PPPoE-Schnittstelle, die der Abonnentenschnittstelle zugrunde liegt, mit der
advisory-options
Anweisung auf Hierarchieebene[edit interfaces interface-name unit logical-unit-number]
. Wenn die empfohlene Geschwindigkeit nicht konfiguriert ist, wird die tatsächliche Portgeschwindigkeit verwendet. Für ge- und xe-Schnittstellen wird der Geschwindigkeitswert auf 10.000.000 und für ae-Schnittstellen der Geschwindigkeitswert auf 0 festgelegt und sowohl in AVP 24 als auch in AVP 38 gesendet(Optional) Konfigurieren Sie die LAC so, dass das Senden von AVP 24 und AVP 38 deaktiviert wird.
Hinweis:Diese Option verhindert, dass die LAC in den ICCN-Nachrichten entweder AVP 24 oder AVP 38 sendet. Diese Option überschreibt auch die Juniper Networks RADIUS VSAs, Tx-Connect-Speed (26-162) und Rx-Connect-Speed (26-163).
[edit services l2tp] user@host# set tx-connect-speed-method none
Konfigurieren der Berichterstellung und Verarbeitung von Teilnehmerzugangsleitungsinformationen
Die in RFC 5515, Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extension, definierten L2TP-AVP-Erweiterungen ermöglichen es der LAC, an das LNS Merkmale der Zugriffsleitung des Teilnehmers zu melden, wie z. B. Identifikationsattribute, Leitungstyp, Verbindungsgeschwindigkeit, verschiedene Datenraten usw. Die LAC empfängt die Zugriffsleitungsinformationen, wenn das CPE des Teilnehmers eine Verbindungsanforderung initiiert, und leitet die verfügbaren Informationen in verschiedenen AVPs, die in ICRQ-Nachrichten enthalten sind, an das LNS weiter. Die LAC kann dem LNS auch signalisieren, dass sie in der Lage ist, Aktualisierungen der Verbindungsgeschwindigkeiten der Teilnehmer zu senden. diese werden durch das Connect Speed Update AVP (97) in der CSUN-Meldung übermittelt.
Ab Junos OS Version 17.4R1 werden auch RFC 5515 AVP-Erweiterungen auf dem LNS unterstützt. Folglich können Sie das LNS so konfigurieren, dass es Informationen zur Teilnehmerzugangsleitung und Aktualisierungen der Verbindungsgeschwindigkeit verarbeitet, die es von der LAC empfängt.
Ab Junos OS Version 19.3R1 werden AVPs für PON- und G.fast-Zugangsleitungen unterstützt, entsprechend den PON- und G.fast-TLVs des Broadband Forum.
Teilnehmerzugangsleitungsinformationen, die von AVPs in ICRQ-Nachrichten übermittelt werden, werden an RADIUS in DSL Forum VSA-AVPs übergeben. Die anfänglichen und aktualisierten Verbindungsgeschwindigkeiten, die in ICCN- und CSUN-Nachrichten übermittelt werden, können von CoS verwendet werden, um die Datenverkehrsraten für die Teilnehmerleitungen anzupassen.
Standardmäßig sind weder die Weiterleitung von Zugriffsleitungsinformationen noch die Funktion zur Aktualisierung der Verbindungsgeschwindigkeit auf der LAC aktiviert. Sie müssen die Funktionen für alle LNS-Endpunkte oder für einen bestimmten LNS-Endpunkt konfigurieren. Die Konfiguration pro Ziel gilt für alle Tunnel mit dieser Ziel-IP-Adresse. Sie können eine Konfiguration pro Ziel verwenden, wenn Sie wissen, dass nur bestimmte Endpunkte diese Funktion unterstützen oder ordnungsgemäß implementieren.
Ebenso ist die Verarbeitung dieser Informationen durch das LNS standardmäßig nicht aktiviert. Sie können die Verarbeitung für Informationen aktivieren, die von allen LAC-Endpunkten empfangen werden, oder für bestimmte LAC-Endpunkte. Die Konfiguration pro Ziel gilt für alle Tunnel mit dieser Ziel-IP-Adresse.
Die CLI-Anweisungen sind sowohl für LAC als auch für LNS identisch. Der Unterschied besteht darin, dass Sie die Anweisungen in die LAC-Konfiguration oder die LNS-Konfiguration aufnehmen.
Gehen Sie wie folgt vor, um die LAC so zu konfigurieren, dass Informationen über Teilnehmerzugangsleitungen an das LNS gesendet werden, oder um das LNS so zu konfigurieren, dass diese vom LAC empfangenen Informationen verarbeitet werden:
Konfigurieren Sie die Funktion global für alle Endpunkte.
[edit services l2tp] user@host# set access-line-information
Konfigurieren Sie die Funktion für einen bestimmten Endpunkt.
[edit services l2tp destination address ip-address] user@host# set access-line-information
Konfigurieren Sie die connection-speed-update
Option auf der LAC nicht, wenn das LNS Änderungen der Verbindungsgeschwindigkeit nicht unterstützt. Dabei kann es sich um ein LNS handeln, das nicht für die Verarbeitung der Aktualisierungen konfiguriert ist, oder um ein nicht konformes LNS eines Drittanbieters. Wenn Sie die LAC-Option für ein solches LNS konfigurieren, werden zusätzliche Steuermeldungen generiert, die ignoriert werden.
Gehen Sie wie folgt vor, um den LAC so zu konfigurieren, dass er auch Aktualisierungen über Änderungen der Verbindungsgeschwindigkeit an das LNS sendet, oder um das LNS so zu konfigurieren, dass vom LAC empfangene Geschwindigkeitsaktualisierungen verarbeitet werden:
Schließen Sie die Aktualisierungsoption ein, wenn Sie die Funktion konfigurieren.
[edit services l2tp] user@host# set access-line-information connection-speed-update
Oder
[edit services l2tp destination address ip-address] user@host# set access-line-information connection-speed-update
Wenn Sie die LAC zum Senden von Updates konfigurieren, müssen Sie auch die Methode konfigurieren, mit der die Werte für die Verbindungsgeschwindigkeit abgeleitet werden. Die Methode gibt die Quelle der Aktualisierungswerte an. Auf dem LNS ist die Ableitungsmethode nicht relevant und kann nicht konfiguriert werden.
[edit services l2tp] user@host# set tx-connect-speed-method method
Betrachten Sie die folgenden Beispiele:
Die folgende Konfiguration gibt an, dass die LAC für alle Tunnel mit der Endpunktadresse 192.0.2.2 Zugriffsleitungsmerkmale vom ANCP-Agenten oder PPPoE-Zwischenagenten (in dieser Reihenfolge) an das LNS in der ICRQ-Nachricht meldet. Das Connect Speed Update Enable AVP (98) ist nicht im ICRQ enthalten; Folglich werden keine CSUN-Nachrichten an das LNS gesendet, um Geschwindigkeitsänderungen in den Teilnehmerzugangsleitungen zu melden, die vom ANCP-Agenten gemeldet werden. Die LAC ignoriert alle CSURQ-Nachrichten, die sie vom LNS empfängt. Dabei kann es sich nur um ein LNS eines Drittanbieters handeln, da das Senden von CSURQ-Nachrichten auf Routern der MX-Serie, die als LNS konfiguriert sind, nicht unterstützt wird.
[edit services l2tp destination address 192.0.2.2] user@host# set access-line-information
Die folgende Konfiguration gibt an, dass die LAC für alle Tunnel mit der Endpunktadresse 203.0.113.23 Zugriffsleitungsmerkmale vom ANCP-Agenten oder PPPoE-Zwischenagenten (in dieser Reihenfolge) an das LNS in der ICRQ-Nachricht meldet. Das Connect Speed Update Enable AVP (98) ist im ICRQ enthalten; CSUN-Nachrichten werden an das LNS gesendet, um Geschwindigkeitsänderungen in den Teilnehmerzugangsleitungen zu melden, die vom ANCP-Agenten gemeldet werden. Die LAC akzeptiert alle CSURQ-Nachrichten, die sie vom LNS empfängt, und antwortet mit einer CSUN-Nachricht. Dabei kann es sich nur um ein LNS eines Drittanbieters handeln, da das Senden von CSURQ-Nachrichten auf Routern der MX-Serie, die als LNS konfiguriert sind, nicht unterstützt wird.
[edit services l2tp] user@host# set destination address 203.0.113.23 access-line-information connection-speed-update user@host# set tx-connect-speed-method ancp
Wenn die Weiterleitung von Zugriffsleitungsinformationen global aktiviert ist, können Sie sie nicht für ein bestimmtes Ziel deaktivieren. Wenn die Aktualisierung der Verbindungsgeschwindigkeit jedoch global aktiviert ist, können Sie die Updates für ein bestimmtes Ziel deaktivieren.
Die folgende Konfiguration gibt an, dass sowohl die Weiterleitung von Zugriffsleitungsmerkmalen als auch die Aktualisierung der Verbindungsgeschwindigkeit für alle Ziele aktiviert sind. Für das Ziel 198.51.100.2 wird die Konfiguration der globalen Updates überschrieben, indem die Konfiguration der Zugriffsleitung für dieses Ziel wiederholt und die Aktualisierungen der Verbindungsgeschwindigkeit für dieses Ziel weggelassen werden.
[edit services l2tp] user@host# set access-line-information connection-speed-update user@host# set tx-connect-speed-method ancp [edit services l2tp destination address 198.51.100.2] user@host# set access-line-information
Der
show services l2tp summary
Befehl zeigt die Konfiguration an, die für alle Ziele gilt. Die folgende Beispielausgabe bestätigt die globale Konfiguration in diesem Beispiel:user@host> show services l2tp summary Failover within a preference level is Disabled Weighted load balancing is Disabled Tunnel authentication challenge is Enabled Calling number avp is Enabled Failover Protocol is Disabled Tx Connect speed method is static Rx speed avp when equal is enabled Tunnel assignment id format is assignment-id Tunnel Tx Address Change is Accept Min Retransmissions Timeout for control packets is 2 seconds Max Retransmissions for Established Tunnel is 7 Max Retransmissions for Not Established Tunnel is 5 Tunnel Idle Timeout is 60 seconds Destruct Timeout is 300 seconds Destination Lockout Timeout is 300 seconds Access Line Information is Enabled, Speed Updates is Enabled Destinations: 0, Tunnels: 0, Sessions: 0, Switched sessions: 0
Der
show services l2tp destination detail
Befehl zeigt die Konfiguration für jedes Ziel einzeln an. In der folgenden Beispielausgabe wird überprüft, ob Aktualisierungen der Verbindungsgeschwindigkeit für 198.51.100.2 deaktiviert sind:user@host> show services l2tp destination detail Local name: 1 Remote IP: 198.51.100.2 Tunnels: 1, Sessions: 1 State: Enabled Local IP: 203.0.113.2 Transport: ipUdp, Logical System: default, Router Instance: default Lockout State: not locked Access Line Information: Enabled, Speed Updates: Disabled ...
In diesem Beispiel ist die Weiterleitung von Zugriffsleitungsmerkmalen für alle Ziele aktiviert, aber die Aktualisierung der Verbindungsgeschwindigkeit ist nur für ein Ziel (198.51.100.21) aktiviert.
[edit services l2tp] user@host# set access-line-information [edit services l2tp destination address 198.51.100.21] user@host# set access-line-information connection-speed-update user@host# up user@host# set tx-connect-speed-method ancp
Die folgende Beispielausgabe bestätigt, dass Aktualisierungen der Verbindungsgeschwindigkeit global deaktiviert sind:
user@host> show services l2tp summary Failover within a preference level is Disabled Weighted load balancing is Disabled Tunnel authentication challenge is Enabled Calling number avp is Enabled Failover Protocol is Disabled Tx Connect speed method is static Rx speed avp when equal is enabled Tunnel assignment id format is assignment-id Tunnel Tx Address Change is Accept Min Retransmissions Timeout for control packets is 2 seconds Max Retransmissions for Established Tunnel is 7 Max Retransmissions for Not Established Tunnel is 5 Tunnel Idle Timeout is 60 seconds Destruct Timeout is 300 seconds Destination Lockout Timeout is 300 seconds Access Line Information is Enabled, Speed Updates is Disabled Destinations: 0, Tunnels: 0, Sessions: 0, Switched sessions: 0
Die folgende Beispielausgabe bestätigt, dass die Aktualisierung der Verbindungsgeschwindigkeit für das Ziel 198.51.100.21 aktiviert ist:
user@host> show services l2tp destination detail Local name: 1 Remote IP: 198.51.100.21 Tunnels: 1, Sessions: 1 State: Enabled Local IP: 203.0.113.3 Transport: ipUdp, Logical System: default, Router Instance: default Lockout State: not locked Access Line Information: Enabled, Speed Updates: Enabled ...
Verhindern, dass die LAC die Rufnummer AVP 22 an das LNS sendet
Die Rufnummer AVP 22 identifiziert in der Regel die Schnittstelle, die mit dem Kunden im Zugangsnetz verbunden ist. Wenn RADIUS die Calling-Station-Id in die Access-Accept-Nachricht einschließt, wird dieser Wert für die AVP der anrufenden Nummer verwendet. Andernfalls wird die zugrunde liegende Schnittstelle (z. B. S-VLAN IFL), auf der die PPPoE-Sitzung eingerichtet wird, für den AVP-Wert für die Anrufnummer verwendet.
Standardmäßig schließt die LAC dieses AVP in die ICRQ-Pakete (Incoming-Call Request) ein, die sie an das LNS sendet. Möglicherweise möchten Sie jedoch Ihre Netzwerkzugriffsschnittstelleninformationen ausblenden. Dazu können Sie den Tunnel so konfigurieren, dass der LAC die anrufende Nummer AVP nicht an das LNS sendet.
So deaktivieren Sie das Senden der AVP für die anrufende Nummer:
Konfigurieren Sie die Deaktivierung.
[edit services l2tp] user@host# set disable-calling-number-avp
Überschreiben Sie das Calling-Station-ID-Format für die AVP der anrufenden Nummer
Die LAC sendet Informationen über die Zugangsleitung oder den Teilnehmer an das LNS in der L2TP-Rufnummer AVP 22. Dieses AVP wird im ICRQ-Paket (Incoming-Call Request) übertragen, wenn die L2TP-Sitzung eingerichtet wird. AVP 22 identifiziert standardmäßig die Zugriffsknotenschnittstelle, die mit dem Kunden im Zugangsnetzwerk verbunden ist; Dies ist der Agent Circuit Identifier (ACI). Die LAC empfängt die ACI im PPPoE Active Discovery Request (PADR) Paket vom L2TP-Client als DSL Forum Agent-Circuit-ID VSA [26-1].
Alternativ können Sie die Anweisung verwenden, um die calling-station-id-format
im AVP gesendeten Werte zu ändern. Sie können z. B. angeben, dass der Agent Remote Identifier (ARI), der im PADR als DSL Forum Agent-Remote-ID VSA [26-2] empfangen wird, anstelle des Agent Circuit Identifier verwendet wird, dass beide verwendet werden oder dass zusätzliche Attribute enthalten sind. Der im AVP verwendete Wertesatz wird als Calling-Station-ID-Format bezeichnet. Wenn dies konfiguriert ist, wird der Wert des AVP anschließend als Calling-Station-ID-Attribut (31) an den RADIUS-Server gesendet. Weitere Informationen finden Sie unter Konfigurieren einer Calling-Station-ID mit zusätzlichen Optionen .
In einigen Fällen kann es sinnvoll sein, dass der Wert der anrufenden Nummer AVP 22 unabhängig vom RADIUS-Attributwert ist. Sie können dies tun, indem Sie das konfigurierte Calling-Station-ID-Format für den Wert überschreiben. Verwenden Sie die remote-circuit-id-format
Anweisung, um ein anderes Format für das AVP anzugeben: das ACI, das ARI oder sowohl das ACI als auch das ARI aus dem PADR-Paket.
Sie können auch Fallback-Werte konfigurieren, die in der AVP für die anrufende Nummer gesendet werden, wenn die Werte, die Sie mit der remote-circuit-id-format
Anweisung konfigurieren, nicht im PADR vorhanden sind. Sie können die Fallback-Option so konfigurieren, dass die konfigurierte Calling-Station-ID oder die zugrunde liegende Standardschnittstelle als Rufnummer AVP gesendet wird.
Bevor Sie beginnen:
Konfigurieren Sie ein Zugriffsprofil.
Konfigurieren Sie L2TP.
Konfigurieren Sie RADIUS.
So konfigurieren Sie die Außerkraftsetzung im Zugriffsprofil:
Festlegen eines ratenbegrenzenden Dienstprofils für L2TP-Verbindungsgeschwindigkeiten
Wenn eine L2TP-Sitzung ausgehandelt wird, sendet der LAC eine ICCN-Nachricht an das LNS, die Werte für die Rx-Verbindungsgeschwindigkeit (in AVP 38) und die Tx-Verbindungsgeschwindigkeit (in AVP 24) am LAC enthält. Die LAC verwendet Werte aus der besten Quelle, die zum Zeitpunkt der Verhandlung verfügbar ist. Wenn mehrere Quellen verfügbar sind, erfolgt die Auswahl auf der Grundlage der Präferenzhierarchie der Quellen. Die Quelle sind entweder RADIUS-, ANCP- oder PPPoE-IA-Tags.
Standardmäßig kann die LAC ein Dienstprofil, das in einer RADIUS-Access-Accept-Nachricht empfangen wurde, nicht als Quelle verwenden, da das Profil erst angewendet wird, wenn die Netzwerkfamilie aktiviert wird, was nach Abschluss der Sitzungsaushandlung geschieht. Wenn das LNS jedoch RFC 5515, Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions unterstützt, kann der LAC eine Aktualisierung der Verbindungsgeschwindigkeit mit Werten aus dem Serviceprofil an das LNS senden.
Ab Junos OS Version 18.1R1 können Sie ein dynamisches Serviceprofil verwenden, um die in AVP 38 und AVP 24 enthaltenen Verbindungsgeschwindigkeiten bereitzustellen, wenn die L2TP-Sitzung ausgehandelt wird. Bei der Anmeldung des Abonnenten ermittelt authd, ob der konfigurierte Dienstprofilname mit dem Profilnamen übereinstimmt, der in der Juniper Networks Activate-Service VSA (26-65) in der RADIUS Access-Accept-Nachricht angegeben ist. Wenn die Namen übereinstimmen, werden die Geschwindigkeiten entweder aus den Standardwerten im Dienstprofil oder aus den vom VSA übergebenen Parametern abgeleitet.
Diese Verarbeitung durch authd zur Herstellung der Verbindungsgeschwindigkeiten findet nur bei der Anmeldung des Teilnehmers statt. Sie tritt nicht als Reaktion auf erneute Authentifizierungs- oder CoA-Anforderungen auf.
Damit diese Funktion funktioniert, müssen Sie auch die Anweisung auf Hierarchieebene [edit services l2tp]
verwenden, um die tx-connect-speed-method
Methode auf service-profile
festzulegen. Sie müssen die effective-shaping-rate
Anweisung auch auf Hierarchieebene [edit chassis]
konfigurieren.
Sie können die Tarife direkt im Serviceprofil als Vorschlagswerte für benutzerdefinierte Variablen definieren. Alternativ können Sie die Raten konfigurieren, die von RADIUS in VSA 26-65 übergeben werden sollen. In beiden Fällen wird der erste Wert als Empfangsgeschwindigkeit (die Upstream-Rate vom Teilnehmer zum LAC) und der zweite Wert als Übertragungsgeschwindigkeit (die Downstream-Rate vom LAC zum Teilnehmer) verwendet. Der VSA kann so konfiguriert sein, dass er mehr als zwei Parameter übergibt, aber nur die ersten beiden Parameter sind für die Funktion zur Begrenzung der Dienstrate von Bedeutung.
Die Ratenwerte werden im Profil oder VSA 26-65 in Kbit/s angegeben, aber das L2TP AVP-Format erfordert Ratenwerte in bps. Wenn Sie diese Funktion aktivieren, konvertieren Standardmultiplikatoren die Raten automatisch von Kbit/s in bps. Sie können auch die Multiplikatoroptionen konfigurieren, um die Raten nach oben oder unten anzupassen. Die angepassten Werte entsprechen den RADIUS VSAs von Juniper Networks, Rx-Connect-Speed (26-163) und Tx-Connect-Speed (26-162). Diese Werte werden als solche in der Sitzungsdatenbank gespeichert. Da die Werte in der SDB verfügbar sind, bevor die L2TP-Verbindung ausgehandelt wird, werden sie von der LAC als AVP 38 und AVP 24 in die ICCN-Nachricht aufgenommen. Sie werden als RADIUS-bezogene Werte behandelt und haben daher die höchste Priorität.
Ein Parameterwert von Null bedeutet, dass die Rate nicht festgelegt ist. Wenn VSA 26-65 z. B. (0, 0) zurückgibt service-profile-name, wird in der SDB kein Wert für Rx oder Tx festgelegt.
Ein weiterer Umstand, der dazu führt, dass keine Werte in der SDB festgelegt werden, ist, wenn VSA 26-65 keine Parameter übergibt und Sie keine Standardwerte im Dienstprofil festgelegt haben. In diesem Fall gibt es keine Werte für authd, die abgeleitet werden können, und daher nichts, was in der SDB für Rx oder Tx platziert werden kann.
Wenn der Dienst, der zum Einrichten der Ratenbegrenzer verwendet wird, deaktiviert oder gelöscht wird, löscht authd diese Ratenbegrenzerwerte aus der Abonnentensitzung. Wenn der Dienst wieder aktiviert wird, setzt authd die Ratenbegrenzer nicht wieder ein.
So konfigurieren Sie die LAC-Verbindungsgeschwindigkeiten so, dass sie bei der Anmeldung aus einem dynamischen Serviceprofil abgeleitet werden, und passen optional die Raten an:
Angenommen, Sie konfigurieren eine dynamische Servicerichtlinie, l2tp-service. Die Richtlinie enthält benutzerdefinierte Variablen (Upstream- und Downstream-Variablen) mit Standardwerten von 20.000 Kbit/s bzw. 30.000 Kbit/s. Die Upstream-Variable wird für den Eingangsfilter (Eingang) und die Downstream-Variable für den Ausgabefilter (Ausgangsfilter) verwendet.
[edit dynamic-profiles l2tp-service] user@host# set variables upstream default-value 20000 user@host# set variables downstream default-value 30000 user@host# set variables aggregate default-value 50000 user@host# interfaces pp0 “$junos-interface-unit” family inet filter input ”$upstream” user@host# interfaces pp0 “$junos-interface-unit” family inet filter output ”$downstream”
Anschließend konfigurieren Sie den folgenden Dienstratenbegrenzer, der angibt, dass bei der Rückgabe einer Dienstrichtlinie mit dem Namen l2tp-service der Rx-Wert in der Richtlinie oder vom VSA übergeben mit 1005 multipliziert wird. Der Tx-Wert wird mit 1003 multipliziert.
[edit access] user@host# set service-rate-limiter service-name l2tp-service user@host# set service-rate-limiter rx-multiplier 1005 user@host# set service-rate-limiter tx-multiplier 1003
Angenommen, ein Abonnent meldet sich an, und die Access-Accept-Nachricht vom RADIUS-Server enthält den Activate-Service VSA, 26-55, der l2tp-service angibt. Was als nächstes geschieht, hängt von den Parametern ab, die von der VSA übergeben werden.
Der VSA enthält "l2tp-service" ohne Parameter. In der SDB werden folgende Werte gespeichert:
Rx ist der Standardwert in der Richtlinie multipliziert mit dem konfigurierten Multiplikator: 20000 Kbit/s x 1005 = 20.100.000 bps.
Tx ist der Standardwert in der Richtlinie multipliziert mit dem konfigurierten Multiplikator: 30000 Kbit/s x 1003 = 30.090.000 bps.
Der VSA enthält "l2tp-service(10000, 15000)". In der SDB werden folgende Werte gespeichert:
Rx ist der erste Parameter, der vom VSA übergeben wird, multipliziert mit dem konfigurierten Multiplikator: 10000 Kbit/s x 1005 = 10.050.000 bps.
Tx ist der zweite Parameter, der von der VSA übergeben wird, multipliziert mit dem konfigurierten Multiplikator: 15000 Kbit/s x 1003 = 15.045.000 bps.
Der VSA enthält "l2tp-service(10000)". In der SDB werden folgende Werte gespeichert:
Rx ist der erste (und einzige) Parameter, der vom VSA übergeben wird, multipliziert mit dem konfigurierten Multiplikator: 10000 Kbit/s x 1005 = 10.050.000 bps.
Da der VSA keinen zweiten Parameter übergibt, ist Tx der Standardwert in der Richtlinie multipliziert mit dem konfigurierten Multiplikator: 30000 Kbit/s x 1003 = 30.090.000 bps.
Der VSA enthält "l2tp-service(10000, 0)". In der SDB werden folgende Werte gespeichert:
Rx ist der erste Parameter, der vom VSA übergeben wird, multipliziert mit dem konfigurierten Multiplikator: 10000 Kbit/s x 1005 = 10.050.000 bps.
Da der zweite übergebene Parameter Null ist und Null bedeutet, dass die Rate nicht festgelegt ist, wird kein Wert in der SDB für Tx gespeichert.
Der VSA enthält "l2tp-service(0, 0)". In der SDB werden folgende Werte gespeichert:
Da ein übergebener Wert von Null bedeutet, dass die Rate nicht festgelegt ist, wird weder für Rx noch für Tx ein Wert in der SDB gespeichert.
Der VSA enthält "l2tp-service(10000, 15000, 4000000)". In der SDB werden folgende Werte gespeichert:
Rx ist der erste Parameter, der vom VSA übergeben wird, multipliziert mit dem konfigurierten Multiplikator: 10000 Kbit/s x 1005 = 10.050.000 bps.
Tx ist der zweite Parameter, der von der VSA übergeben wird, multipliziert mit dem konfigurierten Multiplikator: 15000 Kbit/s x 1003 = 15.045.000 bps.
tx-connect-speed-method
LAC aktivieren.