9.1.1.1. Uniform RADIUS Server Configuration (Preferred)

This configuration method is preferred as it can be re-used amongst multiple applications (Subscriber authentication and accounting, L2TP tunnel accounting, WLAN gateway RADIUS proxy) and enables additional functionality not available in the legacy configuration method. For example:

Note: A RADIUS server is marked down if it detects a few consecutive timeouts independent of the transaction ID or origin of request.

Where consecutive timeouts are defined by the number of retries configured below the RADIUS server policy servers.

The default number of retries is 3, meaning 1 initial try and 2 retries.

If, for example, the RADIUS server has “2 timeouts, 1 reply, 1 timeouts”, whereby the timeouts are originated for the same host, the server is not marked down since intermediate replies were received.

To attach a RADIUS server policy to an authentication policy:

For example,

Note: To avoid conflicts, the following CLI commands are ignored in the authentication policy when a radius-server-policy is attached: All commands in the radius-authentication-server context accept-authorization-change coa-script-policy accept-script-policy request-script-policy The fallback-action command specifies the action when no RADIUS server is available is configured direct in the config>subscr-mgmt>auth-plcy CLI context.

To attach a RADIUS server policy to a RADIUS accounting policy:

For example:

Note: To avoid conflicts, the following CLI commands are ignored in the RADIUS accounting policy when a radius-server-policy is attached: All commands in the radius-accounting-server context acct-request-script-policy

To configure the RADIUS servers in a RADIUS server policy:

For example:

To configure the RADIUS servers in the routing instance:

For example:

Note: To configure RADIUS CoA servers for use in Enhanced Subscriber Management, the server must be configured in the corresponding routing instance with the accept-coa command enabled.

9.1.1.2. Legacy RADIUS Server Configuration

Note: It is recommended to migrate to the uniform RADIUS server configuration as described above to have additional functionality enabled.

To configure a RADIUS server in an authentication policy:

Note: In a legacy RADIUS server configuration, to configure RADIUS CoA servers for use in Enhanced Subscriber Management, the server must be configured in the authentication policy with the accept-authorization-change command enabled. A CoA only server can be configured with the optional coa-only flag.

To configure a RADIUS server in a RADIUS accounting policy:

9.2.1.1. Triple Play Network with RADIUS Authentication

Figure 70 shows a flow of RADIUS authentication of DHCP hosts in the triple play aggregation environment. Besides granting the authentication of given DHCP host, the RADIUS server can include RADIUS attributes (standard and/or Vendor-Specific Attributes (VSAs)) which are then used by the network element to provision objects related to a given DHCP host.

Figure 70:  Triple Play Aggregation Network with RADIUS-Based DHCP Host Authentication 

RADIUS is a distributed client/server concept that is used to protect networks against unauthorized access. In the context of the router’s subscriber management in TPSDA, the RADIUS client running on nodes sends authentication requests to the SSC.

RADIUS can be used to perform three distinct services:

The RADIUS protocol uses “attributes” to describe specific authentication, authorization, and accounting elements in a user profile (which are stored on the RADIUS server). RADIUS messages contain RADIUS attributes to communicate information between network elements running a RADIUS client and a RADIUS server.

RADIUS divides attributes into two groups, standard attributes and Vendor-Specific Attributes (VSAs). VSA is a concept allowing conveying vendor-specific configuration information in a RADIUS messages, as discussed in RFC 2865, Remote Authentication Dial In User Service (RADIUS). It is up to the vendor to specify the exact format of the VSAs.

Nokia-specific VSAs are identified by vendor-id 6527.

9.2.2.1. Calling-Station-ID

A calling-station-id can be configured at SAP level and can be included in the RADIUS authentication and accounting messages. This attribute is used in legacy BRAS to identify the user (typically phone number used for RAS connection). In the broadband networks this was replaced by circuit-id in Option 82. However, the Option 82 format is highly dependent on access-node vendor, which makes interpretation in management servers (such as RADIUS) difficult. Some operators use the calling-station-id attribute as an attribute indicating the way the circuit-id should be interpreted. The calling-station-id attribute can be configured as a string which is be configured on the SAP. It can also be configured to use the sap-id, remote-id or mac-address.

9.2.2.2. Subscriber Session Timeout

To limit the lifetime of a PPP session or DHCPv4 host to a fixed time interval, a timeout can be specified from RADIUS. By default, a PPP session or DHCPv4 host has no session timeout (infinite).

For PPP sessions, a session-timeout can be configured in the ppp-policy. A RADIUS specified session-timeout overrides the CLI configured value.

When the session timeout expires a PPP session is terminated and a DHCPv4 host deleted. For a DHCPv4 host, a DHCP release message is also sent to the server.

The following two attributes can be used in RADIUS Access-Accept and CoA messages to limit the PPP session or DHCPv4 host session time (Table 11):

When specified in a RADIUS Access-Accept message, both attributes specify an absolute value for session timeout. When specified in a RADIUS CoA message, attribute [26-6527-160] Alc-Relative-Session-Timeout specifies a relative session timeout value in addition to the current session time while attribute [27] Session-Timeout specifies an absolute session timeout value. If the current session time is greater than the received Session-Timeout, a CoA NAK is sent with error cause “Invalid Attribute Value (407)”.

Only one of the above attributes to specify a session timeout can be present in a single RADIUS message. An event is raised when both are specified in a single message.

The output of the show service id service-id ppp session detail CLI command contains following fields related to session timeout for PPP sessions:

The output of the show service id service-id dhcp lease-state detail CLI command contains following fields related to session timeout for DHCPv4 hosts:

Note: In a radius-proxy scenario or when a DHCPv4 host is created with a RADIUS CoA message, the RADIUS attribute [26-6527-174] Alc-Lease-Time attribute must be used to specify the lease time. If the [26-6527-174] Alc-Lease-Time is not present in these scenarios, then the RADIUS attribute [27] Session-Timeout is interpreted as DHCPv4 lease time.

9.2.2.3. RADIUS Reply Message for PPPoE PAP/CHAP

The string returned in a [18] Reply-Message attribute in a RADIUS Access-Accept is passed to the PPPoE client in the CHAP Success or PAP Authentication-Ack message.

The string returned in a [18] Reply-Message attribute in a RADIUS Access-Reject is passed to the PPPoE client in the CHAP Failure or PAP Authentication-Nak message.

When no [18] Reply-Message attribute is available, the SR OS default messages are used instead: “CHAP authentication success” or “CHAP authentication failure” for CHAP and “Login ok” or “Login incorrect” for PAP.

9.2.2.4. SHCV Policy

SHCV policies are used to control subscriber host connectivity verification which verifies the host connectivity to the BNG. There are two types of SHCV: periodic and event triggered. Prior to Release 13.0R4, some event triggered SHCV relied on the reference timer set by the host-connectivity-verify under the group interface while others had hard-coded values. Release 13.0R4 introduced the SHCV policy that allows individual configuration of trigger SHCV timers and periodic SHCV timers depending on the application.

Under the group-interface, the host-connectivity-verify configuration was used as a reference timer for some event triggered SHCV while other used hard-coded values. The SHCV-policy separated out every type of SHCV and allows each type to have their individual configurable timer values. Furthermore, individual SHCV trigger types can be shut down. The SHCV policy can be applied to one or more group interfaces and can be configured differently for IPv4 vs. IPv6 hosts.There are various types of triggered SHCV:

Some SHCVs are triggered based on a host’s DHCP messages. These DHCP messages are not buffered. The SHCV is used only to perform a verification check on an old host to verify if the host is still connected to the BNG. Therefore, the BNG still requires the new hosts to retransmit their DHCP messages once the SHCV removes the disconnected host.

9.2.9.1. Provisioning IP Configuration of the Host

The other aspect of subscriber-host authorization is providing IP configuration (ip-address, subnet-mask, default gateway and dns) through RADIUS directory rather than using centralized DHCP server. In this case, the node receiving following RADIUS attributes assumes the role of DHCP server in conversation with the client and provide the IP configuration received from RADIUS server.

These attributes are accepted only if the system is explicitly configured to perform DHCP-server functionality on a given interface.

The following RADIUS attributes are accepted from authentication-response messages:

9.2.9.2. RADIUS-Based Authentication in Wholesale Environment

To support VRF selection, the following attributes are supported:

9.2.9.3. Change of Authorization and Disconnect-Request

In a typical RADIUS environment, the network element serves as a RADIUS client, which means the messages are originated by a routers. In some cases, such as mid-session changes, it is desirable that the RADIUS server initiates a CoA request to impose a change in policies applicable to the subscriber, as defined by RFC 3576.

To configure a RADIUS server to accept CoA and Disconnect Messages is achieved in one of the following ways:

Note: There is a priority in the functions that can be performed by CoA. The first matching one is performed: If the CoA packet contains a Force-Renew attribute, the subscriber gets a FORCERENEW DHCP packet. This function is not supported for PPPoE or ARP hosts. If the CoA packet contains a create-host attribute, a new lease-state is created. Only DHCP lease-states can be created by a CoA message. PPPoE sessions and ARP hosts cannot be created. Otherwise, the ESM strings are updated.

There are several reasons for using RADIUS initiated CoA messages:

If the changes to ESM attributes are required, the RADIUS server sends CoA messages to the network element requesting the change in attributes included in the CoA request:

As a reaction to such message, the router changes the ESM settings applicable to the given host.

If changes to the IP configuration (including the VRF-id in the case of wholesaling) of the given host are needed, the RADIUS server may send a CoA message containing VSA indicating request for FORCERENEW generation:

As a reaction to a message, router generates a DHCP FORCERENEW message for the given subscriber host. Consequently, during the re-authentication, new configuration parameters can be populated based on attributes included in Authentication-response message. The force-NAK attribute has the same function as the Force-Renew attribute, but causes the BNG to reply with a NAK to the next DHCP renew. This invalidates the lease state on the BNG and force the client to completely recreate its lease, making it possible to update parameters that cannot be updated through normal CoA messages, such as IP address or address pool.

If the configuration of the new subscriber-host is required, RADIUS server sends a CoA message containing VSA request new host generation along with VSAs specifying all required parameters.

After executing the requested action, the router element responds with an ACK or NAK message depending on the success/failure of the operation. In case of failure (and hence NAK response), the element includes the error code in accordance with RFC 3576 definitions if an appropriate error code is available.

Supporting CoA messages has security risks as it essentially requires action to unsolicited messages from the RADIUS server. This can be primarily the case in an environment where RADIUS servers from multiple ISPs share the same aggregation network. To minimize the security risks, the following rules apply:

In all cases (creation, modification, force-renew) subscriber host identification attributes are mandatory in the CoA request: “NAS-Port-Id + IP” or “Acct-Session-Id” or “Alc-Subsc-ID-Str” or “user-name”.

When there are no subscriber host identification attributes present in the CoA, the message is NAK’d with corresponding error code.

The properties of an existing RADIUS-authenticated PPPoE session can be changed by sending a Change of Authorization (CoA) message from the RADIUS server. Processing of a CoA is done in the same way as for DHCP hosts, with the exception that only the ESM settings can be changed for a PPPoE session (the Force-Renew attribute is not supported for PPPoE sessions and a Create-Host CoA always generates a DHCP host).

For terminating PPPoE sessions from the RADIUS server, the disconnect-request message can be sent from the RADIUS server. This message triggers a shut down of the PPPoE session. The attributes needed to identify the PPPoE session are the same as for DHCP hosts.

9.2.9.4. RADIUS-Based Accounting

When a router is configured to perform RADIUS-based accounting, at the creation of a subscriber-host, it generates an accounting-start packet describing the subscriber-host and send it to the RADIUS accounting server. At the termination of the session, it generates an accounting-stop packet including accounting statistics for a given host. The router can also be configured to send an interim-accounting message to provide updates for a subscriber-host.

The exact format of accounting messages, their types, and communication between client running on the routers and RADIUS accounting server is described in RFC 2866, RADIUS Accounting. The following describes a few specific configurations.

To identify a subscriber-host in accounting messages different RADIUS attributes can be included in the accounting-start, interim-accounting, and accounting-stop messages. The inclusion of the individual attributes is controlled by the following commands.

RADIUS volume accounting attributes are depending on the type of volume reporting and can be controlled with an include-radius-attribute CLI command. Multiple volume reporting types can be enabled simultaneously:

where:

detailed-acct-attributes — Report detailed per queue and per policer counters using RADIUS VSAs (enabled by default). Each VSA contains a queue or policer id followed by the stat-mode or 64 bit counter. The VSA’s included in the Accounting messages is function of the context (policer or queue, stat-mode, MDA type, and so on):

[26-6527-107] Alc-Acct-I-statmode

[26-6527-127] Alc-Acct-O-statmode

[26-6527-19] Alc-Acct-I-Inprof-Octets-64

[26-6527-20] Alc-Acct-I-Outprof-Octets-64

[26-6527-21] Alc-Acct-O-Inprof-Octets-64

[26-6527-22] Alc-Acct-O-Outprof-Octets-64

[26-6527-23] Alc-Acct-I-Inprof-Pkts-64

[26-6527-24] Alc-Acct-I-Outprof-Pkts-64

[26-6527-25] Alc-Acct-O-Inprof-Pkts-64

[26-6527-26] Alc-Acct-O-Outprof-Pkts-64

[26-6527-39] Alc-Acct-OC-O-Inprof-Octets-64

[26-6527-40] Alc-Acct-OC-O-Outprof-Octets-64

[26-6527-43] Alc-Acct-OC-O-Inprof-Pkts-64

[26-6527-44] Alc-Acct-OC-O-Outprof-Pkts-64

[26-6527-69] Alc-Acct-I-High-Octets-Drop_64

[26-6527-70] Alc-Acct-I-Low-Octets-Drop_64

[26-6527-71] Alc-Acct-I-High-Pack-Drop_64

[26-6527-72] Alc-Acct-I-Low-Pack-Drop_64

[26-6527-73] Alc-Acct-I-High-Octets-Offer_64

[26-6527-74] Alc-Acct-I-Low-Octets-Offer_64

[26-6527-75] Alc-Acct-I-High-Pack-Offer_64

[26-6527-76] Alc-Acct-I-Low-Pack-Offer_64

[26-6527-77] Alc-Acct-I-Unc-Octets-Offer_64

[26-6527-78] Alc-Acct-I-Unc-Pack-Offer_64

[26-6527-81] Alc-Acct-O-Inprof-Pack-Drop_64

[26-6527-82] Alc-Acct-O-Outprof-Pack-Drop_64

[26-6527-83] Alc-Acct-O-Inprof-Octs-Drop_64

[26-6527-84] Alc-Acct-O-Outprof-Octs-Drop_64

[26-6527-91] Alc-Acct-OC-O-Inpr-Pack-Drop_64

[26-6527-92] Alc-Acct-OC-O-Outpr-Pack-Drop_64

[26-6527-93] Alc-Acct-OC-O-Inpr-Octs-Drop_64

[26-6527-94] Alc-Acct-OC-O-Outpr-Octs-Drop_64

[26-6527-108] Alc-Acct-I-Hiprio-Octets_64

[26-6527-109] Alc-Acct-I-Lowprio-Octets_64

[26-6527-110] Alc-Acct-O-Hiprio-Octets_64

[26-6527-111] Alc-Acct-O-Lowprio-Octets_64

[26-6527-112] Alc-Acct-I-Hiprio-Packets_64

[26-6527-113] Alc-Acct-I-Lowprio-Packets_64

[26-6527-114] Alc-Acct-O-Hiprio-Packets_64

[26-6527-115] Alc-Acct-O-Lowprio-Packets_64

[26-6527-116] Alc-Acct-I-All-Octets_64

[26-6527-117] Alc-Acct-O-All-Octets_64

[26-6527-118] Alc-Acct-I-All-Packets_64

[26-6527-119] Alc-Acct-O-All-Packets_64

std-acct-attributes — Report IPv4 and IPv6 aggregated forwarded counters using standard RADIUS attributes (disabled by default):

[42] Acct-Input-Octets

[43] Acct-Output-Octets

[47] Acct-Input-Packets

[48] Acct-Output-Packets

[52] Acct-Input-Gigawords

[53] Acct-Output- Gigawords

v6-aggregate-stats — Report IPv6 aggregated forwarded counters of queues and policers in stat-mode v4-v6 using RADIUS VSAs (disabled by default):

[26-6527-194] Alc-IPv6-Acct-Input-Packets

[26-6527-195] Alc-IPv6-Acct-Input-Octets

[26-6527-196] Alc-IPv6-Acct-Input-GigaWords

[26-6527-197] Alc-IPv6-Acct-Output-Packets

[26-6527-198] Alc-IPv6-Acct-Output-Octets

[26-6527-199] Alc-IPv6-Acct-Output-Gigawords

In addition to accounting-start, interim-accounting, and accounting-stop messages, a RADIUS client on a routers also sends accounting-on and accounting-off messages. An accounting-on message is sent when a given RADIUS accounting-policy is applied to a given subscriber-profile, or the first server is defined in the context of an already applied policy. The following attributes included are in these messages:

Accounting-off messages are sent at following events:

These messages contain following attributes:

In case of dual homing, both nodes send RADIUS accounting messages for the host, with all attributes as it is locally configured. The RADIUS log files on both boxes need to be parsed to get aggregate accounting data for the given subscriber host regardless the node used for forwarding.

For RADIUS-based accounting, a custom record can be defined to refine the data that is sent to the RADIUS server. Refer to the “Configuring an Accounting Custom Record” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for further information.

9.2.9.5. RADIUS Accounting Terminating Cause

The VSA acct-terminate-cause attribute provides some termination information. Two additional attributes: [VSA 227] alc-error-message and [VSA 226] alc-error-code provide additional information in both string and numeric format about the terminating cause of the subscriber session. The full list of error messages and their corresponding error codes can be viewed using the command tools>dump>aaa> radius-acct-terminate-cause.

If required, python can alter the content of both VSAs. The following is a python script example where the error codes are remapped from 123 to 8 and from 124 to 17:

9.2.9.6. Accounting Modes Of Operation

This section is applicable to the 7750 SR or the 7450 ESS. There are three basic accounting models:

Each of the basic models can optionally be enabled to send interim-updates. Inclusion/exclusion of interim-updates depends on whether volume based (start/interim-updates/stop) or time-based (start/stop) accounting is required.

The difference between the three basic accounting models is in its core related to the processing of the acc-session-id for each model. The differences are related to:

The counters for volume-based accounting are collected from queues or policers that are instantiated per sla-profile instance (SPI). This is true regardless of which model of accounting (or combination of models) is deployed. Within accounting context, the SPI equates to queue-instance.

