SAP and MSAP management overview

General information

You can use residential subscriber profiles and policies to manage SAPs. Enabling residential subscriber management on a SAP does not affect an existing dynamic host on a SAP until the host DHCP lease expires, at which point a subscriber identification policy manages lease renewal. Static hosts require the provisioning of a subscriber identification string for continued network access.

When residential subscriber management on a SAP is enabled, each subscriber host that connects to the SAP requires a subscriber identification string to associate the host with a subscriber instance on the NE, or network access is denied. A subscriber identification string uniquely identifies a subscriber in the NFM-P.

The maximum number of subscribers that can use a SAP is configurable. When a SAP is limited to one subscriber, you can specify the treatment of traffic that does not match the subscriber profile, such as BTV traffic, which uses an IP address in the multicast range as the destination address. During single-subscriber SAP configuration, the NFM-P operator specifies whether to allow non-profile traffic and specifies the SLA and subscriber profiles to use for non-profile traffic, if it is allowed.

SAP DHCP monitoring

You can monitor the DHCP events on one or more SAPs. A SAP monitoring form is available from the Manage Residential Subscribers form.

Table 74-3: SAP DHCP monitoring events

DHCP event

Description

DHCP Lease Entries Exceeded

The number of DHCP lease state entries on a SAP has reached the configured maximum.

DHCP Lease State Overridden

An existing DHCP lease state was overridden by a new lease state with the same IP address and a new MAC address.

Suspicious DHCP Packet

A DHCP packet containing suspicious content was received.

DHCP ACK Dropped

A DHCP ACK message was discarded because the related lease state could not be updated.

Host Connectivity Lost

The connection to the specified host was lost.

Host Connectivity Restored

The connection to the specified host was regained.

The maximum number of SAPs that can be selected for monitoring is configurable through XML; the default is five. SAP monitoring has a performance impact, so only a small number are typically monitored at one time.

The Monitored Access Interface form displays a variety of DHCP-related events or notifications about subscriber hosts on a SAP that are compiled using traps received from NEs. You can also open an event log for the SAP from the SAP Properties form. The logged events include information on DHCP lease entries, lease states, and host connectivity. An entry is added to the table whenever a new event occurs. You can purge event entries using the Monitoring Configuration form.

SAP monitoring can be started, stopped, or removed from the monitoring configuration form, and the monitoring period can be configured.

The SAP monitored objects and the associated events are stored in the database. The monitoring continues until the monitoring period elapses or the monitoring is stopped by an NFM-P operator.

Managed SAP (MSAP)

You can configure the NFM-P to automatically create a SAP for a subscriber; this SAP is called a managed SAP, or MSAP. MSAPs are used in network models where each subscriber has a separate VLAN, and multiple subscriber hosts share a SAP. MSAP creation uses the authentication mechanisms that an NE supports to provide an MSAP for the one-subscriber-per-SAP model. An MSAP behaves the same as a regular SAP, but the MSAP configuration is not editable. MSAPs count towards the maximum number of SAPs allowed on an NE.

An MSAP is typically used by only one subscriber, although the NFM-P supports MSAPs shared by multiple subscribers. However, if more than one subscriber is allowed and an MSAP has been defined by a host, when a new host installation attempts to change the MSAP policy the installation fails and raises an event.

The creation of an MSAP is triggered by a capture SAP. When a capture SAP is configured, triggering packets initiate RADIUS authentication, and the RADIUS reply provides a service context. The authentication and the service context are used by the NE to create an MSAP; see Capture SAP.

Although MSAPs are not configurable, a user with a Policy Management or Subscriber Management role can create, list, delete, or modify an MSAP policy to control how the parameters apply during MSAP creation.

An MSAP remains active as long as there is at least one subscriber host on the MSAP; see  MSAP management.

MSAPs are supported in HA and dual-homing environments. In dual homing, the MSAP is synchronized with the other NE during MSAP creation. For both HA and dual-homing environments, each participating NE must use the same MSAP policy.

Capture SAP

A capture SAP must be defined to trigger the process that automatically creates an MSAP. A capture SAP does not forward traffic; see To configure a capture SAP.

You can create a capture SAP only in a VPLS. A capture SAP can create MSAPs in the routed CO configuration of an IES or VPRN, and in a VPLS TPSDA configuration. IES and VPRN MSAPs are restricted to group interfaces. You can configure the capture SAP to allow Dot1Q MSAP creation when the terminating port for the capture SAP is configured for QinQ encapsulation.

The following triggers are supported to initiate MSAP creation:

After you configure the capture SAP, every DHCP packet, PPPoE packet, or ARP packet received on the SAP is sent to the CPM, which triggers RADIUS authentication to provide a service context. The MSAP is created in the specified service. Non-triggering packets captured by the capture SAP are dropped.

