Residential subscriber components

Overview

Configuring residential subscriber management on the NFM-P involves the configuration of a variety of components, depending on the service delivery model.

For detailed NE-specific information about residential subscriber management, see the NE documentation. For information about configuring residential subscriber policies and profiles, see Chapter 64, Residential subscriber policies.

A host requires subscriber-profile and SLA-profile associations to gain access to the network. Profiles define service attributes for hosts such as scheduling, accounting, security, and traffic prioritization by application type. A profile uses existing NFM-P policy definitions and allows the customization of policy parameters using override values.

An NFM-P user who is assigned the administrator, subscriber management, service management, or policy management scope of command role can perform all residential subscriber management functions, such as managing profile or DHCP-lease information.

The NFM-P allows the configuration of multiple components in one operation, but limits configuration to those parameters that are not specific to a component. For example, when a policy is applied to multiple profiles, the NFM-P removes pre-existing policy override values in the profiles.

The figure below shows a conceptual model of the main component relationships in residential subscriber management. The model does not represent a specific type of service or service delivery mechanism and does not show all possible component configurations.

Figure 74-2: Residential subscriber management component relationships
Residential subscriber management component relationships

As shown in Figure 74-2, Residential subscriber management component relationships, there is a one-to-one relationship between a subscriber and a subscriber profile and a many-to-many relationship between subscriber profiles and SLA profiles. A subscriber profile or an SLA profile can apply to multiple SAPs or NEs, and can be specified as the default profile for the SAP or the NE.

The table below lists where to find configuration information for residential subscriber components. The numbered levels segregate components for clarity only.

Table 74-2: Residential subscriber management components

Level

Component

Description

For more information, see

Procedure

1

Subscriber identification policy

Associates a dynamic host with a subscriber

Subscriber identification policies

To configure a subscriber identification policy

Subscriber identification script

Parses DHCP Option 82 field to extract subscriber identification for a host, and optional profile, ANCP, and intermediate destination identification strings.

Subscriber identification policies

To modify the primary subscriber identification script or URL

2

Subscriber

Unique identifier that associates a group of subscriber hosts with policies

Residential subscriber management

2

Subscriber instance

An instantiation of a subscriber on an NE

Residential subscriber management

3

Subscriber profile

Names existing ingress and egress scheduler policies and an accounting policy for use by all hosts of a subscriber

Subscriber profiles

To configure a subscriber profile

4

SLA profile

Names existing QoS policies to define the traffic shaping for different classes of service within an application such as HSI, VoIP, VoD, or BTV

Names existing ACL policies to filter the ingress and egress traffic

SLA profiles

To configure an SLA profile

5

Subscriber explicit map

Lists subscriber identifiers and the associated SLA and subscriber profiles

Subscriber explicit maps

To configure a subscriber explicit map entry

6

Residential subscriber host (static)

A device such as a computer or set-top box that receives service traffic using a fixed IP address

Static subscriber hosts

To create a static host for residential subscriber management on a SAP

, To configure anti-spoofing filters for an IES L3 access interface, and To configure anti-spoofing filters for a VPRN L3 access interface access interface anti-spoofing configuration steps

Residential subscriber host (dynamic)

A device such as a computer or set-top box that receives the service traffic using a temporarily assigned IP address

Subscriber identification policies, Subscriber profiles, SLA profiles,   Subscriber explicit mapsManaged SAP (MSAP), and  PPPoE policies

To view and configure residential subscriber hosts on a SAP

7

Local DHCP server and PPPoE group interface

A local user database is created and associated to a local DHCP server and PPPoE group interface configuration

Local DHCP server

To configure a PPP policy

To configure a local user database for subscriber host authentication

To create a VPRN service

To configure a group interface on an IES

The NFM-P treats residential subscriber management components like policies. Depending on the distribution mode configuration of a local instance, when you modify a global component using the NFM-P, all local instances of the residential subscriber management component on the associated NEs can be updated. The Local Definitions tab of a component management form lists the local instances of the component.

Note: You cannot delete an active component of a residential subscriber management configuration.

Residential subscriber component and policy deployment