Table 13 summarizes the key differences between various accounting modes of operation that are supported. Interim-updates for each individual mode can be enabled or disabled through configuration (interim-update keyword as an extension to the commands that enable three basic modes of accounting). This is denoted by the IU-Config keyword under the ‘I-U’ column in the table. The table also shows that any two combinations of the three basic models (including their variants for volume and time- based accounting) can be enabled simultaneously.

Note: Hosts within the targeted CoA entity are affected as follows: If the CoA target is the session, then both constituting members (IPv4 and IPv6) of the dual-stack host are affected. If the CoA target is the queuing-instance, then up to 32 hosts that are sharing that SPI are affected.

The same principle applies to LI.

The accounting behavior (accounting messages and accounting attributes) in case that the SPI is changed with CoA depends on the accounting mode of operation. The behavior is the following:

9.2.9.7. Per Session Accounting

In the per session accounting mode of operation the accounting message stream (START/INTERIM-UPDATE/STOP) is generated per session. The accounting message stream refers to a collection of accounting messages (START/INTERIM-UPDATE/STOP) sharing the same acct-session-id.

In dual-stack PPPoE case, IPv4 and IPv6 hosts are tied to the same (LCP) session. A single authentication request is initiated for such session (triggered by the first host that initiates the session).

For a single stack PPPoE host, the behavior defined in the per session accounting model is indistinguishable from the per host accounting model. The per session accounting model makes difference in behavior only for dual-stack PPPoE hosts.

The following are the properties of the Per Session Accounting model:

9.2.9.8. RADIUS Session Accounting with PD as a Managed Route

The Prefix Delegation (PD) prefix is included in the accounting messages using the VSA [99], Framed-IPv6-Route attribute with the string type “pd-host” appended to differentiate it from a regular framed IPv6 route; for example, FRAMED IPV6 ROUTE [99] 39 2001:1000::/64 :: 0 pref 0 type pd-host. PD as a managed route is applicable to both PPP and IPoE sessions and can point either to an IPv4 host or to an IPv6 WAN host.

Table 14 outlines the RADIUS accounting behavior based on the session type and the next-hop host.

RADIUS Per Host Accounting

In SR OS, the accounting paradigm is based on SLA profile instances yet this is at odds with traditional RADIUS authentication and accounting which is host-centric. In previous SR OS releases, it was possible to have many hosts sharing a common SLA profile instance, and thus accounting and QoS parameters. Complications would arise with RADIUS accounting because Accounting-Start and Accounting-Stop are a function of sla-profile instance and not the hosts. This meant that some host-specific parameters (like framed-ip-address) would not be consistently included in RADIUS accounting.

Currently, dual-stack subscribers are really two different hosts sharing a single sla-profile instance. A new RADIUS accounting mode has been introduced to support multiple-host environments.

Under accounting-policy, a host-accounting command allows configurable behavior.

9.2.9.9. No Host-Accounting

In prior releases and when no host-accounting is configured, the accounting behavior is as follows:

9.2.9.10. Host-Accounting Enabled

When host-accounting is configured, additional RADIUS accounting messages are created for host activity in addition to messages for common queue accounting. The behavior is as follows:

This new behavior means certain AVP may be in either host; sla-profile instance or both accounting records.

Note that interim-acct records are not sent for hosts, only the start- and stop-accting messages. Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for attributes that are applicable for RADIUS accounting AVPs.

9.2.9.11. Reduction of Host Updates for Session Accounting Start and Stop

When host-update is enabled In session accounting, a dual-stack subscriber can generate multiple host update accounting messages at the start and end of a session (for example, one for the IPv4 host and two more for the IPv6 WAN and IPv6 PD hosts). Two features can be used to reduce the number of host update messages per subscriber.

The first feature delays the Start Accounting message by a configurable value and is applicable to both PPPoE and IPoE sessions. The command for configuring this feature is config>subscr-mgmt>acct-plcy>delay-start-time. The delay allows the full dual-stack address assignment to be completed before triggering the accounting Start message. The Start message reports all the addresses and prefixes assigned to the subscriber at that time. Subsequent new or disconnected hosts triggers interim host updates if enabled.

The second feature is for PPPoE sessions only and is used to reduce the number of host update messages when a dual-stack PPP subscriber disconnects. The command for configuring this feature is config>subscr-mgmt>sub-prof>rad-acct>session-optimized-stop. A single accounting Stop message containing all the addresses and prefixes for the subscriber at the time is generated.

9.2.9.12. Accounting Interim Update Message Interval

The interval between two RADIUS Accounting Interim Update messages can be configured in the RADIUS accounting policy with the update-interval command, for example:

A RADIUS specified interim interval (attribute [85] Acct-Interim-Interval) overrides the CLI configured value.

By default, a random delay of 10% of the configured update-interval is added to the update-interval between two Accounting Interim Update messages. This jitter value can be configured with the update-interval-jitter to an absolute value in seconds between zero and 3600. The effective maximum random delay value is the minimum value of the configured absolute jitter value and 10% of the configured update-interval.

A value of zero sends the Accounting Interim Update message without introducing an additional random delay.

9.2.9.13. CoA Triggered Accounting Interim Update

The vendor-specific attribute (VSA) [228], Alc-Triggered-Acct-Interim, can be used in a Change of Authorization message to trigger an interim accounting message. This feature requires the accounting mode to have interim updates enabled. You can enable interim updates using, the config>subscr-mgmt>radius-acct-plcy>host-accounting interim-update command. The VSA can hold a string of up to 247 characters. The accounting interim echoes this string in the interim message under the same Alc-Triggered-Acct-Interim VSA along with Alc-Acct-Triggered-Reason = CoA-triggered. If the VSA is left blank, it still triggers the accounting interim message with Alc-Acct-Triggered-Reason = CoA-triggered (18), but without the Alc-Triggered-Acct-Interim attribute. If the subscriber session has multiple accounting policies or modes enabled, multiple interim messages are generated.Some CoAs, such as SLA profile or sub-profile changes, triggers accounting update messages to be generated automatically. These CoAs can automatically generate one or more accounting interim messages. If these CoAs also include the Alc-Triggered-Acct-Interim VSA, no additional interim accounting messages are generated. The last automatically-generated accounting interim message contain these reasons:

9.2.9.14. Class Attribute

The RADIUS class attribute helps to aid in user identification.

User identification is used to correlate RADIUS accounting messages with the given user. During the authentication process, the RADIUS authentication server inserts a class attribute into the RADIUS authenticate response message and the router echoes this class attribute in all RADIUS accounting messages.

The 7750 SR can store up to six class attributes for both RADIUS and NASREQ. Each class VSA or AVP can have a maximum of 253 characters. If the VSA or AVP contains more than 253 characters, only the first 253 characters is stored. If there are more than six VSAs or AVPs, only the first six is stored. This functionality is also applicable to RADIUS authentication by the ISA.

9.2.9.15. User Name

The user-name, which is used for user authentication (user-name attribute in RADIUS authentication request), can be included in RADIUS accounting messages. Per RFC 2865, when a RADIUS server returns a (different) user-name attribute, the changed user name is used in accounting and not the originally sent user name.

9.2.9.16. Accounting-On and Accounting Off

For RADIUS servers configured in a RADIUS server policy, the accounting on and off behavior is controlled with the acct-on-off command in the radius-server-policy.

By default, no Accounting-On or Accounting-Off messages are sent (no acct-on-off).

With the acct-on-off command configured in the radius-server-policy:

The Accounting-On or Accounting-Off message is sent to the servers configured in the radius-server-policy, following the configured access-algorithm until an Accounting Response is received. If the first server responds, no message is sent to the other servers.

The Accounting-On message is repeated until an Accounting Response message is received from a RADIUS server: If after the configured retry or timeout timers for each RADIUS server in the RADIUS server no response is received then the process starts again after a fixed one minute wait interval.

The Accounting-Off message is attempted once: If after the configured retry or timeout timers for each RADIUS server in the RADIUS server policy no response is received then no new attempt is made.

It is possible to block a RADIUS server policy until an Accounting Response is received from one of the RADIUS servers in the RADIUS server policy that acknowledges the reception of an Accounting-On. The RADIUS server policy cannot be used by applications for sending RADIUS messages until the state becomes “Not Blocked”. This is achieved with the optional “oper-state-change” flag, for example:

If multiple RADIUS server policies are in use for different applications (for example, authentication and accounting) and an Accounting-On must be send for only one RADIUS server policy, it is possible to tie the acct-on-off states of both policies together using an acct-on-off-group. With this configuration, it is possible to block the authentication servers until the accounting servers are available. An acct-on-off-group can be referenced by:

It is possible to force an Accounting-On or Accounting-Off message for a RADIUS server policy with acct-on-off enabled using following CLI commands:

tools perform aaa acct-on [radius-server-policy policy-name] [force]

tools perform aaa acct-off [radius-server-policy policy-name] [force] [acct-terminate-cause number]

If an Accounting-On was sent to the radius-server-policy and it was acknowledged with an Accounting Response then a new Accounting-On can only be sent with the “force” flag.

If an Accounting-Off was sent to the radius-server-policy and it was acknowledged with an Accounting Response then a new Accounting-Off can only be sent with the “force” flag. The Acct-Terminate-Cause value in the Accounting-Off can be overwritten.

Use the following CLI command to display the Accounting On/Off information for a radius-server-policy:

The operational state provides following state information: The sending of the Accounting-On or Accounting-Off message is ongoing (sendAcctOn, SendAcctOff), is successfully responded (on, off) or no response received (OffNoResp).

The Session-Id is a unique identifier for each RADIUS server policy accounting Accounting-On/Accounting-Off sequence.

The Trigger field shows what triggered the Accounting On or Accounting Off message. If the radius-server-policy is part of an acct-on-off group then the group name is shown in brackets.

The Server field shows which server in the RADIUS server policy responded to the Accounting-On or Accounting-Off message.

To display the acct-on-off state of a radius-server-policy, use the command, for example:

The Acct-On-Off field indicates if the sending of Accounting-On and Accounting-Off messages is enabled or disabled. If enabled, the oper-state is displayed: state Blocked or state Not Blocked. When Blocked, the radius-server-policy cannot be used to send RADIUS messages.

To display acct-on-off-group information, use following command, for example:

9.2.9.17. RADIUS Accounting Message Buffering

When all servers in a RADIUS server policy are unreachable, it is possible to buffer the Accounting Start, Accounting Stop, and Accounting Interim-Update messages for up to 25 hours. Accounting Start messages have a separate buffer from Accounting Interim-Update and Stop messages. When a RADIUS server becomes reachable again, the messages in the buffer are retransmitted. If, for the same accounting session, an Accounting Start message and an Accounting Interim-Update or Stop message is buffered, then the Accounting Start message is sent before the Interim-Update or Stop message.

RADIUS Accounting message buffering parameters can be configured per message type, for example:

When RADIUS accounting message buffering is enabled:

When Accounting Start message buffering is enabled:

When Accounting Interim-Update message buffering is enabled:

Use the following clear command to manually delete messages from the RADIUS accounting message buffer:

clear aaa radius-server-policy policy-name msg-buffer [acct-session-id acct-session-id]

When specifying the account session ID, only that specific message is deleted from the message buffer. If no account session ID is specified, all messages for that RADIUS server policy are deleted from the message buffer.

Use the following show commands to display the RADIUS accounting message buffer statistics:

Use following clear command to reset the RADIUS accounting message buffer statistics:

# clear aaa radius-server-policy policy-name statistics msg-buffer-only

Use the following tools commands to display the RADIUS accounting message buffer content:

# tools dump aaa radius-server-policy policy-name msg-buffer [session-id acct-session-id]

For example:

When specifying the Acct-Session-Id, the message details are displayed.

9.2.9.18. Multiple Accounting Policies

The subscriber profile allows the user to configure a primary accounting policy with an additional accounting policy. The accounting policies are independent of each other and each policy has its own accounting mode, update interval, and include attributes. The RADIUS VSA [85] Acct-Interim-Interval attribute changes both the primary and the duplicate accounting interim update interval.

9.2.9.19. Sending an Accounting Stop Message upon a RADIUS Authentication Failure of a PPPoE Session

In scenarios where PAP/CHAP RADIUS authentication is used for PPPoE sessions, an accounting stop message can be generated to notify the RADIUS servers in case of an authentication failure. This feature is not supported for PADI authentication.

The failure events are categorized in three categories:

Each of the categories can be enabled separately in the RADIUS authentication policy.

In the Enhanced Subscriber Management (ESM) model, the RADIUS accounting server is found after authentication and host identification as part of the subscriber profile configuration. To report authentication failures to accounting servers, an alternative RADIUS accounting policy configuration is required: local user database pre-authentication can provide the RADIUS authentication policy to be used for authentication and the RADIUS accounting policy to be used for authentication failure reporting. A duplicate RADIUS accounting policy can be specified if the accounting stop resulting from a RADIUS authentication failure must also be sent to a second RADIUS destination.

To enable local user database pre-authentication, use the user-db configuration in the capture SAP and in the group interface. For example:

9.2.9.20. Sending an Accounting Stop Message upon an IPoE Host Creation Failure

If IPoE host creation fails, the system can generate an accounting stop message. This feature is similar to the feature described in Sending an Accounting Stop Message upon a RADIUS Authentication Failure of a PPPoE Session. It allows the system to generate an accounting stop message for most host creation failure cases. For IPoE, only the failure event “on-accept-failure” is supported. This failure condition applies when the host was successfully authenticated but the host creation failed (for example, a duplicate host IP address was detected on the new host).

Because RADIUS accounting starts only after the host is successfully created, a failed host cannot trigger a RADIUS accounting message. For this reason, similar to PPPoE, the local user database must be used to provide the RADIUS accounting server for reporting the failure.

The [26.6527.226] Alc-Error-Code and [26.6527.227] Alc-Error-Message attributes are used to report the failure in the RADIUS accounting stop message. The error code is a numeric value that represents the error, and the error message is a descriptive text string that explains the actual failure reason. For IPoE, the error code uses the 279 value (in decimal format) or 0x117 value (in hexadecimal format) "Failed to create subscriber host". The error message provides the same detailed reason for the host creation failure as the log message in log 99.

9.3.1.1. Standard and Enhanced Subscriber Management

The system can switch between standard and enhanced subscriber management modes on a per SAP basis. The Enhanced Subscriber Management mode is supported on the SR-7 and SR-12 chassis and on the ESS-7 chassis.

Some functions are common between the standard and enhanced modes. These include DHCP lease management, static subscriber host definitions and anti-spoofing. While the functions of these features may be similar between the two modes, the behavior is considerably different.

When the enhanced mode is enabled on a SAP (see Subscriber SAPs), first, the router ensures that existing configurations on the SAP do not prevent proper enhanced mode operation. If any one of the following requirements is not met, enhanced mode operation is not allowed on the SAP:

When the router successfully enables the enhanced mode, the current dynamic subscriber hosts are not touched until a DHCP message event occurs that allows re-population of the dynamic host information. Thus, over time, the dynamic subscriber host entries are moved from SAP-based queuing and SAP-based filtering to subscriber-based queuing and filtering. In the event that a dynamic host event cannot be processed due to insufficient resources, the DHCP ACK message is discarded and the previous host lease information is retained in the system.

9.3.2.1. Models

9.3.2.1.1. PPPoE Host

For PPPoE, the BNG suggests the IPv6CP protocol to the client during the session setup phase if the appropriate attributes have been returned by the RADIUS server on authentication. The RADIUS attribute that indicates the setup of a PPPoE host is Framed-IPv6-Prefix, which should contain a /64 prefix for the client.

When a PPPoE host has successfully completed the IPv6CP negotiation, the BNG transmits a Router Advertisement to the PPPoE host containing the suggested prefix and any other options that are configured. The client may use this information to pick one or more addresses from the suggested prefix; all addresses within the prefix are forwarded towards the client.

Alternatively, the Recursive DNS Server (RDNSS) Option as defined in RFC 6106, IPv6 Router Advertisement Options for DNS Configuration, can be included in IPv6 Router Advertisements for DNS name resolution of IPv6 SLAAC hosts. The following CLI command includes the DNS info in IPv6 Router Advertisements for SLAAC hosts and sets the RDNSS lifetime:

config>service>ies>sub-if>grp-if>ipv6>rtr-adv

config>service>vprn>sub-if>grp-if>ipv6>rtr-adv

 

[no] dns-options 

 

   [no] include-dns    - Set/reset inclusion of the RDNSS server

                         option 25 on this group-interface

   [no] rdnss-lifetime – Maximum time the RDNSS address is valid

                         in this group-interface

 

The source for DNS information to be included in Router Advertisements for IPv6 SLAAC hosts, can be (listed in priority order):

1. Local User Database IPv6 options:
   configure subscriber-mgmt local-user-db <ludb-name> ipoe | ppp host <host-name> options6 dns-server <ip-address> [<ip-address>...(up to 4 max)]
2. RADIUS attributes [26-6527-105] Alc-Ipv6-Primary-Dns and [26-6527-106] Alc-Ipv6-Secondary-Dns
3. Default IPv6 DNS Server configured at the group interface:
   configure service ies | vprn <svc-id> subscriber-interface <ip-int-name> ipv6 default-dns <ipv6-address> [secondary <secondary-ipv6-address>]

Note: A default IPv6 server configuration at the group interface is a last resort IPv6 DNS info that can be used for IPoEv6 hosts (IA_NA, IA_PD and SLAAC) and PPPoEv6 hosts (IA_NA, IA_PD and SLAAC).

9.3.2.2. Setup

IPv6 ESM hosts are only supported in the Routed CO model (both VPRN and IES).

At the IPv6 node under the subscriber interface level, the length of the prefixes that are offered is defined through the delegated-prefix-length option. This setting is fixed for the subscriber interface and cannot be changed once subscriber prefixes are defined.

Subscriber prefixes define the ranges of addresses that are offered on this subscriber interface. By default, only these subscriber prefixes are exported to the routing protocols to keep the routing tables small. There are three types of subscriber interfaces:

The subscriber interface prefix can also be provisioned through RADIUS. The RADIUS VSA Alc-IPv6-Sub-If-Prefix requires a prefix and the prefix type. The prefix type can be pd, wan, or both. The prefix is then installed on the subscriber interface where the subscriber is instantiated. The prefix state is tied to the state of the subscriber. Once the subscriber session ends, the prefix is removed from the subscriber interface and subsequently from both the FDB and the RIB. This feature can be used as an alternative to unnumbered subscriber interfaces, where the subscriber interface prefix does not need to be predetermined. However, by installing the prefix after authentication, the subscriber interface becomes numbered. In an unnumbered subscriber interface all subscriber routes are installed whereas in a numbered subscriber interface only the subscriber interface prefix is advertised, therefore reducing the number of advertised routes significantly. The RADIUS-installed prefix can then be advertised through a routing protocol. Subscriber interface prefixes are under the protocol direct type similar to other router interfaces. To advertise only the subscriber interface prefix installed by RADIUS, origin aaa can be used in the router policy.

