Triple Play Enhanced Subscriber Management

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:

• A RADIUS server policy operational state can be controlled by reception of accounting on or off responses.

• Buffering of accounting messages: When all servers in a radius-server-policy are unreachable, it is possible to buffer the acct-stop and acct-interim-update messages for up to 25 hours. When a RADIUS server becomes reachable again then the messages in the buffer are retransmitted.

• A configurable hold down time for accounting servers that are marked down and during which no new communication attempts are made (hold-down-time).

• A configurable maximum number of outstanding RADIUS requests for accounting servers (pending-requests-limit).

• Increased retry and timeout values for unsuccessful RADIUS communication.

• Enhanced RADIUS server statistics

• IPv6 RADIUS server

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 because intermediate replies were received.

To attach a RADIUS server policy to an authentication policy:

For example,

configure
    subscriber-mgmt
        authentication-policy "auth-policy-1" create
            radius-server-policy "aaa-server-policy-1‟
        exit
    exit

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

For example:

configure
    subscriber-mgmt
        radius-accounting-policy "acct-policy-1" create
            radius-server-policy "aaa-server-policy-1‟
        exit
    exit

To configure the RADIUS servers in a RADIUS server policy:

For example:

configure
    aaa
        radius-server-policy "aaa-server-policy-1" create
            description "Radius AAA server policy"
            accept-script-policy "script-policy-2"
            acct-on-off oper-state-change
            acct-request-script-policy "script-policy-3"
            auth-request-script-policy "script-policy-1"
            no python-policy
            servers
                access-algorithm direct
                hold-down-time sec 30
                no ipv6-source-address
                retry 3
                router "Base"
                no source-address
                timeout sec 5
                buffering
                    acct-interim min 60 max 3600 lifetime 5
                    acct-stop min 60 max 3600 lifetime 5
                exit
                server 1 name "server-1"
                server 2 name ‟server-2”
            exit
        exit
    exit

To configure the RADIUS servers in the routing instance:

• In the Base routing instance: config>router>radius-server.

• In a VPRN routing instance: config>service>vprn 10>radius-server.

• In the management routing instance (out of band): config>router management>radius-server.

For example:

configure
    router
        radius-server
            server "server-1" address 172.16.1.1 secret <shared secret> hash2 create
                accept-coa
                coa-script-policy "script-policy-4"
                description "Radius server 1"
                pending-requests-limit 4096
                acct-port 1813
                auth-port 1812
            exit
            server "server-2" address 172.16.1.2 secret <shared secret> hash2 create
                accept-coa
                coa-script-policy "script-policy-4"
                description "Radius server 2"
                pending-requests-limit 4096
                acct-port 1813
                auth-port 1812
            exit
        exit
    exit

To configure a RADIUS server in an authentication policy:

configure
    subscriber-mgmt
        authentication-policy "auth-policy-1" create
            radius-authentication-server
                access-algorithm direct
                hold-down-time 30
                retry 3
                no source-address
                timeout 5
                router "Base"
                server 1 address 172.16.1.1 secret <shared secret> hash2 port 1812 
                    pending-requests-limit 4096
                server 2 address 172.16.1.2 secret <shared secret> hash2 port 1812 
                    pending-requests-limit 4096
            exit
            accept-authorization-change
            accept-script-policy "script-policy-2"
            coa-script-policy "script-policy-4"
            request-script-policy "script-policy-1"
        exit
    exit

To configure a RADIUS server in a RADIUS accounting policy:

configure
    subscriber-mgmt
        radius-accounting-policy "acct-policy-1" create
            radius-accounting-server
                access-algorithm direct
                retry 3              
                timeout 5
                no source-address
                router "Base"
                server 1 address 172.16.1.1 secret <shared secret> hash2 port 1813 
                server 2 address 172.16.1.2 secret <shared secret> hash2 port 1813
            exit
            acct-request-script-policy "script-policy-3"
        exit
    exit

Triple Play aggregation network with RADIUS-based DHCP host authentication shows a flow of RADIUS authentication of DHCP hosts in the Triple Play aggregation environment. Besides granting the authentication of specified DHCP host, the RADIUS server can include RADIUS attributes (standard or Vendor-Specific Attributes (VSAs)) which are then used by the network element to provision objects related to a specified DHCP host.

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:

• Authentication determines whether a specific subscriber-host can access a specific service.

• Authorization associates connection attributes or characteristics with a specific subscriber host.

• Accounting tracks service use by individual subscribers.

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.

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 (AN) 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.

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.

    subscriber-mgmt
        ppp-policy "ppp-policy-1" create
            session-timeout 86400
        exit
    exit

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 (Subscriber session timeout):

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 command contains following fields related to session timeout for PPP sessions:

• Up Time: the PPP session uptime

• Session Time Left: the remaining time before the session is terminated

• RADIUS Session-TO: the RADIUS received session timeout value.

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

• Up Time

  the DHCPv4 host uptime

• Remaining Lease Time

  the remaining time before the lease expires in the DHCP server. The client should renew its lease before this time.

• Remaining SessionTime

  the remaining time before the DHCPv4 host is deleted

• Session-Timeout

  the DHCPv4 host is deleted when its uptime reaches the Session-Timeout value.

• Lease-Time

  the lease time specified by the DHCPv4 server

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.

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. Before Release 13.0.R4, 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.0.R4 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:

• ip-conflict

  This SHCV is sent in the following scenarios:

  • When the subscriber connects a new replacement residential gateway (RG) with a new MAC address on the same SAP on a system that still holds the subscriber's previous RG state. The new RG is assigned the same IP address or prefix as the previous RG (for example, with RADIUS address assignment). The system detects this IP conflict and triggers an SHCV to identify if the previous RG is still connected.
  • When the system does not detect an RG reboot and holds the subscriber's previous RG state, and the IPv4 address assignments are performed by an external DHCP server, the system detects an IP conflict when the DHCP server assigns a new IPv4 address that differs from the previously assigned IPv4 address. This conflict triggers an SHCV to identify if the previous IP address is still in use. This specific use case, where the same device is assigned two different IP addresses, is supported for IPv4 host only.

• host-limit-exceeded

  Sent when a subscriber has exceeded a configured host or session limit. Host limits are set in the sla-profile host-limits and in the sub-profile host-limits. Session limits are set in the group-interface ipoe-session sap-session-limit and session-limit, in the sla-profile session-limits and in the sub-profile session-limits contexts.

• inactivity

  The category-map configured under sla-profile can trigger an SHCV when the subscriber host becomes idle.

• mobility

  Intended for mobility applications such as Wi-Fi. When a subscriber moves between SAPs and requests for the same IP address, a triggered SHCV is sent to verify if the old host is still connected before removing the old host entry.

• mac-learning

  For IP-only static-host MAC learning. The trigger SHCV is sent to learn the subscriber MAC when a no shutdown command is executed on the CLI for the static host.

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 after the SHCV removes the disconnected host.

The other aspect of subscriber-host authorization is providing IP configuration (ip-address, subnet-mask, default gateway and dns) through RADIUS directory instead of 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 specific interface.

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

• framed-ip-address

  The IP address to be configured for the subscriber-host

• framed-ip-netmask

  The IP network to be configured for the subscriber host If RADIUS does not return a netmask, the DHCP request is dropped

• framed-pool

  The pool on a local DHCP server from which a DHCP-provided IP address should be selected

• alc-default-router

  The address of the default gateway to be configured on the DHCP client

• alc-primary-dns

  The DNS address to be provided in DHCP configuration.

  • Juniper VSA for primary DNS

  • Redback VSA for primary DNS

• alc-secondary-dns

  • Juniper VSA for secondary DNS

  • Redback VSA for secondary DNS

• alc-lease-time

  Defines the lease time

• session-timeout — Defines the lease time in absence of the alc-lease-time attribute

• NetBIOS

  • alc-primary-nbns

  • alc-secondary-nbns

To support VRF selection, the following attributes are supported:

Alc-Retail-Serv-Name takes precedence over Alc-Retail-Serv-Id if both are specified.

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:

1. Configure up to 64 RADIUS CoA servers per routing instance:

       config>router>radius-server#
       config>service>vprn>radius-server#
        server "coa-1" address 10.1.1.1 secret <shared-secret> hash2 create
            accept-coa
        exit
   

   This is the preferred method.

2. Configure up to 16 RADIUS CoA servers per authentication policy.

       config>subscr-mgmt>auth-plcy#
        accept-authorization-change
   

   The UDP port for CoA and Disconnect Messages is configurable per system with the command:

       config>aaa#
       radius-coa-port {1647|1700|1812|3799}
   

There are several reasons for using RADIUS initiated CoA messages:

1. Changing ESM attributes (SLA or subscriber profiles) or queues/policers/schedulers rates of the specific subscriber host. CoA messages containing the identification of the specified subscriber-host along with new ESM attributes.

2. Changing (or triggering the change) of IP configuration of the specified subscriber-host. CoA messages containing the identification of the specified subscriber-host along with VSA indicating request of FORCERENEW generation.

3. Configuring new subscriber-host. CoA messages containing the full configuration for the specific host.

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:

• attributes to identify a single or multiple subscriber hosts: NAS-Port-Id + IP address/prefix or Acct-Session-Id or Alc-Subsc-ID-Str

  • Nas-Port-Id attribute + single IP address/prefix attribute:

    • Framed-IP-Address

    • Alc-Ipv6-Address

    • Framed-Ipv6-Prefix

    • Delegated-Ipv6-Prefix

    • Alc-Client-Hardware-Addr (Required for private-retail subnet. For more information, see the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide.)

  • Acct-Session-Id (number format)

  • Alc-Subsc-ID-Str

  • User-Name (Possible to use in combination with the following. For more information, see the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide.)

    • Framed-Ip-Address

    • Alc-Ipv6-Address

    • Framed-Ipv6-Prefix

    • Delegated-Ipv6-Prefix

    • Alc-Client-Hardware-Addr

• alc-subscriber-profile-string

• alc-sla-profile-string

• alc-ancp-string

• alc-app-profile-string

• alc-int-dest-id-string

• alc-subscriber-id-string

• alc-subscriber-qos-override

  Note: If the subscriber-id-string is changed while the ANCP string is explicitly set, the ANCP-string must be changed simultaneously. When changing the alc-subscriber-id-string, the lease state is temporarily duplicated, causing two identical ANCP-strings to be in the system at the same time. This is not allowed.

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

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

• attributes to identify a single or multiple subscriber hosts: ‟NAS-Port-Id + IP address/prefix” or ‟Acct-Session-Id” or ‟Alc-Subsc-ID-Str” or ‟user-name”:

  • Nas-Port-Id attribute + single IP address/prefix attribute:

    • Framed-IP-Address

    • Alc-Ipv6-Address

    • Framed-Ipv6-Prefix

    • Delegated-Ipv6-Prefix

  • Acct-Session-Id (number format)

  • Alc-Subsc-ID-Str

  • User-Name

• alc-force-renew

• alc-force-nak

As a reaction to a message, router generates a DHCP FORCERENEW message for the specified 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.

• alc-create-host

• alc-subscriber-id-string

  This attribute is mandatory in case ESM is enabled, and optional for new subscriber host creation otherwise.

• NAS-port-id

  This attribute indicates the SAP where the host should be created.

• framed-ip-address

  the framed IP address

• alc-client-hw-address

  A string in the xx:xx:xx:xx:xx:xx format. This attribute is mandatory for new subscriber-host creation.

• alc-lease-time

  Specifies the lease time. If both session-timeout and alc-lease-time are not present, then a default lease time of 7 days is used.

• session-timeout

  Specifies the lease time in absence of the alc-lease-time attribute. If both session-timeout and alc-lease-time are not present, then a default lease time of 7 days is used.

• alc-retail-svc-id

  This is only used in case of wholesaling for selection of the retail service. Indicates the service-id of the required retail VPRN service configured on the system.

• Optionally other VSAs describing a specified subscriber host. If the ESM is enabled, but the CoA message does not contain ESM attributes, the new host is not created.

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 then, a 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:

• Support of CoA messages is disabled by default. They can be enabled on a per RADIUS server or authentication-policy basis.

• When CoA is enabled, the node listens and react only to CoA messages received from RADIUS servers. In addition, CoA messages must be protected with the key corresponding to the specified RADIUS server. All other CoA messages are silently discarded.

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”.

• Nas-Port-Id + single IP address/prefix:

  • Nas-Port-Id

  • Framed-IP-Address

  • Alc-Ipv6-Address

  • Framed-Ipv6-Prefix

  • Delegated-Ipv6-Prefix

  • Alc-Client-Hardware-Addr (may be required for private retail subnet. For more information, see the RADIUS Attributes Reference Guide.)

• Acct-Session-Id (number format)

• Alc-Subsc-ID-Str