Global residential subscriber management components are created in draft mode. This allows operators to verify the configuration before they distribute it to the network elements; see Chapter 49, Policies overview for information about global and local policy instances and policy distribution modes.

The NFM-P deploys the components associated with a subscriber, such as policies and profiles, to an NE when one of the following occurs:

After the NFM-P deploys the subscriber and SLA profiles, the NE creates the queues, ACL filters and HQoS schedulers specified in the profiles. The NE ignores pre-existing queue or ACL filter policies on a SAP when subscriber management is enabled on the SAP.

Subscriber identification strings

The NFM-P identifies the subscriber for a dynamic host by obtaining a subscriber identification string from a source such as the following:

A static host requires explicit provisioning on the NFM-P that includes the association of a subscriber identification string.

You can optionally specify a default subscriber identification string for a SAP. You can enter the string or configure the NFM-P to use the SAP ID as the string.

Obtaining subscriber identification strings from DHCP packets

When a dynamic residential subscriber host requests an IP address using DHCP, the host can include a subscriber ID string and optional profile ID strings in the Option 82 field of the DHCP packet. If the request is approved by a DHCP server, the NE obtains the subscriber ID string for the host from the Option 82 information in the returning ACK message. The subscriber ID string is a match criterion for the assignment of SLA and subscriber profiles to the host unless profile ID strings are explicitly encoded in the DHCP option information by the host or configured as SAP default profiles. You can also configure a default subscriber ID string on a SAP.

Note: If adding Option 82 information to a DHCP relay packet causes the packet to exceed the DHCP relay maximum of 1500 bytes, the NE forwards the DHCP request without the Option 82 information. For this reason, short strings can be used as aliases for profile names.

Local DHCP server

A local DHCP server leases IP addresses to clients in the network. Options are configured to define the IP address properties, such as, the length of time an IP address is active and which DNS server must be used. A local user database is used to authenticate and authorize clients requesting IP addresses from the local DHCP server. If the local DHCP server does not use the local user database, the server can use the GI address to assign free IP addresses, however it is not possible to configure match or authentication parameters.

Three applications are targeted for the local DHCP server.

DHCP servers can be integrated with Enhanced Subscriber Management for DHCP and PPPoE clients. A local DHCP server can be created in the routing instance window or VPRN service site window. A local DHCP server created in the VPRN service site can be associated with the L3 access interface on a VPRN service only. A local DHCP server created in the routing instance window can be associated with a network interface or L3 access interface on an IES.

Failover support

You can configure failover support on local DHCPv4 and DHCPv6 servers, as well as on individual IP address pools on the servers. The same IPv6 prefix or IPv4 address range can be shared between the two peering DHCP servers in a redundant configuration. Either DHCP server can allocate a new lease from the same address range or prefix. To avoid IP address duplication, a single active path is available from the clients to one of the DHCP servers in a redundant configuration. The single active path is ensured through a protection mechanism in a dual homed environment in the access side of the network. The supported protection mechanisms are SRRP or MC-LAG.

Sticky leases

You can configure a sticky lease object on a local DHCPv4 or DHCPv6 server to reserve an IP address, preventing the address from being allocated to another device. The reserved IP address can be defined as a public address for a dynamic host; see To configure an IES or VPRN IPsec gateway.

Local user database

A local user database is configured and associated with the local DHCP server to provide local authentication. The local DHCP server must have a pool of IP addresses configured, otherwise it is not able to lease IP addresses.

A create local user database configuration form is available from the Manage Residential Subscribers form; see To configure a local user database for subscriber host authentication. Once a local user database is configured, it can be associated with a local DHCP server and PPPoE configuration on a group interface.

When a local user database is not configured, you can use GI addresses to access free IP addresses, however the clients requesting the IP address will not be authenticated.

ARP host

You can use the NFM-P to configure and retrieve ARP hosts on a 7750 SR. ARP hosts are a subtype of enhanced subscriber host objects. The creation of the object is triggered by the reception of ARP messages from end-user devices. ARP hosts can be configured as an alternative to DHCP subscriber hosts or PPPoE sessions.