The IPv6 node under the group interface contains the DHCPv6 proxy configuration and the router advertisement configuration.

9.3.2.3. 64-bit and 128-bit WAN Mode

Subscriber interfaces are created as 64-bit WAN mode interfaces by default. At the time of creation, the subscriber interface can also be created as a 128-bit WAN mode interface. After the subscriber interface is created, the WAN mode cannot be changed. To change the WAN mode, the 64-bit subscriber interface must be removed and then recreated as 128-bit. This section describes the differences between 64-bit and 128-bit WAN modes.

In a 64-bit WAN mode subscriber interface, the following rules apply.

64-bit WAN mode is applicable in deployment models where each subscriber is assigned a unique /64 WAN-prefix which can be used for DHCP or SLAAC.

In a 128-bit WAN mode subscriber interface, the following rules apply.

9.3.2.4. Behavior

9.3.2.5. Delegated-Prefix-Length

The delegated prefix length (DPL) is applicable to subscriber-hosts with IPv6 Prefix (IA-PD) assigned by the DHCPv6 Server. IPv6 Prefix is more akin to a route then it is to an IP address. The length of the prefix plays crucial role in forwarding decisions, antispoofing, and prefix assignment through DHCPv6 pools in the local DHCPv6 Server.

The structure of an IPv6 prefix is shown in Figure 73.

Figure 73:  IPv6 Prefix 

For example, a DHCPv6 server prefix pool contains an aggregated (configured) IPv6 prefix from which the delegated prefixes are carved out. In Figure 73 this aggregated IPv6 prefix has length of /48. In addition, the DHCPv6 server needs to know the length of the delegated prefix (in the above case /60). These two values are marking the boundary within which a unique delegated prefix is selected.

The delegated prefix length can be obtained using:

Alternatively, the entire prefix, including the DPL can be returned by LUDB.

9.3.2.6. DHCPv6 Relay Agent

A DHCPv6 Relay Agent can support a 7450 ESS and 7750 SR DHCPv6 local server (same or remote chassis) and a third party DHCPv6 external server.

An incoming DHCPv6 client message is relayed within the Relay-Forward message specified in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6). If the server responds with a valid address/prefix, the ESM process attempts to install it. If it fails, the DHCPv6 Relay Agent sends an explicit RELEASE to the server. There is no retransmission of DHCPv6 Relay-Forwards in the case of failure, it requires the client to re-start or re-send the original DHCPv6 message.

A Lightweight DHCPv6 Relay Agent may insert Relay Agent Information including the Interface ID option between the DHCPv6 client and the DHCPv6 Relay Agent.

Additional Relay Agents (non-LDRA) between the DHCPv6 client and the DHCPv6 Relay Agent are not supported.

DHCPv6 Reconfigure messages received from an external DHCPv6 server are forwarded to the DHCP client, if a corresponding DHCPv6 lease exists. The Reconfigure message can be sent in a unicast message to the client or encapsulated in a Relay-Reply message to the DHCPv6 relay agent. The DHCPv6 Reconfigure message is dropped if no corresponding DHCPv6 lease exists.

9.3.2.7. DHCPv6 Relay to Third Party DHCPv6 External Server

When the DHCPv6 Relay Agent is relaying to a third party DHCPv6 external server, following conditions should be met:

Following information is available to the third party DHCPv6 server in a Vendor-Specific-Information-Option (17) included in the Relay-Forward message:

9.3.2.8. DHCPv6 Local Server

A local DHCPv6 pool server for both addresses (IA_NA) and prefixed (IA_PD) manages the address and prefixes sent to either routing gateways or hosts.

Because IPv6 home networks lack NAT, the IPv6 addresses delegated to a routing gateway are in turn assigned to hosts in the home. These addresses are assigned with reasonably long (but configurable) lifetimes so the loss of the WAN connection does not result in the IPv6 hosts in the LAN losing their IPv6 addresses. One consequence of these long lifetimes is that the IPv6 hosts retains any IPv6 address provided the valid-lifetime is greater than zero. If an operator delegates a prefix and then at a later time delegate a second IPv6 prefix, a host may end up with two or more valid prefixes. This situation affects IPv6 source address selection and may result in impaired service.

To overcome the problems of multiple IPv6 prefixes in the home, the operator must ensure that the individual subscriber has the same IPv6 prefix even across modem reboots (that is, if a subscriber session is destroyed and later re-created, an attempt should be made to use the previously delegated prefix). In Release 8.0, the operator used RADIUS for all address and prefix assignment, but in Release 9.0, with the introduction of the local DHCPv6 server, it requires the 7750 to process and maintain some state even after a session disconnects.

For the DHCPv6 local server to function, a DHCPv6 relay or proxy function must also operate alongside ESM. For the purposes of this document, to relay means to implement a DHCPv6 Relay as indicated in RFC 3315: a relay encapsulates the client DHCP message within a DHCP Relay-Forward message and unicasts it to a specified destination.

A proxy is an internal concept. Unlike a DHCPv6 relay, the DHCPv6 proxy does not encapsulate the client message in a Relay-Forward, nor does it send packets towards the Local DHCPv6 Server. The DHCPv6 proxy is exclusively used as an interface between the RADIUS Access-Accept or local user database lookup and the DHCPv6 client in the consumer device.

The use of the DHCPv6 relay or proxy function depends on the attributes returned from authentication phase (RADIUS or LUDB).

Note: If IPv6 DNS parameters are returned in RADIUS and a pool is specified then the DNS parameters are ignored. It is the DHCPv6 server that needs to reply with appropriate DNS servers.

9.3.3.1. Dynamic Tables

To support all processing for Enhanced Subscriber Management, several tables are maintained in the router (Figure 74).

Figure 74:  Enhanced Subscriber Management Dynamic Tables 

9.3.4.1. Instantiating a New Host

When a DHCP ACK is received for a new subscriber host on a particular SAP:

If this is the first host of a subscriber, an HQoS scheduler is instantiated using the ingress and egress scheduler policies referred to in the subscriber profile. Otherwise, if the subscriber profile of the new host equals the subscriber profile of the existing subscriber, the new host is linked to the existing scheduler. If the subscriber profile is different from the subscriber profile of the existing subscriber, a new scheduler is created and all the hosts belonging to that subscriber are linked to this new scheduler. The new subscriber profile does conflict with the subscriber profile provisioned for a static host or non-sub-traffic under the same SAP.

If this is the first host of a subscriber on a particular SAP using a particular SLA profile, an SLA profile instance is generated and added to the SLA profile instance table. This includes instantiating a number of queues, according to the ingress and egress QoS profiles referred to in SLA profile, optionally with some specific overrides defined in the SLA profile. Otherwise the host is linked to the existing SLA profile instance for this subscriber on this SAP.

Note: Any QoS and IP filter policies defined on the SAP are still processed even if Enhanced Subscriber Management is enabled on the SAP. For IPv4 traffic that is dropped due to anti-spoofing, counters, logging, and mirroring can be used. All other Layer 2 traffic that is never blocked by anti-spoofing can be processed by applying a QoS policy on the SAP and can still be classified differently, by the dot1p value. If insufficient hardware resources (queues) or software resources (profile instances) are available to support the new host, the DHCP ACK is dropped and an event is generated.

9.3.4.2. Packet Processing for an Existing Host

Whenever an IP packet arrives on a subscriber-facing SAP on which Enhanced Subscriber Management (ESM) is enabled, a lookup is done in the subscriber host table using as the index the SAP, source IP address, and source MAC address.

9.3.5.1. Functionality

ESM lockout is supported for dual-stack PPPoE hosts, L2TP LAC hosts, dual-stack IPoE hosts, and ARP hosts. ESM Lockout tracks the following:

During lockout, authentication and ESM host creation is suppressed. A lockout context is created when a client first enters lockout. The context maintains state and timeout parameters for the lockout. If a lockout policy is configured for the underlying SAP for a host that has failed authentication or host creation, the host enters lockout for the configured minimum time (1 to 86400 seconds). When the lockout time expires, normal authentication and ESM host creation is resumed on relevant PPP or DHCP messages. In case of another failure, the host again enters the lockout state. The lockout time for the host on each failure is exponentially increased up to the configured maximum time (1 to 86400 seconds). The lockout time for a client is reset to the configured minimum value, and the corresponding lockout context is deleted, if there is no authentication (and host creation) failure within a configured amount of time that needs to elapse after the client initially enters lockout. This time is called the lockout-reset-time.

The host identification for lockout includes <SAP, MAC@, circuit ID, remote ID>.

9.3.6.1. ANCP

Access Node Control Protocol Management (ANCP) can provide the following information to the router:

When ANCP is used with Enhanced Subscriber Management (ESM), a new string ancp-string can be returned from the Python script or from RADIUS. If not returned it defaults to the subscriber ID.

ANCP version 0x31 and 0x32 are both supported and are autodetected at the start of each ANCP session. Within version 0x32, partitioning is also supported.

Multiple partitions from the same Access Node are also supported. If partitions are used, they are automatically detected during the start of an ANCP session.

9.3.6.1.1. Static ANCP Management

As depicted in Figure 76, a DSLAM is connected to an aggregation network that is connecting the DSLAM to a BRAS. ANCP is used to provide SAP level rate management. The DSLAM in this application maintains multiple ANCP connections. The primary connection is to the BRAS, providing rate and OAM capabilities while the secondary is to the router to provide rate management.

7750 SR and 7450 ESS:

Figure 76:  Static ANCP Management Example 

9.3.6.2. General Switch Management Protocol Version 3 (GSMPv3)

General Switch Management Protocol version 3 (GSMPv3) is a generic protocol that allows a switch controller node to establish and maintain connections with one or more nodes to exchange operational information. Several extensions to GSMPv3 exist in the context of broadband aggregation. These extensions were proposed to allow GSMPv3 to be used in a broadband environment as additional information is needed to synchronize the control plane between access nodes (such as DSLAMs) and broadband network gateways (such as BRAS).

In the TPSDA framework, nodes fulfill some BRAS functionality, where per subscriber QoS enforcement is one of the most important aspects. To provide accurate per-subscriber QoS enforcement, the network element not only knows about the subscriber profile and its service level agreement but it is aware of the dynamic characteristics of the subscriber access circuit.

The most important parameters in this context are the subscriber-line capacity (DSL sync-rate) and the subscriber's channel viewership status (the actual number of BTV channels received by the given subscriber in any point in time). This information can be then used to adjust parameters of aggregate scheduling policy.

Besides, the above-mentioned information, GSMPv3 can convey OAM information between a switch controller and access switch. The node can operate in two roles:

The DSL forum working documents recommends that a dedicated Layer 2 path (such as, a VLAN in an Ethernet aggregation network) is used for this communication to provide a certain level of security. The actual connection between DSLAM and BRAS is established at TCP level, and then individual messages are transported.

9.3.6.3. DHCP Release Messages

The node supports DHCP release messages. A DHCP release message removes state from the DHCP server when the node rejects ACKs or removes hosts.

9.3.6.4. DHCP Client Mobility

Client mobility allows the node to use host monitoring (SHCV, ANCP, split DHCP) to remove network and server state when a host is removed locally. This allows for MAC addressed learned and pinned to move based on policy parameters.

Subscriber Host Connectivity Verification (SHCV) configuration is mandatory. This allows clients to move from one SAP to another SAP in the same service. This is only applicable in a VPLS service and group interfaces.

The first DHCP message on the new SAP with same MAC address (and IP address for group-interfaces) triggers SHCV and is always discarded.

SHCV checks that the host is no longer present on the SAP where the lease is currently populated to prevent spoofing. When SHCV detects that the host is not present on the original SAP, the lease-state is removed. The next DHCP message on the new SAP can initiate the host.

9.3.6.5. DHCP Lease Control

DHCP lease control allows the node to be configured to present a different lease to the client. This can be used to monitor the health of the client.

9.3.7.1. Python Language and Programmable Subscriber Configuration Policy (PSCP)

PSCP is an identification mechanism using the Python scripting language. The PSCP references a Python script that can use regular expressions to derive the sub-ident-string, sub-profile-string and sla-profile-string from the DHCP response. A tutorial of regular expressions is beyond the scope of this guide, and can be found on the Internet (refer to https://docs.python.org/2/howto/regex.html).

A tutorial of Python is beyond the scope of this guide but can be found on the Internet (refer to http://www.python.org/).

Example scripts, using some regular expressions, can be found in Sample Python Scripts. See the Python Script Support for ESM section for additional information about the service manager scripting language.

One or more scripts can be written by the operator and stored centrally on a server (in a location accessible by the router). They are loaded into each router at bootup.

Note that if a centrally stored script is changed, it is not automatically re-loaded onto the router. The reload must be forced by executing the shutdown and no shutdown commands on the affected URL(s).

9.3.7.2. Determining the Subscriber Profile and SLA Profile of a Host

Figure 78 describes the data flow while determining which subscriber profile and SLA profile to use for a certain subscriber host based on a snooped/relayed DHCP ACK for that subscriber host.

Figure 78:  Data Flow in Determining Subscriber Profile and SLA Profile 

An incoming DHCP ACK (relayed or snooped) is processed by the script provisioned in the sub-ident-policy defined in the SAP on which the message arrived. This script outputs one or more of the following strings:

These strings are used for a lookup in one or more maps to find the names of the sub-profile and sla-profile to use. If none of the maps contained an entry for these strings, the names are determined based on a set of defaults.

Only when the names for both the sub-profile and sla-profile are known, the subscriber host can be instantiated. If even no default is found for either profile, the DHCP ACK is dropped and the host does not gain network access.

9.3.7.3. Determining the Subscriber Profile

All hosts (devices) belonging to the same subscriber are subject to the same HQoS processing. The HQoS processing is defined in the sub-profile. A sub-profile refers to an existing scheduler policy and offers the possibility to overrule the rate of individual schedulers within this policy.

Because all subscriber hosts of one subscriber use the same scheduler policy instance, they must all reside on the same I/O module.

Figure 79 shows how the sub-profile is derived, based on the sub-ident string, the sub-profile string and/or the provisioned data structures. The numbers associated with the arrows pointing toward the subscriber profiles indicate the precedence of the checks.

Figure 79:  Determining the Subscriber Profile 

9.3.7.4. Determining the SLA Profile

For each host that comes on-line, the router also needs to determine which SLA profile to use. The SLA profile determines for this host:

The SLA profile also has host-limits and session-limits attributes that limit the number of hosts or sessions per SLA profile instance.

The classification and the queue mapping are shared by all the hosts on the same forwarding complex that use the same QoS policy (by their SLA profile).

The queues/policers are shared by all the hosts (of the same subscriber) on the same SAP that are using the same SLA profile. In other words, queues/policers are instantiated when, on a given SAP, a host of a subscriber is the first to use a certain SLA profile. This instantiation is referred to as an SLA profile instance. Ingress queues can be parented to a scheduler referenced in the ingress of a subscriber profile. Egress policers and queues can be parented to a scheduler referenced in the egress of a subscriber or SLA profile, or to a port scheduler.

A scheduler policy can be applied to the egress an SLA profile, allowing its schedulers to be the parent for its queues and for its tier 1 schedulers to be parented to a scheduler in a scheduler policy applied to the egress of a subscriber profile or a Vport, or to a port scheduler applied to a port or Vport. Configuring scheduler overrides is allowed for SLA profile egress schedulers. The configuration of a scheduler policy in the egress of an SLA profile is supported for all host types only on Ethernet interfaces. It is not supported for ESM over MPLS pseudowires, nor is HQoS adjustment and host tracking supported on its schedulers.

The following show, monitor and clear commands are available related to the SLA profile scheduler:

The show qos scheduler-hierarchy subscriber command (shown above) displays the scheduler hierarchy with the SLA profile scheduler as the root. Note that if the SLA profile scheduler is orphaned (that is when the scheduler has a parent which does not exist) then the hierarchy is only shown when the show command includes the sla-profile and sap parameters.

If the SLA profile scheduler is orphaned (that is when the scheduler has a parent which does not exist) then the hierarchy is only shown when the show command includes the sla-profile and SAP parameters.

Figure 80 shows a graphical description of how the SLA profile is derived based on the subscriber identification string, the SLA profile string and the provisioned data structures. The numbers on the arrows towards the SLA profile indicate the priority of the provisioning (the lower number means the higher priority).

Figure 80:  Determining the SLA Profile 

9.3.7.4.1. SLA Profile Instance Sharing

Each subscriber host or session has an SLA Profile Instance (SPI) associated with it. The SPI, is by default, determined by the subscriber ID, the SLA profile name, and the SAP where the subscriber host or session is active. See Figure 75.

SPIs with the same SLA profile name, have the same configuration, however, the following functions are effective per SPI:

1. enforcing the different host limits
2. instantiation of queues and policers
3. accounting statistics
4. credit control functions

For a bridged Residential Gateway deployment, typically multiple IPoE or PPPoE sessions per subscriber are active on the BNG. The next sections describe the different SPI sharing mechanisms that apply for multiple subscriber sessions from the same subscriber, that are active on the same SAP with the same SLA profile name assigned.

9.3.7.4.1.1. SPI Sharing per SAP

By default, all subscriber sessions or hosts from the same subscriber, active on the same SAP and with the same SLA profile assigned, share an SPI. The default SPI sharing is per SAP, as depicted in Figure 81.

Figure 81:  SLA Profile Instance per SAP 

With SPI sharing per SAP, traffic from all subscriber sessions on a given SAP and with the same SLA profile associated are mapped to the same set of queues and policers for QoS handling. Statistics from these queues and policers are also used in accounting. Per-host or per-session accounting modes cannot report counters for individual sessions unless their traffic is mapped in separate queues.

SPI sharing per SAP is the default configuration in an SLA profile and applies to PPPoE sessions, IPoE sessions (enabled on the group-interface) and IPoE hosts (IPoE sessions are disabled on the group-interface):

Example:

configure

    subscriber-mgmt

        sla-profile "sla-profile-1"

            def-instance-sharing per-sap

9.3.7.4.1.2. SPI Sharing - per Session

If QoS handling or accounting per-IPoE or per-PPPoE session is required, then the SPI sharing is configured to per-session sharing in the SLA profile:

Example:

configure

    subscriber-mgmt

        sla-profile "sla-profile-1"

            def-instance-sharing per-session

Per-session sharing applies to PPPoE sessions and IPoE sessions (enabled on the group interface). An IPoE host setup fails when IPoE sessions are disabled on the group interface and per-session sharing is configured.

Each IPoE or PPPoE session from the same subscriber, active on the same SAP and having the same SLA profile assigned, has its own set of queues and policers. Per-session SPI sharing is depicted in Figure 82.

Figure 82:  SLA Profile Instance per Session 

Note: SPI sharing per session is not supported on HS MDA and on HSQ with hs-sla-mode single.

9.3.7.4.1.3. SPI per Group

When even more granular control is needed over which sessions share an SPI, an SPI sharing group identifier can be specified during IPoE or PPPoE session authentication. This overrides the default SPI sharing method for that session as configured in the SLA profile.

Per-group SPI sharing is depicted in Figure 83. The same SPI is shared by all IPoE and PPPoE sessions from the same subscriber, active on the same SAP, having the same SLA Profile assigned and having the same SPI sharing group identifier.

Note: SPI sharing per group is not supported on HSQ with hs-sla-mode single.

Figure 83:  SLA Profile Instance per Group 

The SPI sharing group identifier is an integer value in the range 0 to 65535 and can be specified in authentication using:

1. A local user database lookup:
        configure

           subscriber-mgmt

              local-user-db local-user-db-name

                 ipoe | ppp

                    host host-name

                       identification-strings

                          spi-sharing-group-id <group-id>
   Configure no spi-sharing-group-id to apply the def-instance-sharing method as configured in the SLA profile.
2. RADIUS, by including the [241.26.6527.47] Alc-SPI-Sharing-Id VSA in an Access-Accept message:
   1. Value "group:<group-id>" to enable SPI sharing per group identifier
   2. Value "default" to apply the def-instance-sharing method as configured in the SLA profile
   Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for a detailed description of the attribute.
3. Diameter NASREQ, by including the Vendor specific [NOKIA-1036] Alc-SPI-Sharing grouped AVP in an AA-Answer message:
           Alc-SPI-Sharing ::= < AVP Header: 1036 >

                                   {Alc-SPI-Sharing-Type}

                                   [Alc-SPI-Sharing-Id]
   1. To enable SPI sharing per group identifier
      1. [NOKIA-1037] Alc-SPI-Sharing-Type = 2
      2. [NOKIA-1038] Alc-SPI-Sharing-Id = <group-id>
   2. To apply the def-instance-sharing method as configured in the SLA profile:
      1. [NOKIA-1037] Alc-SPI-Sharing-Type = 0
   See the Diameter and Diameter Applications, AA-Answer Message — Accepted Authorization AVPs section for a detailed description of the attribute.
4. Diameter Gx, by including the Vendor specific [NOKIA-1036] Alc-SPI-Sharing grouped AVP in a CCA message:
           Alc-SPI-Sharing ::= < AVP Header: 1036 >

                                   {Alc-SPI-Sharing-Type}

                                   [Alc-SPI-Sharing-Id]
   1. To enable SPI sharing per group identifier
      1. NOKIA-1037] Alc-SPI-Sharing-Type = 2
      2. NOKIA-1038] Alc-SPI-Sharing-Id = <group-id>
   2. To apply the def-instance-sharing method as configured in the SLA profile:
      1. [NOKIA-1037] Alc-SPI-Sharing-Type = 0
   See 7750 SR Gx AVPs Reference Guide for a detailed description of the attribute.