• User-Name (Possible to use in combination with the following. For more information, see the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide.)

  • Framed-Ip-Address

  • Alc-Ipv6-Address

  • Framed-Ipv6-Prefix

  • Delegated-Ipv6-Prefix

  • Alc-Client-Hardware-Addr

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

• Receiving CoA message with the same attributes as currently applicable to the specified host responds with an ACK message.

• In case of dual homing (through SRRP), the RADIUS server should send CoA messages to both redundant nodes and this with all corresponding attributes (NAS-port-id with its local meaning to corresponding node).

• In the case of change requests, the node which has the specified host active (active SAP or SAP associated with a group interface in SRRP master state) processes the RADIUS message and reply to RADIUS. The standby node always replies with a NAK.

• In the case of create requests, the active node (the SAP described by NAS-port-id is active or associated with a group-interface in SRRP master state). Both nodes reply, but the standby NAKs the request.

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.

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 sends it to the RADIUS accounting server. At the termination of the session, it generates an accounting-stop packet including accounting statistics for a specified 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.

configure
    subscr-mgmt
        radius-accounting-policy <name>
            include-radius-attribute
                [no] acct-authentic
                [no] acct-delay-time
                [no] called-station-id
                [no] calling-station-id
                [no] circuit-id
                [no] delegated-ipv6-prefix
                [no] dhcp-vendor-class-id
                [no] framed-interface-id
                [no] framed-ip-addr
                [no] framed-ip-netmask
                [no] framed-ipv6-prefix
                [no] framed-route
                [no] framed-ipv6-route
                [no] ipv6-address
                [no] mac-address
                [no] nas-identifier
                [no] nas-port
                [no] nas-port-id
                [no] nas-port-type
                [no] nat-port-range
                [no] remote-id
                [no] sla-profile
                [no] sub-profile
                [no] subscriber-id
                [no] tunnel-server-attrs
                [no] user-name
                [no] wifi-rssi
                [no] alc-acct-triggered-reason
                [no] access-loop-options
                [no] all-authorized-session-addresses
                [no] detailed-acct-attributes
                [no] std-acct-attributes
                [no] v6-aggregate-stats

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:

config
    subscr-mgmt
        radius-accounting-policy <name>
            include-radius-attribute
                [no] detailed-acct-attributes
                [no] std-acct-attributes
                [no] v6-aggregate-stats
  

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 specific RADIUS accounting policy is applied to a specified subscriber profile, or the first server is defined in the context of an already applied policy. The following attributes included are in these messages:

• NAS-identifier

• alc-subscriber-profile-string

• Accounting-session-id

• Event-timestamp

Accounting-off messages are sent at following events:

• An accounting policy has been removed from a sub-profile.

• The last RADIUS accounting server has been removed from an already applied accounting policy.

These messages contain following attributes:

• NAS-identifier

• alc-subscriber-profile-string

• Accounting-session-id

• Accounting-terminate-cause

• Event-timestamp

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 specified 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. See the ‟Configuring an Accounting Custom Record” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for further information.

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 more 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 may 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:

import alc
import struct

ALU            = 6527
TERM_CAUSE     = 49
ALC_ERROR_CODE = 226

if (alc.radius.attributes.isSet(TERM_CAUSE) and
    alc.radius.attributes.isVSASet(ALU, ALC_ERROR_CODE)):

    error_code = alc.radius.attributes.getVSA(ALU, ALC_ERROR_CODE)
    error_code = struct.unpack('!i', error_code)[0]

    term_cause  = alc.radius.attributes.get(TERM_CAUSE)
    term_cause = struct.unpack('!i', term_cause)[0]

    #print "error code = ", error_code
    #print "term cause = ", term_cause

    # table with mapping from alc-error-code to the standard terminate cause
    # if no mapping is found, no transformation is performed
    error_map = {
        123 : 8,
        124 : 17
    }

    new_term_cause = error_map.get(error_code, term_cause)
    #print "new term_cause = ", new_term_cause

    alc.radius.attributes.set(TERM_CAUSE, struct.pack('!I', new_term_cause))

In the per host accounting mode of operation the accounting message stream (START/INTERIM-UPDATE/STOP) is generated per host.

An accounting message stream refers to a collection of accounting messages (START/INTERIM-UPDATE/STOP) sharing the same acct-session-id.

The following are the properties of the per host accounting model:

• A RADIUS accounting START message is sent each time a host is created in the system.

• Whenever a host disconnects, a RADIUS accounting STOP message is sent for that host.

• The accounting messages (START, INTERIM-UPDATE, STOP) carry the acct-multi-session-id attribute denoting the queue instance or session with which the host is associated (see Accounting modes of operation ).

• The counters are collected from the queues and policers instantiated through the queue instance (SLA profile instance). If multiple hosts share the same queue instance, the counters are aggregated. In other words, counters per individual hosts cannot be extracted from the aggregated count.

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

• A PPPoE session is identified by the key {session-ID, mac}

• An IPoE session is identified by the configured session-key: {sap, mac} | {sap, mac, Circuit-ID} | {sap, mac, Remote-ID}

For a single stack session, 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 sessions.

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

• A single accounting session ID (acct-session-id) is generated per (IPoE or PPPoE) session and it can optionally be sent in RADIUS Access-Request message.

• This acct-session-id is synchronized through MCS in dual homing environment.

• The accounting messages (START, INTERIM-UPDATE, STOP) carry the acct-multi-session-id attribute denoting the queue instance (SLA profile instance) with which the session is associated.

• The counters are collected from the queues and policers instantiated through the queue instance (SLA Profile Instance). If multiple sessions are sharing the same queue instance, the counters are aggregated. In other words, counters per individual session cannot be extracted from the aggregated count.

• RADIUS-triggered changes and LI, targeted to the session’s accounting session ID are applicable per session:

  • In queue and policer RADIUS overrides, parameters for the referenced queue and policer within the session are changed accordingly.

  • Subscriber aggregate rate limits, scheduler rates, and arbiter rates are changed accordingly.

  • CoA DISCONNECT brings down the entire session.

  • LI activation based on the session acct-session-id affects the hosts within the session (dual-stack).

  • An SLA profile instance change affects all hosts (or sessions) sharing the same sla-profile instance (SPI). Queues are re-instantiated and counters are reset.

• All applicable IP addresses (IPv4 and IPv6, including all IPv6 attributes; alc-ipv6-address, framed-ipv6-prefix, delegated-ipv6-prefix) are present in accounting messages for the session.

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.

RADIUS accounting behavior describes 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 therefore accounting and QoS parameters. Complications arose 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.

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.

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

config
 subscr-mgmt
        radius-accounting-policy "acct-policy-1" create
            update-interval 60
            update-interval-jitter absolute 600

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.

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:

• the reason for the triggered interim message (such as an SLA start)

• the CoA-triggered (18) Alc-Triggered-Acct-Interim attribute that is echoed on the triggered accounting interim message if the VSA is not empty

The RADIUS class attribute helps to aid in user identification.

User identification is used to correlate RADIUS accounting messages with the specified 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.