ARP host configuration can be performed on VPLS and MVPLS L2 access interfaces, IES and VPRN group interfaces, and VPRN retailer subscriber interfaces. The configuration includes enabling the functionality, setting the maximum limit of hosts per SAP or interface, and setting the default authentication interval.The configuration must be performed in conjunction with other enhanced subscriber management configuration on these interfaces. ARP hosts can be retrieved from the VPLS, MVPLS, and IES or VPRN SAPs. ARP hosts can also reside on MSAPs.

Static subscriber hosts

Static subscriber hosts require explicit provisioning rather than an association with a subscriber identification policy. Static hosts for VPLS are configurable on the anti-spoofing tab of the L2 access interface management form. For IES and VPRN services, static hosts are configurable using the management form for a SAP on a group interface.

Static host configuration involves the following elements:

Note: When residential subscriber management is enabled on a VPLS SAP that is part of an operational MC ring group, the following must be configured on each static host:

Subscriber host connectivity verification

Aside from relatively infrequent IP-address lease renewal, DHCP has no session-monitoring or connection-monitoring capability. Residential subscriber management provides this functionality for DHCP hosts and static hosts using subscriber host connectivity verification, or SHCV.

When SHCV is enabled on a SAP, an NE issues a periodic ARP request to each host on the SAP. If the NE receives no reply to an ARP request within the specified interval, the NE raises an event. When SHCV is configured to drop a lost host, the NE immediately removes the host from its active subscriber host table.

SHCV records the state information that it collects for hosts on a SAP and maintains a history of connectivity-related events for troubleshooting purposes. The size of the history log is restricted by a size-constraint policy.

SHCV operates in conjunction with DHCP snooping and is configurable on VPLS, VPRN, and IES SAPs and on IES group interfaces. Because it uses ARP, SHCV automatically populates the FIBs of bridging devices in the access and provider networks.

The configurable items for SHCV on a SAP include:

Note: On an L2 access interface, SHCV uses the NE system IP address as the source of the ARP request. On an L3 access interface, SHCV uses the IP- and MAC-address combination of the interface or the VRRP state for the interface as the ARP source. On IES group interfaces, SHCV uses the address of the subscriber interface as the source.

The behavior that an NE exhibits toward SHCV events is configurable using the residential subscriber management form.

The configurable NE SHCV items include:

SHCV event handling on an NE is disabled by default. When SHCV is enabled on a SAP but is disabled on the NE, the NFM-P records the blocking of SHCV events in the SHCV log. This ensures that an operator is aware of SHCV activity when viewing the SHCV log, even if the NE is configured to suppress SHCV events.

The following conditions represent an SHCV host connectivity loss:

An NE makes more than one SHCV attempt before it raises an event against a host to ensure that the absence of a host response indicates a host connectivity problem and is not simply the result of occasional packet loss.

When a SAP becomes operationally down, the NE generates one trap for the SAP rather than one trap for each host on the SAP. When the SAP returns to service, the NE forwards a trap for each host as it verifies the restoration of connectivity.

SHCV generates the following event traps:

SHCV policies

The SHCV policy provides consistent BNG behavior when handling RG replacement and mobility across different (IP and/or MAC) address types. The SHCV policy is configured on VPRN or IES group interfaces, and VPRN or IES L3 access interfaces.

An SHCV policy specifies uniform Action, Interval, Retry Count, and Timeout parameters for periodic SHCV. The policy also specifies uniform Retry Count and Timeout parameters for each of the following SHCV event triggers:

To create an SHCV policy, see To configure an SHCV policy.

Routed CO

A broadband access network typically requires the aggregation of the traffic from access equipment before routing of the traffic is possible. Routed CO functionality allows a network operator to directly connect a DSLAM or similar multiplexer to a router such as the 7750 SR.

Residential subscriber management, combined with the use of DSCP or dot1p values, supports access-integration models such as the following:

Routed CO allows the configuration of subscriber interfaces and group interfaces on IES and VPRN. A subscriber interface defines the subnets that are available to a subscriber. A group interface is a child object of a subscriber interface that allows the configuration of multiple SAPs as part of a single interface. Routed CO functionality depends on residential subscriber management to maintain the subscriber host information.