5. Python:
   1. alc.dts.setESM module: alc.dtc.SpiSharingGroupId = <group-id>
   2. alc.esm.set module: alc.esm.SpiSharingGroupId = <group-id>
   See the DHCP Management, ESM-Related Python Variables section for further details.

Per-group sharing applies to PPPoE sessions and IPoE sessions (enabled on the group interface). An IPoE host setup fails when IPoE sessions are disabled on the group interface and an SPI sharing group identifier is specified.

9.3.7.4.1.4. Dynamic Changes of SLA Profile and SPI Sharing

During the lifetime of an IPoE or PPPoE session, the SLA profile and the SPI sharing can change. Such a dynamic change can be triggered by re-authentication, RADIUS CoA, or Diameter Gx RAR by specifying a new SLA profile and optionally, an SPI sharing group ID.

Table 16 describes the different transitions in SPI sharing because of re-authentication, RADIUS CoA, or Diameter Gx RAR.

Table 16:  Dynamic Changes of SPI Sharing  

from ↓ to	SLA Profile and SPI sharing info provided for dynamic change
per sap ↓ per sap	SLA profile = <SLA profile name> SLA profile with "def-instance-sharing per-sap" [SPI sharing type = default] Optional. Value must be default when present SPI sharing ID must not be present
per session ↓ per session	[SLA profile = <SLA profile name>] SLA profile with "def-instance-sharing per-session" [SPI sharing type = default] Optional. Value must be default when present SPI sharing ID must not be present
per group ↓ per group	SLA profile = <SLA profile name> Optional. Current SLA profile name is used when not specified SPI sharing type = group SPI sharing ID = <group-id> Overrides the "def-instance-sharing" configured in the SLA profile
per sap ↓ per group	SLA profile = <SLA profile name> Optional. Current SLA profile name is used when not specified SPI sharing type = group SPI sharing ID = <group-id> Overrides the "def-instance-sharing" configured in the SLA profile
per session ↓ per group	SLA profile = <SLA profile name> Optional. Current SLA profile name is used when not specified SPI sharing type = group SPI sharing ID = <group-id> Overrides the "def-instance-sharing" configured in the SLA profile
per group ↓ per sap	SLA profile = <SLA profile name> Optional. Current SLA profile name is used when not specified SLA profile with "def-instance-sharing per-sap" SPI sharing type = default SPI sharing ID must not be present ------------------------------------------------------------------------------------ SLA profile = <SLA profile name> SLA profile with "def-instance-sharing per-sap"
per group ↓ per session	[SLA profile = <SLA profile name>] Optional. Current SLA profile name is used when not specified SLA profile with "def-instance-sharing per-session" SPI sharing type = default SPI sharing ID must not be present ------------------------------------------------------------------------------------ SLA profile = <SLA profile name> SLA profile with "def-instance-sharing per-session"
per sap ↓ per session	SLA profile = <SLA profile name> SLA profile with "def-instance-sharing per-session" [SPI sharing type = default] Optional. Value must be default when present SPI sharing ID must not be present
per session ↓ per sap	SLA profile = <SLA profile name> SLA profile with "def-instance-sharing per-sap" [SPI sharing type = default] Optional. Value must be default when present SPI sharing ID must not be present

9.3.7.4.1.5. Identifying the SPI

An SPI is uniquely identified by the following characteristics:

1. the subscriber identifier
2. the SAP on which the subscriber session is active
3. the SLA profile name
4. An SPI sharing identifier that has two parts to support overlapping ids between groups and sessions:
   1. SPI sharing type: per SAP, per IPoE session, per PPP session, per group
   2. SPI sharing id:
      1. an integer value determined by the system for SPI sharing per session
      2. an integer value in the range 0 to 65535 specified by the user for SPI sharing per group
      3. not required for SPI sharing per SAP

The following are examples for SPI representations in the system:

1. SPI sharing per SAP
   A:PE-1# show service active-subscribers detail

   ===============================================================================

   Active Subscribers

   ===============================================================================

   -------------------------------------------------------------------------------

   Subscriber sub-01 (sub-profile-12)

   -------------------------------------------------------------------------------

   --- snip---

   -------------------------------------------------------------------------------

   (1) SLA Profile Instance

       - sap:[1/1/4:1201.41] (IES 1000 - group-int-1-1)

       - sla:sla-profile-12

   -------------------------------------------------------------------------------

   --- snip---

   A:PE-1# show service active-subscribers hierarchy

   ===============================================================================

   Active Subscribers Hierarchy

   ===============================================================================

   -- sub-01 (sub-profile-12)

      |

      +-- sap:[1/1/4:1201.41] - sla:sla-profile-12

          |

          |-- PPP-session - mac:00:51:00:00:01:41 - sid:1 - svc:1000

          |   |

          |   +-- 10.1.1.141 - IPCP

          |

          |-- PPP-session - mac:00:51:00:00:01:42 - sid:2 - svc:1000

          |   |

          |   +-- 10.1.1.142 - IPCP

          |

          +-- PPP-session - mac:00:51:00:00:01:43 - sid:3 - svc:1000

              |

              +-- 10.1.1.143 - IPCP

   -------------------------------------------------------------------------------

   Number of active subscribers : 1

   Flags: (N) = the host or the managed route is in non-forwarding state

   ===============================================================================

   *A:PE-1# show qos scheduler-hierarchy subscriber "sub-01" detail

   ===============================================================================

   Scheduler Hierarchy - Subscriber sub-01

   ===============================================================================

   --- snip ---

   Root (Egr)

   | slot(1)

   |--(Q) : Sub=sub-01:sla-profile-12 1000->1/1/4:1201.41->6  (Port 1/1/4)

   |   |    AdminPIR:1500       AdminCIR:1500

   --- snip ---
2. SPI sharing per session

   Note: Although they can have the same value as in the following output, an SPI sharing id is not the same as the PPP session id.

   A:PE-1# show service active-subscribers detail

   ===============================================================================

   Active Subscribers

   ===============================================================================

   -------------------------------------------------------------------------------

   Subscriber sub-01 (sub-profile-12)

   -------------------------------------------------------------------------------

   ---snip---

   -------------------------------------------------------------------------------

   (1) SLA Profile Instance

       - sap:[1/1/4:1201.41] (IES 1000 - group-int-1-1)

       - sla:sla-profile-12 PPP session:10

   -------------------------------------------------------------------------------

   ---snip---

   A:PE-1# show service active-subscribers hierarchy

   ===============================================================================

   Active Subscribers Hierarchy

   ===============================================================================

   -- sub-01 (sub-profile-12)

      |

      |-- sap:[1/1/4:1201.41] - sla:sla-profile-12 PPP session:10

      |   |

      |   |-- PPP-session - mac:00:51:00:00:01:41 - sid:10 - svc:1000

      |   |   |

      |   |   +-- 10.1.1.141 - IPCP

      |

      |-- sap:[1/1/4:1201.41] - sla:sla-profile-12 PPP session:11

      |   |

      |   |-- PPP-session - mac:00:51:00:00:01:42 - sid:11 - svc:1000

      |   |   |

      |   |   +-- 10.1.1.142 - IPCP

      |

      +-- sap:[1/1/4:1201.41] - sla:sla-profile-12 PPP session:12

          |

          +-- PPP-session - mac:00:51:00:00:01:43 - sid:12 - svc:1000

              |

              +-- 10.1.1.143 - IPCP

   -------------------------------------------------------------------------------

   Number of active subscribers : 1

   Flags: (N) = the host or the managed route is in non-forwarding state

   ===============================================================================

   A:PE-1# show qos scheduler-hierarchy subscriber "sub-01" detail

   ===============================================================================

   Scheduler Hierarchy - Subscriber sub-01

   ===============================================================================

   --- snip ---

   Root (Egr)

   | slot(1)

   |--(Q) : Sub=sub-01:sla-profile-12:PPP-10 1000->1/1/4:1201.41->6  (Port 1/1/4)

   |   |    AdminPIR:1500       AdminCIR:1500

   --- snip ---
3. SPI sharing per-group
   A:PE-1# show service active-subscribers detail

   ===============================================================================

   Active Subscribers

   ===============================================================================

   -------------------------------------------------------------------------------

   Subscriber sub-01 (sub-profile-12)

   -------------------------------------------------------------------------------

   ---snip---

   -------------------------------------------------------------------------------

   (1) SLA Profile Instance

       - sap:[1/1/4:1201.41] (IES 1000 - group-int-1-1)

       - sla:sla-profile-12 group:100

   -------------------------------------------------------------------------------

   ---snip---

   A:PE-1# show service active-subscribers hierarchy

   ===============================================================================

   Active Subscribers Hierarchy

   ===============================================================================

   -- sub-01 (sub-profile-12)

      |

      |-- sap:[1/1/4:1201.41] - sla:sla-profile-12 group:100

      |   |

      |   |-- PPP-session - mac:00:51:00:00:01:41 - sid:15 - svc:1000

      |   |   |

      |   |   +-- 10.1.1.141 - IPCP

      |   |

      |   |-- PPP-session - mac:00:51:00:00:01:42 - sid:14 - svc:1000

      |   |   |

      |   |   +-- 10.1.1.142 - IPCP

      |

      +-- sap:[1/1/4:1201.41] - sla:sla-profile-12 group:200

          |

          +-- PPP-session - mac:00:51:00:00:01:43 - sid:13 - svc:1000

              |

              +-- 10.1.1.143 - IPCP

   -------------------------------------------------------------------------------

   Number of active subscribers : 1

   Flags: (N) = the host or the managed route is in non-forwarding state

   ===============================================================================

   A:PE-1#  show qos scheduler-hierarchy subscriber "sub-01" detail

   ===============================================================================

   Scheduler Hierarchy - Subscriber sub-01

   ===============================================================================

   ---snip---

   Root (Egr)

   | slot(1)

   |--(Q) : Sub=sub-01:sla-profile-12:Group-100 1000->1/1/4:1201.41->6  (Port 1/1/4)

   |   |    AdminPIR:1500       AdminCIR:1500

   ---snip---

In RADIUS accounting messages, the SPI is uniquely defined by the following attributes:

Example:

configure

    subscriber-mgmt

        radius-accounting-policy "acct-policy-1"

            include-radius-attribute

                subscriber-id

                nas-port-id

                sla-profile

                spi-sharing

For example:

 NAS PORT ID [87] 13 1/1/4:1201.41

    VSA [26] 40 Nokia(6527)

      SUBSC ID STR [11] 6 sub-01

      SLA PROF STR [13] 14 sla-profile-12

    

    # SPI sharing per SAP:

    VSA [241.26] 3 NOKIA(6527)

      SPI SHARING_ID [47] 3 SAP

    # SPI sharing per session:

    VSA [241.26] 14 NOKIA(6527)

      SPI SHARING_ID [47] 14 PPP session:12

    # SPI sharing per group:

    VSA [241.26] 14 NOKIA(6527)

      SPI SHARING_ID [47] 9 group:100

9.3.8.1. Online Change of Sub-id and Brg-id

The sub-id and brg-id strings can be changed online with CLI and CoA/RAR (RADIUS and Diameter interfaces). Conversion between any combination of long and short sub-ids and short brg-ids is supported by moving each IPoE/PPPoE session or host under a new or renamed subscriber. This is performed by:

9.3.8.2. Usage Notes

This section describes the usage of sub-id and brg-id criteria.

Multicast host tracking only works with short sub-ids and is configured as follows:

However, multicast HQoS adjustment is supported with long sub-ids, and should be deployed as a replacement for legacy multicast host tracking. Multicast HQoS adjustment is configured as follows:

9.3.9.1. Sub-id Identifiers

The sub-id can be based on any combination of the following identifiers:

9.3.9.2. Dual-Stack Hosts

Auto-generation of sub-id names for subscribers with a single dual-stack hosts (IPoE and PPPoE) is enabled by default by not explicitly provisioning anything for the def-sub-id. The sub-id name would be semi-randomly generated based on the <mac, sap-id, session-id> for PPPoE hosts and the <mac, sap-id> combination for IPoE host.

9.3.9.3. Mixing Hosts with Auto-Generated IDs and non-Auto-Generated IDs

Hosts with different sub-id names but identical auto-sub-id keys are not linked into the same subscriber. Such scenarios can arise with hosts with the same auto-sub-id keys but different methods for obtaining the sub-id name. For example, one host relying on auto-generated sub-id name while the other is using explicit configuration methods (sap-id, string, RADIUS or LUDB). If the auto-generated sub-id name and explicit sub-id name are the same, the host is tied into the same subscriber.

For example:

The default auto-sub-id for the following two hosts are <mac, sap-id>.

Host X on SAP 1/1/1:1 with MAC 00:00:00:00:00:01 obtains sub-id through RADIUS.

Host Y on SAP 1/1/1:1 with MAC 00:00:00:00:00:01 has sub-id auto-generated.

Regardless of which host comes up first, those two hosts at the end belong to different subscribers if their sub-ids are different.

9.3.9.4. Deployment Considerations

The following is a deployment example scenario.

Assume the following cases:

In the first case where RADIUS returns the sub-id string, the following occurs

In the second case, the effects are the following:

9.3.9.5. Caveats

Only a single combination of the subscriber fields used to auto generate sub-id is allowed per host type (IPoE or PPPoE) and per chassis. In case that the combination of the fields needs to be changed, the existing subscribers with an auto-generated sub-id must be manually terminated. Considering that remote termination of the IPoE subscribers by DHCP server is not supported by all DHCP client vendors through FORCERENEW DHCP message (RFC 3203), changing the subscriber fields while subscribers with auto generated sub-id are active should be avoided.

9.3.10.1. Limiting the Number of IPoE Sessions

The number of IPoE sessions per SAP is limited with the sap-session-limit command configured in the group-interface ipoe-session context

The number of IPoE sessions per group interface or retail subscriber interface is limited with the session-limit command configured in the group-interface ipoe-session or retail subscriber-interface ipoe-session context.

IPoE sessions and subscriber hosts associated with IPoE sessions are subject to the per SLA profile instance host and session limits configured in the config>subscr-mgmt>sla-prof>host-limits context and to the per subscriber host and session limits configured in the config>subscr-mgmt>sub-prof context. See Limiting the Number of Hosts and Sessions per SLA Profile Instance and per Subscriber for a detailed description.

9.3.10.2. Limiting the Number of PPPoE Sessions

The number of PPPoE sessions per SAP is limited with the sap-session-limit command configured in the group-interface pppoe context.

To limit the number of PPPoE sessions per group interface or retail subscriber interface use the session-limit command configured in the group-interface pppoe or retail subscriber-interface pppoe context.

PPPoE sessions and subscriber hosts associated with PPPoE sessions are subject to the per SLA profile instance host and session limits configured in the config>subscr-mgmt>sla-prof>host-limits context and to the per subscriber host and session limits configured in the config>subscr-mgmt>sub-prof context. See Limiting the Number of Hosts and Sessions per SLA Profile Instance and per Subscriber for a detailed description.

9.3.10.3. Limiting the Number of Hosts and Sessions per SLA Profile Instance and per Subscriber

Table 22 list the host limits and Table 24 lists the session limits that can be configured in the following profiles:

Example

For a bridged RGW, allow one dual stack IPoE session (IPv4 and IPv6 IA-PD) per SLA profile instance and up to two sessions per subscriber.

Table 23 specifies the host-limits counters that are applicable for each of the different subscriber host types in SR OS. Table 25 specifies the session-limits counters that are applicable for each of the different subscriber session types in SR OS.

Host and session limits are checked when the host or session is created in the system. When a limit is reached, the host or session setup fails, and an error event is logged. For example:

When a host or session limit is reached for an ARP host, an IPoE host or an IPoE session, a host-limit-exceeded Subscriber Host Connectivity Verification (SHCV) can be triggered to clean up the state of disconnected devices.

Note: If the remove-oldest command is configured in the host-limits context and an IPv4 ARP host, IPv4 DHCP host, IPv4 host, or subscriber host limit is reached when a new DHCPv4 host or an ARP host connects, the oldest active host disconnects and the new host is granted access. The dynamic host with the least remaining lease time is considered the oldest host. The remove-oldest command is not applicable for PPPoE or IPv6 subscriber hosts.

