Dynamic data services
The dynamic data services feature enables a zero-touch, single-ended provisioning model for business services. Its implementation is different for a router running in classic or model-driven management interface configuration mode:
The feature is not available for a router running in mixed configuration mode.
Dynamic data services in model-driven configuration mode
Dynamic data services in model-driven configuration mode can be built with the RADIUS-triggered pySROS script execution feature. See RADIUS-triggered pySROS script execution.
-
The feature is supported in the model-driven configuration mode only.
-
This is a limited support feature intended for laboratory use only, and should not be used in production networks. Contact your Nokia technical support representative for additional details.
RADIUS-triggered pySROS script execution
This feature enables the execution of a pySROS script based on the RADIUS vendor-specific attributes received in an Access-Accept or CoA message for a subscriber session.
By associating a pySROS script policy and pySROS script parameters with an IPoE or PPPoE subscriber session, the subscriber session becomes a control channel for the pySROS script execution. Association is achieved by including both Alc-PySROS-Script-Policy and Alc-PySROS-Script-Params VSAs in an Access-Accept or CoA message for the subscriber session. The script executes as follows:
-
The pySROS script is executed with scriptAction = create when first associated and if the subscriber session was successfully created. The script parameters are passed to the script as an opaque value as shown in the following figure.
Figure 1. Subscriber session as control channel: RADIUS VSA triggers pySROS (create) 
The pySROS script execution with scriptAction = create can also be triggered mid-session via a CoA or reauthentication if there is no pySROS data previously saved in /state.
-
The pySROS script is executed with scriptAction = update when the script policy or script parameters change mid-session. The updated script parameters are passed to the script as an opaque value as shown in the following figure.
Figure 2. Subscriber session as control channel: RADIUS VSA triggers pySROS (update) 
The pySROS script execution with scriptAction = update can also be triggered via a reauthentication when pySROS VSAs in the Access-Accept are different from pySROS data saved in /state.
-
The pySROS script is executed with scriptAction = delete when the control channel is deleted from the system. Script parameters retrieved from the subscriber session /state are passed to the script as an opaque value as shown in the following figure.
Figure 3. Subscriber session as control channel: RADIUS VSA triggers pySROS (delete) 
RADIUS vendor-specific attributes and configuration
The following table specifies the Alc-PySROS-Script-Policy and Alc-PySROS-Script-Params VSAs. For more information see the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide.
|
Attribute name |
Type |
Description |
|---|---|---|
|
Alc-PySROS-Script-Policy 241.26.6527.98 |
(Extended-Vendor-Specific-1) string 1 to 32 characters |
References a script policy configured in /configure system script-control script-policy. The script policy references the pySROS script to execute and has additional configuration parameters for script runs, such as the script output location, maximum run time, and so on. |
|
Alc-PySROS-Script-Params 241.26.6527.99 |
(Extended-Vendor-Specific-1) string Up to 8 VSAs per message. maximum concatenated string length = 1000 bytes |
Parameters available in the PySROS script. The parameters can cross an attribute boundary: the concatenation of all Alc-PySROS-Script-Params attributes as they appear in a RADIUS message are passed as an opaque string to the pySROS script via the pysros.esm module. The parameter string is available as event.eventparams["scriptParams"] in the pysros.esm.event class that is returned when calling the pysros.esm.get_event() function. Preferably, use an attribute value that is easily consumable in Python, such as a dictionary or a JSON string. |
The Alc-PySROS-Script-Policy attribute references a script-policy in the configuration (Strikethrough configuration elements are not applicable for RADIUS-triggered pySROS script execution).
/configure system script-control
+-- script-policy <string> owner <string>
+-- admin-state <keyword>
+-- expire-time <number | keyword>
+-- lifetime <number | keyword>
+-- lock-override <boolean>
+-- max-completed <number>
+-- python-lifetime <number>
+-- python-script
| +-- name <reference>
+-- results <string>
+-- script
+-- name <reference>
+-- owner <reference>
The python-script name references a python script in the configuration (Strikethrough configuration elements are not applicable for RADIUS-triggered pySROS script execution).
/configure python
+-- python-script <string>
+-- action-on-fail <keyword>
+-- admin-state <keyword>
+-- description <string>
+-- protection
| +-- hmac-sha256 <plain-text | hashed-value>
+-- run-as-user <string>
+-- urls <string>
+-- version python3
The Alc-PySROS-Script-Params attribute contains parameters that are available in the pySROS script via the pysros.esm module. The concatenation of all Alc-PySROS-Script-Params attributes as they appear in a RADIUS message are passed as an opaque string to the pySROS script as shown in the following figure.
pysros.esm module details
The pysros.esm module provides functionality to obtain data from the event that caused subscriber management to trigger the execution of a Python application.
For more information see pySROS API documentation.
The pysros.esm.get_event() function returns an Event class with eventparameters as a parameter that returns several {key, value} pairs in the form of a Python dictionary. The {key, value} pairs contain the attributes provided by subscriber management, such as a script action, script parameters, and control channel details.
Output example
Snippet of a pySROS script and its output
#!/usr/bin/env python3
from pysros.esm import get_event
def main():
event = get_event()
print("eventparameters.keys =",event.eventparameters.keys())
print("----------")
for key in event.eventparameters.keys():
print(" +", key, "=", event.eventparameters[key])
print("----------")
eventparameters.keys = ('scriptAction', 'scriptParams', 'serviceName', 'subscriberId', 'sap', 'mac', 'pppoeSessionId', 'username')
----------
+ scriptAction = create
+ scriptParams = {'SVC':{'id':100000, 'name':'dynsvc-epipe-1’},
'SAP1':{'id':'1/x1/1/c1/4:2211.2131', 'desc':'SAP 1’, 'ingr_qos':'default’,'egr_qos':'default','agg_rate':10000},
'SAP2':{'id':'1/x1/1/c1/4:2212.2131', 'desc':’SAP 2’,
'ingr_qos':'default', 'egr_qos':'default'}}
+ serviceName = vprn-submgmt-pysros
+ subscriberId = pppoe-cc-1@vprn2030.com
+ sap = 1/x1/1/c1/4:2211.2032
+ mac = 00:bb:02:00:cc:03
+ pppoeSessionId = 1
+ username = pppoe-cc-1@vprn2030.com
----------
Common {key, value} pairs in eventparameters
The following table describes the common {key, value} pairs available in eventparameters.
|
Key |
Type |
Value |
|---|---|---|
|
scriptAction |
string |
create: new control channel is created. The Alc-PySROS-Script-Policy or Alc-PySROS-Script-Params VSAs are received in an Access-Accept or in a CoA message for the first time for a subscriber session (control channel) update: existing control channel is updated with changed script policy or script parameters (stored values are different from newly received values) delete: the control channel is deleted from the system |
|
scriptParams |
string |
A copy of the Alc-PySROS-Script-Params string. These parameters are passed from RADIUS to the pySROS script in an opaque way. Note: Nokia recommends using a format that is easily consumable in a Python script (for example, a dictionary or JSON string). |
Control channel specific {key, value} pairs in eventparameters
The following table describes the control channel specific {key, value} pairs available in eventparameters.
|
Control Channel |
Key |
Type |
Value |
||
|---|---|---|---|---|---|
|
PPPoE Session |
IPoE session |
IPoE host |
|||
|
Yes |
Yes |
Yes |
subscriberId |
string |
The subscriber ID of the subscriber session |
|
Yes |
Yes |
Yes |
serviceName |
string |
The name of the service where the subscriber session is active |
|
Yes |
Yes |
Yes |
sap |
string |
The SAP ID of the subscriber session |
|
Yes |
Yes |
Yes |
mac |
string |
The MAC address of the subscriber session |
|
Yes |
No |
No |
pppoeSessionId |
integer |
The PPPoE session ID of the subscriber session |
|
Yes |
No |
No |
username |
string |
The PPPoE user name of the subscriber session |
|
No |
Yes |
No |
circuitId |
string |
The circuit ID (IPv4) or Interface ID (IPv6) of the IPoE session. Only included when part of the IPoE session key |
|
No |
Yes |
No |
remoteId |
string |
The remote ID of the IPoE session. In case of IPv6, the enterprise ID is omitted. Only included when part of the IPoE session key |
|
No |
No |
Yes |
ipAddress |
string |
The IPv4 or IPv6 address or prefix of the IPoE host |
Dynamic data services in classic configuration mode
Introduction to dynamic data services
Dynamic data services enables a zero-touch, single-ended provisioning model for business services. Two deployment models are available:
With control channel
Triggered by the authentication of a single or dual-stack PPPoE or IPoE session as a business CPE control channel, parameters are passed in a RADIUS Access-Accept or CoA message to set up a Layer 2 or Layer 3 data service.
Without control channel
RADIUS or local authentication of a dynamic data service data trigger provides the required parameters to set up a Layer 2 or Layer 3 data service.
Dynamic Data Services support includes:
Epipe VLL services
Epipe VLL services with dynamic MS-PWs (FEC 129) or spoke SDP
EVPN based Epipe service
VPLS services
VPLS services with BGP-AD pseudowire
VPLS service with spoke SDP or mesh SDP
EVPN based VPLS service
IES and VPRN services
MVPN services
Routing policy, filter, operational groups and OAM-PM provisioning
The full list of supported configuration commands can be displayed with the tools dump service dynamic-services command-list CLI command. Dynamic data service SAPs must be located on dot1q- or QinQ-encapsulated Ethernet, anchoring or satellite ports and can be part of a LAG.
A Python script interface adds a flexible abstraction layer that reduces the OSS integration cost; only the business user specific service parameters, such as service type, IP address, QoS, and filter parameters, are required from RADIUS or local authentication. These parameters are then used in the Python script to generate a CLI template to set up the target Dynamic Data Service.
Dynamic data services configuration can be updated via a RADIUS CoA message.
Both XML accounting and RADIUS accounting for up to two different RADIUS destinations can be activated on a dynamic data service SAP.
RADIUS-triggered dynamic data services associated with a PPPoE or IPoE session as control channel
See the ‟RADIUS-Triggered Dynamic Data Service Provisioning” section in the Advanced Configuration Guide for a detailed description.
Data-triggered dynamic data services
In the data-triggered dynamic data services model, as shown in Data-triggered dynamic data services, any frame arriving on a dynamic data services capture SAP can result in RADIUS or local authentication. The dynamic data service is then created from a Python script that generates CLI snippets using parameters obtained from authentication.
Data trigger
A dynamic services data trigger is an object that is created when a frame received on a dynamic services capture SAP is sent to the control plane for authentication. A dynamic services data trigger is uniquely identified with its SAP ID. If the dynamic services data trigger was received on capture SAP x / y / z:*.* with outer-tag = a and inner-tag = b, then the dynamic service data trigger SAP ID is ‟x / y / z:a.b”. For each dynamic services data trigger, the following information is stored.
| Data trigger information | Description |
|---|---|
Acct-Session-ID |
The RADIUS accounting session ID for this dynamic services data trigger. This accounting session ID is used as accounting multisession ID in RADIUS accounting for associated dynamic services. It can also be used as a key in CoA or Disconnect Messages to set up or terminate associated dynamic services. |
MAC |
The MAC address learned to set up this dynamic service data trigger. The MAC address is included in the Access-Request message for RADIUS authentication. |
IP |
The IPv4 or IPv6 address learned to set up this dynamic service data trigger. If the data trigger packet was not an IP packet, then this field is empty. When available, the IP address is included in the RADIUS authentication and accounting messages. |
State |
The current state of the dynamic service data trigger: Pending: (initial state) data trigger received and authentication started Accepted: (transient state) authentication succeeded; dynsvc script started but not yet completed sapCreated: (final state) corresponding dynamic services SAP created |
The dynamic services data trigger information can be displayed as follows:
# show service dynamic-services data-triggers
===============================================================================
Dynamic Services Data-triggers
===============================================================================
SAP : 1/1/4:1214.101
-------------------------------------------------------------------------------
Acct session-ID : 144DFF0000009156A24138
MAC : 00:51:00:dd:01:01
IP :
State : sapCreated
-------------------------------------------------------------------------------
No. of Data-triggers: 1
===============================================================================
For a data-triggered dynamic data service to be successfully set up, a dynamic services SAP equal to the data trigger SAP ID must be created.
In the same way as the control channel model, multiple dynamic data services can be associated with a single dynamic services data trigger: up to 32 dynamic services during data trigger authentication or up to 4000 in total through CoA. When the dynamic services SAP that corresponds to a data trigger is deleted (teardown action), then all dynamic services associated with that dynamic services data trigger are deleted (teardown action).
Dynamic services data trigger capture SAP
In the same way as an Enhanced Subscriber Management (ESM) capture SAP is configured, a dynamic services data trigger capture SAP is configured in a VPLS service and captures frames for authentication. A dynamic service data trigger capture SAP does not forward traffic within the VPLS service, and no MAC learning occurs.
A VPLS capture SAP becomes a dynamic services data trigger capture SAP when a dynamic services policy is configured and the dynamic-services context is enabled (no shutdown). The dynamic services policy specifies the authentication mechanism to be used as detailed in the authentication sections below.
For example:
configure
service
vpls 10 customer 1 create
sap 1/1/4:1214.* capture-sap create
description "Dynamic Services Data Trigger capture-sap"
dynamic-services
dynamic-services-policy "dyn-svc-1"
no shutdown
exit
no shutdown
exit
no shutdown
exit
exit
The trigger-packet type needs to be configured. A dynamic services data trigger capture-sap captures any valid Ethernet frames, including non-IP frames.
Valid dynamic services data trigger capture SAPs are:
dot1q-encapsulated Ethernet, anchoring, satellite ports or LAGs
sap x/y/z:*
lag-x:*
pxc-x.a:*
esat-x/y/z:*
QinQ-encapsulated Ethernet, anchoring, satellite ports or LAGs:
sap x/y/z:*.*
sap lag-x:*.*
sap x/y/z:tag.*
sap x/y/z:*.tag
sap lag-x:tag.*
sap lag-x:*.tag
pxc-x.a:*.*
pxc-x.a:tag.*
esat-x/y/z:*.*
esat-x/y/z:tag.*
Enhanced Subscriber Management (ESM) and dynamic services data trigger cannot be enabled simultaneously on a single capture SAP: a no shutdown command of the dynamic-services CLI context is mutually exclusive when configuring an ESM trigger-packet type.
Use the following CLI commands to display capture SAP statistics:
To display the number of data trigger packets forwarded to the CPM and dropped on the IOM:
# show service id <service-id> sap <sap-id> sap-stats =============================================================================== Service Access Points(SAP) =============================================================================== --- snip --- ------------------------------------------------------------------------------- Sap Statistics ------------------------------------------------------------------------------- Last Cleared Time : N/A Packets Octets CPM Ingress : 108 6696 Forwarding Engine Stats Dropped : 6144 405504Table 5. Data trigger packets forwarded/dropped counters Counter Description CPM Ingress
Number of dynamic service data triggers received on the capture SAP that are forwarded to CPM
Forwarding Engine Stats Dropped
Number of dynamic service data triggers is received on the capture SAP that are dropped on IOM
To display the dynamic services capture SAP control plane statistics (data triggers received and data trigger drop reason counters):
# show service id 10 dynamic-services capture-sap 1/1/4:1214.* statistics =============================================================================== Dynamic Services Capture SAP 1/1/4:1214.* Statistics =============================================================================== Data packets received by SAP : 3 ------------------------------------------------------------------------------- Drop Reason Counters ------------------------------------------------------------------------------- No policy configured at capture SAP level : 0 No authentication configured in policy : 0 Data-trigger already exists : 0 Lockout is active : 0 Reached data-trigger system limit : 0 No memory available : 0 Unsuccessful authentication : 1 No data-trigger SAP-id in authentication : 0 Corresponding dynamic SAP is not created : 0 ===============================================================================Table 6. Data triggers received/dropped reason counters Counter Description Data packets received by SAP
Number of dynamic service data triggers received on the capture-sap that reached the CPM
No policy configured at capture SAP level
No dynamic services policy configured at the capture-sap; required to determine the authentication destination.
No authentication configured in policy
The authentication section in the specified dynamic services policy is missing or incomplete.
Data-trigger already exists
A new data trigger frame is received for an existing data trigger that is authenticated, but the corresponding dynamic SAP is not yet created. The new data trigger packet is dropped.
Lockout is active
The data trigger for this managed SAP is currently in a lockout state because of previous authentication failures.
Reached data-trigger system limit
The maximum number of dynamic service data triggers supported on the system is reached. Additional data triggers are dropped.
No memory available
There is not enough system memory available to process the data trigger.
Unsuccessful authentication
The authentication for a data trigger on this capture SAP failed or timed out.
No data-trigger SAP-id in authentication
The dynamic services data trigger SAP ID is not provided in authentication. This is a mandatory parameter.
Corresponding dynamic SAP is not created
The data trigger successfully authenticated but the corresponding dynamic SAP was not created. This is typically caused by a dynamic services script error.
to clear the dynamic services capture SAP control plane statistics:
# clear service id <service-id> dynamic-services capture-sap <sap-id> statistics
RADIUS authentication
When a valid Ethernet frame is received on a dynamic services data trigger capture SAP, it is sent to the control plane for authentication. The dynamic services policy configured at the capture SAP specifies the RADIUS authentication parameters, as shown in the following example:
configure service
vpls 10 customer 1 create
sap 1/1/4:1214.* capture-sap create
description "Dynamic Services Data Trigger capture-sap"
dynamic-services
dynamic-services-policy "dyn-svc-1"
no shutdown
exit
no shutdown
exit
no shutdown
exit
dynamic-services
dynamic-services-policy "dyn-svc-1" create
---snip---
authentication
password "RwXx4x0jao776C3CGlDBKVaNOd//ySXw" hash2
server-policy "aaa-server-policy-1"
exit
---snip---
exit
exit
Local authentication and RADIUS authentication are mutually exclusive and cannot be configured simultaneously in a config>service>dynsvc>plcy>authentication context.
The server-policy CLI command references the config>aaa>radius-server-policy policy-name to be used for authentication.
The password CLI command specifies the password that is used in all RADIUS Access-Request messages.
RADIUS access-request message attributes specifies the attributes that are included in the RADIUS Access-Request message for dynamic services data triggers.
| RADIUS attribute | Description |
|---|---|
[1] User-Name |
The username format for dynamic services data trigger authentication is fixed to nas-port-id (SAP). |
[2] Password |
The password as configured in the authentication section of the dynamic-services-policy. |
[4] NAS-IP-Address |
The outband management interface or system interface IPv4 address. Only included if the RADIUS server is reachable via an IPv4 address. |
[95] NAS-IPv6-Address |
The outband management interface or system interface IPv6 address. Only included if the RADIUS server is reachable via an IPv6 address. |
[44] Acct-Session-Id |
A unique accounting session ID (number format) per dynamic service data trigger. Included as [50] Acct-Multi-Session-Id in radius accounting for all dynamic services that are associated with this data trigger. |
[87] NAS-Port-Id |
The dynamic service data trigger sap-id |
[32] NAS-Identifier |
The system name of the router |
[26-6527-27] Alc-Client-Hardware-Addr |
The MAC address of the data trigger frame that resulted in the authentication. Fixed format (xx:xx:xx:xx:xx:xx) |
[8] Framed-IP-Address |
The IPv4 source address of the IPv4 data trigger frame that resulted in the authentication. Not included if the data trigger frame is not an IPv4 packet. |
[26-6527-99] Alc-Ipv6-Address |
The IPv6 source address of the IPv6 data trigger frame that resulted in the authentication. Not included if the data trigger frame is not an IPv6 packet. |
The attributes that must be returned in the Access-Accept message are the same as for RADIUS-triggered Dynamic Data Services associated with an IPoE or PPPoE session as a control channel.
Local authentication
Local authentication is available for data-triggered dynamic services deployments where RADIUS is used for accounting and dynamic changes (CoA) but cannot provide the actual service provisioning parameters.
When a valid Ethernet frame is received on a dynamic services data trigger capture SAP, it is sent to the control plane for authentication. The dynamic services policy configured at the capture SAP specifies the local authentication parameters, as shown in the following example:
configure service
vpls 10 customer 1 create
sap 1/1/4:1214.* capture-sap create
description "Dynamic Services Data Trigger capture-sap"
dynamic-services
dynamic-services-policy "dyn-svc-2"
no shutdown
exit
no shutdown
exit
no shutdown
exit
dynamic-services
dynamic-services-policy "dyn-svc-2" create
---snip---
authentication
local-auth-db "dynsvc-db-1"
exit
---snip---
exit
exit
Local authentication and RADIUS authentication are mutually exclusive and cannot be configured simultaneously in a config>service>dynsvc>plcy>authentication context.
The local-auth-db CLI command references the local authentication database to be used for authentication, as shown in the following example:
configure service
dynamic-services
local-auth-db "dynsvc-db-1" create
user-name "1/1/4:1214.101" create
description "dynsvc: epipe"
index 1 create
dynamic-services-policy "dyn-svc-2"
sap-id "1/1/4:1214.101"
script-parameters-1 "epipe_1={'t':('dynsvc-epipe-1',None,None,10,11)}"
accounting 1 create
stats-type volume-time
update-interval min 30
exit
exit
no shutdown
exit
no shutdown
exit
exit
A username is used as a key for a lookup in the local authentication database. The username format for dynamic service data triggers is fixed to the SAP ID of the data trigger. For each username entry (data trigger sap-id), multiple dynamic service SAPs can be specified (indexes). The index enables multiple dynamic service SAPs to be associated with a single dynamic service data trigger.
The following data can be specified for each index (dynamic service SAP) in a user-name entry:
dynamic service sap-id (mandatory)
The dynamic service SAP ID that is created. The SAP ID of one of the indexes must match the dynamic service data trigger sap-id.
dynamic-services-policy dynsrv-policy-name (optional)
Specifies the policy to use for setting up the dynamic service. If not specified, the policy provisioned at the dynamic service data trigger capture-sap is used.
script-parameters (mandatory)
Script parameters are used as input to the dynamic data service Python script. They are specified as four strings of up to 250 characters each. The concatenation of all four script parameter strings are passed to the Python script and must be formatted as function-key dictionary. The function-key specifies which Python functions is called, and dictionary contains the actual parameters in a Python dictionary structure format. The format should match the format of the [26-6527-165] Alc-Dyn-Serv-Script-Params attribute when RADIUS authentication is used.
accounting overrides (optional)
For each of the two RADIUS accounting destinations, the stats-type and update-interval can be specified. These parameters override the configured value in the dynamic services policy:
stats-type specifies if dynamic service RADIUS accounting should be enabled or disabled. RADIUS accounting is enabled by specifying the statistics type: volume and time or time only. RADIUS accounting is disabled when no stats-type is specified.
update-interval specifies the time between each dynamic data service accounting interim update. The generation of interim accounting updates is disabled when no update-interval is specified.
A local authentication database can only be used to authenticate a dynamic service data trigger and provide parameters to set up associated dynamic services. The script action cannot be specified and is always set to ‟setup”.
The setup timeout for Access=Accept (CLI command: configure service dynamic-services timers setup-timeout access-accept timeout) also applies for local authenticated dynamic services.
Data-triggered dynamic service provisioning
After authentication, the mechanism to set up, modify, and tear down a data triggered dynamic service is the same as for RADIUS-triggered Dynamic Data Services associated with an IPoE or PPPoE session as a control channel.
The auto-provisioning of a data-triggered dynamic service is initiated by the RADIUS messages or local authentication as listed in Dynamic service script actions.
Notes:
Using the Nas-Port-Id as a key in a CoA or Disconnect-Message targets the corresponding dynamic services SAP; this also occurs when the Nas-Port-Id corresponds with the SAP ID of a data trigger.
Using the Acct-Session-Id as a key in a CoA or Disconnect-Message targets:
the corresponding dynamic services SAP if the Acct-Session-Id belongs to a dynamic services SAP that is not a dynamic services data trigger SAP
the data trigger SAP if the Acct-Session-Id belongs to the dynamic services data trigger SAP
In the event of a tear down, if the dynamic services SAP ID is a dynamic service data trigger SAP ID, all dynamic services associated with that dynamic services data trigger are also removed.
Action |
Dynamic service script action |
Comments |
|
|---|---|---|---|
Rx Access-Accept or local authentication (dynamic services data trigger authentication) |
Setup |
Up to 32 dynamic data services SAPs in a single message The dynamic services SAP that corresponds with the data trigger (also referred to as the dynamic services data trigger sap-id) must be part of this list. The Alc-Dyn-Serv-Script-Action VSA is optional for RADIUS authentication. |
|
Modify / Teardown |
Not supported |
||
Rx CoA (Nas-Port-Id or Acct-Session-Id of a dynamic service SAP different from the data trigger) |
Setup |
Not supported |
|
Modify |
Only a single dynamic data service per message Mandatory VSAs: Alc-Dyn-Serv-Script-Action Alc-Dyn-Serv-Script-Params |
||
Teardown |
Tear down the dynamic service of the dynamic services SAP identified by the Acct-Session-Id or Nas-Port-Id. Alc-Dyn-Serv-Script-Action VSA is mandatory |
||
Rx CoA (Nas-Port-Id of a data trigger) |
Setup |
Not supported. Nas-Port-Id always targets the dynamic services SAP and not the data trigger. |
|
Modify |
Only a single dynamic data service per message Mandatory VSAs: Alc-Dyn-Serv-Script-Action Alc-Dyn-Serv-Script-Params |
||
Teardown |
Tear down the dynamic service of the dynamic services SAP identified by the Nas-Port-Id. Because this is the data trigger SAP that is deleted, all dynamic services SAPs associated with the data trigger are also deleted. Alc-Dyn-Serv-Script-Action VSA is mandatory |
||
Rx CoA (Acct-Session-Id of a data trigger) |
Setup |
Only a single dynamic service SAP per message When successful, the dynamic services SAP is associated with the data trigger identified by the specified Acct-Session-Id. Mandatory VSAs: Alc-Dyn-Serv-Script-Action Alc-Dyn-Serv-SAP-Id Alc-Dyn-Serv-Script-Params Alc-Dyn-Serv-Policy (if no ‟default” policy configured) |
|
Modify |
Only a single dynamic service per message Modify the dynamic service of the dynamic services SAP identified by the Alc-Dyn-Serv-SAP-Id. The dynamic services SAP must be associated with the data trigger identified with the specified Acct-Session-Id. Mandatory VSAs: Alc-Dyn-Serv-Script-Action Alc-Dyn-Serv-SAP-Id Alc-Dyn-Serv-Script-Params |
||
Teardown |
Tear down the dynamic service of the dynamic services SAP identified by the Alc-Dyn-Serv-SAP-Id. The dynamic services SAP must be associated with the data trigger identified with the specified Acct-Session-Id. If the dynamic services SAP identified by the Alc-Dyn-Serv-SAP-Id is a data trigger sap, then teardown the dynamic services of all dynamic services saps associated with that data trigger Mandatory VSAs: Alc-Dyn-Serv-Script-Action Alc-Dyn-Serv-SAP-Id |
||
Rx Disconnect Message (Nas-Port-Id or Acct-Session-Id of a dynamic service SAP different from a data trigger) |
N/A |
Tear down the dynamic service of the dynamic services SAP identified by the Acct-Session-Id or Nas-Port-Id |
|
Rx Disconnect Message (Nas-Port-Id or Acct-Session-Id of a data trigger) |
N/A |
Tear down the dynamic services of all dynamic services SAPs associated with the data trigger identified by the Acct-Session-Id or Nas-Port-Id |
|
A data-triggered dynamic service must be explicitly removed by one of the following:
with a RADIUS Disconnect message containing the Acct-Session-Id or NAS-Port-Id as key
with a RADIUS CoA message containing the Acct-Session-Id or NAS-Port-Id as key and Alc-Dyn-Serv-Script-Action VSA with value 3 (teardown)
with a CLI clear command: clear>service>dynamic-services>data-trigger sap sap-id
All dynamic service SAPs associated with the dynamic services data trigger is removed.
with a CLI tools command: tools>perform>service>dynamic-services> evaluate-script sap sap-id control-session acct-session-id action teardown
The control session accounting session ID corresponds to the dynamic services data trigger accounting session ID.
The removal of a dynamic service SAP that is a data trigger SAP results in the removal (teardown) of all dynamic service SAPs associated with that dynamic services data trigger.
To prevent a data-triggered dynamic service from being immediately set up again after it was removed (because traffic is still being received), the following procedures can be used:
Authentication failure
Update the configuration of the RADIUS server or local authentication such that the authentication for the dynamic service data trigger fails
Tear down the dynamic service
The dynamic service is not set up again because the data trigger authentication fails, resulting in a host-lockout when provisioned.
VID filter on the capture-sap
Add the data trigger encapsulation to a VID filter (ingress MAC filter of type vid) that is applied on the data trigger capture-sap
Tear down the dynamic service
The dynamic service is not set up again because the data trigger is now dropped by the VID filter applied on the capture-sap
Control plane protection
As a dynamic services data trigger capture-sap potentially forward all valid Ethernet frames for authentication to the control plane, control plane protection mechanisms are required to prevent overload conditions.
capture-sap data trigger packet throttling (frames dropped at IOM)
The number of data trigger packets sent to the control plane via the ingress forwarding complex is rate-limited based on a hash using the sap ID, outer tag, and inner tag as the key. The per-hash result is that a maximum of 1 frame is forwarded to the control plane.
This throttling mechanism is always enabled and has no configuration options. It guarantees fairness between different encapsulation while limiting the frame rate sent to the control plane.
Blocking VLANs from authenticating (frames dropped at the IOM)
This can be achieved by applying ingress MAC filters of type VID with the capture-sap command. In the example below, frames with encap 1/1/4:1214.20 is dropped by the VID filter.
configure service vpls <service-id> customer <customer-id> sap 1/1/4:1214.* capture-sap dynamic-services dynamic-services-policy <dynsvc-policy-name> no shutdown exit ingress filter mac 10 exit exit exit exit filter mac-filter 10 create default-action forward type vid entry 10 create match frame-type ethernet_II outer-tag 20 4095 exit action drop exit exit exit exitDynamic service data trigger rate limiting in the control plane (frames dropped at the CPM)
An overall rate limit of dynamic service data triggers limits the number of frames that come from the different IOMs to an acceptable rate for the control plane to handle.
Control plane rate-limiting for dynamic service data triggers is always enabled and has no configuration options.
Using a lockout mechanism to protect the RADIUS infrastructure from overload because of permanent failing authentications of Python script errors.
The existing Enhanced Subscriber Management (ESM) host lockout mechanism can be enabled on a dynamic services data trigger capture-sap.
The dynamic services data trigger sap-id is used as a key for the host-lockout context. A host-lockout context is created whenever a data trigger is deleted:
Authentication failures: RADIUS Access Reject, RADIUS Access-Accept with a wrong or missing data trigger SAP ID, timeout, local authentication lookup failure, local authentication returns a wrong or no data-trigger sap-id.
No data trigger SAP created within the configured dynamic services access-accept setup timeout (30 seconds by default):
configure service dynamic-services timers setup-timeout access-accept <timeout>
A dynamic services Python script failure
A clear command on a data trigger:
clear service dynamic-services data-trigger sap <sap-id>
A tear down of a data trigger initiated via a CoA or Disconnect Message
The last two bullets are tear down operations that occur infrequently and should not result in an actual lockout; only the host lockout context is created and should disappear again when the lockout-reset-time expires. This is configured in the host-lockout-policy:
configure subscriber-mgmt host-lockout-policy <policy-name> lockout-reset-time <seconds> (default 60 seconds).To enable host lockout for dynamic services data trigger, configure a host-lockout-policy at the dynamic services data trigger capture-sap:
configure service vpls <service-id> customer <customer-id> sap <sap-id> capture-sap dynamic-services dynamic-services-policy <dynsvc-policy-name> no shutdown exit host-lockout-policy <policy-name> exit exitThe host-lockout-policy is configured in the config>subscr-mgmt CLI context. For data-triggered dynamic services, the host-key in the policy must be set to all which is achieved with the no host-key CLI command (default). Configuring the host key to mac in a host lockout policy associated with a dynamic service data trigger capture-sap is a configuration error and results in a faulty host lockout behavior.
Use the following show command to display active dynamic services data trigger capture SAP lockouts (the capture SAP must be used as the sap-id):
# show subscriber-mgmt host-lockout-policy "host-lockout-1" all sap 1/1/4:1214.* =============================================================================== Host Lockout Policy "host-lockout-1" =============================================================================== Description Host lockout policy Last Mgmt Change 01/25/2016 16:37:47 Lockout time min 10 Lockout time max 3600 Lockout reset time 60 Max lockout hosts 100 Host key all ------------------------------------------------------------------------------- Active Lockouts for SAP: 1/1/4:1214.* =============================================================================== circuit-id/ elapsed current elapsed next nr mac/ reset lock lock lock of remote-id time (s) time (s) time (s) time (s) lockouts ------------------------------------------------------------------------------- :1214.101 0 10 1 20 1 ------------------------------------------------------------------------------- Nr of active lockouts 1 Nr of lockouts in grace period 0 Nr of total lockouts: 1 ------------------------------------------------------------------------------- Totals for Host Lockout Policy "host-lockout-1" ------------------------------------------------------------------------------- Nr of active lockouts 1 Nr of lockouts in grace period 0 Nr of total lockouts: 1 ===============================================================================Use the following command to clear active dynamic services data trigger capture SAP lockouts (the capture SAP must be used as the sap-id):
# clear subscriber-mgmt host-lockout-policy [policy <host-lockout-policy- name>] <lockout-state> # clear subscriber-mgmt host-lockout-policy sap <sap-id> [lockout-state]Use the cpu-protection and dist-cpu-protection commands on the platforms that support it.
When using the cpu-protection command, a cpu-protection policy-id is needed to apply on the capture SAP.
configure system security cpu-protection policy 200 create overall-rate 100 out-profile-rate 50 exit exit exit exit service vpls <service-id> customer <customer-id> sap 1/1/1:*.* capture-sap create cpu-protection 200 dynamic-services dynamic-services-policy "dynServPolicy" no shutdown exit no shutdown exit exit exitWhen using the dist-cpu-protection command, a dist-cpu-protection policy-id is needed to apply on the capture SAP.
configure system security dist-cpu-protection policy "distCpuProt" create static-policer "dcpuStatPol" create rate packets 50 within 1 exceed-action discard detection-time 5 exit protocol all-unspecified create enforcement static "dcpuStatPol" exit exit exit exit exit service vpls <service-id> customer <customer-id> sap 1/1/1:*.* capture-sap create dynamic-services dynamic-services-policy "dynServPolicy" no shutdown exit dist-cpu-protection "distCpuProt" no shutdown exit exit exit
Debugging
To enable dynamic services data trigger debugging, use the following debug commands:
debug
dynamic-services
data-triggers
# multiple capture-sap commands allowed
capture-sap <sap-id> [encap-val <qtag[.qtag]>] [mode <mode>]
capture-sap <sap-id> [encap-val <qtag[.qtag]>] [mode <mode>]
exit
exit
During debugging, the system logs data trigger events such as:
data trigger received
data trigger authentication events
data trigger SAP created
dynamic service SAP created
dropped data trigger with drop reason such as data trigger already exists or lockout active
The encap-val command limits the debug output to data trigger events for specific encapsulation values.
The mode specifies which data trigger events are logged: all events or dropped data trigger events only.
Dynamic data services Python API
Dynamic data services functions in the alc.dyn module describes the functions available in the SR OS alc.dyn Python module to create dynamic data services.
| alc.dyn functions | Description |
|---|---|
dyn.action (dictionary) |
Executes the setup, modify or teardown function that is found with a lookup in the specified dictionary using the function-key present in the script parameters. The script-parameters can be obtained from RADIUS in the Alc-Dyn-Serv-Script-Params VSA or can be configured in the local authentication database. The action (setup, modify or teardown) is determined from the Alc-Dyn-Script-Action VSA. Returns: None (no value) dictionary - Python dictionary with format: dictionary = {function-key-1 : (setup-function-1, modify-function-1|None, revert-function-1|None, teardown-function-1), …, function-key-n : (setup-function-n, modify-function-n|None, revert-function-n|None, teardown-function-n) } where:
|
dyn.add_cli (string) |
Executes the specified CLI commands to create the dynamic data service Returns: None (no value) string - CLI commands. The string can span multiple lines in the script when enclosed in three double quotes ("""). |
dyn.get_circuit-id() |
Returns a string containing the control channel circuit-id (DHCP relay agent option 82 or PPP tags) |
dyn.get_remote-id() |
Returns a string containing the control channel remote-id (DHCP relay agent option 82 or PPP tags) |
dyn.get_sap() |
Returns a string containing the dynamic data service sap-id: the value of the Alc-DynServ-SAP-ID VSA. A wildcard hash (#) in the VSA value is replaced with the corresponding control channel or data trigger port or vlan-id field. |
dyn.reference (function-key, reference-id, dictionary) |
Create a dynamic reference to another function in the script. Typically used to create n:1 relations between dynamic data services, such as multiple SAPs in a VPLS service or multiple services for the same customer. Dynamic referencing is only allowed in setup functions. Corresponding teardown functions automatically dereference. Returns a dictionary provided by the setup script matching the function-key: function-key is the key in the action dictionary (see dyn.action) to find the corresponding setup or teardown functions. reference-id is the unique reference ID string that identifies the dynamic reference (for example, all SAPs from a VPLS service would have the same reference id). dictionary is a Python dictionary containing parameters for use in the setup or teardown function, such as to generate CLI output. |
dyn.select_free_id (type) |
Returns a string representing a free identifier of the specified type. type is identifier type that is returned:
The corresponding filters are shown in the system as ‟_tmnx_dyn_<number>” |