If RADIUS does not provide all of the required information to install the host (for example, RADIUS lacks the IP address), the MSAP is created with a short timer while waiting for the host to be installed. Default SAP polices are available on the NE and will be used if the MSAP policy is not configured.

The authentication policy used in the capture SAP must be the same as the policy used for the MSAP. For L3, the authentication policy is defined under the group-interface.

Note: When PPPoE is used with MSAPs, the authentication policy must not use the username for MSAP creation.

The MSAP is not created (and an event is generated) if the group-interface name returned from RADIUS points to a different authentication policy than the policy defined by the capture SAP.

For MSAPs, the authentication policy is defined in the MSAP policy. Based on the configuration, the system reauthenticates the sessions when they are renewed. If the authentication policy is not used or when only PPPoE is used, the MSAPs stay active when the session is renewed.

An MSAP is created with dual-pass (shared) queuing. The SLA profile of the host may change the queuing later in the process. An MSAP is always created with the default QoS and scheduling.

MSAP management

An MSAP cannot be modified directly, so MSAP management is performed using MSAP policies. To make changes to an MSAP, alter the MSAP policy for the MSAP and then re-evaluate the MSAP. During re-evaluation, the NE updates the MSAP based on the changes to the MSAP policy; see To modify and re-evaluate an MSAP policy on an MSAP.

The NFM-P treats the setup and teardown of MSAPs as state transitions to offset the load imposed by constant SAP creation and deletion. There are two states that an MSAP can have, active or inactive. These states cannot be configured. The state is automatically set to active when the MSAP is created on the NE. When the NE deletes the MSAP, the state changes to inactive, and the MSAP continues to be available in the NFM-P but is not used until it is reactivated by the NE. When the MSAP is reactivated, it will have the same identification so that the NFM-P can identify it with the same FDN.

The state information is not automatically updated in the NFM-P GUI. You must perform a resynchronization to retrieve the current state information. When the state is inactive, performance statistics for the MSAP are not retrievable; however, historical statistical records are available. You can schedule MSAP statistics or collect the statistics on demand; see the NSP NFM-P Statistics Management Guide for more information about scheduling and collecting statistics.

Inactive services that previously contained MSAPs consume database space. MSAPs that have been in an inactive state for a long period of time or that are no longer used must be manually deleted.

Note: If there is a disruption on the NE and the NE recovers by restarting, all MSAPs are re-evaluated and any policy changes are applied.

Note: The creation of a SAP that uses the same port and encapsulation values as an existing inactive MSAP fails under the following conditions:

Nokia recommends that you delete an inactive MSAP from the NFM-P if you need to create a regular SAP on the same port using the same encapsulation values.

MSAP Re-evaluate Lease States function

The NFM-P Re-evaluate Lease States function allows you to push SLA profile or subscriber profile changes out to residential subscribers without reinstantiating the hosts; see To re-evaluate lease states for an MSAP.

MSAP alarm suppression

An IES or VPRN MSAP that is created on a LAG in an SRRP deployment uses an NFM-P mechanism to suppress unnecessary AccessInterfaceDown alarms. The mechanism uses the SRRP states of the redundant BNGs, and determines whether to raise the alarm based on the following rules:

Note: The alarm-suppression mechanism can function correctly only when SRRP is correctly configured. If an SRRP peer is missing or disabled, the alarms may not be suppressed for the BNG that the NFM-P perceives to be the standby BNG.

MSAP event logs

An MSAP event log records the date, time, and active state for each state change that occurs after the MSAP is created. An event log is not recorded when the MSAP is created, although the information is recorded in a time stamp; see To view an MSAP event log, modify the global MSAP log policy, and purge MSAP log records.

MSAP time stamps

You can view the following MSAP state time stamps:

See To list MSAPs and view MSAP properties.

Workflow to manage MSAPs
 
1 

Create an MSAP policy; see To configure an MSAP policy.

2 

Create a capture SAP that references the MSAP policy you created in Stage 1; see To configure a capture SAP.

3 

Change an existing MSAP by modifying and re-evaluating an MSAP policy, as required. To modify a single MSAP, see To modify and re-evaluate an MSAP policy on an MSAP; to modify multiple MSAPs that use the same policy, see To modify an MSAP policy and re-evaluate the MSAPs.

4 

Perform the following MSAP maintenance tasks, as required:

  1. List MSAPs; see To list MSAPs and view MSAP properties.

  2. View or purge MSAP logs, or modify the MSAP log policy; see To view an MSAP event log, modify the global MSAP log policy, and purge MSAP log records.