The host and session limits per SLA profile instance and per subscriber can be overridden at subscriber host or session creation by the following.

The combination of overrides and configured limits is only checked when the host or session is created.

Overrides are stored in the subscriber host and session ESM info and can be displayed using the following show commands:

For example:

It is the operator's responsibility to keep consistency in the overrides that are stored per subscriber host and session by the following:

For existing hosts or sessions, this consistency can be achieved by a mid-session change, for example, by RADIUS CoA or Diameter Gx RAR or CCA-U.

Note: If different subscriber hosts or sessions that belong to the same SLA profile instance or subscriber have different override limits, an inconsistent behavior can occur when sessions are recovered from persistency or in case of Multi-Chassis Synchronization (MCS). This may occur because the order in which hosts recover from persistency and the order in which the hosts or sessions are synchronized through MCS, may be different from the order in which sessions were created in the system.

9.3.12.1. QoS Parameters in Different Profiles

QoS aspects for subscribers and hosts can be defined statically on a SAP or dynamically using.

Enhanced Subscriber Management. For example, in a VLAN-per-service model, different services belonging to a single subscriber are split over different SAPs, and thus the overall QoS (such as a scheduler policy) of this subscriber must be assigned using Enhanced Subscriber Management.

QoS parameters are shared among the subscriber profile and SLA profile as follows:

The primary use of the subscriber profile is to define the ingress and egress scheduler policies and policer control policies used to govern the aggregate SLA for all hosts associated with a subscriber. To be effective, the queues or policers defined in the SLA profile’s QoS policies references a scheduler or arbiter from the scheduler policy or policer-control-policy respectively as their parent.

9.3.12.2. QoS Policy Overrides

Generic QoS queue or policer parameters can be specified for the SAP in a QoS policy and overridden for some customers by queue and policer parameters defined in the SLA profile. This allows for a single SAP ingress and SAP egress QoS policy to be used for many subscribers, while providing individual subscriber parameters for queue or policer operation.

9.3.13.1. Subscriber HQoS

Hierarchical QoS (HQoS) corresponds to scheduling bandwidth distribution to policers, queues and schedulers and is applied using scheduler policies at ingress and egress of the subscriber profile for a subscriber, and at egress in the SLA profile for a host, together with a port scheduler at both the port and Vport level.

Each scheduler policy can contain up to three tiers of schedulers with lower level schedulers being able to parent to higher level schedulers in the same scheduler policy.

Policers and queues can parent to any scheduler in their related scheduler policy hierarchy (except Vport at egress) and also at the egress to a port scheduler.

Schedulers can parent to any higher level scheduler in their related scheduler policy hierarchy and, at the egress to a port scheduler configured within the port or Vport. When an egress port scheduler is used, an aggregate rate limit can be applied at the subscriber profile and Vport levels instead of using a scheduler. To extend the hierarchy further at egress, a tier 1 scheduler within a scheduler policy can parent to any scheduler in a scheduler policy at a higher level.

The scheduling levels are comprised of:

The ingress hierarchical parenting relationship options are shown in Figure 84.

Figure 84:  Ingress Scheduling Hierarchy Options 

The egress hierarchical parenting relationship options are shown in Figure 85. Not all combinations can be configured concurrently, and some uses of port parent could be equally achieved using a scheduler parent and a child parent-location.

Figure 85:  Egress Scheduling Hierarchy Options 

The parent command is used to specify the name of the parent scheduler when parenting a queue or scheduler, together with the level/cir-level and weight/cir-weight at which to connect.

The location of the parent scheduler (in which applied scheduler policy it exists) for a policer or queue defaults to a scheduler in the subscriber ingress or egress scheduler policy. Parents of schedulers themselves must be explicitly configured and by default must be within the same scheduler policy.

At egress, the scheduler parenting relationship is determined using the parent-location command:

By default, egress queues parent to any scheduler in subscriber egress scheduler policy.

Egress queues can parent to any scheduler within the scheduler policy applied to the egress of an SLA profile (this is not supported for policers managed by HQoS).

By default, a tier 1 scheduler in the scheduler policy is not allowed to be parented to another scheduler.

A tier 1 scheduler in the scheduler policy applied to the egress of an SLA profile can parent to a scheduler applied to the egress of a subscriber profile.

A tier 1 scheduler in the scheduler policy applied to the egress of a subscriber profile can parent to a scheduler applied to the egress of a Vport.

The configuration of a parent-location and frame-based accounting in a scheduler policy is mutually exclusive to ensure consistency between the different scheduling levels.

Note that the parent-location command is supported only on Ethernet interfaces. It is not supported for ESM over MPLS pseudowires.

Both egress queues and egress schedulers can port parent using directly to different levels/cir-levels, with different weights/cir weights, to a port egress port scheduler. Egress schedulers can also port parent directly to different levels/cir-levels, with different weights/cir weights, to a Vport egress port scheduler.

9.3.13.2. Subscriber CFHP

Class Fair Hierarchical Policing (CFHP) corresponds to the policing control of traffic by policers/arbiters. This uses policer control policies and can be applied for ingress and egress capacity control for the subscriber in the subscriber profile.

Each policer control policy can contain up to three tiers of arbiters with lower level arbiters being able to parent to higher level arbiters in the same scheduler policy.

Policers can parent to any arbiter in their related policer control policy hierarchy.

The policing levels are comprised of:

Note: Ingress policed traffic uses the shared policer-output-queues to access the switch fabric. At egress, the policed traffic accesses the egress port through a queue group queue (by default the policer-output-queues queue group, though user configurable queue groups can also be used) or a locally configured subscriber queue. Egress policers can also be managed by HQoS.

The ingress hierarchical parenting relationship options are shown in Figure 86.

Figure 86:  Ingress Policing Hierarchy Options 

The egress hierarchical parenting relationship options are shown in Figure 87.

Figure 87:  Egress Policing Hierarchy Options 

The parent command is used to specify the name of the parent arbiter when parenting a policer or arbiter, together with the level and weight at which to connect.

9.3.13.3. ATM/Ethernet Last-Mile Aware QoS for Broadband Network Gateway

This feature allows the user to perform hierarchical scheduling of subscriber host packets in a way that the packet encapsulation overhead and ATM bandwidth expansion (when applicable) due to the last mile for each type of broadband session, that is, PPPoEoA LLC/SNAP and VC-Mux, IPoE, IPoEoA LLC/SNAP and VC-Mux, and so on, is accounted for by the 7450 ESS and 7750 SR acting as the Broadband Network Gateway (BNG).

The intent is that the BNG distributes bandwidth among the subscriber host sessions fairly by accounting for the encapsulation overhead and bandwidth expansion of the last mile so the packets are less likely to be dropped downstream in the DSLAM DSL port.

The last mile encapsulation type can be configured by the user or signaled using the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags or DHCP Relay Options as per RFC 4679.

Furthermore, this feature allows the BNG to shape the aggregate rate of each subscriber and the aggregate rate of all subscribers destined to a given DSLAM to prevent congestion of the DSLAM. The subscriber aggregate rate is adjusted for the last mile overhead. The shaping to the aggregate rate of all subscribers of a given destination DSLAM is achieved by a new scheduling object, referred to as Virtual Port or Vport in CLI, which represents the DSLAM aggregation node in the BNG scheduling hierarchy

9.3.13.3.1. Broadband Network Gateway Application

An application of this feature in a BNG is shown in Figure 88.

Figure 88:  BNG Application 

Residential and business subscribers use PPPoEoA, PPoA, IPoA, or IPoEoA based session over ATM/DSL lines. Each subscriber host can use a different type of session. Although Figure 88 illustrates ATM/DSL as the subscriber last mile, this feature supports both ATM and Ethernet in the last mile.

A subscriber SAP is auto-configured through DHCP or the RADIUS authentication process, or is statically configured, and uses a Q-in-Q SAP with the inner C-VLAN identifying the subscriber while the outer S-VLAN identifies the Broadband Service Access Node (BSAN) which services the subscriber, such as, the DSLAM. The SAP configuration is triggered by the first successfully validated subscriber host requesting a session. Within each subscriber SAP, there can be one or more hosts using any of the above session types. The subscriber SAP terminates on an IES or VPRN service on the BNG. It can also terminate on a VPLS instance.

When the 7750 BNG forwards IP packets from the IP-MPLS core network downstream towards the Residential Gateway (RG) or the Enterprise Gateway (EG), it adds the required PPP and Ethernet headers, including the SAP encapsulation with C-VLAN/S-VLAN. When the BSAN node receives the packet, it strips the S-VLAN tag, strips or overwrites the C-VLAN tag, and adds padding to minimum Ethernet size if required. It also adds the LLC/SNAP or VC-mux headers plus the fixed AAL5 trailer and variable AAL5 padding (to next multiple of 48 bytes) and then segments the resulting PDU into ATM cells when the last mile is ATM/DSL. Thus the packet size undergoes a fixed offset due to the encapsulation change and a variable expansion due to the AAL5 padding when applicable. Each type of subscriber host session requires a different amount of fixed offset and may require a per packet variable expansion depending of the encapsulation used by the session. The BNG node learns the encapsulation type of each subscriber host session by inspecting the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags as specified in RFC 4679. The BNG node must account for this overhead when shaping packets destined to subscriber.

9.3.13.3.2. Queue Determination and Scheduling

Figure 89 illustrates the queuing and scheduling model for a BNG using the Ethernet or ATM last-mile aware QoS feature.

Figure 89:  BNG Queuing and Scheduling Model 

A set of per FC queues are applied to each subscriber host context to enforce the packet rate within each FC in the host session as specified in the subscriber’s host SLA profile. A packet is stored in the queue corresponding the packet’s FC as per the mapping of forwarding class to queue-id defined in the sap-egress QoS policy used by the host SLA profile. In the BNG application however, the host per FC queue packet rate is overridden by the rate provided in the RADIUS access-accept message. This rate represents the ATM rate that is seen on the last mile, that is, it includes the encapsulation offset and the per packet expansion due to ATM segmentation into cells at the BSAN.

To enforce the aggregate rate of each destination BSAN, a scheduling node, referred to as virtual port, and Vport is in the CLI. The Vport operates exactly like a port scheduler with the difference that multiple Vport objects can be configured on the egress context of an Ethernet port. The user adds a Vport to an Ethernet port using the following command:

CLI Syntax:

config>port>ethernet>access>egress>vport vport-name create

The Vport is always configured at the port level even when a port is a member of a LAG. The vport-name is local to the port it is applied to but must be the same for all member ports of a LAG. It however does not need to be unique globally on a chassis.

CLI Syntax:

config>port>ethernet>access>egress>vport vport-name create

The user applies a port scheduler policy to a Vport using the following command:

CLI Syntax:

config>port>ethernet>access>egress>vport>port-scheduler-policy port-scheduler-policy-name

A Vport cannot be parented to the port scheduler when it is using a port scheduler policy itself. It is thus important the user ensures that the sum of the max-rate parameter value in the port scheduler policies of all Vport instances on a given egress Ethernet port does not oversubscribe the port’s hardware rate. If it does, the scheduling behavior degenerates to that of the H/W scheduler on that port. A Vport which uses an agg-rate can be parented to a port scheduler. This is explained in Applying Aggregate Rate Limit to a Vport. Note that the application of the agg-rate, port-scheduler-policy and scheduler-policy commands under a Vport configuration are mutually exclusive.

Each subscriber host queue is port parented to the Vport which corresponds to the destination BSAN using the existing port-parent command:

CLI Syntax:

config>qos>sap-egress>queue>port-parent [weight weight] [level level] [cir-weight cir-weight] [cir-level cir-level]

This command can parent the queue to either a port or to a Vport. These operations are mutually exclusive in CLI as explained above. When parenting to a Vport, the parent Vport for a subscriber host queue is not explicitly indicated in the above command. It is determined indirectly. The determination of the parent Vport for a given subscriber host queue is described in Vport Determination and Evaluation.

Furthermore, the weight (cir-weight) of a queue is normalized to the sum of the weights (cir-weights) of all active subscriber host queues port-parented at the same priority level of the Vport or the port scheduler policy. Since packets of ESM subscriber host queues are sprayed among the link of a LAG port based on the subscriber-id, it is required that all subscribers host queues mapping to the same Vport, such as having the same destination BSAN, be on the same LAG link so that the aggregate rate towards the BSAN is enforced. The only way of achieving this is to operate the LAG port in active/standby mode with a single active link and a single standby link.

The aggregate rate of each subscriber must also be enforced. The user achieves this by applying the existing agg-rate-limit command to the egress context of the subscriber profile:

CLI Syntax:

config>subscr-mgmt>sub-profile>egress>agg-rate-limit agg-rate

In the BNG application however, this rate is overridden by the rate provided in the RADIUS access-accept message. This rate represents the ATM rate that is seen on the last mile, that is, it includes the encapsulation offset and the per packet expansion due to ATM segmentation into cells at the BSAN.

9.3.13.3.3. Weighted Scheduler Group

The existing port scheduler policy defines a set of eight priority levels with no ability of grouping levels within a single priority. To allow for the application of a scheduling weight to groups of subscriber host queues competing at the same priority level of the port scheduler policy applied to the Vport, or to the Ethernet port, a new group object is defined under the port scheduler policy:

CLI Syntax:

config>qos>port-scheduler-policy>group group-name rate pir-rate [cir cir-rate]

Up to eight groups can be defined within each port scheduler policy. One or more levels can map to the same group. A group has a rate and optionally a cir-rate and inherits the highest scheduling priority of its member levels. For example, the scheduler group shown in the Vport consists of level priority 3 and level priority 4. It thus inherits priority 4 when competing for bandwidth with the standalone priority levels 8, 7, and 5.

In essence, a group receives bandwidth from the port or from the Vport and distributes it within the member levels of the group according to the weight of each level within the group. Each priority level competes for bandwidth within the group based on its weight under congestion situation. If there is no congestion, a priority level can achieve up to its rate (cir-rate) worth of bandwidth.

The mapping of a level to a group is performed as follows:

CLI Syntax:

config>qos>port-scheduler-policy>level priority-level rate pir-rate [cir cir-rate] group group-name [weight weight-in-group]

Note: CLI enforces that mapping of levels to a group are contiguous. In other words, a user would not be able to add priority level to group unless the resulting set of priority levels is contiguous.

When a level is not explicitly mapped to any group, it maps directly to the root of the port scheduler at its own priority like in existing behavior.

9.3.13.3.9. Signaling of Last Mile Encapsulation Type

A subscriber host session can signal one of many encapsulation types each with a different fixed offset in the last mile. These encapsulation types are described in RFC 4679 and are illustrated in Figure 90 and Figure 91. The BNG node learns the encapsulation type of each subscriber host session by inspecting the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoE Tags as specified in RFC 4679.When Ethernet is the last mile, the encapsulation type results in a fixed offset for all packet sizes. When ATM/DSL is the last mile, there is an additional expansion due to AAL5 padding to next multiple of 48 bytes and which varies depending on the packet size.

Both ATM and Ethernet access using PPP encapsulation options are supported in the software and hardware based implementations. Thus, both provide support for the Access-loop-encapsulation sub-TLV in the Vendor-Specific PPPoEv4/PPPoEv6 Tags with the ATM encapsulation values and Ethernet encapsulation values.

ATM and Ethernet access using IP encapsulation are only supported using default encapsulation offset configuration in the subscriber profile in the software based implementation. Support for signaling the Access-loop-encapsulation sub-TLV in the DHCPv4/DHCPv6 Relay Options is included in the hardware based implementation. There is no support for DHCPv6 relay options.

Figure 90:  Subscriber Host Session Encapsulation Types 

Figure 91:  Access-Loop-Encapsulation Sub-TLV 

The operational last-mile values for hosts on the same SAP, having the same SLA profile are displayed in following the show command:

CLI Syntax:

show>service active-subscribers>ale-adjust

The data-link can have values: atm, other and, unknown. If no offset is supplied it is set to unknown. other is used when the data-link is non-atm, otherwise it states atm.

Operational per-queue values can also be found in the show command:

CLI Syntax:

show>qos>scheduler-hierarchy

The following is an example of displaying whether the queue is operating in last-mile mode.

Last Mile ATM:

*A:Dut-C# /show service active-subscribers ale-adjust

===============================================================================

Active Subscriber Access Loop Encapsulation adjustment 

===============================================================================

Subscriber

   SAP                                         SLA profile

   Data-link Offset(bytes)

-------------------------------------------------------------------------------

hpolSub81

   1/1/11:2000.1                               hpolSlaProf1

   atm       -10

-------------------------------------------------------------------------------

No. of Access Loop Encapsulation adjustments: 1 

===============================================================================

 

*A:Dut-C# show qos scheduler-hierarchy subscriber "hpolSub81"

===============================================================================

Scheduler Hierarchy - Subscriber hpolSub81 

===============================================================================

Ingress Scheduler Policy:

Egress Scheduler Policy :

-------------------------------------------------------------------------------

Root (Ing)

|

No Active Members Found on slot 1

 

 

Root (Egr)

| slot(1)

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->8->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->7->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->6->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->5->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->4->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->3->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->2->ATM  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->1->ATM  (Port 1/1/11)

|

 

Last Mile Ethernet:

*A:Dut-C# show service active-subscribers ale-adjust

===============================================================================

Active Subscriber Access Loop Encapsulation adjustment 

===============================================================================

Subscriber

   SAP                                         SLA profile

   Data-link Offset(bytes)

-------------------------------------------------------------------------------

hpolSub81

   1/1/11:2000.1                               hpolSlaProf1

   other     +12

-------------------------------------------------------------------------------

No. of Access Loop Encapsulation adjustments: 1 

===============================================================================

 

*A:Dut-C# show qos scheduler-hierarchy subscriber "hpolSub81"

===============================================================================

Scheduler Hierarchy - Subscriber hpolSub81 

===============================================================================

Ingress Scheduler Policy:

Egress Scheduler Policy :

-------------------------------------------------------------------------------

Root (Ing)

|

No Active Members Found on slot 1

 

 

Root (Egr)

| slot(1)

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->8->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->7->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->6->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->5->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->4->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->3->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->2->Eth  (Port 1/1/11)

|

|--(Q) : Sub=hpolSub81:hpolSlaProf1 2000->1/1/11:2000.1->1->Eth  (Port 1/1/11)

|

Next Mile ATM:

*A:Dut-C# show service active-subscribers ale-adjust subscriber "hpolSub321"

===============================================================================

Active Subscriber Access Loop Encapsulation adjustment 

===============================================================================

Subscriber

   SAP                                         SLA profile

   Data-link Offset(bytes)

-------------------------------------------------------------------------------