There is no direct association between the subnets and the group interfaces. Subnets can be shared between group interfaces. If the host IP address is not in one of the subnets, packets from the network to that host IP are not received by the subscriber or group interfaces.

A subscriber interface defines a maximum of 16 subscriber subnets and acts as the DHCP relay agent for a subscriber. For the forwarding of DHCP packets to a subscriber server, a subscriber interface requires the specification of a gateway address that is in one of the subscriber subnets. Group interfaces below the subscriber interface inherit this gateway address but can specify an override value if required.

All SAPs in a group interface use the same port. The first SAP on a group interface determines which port the group interface uses. Additional SAPs for the group interface must be associated with the group-interface port during SAP creation.

A group interface is similar to a regular IES interface except for the following.

When a subscriber interface or a group interface is operationally disabled, no packets are sent to or from the subscriber hosts on the SAPs of the interface, but the state information for a static or dynamic host persists until the static host is removed from the NE by an operator or the DHCP lease of the dynamic host expires.

Because the configuration of multiple SAPs on a group interface makes normal forwarding of DHCP responses to hosts impossible, DHCP relay for routed CO maintains a cache of DHCP requests. If a DHCP server response does not arrive within the specified interval time, the NE discards the cache entry. The NFM-P operator can choose to have the NE use the Option 82 circuit ID field in a DHCP request as the match criterion for the returning DHCP ACK message.

You can configure NAT for dynamic subscriber hosts in a routed CO deployment. NAT for routed CO requires a NAT policy that is associated with a subscriber profile. In an IES routed CO deployment, NAT is configured on the base routing instance of an NE. In a VPRN routed CO deployment, NAT is configured on the VPRN routing instance; see Chapter 30, NAT for information about configuring and deploying NAT, and about configuring a NAT policy; see To configure a subscriber profile for information about associating a NAT policy with a subscriber profile.

Lease populate is enabled on a group interface by default, and the number of allowable lease entries is set to one. All SAPs on the group interface inherit this configuration during creation.

See Chapter 78, IES management and Chapter 79, VPRN service management for more information on configuring subscriber and group interfaces for IES and VPRN services.

Wholesale and retail configurations for VPRN services

A VPRN routed CO allows a service provider to resell wholesale carrier services while providing direct DSLAM connectivity. You can create a VPRN service for the retailer and also define subscriber access and configuration information for the retailer network. The implementation of configuration changes occurs as if the VPRN is a standalone router using the routed CO model. The benefit of this model is flexibility for the retailer and decreased involvement for the wholesaler.

You must use a subscriber SAP to support shared access for multiple retailers. Another dependency of shared access is the requirement for the wholesaler to maintain separate access nodes for each retailer with network scaling issues.

In the wholesale and retail model, the wholesaler instance connections that are common to the access nodes are distributed to many retail instances. Upstream subscriber traffic ingresses into the wholesaler instance and, after identification, is then forwarded into the retail instance. The reverse principle occurs for traffic in the opposite direction. The wholesale and retail traffic flow is controlled with minimal communication to the RADIUS server. A RADIUS policy is defined in the wholesaler instance. The RADIUS response used during the subscriber instantiation provides the service context of the retailer VPRN. If the wholesaler has a retail business, the operator can configure a separate VPRN for their retail services.

The retailer subscriber interface primarily controls the DHCP configuration. The single exception to this model is the lease-populate value. The lease-populate value in the wholesale context controls the individual SAP limits. The lease-populate value in the retail subscriber interface controls the limits for that retailer interface. The wholesale and retail limits must be met before the instantiation of a new subscriber.

Figure 74-3: Routed CO for traditional and wholesale/retail VPRNs
Routed CO for traditional and wholesale/retail VPRNs

See Chapter 79, VPRN service management for information on configuring the forwarding service component for wholesale and retail VPRN services.

Subscriber host polling and monitoring

Subscriber hosts can be periodically polled and monitored for certain DHCP event changes. A subscriber host monitoring configuration form is available from the Manage Residential Subscribers form.

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