The username, which is used for user authentication (the "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 name is used in accounting and not the originally sent name.

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:

• An Accounting-On is sent for the following:

  • When the system is powered on

  • After a system reboots

  • When the acct-on-off command is added to the radius-server-policy configuration

  • User triggered with CLI: tools perform aaa acct-on

• An Accounting-Off is sent for the following:

  • Before a user initiated system reboot

  • When the acct-on-off command is removed from the radius-server-policy configuration

  • User triggered with CLI: tools perform aaa acct-off

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:

config
    aaa
        radius-server-policy "aaa-server-policy-1" create
            acct-on-off oper-state-change
            servers
                router "Base"
                server 1 name "server-1"
            exit
        exit
    exit

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:

• a single RADIUS server policy as controller: the acct-on-off oper-state of the acct-on-off-group is set to the acct-on-off oper-state of the radius-server-policy

• multiple RADIUS server policies as monitor: the acct-on-off oper-state of the RADIUS server policy is inherited from the acct-on-off oper-state of the acct-on-off group.

config
    aaa
        acct-on-off-group "group-1" create
            description "Grouping of radius-server-policies acct-on-off"
        exit        
        radius-server-policy "aaa-server-policy-1" create
            acct-on-off oper-state-change group "group-1"
            servers
                router "Base"
                server 1 name "server-1"
            exit
        exit
        radius-server-policy "aaa-server-policy-2" create
            acct-on-off monitor-group "group-1"
            servers
                router "Base"
                server 1 name "server-2"
            exit
        exit

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:

# show aaa radius-server-policy "aaa-server-policy-3" acct-on-off 
===============================================================================
RADIUS server policy "aaa-server-policy-3" AcctOnOff info
===============================================================================
Oper state                  : on
Session Id                  : 242FFF0000008F512A3985
Last state change           : 02/24/2013 16:06:41
Trigger                     : startUp
Server                      : "server-1"
===============================================================================

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:

# show aaa radius-server-policy "aaa-server-policy-3"             
===============================================================================
RADIUS server policy "aaa-server-policy-3"
===============================================================================
Description                 : (Not Specified)
Acct Request script policy  : script-policy-1
Auth Request script policy  : script-policy-1
Accept script policy        : script-policy-1
Acct-On-Off                 : Enabled (state Blocked)
-------------------------------------------------------------------------------
RADIUS server settings
-------------------------------------------------------------------------------
Router                      : "Base"
Source address              : (Not Specified)
Access algorithm            : direct
Retry                       : 3
Timeout (s)                 : 5
Hold down time (s)          : 30
Last management change      : 02/20/2013 13:32:05
===============================================================================
===============================================================================
Servers for "aaa-server-policy-3"
===============================================================================
Idx Name                             Address         Port        Oper State
                                                     Auth/Acct   
-------------------------------------------------------------------------------
1   server-3                         172.16.1.10     1812/1813   unknown
===============================================================================

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:

# show aaa acct-on-off-group "group-1" 
===============================================================================
Acct-On-Off-Group Information
===============================================================================
acct on off group name               : group-1
  - controlling Radius-Server-policy :  
        aaa-server-policy-1
  - monitored by Radius-Serer-policy :  
        aaa-server-policy-2

-------------------------------------------------------------------------------
Nbr of Acct-on-off-groups displayed : 1
-------------------------------------------------------------------------------
===============================================================================

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:

config
    aaa
        radius-server-policy "aaa-server-policy-1" create
            servers
                router "Base"
                buffering
                    acct-start min 60 max 3600 lifetime 12
                    acct-interim min 60 max 3600 lifetime 12
                    acct-stop min 60 max 3600 lifetime 12
                exit
                server 1 name "server-1"
            exit
        exit
    exit

When RADIUS accounting message buffering is enabled:

1. The message is stored in the buffer, a lifetime timer is started and the message is sent to the RADIUS server.

2. If, after retry timeout seconds, no RADIUS accounting response is received, then a new attempt to send the message is started after a minimum [(min-val*2n), max-val] seconds. The min-val and max-val parameters are configurable and correspond to each accounting message type.

3. Repeat step 2 until one of the following events occurs and the message is purged from the buffer:

   1. RADIUS accounting response is received

   2. the lifetime of the buffered message expires (as shown in Purging message from buffer)

   3. (if the buffered message is an Accounting Interim-Update only) A new Accounting Interim-Update or an Accounting Stop or for the same accounting session-id and radius-server-policy is stored in the buffer

   4. the message is manually purged from the message buffer with a clear command

      

When Accounting Start message buffering is enabled:

• the Accounting Start message is stored in the buffer

• enabling Accounting Interim-Update and Stop message buffering with the same lifetime value is recommended. This guarantees the message ordering per accounting session. The RADIUS Accounting Start message is used to re-establish a connection to the RADIUS server. Therefore, when the connections to RADIUS servers are restored, Accounting Start messages are always sent first followed by the Accounting Interim-Update or Stop messages. In addition, when connection to the RADIUS server is restored, the system attempts to send the buffered Accounting Start messages first, as Accounting responses are received for the Accounting Start messages, Accounting Interim-Update or Stop messages for that particular subscriber session are sent.

• if, for the same accounting session, an Accounting Start message and an Accounting Interim-Update or Stop message are both buffered, it is possible for the Start message to be dropped from the accounting buffer because of lifetime expiry. As a result, when the connection to the RADIUS server is restored, only the Accounting Interim-Update or Stop message is sent.

• if the RADIUS server is unreachable for a prolonged period, it is possible for subscribers to have started and terminated more than one session. If buffering for Accounting Start is enabled, an Accounting Start message for each session is buffered.

• a Python script is applied only when the RADIUS Start message is sent. In other words, buffered RADIUS messages are never processed by Python. It is possible to alter the Python scripts when RADIUS messages are buffered and the message is subjected to the newest applied Python script.

When Accounting Interim-Update message buffering is enabled:

• only the last Accounting Interim-Update or Accounting Stop message (if enabled) is stored in the buffer. Accounting session events that are reported by a triggered Accounting Interim-Update, such as an SLA-Profile Change can be lost.

• enabling Accounting Stop message buffering is recommended. This guarantees message ordering per accounting session.

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:

# show aaa radius-server-policy "aaa-server-policy-1" msg-buffer-stats
===============================================================================
buffering acct-start        : enabled
  min interval (s)          : 60
  max interval (s)          : 300
  lifetime (hrs)            : 25
buffering acct-interim      : enabled
  min interval (s)          : 60
  max interval (s)          : 300
  lifetime (hrs)            : 25
buffering acct-stop         : enabled
  min interval (s)          : 60
  max interval (s)          : 300
  lifetime (hrs)            : 25
Statistics
-------------------------------------------------------------------------------
Total acct-start messages in buffer                       : 0
Total acct-interim messages in buffer                     : 0
Total acct-stop messages in buffer                        : 0
Total acct-start messages dropped (lifetime expired)      : 0
Total acct-interim messages dropped (lifetime expired)    : 0
Total acct-stop messages dropped (lifetime expired)       : 0
Last buffer clear time                                    : N/A
Last buffer statistics clear time                         : N/A
-------------------------------------------------------------------------------
===============================================================================

Use the 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:

# tools dump aaa radius-server-policy "aaa-server-policy-1" msg-buffer 
===============================================================================
RADIUS server policy "aaa-server-policy-1" message buffering
===============================================================================
message type Acct-Session-Id                                 remaining lifetime
-------------------------------------------------------------------------------
acct-interim 242FFF0000009A512B36FC                          0d 11:58:54
acct-interim 242FFF0000009B512B36FC                          0d 11:58:48
acct-interim 242FFF0000009C512B36FC                          0d 11:58:30
acct-interim 242FFF0000009D512B36FC                          0d 11:58:29
acct-interim 242FFF0000009E512B36FC                          0d 11:59:05
-------------------------------------------------------------------------------
No. of messages in buffer: 5
===============================================================================

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

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.

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:

• ‟on-request-failure”

  All failure conditions between the sending of an Access-Request and the reception of an Access-Accept or Access-Reject.

• ‟on-reject”

  When an Access-Reject is received.

• ‟on-accept-failure”

  All failure conditions that appear after receiving an Access-Accept and before successful instantiation of the host or session.

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.

configure
    subscriber-mgmt
        local-user-db "ludb-1" create
            ppp
                match-list username 
                host "default" create
                    auth-policy "auth-policy-1"
                    acct-policy "acct-policy-1" duplicate "acct-policy-2"
                    no shutdown
                exit
            exit
            no shutdown
        exit
        authentication-policy "auth-policy-1" create
            pppoe-access-method pap-chap
            include-radius-attribute
               - - - snip - - -
            exit
            send-acct-stop-on-fail on-request-failure on-reject on-accept-failure
            radius-server-policy "aaa-server-policy-1"
        exit
        radius-accounting-policy "acct-policy-1" create
            - - - snip - - -
            radius-server-policy "aaa-server-policy-1"
        exit
        radius-accounting-policy "acct-policy-2" create
            - - - snip - - -
            radius-server-policy "aaa-server-policy-2"
        exit

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

configure
    service
        vpls 10 customer 1 create
            sap 1/1/1:1.* capture-sap create
                trigger-packet pppoe
                pppoe-policy "ppp-policy-1"
                pppoe-user-db "ludb-1"
            exit
            no shutdown
        exit                
        ies 1000 customer 1 create
            subscriber-interface "sub-int-1" create
               - - - snip - - -
                group-interface "group-int-1-1" create
                    - - - snip - - -
                    pppoe
                        policy "ppp-policy-1"
                        user-db "ludb-1"
                        no shutdown
                    exit
                exit
            exit
            no shutdown
        exit

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 describes 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.

The system can switch between standard and enhanced subscriber management modes on a per SAP basis. The ESM 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.

• Standard mode

  The system performs SLA enforcement functions on a per SAP basis, that is, the attachment to a SAP with DHCP lease management capabilities. The node can authenticate a subscriber session with RADIUS based on the MAC address, the circuit-id (from Option 82) or both. It then maintains the lease state in a persistent manner. It can install anti-spoofing filters and ARP entries based on the DHCP lease state. Static subscriber hosts are not required to have any SLA or subscriber profile associations and are not required to have a subscriber identification string defined.

• Enhanced mode

  When enabled on a SAP, the system expands the information it stores per subscriber host, allowing SLA enforcement and accounting features on a per subscriber basis. The operator can create a subscriber identification policy that includes a URL to a user-space script that assists with the subscriber host identification process.

  • A subscriber host is identified by a subscriber identification string instead of the limited Option 82 values (although, the identification string is normally derived from string manipulation of the Option 82 fields). A subscriber identification policy is used to process the dynamic host DHCP events to manage the lease state information stored per subscriber host. The static subscriber hosts also must have subscriber identification strings associations to allow static and dynamic hosts to be grouped into subscriber contexts.

  • Further processing by the subscriber identification policy derives the appropriate subscriber and SLA profiles used to define the hierarchical virtual schedulers for each subscriber and the unique queuing and filtering required for the hosts associated with each subscriber.

  • The SLA profile information is used to identify which QoS policies and which queues/policers, and also which egress hierarchical virtual schedulers, is used for each subscriber host (dynamic or static).

  • The system performs SLA enforcement functions on a per subscriber SLA profile instance basis. SLA enforcement functions include QoS (classification, filtering and queuing), security (filtering), and accounting.

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 correct enhanced mode operation. If any one of the following requirements is not met, enhanced mode operation is not allowed on the SAP:

• Anti-spoofing filters must be enabled and configured as IP+MAC matching.

• Any existing static subscriber hosts must have:

  • An assigned subscriber identification string.

  • An assigned subscriber profile name.

  • An assigned SLA profile name.

• The system must have sufficient resources to create the required SLA profile instances and schedulers.

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. If a dynamic host event cannot be processed because of insufficient resources, the DHCP ACK message is discarded and the previous host lease information is retained in the system.

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 after 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:

• wan-host

  A range of prefixes that are assigned to PPPoE hosts and as DHCPv6 IA_NA addresses. These prefixes are always /64.

• pd

  A range of prefixes that are assigned as DHCPv6 IA_PD prefixes for DHCPv6 IPoE clients and for PPPoE RGs. The length of these prefixes is defined by the delegated-prefix-length.

• both

  When both 'wan-host' and 'pd' are defined, the subscriber prefix is a range that can be used for both previous types. However, the delegated-prefix-length is restricted to /64 in this case.

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. After 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.

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.

• The system differentiates each subscriber using only the first 64 bits of the WAN address (each host must have a unique /64 prefix, with the exception of bridge host.) This differentiation includes the ability to identify individual subscribers and to apply different subscriber profile and SLA-profiles to each subscriber.

• For IPoE bridge hosts, when a group of hosts shares a prefix, all hosts must share the same SLA-profile.

• Each SLAAC subscriber must use a unique /64 prefix. IPoE bridge hosts can share the same SLAAC prefix and must also share the same SLA-profile.

• Each IPv6 data-trigger host must use a unique /64 prefix.

• The DHCPv6 server must be set up to assign each host with a unique /64 prefix. The 7750 SR local DHCP server assigns each subscriber with a unique /64 prefix by default.

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.

• It is not recommended to change a subscriber interface from unnumbered to numbered (or the other way around). If the subscriber interface must be changed, all ESM hosts under the subscriber should be removed first.

• The system can uniquely identify each subscriber using the full 128-bit WAN address. Each 128-bit WAN host can have its own unique SLA and Subscriber profile.

• When provisioning a numbered subscriber interface, an IPv6 address or a prefix can be assigned. The mask for the address can range from 32 to 127. If the mask is less than 96, an internal /96 route is generated when a WAN host is created (by DHCP IPv6 IANA). This automatically-generated /96 route is used for subscriber lookup. These /96 routes are visible in the RIB and occupy a route entry in the system forwarding table. A /96 route can serve approximately 4.2 billion WAN hosts. Therefore, a single /96 prefix or address should be able to accommodate all WAN hosts terminating on a subscriber interface. Nokia recommends, when using 128-bit WAN mode to configure subscriber interface, use addresses or prefixes with a mask length of 96 to 127. When using 128-bit WAN mode, it is not recommended to assign individual subscribers unique /64 prefixes, because the system generates an internal /96 route for each host, therefore overloading the routing table.

• Adding and removing a prefix or address from the subscriber interface in 128-bit WAN mode may trigger /96 routes to be generated or deleted, which can impact subscriber service. Nokia recommends performing this action during off-peak hours.

• The auto-generated /96 routes needed for subscriber lookup are tagged in the RIB as "Wan Mode 128 Route".

  # show router 2000 route-table ipv6 2001:db8:2000:100::/96 extensive
  ===============================================================================
  Route Table (Service: 2000)
  ===============================================================================
  Dest Prefix             : 2001:db8:2000:100::/96
    Protocol              : LOCAL
    Age                   : 00h06m26s
    Preference            : 0
    Wan Mode 128 Route    : Yes
    Next-Hop              : N/A
      Interface           : sub-int-2
      QoS                 : Priority=n/c, FC=n/c
      Source-Class        : 0
      Dest-Class          : 0
      Metric              : 0
      ECMP-Weight         : N/A
  -------------------------------------------------------------------------------
  No. of Destinations: 1
  ===============================================================================
  

  These routes can be leaked between local VPRN services on the same router using MP-BGP export and import policies as they are needed for subscriber lookup in extranet topologies. The auto-generated /96 routes are not advertised in the BGP RIB; instead, the prefix configured on the subscriber interface should be used in BGP.

• 128-bit WAN mode is supported in unnumbered subscriber interfaces. Each WAN host generates a /128 route.

• The allow-unmatching-prefixes command can be performed on a numbered subscriber interface in 128-bit WAN mode. This functionality can be used as a subnet migration tool, but must be performed without hosts under the subscriber interface. Changing a subscriber interface from numbered to unnumbered (or the other way around) impacts subscriber service.

• IPv6 DHCP IANA subscribers can be assigned incremental 128-bit addresses.

• IPoE-bridge mode is only recommended to be configured with 64-bit WAN mode. For 128-bit WAN mode, the system generates at least one /96 prefix per subscriber to help lookup. Because each subscriber interface has a limited number of allowed prefixes, generating a /96 per subscriber reduces scalability. If 128-bit WAN mode is used, each DHCP IANA host can have a distinct SLA profile. In 64-bit WAN mode, all DHCP IANA hosts must share the same SLA profile.

• For IPoE bridge SLAAC hosts, hosts sharing the same /64 prefix must share the same SLA profile. IPoE bridge SLAAC hosts do not differ from 128-bit or 64-bit WAN mode.

• Each IPv6 data-trigger host can use a unique /128 address.

• The DHCP IA_NA host for both PPPoE and IPoE hosts can assign incremental 128-bit addresses.

• For retail VPRN that requires 128-bit WAN mode support, the wholesale subscriber interface must also be configured with 128-bit WAN mode.

• SLAAC hosts and DHCP WAN hosts must not share the same prefix.

• The following host types are not supported:

  • GTP hosts

  • hybrid access hosts

  • WLAN hosts

  • default hosts

The delegated prefix length (DPL) is applicable to subscriber-hosts with IPv6 Prefix (IA-PD) assigned by the DHCPv6 Server. An IPv6 prefix is more similar to a route than 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 IPv6 prefix.

For example, a DHCPv6 server prefix pool contains an aggregated (configured) IPv6 prefix from which the delegated prefixes are carved out. In IPv6 prefix 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:

• RADIUS

  • Delegated-IPv6-Prefix attribute that contains the prefix and the length (Delegated-IPv6-Prefix = AAAA:BBBB::/56). The DPL in this case is /56.

  • Alc-Delegated-IPv6-Prefix-Length VSA (to be used in conjunction with the DHCPv6 pool name - Alc-Delegated-IPv6-Pool VSA)

• LUDB

  Configured by LUDB per IPoEv6/PPPoEv6 host:

  This is to be used along with the DHCPv6 pool name (ipv6-delegated-prefix-pool) defined under the same CLI hierarchy.

  CLI syntax:

          configure
          subscriber-mgmt 
              local-user-db <name>
                  ipoe | ppp
                      host <name> 
                          ipv6-delegated-prefix-length [48 to 64]
  

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

  CLI syntax:

      configure
          subscriber-mgmt 
              local-user-db <name>
                      ipoe | ppp
                          host <name> 
                              ipv6-delegated-prefix <ipv6-prefix/prefix-length>
  

• DHCPv6 server

  Each DHCPv6 pool can optionally be configured with a DPL

  CLI syntax:

      configure
           service/router   
              dhcp6
                  local-dhcp-server <name>
                      pool <pool-name>
                          delegated-prefix-length [48 to 127]
  

Configured statically under the ipv6 CLI node of subscriber interface. In this case, the DPL is fixed for all subscriber hosts under the subscriber interface.

CLI syntax:

    configure
        service ies/vprn 
            subscriber-interface <ip-int-name>
                    ipv6
                        delegated-prefix-length [48 to 64] | variable

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.

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

• The third party DHCPv6 server must return a unique IA_PD IPv6 delegated prefix (/64 or lower) for each allocation. The length of the IA_PD IPv6 delegated prefix must match the delegated-prefix-len configured on the subscriber interface on the 7750 DHCP L3 relay. This length is also included in the Relay-Forward message as PFX_LEN option (3) in a Vendor-Specific-Information-Option (17).

• For IPv6oE routed CPEs, the 3rd party DHCPv6 server must return a unique IA_NA IPv6 address (/128) from a different /64 subnet for each allocation.

• For IPv6oE hosts behind bridged CPE's

  • the third party DHCPv6 server must return a unique IA_NA IPv6 address (/128) from a different /64 subnet for each allocation (host) that belongs to a different CPE.

  • the third party DHCPv6 server may return a unique IA_NA IPv6 address (/128) from the same /64 subnet for allocations (hosts) that belong to the same CPE and that are attached to the same VLAN (SAP) on the BNG.

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

• WAN_POOL option (1) contains the pool name from which the IA_NA IPv6 address should be allocated.

• PFX_POOL option (2) contains the pool name from which the IA_PD IPv6 delegated prefix should be allocated.

• PFX_LEN option (3): contains the IA_PD IPv6 delegated prefix length that should be allocated.

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 toward 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).