hpolSub321

   5/1/1:100/1                                 hpolSlaProf1

   atm       +8

-------------------------------------------------------------------------------

No. of Access Loop Encapsulation adjustments: 1 

===============================================================================

 

*A:Dut-C# show qos scheduler-hierarchy subscriber "hpolSub321"

===============================================================================

Scheduler Hierarchy - Subscriber hpolSub321 

===============================================================================

Ingress Scheduler Policy:

Egress Scheduler Policy :

-------------------------------------------------------------------------------

Root (Ing)

|

No Active Members Found on slot 5

 

 

Root (Egr)

| slot(5)

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->8:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->7:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->6:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->5:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->4:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->3:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->2:ATM  (Port 5/1/1)

|

|--(Q) : Sub=hpolSub321:hpolSlaProf1 2000->5/1/1:100/1->1:ATM  (Port 5/1/1)

|

===============================================================================

9.3.14.1. IP (Layer 3) Volume Accounting

Subscriber volume statistics by default count Layer 2 frame sizes optionally modified by configuration such as packet-byte-offset, last mile aware shaping, and so on.

To report subscriber volume statistics as Layer 3 (IP) packet sizes, the volume-stats-type can be configured to ip in the subscriber profile:

volume-stats-type ip affects the subscriber statistics in SNMP, CLI, RADIUS accounting, XML accounting and Diameter Gx usage monitoring. Volume quota for RADIUS or Diameter Credit Control applications are interpreted as Layer 3 quota.

The following restrictions apply for volume-stats-type ip:

9.3.14.2. Separate IPv4 and IPv6 Counters

IPv4 and IPv6 forwarded and dropped subscriber traffic can be counted separately by a stat-mode v4-v6 command that is configured as a policer or queue qos override in the sla-profile. The stat-mode v4-v6 command is only applicable for Enhanced Subscriber Management (ESM).

For policers, the stat-mode command overrides the policer stat-mode configuration as defined in the sap-ingress or sap-egress qos policy. For details on sap-ingress and sap-egress policer stat-mode, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide. For a policer in stat-mode v4-v6, following counters are available:

When a policer’s stat-mode is changed while the SLA profile is in use, any previous counter values are lost and any new counters are set to zero.

For queues, a stat-mode is only available for use in Enhanced Subscriber Management (ESM) context to enable separate IPv4/IPv6 counters. For a queue in stat-mode v4-v6, following counters are available:

A queue’s stat-mode cannot be changed while the SLA profile is in use.

There are no in-profile or out-of-profile forwarded and dropped counters for policers and queues in stat-mode v4-v6.

Non-IP traffic (for example PPPoE LCP frames) is counted against the IPv4 counters.

The separate IPv4 and IPv6 forwarded and dropped counters are reported in

When a queue or policer is configured in stat-mode v4-v6, existing VSA’s are re-used in RADIUS detailed per queue or per policer accounting (configure subscriber-mgmt radius-accounting-policy <name> include-radius-attribute detailed-acct-attributes):

In addition the [26-6527-107] Alc-Acct-I-statmode / [26-6527-127] Alc-Acct-O-statmode is sent with value set to “v4-v6”.

Optionally a set of VSA's can be included in RADIUS accounting to report the aggregate IPv6 forwarded octets and packets of queues and policers with stat-mode v4-v6 enabled (configure subscriber-mgmt radius-accounting-policy <name> include-radius-attribute detailed-acct-attributes v6-aggregate-stats):

[26-6527-194] Alc-IPv6-Acct-Input-Packets

[26-6527-195] Alc-IPv6-Acct-Input-Octets

[26-6527-196] Alc-IPv6-Acct-Input-GigaWords

[26-6527-197] Alc-IPv6-Acct-Output-Packets

[26-6527-198] Alc-IPv6-Acct-Output-Octets

[26-6527-199] Alc-IPv6-Acct-Output-Gigawords

Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for a detailed description of all counter attributes.

The complete-subscriber-ingress-egress and custom-record-subscriber XML records use following fields to represent IPv4 and IPv6 forwarded/dropped octets and packets for queues or policers with stat-mode v4-v6 enabled:

v4po - IPv4PktsOffered (policer only)

v4oo - IPv4OctetsOffered (policer only)

v6po - IPv6PktsOffered (policer only)

v6oo - IPv6OctetsOffered (policer only)

v4pf - IPv4PktsForwarded

v6pf - IPv6PktsForwarded

v4pd - IPv4PktsDropped

v6pd - IPv4PktsDropped

v4of - IPv4OctetsForwarded

v6of - IPv6OctetsForwarded

v4od - IPv4OctetsDropped

v6od - IPv4OctetsDropped

For custom records, the following CLI is re-used to include v4/v6 counters if the queue is configured in stat-mode v4-v6:

i-counters

all-packets-offered-count # n/a

all-octets-offered-count # n/a

high-packets-offered-count # n/a

low-packets-offered-count # n/a

uncoloured-packets-offered-count # n/a

high-octets-offered-count # n/a

low-octets-offered-count # n/a

uncoloured-octets-offered-count # n/a

all-packets-offered-count # n/a

all-octets-offered-count # n/a

high-packets-discarded-count # IPv4

low-packets-discarded-count # IPv6

high-octets-discarded-count # IPv4

low-octets-discarded-count # IPv6

in-profile-packets-forwarded-count # IPv4

out-profile-packets-forwarded-count # IPv6

in-profile-octets-forwarded-count # IPv4

out-profile-octets-forwarded-count # IPv6

e-counters

in-profile-packets-forwarded-count # IPv4

in-profile-packets-discarded-count # IPv4

out-profile-packets-forwarded-count # IPv6

out-profile-packets-discarded-count # IPv6

in-profile-octets-forwarded-count # IPv4

in-profile-octets-discarded-count # IPv4

out-profile-octets-forwarded-count # IPv6

out-profile-octets-discarded-count # IPv6

9.3.15.1. Dynamic Updates of Subscriber Filter Policies

The IP or IPv6 filter policy configuration of subscriber hosts can be dynamically updated using the mechanisms described in the next sections.

Refer to the 7750 SR and VSR RADIUS Attributes Reference Guide for a detailed description of the RADIUS attributes format.

Refer to the 7750 SR and VSR Gx AVPs Reference Guide for a detailed description of the Diameter AVP’s format.

9.3.15.1.4. Insert Shared Filter Entries

The target application for shared filter entries is operators that have a predefined limited number of different filter lists that each are shared with multiple subscriber hosts or sessions and that are to be managed and activated from RADIUS or Diameter at authentication.

A local configured IP or IPv6 filter associated with a host or session (sla-profile or ip filter override) can be enhanced with dynamic filter entries that can be shared with multiple subscriber hosts or sessions. The shared dynamic filter entries are inserted with:

1. a set of RADIUS attributes ([26.529.242] Ascend-Data-Filter or [26.6527.158] Alc-Nas-Filter-Rule-Shared) received in a RADIUS Access-Accept or CoA message. A CoA message containing a set of one of those attributes overrides the previous set of shared filter entries active for that subscriber host or session.
2. a set of [6527-158] Alc-Nas-Filter-Rule-Shared AVP’s embedded in the [3GPP-1005] Charging-Rule-Name AVP received in a Diameter CCA or RAR message. The last received set of attributes overrides the previous set of shared filter entries for that subscriber host or session.

For each unique set of dynamic filter entries received per type (IPv4 or IPv6) and direction (ingress or egress), a copy is made of the local filter with the dynamic entries included at a preconfigured insert point. If the same set of dynamic filter entries is sent to subscriber hosts or sessions that have the same associated local filter, then they share the same filter copy. When there are no more subscriber hosts associated with a filter copy, then the filter copy is deleted. A filter copy is identified as local filter id:number. For example: show filter ip 10:2.

Shared filter entries are moved if the subscriber host filter policy is changed (new SLA profile or ip filter policy override) and if the new filter policy contains enough free reserved entries.

Figure 92:  Insert Shared Filters 

A range of entries must be reserved for shared entries in a filter policy:

config>filter>ip-filter

   sub-insert-shared-radius start-entry 100 count 10

 

High and low watermarks can be configured to raise an event when the thresholds of dynamic filter copies are reached:

*A:cses-V22>config>filter>ip-filter# shared-radius-filter-wmark ?

  - no shared-radius-filter-wmark

  - shared-radius-filter-wmark low <low-watermark> high <high-watermark>

 <low-watermark>      : [0..7999]

 <high-watermark>     : [1..8000]

The format used to specify shared filter entries ([26.6527.158] Alc-Nas-Filter-Rule-Shared format or [26.529.242] Ascend-Data-Filter format) cannot change during the lifetime of the subscriber host or session. A RADIUS message can only contain a single format for shared filter entries.

Shared filter entries can be removed with [26.6527.158] Alc-Nas-Filter-Rule-Shared attribute value equal to 0x00 or “ “ (a space).

9.3.15.2. Checking Filter Policy Details

Use following show commands to check filter policy details and the filter configuration for a subscriber host:

9.3.16.1. Overview

The synchronization process provides the means to manage distributed database (the Multi-Chassis Synchronization (MCS) database), which contains the dynamic state information created on any of the nodes by any application using its services. The individual entries in the MCS database are always paired by peering-relation, sync-tag and application-id. At any time the given entry is related to the single redundant-pair objects (two SAPs on two different nodes) and hence stored in a local MCS database of the respective nodes.

Internally, peering-relation and sync-tag are translated into a port and encapsulation value identifying the object (SAP) that the given entry is associated with. The application-id then identifies the application which created the entry on one of the nodes. There are three basic operations that the application can perform on MCS database. The MCS database always synchronizes these operations with its respective peer for the given entry.

The following principles apply:

The choice of the operation in corresponding situation is driven by the application. The following general guidelines are observed:

As previously stated, the MCS process automatically synchronizes any database operation with the corresponding peer. During this time, the MCS process maintains state per peer indicating to the applications (and network operator) the current status, such as in-sync, synchronizing or sync_down. These states are indicated by corresponding traps.

9.3.17.1. SRRP Messaging

SRRP uses the same messaging format as VRRP with slight modifications. The source IP address is derived from the system IP address assigned to the local router. The destination IP address and IP protocol are the same as VRRP (224.0.0.18 and 112, respectively).

The message type field is set to 1 (advertisement) and the protocol version is set to 8 to differentiate SRRP message processing from VRRP message processing.

The vr-id field has been expanded to support an SRRP instance ID of 32 bits.

Due to the large number of subnets backed up by SRRP, only one message every minute carries the gateway IP addresses associated with the SRRP instance. These gateway addresses are stored by the local SRRP instance and are compared with the gateway addresses associated with the local subscriber IP interface.

Unlike VRRP, only two nodes may participate in an SRRP instance due the explicit association between the SRRP instance group IP interface, the associated redundant IP interface and the multi-chassis synchronization (MCS) peering. Since only two nodes are participating, the VRRP skew timer is not utilized when waiting to enter the master state. Also, SRRP always preempts when the local priority is better than the current master and the backup SRRP instance always inherits the master’s advertisement interval from the SRRP advertisement messaging.

SRRP advertisement messages carry a becoming-master indicator flag. The becoming-master flag is set by a node that is attempting to usurp the master state from an existing SRRP master router. When receiving an SRRP advertisement message with a better priority and with the becoming-master flag set, the local master initiates the becoming-backup state, stops routing with the SRRP gateway MAC and sends an SRRP advertisement message with a priority set to zero. The new master continues to send SRRP advertisement messages with the becoming-master flag set until it either receives a return priority zero SRRP advertisement message from the previous master or its becoming-master state timer expires. The new backup node continues to send zero priority SRRP advertisement messages every time it receives an SRRP advertisement message with the becoming-master flag set. After the new master either receives the old master’s priority zero SRRP advertisement message or the become-master state timer expires, it enters the master state. The become-master state timer is set to 10 seconds upon entering the become-master state.

The SRRP advertisement message is always evaluated to see if it has higher priority than the SRRP advertisement that would be sent by the local node. If the advertised priority is equal to the current local priority, the source IP address of the received SRRP advertisement is used as a tie breaker. The node with the lowest IP address is considered to have the highest priority.

The SRRP instance maintains the source IP address of the current master. If an advertisement is received with the current master’s source IP address and the local priority is higher priority than the masters advertised priority, the local node immediately enters the becoming-master state unless the advertised priority is zero. If the advertised priority is zero, the local node bypasses the becoming-master state and immediately enters the master state. Priority zero is a special case and is sent when an SRRP instance is relinquishing the master state.

9.3.17.2. SRRP and Multi-Chassis Synchronization

To take full advantage of SRRP resiliency and diagnostic capabilities, the SRRP instance should be tied to a MCS peering that terminates on the redundant node. The SRRP instance is tied to the peering using the srrp srrp-id command within the appropriate MCS peering configuration. Once the peering is associated with the SRRP instance, MCS synchronizes the local information about the SRRP instance with the neighbor router. MCS automatically derives the MCS key for the SRRP instance based on the SRRP instance ID. For example, an SRRP instance ID of 1 would appear in the MCS peering database with a MCS-key srrp-0000000001.

The SRRP instance information stored and sent to the neighbor router consists of:

9.3.17.3. SRRP Instance

The SRRP instance uses the received information to verify provisioning and obtain operational status of the SRRP instance on the neighboring router.

9.3.17.4. Subscriber Subnet Owned IP Address Connectivity

In order for the network to reliably reach the owned IP addresses on a subscriber subnet, the owning node must advertise the IP addresses as /32 host routes into the core. This is important since the subscriber subnet is advertised into the core by multiple routers and the network follows the shortest path to the closest available router which may not own the IP address if the /32 is not advertised within the IGP.

9.3.17.5. Subscriber Subnet SRRP Gateway IP Address Connectivity

The SRRP gateway IP addresses on the subscriber subnets cannot be advertised as /32 host routes since they may be active (master) on multiple group IP interfaces on multiple SRRP routers. Without a /32 host route path, the network forwards any packet destined to an SRRP gateway IP address to the closest router advertising the subscriber subnet. While a case may be made that only a node that is currently forwarding for the gateway IP address in a master state should respond to ping or other diagnostic messages, the distribution of the subnet and the case of multiple masters make any resulting response or non-response inconclusive at best. To provide some ability to ping the SRRP gateway address from the network side reliably, any node receiving the ICMP ping request responds if the gateway IP address is defined on its subscriber subnet.

9.3.17.6. Receive SRRP Advertisement SAP and Anti-Spoof

The group IP interface SAPs are designed to support subscriber hosts and perform an ingress anti-spoof function that ensures that any IP packet received on the group IP interface is coming in the correct SAP with the correct MAC address. If the IP and MAC are not registered as valid subscriber hosts on the SAP, the packet is silently discarded. Since the SRRP advertisement source IP addresses are not subscriber hosts, an anti-spoof entry cannot exist and SRRP advertisement messages would normally be silently discarded. To avoid this issue, when a group IP interface SAP is configured to send and receive SRRP advertisement messages, anti-spoof processing on the SAP is disabled. This precludes subscriber host management on the SRRP messaging SAP.

9.3.18.1. SRRP Considerations for PPPoE

SRRP is based on VRRP whose purpose is to provide a default gateway redundancy for clients sharing the transport medium such as Ethernet. IPoE would be a typical example of this where IPoE clients use a virtual IP and MAC address that is shared between two default gateway nodes in the Master/Backup configuration. SRRP supports only two nodes in a cluster but VRRP allows multiple nodes to be configured in a cluster with a priority that determines which node assumes Mastership. Although it is mandatory for the proper operation of IPoE clients that the same SRRP IP address is shared between the two BNG nodes providing redundancy, having the same SRRP IP address is not necessary for the operation of SRRP itself. In other words, SRRP itself (Master or Backup states) works with different SRRP IP addresses on each node. Same is valid for MAC addressing. It is possible by configuration that the redundant BNG nodes use different IP/MAC addresses on a pair of SRRP instances.

Upon a switchover, a gratuitous ARP is sent from a newly selected active node so that each IPoE client can update the ARP table, if the MAC address has indeed changed (it does not have to). More importantly, if an Layer 2 aggregation network is in place between the BNG and the IPoE client, all intermediate Layer 2 devices must update their port-to-mac mappings (Layer 2 FDB). The above described process ensures proper packet addressing on the IPoE client side as well as the proper forwarding path through Layer 2 aggregation network to the newly activated BNG.

When considering PPPoE in conjunction with SRRP, keep in mind that PPP protocol (point-to-point protocol) is adopted for the Ethernet (shared medium) by enabling an extra Ethernet related layer in PPP that allows sharing of point-to-point sessions over Ethernet (shared medium). The result is a PPPoE protocol designed to ‘tunnel’ each PPP session over Ethernet.

PPPoE is not aware of ARP (Address Resolution Protocol) and it does not react to gratuitous ARP packets sent by a newly active BNG. The destination MAC address that PPPoE clients use when sending traffic is determined not by ARP but by the PPPoE Discovery phase at the beginning of the session establishment. This originally discovered destination MAC is used throughout the lifetime of the session. This has a couple of consequences:

9.3.18.2. State Synchronization

PPPoE sessions are synchronized between the redundant BNG nodes. The subscriber synchronization is achieved through Multi-Chassis Synchronization (MCS) protocol in a similar way it is performed for IPoE.

Two keywords, ipoe and pppoe enable a more granular control over which type of subscribers the MCS should be enabled.

Subscriber synchronization is important for following reasons:

9.3.18.2.1. PPPoE Multi-chassis Synchronization (MCS) Model

PPPoE MCS model is based on SRRP synchronization and can be used in a centralized or distributed environment with or without Layer 2 aggregation network in-between DSLAMs and BNG nodes. The failure detection speed is dependent on SRRP timers. Traffic load can be balanced per SRRP group over the two links. In this model (Figure 94), PPPoE states are synchronized between the redundant BNG nodes. If one BNG fails, the newly activated BNG sends out a ‘MAC update’ (gratuitous ARP) message prompting the intermediate Layer 2 nodes to update their forwarding tables so that forwarding can resume. The SRRP timers can be configured in the sub-second range. In reality, the limiting factor for timer values is the scale of the deployment, in particular the number of SRRP groups per node.

Figure 94:  Fully Redundant “Statefull 1:1” Model 

9.3.18.3. Traffic Control and Redundant Interface

To preserve QoS and Accounting, subscriber’s traffic must flow in both directions through the Master BNG node.

In the upstream direction, this is always true as traffic is steered to the master SRRP node just by the virtue of SRRP operation.