The Monitored Subscriber Host form displays a variety of polled information about the host that is obtained from the NE. You can also open a DHCP event log for the host from the Host Properties form. The logged events include information on DHCP lease renewals, lease expiration, and profile changes. An entry is added to the table whenever a new event occurs. You can purge event entries using the Host Properties form.

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

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

Subscriber services

The NFM-P supports the retrieval of subscriber services and related attributes from PPP or IPoE subscriber hosts. A subscriber service specifies a mode of operation in which a subscriber-specific service is activated and deactivated on a PPPoE session via a RADIUS Access-Accept message or a CoA-Request message. This function is sometimes referred to as Radius Based Policy control, or RaBaPol.

Single or multiple subscriber service activation and/or deactivation calls can be included in Access-Accept messages for new PPPoE sessions, or in CoA-Request messages for existing PPPoE sessions. PPPoE sessions can be IPv4, IPv6 or dual stack. Subscriber services can also operate on the PPPoE session itself.

Examples of subscriber services are:

Figure 74-4: Subscriber services model
Subscriber services model
BNG integrated virtual CPE

In a redundant configuration, the vRGW runs in an active/standby redundancy model. When a switch-over occurs, subscriber hosts are re-created via data trigger. In order to avoid assigning the same address to multiple hosts, allocated IP addresses are tracked in the address pool assigned to a subscriber. To support this functionality, the Standby IP Lifetime is configured on the DHCP pool on a BRG profile. Additionally, the BRG instance displays the standby IP address, remaining hold time, and a list of BRG address pools.

Managed routes

The NFM-P can retrieve managed route (also known as framed route) information from the NE for hosts instantiated on IES and VPRN services. A routed subscriber host is a subscriber with subnets behind the routed gateway in order to support subscriber hosts with regular routers. The subscriber host associated subnets are learned through RADIUS VSAs (up to 16 routes).

Framed routes (IPv4 subnets) are displayed on the following ESM session types:

Framed IPv6 routes (IPv6 prefixes) are displayed on the following ESM session types:

IPoE sessions

An IPoE session is a logical grouping of multiple subscriber hosts that represent different IP stacks on the same end user device. The grouping is based on a configurable data key, available in a trigger packet. An IPoE session can be single-stack IPv4, single-stack IPv6,or dual-stack, depending which host types or stacks are associated with the session.

The creation of a new IPoE session triggers authentication in the same way as for a subscriber host. A unique accounting session ID is generated for the IPoE session. The authentication data is stored in the IPoE session state for future reference.

Subscriber hosts with a matching key in the trigger packet are associated with an existing session without re-authentication: the data stored in the session state is used to instantiate the subscriber host. Deleted subscriber hosts are no longer associated with the IPoE session.

During the lifetime of an IPoE session, the state is maintained by control plane events for the associated IP stacks (such as DHCP lease state renewals or SHCV checks). Mid-session changes can occur.

An IPoE session is terminated when the last associated IP stack is deleted, or by policy control. The corresponding IPoE session state is then deleted from the system.

The NFM-P specifies IPoE session trigger packet information and session termination control by means of an IPoE session policy. The IPoE session policy is bound to a VPLS capture SAP, and to an IES or VPRN service group interface.

HSQ

HSQ (High Scale QoS) is an evolution of egress Q chip traffic management functions on an enhanced version 4 IOM (iom4-e-hs). The functionality of HSQ is similar to the HSMDAv2, with expanded queue and shaping scale, and an added level of aggregate shaping. Because HSQ functions at the egress forwarding plane level, all egress ports on supported MDA types utilize HSQ QoS functions. Ingress ports on attached MDAs are provisioned using the standard HQoS (Hierarchical Quality of Service) feature set. HSQ supports ports, LAGs, and PW ports.

The following services support HSQ:

HSQ supports two SLA modes for ESM: Expanded and Single. The SLA mode is configurable on the subscriber profile. In Single mode, the subscriber aggregate rate and the SLA profile queuing are both performed using a single CVLAN context for the subscriber.