1. DHCPv6 proxy:

   If only the IPv6 address/prefix information is provided (Framed-IPv6-Prefix, Alc-IPv6-Address or Delegated-IPv6-Prefix).

2. DHCPv6 relay:

   • If no IPv6 address/prefix (Framed-IPv6-Prefix, Alc-IPv6-Address or Delegated-IPv6-Prefix) and no IPv6 pool (Framed-Pool, Delegated-Pool) information provided.

   • If no IPv6 address/prefix (Framed-IPv6-Prefix, Alc-IPv6-Address or Delegated-IPv6-Prefix) and IPv6 pool (Framed-Pool, Delegated-Pool) information provided.

3. If both IPv6 address/prefix (Framed-IPv6-Prefix, Alc-IPv6-Address or Delegated-IPv6-Prefix) and IPv6 pool (Framed-Pool, Delegated-Pool) information are present, the DHCP packet is DROPPED.

To support all processing for ESM, several tables are maintained in the router (ESM dynamic tables).

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

• The ACK message is parsed using the appropriate script.

• An entry is generated in the subscriber host table with indexes:

  • The SAP on which the host resides

  • The assigned IP address

  • The assigned MAC address and as lookup parameters:

    • the subscriber profile

    • the SLA profile to be used (derived from using the script)

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.

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.

• If there is no entry, this means that the host is not using the assigned IP address, so the packet is dropped.

• If there is an entry, this refers to the subscriber profile and SLA profile to be used.

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

• PPPoE PADI and PADR

• DHCPv4 discover, DHCPv4 request, DHCPv6 solicit, DHCPv6 request

• ARP Request

• PPPoE session disconnect after successful session establishment

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>.

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

• ANCP can communicate the current access line rate to the router. This allows the router to adjust the H-QoS subscriber scheduler with the correct rate or potentially change alarm when the rate goes below a set threshold. This allows a policy manager to change the entire policy when the rate drops below a minimal threshold value. The ANCP actual upstream synchronization rate is mapped to the ingress while ANCP actual downstream synchronization rate is mapped to the egress.

• The router can send DSL line OAM commands to complete an OAM test from a centralized point or when operational boundaries prevent direct access to the DSLAM.

When ANCP is used with ESM, the ancp-string 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.

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 more 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 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:

• as the intermediate controller

  The router terminates a connection from the DSLAM.

• as the terminating controller

  The router fulfills full the roll of BRAS.

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 specific level of security. The actual connection between DSLAM and BRAS is established at TCP level, and then individual messages are transported.

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.

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.