In the downstream direction which represents bulk of traffic, SRRP cannot be relied up on to steer traffic through the Master node. This poses a problem in a very common environment where IP subnets are shared over multiple group interfaces with SRRP enabled. A particular subnet is advertised to the network side from both BNG nodes, Master and Backup. Natural routing on the network side determines which BNG node receives subscriber’s traffic in the downstream direction. If the Backup SRRP node receives the traffic, it cannot simply send the traffic directly to the access network where the subscriber resides by just inserting the source MAC address of the SRRP instance in the outgoing packet. This would break the operation of SRRP. Instead, the Backup BNG node must send the traffic to the Master BNG node through a redundant-interface. The Master SRRP node would then forward traffic directly to the subscriber. Source MAC address of this traffic would then be the MAC address of SRRP instance. This traffic shunting over the redundant interface can result in a substantial load on the link between the two BNG nodes.

The increase in shunted traffic can quickly become an issue if the redundant BNG nodes that are not collocated. To minimize the shunt traffic, more granular routing information must be presented to the network core. This would lead to more optimal routing where downstream subscriber traffic would be directed towards the Master BNG node, without the need to cross the redundant interface. The downside of this approach is that this would further fragment the IP address space within the network core. In the extreme case where /32 (subscriber) IP addresses are advertised, the churn that /32s can cause in the core routing would most likely be unsustainable. In this case, routing updates in the core would be triggered by subscribers coming on/off-line.

Optimal operation would call for the shunt traffic to be eliminated and at the same time, a high IP route aggregation on the network side is achieved. The existence of the shunt traffic stems from the fact that routing protocols advertise subscriber subnets into the network with no awareness of the SRRP activity state (Master/Standby). To address this problem along with better aggregation of advertised subnets, two SRRP enhancements are introduced:

Both of these concepts are described in SRRP Enhancement.

Traffic destined to or from the subscriber is forwarded under the condition that the subscriber-interface is operationally UP. This applies also to shunting of downstream subscriber traffic from the STANDBY to MASTER node. It is always necessary to keep the subscriber-interface operationally UP by configuring a dummy group interface with a oper-up-while-empty command under it. This is especially true for the MC-LAG which causes the messaging SAP on the STANDBY node always to be in the INIT state. In case that MSAPs are used on such group interfaces, the group interfaces would be also operationally DOWN, causing the subscriber-interface to be operationally DOWN.

9.3.18.3.1. Subnet Assignment and Advertisement - Option ‘A’

A single IP subnet is used for all subscribers terminated within the redundant BNG nodes. The upside of the Option ‘A’ is that it offers aggregated IP addressing in the network core per pair of redundant BNG nodes. The downside is that the subscriber termination point (active BNG for the SRRP group) is hidden from the network core. Since both BNG nodes share the same IP subnet for the subscribers, the natural routing can cause downstream traffic to be sent to the standby BNG which must shunt the traffic to the active BNG. It is likely that half of the traffic is shunted over the redundant-interface with this approach. This scenario is shown in Figure 95.

Figure 95:  Shared Subscriber IP Space 

9.3.18.4. MSAP Considerations

As per RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE), this has the implications on the operation of the capture SAP. In an IPoE environment, the initial DHCP traffic related to host establishment uses its native MAC of the physical port on the router. Once the group interface is learned (later in the process, by RADIUS or msap-policy), the MAC address is switched to SRRP MAC address (virtual MAC). The IPoE client adapts easily to this change. On the contrary, for the proper operation of PPPoE with SRRP, the initial destination MAC address learned by the PPPoE client does not change during the lifetime of the session.

This is ensured by indirectly referencing the grp-if under the capture SAP:

With this approach the grp-if is nailed during the session initiation phase by referencing the SRRP instance in track-srrp statement (SRRP is a group interface-wide concept). RADIUS returned grp-if name must match the one on which referenced SRRP instance runs.

The capture SAP of the form

assumes that there is only one grp-if associated with all MSAPs under this capture SAP.

A check is put in place to make sure that the MAC addresses associated with the SRRP instance is the same as the MAC address of the associated capture SAP. A log is raised if there is a discrepancy between the MAC addresses while the grp-if is operationally UP. If there is a MAC address change (user misconfiguration) then the existing PPPoE sessions time out and the new sessions fail to establish until the condition is corrected.

9.3.18.5. Unnumbered Interface Support

For unnumbered subscriber-interface support in PPPoE, the gateway IP address that is used to send gratuitous ARP is not available. For this reason, the system IP address is used to send gratuitous ARPs. Gratuitous ARP is used to update the Layer 2 network forwarding path towards the BNG node in the upstream direction.

The system IP address is used automatically if the subscriber interface is unnumbered.

9.3.18.6. Compatibility with MC-LAG

SRRP for PPPoE works in an environment where MC-LAG is enabled. For example, the standby LAG link automatically puts the SRRP node in a Backup state and the SRRP becomes master on the active MC-LAG link. It is important that the SRRP on the standby leg of the MC-LAG is forced into a Backup state, or any new state that forces the downstream traffic to use the redundant interface.

Traffic destined to/from the subscriber is forwarded under the condition that the subscriber-interface is operationally UP. This applies also to shunting of downstream subscriber traffic from the STANDBY to MASTER node. It is always necessary to keep the subscriber-interface operationally UP by configuring a dummy group interface with a oper-up-while-empty command under it. This is especially true for the MC-LAG which causes the messaging SAP on the STANDBY node always to be in the INIT state. If MSAPs are used on such group interfaces, the group interfaces would be also operationally DOWN, causing the subscriber-interface to be operationally DOWN.

9.3.18.7. IPv6 Support

Prerequisite for MC IPv6 Redundancy is to synchronize PPPoEv6 and IPoEv6 subscribers between the nodes by MCS.

In PPPoE environment, SRRP is used to refresh the forwarding path (MAC addresses) in the access aggregation network (by gratuitous ARP). SRRP ensures that the upstream traffic is steered to the Master BNG node. In the downstream direction, the Backup BNG directs traffic over to the Master BNG node by a redundant-interface.

The IPv6 functionality currently relies on IPv4 based SRRP and IPv4 based redundant-interface. In other words, IPv4 is required to run on the access side as well as on the redundant-interface.

The redundant-interface is used in the downstream direction. Traffic arriving on the network links on the Standby node is shunted over to the Master node over the redundant-interface. This is required to ensure consistent QoS and accounting functionality across the nodes (upstream and downstream traffic on the access links for a subscriber must traverse the same BNG node). There is no IPv6 related CLI associated with the redundant-interface.

All IPv6 subscriber traffic that arrives on the Standby node in the downstream direction is automatically shunted over the IPv4 redundant-interface to the Master node. When IPv6 traffic arrives over the redundant-interface on the Master node, it is either PPPoEv6 encapsulated or left as plain IPoEv6 before it is forwarded to the subscriber.

In the upstream direction (AN->BNG) the behavior is the following:

Note that the current version of SRRP relies only on IPv4 routes. The connection between SRRP and IPv4 routes is done with the subnets with gw IP addresses defined under the subscriber-interfaces in the ESM context. This connection is needed so that SRRP can send Gratuitous ARP properly.

These are the cases for PPPoEv6 MC Redundancy that are supported:

numbered IPv6 only subscriber-interfaces (config>service>sub-if>ipv6 hierarchy) is not supported

9.3.18.8. Considerations with Local DHCP Server

When local DHCP Server redundancy/synchronization is used, using address-range failover local | remote, in conjunction with PPPoE in multi-chassis environment, both DHCP servers must be referenced under the corresponding group interface on each node. For address-range failover access-driven configurations only one DHCP server must be referenced.

Otherwise, the PPPoE clients are not synchronized by MCS.

This is not the requirement in the IPoE environment. In the IPoE environment, it is enough that the DHCP server points to the IP address of the local DHCP server. If the IP lease is originally assigned by the peer DHCP server, the request for renewal is automatically forwarded to the remote DHCP server by the virtue of the IP address of the original DHCP server that is included in the renewal request.

It is necessary for the successful renewal of the IP address on the remote DHCP server, that the remote DHCP server has a valid return path back to the gi-address of the forwarder of the renewal request.

9.3.18.9. Redundant Interface Considerations

In PPPoE dual-chassis environment without the redundant-interface in place, SRRP aware routing should always be used. Otherwise, if the downstream traffic arrives on the backup node, it is forwarded directly to the client over the access network (assuming that the access network is operational) with the source MAC address of the group interface (instead of gw-mac). This grp-if MAC address is different from the MAC address (gw-mac) negotiated during the initial PPPoE phase, and therefore, this traffic is dropped by the client. It must be ensured that the downstream traffic is always attracted to the Master node in the absence of redundant.

9.3.19.1. Layer 3 Subscriber Interfaces

On regular interfaces in an IES or VPRN service, only one SAP can be associated. A group interface allows multiple SAPs to be configured as part of a single interface. All SAPs in a single group interface must be within the same port. Since broadcast is not allowed in this mode, forwarding to the subscriber is based on IP/MAC addresses information gathered by the subscriber management module and stored in the subscriber management table. These entries are based on both static and dynamic DHCP hosts. Routed CO must be used with standard subscriber management or enhanced subscriber management. DSLAMs are typically deployed with Ethernet interfaces.

This model is a combination of two key technologies, subscriber interfaces and group interfaces. While the subscriber interface define the subscriber subnets, the group interfaces are responsible for aggregating the SAPs.

As depicted in Figure 97, an operator can create a new subscriber interface in the IES or VPRN service. A subscriber interface allows for the creation of multiple group interfaces. The IP space is defined by the subnets of the subscriber interface’s addresses. Figure 98 shows the details of group interface A.

Figure 97:  Subscriber Interface in an IES/VPRN Service 

Figure 98:  Details of a Group Interface 

Figure 99 shows a network diagram where the DSLAM are connected directly to a Broadband Service Router (BSR) providing access to an IP subnet. Subscribers from multiple DSLAMs can be part of the same subnet. Note that BSR is also referred to as Broadband Network Gateway (BNG).

Figure 99:  Aggregation Network with Direct DSLAM-BSR Connection  

The BSR can be configured with multiple subnets, allowing subscribers to be part of a single subnet as well as providing mechanisms for re-addressing or expanding existing services without affecting existing users.

Figure 100:  Detailed View of Configurable Objects Related to Layer 3 Subscriber Interfaces 

Figure 100 shows a detailed view of a router and the configuration objects implemented to support Layer 3 subscriber interfaces.

The individual features related to subscribers, such as DHCP relay, DHCP snooping and anti-spoofing filters, are enabled at group interface level. For a Routed CO model of subscriber management, and when enhanced subscriber management (if sub-sla-mgmt is configured). Then, hashing is based on an internally assigned subscriber-ID. Having a unique subscriber ID configured in CLI ensures that each subscriber is assigned a unique internal subscriber ID.

It is assumed that individual end-user devices (further referred to as subscriber hosts) get their IP address assigned through either DHCP or static configuration. The management of individual subscriber hosts (such as creation, queue allocation, and so on) is performed by Enhanced Subscriber Management.

The operator can provision how the system advertises routes. While most deployments advertise the full subnet it is possible to have the system advertise only the active, discovered or static host routes.

The distribution of this information into routing protocols is driven by import/export route policies configured by the operator.

9.3.19.2. Wholesale Retail Routed CO

VPRN Routed CO allows a provider to resell wholesaler services (from a carrier) while providing direct DSLAM connectivity. An operator can create a VPRN service for the retailer and configure the access from subscribers as well as to the retailer network. Any further action acts as if the VPRN is a standalone router running the Routed CO model. All forwarding to these servers must be done within the VPRN service. The operator can leak routes from the base routing instance. In this model, the operator can use RADIUS for subscriber host authentication, DHCP relay and DHCP proxy. This provides maximum flexibility to the retailer while minimizing the involvement of the wholesaler. Access cannot be shared among retailers unless a subscriber SAP is used. This requires that the wholesaler maintain a different access node (DSLAM) for each retailer that does not scale well. The wholesale retail model described in this section overcomes these limitations.

9.3.19.2.1. Wholesale Retail Model

In the wholesale retail model (Figure 101), the wholesaler instance connections that are common to the access nodes are distributed to many retail instances. A subscriber host attached to an access node connected in the wholesaler service can be instantiated in a retail service and obtain IP addresses from the retailers address space. The service context of the retailer is determined during the subscriber host authentication phase (for example, by the Alc-Retail-Serv-Id attribute in RADIUS or the retail-service-id CLI in the local user database).

Upstream subscriber traffic ingresses into the wholesaler instance and after identification is then forwarded into the retail instance. The reverse occurs for traffic in the downstream direction.

Figure 101:  Wholesale Retail Model 

In a wholesale retail model, two subscriber interfaces must be configured and linked together: one in the wholesale VPRN and one in the retail service.

The wholesale subscriber interface defines the IP subnets and host specific configuration parameters for subscriber hosts belonging to the wholesaler. There are associated group interfaces that contain the SAPs which connect to the access nodes.

The retail subscriber interface defines the IP subnets and host specific configuration parameters for subscriber hosts belonging to the retailer. The retail subscriber interface is linked to a wholesale subscriber interface for forwarding by explicit configuration. There are no associated group interfaces.

For example:

config>service

        vprn 1000 customer 1 create

            subscriber-interface "sub-int-ws-1" create

            # wholesale subscriber interface

                --- snip ---

                group-interface "group-int-1-1" create

                    --- snip ---

                    sap 1/1/1:1 create

                        --- snip ---

                    exit

                exit

            exit

        exit

 

 

       vprn 1001 customer 1 create

            subscriber-interface "sub-int-rt-1" fwd-service 1000    \\

                            fwd-subscriber-interface "sub-int-ws-1" create

            # linked retail subscriber interface

                --- snip ---

            exit

        exit

 

A retail subscriber interface can be linked to a single wholesale subscriber interface and context only. Subscriber interface chaining (linking a retail subscriber interface to another retail subscriber interface) is not supported. Multiple retail subscriber interfaces belonging to different retail contexts can be associated with a single wholesale subscriber interface. When a retail subscriber interface is linked to a wholesale context, all other retail subscriber interfaces from the same retailer must be linked to the same wholesale context.

9.3.19.2.3. Hub-and-Spoke Forwarding

In some cases, hub-and-spoke-type forwarding is needed for the retailer’s VPRN. When the retailer expects all subscriber traffic to reach its router (for accounting, monitoring, wiretapping, and so on) normal best-hop behavior within the retailer VPRN is not desired. Any subscriber-to-subscriber traffic is forwarded within the VPRN preventing the retailer from receiving these packets. To force all subscriber packets to the retailer network, a new type of hub-and-spoke topology is defined: type subscriber-split-horizon. It can be used to force all subscriber traffic (upstream) to the retailer’s network. The system requires that the operator shut down the VPRN service to enable this flag.

With retail VPRN type configured to subscriber-split-horizon, routes learned from MBGP, IGP through a regular interface, static routes through regular interfaces and locally attached regular interface routes are considered hub routes and are used for upstream traffic forwarding. Subscriber subnets cannot be used for upstream traffic forwarding. Downstream traffic uses routes in both hub and spoke routing instances.

Figure 102 shows user-to-user traffic forwarding for both retail VPRN types: regular and subscriber-split-horizon.

Figure 102:  Wholesale Retail – Hub-and-Spoke Forwarding 

Hub-and-spoke forwarding can also be used in combination with wholesale unicast RPF (uRPF) check. The uRPF is performed on upstream traffic on spoke routes (subscriber subnets) and the forwarding uses hub routes only.

9.3.19.3. Routed Subscriber Hosts

A routed subscriber host associated route, as shown in Figure 103, is a global routable subnet/prefix behind a routed CPE or Home Gateway. The routed CPE is identified in the BNG as an ESM subscriber host: QoS, accounting and anti-spoofing is enforced per CPE. The associated routes are installed in the BNG route table with next-hop pointing to the routed subscriber host’s WAN address.

Figure 103:  Router Subscriber Hosts 

Routed subscriber host associated routes are supported on IES/VPRN subscriber interfaces in a routed CO configuration. To put a SAP or MSAP in routed subscriber mode, the anti-spoof type for the SAP or MSAP must be configured to nh-mac:

There are three ways to learn about a routed subscriber host associated IPv4 route:

A routed subscriber host associated IPv6 route can only be learned with the RADIUS [99] Framed-IPv6-Route attribute.

9.3.19.4. Subscriber Prefix Leaking

This section describes VPRN leaking and GRT lookup and routed CO in a VPRN.

9.3.20.1. Dual Homing to Two PEs (Redundant-Pair Nodes) in Triple Play Aggregation

Figure 104:  Dual-Homing to Two PEs 

Figure 104 depicts dual-homing to two different PE nodes. The actual architecture can be based on a single DSLAM having two connections to two different PEs (using MC-LAG) or ring of DSLAMs dual-connected to redundant pair of PEs.

Similarly to previous configuration, both aggregation models (VLAN-per-subscriber or VLAN-per-service) are applicable.

Configurations include:

Figure 105 shows a typical configuration of network model based on Layer 2 CO model. Individual rings of access nodes are aggregated at BSA level in one (or multiple) VPLS services. At higher aggregation levels (the BSR), individual BSAs are connected to Layer 3 interfaces (IES or VPRN) by spoke SDP termination. Every Layer 3 interface at BSR level aggregates all subscribers in one subnet.

Figure 105:  Layer 2 CO Dual Homing - Network Diagram  

Typically, BTV service distribution is implemented in a separate VPLS service with a separate SAP per access-node. This extra VPLS is not explicitly indicated in Figure 105 (and subsequent figures) but the descriptions refer to its presence.

From a configuration point of view in this model, it is assumed that all subscriber management features are enabled at the BSA level and that synchronization of the information (using multi-chassis synchronization) is configured between redundant pair nodes (BSA-1 and BSA-2 shown in Layer 2 CO Dual Homing - Network Diagram). The multi-chassis synchronization connection is used only for synchronizing active subscriber host database and operates independently from dual-homing connectivity control. At the BSR level, there are no subscriber management features enabled.

The operation of redundancy at the BSR level through VRRP is the same as dual homing based on MC-LAG. The operation of dual homing at BSA level is based on two mechanisms. Ring control connection between two BSAs have two components, in-band and out-of-band communication. With in-band communication, BFD session between BSA-1 and BSA-2 running through the access ring and using dedicated IES/VPRN interface configured on both nodes. This connection uses a separate VLAN throughout the ring. The access nodes provides transparent bridging for this VLAN. The BFD session is used to continuously verify the integrity of the ring and to detect a failure somewhere in the ring.

With out-of-band communication, the communication channel is used by BSA nodes to exchange information about the reachability of individual access nodes as well as basic configurations to verify the consistency of the ring. The configuration information is synchronized through multi-chassis synchronization and therefore it is mandatory to enable multi-chassis synchronization between two nodes using the multi-chassis-ring concept.

In addition, the communication channel used by MC-LAG or MC-APS control protocol is used to exchange some event information. The use of this channel is transparent to the user.