A unique SLA profile instance is required when one or both of the following conditions occur:

In Single mode, the first condition causes the new SLA profile context to alter the existing SLA profile instance associated with the subscriber. The second condition is not supported for a subscriber configured in Single mode. In Expanded mode, multiple SLA profile instances are supported by moving the subscriber aggregate shaping function to an SVLAN specifically created for the subscriber instance. A unique CVLAN is created for each unique SLA profile instance for the subscriber.

For configuration information, see Workflow to configure HSQ.

ESM over GTP hybrid access

Hybrid access technology provides higher bandwidth to areas where there is limited network infrastructure (typically copper wire-based), and provides the option for the service provider to make a smooth transition to LTE technology in the future. GPRS Tunnelling Protocol (GTP) is used to terminate wireless connections on S11 interfaces, allowing the service provider to use ESM over GTP on hybrid access (WLAN GW and BNG). GTP can be used with and without bonding. The Access Point Name (APN) policy defines subscribers with an access point name and authentication parameters. GTP is configured on VPRN and base routing instances, including APN policy configuration on S11 interfaces.

For configuration information, see Workflow to configure ESM over GTP hybrid access.

Home LAN extension

In a home LAN extension configuration, a bridge domain is created for each residential subscriber on the BNG, the bridge domain is extended by a VXLAN tunnel to the VM in the domain controller. All L3 routing and services on a residential CPE are moved out of the CPE to run in the service provider’s network. These L3 services can be integrated on the BNG or run in a VM per CPE in the data-center. The home CPE runs in bridged mode. It provides local-bridging for traffic between devices on the home LAN, and any traffic destined to an address that is not on the local subnet is bridged towards the BNG. From BNG’s perspective this looks like a bridged residential subscriber with ESM and L2-aware NAT for routed traffic. Each device on the home LAN gets a unique address from the DHCP Server or DHCP proxy on the BNG. In this manner, the VM appears to be on the home LAN.

For more information, see Workflow to configure home LAN extension functionality in a network.

ISA service chaining

Value Added Service (VAS) is a set of service functions in a data center (DC) providing optional services to ESM hosts on a vRGW or BNG. These service functions in the DC can live on virtual machines (VMs) behind a network virtualization edge (NVE) or a third party NVE. ESM hosts corresponding to residential subscribers on the vRGW or BNG (and corresponding NAT outside IP addresses) can be in a different subnet than the VMs in the DC. The vRGW or BNG can access the VAS in DC over an EVPN or VxLAN overlay.

Based on ingress/egress VAS filters associated with L2-aware subscribers, traffic is steered towards service functions (VMs or appliances behind an NVE in an EVPN-enabled data center). The vRGW/BNG shares a local subnet and an overlay routing context (VPRN) with the NVE (behind which the service functions sit), and acts as the next-hop router for the NVEs to reach the NAT outside IP addresses on the vRGW/BNG. NAT outside service can be same as the overlay routing context shared with the NVEs in the DC, or can be a different context. In case it is a different context, NAT routes are leaked into the overlay VPRN, and announced via EVPN prefix routes.

Traffic after NAT on the vRGW/BNG is directed to the MAC address of the service function, resolved by tracking EVPN updates, and is VxLAN tunneled towards VTEP on an NVE in the DC. The NVE bridges this traffic to the service function, or traffic after NAT on vRGW/BNG is directed to the MAC address of the NVE (resolved by tracking appropriate EVPN routes), and is VxLAN tunneled towards VTEP on the NVE. The NVE routes the traffic in appropriate routing context (based on the VNI) to the VM/VA sitting behind it.

Workflow to configure ISA service chaining

Complete the following procedures to configure ISA service chaining:

  1. Configure an NE with a MAC prefix for ISA service chaining; see To configure ISA service chaining on an NE.

  2. Configure the base routing instance for ISA service chaining, with ISA groups and VXLAN VTEP ranges; see To configure a routing instance or a VRF instance.

  3. Configure a service chaining EVPN policy, see To configure a service chaining EVPN policy.

  4. Configure a service chaining VAS Filter policy, see To configure a service chaining VAS filter policy.