Python Language and Programmable Subscriber Configuration Policy (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 (see 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 (see 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 more 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 URLs.

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

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:

sub-ident

identifies the subscriber (always needed)

sub-profile

identifies the subscriber class (optional)

sla-profile

identifies the SLA Profile for this subscriber host (optional)

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.

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.

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

1. A lookup in the explicit-subscriber-map is done with the sub-ident string returned by the script. If a matching entry is found, the sub-profile-name (if defined) is taken. Otherwise:

2. If a sub-ident-policy is defined on the SAP, a lookup is done on its sub-profile-map with the sub-profile string from the script. The sub-profile-name is taken from the entry.

   If no entry was found, then:

3. If provisioned, the sub-profile-name is taken from the def-sub-profile attribute on the SAP. If not provisioned, then:

4. The sub-profile with the name ‟default” is selected (if provisioned). If this is not provisioned, there are no other alternatives, the ACK is dropped, and the host does not gain access.

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 QoS-policies to use:

  • classification

  • queues/policers

  • queue mapping

• The egress scheduling policies use egress HQoS

• The IP filter to use.

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 and 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 and policers are instantiated when, on a specific SAP, a host of a subscriber is the first to use a specific 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:

show qos scheduler-hierarchy subscriber sub-ident-string sla-profile sla-profile-
name 
sap sap-id [scheduler scheduler-name] [detail]

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.

monitor qos scheduler-stats subscriber sub-ident-string [interval seconds] [repeat 
repeat] [absolute|rate] sap sap-id sla-profile sla-profile-name

show qos scheduler-stats subscriber sub-ident-string sap sap-id sla-profile sla-
profile-name [scheduler scheduler-name]

clear qos scheduler-stats subscriber sub-ident-string sap sap-id sla-
profile sla-profile-name [scheduler scheduler-name]

Determining the SLA profile 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 toward the SLA profile indicate the priority of the provisioning (the lower number means the higher priority).

1. A lookup is done with the sub-ident string returned by the script in the explicit-subscriber-map. If a matching entry is found, the sla-profile-name is taken from it – if defined. Otherwise:

2. A lookup with the sla-profile string from the script is done in the sla-profile-map of the sub-profile found earlier. The sla-profile-name from the found entry is taken. If no entry was found, then:

3. A lookup is done with the sla-profile string in the sla-profile-map of the sub-ident-policy configured on the SAP. The sla-profile-name from the found entry is taken. If no sub-ident-policy was configured on the SAP or no entry was found, then:

4. If provisioned, the sla-profile-name is taken from the def-sla-profile attribute on the SAP. If not provisioned, there are no more alternatives, the ACK is dropped, and the host does not gain access.

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:

• CoA

• tools commands:

  • tools>perform>subscr-mgmt>edit-ipoe-session subscriber

  • tools>perform>subscr-mgmt>edit-lease-state subscriber

  • tools>perform>subscr-mgmt>edit-ppp-session subscriber

  • tools>perform>subscr-mgmt>edit-slaac-host subscriber

  The above commands must be run separately for each host or session of the subscriber that is renamed.

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

• Long sub-ids and long brg-ids are automatically enabled without having to explicitly enable them by provisioning additional CLI commands.

• Although, the internal ANCP strings are 64 characters long, some of the external ANCP strings are limited to 63 characters. This is the limitation of the ANCP protocol and some of these strings are:

  • Access-Loop-Circuit-ID TLV

  • Access-Loop-Remote-ID TLV

  • Access-Aggregation-Circuit-ID-ASCII

  Consequently, the maximum size of externally controlled ANCP parameters remains at 63 characters (such as the ANCP protocol, RADIUS, CLI). This means that when ANCP is used, the operators should restrict the sub-id string to a maximum of 63 characters, or always provide and explicit ANCP string that is a maximum of 63 characters in length.

• Multicast host-tracking is not supported with long sub-ids. This means that the hosts with a sub-id longer than 32 characters are excluded from host tracking. The sub-id key length for host-tracking related MIB tables remain unchanged at 32 characters and only contains subs with short sub-ids.

  The following MIBs are not supported for long sub-ids:

  • tmnxSubGrpTrkEntry

  • tmnxSubHostGrpTrkEntry

  • tmnxSubHostSapTrkEntry

  • tmnxSubHostTrkEntry

  • tmnxSubHostTrkStatsEntry

  • tmnxSubTrkPlcySubscriberEntry

  • tmnxSubTrkStatusEntry

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

  configure
    subscriber-management
        host-tracking-policy <policy-name>
              egress-rate-modify [agg-rate-limit | scheduler <sch-name>]
   
  configure
    subscriber-management
        sub-profile <subscriber-profile-name>
            host-tracking-policy <policy-name>  => mutually exclusive with igmp-policy
  

  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:

  configure
    subscriber-management
        igmp-policy <policy-name>
                egress-rate-modify [egress-aggregate-rate-limit | scheduler <name>]
   
  configure
    subscriber-management
        sub-profile <subscriber-profile-name>
                igmp-policy <policy-name>
  

• With the introduction of the long sub-id and long brg-id options, the show command output is rearranged by inserting additional line breaks and by wrapping the long sub-id and long brg-id at the end of the line. For example, the sub-id subidlong.123456789_123456789_123456789 123456789_123456789_3333 is wrapped as follows:

===============================================================================
Subscriber                             : subidlong.123456789_123456789_12345678
                                         9 123456789_123456789_3333
===============================================================================

• In a multihoming environment, the internal short sub-ids and short brg-ids are not synchronized. This means that they are independently derived on each node, meaning that if they are needed by the operator, they have to be retrieved by the management system after every switchover.

  In most cases, the operator is not aware of the internal sub-id and brg-id. Their awareness is required only if an SNMP table walk is performed in one of the 11 MIB tables where the long sub-id and long brg-id causes the key to exceed the 128 character limit. If an entry with an internal sub-id or brg-id in one of the tables is found, then these internal values can be used to find the real (long) subscriber identity with a help of the conversion tables (tmnxSubShortEntry and tmnxSubBrgShortEntry).

• Internally generated sub-ids and brg-ids are not saved in a persistency file. The sub-ids and brg-ids change after a reboot. Similar to multihoming, if they are needed by the operator, they must be re-retrieved after a chassis reboot even when persistency is enabled.

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

• The sap-id, in combination with any other allowable identifier, is used as the search key. This assumes a 1:1 (subscriber per SAP) deployment model.

• The circuit-id, in combination with any other allowable identifier, is used to identify subscribers. This can be used in 1:1 deployment model, or in service per SAP deployment model. Circuit-id is applicable to IPoE v4 type hosts (option 82), to IPoE v6 type hosts (option 18 – interface-id) and PPPoE hosts (remote agent option signaled by PPPoE tags). The format of circuit-id is identical for IPv4 and IPv6 hosts.

• The remote-id, in combination with any other allowable identifier, is used to identify subscribers. This can be used in 1:1 deployment model, or in service per SAP deployment model. The remote-id is applicable to IPoE v4 type hosts (option 82), to IPoE v6 type hosts (option 37) and PPPoE hosts (remote agent option signaled by PPPoE tags).

• The mac address (in combination with any other allowable identifier is used to identify subscribers. This assumes a 1:1 deployment model.

• The PPPoE session ID, in combination with any other allowable identifier, is applicable only to PPPoE hosts. The session ID used is the first host that is instantiated for the subscriber.

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.

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.

The following is a deployment example scenario.

CLI syntax:

    config
     subscriber-mgmt
        auto-sub-id-key 
            ppp-sub-id-key sap-id
            ipoe-sub-id-key mac circuit-id

CLI syntax:

    config
     service vprn 10
         subscriber-interface <ip-int-name>
         authentication-policy <auth-pol-name>
         group-interface <ip-int-name>
            sap 1 
                sub-sla-mgmt
                    def-sub-id 	use-sap-id 
                    sub-ident-policy <ident-pol-name>
            sap 2 
                sub-sla-mgmt
                    def-sub-id auto-id 
                    sub-ident-policy <ident-pol-name>
            sap 3 
                sub-sla-mgmt
                    def-sub-id ‟sub3”
                    sub-ident-policy <ident-pol-name>
            sap 4 
                sub-sla-mgmt
                        sub-ident-policy <ident-pol-name>

Assume the following cases:

1. RADIUS returns the sub-id on all four SAPs.

2. RADIUS does not return the sub-id string on any of the SAPs.

In the first case where RADIUS returns the sub-id string, on all four SAPs, the sub-id string is assigned by the RADIUS server. Defaults have no effect, and neither do identifiers specified under the auto-sub-id-key node.

In the second case, the effects are the following:

• On SAP1 the sub-id name is the sap-id (1/1/1:3)

• On SAP 2 the sub-id name is the sap-id for PPPoE hosts and <mac>-<circuit-id> concatenation for IPoE type hosts.

• On SAP3 the sub-id name is the literal ‛sub3’ for PPPoE and IPoE hosts.

• On SAP4 the sub-id name is a semi-random value based on the sap-id for PPPoE hosts and the <mac, circuit-id> combination for IPoE hosts.

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.

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.

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.

Host limits list the host limits and Session limits lists the session limits that can be configured in the following profiles:

• sla-profile

  The limits are enforced per SLA profile instance.

• sub-profile

  The limits are enforced per subscriber.

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.

configure
    subscriber-mgmt
        sla-profile "sla-profile-1"
            description "host and sessions limits per SLA Profile Instance"
            host-limits
                ipv4-overall 1
                ipv4-arp 0
                ipv4-dhcp 1
                ipv6-pd-overall 1
                ipv6-wan-overall 0
            exit
            session-limits
                ipoe 1
                pppoe-overall 0
                l2tp-overall 0
            exit
        exit
        sub-profile "sub-profile-1"
            description "host and session limits per subscriber"
            session-limits
                overall 2

Host limit counters applicable per subscriber host type specifies the host-limits counters that are applicable for each of the different subscriber host types in SR OS. Session limit counters applicable per subscriber session type 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:

6338 2020/09/24 09:48:50.612 UTC WARNING: DHCP #2005 Base Lease State Population Error

"Lease state table population error on SAP 1/1/4:2111.1 in service 1000 - sub-profile 'sub-profile-1' : host-limit overall (1) exceeded for subscriber 'ipoe-001'"

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.

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

• Include the 245.26.6527.5 Alc-Spi-Host-And-Session-Limits and 245.26.6527.6 Alc-Sub-Host-And-Session-Limits VSAs in the RADIUS Access-Accept message during authentication.

  See the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for a detailed description of the VSAs.

• Include the NOKIA-1047 Alc-Spi-Host-And-Session-Limits and NOKIA-1048 Alc-Sub-Host-And-Session-Limits Vendor Specific Diameter AVPs in a CCA-I or CCA-U message during authentication.

  See the 7750 SR and VSR Gx AVPs Reference Guide for a detailed description of the AVPs.

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:

• show service id service-id dhcp lease-state detail

• show service id service-id dhcp6 lease-state detail

• show service id service-id slaac host detail

• show service id service-id arp-host detail

• show service id service-id ppp session detail

• show service id service-id pppoe session detail

• show service id service-id ipoe session detail

• show service id service-id managed-hosts type {aaa | bonding | data-triggered | gtp | wpp}

For example:

# show service id 1000 ipoe session subscriber "ipoe-001" detail
===============================================================================
IPoE sessions for service 1000
===============================================================================
SAP                     : [1/1/4:2111.1]
Mac Address             : 0a:11:00:00:00:01
Circuit-Id              : pe1|1000|group-int-2-1|1/1/4:2111.1
Remote-Id               : 0a:11:00:00:00:01
Session Key             : sap-mac
--- snip ---
Subscriber Session Limit Overrides
 ipoe                   : 3
 pppoe-overall          : 0
 l2tp-overall           : 0
SLA Profile Instance Session Limit Overrides
 ipoe                   : 1
 pppoe-overall          : 0
 l2tp-overall           : 0
-------------------------------------------------------------------------------
Number of sessions : 1
===============================================================================

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

• ensure that all hosts and sessions that belong to the same SLA profile instance receive the same dynamic SLA profile instance limit overrides

• ensure that all hosts and sessions that belong to the same subscriber receive the same dynamic subscriber limit overrides

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.

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

ESM, for example, in a VLAN-per-service model, different services belonging to a single subscriber are split over different SAPs, and therefore 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 subscriber profile refers to HQoS ingress and egress scheduler policies which define the overall treatment for hosts of this subscriber when queues are used, or policers managed by HQoS are used at egress. If the subscriber is using policers, the subscriber profile also refers to CFHP ingress and egress policer-control-policies which define the overall treatment for hosts of this subscriber.

• The SLA profile refers to specific queue or policer settings for each host (BTV, VoIP, PC) using SAP ingress and SAP egress QoS policies. The SLA profile can also refer to an egress HQoS scheduler policy which defines the scheduling from the queues of the related host.

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.

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.

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 composed of:

• ingress and egress queues

• egress policers

• egress SLA-profile schedulers

• ingress and egress subscriber profile schedulers

• egress Vport schedulers

• port schedulers

The ingress hierarchical parenting relationship options are shown in Ingress scheduling hierarchy options.

The egress hierarchical parenting relationship options are shown in Egress scheduling hierarchy options. 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.

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.

config>qos>sap-ingress>queue# parent
  - parent scheduler-name [weight weight] [level level]
                            [cir-weight cir-weight] [cir-level cir-level]

config>qos>sap-egress>queue# parent
- parent scheduler-name [weight weight] [level level]
                            [cir-weight cir-weight] [cir-level cir-level]


config>qos>scheduler-policy>tier>scheduler# parent
- parent scheduler-name [weight weight] [level level]
                            [cir-weight cir-weight] [cir-level cir-level]

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.

      config>qos>sap-egress# parent-location default

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).

      config>qos>sap-egress# parent-location sla

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

      config>qos>scheduler-policy>tier# parent-location none

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.

      config>qos>scheduler-policy>tier# parent-location sub

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.

      config>qos>scheduler-policy>tier# parent-location 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.

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 composed of:

• Ingress and egress policers

• Ingress and egress subscriber arbiters

The ingress hierarchical parenting relationship options are shown in Ingress policing hierarchy options.

The egress hierarchical parenting relationship options are shown in 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.

config>qos>sap-ingress>policer$ parent
  - parent arbiter-name [weight weight-level] [level level]

config>qos>sap-egress>policer$ parent
- parent arbiter-name [weight weight-level] [level level]

config>qos>plcr-ctrl-plcy>tier>arbiter# parent
- parent arbiter-name [weight weight-level] [level level]

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) because of 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 for a specific 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 specific 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

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:

configure
    subscriber-mgmt
        sub-profile <subscriber-profile-name>
            volume-stats-type ip

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:

• Layer 3/IP accounting is not supported in combination with MLPPP

• Layer 3/IP accounting in combination with ESMoPW and last-mile-aware shaping may be inaccurate if the MPLS encapsulation overhead changes during the lifetime of a subscriber.

• Layer 3/IP accounting is restricted to a single encap per sla-profile instance (queue instance). The first host associated with the sla-profile instance (queue instance) determines the allowed encapsulation. Conflicting encapsulations are:

  • PPPoE and IPoE on regular Ethernet SAPs

  • PPPoE and IPoE on PW SAPs

• PPPoE keep alive packets do not contain IP payload and introduce an error in Layer 3/IP accounting when enabled in combination with L2TP-LAC. A workaround is to isolate the keep alives in a separate queue or policer.

• Padding of frames smaller than the Ethernet minimum frame size (64B) may introduce an inaccuracy in Layer 3/IP accounting.

• With ATM in the last mile, last-mile-aware shaping may introduce an inaccuracy in Layer 3/IP accounting.

• Packet-Byte-Offset (PBO) changes during the lifetime of a subscriber introduces an inaccuracy in Layer 3/IP accounting.

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).

configure subscriber-mgmt
        sla-profile "sla-profile-1" create
            ingress
                qos 10
                    queue 1
                        stat-mode v4-v6
                    exit
                    policer 1
                        stat-mode v4-v6
                    exit
                exit
            exit
            egress
                qos 10
                    queue 1
                        stat-mode v4-v6
                    exit
                    policer 1
                        stat-mode v4-v6
                    exit
                exit
            exit
        exit

For policers, the stat-mode command overrides the policer stat-mode configuration as defined in the sap-ingress or sap-egress qos policy. For information about sap-ingress and sap-egress policer stat-mode, see 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:

• Offered IPv4 octets and packets

• Offered IPv6 octets and packets

• Dropped IPv4 octets and packets

• Dropped IPv6 octets and packets

• Forwarded IPv4 octets and packets

• Forwarded IPv6 octets and packets

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:

• Offered High Priority, Low Priority, Uncolored, Managed octets and packets

• Dropped IPv4 octets and packets

• Dropped IPv6 octets and packets

• Forwarded IPv4 octets and packets

• Forwarded IPv6 octets and packets

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

• SNMP

• CLI

show service active-subscribers detail
- - - snip - - -
------------------------------------------------------------------------
SLA Profile Instance statistics
------------------------------------------------------------------------
                        Packets                 Octets

Off. HiPrio           : 0                       0
Off. LowPrio          : 1102685                 1102685000
Off. Uncolor          : 0                       0
Off. Managed          : 0                       0

Queueing Stats (Ingress QoS Policy 10)
Dro. HiPrio           : 0                       0
Dro. LowPrio          : 0                       0
For. InProf           : 0                       0
For. OutProf          : 0                       0
Dro. V4               : 0                       0
Dro. V6               : 0                       0
For. V4               : 367543                  367543000
For. V6               : 735142                  735142000

Queueing Stats (Egress QoS Policy 10)
Dro. InProf           : 0                       0
Dro. OutProf          : 0                       0
For. InProf           : 0                       0
For. OutProf          : 0                       0
Dro. V4               : 0                       0
Dro. V6               : 0                       0
For. V4               : 367543                  367543000
For. V6               : 735088                  735088000

------------------------------------------------------------------------
SLA Profile Instance per Queue statistics
------------------------------------------------------------------------
                        Packets                 Octets

Ingress Queue 1 (Unicast) (Priority) (Stats mode: v4-v6)
Off. HiPrio           : 0                       0
Off. LowPrio          : 1102685                 1102685000
Dro. V4               : 0                       0
Dro. V6               : 0                       0
For. V4               : 367545                  367545000
For. V6               : 735146                  735146000

Egress Queue 1 (Stats mode: v4-v6)
Dro. V4               : 0                       0
Dro. V6               : 0                       0
For. V4               : 367547                  367547000
For. V6               : 735096                  735096000

------------------------------------------------------------------------
SLA Profile Instance per Policer statistics
------------------------------------------------------------------------
                        Packets                 Octets

Ingress Policer 1 (Stats mode: v4-v6)
Off. V4               : 0                       0
Off. V6               : 0                       0
Dro. V4               : 0                       0
Dro. V6               : 0                       0
For. V4               : 0                       0
For. V6               : 0                       0

Egress Policer 1 (Stats mode: v4-v6)
Off. V4               : 0                       0
Off. V6               : 0                       0
Dro. V4               : 0                       0
Dro. V6               : 0                       0
For. V4               : 0                       0
For. V6               : 0                       0

• RADIUS accounting

  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-profile counter VSA’s map to IPv4 octets/packets

  • ingress queue high priority dropped counter VSA’s map to IPv4 octets/packets

  • out-of-profile counter VSA’s map to IPv6 octets/packets

  • ingress queue low priority dropped counter VSA’s map to IPv6 octets/packets

  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 VSAs 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

  See the 7450 ESS, 7750 SR, and VSR RADIUS Attributes Reference Guide for a detailed description of all counter attributes.

• XML accounting

  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

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

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

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

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

CLI syntax:

    show filter ip ip-filter-id detail
    show filter ipv6 ip-filter-id detail
    show filter ip ip-filter-id type entry-type
    show filter ipv6 ipv6-filter-id type entry-type
 entry-type : fixed | radius-insert | credit-control-insert | radius-shared
    show service active-subscribers filter [subscriber sub-ident-string] [origin origin]
 sub-ident-string : [64 chars max]
 origin : radius | credit-control”

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 specified entry is related to the single redundant-pair objects (two SAPs on two different nodes) and therefore 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 specified 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 specified entry.

The following principles apply:

• add-operation

  Any dynamic-state created in the application is pushed to the MCS database. MCS then creates and synchronizes with the corresponding peer provided (if configured). The application in the peer node is then notified as soon as the entry has been created. Similarly, the application in the local node (the node where the state has been created) is notified that entry has been synchronized (MCS is ‟in-sync” state). This operation is also used to modify existing MCS database entry.

• local-delete

  The MCS database entry is marked as no longer in use locally and this information is sent to the peer node. If the information is no longer used by applications on both nodes (the application in remote-node has already issued local-delete before), it is removed from database.

• global-delete

  The MCS database entry is removed from both nodes and from the application in the remote node.

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

• An event which leads to a dynamic-state deletion on a standby chassis is handled as ‟local-delete”.

• An event which leads to a dynamic-state deletion on an active chassis is handled as ‟global-delete”.

• An exception to above the rules is an explicit clear command which is handled as global-delete regardless of where the command was executed.

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.

In a stateful BNG dual homing setup, Multi-Chassis Synchronization (MCS) is used to synchronize the subscriber state between the active and standby BNG, including the DHCP lease states, using configure redundancy multi-chassis options sub-mgmt configuration. For IPoE subscribers the synchronization includes DHCPv4 and DHCPv6 lease states and for PPPoE subscribers the synchronization includes DHCPv6 lease states.

The DHCP lease states are synchronized as follows:

• when the lease is created in the system

• at every DHCP renewal

• when the lease is removed from the system

With short lease times in a scaled deployment, MCS synchronization creates additional load on the control plane. Short least times typically occur when the lease-split feature is enabled because a short lease time is used between the DHCP client and DHCP relay agent and a long lease time is used between the DHCP relay agent and DHCP server. With lease split enabled, the MCS application synchronizes the DHCP renewals following the short lease speed.

To reduce the control plane load in scaled multichassis redundant BNG deployments with short DHCP leases, a DHCP lease time threshold can be configured to control the eligibility of a DHCP lease for MCS synchronization at renewal:

# configure redundancy multi-chassis options sub-mgmt dhcp-leasetime-threshold
  - dhcp-leasetime-threshold [days <days>] [hrs <hours>] [min <minutes>] [sec <seconds>]
  - no dhcp-leasetime-threshold
 <days>               : [0..1]
 <hours>              : [0..23]
 <minutes>            : [0..59]
 <seconds>            : [0..59]

An active DHCP lease time threshold per multichassis peer is determined as the smallest value configured on either of the redundant BNGs:

# show redundancy multi-chassis sync peer 192.0.2.1
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
-------------------------------------------------------------------------------
Peer IP Address         : 192.0.2.1
Peer Name               : mcs-pe2-pe1
Description             : (Not Specified)
Authentication          : Disabled
Source IP Address       : 192.0.2.2
Admin State             : Enabled
Sub-mgmt options        :
  DHCP lease threshold  : Active (10 minutes)
    Local / Remote      : 10 minutes / 15 minutes

The DHCP lease time threshold is inactive when unconfigured or unsupported on at least one end of the multichassis peer:

# show redundancy multi-chassis sync peer 192.0.2.1
===============================================================================
Multi-chassis Peer Table
===============================================================================
Peer
-------------------------------------------------------------------------------
Peer IP Address         : 192.0.2.1
Peer Name               : mcs-pe2-pe1
Description             : (Not Specified)
Authentication          : Disabled
Source IP Address       : 192.0.2.2
Admin State             : Enabled
Sub-mgmt options        :
  DHCP lease threshold  : Inactive
    Local / Remote      : 10 minutes / --

DHCP leases with lease time committed by the DHCP server less than or equal to the active DHCP lease time threshold are not synchronized at renewal, if only the remaining lease time is changed.

When lease split is active, the following rules apply if the short lease time is less than or equal to the active DHCP lease time threshold:

• The DHCP lease is not synchronized when the DHCP client renewal or rebind is proxied, only the remaining short lease time is changed, and at least one DHCP server is reachable.

• The DHCP lease is always synchronized when the DHCP client renewal or rebind is relayed to the DHCP server.

After an MCS redundancy switchover, DHCP leases that are flagged to skip MCS synchronization are granted the full lease time in the new active BNG. This could lead to a temporary address conflict when a client disconnects ungracefully immediately after such a switchover as illustrated in the following scenario:

• A DHCP client lease with 15 minutes lease time is active on a redundant BNG pair with active DHCP lease time threshold equaling 20 minutes.

• Five minutes after the last DHCP client renewal, an SRRP switchover occurs. At the new active BNG, the DHCP lease is eligible to be extended to the DHCP server committed lease time of 15 minutes while the client and server have a remaining lease time of 10 minutes.

• If the client disconnects ungracefully before the next renewal (for example, by not sending a DHCP release), the state in the BNG is not cleared and the session lives longer than expected.

• The lease in the DHCP server expires 10 minutes after the switchover, while the lease in the BNG is still active. The DHCP server can allocate the same address or prefix to another user, which could create a temporary address conflict in the BNG.

Subscriber Routed Redundancy Protocol (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.

Because of 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 because of the explicit association between the SRRP instance group IP interface, the associated redundant IP interface and the multichassis synchronization (MCS) peering. Because only two nodes are participating, the VRRP skew timer is not used when waiting to enter the SRRP master state. Also, SRRP always preempts when the local priority is better than the current SRRP master instance and the backup SRRP instance always inherits the SRRP master’s instance 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 SRRP 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 SRRP 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 SRRP 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 SRRP new master either receives the old SRRP master’s priority zero SRRP advertisement message or the become-master state timer expires, it enters the SRRP 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 SRRP master. If an advertisement is received with the current SRRP master’s source IP address and the local priority is higher priority than the SRRP 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 SRRP master state. Priority zero is a special case and is sent when an SRRP instance is relinquishing the SRRP master state.

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. After 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:

• The SRRP instance MCS key

• Containing service type and ID

• Containing subscriber IP interface name

• Subscriber subnet information

• Containing group IP interface information

• The SRRP group IP interface redundant IP interface name, IP address and mask

• The SRRP advertisement message SAP

• The local system IP address (SRRP advertisement message source IP address)

• The Group IP interface MAC address

• The SRRP gateway MAC address

• The SRRP instance administration state (up or down)

• The SRRP instance operational state (disabled/becoming-backup, becoming-master, master)

• The current SRRP priority

• Remote redundant IP interface availability (available or unavailable)

• Local receive SRRP advertisement SAP availability (available or unavailable)

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

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 because 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.

The SRRP gateway IP addresses on the subscriber subnets cannot be advertised as /32 host routes because they may be active (SRRP master state) on multiple group IP interfaces on multiple SRRP routers. Without a /32 host route path, the network forwards any packet destined for 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 an SRRP master state should respond to ping or other diagnostic messages, the distribution of the subnet and the case of multiple SRRP master states 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.

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. Because 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.

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 an active or standby 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 the master state. Although it is mandatory for the correct 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 correct packet addressing on the IPoE client side as well as the correct 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:

1. If SRRP is used for PPPoE then the ‛SRRP’ MAC address between the redundant BNG nodes must be shared. It is not allowed to use a unique ‛SRRP’ MAC address per BNG in the redundant pair of BNG nodes (as it can for IPoE). Every PADx conversation is based on the SRRP shared MAC address, that is, the PADO reply must have the shared SRRP MAC address as the source MAC. This has a significant impact on the operation of MSAP in conjunction with this feature.

2. Because PPPoE sessions are not ARP aware, the only purpose of the gratuitous ARP would be to update the Layer 2 FDB in the aggregation network (and not the PPPoE client destination MAC address). For IPoE, the gratuitous ARP is sent for all subnet gateway IP addresses found under the subscriber interface over either all SAPs (default) or top-tags only. For PPPoE, the gratuitous ARP is sent only for the system IP address. The purpose of the gratuitous ARP in PPPoE scenario is only to update Layer 2 network path which is otherwise IP unaware. It is not necessary to send the gratuitous ARP for every default-gateway address found under the subscriber-interface. Because this feature is only applicable to PPPoE deployments, therefore, only PPPoE is present under the group interface. This is indicated by the following command under the SRRP node:

    group-interface <ip-int-name>
        srrp <id>
            one-garp-per-sap

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.

multi-chassis
            peer <IP@>create
                sync
                    local-dhcp-server
                    SRRP
                    sub-mgmt [ipoe | pppoe] 
                 :
:
                    no shutdown
                exit
                no shutdown
            exit 

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:

• Forwarding of downstream traffic between the redundant BNG nodes through a redundant interface is an artifact of how natural routing steers traffic through the network.

• Subscriber instantiation on the node which did not originally create subscriber session. This drastically reduces downtime during the SRRP switchover.

• Monitors operational aspects of the subscriber management through show commands.

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

In the upstream direction, this is always true as traffic is steered to the active BNG (SRRP master state) 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 active BNG (SRRP master state). 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 active and standby BNGs. Natural routing on the network side determines which BNG node receives subscriber’s traffic in the downstream direction. If the standby BNG (SRRP backup state) 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 standby BNG must send the traffic to the active BNG through a redundant interface. The active BNG then forwards traffic directly to the subscriber. Source MAC address of this traffic is 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 BNGs.

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

Optimal operation calls 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 master or backup state. To address this problem along with better aggregation of advertised subnets, two SRRP enhancements are introduced:

• SRRP fate-sharing

• SRRP aware routing

Both of these concepts are described in SRRP enhancement.

Traffic destined for 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 (SRRP backup state) to the active (SRRP master state) 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.

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. After 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 correct 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:

config>service>vpls
    sap 1/1/1:1.* capture-sap 
        track-srrp 10
    sap 1/1/1:2.* capture-sap 
        track-srrp 20

config>service>vprn>
    subscriber-interface <ip-int-name>
        group-interface <ip-int-name>
            sap 1/1/1:1.1
                srrp 10
                message-path 1/1/1:1.1

    group-interface <ip-int-name>
        sap 1/1/1:2.1
            srrp 20
                message-path 1/1/1:2.1

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

sap port-id:*.* capture-sap
    track-srrp X

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.

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 toward the BNG node in the upstream direction.

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

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

Traffic destined for 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 (SRRP backup state) to active (SRRP master state) 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.

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 active BNG node (SRRP master state). In the downstream direction, the standby BNG directs traffic over to the active BNG node via 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 active 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 active node. When IPv6 traffic arrives over the redundant-interface on the active 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:

• PPPoEv6

  On the switchover, gratuitous ARPs (gARP) is sent from the new active BNG (SRRP master state) on each VLAN. The IP address in gARP is the IPv4 gw-ip address or the system IP if there are unnumbered interfaces. This updates the Layer 2 network path with the correct SRRP MAC address.

• IPoEv6

  IPv4 based SRRP is used to update the Layer 2 forwarding path in the case of a switchover. A gratuitous ARP is sent in the same way as it is used for IPoE v4 hosts. Router Advertisements (RA) are not sent out in the event of the switchover.

  However, the two BNG nodes share the same virtual Link Local (LL) IPv6 address. This address is used by the clients as a default-gw and only the active BNG (SRRP master state) advertises this LL address in RAs. RAs are suppressed on the standby BNG. As previously mentioned, RAs are not sent during the switchover. RAs are sent:

  • When the client is first established

    This is how the client learns its default-gw (in PPPoE case RA can also be used for SLAAC, stateless address configuration).

  • As a reply to Router Solicitations messages sent by the clients

  • Periodically to each client

  Note that RAs are unicast to each client.

  Neighbor Advertisements (NA) used for address resolution are sent only from the active BNG. NA has the SRRP MAC address in the target link layer option on SRRP enabled group interfaces (on non-SRRP enabled group interfaces, NAs contains the group interface MAC address).

  The LL IPv6 address must be the same on both nodes. In addition, the gw-mac address must be the same on both nodes. The IPv6 clients are not aware of the switchover and therefore they do not send NS to solicit the update of its neighbor cache with the possibly different gw-mac address.

  The syntax to configure the LL address on the subscriber interface is as follows:

        config>service>ies | vprn>
            subscriber-interface <ip-int-name>
                ipv6
                    [no] link-local-address <ipv6-address>

            <ipv6-address>       : ipv6-address   - x:x:x:x:x:x:x:x
                                                    x:x:x:x:x:x:d.d.d.d
                                                     x [0..FFFF]H
                                                     d [0..255]D

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:

• unnumbered subscriber-interfaces (config>service>subscriber-interface hierarchy)

• numbered IPv4 subscriber-interfaces (config>service>subscriber-interface hierarchy)

• numbered IPv4 and IPv6 subscriber-interfaces (config>service>subscriber-interface and config>service>sub-if>ipv6 hierarchy)

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

When local DHCP server redundancy or synchronization is used, using address-range failover local | remote, in conjunction with PPPoE in multichassis 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.

subscriber-interface <ip-int-name>
    group-interface <ip-int-name>
        dhcp
            server <local-dhcp-ip-address> <remote-dhcp-ip-address>

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.

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 standby node (SRRP backup state), 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 active node (SRRP master state) in the absence of redundancy.

When SRRP is in the INIT state on both ends of a multi-chassis redundant setup, such as in the case of directly connected access node failures, the PPPoE session in the BNG does not time out based on the LCP keepalives. When the IPCP address of the PPPoE session is allocated via the internal DHCPv4 client, the PPPoE session is maintained until the DHCPv4 client lease expires. The system deletes the PPPoE session and sends an accounting stop message. No link exists between the router that sends the accounting stop message and the router where the SRRP instance was last active.

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. Because 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 Central Office (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 Subscriber interface in an IES/VPRN service, 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. Details of a group interface shows the details of group interface A.

Aggregation network with direct DSLAM-BSR connection 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).

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.

Detailed view of configurable objects related to Layer 3 subscriber interfaces shows a detailed view of a router and the configuration objects implemented to support Layer 3 subscriber interfaces.

• A subscriber service is defined by an IES Service. One or more IES services can be created.

• Each IES service concentrates a number of subscriber-interfaces. The operator can create multiple subscriber interfaces (represented as a subscriber subnet). A subscriber interface defines at least one subnet.

• A group interface is provisioned within the subscriber interface for each DSLAM connected. All group interfaces created under the subscriber interface share the same subnet (or subnets). Group interfaces (shown as intf_1 and intf_2 in Detailed view of configurable objects related to Layer 3 subscriber interfaces) are configured as unnumbered and are associated with the subscriber-interface under which they are configured.

• SAPs can be configured under the group interface. In a VLAN-per-DSLAM model only, one SAP per group interface is needed, while in the VLAN-per-subscriber model, a subscriber of the DSLAM requires its own SAP. All SAPs on a group interface must be on the same physical port or LAG.

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 ESM.

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.

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.

A routed subscriber host associated route, as shown in Routed subscriber hosts, 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.

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:

configure
    service ies/vprn <service-id>
        subscriber-interface <ip-int-name>
            group-interface <ip-int-name>
                sap <sap-id>
                           anti-spoof nh-mac

configure
    subscriber-mgmt
        msap-policy <msap-policy-name>
            ies-vprn-only-sap-parameters
                anti-spoof nh-mac 

Routes associated with a routed subscriber host (known as managed routes) can be learned in the following ways:

• managed routes configuration for a static host

• the RADIUS or NASREQ authentication [22] Framed-Route and [99] Framed-IPv6-Route attributes

• advertised using an ESM dynamic BGP peer

• learned using a RIP listener neighbor (IPv4 routes only)

• the IPv6 Prefix Delegation prefix as a managed route

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

Dual homing to two PEs 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:

• Loop resolution and failure recovery — Can be based on MC-LAG or mVPLS.

• DHCP-lease-state persistency — Stores all required information to recover from node failure.

• DHCP-lease-state synchronization — A mechanism to synchronize the DHCP lease-state between two PE nodes in the scope of redundancy groups (a group of SAPs used for dual homing).

• IGMP snooping state synchronization — Similarly to DHCP lease-state synchronization, IGMP snooping state is synchronized to ensure fast switchover between PE nodes. In a VPLS network, a BTV stream is typically available in all PE nodes (the ring interconnecting all PEs with Mcast routers is typically used) so the switch over can be purely driven by RSTP or MC-LAG.

• ARP reply agent responses

  The ARP reply agent can response to ARP requests addressing a host behind the specific SAP if the SAP is in a forwarding state. This prevents the FDB table in the VPLS from being ‟poisoned” by ARP responses generated by the node with a SAP in a blocking state (see Layer 2 CO dual homing - network diagram ).

Layer 2 CO dual homing - network diagram 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.

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 Layer 2 CO dual homing - network diagram (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 multichassis synchronization) is configured between redundant pair nodes (BSA-1 and BSA-2 shown in Layer 2 CO dual homing - network diagram ). The multichassis 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 multichassis synchronization and therefore it is mandatory to enable multichassis synchronization between two nodes using the multichassis-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.

Dual homing ring under steady-state condition 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 multichassis ring must be provisioned consistently between two nodes.

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

In Dual homing ring under steady-state condition, the ring is fully closed and every access node has two possible paths toward the VPLS core. Dual homing ring under steady-state condition 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 specific ring node for any specified 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 primary BSA for both paths is based on the IP address of the interface used for IB-RCC communication (bidirectional forwarding session). The BSA with the lower IP address of the interface used as IB-RCC channel becomes the primary for ring nodes and their respective VLANs assigned to path-a. The primary for path-b is the other BSA.

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

In the primary BSA:

• All SAPs that belong to the path where the specific BSA is the primary node are operationally UP and all FDB entries of subscriber hosts associated with these SAPs point to their respective SAPs.

• The primary BSA of a path performs periodical Ring Node Connectivity Verification (RNCV) check to all ring nodes.

• In case of a RNCV failure, the respective alarm is raised. The loss of RNCV to the specified ring node does not trigger any switchover action even if the other BSA appears to have the connection to that ring node. If the BFD session is up, the ring is considered closed and the primary or standby behavior is driven solely by provisioning of the individual paths.

• The ARP reply agent replies to ARP requests addressing subscriber hosts for which the BSA is primary.

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 toward the SDP connecting to the primary BSA (also called a shunt SDP).

In both primary and standby BSAs:

• The information about individual path assignments is exchanged between both BSAs through multichassis synchronization communication channel and conflicting SAPs (being assigned to different paths on both BSA nodes) are forced to path-a (the default behavior).

• For IGMP snooping, the corresponding multichassis IDs are targeting all subscriber-facing SAPs on both nodes. On the standby BSA node, the corresponding SAPs are in an operationally down state to prevent the MC traffic be injected on the ring twice.

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

• Both nodes are configured similarly.

• Peering is up.

• The multichassis ring is provisioned similarly between two nodes

• IB-RCC is operationally down.

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

Functionally, both BSAs are now the primary BSA 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.

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 specified BSA can have subscriber hosts associated with the specified SAP that are behind reachable ring nodes as well as subscriber hosts behind un-reachable ring nodes. This means that the specified 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 specified 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:

• Both nodes trigger a RNCV check toward all ring nodes. The node, which receives the reply first, assumes a primary role and informs the other BSA through an out-of-band channel. This way, the other node can immediately take actions related to the standby role without waiting for an RNCV timeout. Even if the other node receives an RNCV response from the specified ring node later, the primary role remains with the node that received the response first.

• After assuming the primary role for hosts associated with the specified SAPs, the node sends out FDB population messages to ensure that new path toward the VPLS core is established. The FDB population messages are sourced from the MAC address of the default gateway used by all subscriber hosts (such as the VRRP MAC address) which is provisioned at the service level.

By its definition, the multichassis 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 primary for the path-a and the other way around for path-b.

After restoration of BFD session, the primary role, as described in Steady-state operation of dual homed ring, is assumed by respective BSAs. The FDB tables are updated according to the primary/standby role of the specified BSA and FDB population messages are sent accordingly.

The multichassis 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 multichassis ring with a corresponding sync-tag as a ring-name identifying a local port ID must be provision on both nodes. And the BFD session and corresponding interfaces must be configured consistently.

If the multichassis 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:

• By default, all SAPs (and therefore all VLANs on the specified port) are assigned to path-a.

• An explicit statement defining the specified VLAN range assigns all SAPs falling into this range to the path-b.

• An explicit statement defining the specified VLAN range defines all SAPs that are excluded from the multichassis ring control.

• If a conflict in the configuration of VLAN ranges between two redundant nodes is detected, all SAPs falling into the ‟conflict-range” are assigned to path-a, on both nodes regardless the local configuration.

• For QinQ-encapsulated ports the VLAN range refers to the outer VLAN.

Low depicts a single DSLAM dual-homed to two BSRs.

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

• Group interface (dslam-1) with corresponding SAPs (vlan 1-100)

• SRRP instance controlling a specific group interface

• Redundant interface between BSRs to provide ‟shunt” connectivity

• MCS connection to provide synchronization of dynamic subscriber-host entries

During the operation, BSR-1 and BSR-2 resolves active/standby relations and populates respective FDBs in such a way that, subscriber-host entries on the active node (SRRP master state) point to a corresponding group interface while subscriber-host entries on the standby node (SRRP backup state) 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 chapter.

The typical implementation of MC services at the network level is shown in 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 MC services in a Layer 3-Ring topology (a)). 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 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 MC services on a Layer 3-ring topology (b).

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.

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 the primary BSR 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 instead of the BFD API.

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 specific subscriber at a time. Dual homing involves several components:

• Redundant Interface

  This is used to shunt traffic to the active node for a specific subscriber for downstream traffic.

• SRRP

  This is used to monitor the state of connectivity to the DSLAM. See the SRRP section for more detail.

• MCS

  This is used to exchange subscriber host and SRRP information between the dual homed nodes.

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.

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. After 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:

• SRRP instance MCS key

• service type and ID

• subscriber IP interface name

• subscriber subnet information

• group IP interface information

• SRRP group IP interface redundant IP interface name, IP address and mask

• SRRP advertisement message SAP

• local system IP address (SRRP advertisement message source IP address)

• group IP interface MAC address

• SRRP gateway MAC address

• SRRP instance administration state (up or down)

• SRRP instance operational state (disabled/becoming-backup/backup/becoming-master/ master)

• current SRRP priority

• remote redundant IP interface availability (available or unavailable)

• local receive SRRP advertisement SAP availability (available or unavailable)

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.

SRRP Fate Sharing is a concept in which a group of SRRP instances track a single operational-object composed of SRRP messaging SAPs. The SRRP instances behave as one (in the single failure case) with regards to SRRP state (init/master/backup). 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 FSG — single network failure. SRRP Fate Sharing provides optimal protection in the context of a single failure in the network.

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.

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 instances on both BNG nodes can reach the SRRP master state. 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 because they can be tied into Eth-OAM.

After 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 may be needed in to detect the remote end failure and consequently bring the SAP operationally into a DOWN state.

After the single network failure is detected, all instance within the FSG transitions into an SRRP 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.

Failure Detection in a Fate Sharing Group

• Dual homing over directly connected ports. No Eth-OAM is needed, AN is directly connected to the BNG.

  

• Dual homing with aggregation network - aggregation network has no redundancy between Layer 2 switches (STP). To determine whereabouts of failure at point 1 in Scenario 2, Eth-OAM is needed.

  

• Dual homing with aggregation network - aggregation network with redundancy between Layer 2 switches (STP). No Eth-OAM is needed in this case for successful operation. However, the failure detection is based on the failure of the directly attached ports.

  

• Single homing with aggregation network. In this case, SRRP can protect only against direct failures. Any remote failure leaves a part of the network isolated from the subscriber point of view.

  

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 wanted 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:

• Initially configured SRRP priorities for all SRRP instance within the FSG within the node should be the same.

• Initially configured SRRP priorities should be different between pairing FSGs. For example, SRRP instances in the BNG node A within an FSG all have the same SRRP priority ‛X’, while corresponding SRRP instances on the paired node within corresponding FSG all have SRRP priority ‛Y’. This ensures that the SRRP master state is clearly defined between the two BNG nodes. This step is not mandatory as SRRP naturally breaks the master state election tie in the case that all SRRP priorities are the same. However, following this step may provide a clearer view from an operational perspective.

• The priority-step parameter used for dynamic SRRP priority adjustment must be greater than the difference in initially configured SRRP priorities between two BNG nodes. This ensures that a single failure event triggers the SRRP switchover. Otherwise, if the dynamically lowered SRRP priority is still greater than the one from the SRRP peer, the switchover would not be triggered. Therefore, the fate sharing concept would not function as intended.

• Initially configured SRRP priority of each SRRP instance should be greater than the (anticipated) number of SRRP instances in a FSG multiplied by the SRRP priority-step. This ensures that the dynamically priority never tries to go below 1. There is a code check that prevents SRRP priority going below 1. Nonetheless, it is recommended not to get into a situation where this needs to be enforced in the code.

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. Because 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, all SRRP instances within the corresponding FSG are in the SRRP master state on BNG 1.

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 are in the SRRP master state on BNG 2.

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. Because all SRRP priorities are at the maximum (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 SRRP master state), the priority of this FSG would be increased again and the switchover would unnecessarily occur for the second time. The new SRRP instances, when operational, should always be added in the FSG with SRRP master state first.

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

• SRRP initialization

• addition of a SAP under the monitoring group

• messaging SAP failure

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.

There are three cases with its own specifics:

• subscriber interface routes (IPv4/IPv6)

• managed routes

• subscriber management Routes (/32 IPv4 hosts routes and IPv6 PD wan-host routes)

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:

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.

In specific cases, subscriber traffic is terminated on the BNG by an Epipe. In this case, the subscriber traffic can be offloaded onto a plain Ethernet port by a VSM module (a ‛loop’) so that it can be terminated in ESM. Epipes can be configured in A/S configuration and terminated on two BNG nodes in multihomed environment.

In these multihomed environment with Epipes and ‛loops’, the ESM itself detaches from the Epipe, which brings the subscriber traffic to the BNG. Because of that, the ESM would not know if the PW’s state is active or standby. As a result, in the downstream direction, traffic could end up being forwarded toward the standby PW, effectively being black-holed.

To overcome this, SRRP can be used in conjunction with an additional mechanism to help monitor the activity of the PWs. This monitoring mechanism is very similar to Fate-sharing. The difference in this case is that the messaging SAP (instead of SRRP instance) is monitoring the activity of the PW. As a result, the SRRP messaging SAP reflects the state of the PW. For example, the PW in a Standby mode would cause the messaging SAP to be in the DOWN state while the PW Active state would cause the messaging SAP to be in the UP state. That is, the SRRP instance reflects the operational state of the messaging SAP. SRRP is indirectly tied into PW state.

Modifying the priority of SRRP instance based on PW’s state as a mean of tying the SRRP master state to the active PW would not help here as SRRP messages are not flowing over standby PWs. This is why SRRP state must be enforced by the messaging SAP.

Fate-sharing for PW termination in conjunction with SRRP is not supported.

Metric adjustment for the subscriber routes is supported. After the tracked SRRP instance transitions into a non-master SRRP state, the state attribute of the route changes and the appropriate action defined in the routing policy is taken.

The failure detection mechanism to trigger an action within FSG relies on the operational state of the messaging SAP. Such failure detection mechanism is referred as a group monitor.

Group monitor can also be used to detect the state change of the PW. PW state change is reflected in the messaging SAP which in turn triggers the state change of an SRRP instance.

All this is implemented through an oper-group object which is described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN. All entities that needs to be monitored (messaging SAPs and PWs) are associated with this oper-group object. Finally, an SRRP instance (in case of FSG) or a messaging SAP (in case of PW) is instructed to monitor the entities in the oper-group object. State transitions of objects in a oper-group object trigger state transitions of entities that are monitoring them (messaging SAPs and SRRP instances). State transitions of monitored objects in a oper-group cause the following actions:

• With FSG, priorities of SRRP instances are recalculated.

• With PW termination on BNG, the operational state of the messaging SAP is changed.

The following is an overview of the CLI syntax showing the principles to create an operational group (oper-group). For command descriptions and full syntax, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide and 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide.

• Create an oper-group.

       config>service
           oper-group <name> [create]
  

• Add a SAP to the oper-group.

       config>service(ies | vprn)>sub-if>grp-if>sap
           oper-group <name>
  

• Link the state of an oper-group to the SAP. A messaging SAP can monitor the state of a PW.

       config>service(ies | vprn)>sub-if>grp-if>sap
           monitor-oper-group <name>
  

• Link the state of an oper-group to the SRRP instance. A state transition of an object in the oper-group (not the state of the oper-group itself) triggers an SRRP priority recalculation. When an object within the oper-group goes down, the SRRP priority is lowered by a priority step. The SRRP priority is adjusted on every state transition of an oper-group member object.

       config>service(ies | vprn)>sub-if>grp-if>srrp <srrp-id>
           monitor-oper-group <name> priority-step [0-253]
  

• Add a PW to the oper-group. A messaging SAP monitors the oper-group and assumes the state according to the state of the PW in the oper-group. A standby or a down PW state causes the messaging SAP to assume a down state. Otherwise, the messaging SAP would be in the UP state. In order for the SAP to assume the down state, both RX and TX sides of the PW must be shut down. In other words, a PW in standby mode also must have the local TX disabled by the via the ‛slave’ flag (standby-signaling-slave command in the spoke SDP context). Without the TX disabled, the SAP monitoring the PW does not transition in the down state.

       config>service>epipe>spoke-sdp
           oper-group <name>
  
  

A hold timer is provided within the oper-group command to suppress flapping of the monitored object (SAP or pseudowire).

Pseudowire example shows an example with ESM over pseudowire through a VSM loop.

*A:Dut-C>config>service>epipe# info   
----------------------------------------------
            endpoint "x" create
                standby-signaling-master
            exit
            sap 1/1/7:1 create
            exit
            spoke-sdp 1:1 endpoint "x" create
                precedence primary
                no shutdown
            exit
            spoke-sdp 2:1 endpoint "x" create
                no shutdown
            exit
            no shutdown
----------------------------------------------
 
*A:Dut-A>config>service>epipe# info 
----------------------------------------------
            sap ccag-1.b:11 create
            exit
            spoke-sdp 2:1 create
                standby-signaling-slave
                oper-group "1"
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A:Dut-B>config>service>epipe# info 
----------------------------------------------
            sap ccag-1.b:11 create
            exit
            spoke-sdp 2:1 create
                standby-signaling-slave
                oper-group "1"
                no shutdown
            exit
            no shutdown
----------------------------------------------
*A:Dut-A>config>service>ies# info 
----------------------------------------------
            redundant-interface "redif11" create
                address 10.1.1.2/24 remote-ip 10.1.1.4
                spoke-sdp 1:1 create
                    no shutdown
                exit
            exit
            subscriber-interface "subif_1" create
                shutdown
                address 10.1.1.2/24 gw-ip-address 10.1.1.100
                group-interface "grpif_1_2" create
                    shutdown
                    redundant-interface "redif11"
                exit
            exit
            subscriber-interface "subTest" create
                address 10.1.1.2/24 gw-ip-address 10.1.1.254
                group-interface "grpTest" create
                    redundant-interface "redif11"
                    sap ccag-1.a:1 create
                    exit
                    sap ccag-1.a:11 create
                        monitor-oper-group "1"
                    exit
                    srrp 11 create
                        message-path ccag-1.a:11
                        no shutdown
                    exit
                exit
            exit
            no shutdown
----------------------------------------------
*A:Dut-B>config>service>ies# info 
----------------------------------------------
            redundant-interface "redif11" create
                address 10.1.1.4/24 remote-ip 10.1.1.2
                spoke-sdp 1:1 create
                    no shutdown
                exit
            exit
            subscriber-interface "subif_1" create
                shutdown
                address 10.1.1.4/24 gw-ip-address 10.1.1.100
            exit
            subscriber-interface "subTest" create
                address 10.1.1.4/24 gw-ip-address 10.1.1.254
                group-interface "grpTest" create
                    redundant-interface "redif11"
                    sap ccag-1.a:1 create
                    exit
                    sap ccag-1.a:11 create
                        monitor-oper-group "1"
                    exit
                    srrp 11 create
                        message-path ccag-1.a:11
                        no shutdown   
                    exit
                exit
            exit
            no shutdown
----------------------------------------------
*A:Dut-B>config>service>ies# show srrp 
===============================================================================
SRRP Table
===============================================================================
ID        Service        Group Interface                 Admin     Oper
-------------------------------------------------------------------------------
11        1              grpTest                         Up        initialize
-------------------------------------------------------------------------------
No. of SRRP Entries: 1
===============================================================================
*A:Dut-A>config>service>ies# show srrp 
*A:Dut-A>config>service>ies# 
===============================================================================
SRRP Table
===============================================================================
ID        Service        Group Interface                 Admin     Oper
-------------------------------------------------------------------------------
11        1              grpTest                         Up        master
-------------------------------------------------------------------------------
No. of SRRP Entries: 1
===============================================================================

As shown in IP-in-IP, IP-in-IP uses IP protocol 4 (IPv4) to encapsulate IPv4 traffic from the home network across an IPv6 access network. The IPv4 traffic tunneling is treated as best-effort with no subscriber management or policy, and does not use ESM. The scale is dependent only on the internal structures of the MS-ISA and CPM, that is, the IP-in-IP model can support more subscribers than an ESM-based approach.

DS-Lite IP-in-IP is configured through the existing nat command that is inside the CLI statements that are within the base router or VPRN. A service performing large scale NAT supports DS-Lite.

DS-Lite expects a routing (non-NATing) gateway in the home, where many different IPv4 inside addresses exist for each subscriber. These inside addresses may overlap other subscriber’s address, especially with the heavy use of RFC 1918 address space.

The lack of control of protocol for the IP-in-IP tunnels simplifies the functional model, because any received IPv4 packet to the ISA DS-Lite address can be:

• checked for protocol 4 in the IPv6 header

• checked that the embedded IP packet is IPv4

• processed as if it were L2-Aware, where the source-IP of the tunnel (the source IPv6 address) is used as the subscriber identifier

Note that the inside IP address in the NAT, tables must not be the IPv6 address of the tunnel, but the true IPv4 address of any host within the home. The subscriber-id must be the literal IPv6 address (appreciating this may be 34 characters in length).

DS-Lite is configured on an inside service and uses the existing Large Scale NAT policies and outside pools. DS-Lite and NAT44 Large Scale NAT can operate concurrently on the same inside and outside services.

DS-Lite is configured with the following CLI:

configure {router | service vprn service-id}
- [no] nat
- inside
- [no] dual-stack-lite
- [no] *address ipv6-address

In this mode, L2TP provides the transport for IPv4 that allows full ESM capabilities on the 7750 SR. From the node’s perspective, the L2TP tunnel is no different in capability to those already supported. Only the underlying transport (IPv6 instead of IPv4) distinguishes this approach.

To support legacy IPv4 access, L2TP over IPv6 is combined with the existing Layer 2–aware NAT feature as shown in L2TP over IPv6.

As ESM is used, scale is limited by the number of ESM hosts supported on a chassis and any associated resources like queues.

L2TP LNS over IPv6 is supported in both the base routing instance and VPRN that has 6VPE configured.

Like the LNS implementation, tunnels are terminated on any routing interface, including loopback, SAP, or network port. A single interface simultaneously supports IPv4 and IPv6 L2TP tunnel termination by having two different addresses configured.

For greater scalability, L2TP tunnel and session count per chassis are increased to allow 1 tunnel per session.

NAT capabilities are supported by existing Layer 2–aware NAT methods. Note that the L2TP LNS over IPv6 may be used without NAT as well and the L2TP sessions may be either IPv6-only or dual-stack.

The IPv4 and IPv6 addresses of DNS name servers and the IPv4 addresses of NBNS name servers can be dynamically assigned to subscriber sessions from different authentication origins as listed in DNS and NBNS name server authentication origins . The default subscriber management authentication origin priority determines the relative priority when DNS and NBNS name server IP addresses are obtained from multiple origins as illustrated in DNS and NBNS name server authentication origins.

For redundancy purposes multiple name servers can be associated with a subscriber session:

• for NBNS name servers

  a primary and secondary address

• for IPv4 and IPv6 DNS name servers

  a primary, a secondary, and extended addresses

  The extended DNS name servers are an ordered list of addresses beyond primary and secondary and can be provisioned using an SR OS or third party DHCP server only. Extended addresses are not applicable for PPPoE IPCP subscriber hosts.

The order of preference in which the name servers are sent to the client is:

1. primary

2. secondary

3. extended

A client typically contacts the name servers in order of preference.

Typically, all name servers are obtained from the same authentication origin, for example RADIUS, but this is not enforced in SR OS. For each subscriber session, primary, secondary, and extended name servers are independently determined based on the authentication origin priorities.

For example, DNS name server IP addresses obtained from different authentication origins for an IPoE DHCPv4 host (relay):

• a primary DNS server (10.1.1.1) is configured in the Local User Database (LUDB)

• a primary (10.1.2.1) and secondary (10.1.2.2) DNS server is received in a RADIUS Access-Accept message

• the DHCP Offer or Ack message received from the DHCP server contains a domain name server option that includes four DNS servers (10.1.3.1, 10.1.3.2, 10.1.3.3 and 10.1.3.4)

Using default authentication origin priorities, the following DNS name server IP addresses are associated with the subscriber session and included in a domain name server option in the DHCP Ack message sent to the client:

• Primary DNS = 10.1.1.1 (origin = LUDB, highest priority for primary DNS)

• Secondary DNS = 10.1.2.2 (origin = RADIUS, highest priority for secondary DNS)

• Extended DNS 1 = 10.1.3.3 (origin = DHCP)

• Extended DNS 2 = 10.1.3.4 (origin = DHCP)

DNS and NBNS name server authentication origins lists the DNS and NBNS name server configuration options for the different authentication origins.

Alternatively, the SR OS features described in this section can also be used to send DNS and NBNS name server IP addresses to the subscriber sessions. When using these mechanisms, the authentication origin priorities are overruled, and the name servers associated with the session in the BNG do not correspond with the name servers sent to the client.

Important changes occurred in the DNS and NBNS name server origin priorities in SR OS Release 21.7 which could result in different DNS and NBNS name server IP addresses being sent to a subscriber session after an upgrade, if the configurations of the DHCP and RADIUS servers are not simultaneously updated accordingly. To facilitate a smooth transition when the configuration of back-end systems cannot be changed at the time of the upgrade, the legacy behavior, which is backward compatible with SR OS Releases before 21.7 can be enabled using the following configuration:

configure subscriber-mgmt
    system-behavior
        legacy-dns-nbns

The following changes are enabled with the legacy-dns-nbns configuration:

• supported authentication origins and their relative priorities for DNS and NBNS name servers as illustrated in Legacy DNS and NBNS name server authentication origins:

  • DHCPv4 and DHCPv6 relay

    DNS and NBNS name servers can only be provided by the DHCP server

  • DHCPv4 proxy

    default DNS and NBNS name servers configured at the subscriber interface are not considered

  • Local Address Assignment (LAA)

    DNS and NBNS name servers obtained from local address assignment (DHCP server options) have the highest origin priority

• mid-session changes for DNS and NBNS name servers at re-authentication as described in Changing DNS and NBNS name servers mid-session

• a group-interface configured as DHCPv6 Relay inserts a DNS Recursive name server Option (23) in the DHCP Advertise and DHCP Reply message without checking the Option Request Option (6) in the client message

Mid-session changes for DNS and NBNS name servers using RADIUS CoA are enabled by default and are not disabled with the legacy-dns-nbns configuration.