Ring node connectivity check continuously checks the reachability of individual access nodes in the ring. The session carrying the connection is conducted on separate VLAN, typically common for all access nodes. SHCV causes no interoperability problems.

9.3.20.2. Steady-State Operation of Dual-homed Ring

Figure 106 illustrates the operation of the dual-homed ring. The steady state is achieved when both nodes are configured in a consistent way and the peering relation is up. The multi-chassis ring must be provisioned consistently between two nodes.

In-Band Ring Control Connection (IB-RCC) is in operational UP state. Note that this connection is set up using a bi-directional forwarding session between IP interfaces on BSA-1 and BSA-2.

Figure 106:  Dual Homing Ring Under Steady-State Condition 

In Figure 106, the ring is fully closed and every access node has two possible paths towards the VPLS core. Figure 106 refers to these as path-a and path-b. To avoid the loop created by the ring, only one of the paths can be used by any given ring node for any given VLAN. The assignment of the individual VLANs to path-a or path-b, respectively, has to be provisioned on both BSAs.

The selection of the BSA master for both paths is based on the IP address of the interface used for IB-RCC communication (bi-directional forwarding session). The BSA with the lower IP address of the interface used as IB-RCC channel becomes master for ring nodes and their respective VLANs assigned to path-a. The master of path-b is the other BSA.

In this example, each path in the ring has a master and standby BSA. The functionality of both devices in steady state are as follows:

In the master BSA:

In the standby BSA:

All SAPs that belong to a BSA’s path, the standby is operationally down and all FDB entries of subscriber hosts associated with those SAPs point towards the SDP connecting to the master BSA (also called a shunt SDP).

In both BSAs:

9.3.20.3. Broken-Ring Operation and the Transition to this State

Figure 107 illustrates the model with a broken ring (link failure or ring node failure). This state is reached in following conditions:

In this scenario, every ring node has only one access path towards the VPLS core and hence, the Path-a and Path-b notion has no meaning in this situation.

Functionally, both BSAs are now the master for the reachable ring nodes and act as described in Steady-State Operation of Dual-homed Ring. For all hosts behind the unreachable ring nodes, the corresponding subscriber host FDB entries point to the shunt SDP.

Figure 107:  Broken Ring State 

The mapping of individual subscriber hosts into the individual ring nodes is complicated, especially in the VLAN-per-service model where a single SAP can represent all nodes on the ring. In this case, a given BSA can have subscriber hosts associated with the given SAP that are behind reachable ring nodes as well as subscriber hosts behind un-reachable ring nodes. This means that the given SAP cannot be placed in an operationally down state (as in a closed ring state), but rather, selectively re-direct unreachable subscriber states to the shunt SDP.

All SAPs remain in an operationally up state if the ring remains broken. This mainly applies for BTV SAPs that do not have any subscriber hosts associated with and do not belong to any particular ring node.

To make the mapping of the subscriber-hosts on the given ring node automatically provisioned, the ring node identity is extracted during subscriber authentication process from RADIUS or from a Python script. The subscriber hosts which are mapped to non-existing ring node remain attached to the SAP.

At the time both BSA detect the break in IB-RCC communication (if BFD session goes down) following actions are taken:

9.3.20.4. Transition from Broken to Closed Ring State

By its definition, the multi-chassis ring operates in a revertive mode. This means that whenever the ring connectivity is restored, the BSA with lower IP address in the IB-RCC communication channel become masters of the path-a and vice versa for path-b.

After restoration of BFD session, the master functionality, as described in Steady-State Operation of Dual-homed Ring, is assumed by respective BSAs. The FDB tables are updated according to the master/standby role of the given BSA and FDB population messages is sent accordingly.

9.3.20.5. Provisioning Aspects and Error Cases

The multi-chassis ring can operate only if both nodes similarly configured. The peering relation must be configured and both nodes must be reachable at IP level. The multi-chassis ring with a corresponding sync-tag as a ring-name identifying a local port ID must be provision on both nodes. And, BFD session and corresponding interfaces needs to be configured in a consistent way.

In case the multi-chassis rings are not provisioned consistently, the ring does not become operational and the SAP managed by it is in an operationally up state on both nodes.

The assignment of individual SAPs to path-a and path-b is controlled by configuration of VLAN ranges according to the following rules:

9.3.20.6. Dual Homing to Two BSR Nodes

Figure 108 depicts a single DSLAM dual-homed to two BSRs.

Figure 108:  Low  

To provide dual-homing in the context of subscriber interfaces, the following items must be configured on both BSRs:

During the operation, BSR-1 and BSR-2 resolves master-backup relations and populates respective FDBs in such a way that at master side, subscriber-host entries point to corresponding group interface while at the back-up side, subscriber-host entries point to the redundant interface. Note that the logical operation of the ring in the Layer 3 CO model is driven by SRRP. For more details on SRRP operation, see the Subscriber Routed Redundancy Protocol (SRRP) chapter.

9.3.20.7. MC Services

The typical implementation of MC services at the network level is shown in Figure 109.

Figure 109:  MC Services in a Layer 3-Ring Topology (a) 

The IGMP is used to register joins and leaves of the user. IGMP messaging between BSRs is used to determine which router performs the querier role (BSR2 in Figure 109). PIM is used to determine which router is the designated router and the router that sends MC streams on the ring.

The access nodes have IGMP snooping enabled and from IGMP messaging between BSR, they are aware which router is the querier. In the most generic case, IGMP snooping agents (in access nodes) send the IGMP-joins messages only to IGMP-querier. The synchronization of the IGMP entries can be then be performed through MCS. In some cases, access nodes can be configured in such a way that both ring ports are considered as m-router ports and IGMP joins are sent in both directions.

All of the above is a steady state operation which is transparent to the topology used in a Layer 2 domain.

A ring-broken state is shown in Figure 110.

In this case, IGMP and PIM messaging between BSRs is broken and both router assume role of querier and role of designated router. By the virtue of ring topology, both routers see only IGMP joins and leaves generated by host attached to a particular “half” of the ring. This means that both routers have “different” views on the dynamic IGMP state.

Figure 110:  MC Services on a Layer 3-Ring Topology (b) 

In principle, MCS could be used to synchronize both routers, but in case of a Layer 2 ring, the implementation sends all IGMP messages to a “ring-master: which then performs IGMP processing and consequently, MCS sync. As a result, any race conditions are avoided.

Another ring-specific aspect is related to ring healing. The ring continuity check is driven by BFD which then drives SRRP and PIM messaging. BFD is optimized for fast detection of ring-down events while ring-up events are announced more slowly. There is a time window when routers are not aware that the ring is recovered. In the case of MC, this means traffic is duplicated on the ring.

To avoid this, the implementation of BFD provides a “raw mode” which provides visibility on “ring-up” events. The protocols, such as SRRP and PIM, use this raw mode rather than the BFD API.

9.3.20.8. Routed CO Dual Homing

Routed CO dual homing is a solution that allows seamless failover between nodes for all models of routed CO. In the dual homed environment, only one node forwards downstream traffic to a given subscriber at a time. Dual homing involves several components:

Routed CO dual homing can be configured for both wholesaling models. Dual homing is configured by creating a redundant interface that is associated with the protected group interfaces. The failure detection mechanism can be SRRP. If SRRP is used, each node monitors the SRRP state to determine the priority of its own interface.

Dual homing is used to aggregate a large number of subscribers to support a redundancy mechanism that allows a seamless failover between nodes. Because of the Layer 3 nature of the model, forwarding is performed for the full subscriber subnet.

9.3.20.8.2. SRRP in Dual Homing

Subscriber Router Redundancy Protocol (SRRP) allows two separate connections to a DSLAM to operate in an active/standby fashion similar to how VRRP interfaces operate. Since the SRRP state is associated with the group interface, multiple group interfaces may be created for a given port so some of the SAPs are active in one node and others active on the other node. While each SRRP pair is still allowed to be active/backup, the described configuration is allowed for load balancing between the nodes. In a failure scenario, subscriber bandwidth is affected. For more information about SRRP, see the Subscriber Routed Redundancy Protocol (SRRP) chapter.

If SRRP is configured before the redundant interface is up, and in backup state the router forwards packets to the access node using the backup interface but does not use the gateway MAC address. This applies to failures in the redundant interface as well. If the redundant interface exists and up the router sends downstream packets to the redundant interface and not use the backup group interface.

In a dual homing architecture the nodes must be configured with SRRP to support redundant paths to the access node. The nodes must also be configured to synchronize subscriber data and IGMP state. To facilitate data forwarding between the nodes in case some of the ports in a given subscriber subnet are affected a redundant interface must be created and configured with a spoke. The redundant interface is associated with one or more group interfaces.

The service IDs for both the wholesale VPRN and the retailer VPRN must be the same in both nodes.

An interface in a backup state uses the redundant interface to send traffic to the active interface (in the active node). The SAP structure under the group interface must be the same on both nodes as the synchronization of subscriber information is enabled on a group interface basis.

SRRP is associated a group interface. Multiple group interfaces can be created for a specific port so that some of the SAPs are active in one node and others active on the other node. While every SRRP pair is still allowed to be active or backup the described configuration allows for load balancing between the nodes. In a failure scenario, subscriber bandwidth is affected.

Figure 111:  Dual Homing Example 

9.3.20.9. SRRP and Multi-Chassis Synchronization

To take full advantage of SRRP resiliency and diagnostic capabilities, the SRRP instance is tied to a MCS peering that terminates on the redundant node. Once the peering is associated with the SRRP instance, MCS synchronizes the local information about the SRRP instance with the neighbor router. MCS automatically derives the MCS key for the SRRP instance based on the SRRP instance ID. An SRRP instance ID of 1 would appear in the MCS peering database with a MCS-key srrp-0000000001.

The SRRP instance information stored and sent to the neighbor router contains the following:

9.3.20.10. Dual Homing and ANCP

The routers provide a feature related to exchange of control information between DSLAM and BRAS (BSA is described in this model). This exchange of information is implemented by in-band control connection between DSLAM and BSA, also referred to as ANCP connection.

In case of dual homing, two separate connections are set. As a consequence, there is no need to provide synchronization of ANCP state. Instead every node of the redundant-pair obtains this information from the DSLAM and creates corresponding an ANCP state independently.

9.3.21.1. SRRP Fate Sharing

SRRP Fate Sharing is a concept in which a group of SRRP instances track a single operational-object comprised of SRRP messaging SAPs. The SRRP instances behave as one (in the single failure case) with regards to SRRP mastership. The group of SRRP instances that are sharing fate on a paired node are referred as a Fate Sharing Group (FSG).

Transition of a single messaging SAP within the FSG into a DOWN state forces the SRRP instance on top of it into the INIT state. Consequently, all other SRRP instances within the same FSG transitions into a Backup state. In other words, SRRP instances within the FSG all share the same fate as the failed SRRP instance as shown in Figure 113. SRRP Fate Sharing provides optimal protection in the context of a single failure in the network.

Figure 113:  FSG -— Single Network Failure 

In the event of multiple network failures, the concept of the FSG breaks as there is a possibility that a ‘FSG’ contains SRRP instances that are in any of the three possible SRRP states: Master, Backup, or Init. This Fate Sharing feature may not provide optimal protection when there are multiple network failures distributed over both redundant nodes.

Figure 114:  Multiple Network Failures 

The whereabouts of the failure in the network path that SRRP is designed to monitor are not always clearly reflected through SRRP states. For example, if the network failure is somewhere in the aggregation network beyond the direct reach of our BNG, SRRP assumes Mastership on both BNG nodes. This is a faulty condition and the reason why solely monitoring of the SRRP states is not enough to protect against failures. On the other hand, the SRRP messaging SAP states are more indicative of the network failure since they can be tied into Eth-OAM.

Once a single network failure is detected and as a result an SRRP instance transitions into a non-Master state, the remaining SRRP instances in the FSG are forced into a Backup state. This is achieved by changing the priority of each individual SRRP instance in the FSG.

When there are simultaneous multiple failures (multiple ports fail at the same time), it is possible that the SRRP instances within the FSG settle in any of the three possible SRRP states: Master, Backup, or Init. In such scenario, shunted traffic ensues.

In the premise of SRRP Fate Sharing, the network failure is reflected in the operational state of the messaging SAP over which SRRP runs. This is the case if the failure is localized to the BNG (somewhere on the directly connected link). In the case of non-localized failure (beyond the direct reach of the BNG node), Eth-OAM might be needed in to detect the remote end failure and consequently bring the SAP operationally into a DOWN state.

Once the single network failure is detected, all instance within the FSG transitions into a non-Master state.

If there are no failures in the network, all SAPs are UP and SRRP instances within the FSG are in a homogeneous and deterministic state based on their configured priorities.

Figure 115:  SRRP Fate Sharing 

Failure Detection in a Fate Sharing Group

9.3.21.2. Fate Sharing Algorithm

Fate Sharing Group (FSG) is relaying on tracking the state of messaging SAPs over which SRRP instances run. An SRRP instance with the messaging SAP operationally DOWN transitions into the Init state.

The transitioning of any messaging SAP in a FSG into an UP/DOWN state triggers SRRP priority adjustment within the FSG. The SRRP priorities should be chosen carefully to achieve the desired behavior. They are modified dynamically as the SAP states change. The range in which SRRP priorities can be modified is from 1 to the SRRP priority that is initially configured under the SRRP node. Here are some general guidelines for choosing SRRP priorities in a FSG:

The priorities can never be less than 1 or greater than initially configured SRRP priority.

Example scenarios:

Assume 3 SRRP instances in a FSG. The SRRP instances in the FSG-1 on BNG 1 have the priority of 100, while the SRRP instances in the FSG-2 on BNG 2 have the priority of 95. The priority-step is 6. The SRRP instances and underlying messaging SAPs are referred to as SRRP 1, 2, 3 and SAP 1,2,3, respectively.

Initialization:

Scenario 1 – all SAPs are operationally UP.

BNG 1 boots up and all messaging SAPs transition into the UP state. When the first SRRP instance in FSG-1 comes up, it looks under the FSG to finds out how many messaging SAPs are operationally UP. Since all messaging SAPs are operationally UP, this first SRRP instance assumes its initially configured priority of 100. The other two SRRP instances in the same FSG follows the same sequence of events.

BNG 2 follows the same flow of events. As a result, BNG 1 assumes mastership over BNG 1 for all SRRP instances within the corresponding FSG.

Scenario 2 – messaging SAP 1 is operationally DOWN on BNG 1, the rest of the messaging SAPs are operationally UP.

SRRP 2 and 3, during the initialization, pick up SRRP priority of 94 (100 – 1*priority-step).

On BNG 2, all messaging SAPs are UP and consequently all SRRP instances within the FSG on BNG 2 have SRRP priority of 95. The SRRP instances on BNG 2 assumes Mastership.

Scenario 3 – Continuing from scenario 2, the SAP 1 on BNG 1 transitions into the UP state. SRRP priority of each SRRP instance in FSG-1 is increased by 6, bringing it to 100, enough to assume Mastership.

Adding a New Instance into an FSG

To introduce minimal network disruption, first create messaging SAPs in both BNG nodes and ensure that both SAPs are operationally UP. Then a new SRRP 4 instance should be created on both BNG nodes. The next step would be to include this new messaging SAP into a SAP monitoring group. And finally, the SRRP-4 is added into the FSG (1 and 2). This triggers the recalculation of SRRP priorities for the existing FSG-1 and FSG-2. Since all SRRP priorities are at the max (initially configured priority), nothing changes.

There are more disruptive ways of adding an SRRP instance into a FSG. One such example would be in the case where SRRP priorities are not at their maximum (initially configured) priority. If an SRRP instance is first added into an FSG that is in a Backup state, this would increase the FSG priority and potentially cause a switchover. If the SRRP instances is then added in a FSG on the peer BNG (previously Master), the priority of this FSG would be increased again and the switchover would unnecessarily occur for the second time. The new SRRP instances, once operational, should always be added in the Master FSG first.

SRRP priority re-calculation within the FSG is triggered by the following events:

This priority calculation looks into how many SAPs are in the DOWN state within the monitored SAP group. Based on this number, the priority is calculated as follows:

SRRP priority = configured-priority – priority-step * num_down_SAPs.

9.3.21.3. SRRP Aware Routing - IPv4/IPv6 Route Advertisement Based on SRRP State

There are three cases that need to be covered, each case with its own specifics:

Depending on the route type, the action is to either modify the route metric based on the SRRP state that the route is tracking, or to advertise/withdraw the route based on the SRRP state that the route is tracking. The action is defined in the routing policy and it is based on the new attributes with which the routes are associated.

To achieve a better granularity of the routes that are advertised, an origin attribute is added to the subscriber management routes (/32 IPv4 routes and IPv6 PD wan-host) with three possible values:

aaa

IPv4

subscriber-management /32 host routes that are originated through RADIUS framed-ip-address VSA other than 255.255.255.254. The 255.255.255.254 returned by the RADIUS indicates that the BNG (NAS) should assign an IP address from its own pool.

IPv6

subscriber-management routes that are originated through framed-ipv6-prefix (SLAAC), delegated-ipv6-prefix (IA_PD) or alc-ipv6-address (IA_NA) RADIUS attributes. This is valid for IPoE and PPPoE type host.

dynamic

IPv4

subscriber-management /32 host routes that are originated through the DHCP server (local or remote) and also RADIUS framed-ip-address=255.255.255.254 (RFC 2865).

IPv6

subscriber-management routes that are assigned through the local DHCPv6 server pools whose name is obtained through Alc-Delegated-IPv6-Pool (PD pool) and Framed-IPv6-Pool (NA pool) RADIUS attributes. This is valid for IPoE and PPPoE type hosts.

In addition, for IPoEv6 only, the pool name can be also obtained through the ipv6-delegated-prefix-pool (PD pool) and ipv6-wan-address-pool (NA pool) from LUDB.

static

IPv4

subscriber-management /32 host routes that are originated through LUDB. This also covers RADIUS fallback category (RADIUS falls back to system-defaults or to LUDB).

IPv6

subscriber-management routes obtained from LUDB through the ipv6-address (IA_NA) or ipv6-prefix (IA_PD). This is supported only for IPoE.

Overall, the following new route attribute is added:

state: srrp-master, srrp-non-master

The existing origin attribute is expanded to contain the following values:

origin: aaa, dynamic, static

These two attribute types are applied in the following fashion:

The state attribute is applied to all three route types: subscriber interface routes, managed routes and subscriber management routes. Each route listens to the SRRP state.

If an attribute is defined in the routing policy as a match condition (from statement) but the route itself does not have this attribute, the route is evaluated into a non-match condition.

The origin attribute is always applied only to subscriber management routes. No additional statement is needed to explicitly apply this attribute as it may be the case for the state attribute.

Every time there is a change in the attribute associated with the route, the route is re-evaluated in the RTM by the routing policy and corresponding action is taken.